Deployment Guide
製作著作 © 2008 Red Hat, Inc.
Copyright © 2008 Red Hat, Inc. This material may only be distributed subject to the terms and conditions set forth in the Open Publication License, V1.0 or later with the restrictions noted below (the latest version of the OPL is presently available at http://www.opencontent.org/openpub/).
Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder.
Distribution of the work or derivative of the work in any standard (paper) book form for commercial purposes is prohibited unless prior permission is obtained from the copyright holder.
Red Hat and the Red Hat "Shadow Man" logo are registered trademarks of Red Hat, Inc. in the United States and other countries.
All other trademarks referenced herein are the property of their respective owners.
The GPG fingerprint of the security@redhat.com key is:
CA 20 86 86 2B D6 9D FC 65 F6 EC C4 21 91 80 CD DB 42 A6 0E
1801 Varsity Drive Raleigh, NC 27606-2072 USA Phone: +1 919 754 3700 Phone: 888 733 4281 Fax: +1 919 754 3701 PO Box 13588 Research Triangle Park, NC 27709 USA
January 2008
| 改訂履歴 | ||||
|---|---|---|---|---|
| 改訂 5.2-11 | Wed May 21 2008 |
Michael Hideo Smith <mhideo@redhat.com>
|
||
|
||||
概要
This Deployment Guide documents relevant information regarding the deployment, configuration and administration of Red Hat Enterprise Linux 5.2.
- はじめに
- I. ファイルシステム
- II. ネットワーク関連の設定
-
- 3. ネットワークインターフェース
- 4. ネットワーク設定
- 5. サービスへのアクセスの制御
- 6. Berkeley Internet Name Domain (BIND)
- 7. OpenSSH
- 8. Samba
- 9. Dynamic Host Configuration Protocol (DHCP)
- 10. Apache HTTP Server
- 11. FTP
- 12. 電子メール
- 13. LDAP（Lightweight Directory Access Protocol）
- 14. 認証の設定
- III. システム設定
-
- 15. コンソールのアクセス
-
16.
sysconfigディレクトリ -
-
16.1.
/etc/sysconfig/ディレクトリ内のファイル -
-
16.1.1.
/etc/sysconfig/amd -
16.1.2.
/etc/sysconfig/apmd -
16.1.3.
/etc/sysconfig/arpwatch -
16.1.4.
/etc/sysconfig/authconfig -
16.1.5.
/etc/sysconfig/autofs -
16.1.6.
/etc/sysconfig/clock -
16.1.7.
/etc/sysconfig/desktop -
16.1.8.
/etc/sysconfig/dhcpd -
16.1.9.
/etc/sysconfig/exim -
16.1.10.
/etc/sysconfig/firstboot -
16.1.11.
/etc/sysconfig/gpm -
16.1.12.
/etc/sysconfig/hwconf -
16.1.13.
/etc/sysconfig/i18n -
16.1.14.
/etc/sysconfig/init -
16.1.15.
/etc/sysconfig/ip6tables-config -
16.1.16.
/etc/sysconfig/iptables-config -
16.1.17.
/etc/sysconfig/irda -
16.1.18.
/etc/sysconfig/keyboard -
16.1.19.
/etc/sysconfig/kudzu -
16.1.20.
/etc/sysconfig/named -
16.1.21.
/etc/sysconfig/network -
16.1.22.
/etc/sysconfig/nfs -
16.1.23.
/etc/sysconfig/ntpd -
16.1.24.
/etc/sysconfig/radvd -
16.1.25.
/etc/sysconfig/samba -
16.1.26.
/etc/sysconfig/selinux -
16.1.27.
/etc/sysconfig/sendmail -
16.1.28.
/etc/sysconfig/spamassassin -
16.1.29.
/etc/sysconfig/squid -
16.1.30.
/etc/sysconfig/system-config-securitylevel -
16.1.31.
/etc/sysconfig/system-config-selinux -
16.1.32.
/etc/sysconfig/system-config-users -
16.1.33.
/etc/sysconfig/system-logviewer -
16.1.34.
/etc/sysconfig/tux -
16.1.35.
/etc/sysconfig/vncservers
-
16.1.1.
-
16.2.
/etc/sysconfig/ディレクトリ内のディレクトリ - 16.3. その他のリソース
-
16.1.
- 17. 日付と時刻の設定
- 18. X Window System
- 19. X Window System の設定
- 20. ユーザーとグループ
- 21. プリンタの設定
- 22. 自動化タスク
- 23. ログファイル
- IV. セキュリティと認証
-
- 24. セキュリティ概要
- 25. ネットワークの安全性を図る
- 26. セキュリティと SELinux
- 27. 参考文献
Red Hat Enterprise Linux 導入ガイド へようこそ。
Red Hat Enterprise Linux 導入ガイドは、必要性に応じた Red Hat Enterprise Linux のカスタマイズの方法についての情報を含んでいます。このマニュアルは、システムの設定及びカスタマイズのために、総合的でタスク指向なガイドをお探しの場合にはふさわしいです。
このガイドは、ユーザーが Red Hat Enterprise Linux システムの基礎的な知識を持っていることを前堤にしています。 Red Hat Enterprise Linux のインストールにヘルプが必要であれば、 Red Hat Enterprise Linux インストールガイド を参照してください。
本ガイドを読むと、特定の単語が、異なるフォント、書体、サイズ、太さで表記されています。この強調表示は、規則にしたがって行われています。異なる単語であっても、同じスタイルで表記されている場合は、特定のカテゴリに含まれることを示しています。この様に表記されている単語のタイプには次のような物があります。
-
コマンド -
Linux コマンド (場合によっては、その他のオペレーティングシステムコマンド) は、この様に表記します。この様に表記されている場合、その文字列をコマンドラインで入力し、 Enter キーを押せば、そのコマンドを実行することができます。コマンドの中には、ファイル名などの異なる表記部分が含まれることもあります。この場合は、その部分もコマンドの一部であり、全体として1つのコマンドを構成します。例えば、
cat testfileコマンドは、現在の作業ディレクトリにあるtestfileという名前のファイルの内容を表示するのに使用します。 -
ファイル名 -
ファイル名、ディレクトリ名、パス、 RPM パッケージ名は、この様に表記します。このスタイルは、その名前の特定のファイルやディレクトリがシステム上に存在することを示しています。例えば、
ホームディレクトリの
.bashrcファイルには、そのユーザー用の bash シェル定義とエイリアスが保存されています。/etc/fstabファイルには、異なるシステムデバイス及びファイルシステムの情報が保存されています。Web サーバーのログファイル解析プログラムを使用するためには
webalizerRPM をインストールしてください。 - アプリケーション
-
この表記はプログラムがエンドユーザーアプリケーションである (システムソフトウェアではない) ことを示します。例えば、
Mozilla を使用して Web を閲覧します。
- key
-
キーボード上のキーは以下のように表記します。例えば、
ディレクトリ内の特定のファイルをリストする Tab キーによる補完機能を使用するには、
lsコマンドを入力し、次に文字を入力し、最後に Tab キーを押してください。ターミナルがディレクトリ内のその文字で始まるファイルのリストを表示します。 - key-combination
-
キーの組み合わせは、次のように表記されます。例えば、
Ctrl-Alt-Backspace キーの組合せでグラフィカル操作を終了し、グラフィカルなログイン画面かコンソールに戻ります。
- GUI インターフェース上にあるテキスト
-
GUI のインターフェース画面やウィンドウ上に使われる見出し、単語、および文字列は、この様に表記します。このスタイルで表記されている場合、特定の GUI 画面、または GUI 画面上の特定の項目を指しています (チェックボックスやフィールドに付けられた文字列など) 。例えば、
スクリーンセーバーを停止するときにパスワードを要求するようにしたいときは、 パスワードを要求 のチェックボックスを選択します。
- GUI 画面、又はウィンドウ上のメニュー上部
-
この表記がある時は、それがプルダウンメニューの最上位の項目だということを表します。 GUI 画面上にあるその文字列をクリックすると、そのメニューの残りが表示されます。例えば、
GNOME ターミナル上の ファイル には、同じウィンドウ内に複数の シェルプロンプトを開くことができる 新規タブ オプションがあります。
GUI メニューを連続して操作する場合は、次の例のように表記します。
アプリケーション (パネル上のメインメニュー) => プログラム => Emacs テキストエディタ と進み、 Emacs テキストエディタを起動します。
- GUI 画面、又はウィンドウ上のボタン
-
この表記は、 GUI 画面上のクリックできるボタン上にテキストがあることを示します。例えば、
戻る ボタンを押して、最後に表示したウェブページに戻ります。
-
コンピューター出力 -
この表記のテキストは、エラーメッセージやコマンドに対する応答など、シェルプロンプトに表示されるテキストを示します。例えば、
lsコマンドは1つのディレクトリの内容を表示します。例えば、Desktop about.html logs paulwesterberg.png Mail backupfiles mail reports
コマンドの実行結果として表示される出力 (この場合は、ディレクトリの内容) は、上記の様に表示されます。
-
プロンプト -
コンピュータが入力待ちであることを示すプロンプトは、この表記で示されます。例えば、
$#[stephen@maturin stephen]$leopard ログイン: -
ユーザーインプット -
コマンドラインか GUI 画面上のテキストボックスに、ユーザーが入力するテキストはこのように表記します。次の例では、
textがこの表記で示されています。システムをテキストベースのインストールプログラムで起動するには、
boot:プロンプトで、textコマンドを入力する必要があります。 -
<置き換え可能な文字列> -
サンプル例として使用しているテキストです。つまり、ユーザーが入力するデータで置き換えるテキストはこのように表記します。次の例では、
<version-number>がこの表記で示されています。/usr/src/kernels/はカーネルソースのディレクトリです。<version-number>/<version-number>は、このシステムにインストールしているカーネルのバージョンとタイプになります。
また、特定の情報について、ユーザーの注意を引くためにいくつかの注意書きがあります。重要度に応じて、それぞれの項目は、注記、ヒント、重要、注意、警告のマークが付いています。例えば、
注記
Linux は、大文字/小文字を区別します。つまり rose は、 ROSE と rOsE とは異なります。
ヒント
/usr/share/doc/ ディレクトリには、システムにインストールされているパッケージの為の追加のドキュメントが含まれています。
重要
DHCP 設定ファイルを変更した場合、その変更は DHCP デーモンを再起動するまで反映されません。
注意
日常の操作は root で実行しないで下さい。 — システム管理の作業に、 root アカウントで操作をする必要があるとき以外は、通常のユーザーアカウントを使用して下さい。
警告
必要なパーティションだけを削除するよう充分に注意してください。他のパーティションを削除するとデータの損失、システム環境の破損を招く恐れがあります。
Red Hat Enterprise Linux 導入ガイド に誤りがあった場合や、このガイドに関して改善のご意見などあれば、ぜひご連絡ください。 Deployment_Guide コンポーネントに、レポートとして Bugzilla (http://bugzilla.redhat.com/bugzilla/) に提出をお願いします。
改善策をお寄せいただく場合には、できるだけ具体的に説明してください。ガイドの誤りについては、早急に発見できるよう、章及びセクションの番号、前後の文章を添えてお知らせください。
ファイルシステム とは、コンピュータ内に保存されたファイルとディレクトリを示します。１つのファイルシステムは、 ファイルシステムタイプ と呼ばれる異る形式を持つことが出来ます。これらの形式は情報がファイルやディレクトリとしてどの様に保存されるかを決定します。幾つかのファイルシステムタイプはデータを冗長コピーとして保存し、他のファイルシステムタイプはハードドライブへのアクセスを迅速にします。このセクションでは、 ext3 、 swap 、 RAID 、及び LVM ファイルシステムタイプについて説明しています。また、パーティション管理用の parted ユーティリティとファイル権限のカスタム化用の ACL (access control list＝アクセスコントロールリスト) も説明しています。
ユーティリティ parted を使用してユーザーができること
-
既存のパーティションテーブルを表示する
-
既存のパーティションサイズを変更する
-
空き領域または追加のハードドライブからパーティションを追加する
デフォルトでは、 parted パッケージは Red Hat Enterprise Linux をインストールする際に含まれます。 parted を起動するには、 root としてログインしシェルプロンプトでコマンド parted を入力します (/dev/sda/dev/sda
削除またはサイズ変更しようとしているパーティションを含むデバイスは使用中であってはなりません。 同様に、 デバイスに新しいパーティションを作成する際は、 そのデバイスが使用中であってはなりません。
使用中であってはならないデバイスに対して、 デバイス上のパーティションはマウントできません。 また、 デバイス上のいずれの swap 領域も有効にしないようにしてください。
また、 使用中のパーティションテーブルは変更しないでください。 カーネルがその変更を正しく認識できない場合があります。 パーティションテーブルが実際にマウントされたパーティションの状態と一致しない場合、 情報が誤ったパーティションに書き込まれてしまう可能性があるため、 データが紛失、 上書きされてしまいます。
これを簡単に行うには、 システムをレスキューモードで起動します。 ファイルシステムをマウントするよう要求されたら、 スキップ を選択します。
別の方法として、そのドライブが使用中のパーティションを含んでいない場合は(システムプロセスがアンマウントされるファイルシステムを使用またはロックする場合)、umountコマンドを使用してパーティションをアンマウントして、swapoffコマンドを使用してハードドライブ上の全てのスワップ領域を無効にします。
表 1.1. 「parted のコマンド」 一般的に使用される parted コマンドの一覧が含まれています。 これに続くセクションでは、 これらいくつかのコマンドと引数について詳しく説明しています。
| コマンド | 説明 |
|---|---|
check
|
ファイルシステムの簡単なチェックを行う |
cp
|
1つのパーティションから別のパーティションへファイルシステムをコピーする。 転送元と 転送先の部分はそれぞれのパーティションのマイナー番号。
|
help
|
使用可能なコマンドの一覧を表示する |
mklabel
|
パーティションテーブル用にディスクラベルを作成する |
mkfs
|
ファイルシステムの種類タイプのファイルシステムを作成する
|
mkpart
|
パーティションを作成して、新規のファイルシステムは作成しない |
mkpartfs
|
パーティションを作成して、指定のファイルシステムを作成する |
move
|
パーティションを移動する |
name
|
Mac及びPC98ディスクラベル専用のパーティションに名前を付ける |
print
|
パーティションテーブルを表示する |
quit
|
partedを終了する
|
rescuestart-mbend-mb
|
失われたパーティションをstart-mbから end-mbに救出する
|
resize
|
パーティションサイズを 開始-mbから終了-mbへ変更する
|
rm
|
パーティションを削除する |
select
|
設定するデバイスを別に選択する |
set
|
パーティションにフラグを設定する。 状態は オンまたはオフ。
|
toggle [
|
パーティション NUMBER 上の FLAG の状態を切り替える
|
unit
|
デフォルトのユニットを UNIT に設定する
|
表 1.1. parted のコマンド
parted を開始したら、 コマンド print を入力してパーティションテーブルを表示します。 以下と似たような出力が表示されます。
Model: ATA ST3160812AS (scsi) Disk /dev/sda: 160GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 32.3kB 107MB 107MB primary ext3 boot 2 107MB 105GB 105GB primary ext3 3 105GB 107GB 2147MB primary linux-swap 4 107GB 160GB 52.9GB extended root 5 107GB 133GB 26.2GB logical ext3 6 133GB 133GB 107MB logical ext3 7 133GB 160GB 26.6GB logical lvm
1 番目の行はディスクのタイプ、 製造元、 モデル番号とインターフェースになります。 2 番目の行はディスクラベルのタイプを表示します。 以下残りの出力の 4 番目の行はパーティションテーブルを表示しています。
パーティションテーブル内の マイナー 番号はパーティション number になります。 例えば、 マイナー番号 1 のパーティションは /dev/sda1 になります。 Start と End の値はメガバイト単位です。 Type には metadata、 free、 primary、 extended、 logical があります。 Filesystem はファイルシステムのタイプで、 次のいずれかになります。
-
ext2
-
ext3
-
fat16
-
fat32
-
hfs
-
jfs
-
linux-swap
-
ntfs
-
reiserfs
-
hp-ufs
-
sun-ufs
-
xfs
デバイスの Filesystem に値が表示されない場合、 そのファイルシステムのタイプは不明ということになります。
Flags の欄はパーティションに対して設定されたフラグを表示します。 使用されるフラグは boot、 root、 swap、 hidden、 raid、 lvm、 lba になります。
警告
使用中のデバイス上ではパーティションの作成をしないで下さい。
パーティションを作成する前に、レスキューモードで起動します。(或は、デバイス上の どのパーティションもアンマウントして、デバイス上のすべてのスワップ領域を止めます)
partedをスタートします。ここで、 /dev/sdaは パーティションを作成するデバイス名です。
parted /dev/sda
現在のパーティションテーブルを表示して、十分な空き領域があるかどうか 判定します。
print
十分な空き領域がない場合、 既存のパーティションのサイズを変更することができます。 詳細については、 項1.1.4. 「パーティションのサイズ変更」 を参照してください。
パーティションテーブルから、 新規パーティションの開始点と終了点、 及びパーティションタイプを決定します。 1 つのデバイス上にはプライマリパーティションは 4 つまでしか作れません(拡張パーティションがない場合)。 パーティションが 4 つ以上必要な場合は、 プライマリパーティションを 3 つにして、 拡張パーティションを 1 つ構築し、 その拡張パーティションの中に複数の論理パーティションを持たせることができます。 ディスクパーティションの概要については、 Red Hat Enterprise Linux インストールガイド の付録 ディスクパーティションの概要 を参照してください。
例えば、ハードディスク上の1024メガバイトから2048メガバイトまでを ext3ファイルシステムでプライマリパーティションにするには、次のコマンドを タイプします。
mkpart primary ext3 1024 2048
ヒント
代わりに mkpartfs コマンドを使用すると、 パーティションが作成された後にファイルシステムが作成されます。 しかし parted では ext3 ファイルシステムの作成はサポートしていません。 したがって、 ext3 ファイルシステムを作成したい場合は、 mkpart を使用し、後で説明するように mkfs コマンドでファイルシステムを作成します。
変更はEnterキーを押した時点で反映されます。 ですから実行する前にコマンドを良く確認してください。
パーティションを作成した後で、printコマンドを使用して パーティションテーブルの中で 正しいパーティションタイプ、ファイルシステムタイプ、 及び、サイズになっていることを確認します。またラベルを付けることが出来るように 新規パーティションのマイナー番号も記録しておきます。さらに以下の出力も表示すべきです。
cat /proc/partitions
これでカーネルが新規パーティションを認識することが確実になります。
パーティションはまだ、ファイルシステムを持っていません。以下のようにして ファイルシステムを作成します：
/sbin/mkfs -t ext3 /dev/sda6
警告
パーティションをフォーマットすると、 パーティション上に現在存在するすべてのデータが永久に消滅します。
次に、パーティションにラベルを与えます。例えば、新規パーティションが /dev/sda6で、/workと ラベルを付けたい場合は、次のようにします：
e2label /dev/sda6 /work
デフォルトでは、インストールプログラムは、 パーティションのマウントポイントをラベルとして使用して、 ラベルが固有のものであることを確認します。どのラベルを使用しても構いません。
rootとして、/etc/fstabファイルを編集して新規パーティションを 含む様にします。新しい行は以下に似た状態になります。
LABEL=/work /work ext3 defaults 1 2
1番目の列ではLABEL=に続いて、パーティションに 付けたラベル名が来ます。2番目の列では新規パーティションのマウントポイント、 次の列がファイルシステムタイプ(例えばext3 や swap)となります。フォーマットについて もっと情報が必要な場合は、コマンドman fstabをタイプして そのmanページを御覧下さい。
4番目の列がdefaultsになっている場合、 このパーティションはブート時にマウントされます。 パーティションを再起動せずにマウントするには、次のコマンドをタイプします。
mount /work
警告
使用中のデバイス上のパーティションは削除しないで下さい。
パーティションを削除する前にレスキューモードで起動します。(又は、デバイス上の どのパーティションもアンマウントし、デバイス上のどのスワップ領域も停止します。)
partedをスタートします。ここで、 /dev/sdaは パーティションを作成するデバイス名です。
parted /dev/sda
現在のパーティションテーブルを表示して削除するパーティションの マイナー番号を決定します：
print
rmコマンドを使用してパーティションを削除します。 例えば、マイナー番号3のパーティションを削除するには、次の入力をします：
rm 3
変更はEnterキーを押すとすぐに反映されます。 実行する前にコマンドを再確認して下さい。
パーティションを削除した後は、printコマンドを使用して パーティションテーブルから削除されていることを確認します。また、次の 出力も表示すべきです。
cat /proc/partitions
これでカーネルが、パーティションは削除されたと認識することを確実にします。
最後のステップは/etc/fstabファイルからそれを削除することです。 削除されたパーティションを表明している行を見付けて、ファイルからそれを削除します。
警告
使用中のデバイス上のパーティションのサイズ変更はしないで下さい。
パーティションのサイズ変更の前に、レスキューモードで起動します。(又は、デバイス上のどんなパーティションでも アンマウントして、デバイス上のどのスワップ領域も止めます。)
partedをスタートします。ここで、 /dev/sdaは パーティションをサイズ変更するデバイス名です。
parted /dev/sda
現在のパーティションテーブルを表示してサイズ変更するパーティションのマイナー番号、及び そのパーティションの開始点と終了点を確認します。
print
パーティションのサイズを変更するには、resizeコマンドの後ろに パーティションのマイナー番号、開始点と終了点をメガバイトで付けて実行します。 例えば、次のようにします。
resize 3 1024 2048
警告
パーティションはデバイス上の使用可能領域を超える大きさにはできません。
パーティションのサイズ変更が終了すると、printコマンドで そのパーティションのサイズが正しく変更されたか、正しいパーティションタイプか、 正しいファイルシステムタイプかを確認します。
システムをノーマルモードで再起動して、コマンドdfの使用で パーティションがマウントされているか、新しいサイズが認識されているかを 確認します。
以下のコマンドは、コマンドプロンプトでlvm helpを発行することにより見つけることができます。
| コマンド | 説明 |
|---|---|
dumpconfig
|
有効な設定をダンプする |
formats
|
利用可能なメタデータ形式をリストする |
help
|
ヘルプコマンドを表示する |
lvchange
|
論理ボリュームの属性を変更する |
lvcreate
|
論理ボリュームを作成する |
lvdisplay
|
論理ボリュームに関する情報を表示する |
lvextend
|
論理ボリュームにスペースを追加する |
lvmchange
|
デバイスマッパーの使用により、このコマンドは廃止されました |
lvmdiskscan
|
物理ボリュームとして使用できるデバイスをリストする |
lvmsadc
|
アクティビティデータを収集する |
lvmsar
|
アクティビティレポートを作成する |
lvreduce
|
論理ボリュームのサイズを削減する |
lvremove
|
システムから論理ボリュームを削除する |
lvrename
|
論理ボリュームの名前を変更する |
lvresize
|
論理ボリュームのサイズを変更する |
lvs
|
論理ボリュームに関する情報を表示する |
lvscan
|
ボリュームグループ内のすべての論理ボリュームをリストする |
pvchange
|
物理ボリュームの属性を変更する |
pvcreate
|
LVMにより使用する物理ボリュームを初期化する |
pvdata
|
物理ボリュームに対するディスク上のメタデータを表示する |
pvdisplay
|
物理ボリュームのさまざまな属性を表示する |
pvmove
|
エクステントをある物理ボリュームから別の物理ボリュームに移動する |
pvremove
|
物理ボリュームからLVMラベルを削除する |
pvresize
|
ボリュームグループにより使用されている物理ボリュームのサイズを変更する |
pvs
|
物理ボリュームに関する情報を表示する |
pvscan
|
すべての物理ボリュームをリストする |
segtypes
|
利用可能なセグメントタイプをリストする |
vgcfgbackup
|
ボリュームグループ設定をバックアップする |
vgcfgrestore
|
ボリュームグループ設定を復元する |
vgchange
|
ボリュームグループ属性を変更する |
vgck
|
ボリュームグループの整合性をチェックする |
vgconvert
|
ボリュームグループメタデータ形式を変更する |
vgcreate
|
ボリュームグループを作成する |
vgdisplay
|
ボリュームグループ情報を表示する |
vgexport
|
ボリュームグループをシステムから登録解除する |
vgextend
|
物理ボリュームを論理グループに追加する |
vgimport
|
エクスポートされたボリュームグループをシステムに登録する |
vgmerge
|
論理グループをマージする |
vgmknodes
|
/dev/にボリュームグループデバイスの特別なファイルを作成する |
vgreduce
|
ボリュームグループから物理ボリュームを削除する |
vgremove
|
ボリュームグループを削除する |
vgrename
|
ボリュームグループの名前を変更する |
vgs
|
ボリュームグループに関する情報を表示する |
vgscan
|
すべてのボリュームグループを検索する |
vgsplit
|
新しいボリュームグループに物理ボリュームを移動する |
version
|
ソフトウェアおよびドライバのバージョン情報を表示する |
表 1.2. LVMコマンド
ファイル及びディレクトリには、ファイル所有者、ファイルに関連付けられたグループ、そのシステムのその他ユーザーに関するパーミッションセットがあります。しかし、このパーミッションセットには限界があります。例えば、異なるユーザーに別々のパーミッションを設定することはできません。このため、 アクセス制御リスト (ACL) が導入されました。
Red Hat Enterprise Linux 5 カーネルは ext3 ファイルシステム及び NFS エクスポートファイルシステムに対して ACL サポートを提供します。 ACL は Samba でアクセスされる ext3 ファイルシステム上でも認識されます。
ACLの導入にはカーネルのサポートに加え、aclパッケージが 必要となります。 パッケージにはACL情報の追加、変更、削除、読み出しに使われるユーティリティが含まれています。
cpとmv はファイルやディレクトリに関連するACL をコピー又は移動するコマンドです。
ACLをファイル又はディレクトリに使用する前に、 ACLサポートを利用してファイル又はディレクトリのパーティション をマウントする必要があります。 ローカルext3ファイルシステムの場合は、次のコマンドにてマウントできます。
mount -t ext3 -o acl <device-name><partition>
例は次の通り
mount -t ext3 -o acl /dev/VolGroup00/LogVol02 /work
パーティションが/etc/fstabファイルにある場合、 acl オプションを
LABEL=/work /work ext3 acl 1 2
Sambaを介してext3ファイルシステムに接続され、ACLが有効になっている場合、 Sambaは--with-acl-supportオプションに対応しているため、 ACLは認識されます。Samba共有に接続又はマウントする時に、 特別なフラグは必要ありません。
ACLにはアクセスACL と デフォルトACLの２種類があります。 アクセスACLは特定ファイルやディレクトリのアクセス制御リストです。 デフォルトACLはディレクトリのみに関係し、ディレクトリ内のファイルがACLにアクセス できない場合、デフォルトACLのルールをそのディレクトリに適用します。 デフォルトACLの設定は任意です。
ACLは次のように設定します。
-
ユーザーごと
-
グループごと
-
有効な権利マスクを経由
-
ファイルのユーザーグループに含まれていないユーザー
setfacl ユーティリティでファイルとディレクトリのACLを 設定します。-mオプションにてファイル又はディレクトリの ACLを追加又は変更して下さい。
setfacl -m <rules><files>
次のフォーマットにてルール(<rules>)を指定して 下さい。同じコマンドにてルールを複数指定する場合はコンマで区切って下さい。
-
u:<uid>:<perms> -
ユーザーのアクセルACLを設定します。 ユーザー名、又はUIDを指定できます。 システム上で有効なユーザーを指定して下さい。
-
g:<gid>:<perms> -
グループのアクセルACLを設定します。 グループ名、又はGIDを指定できます。 システム上で有効なグループを指定して下さい。
-
m:<perms> -
有効な権利マスクを設定します。 このマスクはグループが有するすべてのパーミッションと全ユーザー/全グループを連結します。
-
o:<perms> -
ファイルに対するグループのユーザーでないユーザーのアクセスACLを設定します。
余白は無視されます。書き込み、読み取り、実行のパーミッション (<perms>) は r、 w、 x 文字の組み合わせでなければなりません。
ファイル、又はディレクトリのACLが既に存在し、setfaclコマンドが使用されている場合、既存のACLにルールを追加したり、 既存ルールを変更することができます。
読み取りと書き込みのパーミッションをユーザー andrius に与える場合の例は次の通りです。
setfacl -m u:andrius:rw /project/somefile
ユーザー、グループ、その他のパーミッションを全て解除する場合は、-x オプションを使い、パーミッションを指定しないでください。
setfacl -x <rules><files>
UID 500 のユーザーからすべてのパーミッションを解除する場合の例は次の通りです。
setfacl -x u:500 /project/somefile
デフォルトACLを設定するには、d: を追加した後 ルールを追加し、ファイル名の代わりにディレクトリを指定して下さい。
次の例では、ユーザーグループに存在しないユーザーに書き込みと実行 を許可する/share/ディレクトリのデフォルト ACLを設定します。(個別ファイルのアクセスACLによってオーバーライドできます)
setfacl -m d:o:rx /share
ファイル又はディレクトリの既存 ACL を特定するには、 getfacl コマンドを使用して下さい。下記の例では、 getfacl はファイルの既存 ACL を特定するのに使われています。
getfacl home/john/picture.png
上記のコマンドは下記の出力を返します。
# file: home/john/picture.png # owner: john # group: john user::rw- group::r-- other::r--
デフォルト ACL が存在するディレクトリが特定された場合、デフォルト ACL は下記のように表示されます。
[john@main /]$getfacl home/sales/# file: home/sales/ # owner: john # group: john user::rw- user:barryg:r-- group::r-- mask::r-- other::r-- default:user::rwx default:user:john:rwx default:group::r-x default:mask::rwx default:other::r-x
警告
tarコマンドやdumpコマンドでは ACLのバックアップはできません。
star ユーティリティは tar ユーティリティと同様、ファイルのアーカイブを生成しますが、オプションが異なります。よく使用されるオプションの一覧は 表 2.1. 「starのコマンドラインオプション」 を参照下さい。全オプションに関しては star の man ページを参照下さい。 star パッケージにはこのユーティリティが必要です。
| オプション | 説明 |
|---|---|
-c
|
アーカイブファイルを作成します。 |
-n
|
ファイルを抽出しないで下さい。ファイル抽出の影響を確認するため、 -xを併して使用して下さい。
|
-r
|
アーカイブのファイルを置換します。ファイルはアーカイブファイルの最後の 方に書き込まれています。同じパスとファイル名を持つファイルを 全て置換して下さい。 |
-t
|
アーカイブファイルの内容を表示します。 |
-u
|
アーカイブファイルを更新します。 ファイルがアーカイブに存在しない場合、 又はファイルがアーカイブ内の同名ファイルより新しい場合はアーカイブの最後の方に書き込まれています。このオプションはこのオプションは、アーカイブがバックスペース可能な 非ブロックテープ又はファイルの場合のみ使用できます。 |
-x
|
アーカイブからファイルを抽出します。 -U及びファイルシステム の関連ファイルより古いアーカイブのファイルと併して使用された場合は、 ファイルは抽出されません。
|
-help
|
重要性が最も高いオプションを表示します。 |
-xhelp
|
重要性が最も低いオプションを表示します。 |
-/
|
アーカイブよりファイルを抽出する際に、ファイル名の部分にある スラッシュを外さないようにして下さい。 デフォルトでは、ファイルが抽出された際にスラッシュが取り除かれます。 |
-acl
|
ファイル又はディレクトリの作成、抽出中に関連ACLをアーカイブ又は復元します。 |
表 2.1. starのコマンドラインオプション
あるファイルシステムのファイルにACLが設定された場合、そのファイルシステムは ext_attr属性を保持しています。 下記コマンドを使用してこの属性を確認することができます。
tune2fs -l <filesystem-device>
旧カーネルと共にext_attr属性を持つファイルシステム をマウントすることができます。 しかし、設定されたACLはこのカーネルによっては実行されません。
e2fsck ユーティリティのバージョンは、 ext_attr 属性にてファイルシステムを確認するバージョン 1.22 以上の e2fsprogs パッケージに含まれています。 (Red Hat Enterprise Linux 2.1 と 4 のバージョンを含む) それより古いバージョンでの確認は拒否されます。
詳細は次のリソースを参照下さい。
-
aclmanページ — ACLの説明です。 -
getfaclman ページ — ファイルアクセス制御リストの入手方法を説明しています。 -
setfaclman ページ — ファイルアクセス制御リストの設定方法を説明しています。 -
starman ページ —starユーティリティとオプションの詳細を説明しています。
-
http://acl.bestbits.at/ — ACLのWebサイトです。
ネットワークの設定法を説明した後、このセクションでは、リモートログイン、共有ファイル、及びネットワーク上のディレクトリ、更にはウェブサーバーの設定も含むネットワーク関連のトピックを説明しています。
目次
- 3. ネットワークインターフェース
- 4. ネットワーク設定
- 5. サービスへのアクセスの制御
- 6. Berkeley Internet Name Domain (BIND)
- 7. OpenSSH
- 8. Samba
- 9. Dynamic Host Configuration Protocol (DHCP)
- 10. Apache HTTP Server
- 11. FTP
- 12. 電子メール
- 13. LDAP（Lightweight Directory Access Protocol）
- 14. 認証の設定
Red Hat Enterprise Linux を使用したすべてのネットワーク通信は、設定したソフトウェア インターフェース とシステムに接続された 物理的なネットワークデバイス 間で行われます。
ネットワークインターフェース用の設定ファイルは /etc/sysconfig/network-scripts ディレクトリにあります。これらのネットワークインターフェースをアクティブ/非アクティブにするのに使用されるスクリプトもここにあります。インターフェイスファイルの数量と種類はシステムごとに異なりますが、 3 種類のカテゴリのファイルがこのディレクトリに存在します：
-
インターフェース設定ファイル
-
インターフェース制御スクリプト
-
ネットワーク機能ファイル
これらの各カテゴリのファイルは、合同で機能し各種ネットワークデバイスを動作させます。
この章では、これらファイル間の関係とファイルの使用方法について説明していきます。
インターフェースの設定ファイルについて探求する前に、先ずネットワーク設定で使用される主要な設定ファイルを項目別に分けていきます。ネットワークスタックの設定におけるこれらのファイルの役割を理解すると、 Red Hat Enterprise Linux システムをカスタマイズする時に役に立ちます。
主要なネットワーク設定ファイルは、次のようになります：
-
/etc/hosts -
このファイルの主な目的は、他の方法では解決できないホスト名を解決することです。また、 DNS サーバがない小規模ネットワーク上のホスト名の解決にも使用できます。コンピュータが加入しているネットワークの種類に関係なく、このファイルはループバックデバイスの IP アドレス (
127.0.0.1) を指定する行をlocalhost.localdomainとして含む必要があります。詳細はhostsの man ページを参照してください。 -
/etc/resolv.conf -
このファイルは、 DNS サーバと検索ドメインの IP アドレスを指定します。他の設定がない限り、このファイルはネットワーク初期化スクリプトで構成されます。このファイルに関する詳細は
resolv.confの man ページを参照してください。 -
/etc/sysconfig/network-scripts/ifcfg-<interface-name> -
それぞれのネットワークインターフェースには、それに対応するインターフェース設定スクリプトがあります。これらの各ファイルは、そのネットワークインターフェース特定の情報を提供します。このタイプのファイルとそれが受け付けるディレクティブに関する詳細は 項3.2. 「インターフェース設定ファイル」 を参照してください。
警告
/etc/sysconfig/networking/ ディレクトリは ネットワーク管理ツール (redhat-config-network) で使用されており、その内容は手動で編集される べきではありません。設定消去の危険がある為、ネットワーク設定には、１種類の方法だけ使用することが強く推奨されます。
インターフェース設定ファイルは、個々のネットワークデバイス用のソフトウェアインターフェイスを制御します。システムはブートする時、これらのファイルを使用してどのインターフェースを立ち上げるか、及びそれらをどのように構成するかを決定します。これらのファイルは通常、 ifcfg- と名付けられ、 <name> <name> の部分には設定ファイルが制御するデバイスの名前が入ります。
最も一般的なインターフェースファイルの1つは ifcfg-eth0 で、これはシステム内の最初のイーサネット ネットワークインターフェースカード すなわち NIC を制御します。システム内に複数の NIC がある場合は、複数の ifcfg-ethファイル (<X><X> は特定のインターフェースに対する独自の番号) を用意します。各デバイスには独自の設定ファイルがあるので、管理者はそれぞれのインターフェース機能を別々に制御できます。
以下に固定 IP アドレスを使用する ifcfg-eth0 ファイルのサンプルを示します:
DEVICE=eth0 BOOTPROTO=none ONBOOT=yes NETWORK=10.0.1.0 NETMASK=255.255.255.0 IPADDR=10.0.1.27 USERCTL=no
インターフェース設定ファイルで要求される値は、ほかの値によって変わることがあります。たとえば、 DHCP を利用するインターフェース用の ifcfg-eth0 ファイルは、 IP 情報が DHCP サーバーより供給されるため、幾分異なって見えます。
DEVICE=eth0 BOOTPROTO=dhcp ONBOOT=yes
但し、任意のネットワークインターフェースの設定ファイルは、手動で編集することもできます。
イーサネットインターフェースの設定ファイル内の設定可能なパラメータを一覧で以下に示します：
-
BONDING_OPTS=<parameters> -
sets the configuration parameters for the bonding device, and is used in
/etc/sysconfig/network-scripts/ifcfg-bond(see 項3.2.3. 「チャンネルボンディングインターフェース」). These parameters are identical to those used for bonding devices in<N>/sys/class/net/, and the module parameters for the bonding driver as described in<bonding device>/bondingbondingModule Directives.複数のボンディングデバイスが異なる設定を持つことができるようにする為にこの設定法が 使われます。
ifcfg-で<name>BONDING_OPTSを使用する場合は、ボンディングデバイスの オプション指定用には/etc/modprobe.confは使用しないで 下さい。 -
BOOTPROTO=<protocol> -
ここで
<protocol>-
none— 起動時プロトコルを使用してはいけません。 -
bootp— BOOTP プロトコルを使用しなければいけません。 -
dhcp— DHCP プロトコルを使用しなければいけません。
-
-
BROADCAST=<address> -
ここで
<address>ifcalcで自動的に算出されますので、このディレクティブは無用になります。 -
DEVICE=<name> -
ここで
<name> -
DHCP_HOSTNAME -
IP アドレスを受信する前に、 DHCP サーバーがクライアントにホスト名を指定することを要求する場合にのみこのオプションを使用します。
-
DNS{1,2}=<address> -
ここで
<address>PEERDNSディレクティブがyesにセットされている場合は、/etc/resolv.confに配置されます。 -
ETHTOOL_OPTS=<options> -
ここで
<options>ethtoolでサポートされる以下のいずれかのデバイス特有のオプションです。例えば、 100Mb と全 duplex を強制したい場合：ETHTOOL_OPTS="autoneg off speed 100 duplex full"Instead of a custom initscript, use
ETHTOOL_OPTSto set the interface speed and duplex settings. Custom initscripts run outside of the network init script lead to unpredictable results during a post-boot network service restart.注記
速度、又は duplex 設定の変更は、ほとんどいつも
autoneg offのオプションを使用して自動交渉を無効にする必要があることに注意して下さい。オプションエントリは順番に影響されるため、これを最初に示す必要があります。 -
GATEWAY=<address> -
ここで
<address> -
HWADDR=<MAC-address> -
ここで
<MAC-address>はAA:BB:CC:DD:EE:FF形式でのイーサネットデバイスのハードウェアドレスです。このディレクティブは、複数の NIC を持つマシンが各 NIC のモジュールの設定されたロード順序に関係なく、インターフェースが正しいデバイス名を割り当てられていることを確認するのに役立ちます。このディレクティブは、MACADDRとは一緒に 使用しないでください。 -
IPADDR=<address> -
ここで
<address> -
MACADDR=<MAC-address> -
ここで
<MAC-address>はAA:BB:CC:DD:EE:FF形式でのイーサネットデバイスのハードウェアアドレスです。このディレクティブは、 MAC アドレスをインターフェースに割り当てるために使用され、物理 NIC に割り当てられたものを上書きします。このディレクティブは、HWADDRとは一緒に 使用しないでください。 -
MASTER=<bond-interface> -
ここで
<bond-interface>このディレクティブは、
SLAVEディレクティブと共に使用されます。チャンネルボンディングインターフェースについての詳細は、 項3.2.3. 「チャンネルボンディングインターフェース」 を参照してください。
-
NETMASK=<mask> -
ここで
<mask> -
NETWORK=<address> -
ここで
<address>ifcalcで算出されますので、このディレクティブは無用となります。 -
ONBOOT=<answer> -
ここで
<answer>-
yes— このデバイスは起動時に有効にする必要があります。 -
no— このデバイスは起動時に有効にしてはいけません。
-
-
PEERDNS=<answer> -
ここで
<answer>-
yes— DNS ディレクティブがセットしてある場合は、/etc/resolv.confを変更します。 DCHP を使用する場合、yesがデフォルトです。 -
no—/etc/resolv.confを変更しません。
-
-
SLAVE=<bond-interface> -
ここで
<bond-interface>-
yes— このデバイスは、MASTERディレクティブで指定されるチャンネルボンディングインターフェースにより制御されます。 -
no— このデバイスは、MASTERディレクティブで指定されるチャンネルボンディングインターフェースで 制御されません。
このディレクティブは、
MASTERディレクティブと共に使用されます。チャンネルボンディングインターフェースについての詳細は、 項3.2.3. 「チャンネルボンディングインターフェース」 を参照してください。
-
-
SRCADDR=<address> -
ここで
<address> -
USERCTL=<answer> -
ここで
<answer>-
yes— root でないユーザーは、このデバイスを制御できます。 -
no— root でないユーザーは、このデバイスを制御できません。
-
次の例は、 LAN A 用ネットワーク間 IPsec 接続の ifcfg ファイルを示します。この例では接続を識別するための固有名は ipsec1 になっていますので、結果として出るファイル名は /etc/sysconfig/network-scripts/ifcfg-ipsec1 となります。
TYPE=IPsec ONBOOT=yes IKE_METHOD=PSK SRCNET=192.168.1.0/24 DSTNET=192.168.2.0/24 DST=X.X.X.X
上記の例で、 X.X.X.X はパブリックにルート可能な目的地 IPsec ルータの IP アドレスです。
以下は、 IPsec インターフェース用の設定可能なパラメータ一覧です。
-
DST=<address> -
ここで
<address>は、 IPsec の目的ホストまたはルータの IP アドレスになります。これはホスト間 IPsec 設定とネットワーク間 IPsec 設定のいずれでも使用されます。 -
DSTNET=<network> -
ここで
<network>は、 IPsec 目的ネットワークのネットワークアドレスです。これはネットワーク間 IPsec 設定にのみ使用されます。 -
SRC=<address> -
ここで
<address>は、 IPsec 発信元ホストまたはルータの IP アドレスです。この設定はオプションで、ホスト間 IPsec 設定にのみ使用されます。 -
SRCNET=<network> -
ここで
<network>は、 IPsec 発信元ネットワークのネットワークアドレスです。これはネットワーク間 IPsec 設定にのみ使用されます。 -
TYPE=<interface-type> -
ここで
<interface-type>はIPSECです。このアプリケーションの両方ともipsec-toolsパッケージの一部です。
IPsec で手動のキー暗号化を使用する場合は、設定パラメータを /usr/share/doc/initscripts-(<version-number>/sysconfig.txt<version-number> にはインストールしている initscripts パッケージのバージョンを入れます) で参照してください。
racoon IKEv1 キー管理用デーモンは交渉して IPSec のパラメータセットの設定をします。これは、事前共用のキーである RSA 署名、又は GSS- API を使用できます。 racoon がキーの自動暗号化を管理する為に使用される場合、次のオプションが必要になります:
-
IKE_METHOD=<encryption-method> -
ここで
<encryption-method>は、PSK、X509、GSSAPIのいずれかになります。PSKを指定する場合は、IKE_PSKパラメータも設定する必要があります。X509を指定する場合は、IKE_CERTFILEパラメータも設定する必要があります。 -
IKE_PSK=<shared-key> -
ここで
<shared-key>は、 PSK (preshared キー) 方法に共有している機密の値です。 -
IKE_CERTFILE=<cert-file> -
ここで
<cert-file>は、ホスト用の有効なX.509証明書ファイルです。 -
IKE_PEER_CERTFILE=<cert-file> -
ここで
<cert-file>は、 リモート ホスト用の有効なX.509証明書ファイルです。 -
IKE_DNSSEC=<answer> -
ここで
<answer>はyesです。racoonデーモンは DNS 経由でリモートホストのX.509証明書を回収します。IKE_PEER_CERTFILEを指定する場合は、このパラメータを 含ませない でください。
IPsec に使用できる暗号化アルゴリズムに関する詳細は、 setkey の man ページを参照してください。 racoon に関する詳細は、 racoon 及び racoon.conf の man ページを参照してください。
Red Hat Enterprise Linux では、管理者は bonding カーネルモジュールと チャンネルボンディングインターフェース と呼ばれる特殊なネットワークインターフェースを使用して、複数のネットワークインターフェースを単一チャンネルに結合することができます。チャンネルボンディングで複数のネットワークインターフェースを 1 つのネットワークインターフェースとして動作させることが可能で、同時にバンド幅を広げ冗長性を持たせることができます。
チャンネルボンディングインターフェースを作成するには、 /etc/sysconfig/network-scripts/ ディレクトリ内に ifcfg-bond というファイルを作成します。 <N><N> の部分には、 0 など、インターフェースの数を入れます。
ファイルの内容は、イーサネットインターフェースなど、結合されるインターフェースのタイプがどれであっても、そのタイプと酷似しています。唯一の違いは、 DEVICE= ディレクティブを bond にする必要があることです。 <N><N> にはインターフェースの数が入ります。
以下は、チャンネルボンディング設定ファイルの例です。
DEVICE=bond0 BONDING_OPTS="mode=1 miimon=500" BOOTPROTO=none ONBOOT=yes NETWORK=10.0.1.0 NETMASK=255.255.255.0 IPADDR=10.0.1.27 USERCTL=no
チャンネルボンディングインターフェースを作成したら、結合するネットワークインターフェースは MASTER= と SLAVE= ディレクティブをその設定ファイルに追加して設定する必要があります。チャンネルに結合された各インターフェイスの設定ファイルはほぼ同一のものになります。
例えば、チャンネルボンディングした 2 つのイーサネットインターフェース、 eth0 と eth1 はいずれも次の例のようになります:
DEVICE=eth<N> BOOTPROTO=none ONBOOT=yes MASTER=bond0 SLAVE=yes USERCTL=no
この例にある <N> にはインターフェースの数値を入れます。
使用頻度の少ない 2 種類のインターフェース設定ファイルが エイリアス と クローン です。
複数のアドレスを単一インターフェースにバインドするために使われるエイリアスインターフェース設定ファイルは、この ifcfg- 命名慣習に従います。
<if-name>:<alias-value>
例えば、 ifcfg-eth0:0 ファイルは、 DEVICE=eth0:0 と静的 IP アドレス 10.0.0.2 を指定するよう設定でき、 ifcfg-eth0 の DHCP 経由でその IP 情報を受け取るためにすでに設定されているイーサネットインターフェースのエイリアスとして機能します。この設定では、 eth0 は動的 IP アドレスにバウンドされますが、同じ物理的ネットワークカードが固定 IP アドレスの 10.0.0.2 経由で要求を受け取ることができます。
注意
エイリアスインターフェースは DHCP をサポートしません。
クローンインターフェース設定ファイルは ifcfg- の命名慣習に従います。エイリアスファイルは、既存のインターフェースに対して複数のアドレスを許可しますが、クローンファイルはインターフェースに追加オプションを指定するのに使用します。たとえば、 <if-name> -<clone-name>eth0 という標準の DHCP イーサネットインターフェースの場合は、次のようなものになります:
DEVICE=eth0 ONBOOT=yes BOOTPROTO=dhcp
設定されていない場合、 USERCTL ディレクティブのデフォルト値は no になっているので、ユーザーはこのインターフェースをアップ/ダウンすることはできません。ユーザーがインターフェースを操作できるようにするには、 ifcfg-eth0 を ifcfg-eth0-user にコピーしてクローンを作成し、以下の行を ifcfg-eth0-user に追加します。
USERCTL=yes
これで、 ifcfg-eth0 と ifcfg-eth0-user からの設定オプションが結合されるので、ユーザーは /sbin/ifup eth0-user コマンドを使用して eth0 インターフェースを立ち上げることができます。これは非常に基本的な例ですが、この方法はさまざまなオプションとインターフェースで使用できます。
ダイヤルアップ接続を通してインターネットに接続する場合、インターフェース用に設定ファイルが必要です。
PPP インターフェイスファイルは、以下の形式を使用して名付けられます:
-
ifcfg-ppp<X> -
ここで
<N>は、特定のインターフェースに対応する数値です。
PPP インターフェース設定ファイルは、 wvdial、 ネットワーク管理ツール、又は Kppp がダイヤルアップアカウントの作成に使用された時に、自動的に作成されます。また、このファイルは手動で作成、編集が可能です。
以下に標準的な ifcfg-ppp0 ファイルを示します：
DEVICE=ppp0 NAME=test WVDIALSECT=test MODEMPORT=/dev/modem LINESPEED=115200 PAPNAME=test USERCTL=true ONBOOT=no PERSIST=no DEFROUTE=yes PEERDNS=yes DEMAND=no IDLETIMEOUT=600
SLIP(Serial Line Internet Protocol) はもう1つのダイアルアップインターフェースですが、一般には使用されなくなっています。 SLIP ファイルのインターフェース設定ファイル名には、 ifcfg-sl0 などがあります。
これらのファイルで使用できる他のオプションを以下に示します：
-
DEFROUTE=<answer> -
ここで
<answer>-
yes— このインターフェースをデフォルトルートとして設定します。 -
no— このインターフェースをデフォルトルートとして設定しません。
-
-
DEMAND=<answer> -
ここで
<answer>-
yes— このインターフェースにより、接続を試みられたときにpppdはその接続を開始します。 -
no— このインターフェースの接続は手動で確立する必要があります。
-
-
IDLETIMEOUT=<value> -
ここで
<value> -
INITSTRING=<string> -
ここで
<string> -
LINESPEED=<value> -
ここで
<value>57600、38400、19200、9600があります。 -
MODEMPORT=<device> -
ここで
<device> -
MTU=<value> -
ここで
<value>576に設定すると、脱落するパケットが減り、接続のスループットが若干改善されます。 -
NAME=<name> -
ここで
<name> -
PAPNAME=<name> -
ここで
<name> -
PERSIST=<answer> -
ここで
<answer>-
yes— このインターフェースは、たとえモデムがハングアップした後に停止されても、常にアクティブのままにする必要があります。 -
no— このインターフェースは常にアクティブのままにしてはいけません。
-
-
REMIP=<address> -
ここで
<address> -
WVDIALSECT=<name> -
ここで
<name>/etc/wvdial.confのダイアラ設定とこのインターフェースを関連付けます。このファイルには、ダイアルする電話番号、インターフェースの重要情報などが含まれています。
他の一般的なインターフェイス設定ファイルは次の項目を含みます：
-
ifcfg-lo -
ローカルの ループバック インターフェイス はよくテストで 使用されるだけでなく、同じシステムを指定し直す IP アドレスを必要とするさまざまなアプリケーションでも使用されます。ループバックデバイスに送信されたデータはすぐにホストのネットワーク層に戻されます。
警告
ループバックインターフェースのスクリプトである
/etc/sysconfig/network-scripts/ifcfg-loは絶対に手動で編集しないで下さい。編集するとシステムの正常な動作が妨害される可能性があります。 -
ifcfg-irlan0 -
赤外線インターフェース によって、ラップトップとプリンタなどデバイス間の情報を赤外線リンク上で流すことができます。これは、通常ピアツーピア接続で可能という事以外はイーサネットと同じような方法で動作します。
-
ifcfg-plip0 -
PLIP (Parallel Line Interface Protocol) 接続も、パラレルポートを使用すること以外は、殆んどイーサネットデバイスと同様な方法で動作します。
-
ifcfg-tr0 -
トークンリング トポロジーは以前程 LAN (Local Area Networks) 上で一般的ではありません。イーサネットによって取り残されています。
インターフェース制御スクリプトは、システムインターフェースの起動と停止をします。おもなインターフェース制御スクリプトとしては /etc/sysconfig/network-scripts ディレクトリ内に、 /sbin/ifdown と /sbin/ifup の 2 つがあり、各種制御スクリプトをコールします。
ifup と ifdown のインターフェーススクリプトは、 /sbin/ ディレクトリにあるスクリプトへのシンボリックリンクです。どちらかのスクリプトが呼び出されると、次のような、指定されるべきインターフェースの値を要求します:
ifup eth0
注意
ユーザーがネットワークインターフェースを立ち上げたり、落したりするのに使用すべきスクリプトは、 ifup と ifdown のインターフェーススクリプトだけです。
参考のために以下にスクリプトの例をあげておきます。
ネットワークインターフェースを立ち上げるプロセスで各種のネットワーク初期化タスクを行なうために使用される 2 つのファイルは、 /etc/rc.d/init.d/functions と /etc/sysconfig/network-scripts/network-functions です。詳細については 項3.5. 「ネットワーク機能ファイル」 を参照してください。
インターフェースが1つ指定済みであることと、要求を実行中のユーザーがそのインターフェースの制御をする許可があることを確認した後、正しいスクリプトがインターフェースをアップ/ダウンします。以下に、 /etc/sysconfig/network-scripts/ ディレクトリ配下にある一般的なインターフェース制御スクリプトを示します。
-
ifup-aliases -
複数の IP アドレスが 1 つのインターフェイスに関連付けられている場合、インターフェース設定ファイルから IP エイリアスを設定します。
-
ifup-ipppとifdown-ippp -
ISDN インターフェースをアップとダウンする為に使用します。
-
ifup-ipsecとifdown-ipsec -
IPsec インターフェースをアップとダウンする為に使用します。
-
ifup-ipv6とifdown-ipv6 -
IPv6 インターフェースをアップとダウンする為に使用します。
-
ifup-ipx -
IPX インターフェースをアップする為に使用します。
-
ifup-plip -
PLIP インターフェースをアップする為に使用します。
-
ifup-plusb -
ネットワーク接続用の USB インターフェースをアップする為に使用します。
-
ifup-postとifdown-post -
これらには、インターフェイスを立ち上げた後、及び停止した後に実行されるコマンドが含まれています。
-
ifup-pppとifdown-ppp -
PPP インターフェースをアップとダウンする為に使用します。
-
ifup-routes -
デバイスの静的ルートを、そのインターフェイスがアップするときに追加します。
-
ifdown-sitとifup-sit -
IPv4 接続内にある IPv6 トンネルのアップ/ダウンに関連した機能呼び出しを含みます。
-
ifup-slとifdown-sl -
SLIP インターフェースをアップとダウンする為に使用します。
-
ifup-wireless -
ワイヤレスインターフェースをアップする為に使用します。
警告
/etc/sysconfig/network-scripts/ ディレクトリのスクリプトを削除、または変更すると、インターフェース接続のおかしな動作や、停止等の原因となるので注意してください。ネットワークインターフェイス関連のスクリプトを変更するのは、経験豊富な上級ユーザーに限ってください。
すべてのネットワークスクリプトを同時に操作する最も簡単な方法は、ネットワークサービス (/etc/rc.d/init.d/network) 上の /sbin/service コマンドを使用することです。以下のコマンドの例のようにします：
/sbin/service network <action>
ここでは、 <action> は、 start か、 stop か、 restart のいずれかとなります。
設定したデバイスと現在アクティブになっているネットワークインターフェースの一覧を表示するには、次のコマンドを使用します：
/sbin/service network status
Routing will be configured on routing devices, therefore it should not be necessary to configure static routes on Red Hat Enterprise Linux servers or clients. However, if static routes are required they can be configured for each interface. This can be useful if you have multiple interfaces in different subnets. Use the route command to display the IP routing table.
Static route configuration is stored in a /etc/sysconfig/network-scripts/route- file. For example, static routes for the eth0 interface would be stored in the interface/etc/sysconfig/network-scripts/route-eth0 file. The route- file has two formats: IP command arguments and network/netmask directives.
interface
IP Command Arguments Format
Define a default gateway on the first line. This is only required if the default gateway is not set via DHCP:
defaultX.X.X.Xdevinterface
X.X.X.X is the IP address of the default gateway. The interface is the interface that is connected to, or can reach, the default gateway.
Define a static route. Each line is parsed as an individual route:
X.X.X.X/XviaX.X.X.Xdevinterface
X.X.X.X/X is the network number and netmask for the static route. X.X.X.X and interface are the IP address and interface for the default gateway respectively. The X.X.X.X address does not have to be the default gateway IP address. In most cases, X.X.X.X will be an IP address in a different subnet, and interface will be the interface that is connected to, or can reach, that subnet. Add as many static routes as required.
The following is a sample route-eth0 file using the IP command arguments format. The default gateway is 192.168.0.1, interface eth0. The two static routes are for the 10.10.10.0/24 and 172.16.1.0/24 networks:
default 192.168.0.1 dev eth0 10.10.10.0/24 via 192.168.0.1 dev eth0 172.16.1.0/24 via 192.168.0.1 dev eth0
Static routes should only be configured for other subnets. The above example is not necessary, since packets going to the 10.10.10.0/24 and 172.16.1.0/24 networks will use the default gateway anyway. Below is an example of setting static routes to a different subnet, on a machine in a 192.168.0.0/24 subnet. The example machine has an eth0 interface in the 192.168.0.0/24 subnet, and an eth1 interface (10.10.10.1) in the 10.10.10.0/24 subnet:
10.10.10.0/24 via 10.10.10.1 dev eth1
Duplicate Default Gateways
If the default gateway is already assigned from DHCP, the IP command arguments format can cause one of two errors during start-up, or when bringing up an interface from the down state using the ifup command: "RTNETLINK answers: File exists" or 'Error: either "to" is a duplicate, or "X.X.X.X" is a garbage.', where X.X.X.X is the gateway, or a different IP address. These errors can also occur if you have another route to another network using the default gateway. Both of these errors are safe to ignore.
Network/Netmask Directives Format
You can also use the network/netmask directives format for route- files. The following is a template for the network/netmask format, with instructions following afterwards:
interface
ADDRESS0=X.X.X.XNETMASK0=X.X.X.XGATEWAY0=X.X.X.X
-
ADDRESS0=is the network number for the static route.X.X.X.X -
NETMASK0=is the netmask for the network number defined withX.X.X.XADDRESS0=.X.X.X.X -
GATEWAY0=is the default gateway, or an IP address that can be used to reachX.X.X.XADDRESS0=X.X.X.X
The following is a sample route-eth0 file using the network/netmask directives format. The default gateway is 192.168.0.1, interface eth0. The two static routes are for the 10.10.10.0/24 and 172.16.1.0/24 networks. However, as mentioned before, this example is not necessary as the 10.10.10.0/24 and 172.16.1.0/24 networks would use the default gateway anyway:
ADDRESS0=10.10.10.0 NETMASK0=255.255.255.0 GATEWAY0=192.168.0.1 ADDRESS1=172.16.1.0 NETMASK1=255.255.255.0 GATEWAY1=192.168.0.1
Subsequent static routes must be numbered sequentially, and must not skip any values. For example, ADDRESS0, ADDRESS1, ADDRESS2, and so on.
Below is an example of setting static routes to a different subnet, on a machine in the 192.168.0.0/24 subnet. The example machine has an eth0 interface in the 192.168.0.0/24 subnet, and an eth1 interface (10.10.10.1) in the 10.10.10.0/24 subnet:
ADDRESS0=10.10.10.0 NETMASK0=255.255.255.0 GATEWAY0=10.10.10.1
DHCP should assign these settings automatically, therefore it should not be necessary to configure static routes on Red Hat Enterprise Linux servers or clients.
Red Hat Enterprise Linux は、インターフェースをアップ/ダウンするのに使用される重要な一般的機能を含む数種のファイルを利用します。各インターフェース制御ファイルに同じ機能を強制的に含める代わりに、これらの機能は使いやすいようにグループ化して数ファイルにまとめ、必要なときに使えるようにします。
/etc/sysconfig/network-scripts/network-functions ファイルには多くのインターフェース制御スクリプトに便利で最も一般に使用される IPv4 機能が含まれています。これらの機能には、インターフェースのステータスの変化に関する情報を要求した実行中プログラムとの交信、ホスト名の設定、ゲートウェイデバイスの検索、特定デバイスのアップ/ダウンの確認、デフォルトルートの追加などがあります。
IPv6 インターフェースに必要な機能は IPv4 インターフェースのものとは異なりますので、この情報を保持するために /etc/sysconfig/network-scripts/network-functions-ipv6 ファイルが特別に存在します。このファイルにある機能が、静的 IPv6 ルートの設定と削除、トンネルの作成と削除、インターフェースへの IPv6 アドレスの追加と削除を行ない、１つのインターフェース上で IPv6 アドレスの存在を確認します。
ネットワークインターフェースに関して詳細に説明しているリソースを以下に示します。
-
/usr/share/doc/initscripts-<version>/sysconfig.txt -
この章では触れていない IPv6 オプションなど、ネットワーク設定ファイル用に利用可能なオプションへのガイドです。
-
/usr/share/doc/iproute-<version>/ip-cref.ps -
このファイルには、ルーティングテーブルの操作や他の操作に使用できる
ipコマンドについての豊富な情報が含まれています。このファイルを表示するには、 ggv アプリケーション又は、 kghostview アプリケーションを使用して下https://engineering.redhat.com/docbot/rhel/rhel-5-0-0/html/ja-JP/Deployment_Guide/s1-network-config-isdn.htmlさい。
コンピュータがほかのコンピュータと通信するには、ネットワーク接続が必要です。このためには、オペレーティングシステムにインターフェースカード (イーサネット、 ISDN モデム、トークンリングなど) を認識させ、ネットワークに接続するようにインターフェースを設定します。
ネットワーク管理ツール は、以下のような種類のネットワークインターフェースの設定に使用できます:
-
イーサネット
-
ISDN
-
モデム
-
xDSL
-
トークンリング
-
CIPE
-
ワイヤレスデバイス
また、 IPsec 接続の設定、 DNS 設定の管理、追加のホスト名と IP アドレスの組み合わせを保存するのに使う /etc/hosts ファイルの管理を行なうのにも使用できます。
ネットワーク管理ツール を使用するには、 root 権限を持っている必要があります。アプリケーションをスタートするには、 Applications (the main menu on the panel) => システム設定 = > >ネットワーク の順で進むか、シェルプロンプト (例、 XTerm または GNOME terminal) で system-config-network とコマンドを入力します。コマンドをタイプする場合、 X が実行していればグラフィカルバージョンが表示されますが、それ以外はテキストベースのバージョンが表示されます。
コマンドラインバージョンを使うには、 root として system-config-network-cmd --help コマンドを実行し、すべてのオプションを表示します。
ヒント
Red Hat Enterprise Linux でハードウェアデバイスがサポートされているかを調べるには、 Red Hat ハードウェア互換の一覧 ( http://hardware.redhat.com/hcl/) を参照してください。
ネットワーク管理ツール でネットワーク接続を設定するには、以下のステップを実行します:
-
物理ハードウェアデバイスに関連付けられたネットワークデバイスを追加します。
-
存在していない場合、ハードウェアの一覧に物理ハードウェアデバイスを追加します。
-
ホスト名と DNS を設定します。
-
DNS で検索できないホストを設定します。
本章では、ネットワーク接続のタイプごとに各手順を説明します。
イーサネット接続を確立するには、 NIC (ネットワーク インターフェースカード)、ネットワークケーブル (通常はカテゴリ 5 ケーブル)、接続先のネットワークが必要です。ネットワークの速度は異なるため、 NIC が接続先のネットワークと互換性があることを確認します。
イーサネット接続を追加するには、以下の手順に従います。
-
デバイス タブをクリックします。
-
ツールバーにある 新規 ボタンをクリックします。
-
デバイスタイプ 一覧から イーサネット接続 を選択して、 進む ボタンをクリックします。
-
ハードウェアの一覧にすでにネットワークインターフェースカードが追加されている場合は、 イーサネットカード の一覧で イーサネットカードを選択します。それ以外は、 他のイーサネットカード を選択してハードウェアデバイスを追加します。
注記
通常、インストールプログラムによって、サポートされているイーサネットデバイスが検出され、設定をするように求められます。イーサネットデバイスをインストール時に設定した場合は、 ハードウェア タブのハードウェア一覧に表示されます。
-
他のイーサネットカード を選択した場合は、 イーサネットアダプタを選択 ウィンドウが表示されます。イーサネットカードのメーカーとモデルを選択し、デバイス名を選択します。このイーサネットカードがシステムにとって 1 番目の場合なら、デバイス名に eth0 を選択し、 2 番目の場合なら eth1 を選択します (この順でくり返す)。 ネットワーク管理ツール を使用して、 NIC のリソースを設定することもできます。 進む ボタンをクリックして作業を続行します。
-
図 4.2. 「イーサネットの設定」 で示しているように、 ネットワークの設定 ウィンドウで、 DHCP か静的 IP アドレスのどちらかを選択します。ネットワークを接続するたびにデバイスに異なる IP アドレスが割り当てられる場合は、ホスト名を指定しないでください。 進む をクリックして続けます。
-
イーサネットデバイスの作成 ページで 適用 をクリックします。
イーサネットのデバイス設定が完了すると、 図 4.3. 「イーサネットデバイス」 にあるように、デバイス一覧に表示されます。
必ず、 ファイル => 保存 を選択して変更を保存してください。
イーサネットデバイスの追加後に、デバイスの一覧からデバイスを選択して 編集 をクリックすると、設定を編集することができます。たとえば、デバイスを追加したときに、デフォルトでは起動時に開始されるよう設定されます。この設定を変更するには、デバイスを選択して編集し、 コンピュータの起動時にデバイスを起動、 値を修正、変更を保存します。
デバイスが追加されたとき、 無効 ステータスで表示されるように、すぐには起動しません。デバイスを起動するには、そのデバイスをデバイス一覧から選択して 起動 ボタンをクリックします。コンピュータが開始するとき (デフォルト)、システムがデバイスを起動するよう設定されている場合は、この手順を再度行なう必要はありません。
イーサネットカードで複数のデバイスを使用する場合、 2 番目以降のデバイスは デバイスエイリアス になります。デバイスエイリアスにより、物理的にひとつのデバイスで複数の仮想デバイスを設定することができます。従って、ひとつの物理的デバイスに複数の IP アドレスを与えることができます。例えば、 eht1 デバイスと eth1:1 デバイスを設定することができます。詳細については 項4.11. 「デバイスエイリアス」 を参照してください。
ISDN 接続とは、電話会社が設置した特殊な電話回線を通して ISDN モデムカードで確立されるインターネット接続のことです。 ISDN 接続はヨーロッパで普及しています。
ISDN 接続を追加するには、次の手順を実行します。
-
デバイス タブをクリックします。
-
ツールバーにある 新規 ボタンをクリックします。
-
デバイスタイプ 一覧から ISDN 接続 を選択して 進む をクリックします。
-
プルダウンメニューから ISDN アダプタを選択します。アダプタ用のリソースと D チャンネルプロトコルを設定します。 進む ボタンをクリックして続行します。
-
使用している ISP が設定済 ISP 一覧にある場合は、それを選択します。なければ、 ISP アカウント作成の必要情報を入力します。値がわからない場合は ISP に問い合わせてください。 進む をクリックします。
-
IP 設定 ウィンドウで、 カプセル化モード (Encapsulation Mode) を選択して、自動的に IP アドレスを取得するか、1つの静的 IP アドレスを設定します。完了したら 進む をクリックします。
-
ダイアルアップ接続の設定 ページで、 適用 をクリックします。
設定が完了した ISDN デバイスは、 図 4.5. 「ISDN デバイス」 のように、 ISDN タイプのデバイスとしてデバイスの一覧に表示されます。
必ず、 ファイル => 保存 を選択して変更を保存してください。
ISDN デバイスを追加したら、デバイスの一覧からデバイスを選択して 編集 をクリックすると、設定を編集することができます。たとえば、デバイスを追加したときに、デフォルトでは起動時に実行が開始されないように設定されます。この設定を編集して変更することができます。圧縮、 PPP オプション、ログイン名、パスワードなども変更することができます。
デバイスが追加されたとき、 無効 ステータスで表示されるように、すぐには起動しません。デバイスを起動するには、そのデバイスをデバイス一覧から選択して 起動 ボタンをクリックします。コンピュータが開始するとき (デフォルト)、システムがデバイスを起動するよう設定されている場合は、この手順を再度行なう必要はありません。
モデムを使用すると、有効な電話回線によるインターネット接続を設定することができます。 ISP (インターネットサービス プロバイダ) アカウント (ダイヤルアップアカウントとも呼ばれる) が必要です。
モデム接続を追加するには、次の手順を実行します。
-
デバイス タブをクリックします。
-
ツールバーにある 新規 ボタンをクリックします。
-
デバイスタイプ 一覧から モデム接続 を選択して 進む をクリックします。
-
ハードウェア一覧 (ハードウェア タブにある) に設定済みのモデムがある場合、 ネットワーク管理ツール は、モデム接続を確立するのにそのモデムが使用されるものと見なします。モデムが設定されていない場合は、システムにあるモデムを検出しようとします。この検索には少し時間がかかります。モデムが検出されない場合は、表示した設定は検索で検出された値ではありませんというメッセージを表示して警告します。
-
検索されると、 図 4.6. 「モデムの設定」 のようなウィンドウが表示されます。
-
モデムデバイス、ボードレート、フロー制御、モデム音量を設定します。値がわからない場合は、モデムが正常に検索されたらデフォルトのままにしてください。タッチトーンダイヤル方式でない場合は、該当するチェックボックスのチェックを外してください。 進む をクリックします。
-
使用している ISP が設定済 ISP 一覧にある場合は、それを選択します。ない場合は、 ISP アカウント作成用の必要情報を入力します。値がわからない場合は、 ISP に問い合わせてください。 進む をクリックします。
-
IP 設定 ページで、 IP アドレスを自動的に取得を選択するか、静的 IP アドレスを設定します。完了したら 進む をクリックします。
-
ダイアルアップ接続の設定 ページで、 適用 をクリックします。
モデムデバイスを設定したら、 モデム タイプでデバイス一覧に、 図 4.7. 「モデムデバイス」 のように表示されます。
必ず、 ファイル => 保存 を選択して変更を保存してください。
モデムデバイスの追加後に、デバイスの一覧からデバイスを選択して 編集 をクリックすると、設定を編集することができます。たとえば、デバイスを追加したときに、デフォルトでは起動時に実行が開始されないように設定されています。この設定を編集して変更することができます。圧縮、 PPP オプション、ログイン名、パスワードなども変更することができます。
デバイスが追加されたとき、 無効 ステータスで表示されるように、すぐには起動しません。デバイスを起動するには、そのデバイスをデバイス一覧から選択して 起動 ボタンをクリックします。コンピュータが開始するとき (デフォルト)、システムがデバイスを起動するよう設定されている場合は、この手順を再度行なう必要はありません。
DSL は Digital Subscriber Lines の略語です。 ADSL 、IDSL 、 SDSL など数種の DSL タイプがあります。 ネットワーク管理ツール はすべての DSL 接続の種類を指して xDSL という言葉を使用します。
イーサネットカードを使用して DHCP から IP アドレスを取得するシステム設定が必要となる DSL プロバイダもあれば、イーサネット カードで PPPoE (Point-to-Point Protocol over Ethernet) 接続の設定が必要になる DSL プロバイダもあります。接続方式については、 DSL プロバイダに問い合わせてください。
DHCP を使用する必要がある場合、イーサネットカードの設定については、 項4.2. 「イーサネット接続の確立」 を参照してください。
PPPoE を使用する必要がある場合は、次の手順を実行します。
-
デバイス タブをクリックします。
-
新規 ボタンをクリックします。
-
デバイスタイプ 一覧から xDSL接続 を選択して、図 4.8. 「デバイスタイプの選択」 に示してあるように 進む をクリックします。
-
イーサネットカードがハードウェアの一覧に表示されている場合は、 図 4.9. 「xDSLの設定」 で示しているページからプルダウンメニューで イーサネットデバイス を選択します。 イーサネットカードが表示されていない場合は、 イーサネットアダプタの選択 ウィンドウが表示されます。
注記
通常、インストールプログラムによって、サポートされているイーサネットデバイスが検出され、設定をするように求められます。イーサネットデバイスをインストール時に設定した場合は、 ハードウェア タブのハードウェア一覧に表示されます。
-
プロバイダ名、 ログイン名、 パスワード を入力します。 T-Online アカウントを設定していない場合は、 アカウントタイプ プルダウンメニューから 通常（Normal） を 選択します。
T-Online アカウントを設定している場合、アカウントタイプ メニューから T-Online を選択して、ログイン名 と パスワード フィールドに値を入力します。DSL 接続が完全に設定された後には、 使用する T-Online アカウント設定を更に細かく設定できます。（ T-Online アカウントの設定 参照）
-
進む をクリックして、DSL 接続を作成 メニューへ行きます。設定を確認したら 適用 をクリックして 終了します。
-
DSL 接続の設定が完了すると、 図 4.10. 「xDSL デバイス」 のように DSL 接続がデバイスの一覧に表示されます。
-
xDSL 接続の追加後に、デバイスの一覧からデバイスを選択して 編集 をクリックすると、設定を編集することができます。
例えば、デバイスが追加された時には、デフォルトでは起動時のスタートをする設定が なされていません。この設定を編集して変更します。終了したら OK を クリックします。
-
xDSL 接続の設定に満足できるなら、ファイル => 保存 と進んで変更を保存します。
T-Online アカウントの設定
T-Online アカウントを設定している場合は、次の追加の手順を実行します:
-
デバイス一覧からデバイスを選択して、編集 ボタンを クリックします。
-
図 4.12. 「xDSL の設定 - プロバイダータブ」 に示してあるように、xDSL の設定 メニューから プロバイダー タブを選びます。
-
T-Online アカウントの設定 ボタンをクリックします。 そうすると、図 4.13. 「アカウントの設定」 に示してあるように T-Online アカウント用の アカウント設定 ウィンドウが開きます。
-
アダプター識別子、関連の T-Online 番号、 並行ユーザー番号/接尾辞、個人パスワード を 入力します。それが終了したら、OK をクリックして アカウント設定 を閉じます。
-
xDSL の設定 ウィンドウで、OK を クリックします。必ず ネットワーク管理ツール で ファイル=> 保存 と進んで、変更を保存してください。
デバイスが追加されたとき、 無効 ステータスで表示されるように、すぐには起動しません。デバイスを起動するには、そのデバイスをデバイス一覧から選択して 起動 ボタンをクリックします。コンピュータが開始するとき (デフォルト)、システムがデバイスを起動するよう設定されている場合は、この手順を再度行なう必要はありません。
トークンリングネットワーク とは、すべてのコンピュータが環状に接続されているネットワークのことです。 トークン または特殊なネットワークパケットが、トークンリングに沿って伝送され、コンピュータが情報をやり取りすることができます。
ヒント
Linux でトークンリングを使用する方法については、 http://www.linuxtr.net/ で Linux Token Ring Project の Web サイトを参照してください。
トークンリング接続を追加するには、次の手順を実行します。
-
デバイス タブをクリックします。
-
ツールバーにある 新規 ボタンをクリックします。
-
デバイスタイプ 一覧から トークンリング接続 を選択して、 進む ボタンをクリックします。
-
ハードウェアの一覧にすでにトークンリングカードを追加されている場合は、 トークンリングカード の一覧でトークンリングカードを選択します。トークンリングカードが追加されていない場合は、 他の トークンリングカード を選択してハードウェアデバイスに追加します。
-
他のトークンリングカード を選択した場合、 図 4.14. 「トークンリングの設定」 で示されるような トークンリングアダプタの選択 ウィンドウが表示されます。アダプタのメーカーとモデルを選択します。そしてデバイス名を選択します。このトークンリングカードがシステムにとって 1 番目のトークンリングカードなら、 tr0 を選択し、 2 番目なら tr1 を選択します (この順で進む)。 ネットワーク管理ツール を使用して、アダプタのリソースを設定することもできます。 進む をクリックして続行します。
-
ネットワークの設定 ページで、 DHCP を使用するか、静的 IP アドレスを使用するか選択します。デバイス用のホスト名も指定できます。このデバイスが ネットワークのスタートの度に動的アドレスを受け取る場合は、ホスト名を指定しないでください。 進む クリックして続けます。
-
トークンリングデバイスの作成 のページで 適用 をクリックします。
トークンリングデバイスの設定が完了すると、 図 4.15. 「トークンリングデバイス」 のようにトークンリングデバイスがデバイスの一覧に表示されます。
必ず、 ファイル => 保存 を選択して変更を保存してください。
デバイスの追加後に、デバイスの一覧からデバイスを選択して 編集 をクリックすると、設定を編集することができます。たとえば、起動時にデバイスを開始するかどうかを設定することができます。
デバイスが追加されたとき、 無効 ステータスで表示されるように、すぐには起動しません。デバイスを起動するには、そのデバイスをデバイス一覧から選択して 起動 ボタンをクリックします。コンピュータが開始するとき (デフォルト)、システムがデバイスを起動するよう設定されている場合は、この手順を再度行なう必要はありません。
ワイヤレスイーサネットデバイスは、徐々に普及してきています。ワイヤレスデバイスの設定はイーサネットの設定と似ていますが、 SSID やワイヤレスデバイス用のキーなどの設定ができる点で異なります。
ワイヤレスイーサネット接続を追加するには、次の手順を実行します。
-
デバイス タブをクリックします。
-
ツールバーにある 新規 ボタンをクリックします。
-
デバイスタイプ 一覧から ワイヤレス接続 を選択して、 進む ボタンをクリックします。
-
ハードウェアの一覧にすでにワイヤレスネットワークインターフェースカードを追加している場合は、 ワイヤレスカード の一覧でワイヤレスネットワークインターフェイスカードを選択します。追加されていない場合は、 他のワイヤレスカード を選択してハードウェアデバイスを追加します。
注記
通常、インストールプログラムによって、サポートされているワイヤレスイーサネットデバイスが検出され、設定をするように求められます。ワイヤレスイーサネットデバイスがインストール時に設定されている場合は、 ハードウェア タブのハードウェアの一覧に表示されます。
-
他のワイヤレスカード を選択した場合は、 イーサネットアダプタの選択 ウィンドウが表示されます。イーサネットカードのメーカーとモデル、デバイス名を選択します。このカードがシステムにとって 1 番目のイーサネットカードなら、デバイス名に eth0 を選択し、 2 番目なら eth1 を選択します (この順で進む)。 ネットワーク管理ツール を使用して、ワイヤレスネットワークインターフェースカードのリソースをユーザーが設定することもできます。 進む をクリックして続行します。
-
図 4.16. 「ワイヤレス設定」 にあるように、 ワイヤレス接続の設定 ページで、ワイヤレスデバイスの設定をします。
-
ネットワークの設定 ページで、 DHCP を使用するか、静的 IP アドレスを使用するか選択します。デバイス用のホスト名も指定できます。このデバイスが ネットワークのスタートの度に動的アドレスを受け取る場合は、ホスト名を指定しないでください。 進む クリックして続けます。
-
ワイヤレスデバイスの作成 ページで 適用 をクリックします。
ワイヤレスデバイスの設定が完了すると、ワイヤレスデバイスが 図 4.17. 「ワイヤレスデバイス」 に示すようにデバイスの一覧に表示されます。
必ず、 ファイル => 保存 を選択して変更を保存してください。
ワイヤレスデバイスの追加後に、デバイスの一覧からデバイスを選択して 編集 をクリックすると、設定を編集することができます。たとえば、起動時にデバイスを有効にするかどうかを設定することができます。
デバイスが追加されたとき、 無効 ステータスで表示されるように、すぐには起動しません。デバイスを起動するには、そのデバイスをデバイス一覧から選択して 起動 ボタンをクリックします。コンピュータが開始するとき (デフォルト)、システムがデバイスを起動するよう設定されている場合は、この手順を再度行なう必要はありません。
DNS タブは、システムのホスト名、ドメイン、ネームサーバー、検索ドメインを設定します。ネームサーバーはネットワーク上のほかのホストを調べるときに使用します。
DNS サーバー名が DHCP または PPPoE からリトリーブされる場合は (あるいは、 ISP からリトリーブされる場合は)、1番目、2番目、3番目 の DNS サーバーを追加しないでください。
ホスト名が DHCP または PPPoE から動的にリトリーブされる場合は (あるいは、 ISP からリトリーブされる場合)、ホスト名を変更しないでください。
注記
ネームサーバーセクションでは、システムをネームサーバーとして設定しないことに注意してください。その代わり、 IP アドレスを解決してホスト名に変換するとき、またはその逆に変換するときに使用するネームサーバーを設定します。
警告
ホスト名が変更されて、 system-config-network がローカルホスト上で開始されると、その時はもう１つの X11 アプリケーションを開始することが出来ません。その場合、再ログインして新しいデスクトップセッションを開く必要があります。
ホスト タブでは、 /etc/hosts ファイルからホストの追加、編集、削除を行うことが できます。このファイルには、 IP アドレスと対応するホスト名が含まれています。
システムが IP アドレスに対してホスト名を解決しようとするとき、または IP アドレス用のホスト名を決定するとき、システムはネームサーバーを使用する前に /etc/hosts ファイルを参照します (デフォルト設定の Red Hat Enterprise Linux を 使用している場合)。その IP アドレスが /etc/hosts ファイルにある場合、ネームサーバーは使用されません。 DNS に登録されていない IP アドレスを持ったコンピュータがネットワークにある場合、 /etc/hosts ファイルにその IP アドレスを追加することが推奨されます。
/etc/hosts ファイルにエントリを追加するには、 ホスト タブへ行き、ツールバーにある 新規 ボタンをクリックして、必要な情報を提供し OK をクリックします。 ファイル => 保存 の順で選択するか、又は Ctrl-S キーを同時に押して /etc/hosts ファイルに対する変更を保存します。ネットワークまたはネットワークサービスは、アドレスが変換される度に現在のファイルのバージョンが参照されるため、再スタートする必要はありません。
警告
localhost 項目は削除しないでください。システムにネットワーク接続がない場合、あるいは常に稼動しているネットワーク接続がある場合でも、ローカルホストループバックインターフェース経由でシステムに接続する必要のあるプログラムがある場合があります。
ヒント
検索順序を変更するには、 /etc/host.conf ファイルを編集します。 order hosts, bind の行は、 /etc/hosts がネームサーバーに優先することを指定しています。 order bind, hosts の行を変更すると、最初にネームサーバーを使用してホスト名と IP アドレスが決定されます。ネームサーバーで IP アドレスが決定できない場合は、 /etc/hosts ファイルで IP アドレスを探します。
それぞれの物理ハードウェアデバイス用に複数の論理ネットワークデバイスが作成できます。例えば、システム内にひとつだけイーサネットカードがある場合 (eth0)、別のニックネームと別の設定オプションで論理ネットワークデバイスを作成し、それをすべて eth0 に関連付けることができます。
論理ネットワークデバイスはデバイスエイリアスとは異なります。同一物理デバイスに関連する論理ネットワークデバイスは、別々のプロファイルで存在する必要があり、同時に起動することはできません。デバイスエイリアスも同じ物理ハードウェアデバイスに関連しますが、同一物理ハードウェアデバイスに属する複数のデバイスエイリアスは同時に起動することが可能です。デバイスエイリアスの作成に関する詳細は、 項4.11. 「デバイスエイリアス」 を参照してください。
プロファイル は、異なるネットワーク用に複数の設定セットを作成するのに使用されます。設定セットは論理デバイスだけでなくホストや DNS の設定も含むことができます。プロファイルを設定した後は、 ネットワーク管理ツール を使用して、複数のプロファイルを切替えることができます。
デフォルトでは、 共通 と呼ばれるプロファイルがひとつだけあります。新規のプロファイルを作成するには、プルダウンメニューから プロファイル => 新規 を選択し、そのプロファイル用に独自の名前を入力します。
メインウィンドウの下部にあるステータスバーで表示されるように、新規のプロファイルを修正しています。
すでに一覧にある既存デバイスをクリックして、 コピー ボタンをクリックして既存のデバイスを論理ネットワークデバイスにコピーします。 新規 ボタンを使用すると、正しくないネットワークエイリアスが作成されます。論理デバイスのプロパティを変更するには、そのデバイスを一覧から選択して 編集 をクリックします。例えば、簡単な判別の為に eth0_office など、ニックネームをわかりやすい名前に変更することができます。
デバイスの一覧の中に、 プロファイル とラベルの付いたチェックボックスの列があります。それぞれのプロファイル用に、デバイスに対しチェックを入れたり外したりすることができます。チェックのあるデバイスのみが現在選択中のプロファイルに含まれます。例えば、 Office と呼ばれるプロファイルに eth0_office と言う名前の論理デバイスを作成して、そのプロファイルが選択された場合にその論理デバイスを起動したい場合、 eth0 デバイスのチェックをはずし、 eth0_office デバイスにチェックを入れます。
例えば、 図 4.20. 「オフィスプロファイル」 では、 eth0_office の論理デバイスを持つ Office と呼ばれるプロファイルを示しています。 DHCP を使用して最初のイーサネットカードを起動するよう設定されています。
図 4.21. 「ホームプロファイル」 に表示してあるように、 ホーム プロファイルは eth0_home 論理デバイスを起動することに注意して下さい。これは eth0 と関連付けられています。
また、 eth0 を オフィス プロファイルでのみ起動するよう設定して、 ppp (モデム) デバイスを ホーム プロファイルでのみ起動するよう設定することもできます。もうひとつの例としては、 共通 プロファイルで eth0 を起動して、旅行中に使用するために アウェイ プロファイルで ppp デバイスを起動するよう設定することもできます。
起動時にプロファイルを起動するには、ブートローダ設定ファイルを編集して netprofile= オプションを含むようにします。例えば、システムが GRUB をブートローダとして使用して <profilename>/boot/grub/grub.conf に次が含まれている場合:
title Red Hat Enterprise Linux (2.6.9-5.EL) root (hd0,0) kernel /vmlinuz-2.6.9-5.EL ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.9-5.EL.img
次のように変更します (ここで <profilename> はブート時に起動されるべきプロファイル名です):
title Red Hat Enterprise Linux (2.6.9-5.EL) root (hd0,0) kernel /vmlinuz-2.6.9-5.EL ro root=/dev/VolGroup00/LogVol00 \ netprofile=<profilename> \ rhgb quiet initrd /initrd-2.6.9-5.EL.img
システムがブートした後にプロファイルを切り替えるには、 Applications (the main menu on the panel) =>システムツール > ネットワークデバイスのコントロール の順で進み (または、 system-control-network コマンドを入力)、プロファイルを選択して起動します。デフォルトの 共通 インターフェース以外にもプロファイルが存在する場合にのみ、プロファイルの起動セクションが ネットワークデバイスのコントロール インターフェース内に表示されます。
代わりに、次のコマンドを実行してプロファイルを有効にできます (<profilename> にプロファイル名を置き換える)。
system-config-network-cmd --profile <profilename> --activate
デバイスエイリアス は、同一の物理ハードウェアに属する仮想デバイスですが、異なる IP アドレスを持つことで同時に起動することができます。これらのデバイスは通常、コロンと数字が後ろに付くデバイス名で表示されます (例、eth0:1)。ひとつのネットワークカードしかないシステムで、複数の IP アドレスを持ちたい場合に役に立ちます。
eth0 など — イーサネットデバイスを設定した後、静的 IP アドレス (DHCP はエイリアスで動作しません) を使用するには、 — デバイス タブへ行き、 新規 をクリックします。イーサネットカードを選択してエイリアスで設定し、静的 IP アドレスをエイリアス用にセットします。 適用 をクリックして作成します。イーサネットカード用のデバイスがすでに存在するので、作成したものは eth0:1 などのエイリアスになります。
警告
イーサネットデバイスがエイリアスを持つように設定している場合は、デバイスもエイリアスも DHCP を使用するようには設定できません。 IP アドレスを手動で設定する必要があります。
図 4.22. 「ネットワークデバイスエイリアスの例」eth0 デバイス用の任意のエイリアスを例として示しています。 eth0:1 デバイスに注意してください — eth0 用の 1 番目のエイリアス。 eth0 用の 2 番目のエイリアスはデバイス名が eth0:2 になります (この順で進む)。ブート時に起動するかどうかや、エイリアス番号などデバイスエイリアスの設定を修正するには、一覧からそのデバイスエイリアスを選択して 編集 ボタンをクリックします。
エイリアスを選択して 起動 ボタンをクリックしてエイリアスを起動します。複数のプロファイルを設定している場合、どのプロファイルがどの設定に入るか選択します。
エイリアスが起動していることを確認するには、コマンド /sbin/ifconfig を使用します。その出力が異なる IP アドレスのデバイスとデバイスエイリアスを表示するはずです:
eth0 Link encap:Ethernet HWaddr 00:A0:CC:60:B7:G4 inet addr:192.168.100.5 Bcast:192.168.100.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:161930 errors:1 dropped:0 overruns:0 frame:0 TX packets:244570 errors:0 dropped:0 overruns:0 carrier:0 collisions:475 txqueuelen:100 RX bytes:55075551 (52.5 Mb) TX bytes:178108895 (169.8 Mb) Interrupt:10 Base address:0x9000 eth0:1 Link encap:Ethernet HWaddr 00:A0:CC:60:B7:G4 inet addr:192.168.100.42 Bcast:192.168.100.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:10 Base address:0x9000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:5998 errors:0 dropped:0 overruns:0 frame:0 TX packets:5998 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1627579 (1.5 Mb) TX bytes:1627579 (1.5 Mb)
ネットワーク管理ツール のコマンドラインバージョンは、システムのネットワーク設定をファイルに保存するために使用できます。 Red Hat Enterprise Linux システムにネットワーク設定を復元するのにこのファイルを使用できます。
この機能は自動化バックアップスクリプトの一部として使用することができ、アップグレードや再インストールの前に設定を保存したり、別の Red Hat Enterprise Linux システムに設定をコピーすることができます。
システムのネットワーク設定を /tmp/network-config ファイルに保存、または エクスポート するには、次のコマンドを root として実行します:
system-config-network-cmd -e > /tmp/network-config
先のコマンドから作成したファイルからネットワーク設定を復元、または インポート するには、 root として次のコマンドを実行します。
system-config-network-cmd -i -c -f /tmp/network-config
-i オプションはデータのインポートで、 -c オプションはインポートの前に既存の設定を消去するという意味です。 -f オプションは、インポートするファイルが以下の通りであることを指定します。
システムのセキュリティを維持することは極めて重要です。システムのセキュリティを管理する1つの方法として、システムのサービスに対するアクセスを注意深く管理することがあります。特定のサービスに対して公開アクセスを許可する必要があるかもしれません （たとえば、 Web サーバーを運営する場合の httpd）。しかし、サービスを提供する必要がないならば、バグの不正アクセスを受ける可能性を最小限にするためサービスをオフにすべきでしょう。
システムサービスへのアクセスを管理する手段はいくつかあります。使用する手段は、サービス、システムの設定、 Linux に関するユーザーの専門知識のレベル、などに基づいて決定してください。
サービスへのアクセスを拒否する一番簡単な方法は、サービスをオフにすることです。 xinetd で管理されるサービスと、 /etc/rc.d/init.d 階層内にあるサービス (SysV サービスとも呼ばれる) の起動/停止を設定するには、次の3つの異なるアプリケーションを使用します。
- サービス設定ツール
-
これは、グラフィカルアプリケーションです。各サービスの説明を表示、各サービスがブート時にスタートしたかどうかを表示 (ランレベル3、4、5用) 、及び各サービスを起動、停止、再起動を許可することができます。
- ntsysv
-
これは、テキストベースのアプリケーションです。ブート時に各ランレベルで起動させるサービスを設定します。このプログラムを使用して
xinetd以外のサービスの、起動、停止、または再起動はできません。 -
chkconfig -
これは、コマンドラインユーティリティです。さまざまなランレベルでサービスの起動や停止を実行できます。
xinetd以外のサービスはこのユーティリティを使用して起動、停止、または再起動をすることはできません。
これらのツールの方がほかの手段よりも使いやすくなっています。 — 他の手段とは、 /etc/rc.d の下にあるディレクトリ中の多数のシンボリックリンクを手作業で編集したり、 /etc/xinetd.d の中の xinetd 設定ファイルを編集することです。
システムサービスへのアクセスを管理する別の方法として、 iptables によって IP ファイアウォールを設定することもできます。しかし、 Linux の初心者には、 iptables が最良の策ではない場合があるということを理解しておいてください。初心者にとって iptables の設定は複雑かもしれません。その操作は経験のある Linux のシステム管理者に任せるのが最善です。
Alternatively, if you are looking for a utility to set general access rules for your home machine, and/or if you are new to Linux, try the セキュリティレベル設定ツール (system-config-securitylevel), which allows you to select the security level for your system, similar to the Firewall Configuration screen in the installation program.
サービスへのアクセスを設定する前に、 Linux ランレベルを理解する必要があります。ランレベルとは状態、あるいは モード です。これは /etc/rc.d/rc ディレクトリに一覧表示されたサービスで定義されます。 <x>.d<x> はランレベルの数字になります。
次のようなランレベルがあります。
-
0 — 停止
-
1 — シングルユーザーモード
-
2 — 未使用 （ユーザー定義可能）
-
3 — 完全マルチユーザーモード
-
4 — 未使用 （ユーザー定義可能）
-
5 — 完全マルチユーザーモード （X ベースのログイン画面）
-
6 — リブート
テキストログイン画面を使用すると、ランレベル3で実行していることになります。グラフィックログイン画面を使用すると、ランレベル5で実行していることになります。
デフォルトのランレベルを変更するには、 /etc/inittab ファイルを変更します。このファイルは、その最上部あたりに次のような1行があります。
id:5:initdefault:
この行の数字を希望するランレベルに変更します。システムをリブートするまで変更内容は反映されません。
多くの UNIX システム管理者は、 TCP ラッパーを使用して特定のネットワークサービスへのアクセスを管理する経験を持ちます。 xinetd によって管理されるすべてのネットワークサービス （そして libwrap のサポートが組み込まれているプログラム） は、 TCP ラッパーを使用してアクセスを管理することができます。 xinetd は、 /etc/hosts.allow と /etc/hosts.deny ファイルを使ってシステムサービスへのアクセスを設定することができます。ファイル名自体が表しているように、 hosts.allow には、 xinetd によって制御されるネットワークサービスへクライアントのアクセスを許可する規則一覧が含まれ、 hosts.deny にはアクセスを拒否する規則が含まれています。 hosts.allow ファイルは hosts.deny ファイルに優先します。アクセスを許可したり、拒否する決定は、各 IP アドレス （またはホスト名） か、またはクライアントのパターンに基づいて行われます。詳細については、 man ページ (man 5 hosts_access) のセクション 5 内の hosts_access を参照してください。
インターネットサービスへのアクセスを制御するには、 xinetd を使用します。 inetd の代わりになるもので、より安全です。 xinetd デーモンはシステム資源を保護し、アクセスを制御し、ログをとります。また、特殊な用途のサーバー群を起動するために使用することもできます。 xinetd を使用すれば、特定ホストへのアクセスのみを許可したり、特定ホストへのアクセスを禁止したり、特定の時間帯にのみサービスへのアクセスを許可したり、受信接続の割合や接続による負荷を制限したりすることができます。
xinetd は停止することなく動作し続け、すべてのポートで管理するサービスを監視します。管理するサービスのいずれかに対する接続要求が到着すると、 xinetd は該当するサービスに適したサーバーを起動します。
xinetd 用の設定ファイルは /etc/xinetd.conf ですが、このファイルには、いくつかのデフォルト値と /etc/xinetd.d ディレクトリをインクルードするための命令しかないことがわかるでしょう。 xinetd サービスを有効または無効にするには、 /etc/xinetd.d ディレクトリ内の設定ファイルを編集します。 disable 属性が yes に設定されている場合は、サービスは無効です。 disable 属性が no に設定されている場合は、サービスは有効です。 サービス設定ツール 、 ntsysv 、 chkconfig などを使用して、 xinetd 設定ファイルを編集したり、ステイタスを変更することができます。 xinetd によって制御されているネットワークサービスの一覧は、 ls /etc/xinetd.d コマンドを使用して、 /etc/xinetd.d ディレクトリの内容を確認してください。
サービス設定ツール は Red Hat で開発されたグラフィカルアプリケーションで、ブート時に （ランレベル3、4、5で） /etc/rc.d/init.d ディレクトリ内で起動する SysV サービスを設定したり、有効にする xinetd サービスを設定します。さらに、 SysV サービスの起動、停止、再起動や、 xinetd の再起動も可能です。
デスクトップから サービス設定ツール をスタートするには、パネル上の Applications (the main menu on the panel) => システム設定 => サーバー設定 => サービス と進むか、あるいはシェルプロンプト (例えば、 XTerm や GNOME ターミナル) で system-config-services コマンドを実行します。
サービス設定ツール は現在のランレベルや、現在編集中のランレベルを表示します。別のランレベルを編集するには、プルダウンメニューから ランレベルの編集 を選択して、ランレベル3、4、5のうちどれかを選択します。ランレベルの説明については、 項5.1. 「ランレベル」 を参照してください。
サービス設定ツール は /etc/rc.d/init.d ディレクトリからのサービスと、 xinetd で制御されるサービスを一覧表示します。アプリケーションの左側にある一覧のサービスの名前をクリックすると、そのサービスの説明と状態が表示されます。サービスが xinetd サービスでない場合、状態ウィンドウでそのサービスが現在実行中かどうか表示されます。サービスが xinetd で制御されている場合は、状態ウィンドウは xinetd service というフレーズを表示します。
サービスをすぐに起動、停止、再起動するには、一覧からサービスを選択し、ツールバーにある動作ボタンをクリックします (またはプルダウンメニューの 操作 をクリックして動作を選択します) 。サービスが xinetd サービスの場合、個別には開始、停止ができないため、動作ボタンは無効になっています。
サービス名の横にあるチェックボックスにチェックを入れたり、外したりすることで xinetd サービスを有効/無効にする場合、プルダウンメニューの ファイル => 変更を保存 (もしくは、タブの上の 保存 ボタン)を選択して、 xinetd を再起動します。そうすると変更した xinetd サービスがすぐに有効/無効になります。また、 xinetd はこのセッティングを記憶するように設定されています。一度に複数の xinetd サービスを有効/無効にすることが可能で、終了した時点で変更を保存できます。
例えば、ユーザーが rsyncをランレベル3で有効にするためにチェックを入れて、変更を保存したと想定します。 rsync サービスはすぐに有効になります。次回に xinetd がスタートする時も rsync はまだ有効のままです。
注記
xinetd サービスへの変更を保存すると、xinetd は再起動して、変更がすぐに反映されます。他のサービスへの変更を保存したときはランレベルが再設定されますが、変更はすぐには反映されません。
現在選択しているランレベルでブート時に xinetd 以外のサービスをスタートできるようにするには、一覧内のサービスの名前の横のチェックボックスにチェックを入れます。ランレベルを設定した後、プルダウンメニューの ファイル => 変更を保存 の順で選択して変更を適用します。ランレベルの設定は変わりますが、ランレベルは再起動されません。そのため、変更はすぐには反映されません。
例えば、ランレベル3の設定をしていると想定しましょう。 httpd サービスの値を「チェック付き」から「チェックなし」に変更して、それから 変更を保存 を選択すると、ランレベル3の設定はブート時に httpd をスタートしないように変更されます。しかし、ランレベル3は再初期化されていないので、 httpdはまだ作動中のままです。ここで以下のオプションの1つを選択します。
-
httpdサービスの停止 — 一覧からそのサービスを選択して 停止 ボタンをクリックすることで停止します。サービスが正しく停止されたことを伝えるメッセージが表示されます。 -
ランレベルの再初期化 — シェルプロンプトに進んで、コマンド
telinit（3はランレベルの数字） を入力し、ランレベルを再初期化します。このオプションは、複数のサービスの 起動時に開始 の値を変更して、その変更内容をただちに反映させたい場合に推奨されます。x -
何もしない —
httpdサービスを停止する必要はありません。サービスの停止には、システムが再起動するまで待ちます。次回システムが起動するとき、ランレベルはhttpdサービスが実行されずに初期化されます。
ランレベルにサービスを追加するには、プルダウンメニューの ランレベルの編集 からランレベルを選択し、 動作 => サービスの追加 を選択します。ランレベルからサービスを削除するには、プルダウンメニューの ランレベルの編集 からランレベルを選択し、左側の一覧から削除するサービスを選択して、 動作 => サービスの削除 を選択します。
ntsysv ユーティリティは、サービスを有効/無効にするための単純なインターフェイスを提供します。 ntsysv を使用すれば、 xinetd によって管理されるサービスのオン/オフを切り替えることができます。また、 ntsysv を使用して、ランレベルの設定をすることもできます。デフォルトでは現在のランレベルのみが設定されています。別のランレベルを設定するには、 --level オプションを付けて1つ又は複数のランレベルを指定します。例えば、 ntsysv --level 345 コマンドはランレベル3、4、5を設定します。
ntsysv インターフェイスは、テキストモードのインストールプログラムのような動作をします。上向き矢印や下向き矢印を使用して、一覧の中を移動します。スペースキーは、サービスの選択と選択解除を切り替えたり、また Ok ボタンや Cancel ボタンを「押す」場合にも使用します。サービスの一覧、 Ok ボタンと Cancel ボタンの間などを移動するには、 Tab キーを使用します。アスタリスク (*) はサービスが有効になっていることを示します。 F1 キーを押すと、選択しているサービスの簡単な説明が表示されます。
警告
xinetd で管理されているサービスはすぐに ntsysv > に反応します。その他のサービスは全て、すぐには反映されません。コマンド service を使用して個々のサービスを開始したり停止する必要があります。今の例では、 <daemon> stop<daemon> を停止したいサービスの名前、例えば httpd に入れ換えます。 stop の代わりに、 start や restart を指定すると起動や再起動をすることができます。
また、 chkconfig コマンドもサービスを有効/無効にするために使用することができます。 chkconfig --list コマンドは、システムサービスの一覧、各サービスがどのランレベル（0-6）で起動 （on） または停止 （off）したかが表示されます。一覧の末尾には、 xinetd によって管理されるサービス用のセクションがあります。
chkconfig --list コマンドを使用して、 xinetd が管理するサービス1つを照会すると、 xinetd サービスが起動している （on） か、停止している （off） かを表示します。たとえば、 chkconfig --list finger コマンドは以下の出力を表示してきます。
rsync on
上記で表示してあるように、 rsync は xinetd サービスとして有効です。 xinetd が稼動していれば、 rsync は有効です。
chkconfig --list を使用して /etc/rc.d のサービス1つを照会する場合は、ランレベルごとのサービス設定が表示されます。例えば、 chkconfig --list httpd コマンドは以下の出力を表示します。
httpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
chkconfig は、あるサービスを特定のランレベルで起動する (あるいは起動しない)ように設定するのにも使用されます。例えば、ランレベル3、4、5で nscd を停止するには、以下のコマンドを使用します。
chkconfig --level 345 nscd off
警告
xinetd で管理されているサービスは、すぐに chkconfig に反応します。たとえば、 xinetd が実行中で、 rsync が無効の場合に chkconfig rsync on を実行すると、手動で xinetd を再起動しなくても rsync はすぐに有効になります。 chkconfig を使用しても、ほかのサービスへの変更がすぐに反映されるわけではありません。 service 形式のコマンドを使って、各サービスの停止や起動を行う必要があります。今の例では、 <daemon> stop<daemon> に停止するサービスの名前 （たとえばhttpd） を指定します。 stop の代わりに、 start や restart を指定すると、サービスを起動または再起動することができます。
詳しい情報は以下のリソースで参照してください。
-
ntsysv、chkconfig、xinetd、及びxinetd.conf用の man ページ。 -
man 5 hosts_access— （man ページのセクション5の） ホストアクセス制御ファイルの書式に関する man ページ。
-
http://www.xinetd.org —
xinetdの Web ページ。詳細な機能一覧や設定ファイルのサンプルがあります。
インターネットなど、殆どの最近のネットワーク上で、ユーザーは他のコンピュータを名前で探します。これによりユーザーは、ネットワークリソースのネットワークアドレス番号を記憶する煩わしさから免れます。このような名前ベースの接続を許可するネットワークを効率的に設定するには、 DNS (Domain Name Service) あるいは、 ネームサーバーを設定します。これによりネットワーク上のホスト名を数値アドレスに、又はその逆方向に解決ます。
この章では Red Hat Enterprise Linux に収納されているネームサーバーと BIND (Berkeley Internet Name Domain) DNS サーバーについて、その設定ファイルの構造に焦点を置きながら、ローカル及びリモートで管理する方法を説明します。
注記
BIND は、Red Hat Enterprise Linux で、 named サービスとしても知られています。これは、 サービス設定ツール (system-config-service) を通じて 管理することができます。
DNS はホスト名をその対応する IP アドレスに関連付けて、ユーザーがネットワーク上の他のマシンに接続したい場合に、 IP アドレスを記憶せずにその名前で接続できるようにします。
DNS と FQDN を使用すると、システム管理者はマシンに対する名前ベースのクエリに影響することなくホストの IPアドレスを変換する柔軟性を持てる利点があります。また逆に、管理者は名前ベースのクエリを処理するマシンを入れ換えることが出来ます。
DNS は、通常幾つかのドメインに対し権限を所有し、他のドメイン用の DNS サーバーを参照する中央設置のサーバーを使用して実装されます。
クライアントホストがネームサーバーからの情報を要求すると、通常それはポート 53 に接続されます。それからネームサーバーはリゾルバライブラリをベースにして FQDN を解決しようとします。このリゾルバライブラリには、要求されたホストに関して又は 以前のクエリのキャッシュデータの権限情報を収納している可能性があります。もし、ネームサーバーがリゾルバライブラリに解答を持っていない場合は、 ルートネームサーバー と呼ばれる他のネームサーバーにクエリをして、課題となっている FQDN 用の権限を持つネームサーバーを判定します。その後、その情報を使用してその権限ネームサーバーにクエリし、要求のあったホストの IPアドレスを決定します。逆引きのクエリをしている場合、名前ではなく不明な IPアドレスでクエリされること以外は同じ手順が使用されます。
インターネット上では、ホストの FQDN は異なるセクションに分割することが出来ます。これらのセクションはツリーのように階層として構成され、その内容は主幹、1次分岐、2次分岐、などとなります。次のような FQDN を考えてみましょう。
bob.sales.example.com
特定のシステムに関連している IP アドレスを取得する為に FQDN を解決する方法を考える場合、名前は右から左へ読む必要があります。それぞれの階級はピリオド (.) で区切られています。この例では、 com がこの FQDN 用の トップレベルドメイン を示します。 example と言う名前は、 com の下のサブドメインで、 sales はまた example の下のサブドメインです。最も左側の名前 bob はそのマシンのホスト名を識別します。
ホスト名を除く、それぞれのセクションは ゾーン と呼ばれ、特定の ネーム空間 (namespace) を定義します。ネーム空間はそのサブドメインの左側の名前を制御します。この例では2つしかサブドメインを含んでいませんが、 FQDN は最低限の1つのサブドメインが設定されている限り、ネーム空間の構成に応じてそれ以上含むことが出来ます。
ゾーンは、 ゾーンファイル (ゾーンのネーム空間を説明) や、その特定のドメイン、又はサブドメインで使用するメールサーバー、その他の使用を通じて権限のあるネームサーバー上で定義されます。ゾーンファイルは、本来の権限が所在しファイルが変更される場所である プライマリネームサーバー (別名：マスターネームサーバー)と、そのプライマリネームサーバーからそれらのゾーンファイルを受け取る セカンダリネームサーバー (別名：スレーブネームサーバー) に保存されます。どのネームサーバーでも同時に異なるゾーン用のプライマリとセカンダリネームサーバーになることが可能で、それらもまた、複数ゾーン用の権限として考慮できます。それはネームサーバーの構成の仕方により決定されるものです。
プライマリネームサーバー設定には 4 つのタイプがあります:
- master(マスター)
-
あるネーム空間に対するオリジナルで権限あるゾーンレコードを保存し、他のネームサーバーからのネーム空間に関するクエリに答えます。
- slave(スレーブ)
-
このサーバーが権限を持つと考えられているネーム空間に関して、他のネームサーバーからのクエリに回答します。しかし、スレーブネームサーバーは、ネーム空間情報をマスターネームサーバーから入手します。
- caching-only(キャッシュのみ)
-
名前から IP への解決を行うサービスを提供しますが、どのゾーンにも権限を持っていません。すべての解決に対して回答は一定期間メモリ内のデータベースにキャッシュされます。キャッシュ期間は検索されたゾーンレコードによって指定されます。
- forwarding(転送)
-
名前解決を行うべきネームサーバーの特定の一覧に要求を転送します。指定されたネームサーバーの、どのネームサーバーも解決することができない場合、解決は失敗します。
ネームサーバーは、上記のタイプのうち1つのタイプであるか、複数のタイプであることが可能です。たとえば、あるネームサーバーはあるゾーンではマスターであり、他のゾーンではスレーブであってもかまいませんし、解決転送だけを提供するものであってもかまいません。
BIND は /usr/sbin/named デーモンを通して名前解決サービスを実行します。 BIND はまた、 /usr/sbin/rndc と言う管理ユーティリティも含んでいます。 rndc に関する詳細は、 項6.4. 「rndc の使用法」 でご覧ください。
BIND は、以下の場所にその設定ファイルを格納しています。
-
/etc/named.conf -
namedデーモンの設定ファイル -
/var/named/ディレクトリ -
namedの作業ディレクトリで、ゾーン、静的、キャッシュのファイルをそれぞれ格納します。
注記
bind-chroot パッケージをインストールしている場合、 BIND サービスは、 /var/named/chroot 環境内で動作します。全ての設定ファイルはそこへ移動されます。その状態で、 named.conf は /var/named/chroot/etc/named.conf に置かれることになります。
ヒント
caching-nameserver パッケージをインストールしている場合、デフォルトの設定ファイルは /etc/named.caching-nameserver.conf です。このデフォルト設定を変えるには、 /etc/named.conf 内に自己のカスタム設定ファイルを作成します。再起動の後では BIND は、デフォルト設定ファイルではなく、 /etc/named.conf のカスタムファイルを使用します。
以下の数ヶ所のセクションで、 BIND 設定ファイルを詳細に説明します。
named.conf ファイルは、左右の大括弧 { } で囲まれた組み込みオプションを使用した一連のステートメントです。多くの小さなエラーが named サービスの開始を阻止しますので、管理者は named.conf を編集する時に構文上のエラーを避けるように注意する必要があります。
標準的な named.conf は、次の例の様に構成されています：
<statement-1> ["<statement-1-name>"] [<statement-1-class>] { <option-1>; <option-2>; <option-N>; }; <statement-2> ["<statement-2-name>"] [<statement-2-class>] { <option-1>; <option-2>; <option-N>; }; <statement-N> ["<statement-N-name>"] [<statement-N-class>] { <option-1>; <option-2>; <option-N>; };
以下のタイプのステートメントが一般的に /etc/named.conf で使用できます：
acl ステートメント (access control statement) はネームサーバーへ許可又は拒否されるホストのグループを定義します。
acl ステートメントは次の形をとります：
acl <acl-name> { <match-element>; [<match-element>; ...] };
このステートメント内では、 <acl-name> をアクセス制御リストの名前で入れ換え、 <match-element> をセミコロンで隔離された IP アドレスで入れ換えます。殆どの場合、個々の IP アドレス、又は IP ネットワーク表記 (10.0.1.0/24など) を使用して acl ステートメント内の IP アドレスを識別します。
次のアクセス制御リストは、設定を簡素がする為にキーワードとして既に定義されています：
-
any— すべての IP アドレスと一致。 -
localhost— ローカルシステムによって使用されている IP アドレスと一致。 -
localnets— ローカルシステムが接続しているネットワークの IP アドレスと一致。 -
none— どの IP アドレスとも一致しない。
他のステートメント (options ステートメントなど) と一緒に使用した場合、 acl ステートメントは BIND ネームサーバーの誤用を防止するのに役に立ちます。
次の例は、2つのアクセス制御リストを定義し、 options ステートメントを使用してネームサーバーによるそれらの取扱方法を指定しています：
acl black-hats {
10.0.2.0/24; 192.168.0.0/24; };
acl red-hats { 10.0.1.0/24; };
options {
blackhole { black-hats; };
allow-query { red-hats; };
allow-recursion { red-hats; };
}
上記の例は、 black-hats と red-hats の2つのアクセス制御リストを示していますが、 black-hats リスト内のホストは、ネームサーバーへのアクセスを拒否されて、 red-hats リスト内のホストは通常のアクセスが許可されています。
include ステートメントはファイルを named.conf ファイルにインクルードできるようにします。この方法で壊れやすい設定データ (keysなど) は限定権限を付けて個別のファイルに保管することが可能です。
include ステートメントは次のような形を取ります：
include "<file-name>"
このステートメントでは、 <file-name> はファイルへの絶対パスで入れ換えます。
options ステートメントはグローバルサーバーの設定オプションを定義して他のステートメントのデフォルトをセットします。これは named の作業ディレクトリの場所、許可できるクエリのタイプ、その他を指定するのに使用されます。
options ステートメントは以下の形をとります：
options { <option>; [<option>; ...] };
このステートメントでは、 <option> ディレクティブは有効なオプションで入れ換えます。
次のようなオプションが一般的に使用されます：
-
allow-query -
どのホストにこのネームサーバーへのクエリを許可するかを指定します。デフォルトでは、すべてのホストのクエリが許可されます。ここでアクセス制御リストや一連の IP アドレス又はネットワークを使用して、特定のホストだけにネームサーバーへのクエリを許可することができます。
-
allow-recursion -
allow-queryと似ていますが、これは繰り返しクエリに適用されます。デフォルトでは、すべてのホストにネームサーバーへの繰り返しクエリを行うことが許可されます。 -
blackhole -
どのホストがサーバーへのクエリを許可されないかを指定します。
-
directory -
デフォルトの
/var/namedと異なる場合、namedの作業ディレクトリを指定します。 -
forwarders -
解決を求めて要求が転送されるネームサーバーの有効な IP アドレスの一覧を指定します。
-
forward -
forwardersディレクティブの転送動作を指定します。以下のようなオプションが許可されます：
-
first—namedがその名前を自分で解決しようとする前に、forwardersディレクティブに記されているネームサーバーにクエリが実行されるよう指定します。 -
only—forwardersディレクティブに指定されているネームサーバーへのクエリが失敗した場合、namedが自分で名前解決しないように指定します。
-
-
listen-on -
namedがクエリの監視をする場所であるネットワークインターフェイスを指定します。デフォルトではすべてのインターフェイスが使用されます。このディレクティブを DNS 上で使用すると DNS サーバーはゲートウェイとしても機能し、 BIND は、そのネットワークの1つから届くクエリのみに回答するように設定できます。
以下に
listen-onディレクティブの例を示します：options { listen-on { 10.0.1.1; }; };この例では、プライベートネットワーク用ネットワークインターフェイスから到着した要求 (
10.0.1.1) だけが受け付けられます。 -
notify -
ゾーンが更新された時に
namedからスレーブサーバーに通知を出します。次のようなオプションが受け付けられます：-
yes— スレーブサーバーに通知します。 -
no— スレーブサーバーに通知しません。 -
explicit— ゾーンステートメント内にあるalso-notifyリストに指定してあるスレーブサーバーにのみ通知します。
-
-
pid-file -
namedによって作成されたプロセス ID ファイルの場所を指定します。 -
root-delegation-only -
TLD (top-level domains) と、オプションの排除リストをもつ root ゾーン内での代行プロパティの強制執行を始動します。 代行 (Delegation) とは、単独ゾーンを複数のサブゾーンに分離するプロセスのことです。代行ゾーンを作成するには、 NS records(NameServer records) として知られる項目が使用されます。ネームサーバー記録 (NameServer records) (代行記録) は特定のゾーン用に権限的ネームサーバーを指名します。
以下の
root-delegation-onlyの例は、代行のない対応が予期され、信用される送信元としての TLD の排除リストを指定します:options { root-delegation-only exclude { "ad"; "ar"; "biz"; "cr"; "cu"; "de"; "dm"; "id"; "lu"; "lv"; "md"; "ms"; "museum"; "name"; "no"; "pa"; "pf"; "se"; "sr"; "to"; "tw"; "us"; "uy"; }; }; -
statistics-file -
統計ファイル用に別の場所を指定します。デフォルトでは、
named統計は、/var/named/named.statsファイルに保存されています。
他にも数種類のオプションが利用できます。その多くは正常に機能するためにそれぞれ他のオプションに依存します。詳細に関しては、 項6.7.1. 「インストールされているドキュメント」 内の BIND 9 管理者リファレンスマニュアル 、及び bind.conf の man ページを参照してください。
zone ステートメントはその設定ファイルの場所やゾーン独自のオプションなど、ゾーンの特性を指定します。このステートメントは、グローバル options ステートメントを上書きするのに使用できます。
zone ステートメントは以下のような形をとります：
zone <zone-name><zone-class> { <zone-options>; [<zone-options>; ...] };
このステートメントでは、 <zone-name> がゾーンの名前であり、 <zone-class> がゾーンのオプションクラスで、 <zone-options> がゾーンの特徴となるオプションの一覧です。
<zone-name> の属性はゾーンステートメントにとって重要です。 /var/named/ ディレクトリに位置している対応のゾーンファイルで使用される $ORIGIN ディレクティブに、割り当てられるデフォルト値なのです。 named デーモンはゾーンファイル内にリストしてあるいずれかの非完全修飾ドメイン名にゾーンの名前を付け加えます。
注記
caching-nameserver パッケージをインストールしている場合、デフォルトの設定ファイルは /etc/named.rfc1912.zones の中になります。
例えば、 zone ステートメントが example.com 用にネーム空間を定義する場合、 example.com を <zone-name> として使用すると、それは example.com ゾーンファイルの中でホスト名の末尾に配置されます。
ゾーンファイルに関する詳細は 項6.3. 「ゾーンファイル」 で御覧下さい。
最も一般的な zone ステートメントオプションには次のようなものがあります：
-
allow-query -
このゾーンについての情報を要求することのできるクライアントを指定します。デフォルトでは、すべてのクエリ要求を許可します。
-
allow-transfer -
ゾーン情報の転送を要求することが許可されたスレーブサーバーを指定します。デフォルトでは、すべての転送要求を許可します。
-
allow-update -
ゾーン内の情報を動的に更新することのできるホストを指定します。デフォルトでは、すべての動的更新要求を拒否します。
ホストがそのゾーン情報を更新するのを許可する場合には十分注意が必要です。指定されたホストが完全に信頼されていない場合には、このオプションを有効にしないでください。一般的に、管理者に手動でゾーンのレコードを更新してもらい、
namedサービスをリロードしてもらうのが良いでしょう。 -
file -
ゾーンの設定データが記載された
named作業ディレクトリの中のファイル名を指定します。 -
masters -
権限のあるゾーン情報の要求先の IP アドレスを指定します。ゾーンが
typeslaveとして定義されている場合にのみ使用します。 -
notify -
ゾーンが更新された時に
namedがスレーブサーバーに通知するかどうかを指定します。このディレクティブは、次のようなオプションを受け付けます:-
yes— スレーブサーバーに通知します。 -
no— スレーブサーバーに通知しません。 -
explicit— ゾーンステートメント内にあるalso-notifyリストに指定してあるスレーブサーバーにのみ通知します。
-
-
タイプ -
ゾーンタイプを定義
以下に有効なオプションを示します：
-
delegation-only— COM, NET, 又は ORG などのインフラストラクチャゾーンの代行ステータスを強制執行します。明示された、あるいは暗示された代行はNXDOMAINとして扱われます。このオプションは再帰的、又はキャッシュ化実装で使用される TLD や root ゾーンでのみ適用できます。 -
forward— 他のネームサーバーにこのゾーンの情報を求めるすべての要求を転送します。 -
hint— ルートネームサーバーをポイントするのに使用される特別なタイプのゾーンです。ルートネームサーバーは、他の方法ではあるゾーンのことがわからない場合に、クエリを解決します。hintゾーンでは、デフォルトを越えた設定は必要ありません。 -
master— このゾーン用の権限としてのネームサーバーを示します。システムにそのゾーンの設定ファイルがある場合、そのゾーンはmasterとして設定しなくてはなりません。 -
slave— このネームサーバーをこのゾーンのスレーブサーバーと指名します。さらに、このゾーン用にマスターネームサーバーの IP アドレスを指定します。
-
-
ゾーン統計値 -
namedにこのゾーンについての統計を保持するよう設定し、デフォルトの場所 （/var/named/named.stats） か、serverステートメントのstatistics-fileオプションに記されているファイルのいずれかにこれを書きこみます。serverのステートメントに関する詳細は 項6.2.2. 「他のステートメントタイプ」 で御覧下さい。
マスターネームサーバーやスレーブネームサーバーの /etc/named.conf ファイルに対する変更は、 zone ステートメントの追加、変更、削除などに関わるものです。これらの zone ステートメントには、数多くのオプションを含めることができまが、ほとんどのネームサーバーは、そのうちのほんのわずかしか利用しません。以下の zone ステートメントは、マスター/スレーブネームサーバー関係で利用することのできる非常に基本的な例です。
以下に example.com をホストするプライマリネームサーバー (192.168.0.1) 用の zone ステートメントの1例を示します：
zone "example.com" IN { type master; file "example.com.zone"; allow-update { none; }; };
ステートメントでは、ゾーンは example.com として識別され、タイプは master に設定され、 named サービスは /var/named/example.com.zone ファイルを読み込むように指示されます。また、 named は他のホストの更新を許可しないように指示しています。
example.com 用のスレーブサーバーの zone ステートメントは前の例とは若干異なります。スレーブサーバー用には、タイプが slave にセットされ、 allow-update 行の場所には、 named に対してマスターサーバーの IP アドレスを伝えるディレクティブがあります。
以下に example.com の zone ステートメントの例を示します。
zone "example.com" { type slave; file "example.com.zone"; masters { 192.168.0.1; }; };
この zone ステートメントは、スレーブサーバー上の named を設定して、 example.com ゾーンに関する情報を得るために 192.168.0.1 の IP アドレスでマスターサーバーにクエリします。スレーブサーバーがマスターサーバーから取得する情報は /var/named/example.com.zone ファイルに保存されます。
以下に、 named.conf の中で利用でき、使用頻度に低いステートメントタイプの一覧を示します。
-
制御 -
namedサービス管理用のrndcコマンドを使用するのに必要な各種のセキュリティ要求を設定します。controlsステートメントがどのように構成されているか、及び利用できるオプションは、 項6.4.1. 「/etc/named.confの設定」 を参照して下さい。 -
key "<key-name>" -
名前によって特定の鍵を定義します。鍵は安全な更新や
rndcコマンドの使用などのさまざまな行動の認証に使用されるものです。keyでは以下の2つのオプションが使用されます：-
algorithm—<algorithm-name>dsa又はhmac-md5など、使用されるアルゴリズムのタイプ。 -
secret "— 暗号化した鍵。<key-value>"
keyステートメントの書き方については 項6.4.2. 「/etc/rndc.confの設定」 を参照してください。 -
-
ロギング -
channel と呼ばれる複数タイプのログの使用を許可します。
loggingステートメント内でchannelオプションを使用することにより、カスタム化したタイプのログ： — 自己のファイル名 (file) 、サイズ制限 (size) 、バージョン指定 (version) 、及び重要度のレベル (severity) などを持つログを構成することができます。1度カスタムチャンネルが定義されると、categoryオプションを使用してチャンネルを分類化でき、namedが再起動した時にログが始まります。ディフォルトでは、
namedは、syslogデーモンへ標準のメッセージをログします。そしてそれを/var/log/messagesに配置します。これが起こるのは、幾つかの標準チャンネルが数種の重要度レベルで BIND に組み込まれており、情報ログのメッセージ (default_syslog) を処理するものや、特にデバッグのメッセージ (default_debug) を処理するものなどがあるからです。defaultと呼ばれるデフォルトのカテゴリーは、特殊な設定なしに通常のログを取るような組み込みチャンネルを使用します。ログプロセスのカスタマイズは、かなり細かなプロセスでこの章の説明範囲から越えてしまうものです。カスタムの BIND ログの作成法に関する詳細は、 項6.7.1. 「インストールされているドキュメント」 の中の BIND 9 管理者リファレンスマニュアル を御覧下さい。
-
server -
特に通知とゾーン転送に関して、
namedがリモートネームサーバーに対してどう対処すべきかを左右するオプションを指定します。transfer-formatオプションは、1つのリソースレコードがそれぞれのメッセージ (one-answer) と共に送信されるか、又は複数のリソースレコードがそれぞれのメッセージ (many-answers) と一緒に送信されるかを制御します。many-answersはより効率的ですが最新の BIND ネームサーバーだけがそれを理解します。 -
trusted-keys -
この中にはセキュア DNS (DNSSEC) で使用される各種の公共鍵が含まれています。 BIND セキュリティに関する詳細は 項6.5.3. 「セキュリティ」 で御覧下さい。
-
view "<view-name>" -
どのネットワークでネームサーバーに問い合わせをしているホストがオンになっているかに応じて特別なビューを作成します。これにより、幾つかのホストはあるゾーンに関して1つの回答を受けることができ、その他のホストは全く別の情報を受け取るようにできます。別の方法として、特定のゾーンだけが特定の信頼できるホストに対し利用可能となり、信用できないホストは単に他のゾーンに関するクエリをするだけということも出来ます。
名前が独自であれば、複数のビューも使用できます。
match-clientsオプションは、特定のビューに適用する IP アドレスを指定します。どのようなoptionsステートメントでもビューの中で使用でき、既にnamed用に設定してあるグローバルオプションを上書き出来ます。殆どのviewステートメントはmatch-clientsリストに適用できる複数のzoneステートメントを含んでいます。特定クライアントの IP アドレスに適合する最初のviewステートメントが採用される為、viewステートメントがリストされる順序は重要です。viewステートメントに関する詳細は 項6.5.2. 「複数ビュー」 で御覧下さい。
ゾーンファイル には、ネーム空間についての情報が記載されており、デフォルトでは named の作業ディレクトリ (/var/named/) に保存されます。各ゾーンファイル名は zone ステートメントの file オプションデータに従い、通常 example.com.zone などのように、該当するドメインに関係した、ゾーンデータが記載されているファイルとして識別できるような名前が付けられます。
注記
bind-chroot パッケージをインストールしている場合は、 BIND サービスは /var/named/chroot 環境内で動作します。全ての設定ファイルはそこに移動されます。その状態で、ゾーンファイルは /var/named/chroot/var/named 内で見つけることができます。
各ゾーンファイルには、 ディレクティブ と リソースレコード が含まれている場合があります。 ディレクティブ は、ネームサーバーに対して、タスクを実行したり、ゾーンに特別の設定を適用したりするよう命令します。リソースレコードは、ゾーンのパラメータを定義し、個々のホストに識別を割り当てるものです。ディレクティブはオプションですが、リソースレコードはネームサービスをゾーンに提供するため必要です。
すべてのディレクティブとリソースレコードは、個々の行に記載する必要があります。
コメントは、ゾーンファイル内のセミコロン （;） の後に置かれます。
ディレクティブは、ドルサイン文字 ($) で始まり、その後にディレクティブの名前が続きます。通常はゾーンファイルの先頭に置かれます。
以下のディレクティブが最も一般的に使用されます：
-
$INCLUDE -
ディレクティブが使用されている場所で、このゾーンファイル内に別のゾーンファイルをインクルードするよう
namedを設定します。このディレクティブにより、おもなゾーンファイル以外にも追加ゾーン設定を保存することができます。 -
$ORIGIN -
ホスト名だけのレコードなど、修飾指定のないレコードにドメイン名を設定します。
たとえば、ゾーンファイルには以下のような行を含むことができます:
$ORIGIN example.com.後付きのピリオド (
.) のないリソースレコードに使用されている名前はどれも、その後にexample.comが付加されます。注記
ゾーンが
/etc/named.conf内に指定されている場合は、$ORIGINディレクティブを使用する必要はありません。ゾーンの名前はデフォルトで$ORIGINディレクティブ値として使用されます。 -
$TTL -
デフォルトの Time to Live（TTL） 値をゾーン用に設定します。これは、ゾーンのリソースレコードが有効である時間を秒単位で与えられる数です。各リソースレコードはそれぞれ自己の TTL 値を含むことが可能で、それがこのディレクティブを上書きします。
この値を増加させると、リモートネームサーバーは、このゾーンの情報をより長時間キャッシュします。こうすると、このゾーンについて行われるクエリの数は減りますが、リソースレコード変更を伝えるのに要する時間は長くなります。
ゾーンファイルの主要コンポーネントはそのリソースレコードです。
ゾーンファイルリソースレコードには、多種のタイプがあります。最もよく使用されるタイプを以下に示します：
-
A -
アドレスレコードを示します。名前に割り当てる IP アドレスを次の例のように指定します:
<host>IN A<IP-address>この
<host>値が省略された場合、Aレコードはネーム空間の一番上にデフォルト IP アドレスをポイントします。このシステムは、すべての非 FQDN 要求の対象となります。example.comゾーンファイルについて、以下のAレコード例を考えてみましょう：server1 IN A 10.0.1.3 IN A 10.0.1.5example.comへのリクエストは 10.0.1.3 又は 10.0.1.5 にポイントされています。 -
CNAME -
Canonical Name レコードを示します。1つのネームを別のネームにマップします。このタイプのレコードは エイリアス(別名)レコード として知られています。
次の例では、
namedに対して、<alias-name>に送信された要求はすべてホスト、<real-name>をポイントすることを知らせます。CNAMEレコードは、最も一般的に Web サーバーのwwwなどの共通名スキームを使用するサービスをポイントするのに使用されます。<alias-name>IN CNAME<real-name>次の例で、1つの
Aレコードがあるホスト名をある IP アドレスにバインドし、CNAMEレコードが一般的に使用されるwwwホスト名をそれにポイントしています。server1 IN A 10.0.1.5 www IN CNAME server1 -
MX -
Mail eXchangeレコードを示します。このゾーンによって制御される特定のネーム空間に送られたメールがどこへ行くのかを知らせます。
IN MX<preference-value><email-server-name>ここでは、
<preference-value>により、このネーム空間の E メールサーバーを数値的にランク付けすることが出来るため、幾つかの E メールシステムに、他の E メールシステムよりも優先させることが出来ます。最低の<preference-value>を持つMXリソースレコードは、他のものよりも優先されますが、複数の E メールサーバーが同じ値を所持して、 E メールのトラフィックを平等に分散させることができます。<email-server-name>はホスト名か、 FQDN とすることが出来ます。IN MX 10 mail.example.com. IN MX 20 mail2.example.com.この例では、最初の
mail.example.comE メールサーバーはexample.comドメイン宛の E メールを受信する場合に、mail2.example.comE メールサーバーよりも優先されています。 -
NS -
NameServer レコードを示します。ある特定のゾーンに対して権限のあるネームサーバーを表明します。
以下に
NSレコードのレイアウトを示します：IN NS<nameserver-name>ここでは、
<nameserver-name>は FQDN でなければなりません。次に、2つのネームサーバーがあるドメインについて権限を持っていることが示されます。これらのネームサーバーがどちらもスレーブであるか、それとも1つはマスターであるかは重要ではありません。これらは両方とも権限があると考えられます。
IN NS dns1.example.com. IN NS dns2.example.com. -
PTR -
PoinTeR レコードを示します。ネーム空間の別の部分を指すよう設計されています。
PTRレコードは、 IP アドレスから逆に特定の名前を指すため、主に逆引き名前解決に使用されます。使用中のPTRレコードの例については 項6.3.4. 「逆引き名前解決ゾーンファイル」 を参照してください。 -
SOA -
これは Start Of Authority リソースレコードを参照します。ネーム空間についての重要な権限ある情報をネームサーバーに明示します。
SOAレコードは、ディレクティブの後に置かれ、ゾーンファイル内の最初のリソースレコードとなります。以下の例は
SOAリソースレコードの基本的構成を示しています:@ IN SOA<primary-name-server><hostmaster-email>(<serial-number><time-to-refresh><time-to-retry><time-to-expire><minimum-TTL> )@記号は、このSOAリソースレコードによって定義されているネーム空間として$ORIGINディレクティブ （$ORIGINディレクティブが設定されていない場合にはゾーンの名前） を置きます。このドメインの権限であるプライマリネームサーバーのホスト名は<primary-name-server>ディレクティブであり、このネーム空間に関して連絡する人の E メールは<hostmaster-email>ディレクティブです。<serial-number>ディレクティブは、namedがゾーンをリロードするべきであることを知らせるためにゾーンファイルが変更されるたび数が増えていく数値です。<time-to-refresh>ディレクティブは、ゾーンに変更が行われた場合に、マスターネームサーバーに問い合わせるまでの待機時間を決定するためにスレーブサーバーが使用する数値です。<serial-number>ディレクティブは、スレーブが古いゾーンデータを使用しているかどうか、それに従いリフレッシュすべきなのかどうかを判断するためにスレーブサーバーによって使用される数値です。<time-to-retry>ディレクティブは、マスターネームサーバーが応答していない場合に、リフレッシュ要求を発行するまでの待機間隔をスレーブサーバーが決定するのに使用する数値です。マスターが、<time-to-expire>ディレクティブで指定された時間内にリフレッシュ要求に応答しなかった場合、スレーブサーバーはそのネーム空間についての要求の権限を持つものとして応答を停止します。<minimum-TTL>ディレクティブは、他のネームサーバーがゾーンの情報をキャッシュする時間数です。BIND を設定する際は、時間はすべて秒数で指定します。しかし、分（
M）、時間（H）、日（D）、週（W）など秒以外の時間単位を指定するときに短縮形を使用することもできます。 表 6.1. 「他の時間単位と比較した秒数」 の表は、秒数での時間数と他の形式による相当時間を示します。秒 他の時間単位 601M180030M36001H108003H216006H4320012H864001D2592003D6048001W31536000365D表 6.1. 他の時間単位と比較した秒数
以下の例は、
SOAリソースレコードが実際の値で設定されると、どのように表示されるかを示したものです。@ IN SOA dns1.example.com. hostmaster.example.com. ( 2001062501 ; serial 21600 ; refresh after 6 hours 3600 ; retry after 1 hour 604800 ; expire after 1 week 86400 ) ; minimum TTL of 1 day
個別に見た場合、ディレクティブとリソースレコードは把握するのが困難です。しかし、共通ファイルとして一緒に置くと理解しやすくなります。
以下に非常に基本的なゾーンファイルの例を示します。
$ORIGIN example.com. $TTL 86400 @ IN SOA dns1.example.com. hostmaster.example.com. ( 2001062501 ; serial 21600 ; refresh after 6 hours 3600 ; retry after 1 hour 604800 ; expire after 1 week 86400 ) ; minimum TTL of 1 day IN NS dns1.example.com. IN NS dns2.example.com. IN MX 10 mail.example.com. IN MX 20 mail2.example.com. dns1 IN A 10.0.1.1 dns2 IN A 10.0.1.2 server1 IN A 10.0.1.5 server2 IN A 10.0.1.6 ftp IN A 10.0.1.3 IN A 10.0.1.4 mail IN CNAME server1 mail2 IN CNAME server2 www IN CNAME server1
この例では、標準ディレクティブと SOA 値が使われています。権限のあるネームサーバーは、 dns1.example.com と dns2.example.com に設定され、これらをそれぞれ 10.0.1.1 と 10.0.1.2 に結び付ける A レコードがあります。
MX レコードで設定される E メールサーバーは、 CNAME レコードを介して server1 と server2 をポイントします。 server1 と server2 の名前は最後がピリオド （.） で終わっていないため、その後ろに $ORIGIN ドメインが置かれ、 server1.example.com と server2.example.com に拡張されます。関連 A リソースレコードを通して、その IP アドレスを決定することができます。
標準名の ftp.example.com と www.example.com で利用できる一般的な FTP と Web のサービスは、 CNAME レコードを使って、これらの名前に合ったサービスにポイントされます。
このゾーンファイルは、 named.conf ファイルの zone ステートメントでサービスにコールされます。以下のようになります：
zone "example.com" IN { type master; file "example.com.zone"; allow-update { none; }; };
逆引き名前解決ゾーンファイルは、特定のネーム空間の IP アドレスを FQDN に変換します。これは標準ゾーンファイルに非常に似ていますが、 PTR リソースレコードが IP アドレスを完全修飾ドメイン名にリンクする為に使われるという点で異なっています。
以下の例では基本的な PTR レコードのレイアウトを示しています:
<last-IP-digit> IN PTR <FQDN-of-system>
<last-IP-digit> は、特定のシステムの FQDN をポイントする IP アドレスの最後の数です。
次の例では、 IP アドレス 10.0.1.1 から 10.0.1.6 は、対応する FQDN に ポイントされています。 /var/named/example.com.rr.zone に位置しています。
$ORIGIN 1.0.10.in-addr.arpa. $TTL 86400 @ IN SOA dns1.example.com. hostmaster.example.com. ( 2001062501 ; serial 21600 ; refresh after 6 hours 3600 ; retry after 1 hour 604800 ; expire after 1 week 86400 ) ; minimum TTL of 1 day 1 IN PTR dns1.example.com. 2 IN PTR dns2.example.com. 5 IN PTR server1.example.com. 6 IN PTR server2.example.com. 3 IN PTR ftp.example.com. 4 IN PTR ftp.example.com.
このゾーンファイルは、 named.conf ファイルの zone ステートメントでサービスにコールされます。以下のようになります：
zone "1.0.10.in-addr.arpa" IN { type master; file "example.com.rr.zone"; allow-update { none; }; };
ゾーンの命名法を除き、この例と標準 zone ステートメントの間にはほとんど違いがありません。逆引き名前解決ゾーンでは、 IP アドレスの最初の3つのブロックを逆にし、その後に .in-addr.arpa を添付する必要があることに注意してください。これにより逆引き名前解決ゾーンファイルで使用される IP 番号の1つのブロックがこのゾーンで正しく添付されます。
BIND には、 rndc というユーティリティコマンドが含まれています。それを使用することで、ローカルホスト又はリモートホストからの named デーモンのコマンドライン管理ができます。
named デーモンへの権限のないアクセス防止するために、 BIND は共有秘密鍵認証方法を使用して、ホストに特権を与えます。これは、 /etc/named.conf と rndc の設定ファイルである /etc/rndc.conf の両方で同一の鍵が存在しなければならないということになります。
注記
bind-chroot パッケージをインストールしている場合、 BIND サービスは /var/named/chroot 環境の中で動作します。全ての 設定ファイルはそこへ移動され、その状態で、 rndc.conf ファイルは /var/named/chroot/etc/rndc.conf 内に置かれます。
rndc ユーティリティが chroot 環境で実行されないため、 /etc/rndc.conf は /var/named/chroot/etc/rndc.conf への symlink であることに注意して下さい。
rndc が named サービスに接続される為には、 BIND サーバーの /etc/named.conf ファイルに controls ステートメントがなければなりません。
以下の例に示す controls ステートメントにより、ローカルホストから rndc が接続できるようになります。
controls { inet 127.0.0.1 allow { localhost; } keys { <key-name>; }; };
このステートメントは named にループバックアドレスのデフォルト TCP ポート 953 をリッスンするように指示し、適切な鍵が与えられた場合にローカルホストからの rndc コマンドを許可します。 <key-name> は、 /etc/named.conf ファイル内の key ステートメントで名前を指定します。次の例は、 key ステートメントのサンプルを示します。
key "<key-name>" { algorithm hmac-md5; secret "<key-value>"; };
この場合には、 <key-value> は HMAC-MD5 アルゴリズムを使用します。以下のコマンドを発行して HMAC-MD5 アルゴリズムを利用し鍵を生成します:
dnssec-keygen -a hmac-md5 -b <bit-length> -n HOST <key-file-name>
鍵は 256 ビットの長さ以上ある方がいいでしょう。 <key-value> 領域に置くべき実際の鍵は、このコマンドで生成される <key-file-name>
警告
/etc/named.conf は、すべてが読み込めるファイルであるため、 key ステートメントを別のファイルの中に置いて root のみの読み取り可能にして、次の例のように include ステートメントを使用して参照します:
include "/etc/rndc.key";
key は /etc/rndc.conf の中で最も重要なステートメントです。
key "<key-name>" { algorithm hmac-md5; secret "<key-value>"; };
<key-name> と <key-value> は /etc/named.conf 内での設定とまったく同じでなくてはなりません。
ターゲットサーバーの /etc/named.conf に指定された鍵をテストするには次の行を /etc/rndc.conf に追加します。
options { default-server localhost; default-key "<key-name>"; };
このディレクティブはグローバルなデフォルト鍵を設定します。しかし、 rndc 設定ファイルも次の例にあるように、異なるサーバーに異なる鍵を指定できます:
server localhost { key "<key-name>"; };
重要
root ユーザー以外は /etc/rndc.conf ファイルを読み書きできないようにしてください。
/etc/rndc.conf ファイルに関する詳細は、 rndc.conf の man ページを参照してください。
rndc コマンドは以下のような形態をとります。
rndc <options><command><command-options>
rndc を適切に設定されたローカルホストで実行する場合、以下のコマンドが利用できます。
-
halt—namedサービスをただちに停止します。 -
querylog— このネームサーバーに送られたクエリのすべてをログします。 -
refresh— ネームサーバーのデータベースをリフレッシュします。 -
reload— ゾーンファイルをリロードしますが、以前にキャッシュされた他の回答を全て保存します。このコマンドを使用すると、すべての保存された解決を消失することなくゾーンファイルの変更が出来ます。加えた変更が特定のゾーンのみに影響する場合、
reloadコマンドの後にそのゾーン名を付加することでその特定ゾーンだけをリロードします。 -
stats— 現在のnamed統計を/var/named/named.statsファイルにダンプします。 -
stop— サーバーを安全に停止し、終了前に動的な更新や IXFR (Incremental Zone ransfers) データを保存します。
ときには、 /etc/rndc.conf ファイル内のデフォルト設定を上書きしたい場合があるかもしれません。そのような場合には、以下のようなオプションが利用できます：
-
-c— 設定ファイルの代替場所を指定します。<configuration-file> -
-p— デフォルトの 953 以外の<port-number>rndc接続に使用するポート番号を指定します。 -
-s—<server>/etc/rndc.confに記されているdefault-server以外のサーバーを指定します。 -
-y—<key-name>/etc/rndc.conf内のdefault-keyオプション以外の鍵を指定します。
これらのオプションについてのさらに詳しい情報は、 rndc man ページに記載されています。
ほとんどの BIND 実装では、 named だけを使用して名前解決サービスを提供したり、特定のドメインかサブドメインの権限として動作したりします。しかし BIND バージョン 9 には数多くの高度な機能があり、より安全で効率的な DNS サービスを利用することができます。
重要
DNSSEC、 TSIG、 IXFR (次ぎのセクションで定義) など先進機能のうちいくつかは、この機能に対応したネームサーバーを持つネットワーク環境でのみ使用することができます。ネットワーク環境に非 BIND のネームサーバーや、旧式の BIND ネームサーバーがある場合には、これらを利用する前に各先進機能に対応しているかどうか確認してください。
ここで述べてある機能はすべて、 項6.7.1. 「インストールされているドキュメント」 の BIND 9 管理者リファレンスマニュアル でさらに詳細に説明されています。
BIND は、 IXFR （Incremental Zone Transfers 増分ゾーン転送）をサポートしています。これは、スレーブネームサーバーはマスターネームサーバー上で変更されたゾーンの更新部分だけをダウンロードします。標準転送プロセスでは、たとえわずかな変更であってもゾーン全体を各スレーブネームサーバーに転送しなくてはなりません。非常に長いゾーンファイルと数多くのスレーブネームサーバーを持つ非常に人気のあるドメインには、 IXFR を利用することにより、通知と更新プロセスのリソース集中を大幅に削減することができます。
IXFR は、 動的更新 を利用してマスターゾーンレコードの変更を行っている場合にのみ利用可能であることに注意してください。手作業でゾーンファイルを編集して変更を行っている場合は、 AXFR (Automatic Zone Transfer) が使用されます。動的更新の詳細については、 BIND 9 管理者リファレンスマニュアル 内の 項6.7.1. 「インストールされているドキュメント」 を御覧下さい。
named.conf の view ステートメントを使用することにより、 BIND では、要求発信元のネットワークに応じて異なる情報を提出することができます。
ローカルネットワーク以外のクライアントには重要なタイプの DNS クエリを拒絶し、内部のクライアントはこれができるようにしたいというような場合、この機能が使用されます。
view ステートメントは、 match-clients オプションを使用して IP アドレスかネットワーク全体を一致させ、特別のオプションとゾーンデータを与えるようにします。
BIND はマスターネームサーバーとスレーブネームサーバーの両方でゾーンの更新と転送を保護するためのさまざまな方法をサポートしてしています。
- DNSSEC
-
DNS SECurity の短縮形。この機能を利用すると、 ゾーン鍵 でゾーンを暗号的に署名することができます。
この方法により、ある特定のゾーンの情報は、受領者がそのネームサーバーの公開鍵を持っている限り、特定の秘密鍵で署名したネームサーバーから来たものとして検証することができます。
BIND バージョン 9 はまた、メッセージ認証の SIG (0) 公開秘密鍵方法をサポートしています。
- TSIG
-
Transaction SIGnatures の略語です。マスターとスレーブの両方で共有秘密鍵が存在することが証明された後でのみ、この機能でマスターからスレーブへの転送が認可されます。
この機能により標準 IP アドレスに基づいた転送許可の方法が強化されます。攻撃者は IP アドレスにアクセスしてゾーンを転送しなくてはならないだけでなく、秘密鍵を知らなくてはならなくなります。
BIND バージョン 9 はまた、 TKEY をサポートしています。これは、ゾーン転送を許可するもう1つの共有秘密鍵方法です。
初心者にとって BIND 設定ファイルを編集するときに間違えたりすることはよくあります。以下の問題を避けるように気を付けて下さい：
-
ゾーンファイルを編集するときには必ずシリアル番号をインクリメントしてください。
シリアル番号がインクリメントされない場合、マスターネームサーバーは、正しく新しい情報を得ることができますが、スレーブネームサーバーにはその変更は通知されず、そのゾーンのデータをリフレッシュしようとしません。
-
/etc/named.confファイルでは、大かっことセミコロンは必ず正しく使ってください。セミコロンが省略されていたり、大かっこ部分が閉じていなかったりした場合、
namedが起動を拒否する原因になる可能性があります。 -
忘れずにすべてのFQDNの後のゾーンファイルにピリオド （
.） を付け、ホスト名ではピリオドを省略してください。ドメイン名の後のピリオドは完全修飾ドメイン名を示します。ピリオドを省略すると、
namedはそのゾーンの名前か、$ORIGIN値を名前の後ろに付けてこれを完成させます。 -
namedから他のネームサーバーへのファイアウォールが接続をブロックしている場合、この設定ファイルを編集します。デフォルトで、 BIND バージョン 9 は 1024 以上のランダムポートを使用して、他のネームサーバーにクエリを出します。しかし、ファイアフォールの中にはすべてのネームサーバーがポート 53 のみを使用して通信することを期待するものもあります。
namedが強制的にポート 53 を使用するようにするには、以下に示す行を/etc/named.confのoptionsステートメントに追加します：query-source address * port 53;
以下の情報源は、 BIND に関する追加情報を提供します。
BIND には多くの異るトピックが網羅された広範囲なドキュメントがインストールされており、それぞれのトピックはそれ自身の題名のディレクトリにあります。以下の各項目では、 <version-number> を、システムにインストールされた bind のバージョンで入れ換えます:
-
/usr/share/doc/bind-<version-number>/ -
このディレクトリは最新の機能を一覧表示しています。
-
/usr/share/doc/bind-<version-number>/arm/ -
このディレクトリには BIND 9 管理者リファレンスマニュアル の HTML と SGML が含まれています。この中には、 BIND リソース要件、異なったタイプのネームサーバーを設定する方法、ロードバランシングの実行方法などの高度なトピックが記載されています。ほとんどの BIND 初心者にとって、最初に読むのにもっとも適した場所です。
-
/usr/share/doc/bind-<version-number>/draft/ -
このディレクトリには、 DNS サービスに関連した問題を見直す各種技術ドキュメントが含まれており、それが問題に対する幾つかの方法を提案しています。
-
/usr/share/doc/bind-<version-number>/misc/ -
このディレクトリには特定の高度な問題を扱うよう設計されたドキュメントが含まれています。 BIND バージョン 8 のユーザーは、
migrationドキュメントを参照して、 BIND 9 に移行する際に実行しなくてはならない特定の変更を調べる必要があります。optionsファイルには、/etc/named.confで使用する BIND 9 に実装されているオプションがすべて一覧表示されています。 -
/usr/share/doc/bind-<version-number>/rfc/ -
このディレクトリは BIND に関連した全ての RFC ドキュメントを提供します。
BIND に関連した各種アプリケーションと設定ファイルについての man ページが多くあります。以下は、なかでも重要と思われる man ページの一覧です。
- 管理アプリケーション
-
-
man rndc— BIND ネームサーバーを制御する為のrndcを使用する時に利用できる異なるオプションを説明しています。
-
- サーバーアプリケーション
-
-
man named— BIND ネームサーバーデーモンを制御するのに使用されるさまざまな引数を検索出来ます。 -
man lwresd— 軽量リゾルバデーモンの目的と、利用できるオプションについて説明しています。
-
- 設定ファイル
-
-
man named.conf—named設定ファイルの中で利用できるオプションの総括的な一覧です。 -
man rndc.conf—rndc設定ファイル内で利用できるオプションの総括的な一覧です。
-
-
http://www.isc.org/index.pl?/sw/bind/ — BIND プロジェクトのホームページ。現在のリリースについての情報と BIND 9 管理者リファレンスマニュアル の PDF バージョンを含んでいます。
-
http://www.redhat.com/mirrors/LDP/HOWTO/DNS-HOWTO.html — 解決用キャッシング用ネームサーバーとしての BIND の使用方法と、ドメインのためのプライマリネームサーバーとして機能させるのに必要なさまざまなゾーンファイルの設定が記載されています。
SSH™ (いわゆる Secure SHell) は2つのシステム間でクライアント/サーバーアーキテクチャを使用して安全な接続を具備して、ユーザーがリモートでサーバーのホストシステムにログインできるようにします。 FTP や Telnet のような他のリモート通信プロトコルとは異り、 SSH は ログインセッションを暗号化するため、侵入者が暗号化のないパスワードを盗むのを困難にするような接続を確立します。
SSH は リモートホストへのログインに使用される telnet や rsh のような旧式で安全性の低いターミナルアプリケーションを入れ換えるように設計されています。 scp と呼ばれる関連したプログラムは、 rcp などのホスト間でファイルをコピーする旧式のプログラムから入れ換わります。これらの旧式のアプリケーションはクライアントとサーバー間で送信されるパスワードを暗号化しませんので、可能な限り使用を避けるようにします。リモートシステムへのログインに安全な方法を使用することで、クライアントとリモートホストの両方へのリスクを低減します。
SSH プロトコルは以下の安全策を提供します:
-
初期接続の後、クライアントは以前に接続していたのと同じサーバーに接続していることを確認できます。
-
クライアントは、堅牢な 128-bit 暗号化を使用してサーバーへ認証情報を送信します。
-
セッション中に発信、及び受信された全てのデータは 128-bit 暗号化を使用して送信されるため、復号化と読み取りをするための盗聴は非常に困難になります。
-
クライアントはサーバーから X11 アプリケーション [1] を転送することができます。この技術は X11 転送 と呼ばれ、ネットワーク上でグラフィカルアプリケーションを安全に使用する手段を提供します。
SSH プロトコルは、それが発信と受信をするすべてを暗号化しますので、他では安全でないプロトコルにも安全確保に使用できます。 ポート転送 (port forwarding) と呼ばれる技術を使用して、 SSH サーバーは、 POP などの他では安全でないプロトコルを安全にする通路となり、システムとデータの全体的セキュリティを強化します。
OpenSSH サーバーとクライアントは、仮想プライベートネットワーク (vpn) と同じように、サーバーとクライアントマシン間のトラフィックにトンネルを作成することもできます。
Red Hat Enterprise Linux には、一般的な OpenSSH パッケージ (openssh) と共に OpenSSH サーバー (openssh-server)、及びクライアント (openssh-clients) のパッケージが含まれています。 OpenSSH パッケージは OpenSSL パッケージ (openssl) を必要とすることに注意して下さい。 OpenSSL パッケージは数種の暗号化ライブラリをインストールして、 OpenSSH が暗号化通信を提供できるようにします。
極悪なコンピュータユーザーは、彼らがあるシステムにアクセスをする為に妨害、介入、ネットワークの経路変更などを可能にする各種のツールを持って、自由に使える状態にあります。一般的な名目で、これらの脅威は以下のように分類することができます:
-
2つのシステム間での通信傍受 — このシナリオでは、攻撃者はネットワーク上で通信中の二者間の何処かに存在し、両者で送信される情報をコピーします。攻撃者は傍受して、情報を盗んだり、又は改訂してから本来の受信者に送りつけます。
この攻撃は、パケットスニファの使用を通じてマウントが可能になります — 一般的なネットワークユーティリティです。
-
特定ホストとして擬装 — この作戦を使用して攻撃者のシステムは送信の本来の受信者のふりをします。この作戦が成功すると、ユーザーのシステムは、間違えたホストと通信していることに気づかないままとなります。
この攻撃は、 DNS ポイゾニング [2] として知られる技術で、又は IP スプーフィング [3] を通じてマウントが可能になります。
この両方の技術は潜在的に繊細な情報を傍受し、その傍受が攻撃的な理由でなされた場合、結果は致命的です。
SSH がリモートシェルログインとファイルコピーに使用されると、これらのセキュリティ脅威は大幅に減少します。これは、 SSH クライアントとサーバーがデジタル署名を使用してそれぞれの身元を証明しているからです。さらには、クライアントシステムのサーバーシステム間の全ての通信が暗号化されています。それぞれのパケットが、ローカルとリモートシステムのみに知られているキーを使用して暗号化されている為、通信の何方か側の身元を擬装しようとする試みは成功しません。
SSH プロトコルにより、どのクライアントとサーバーのプログラムもこのプロトコルの仕様を使って安全に通信できて、交替使用も出来ます。
2種類の SSH (バージョン 1 と バージョン 2) が現在存在します。 Red Hat Enterprise Linux のOpenSSH セットは、バージョン 1 内での悪用に対して脆弱性のない拡張鍵交換アルゴリズムを持つバージョン 2 を使用します。但し、 OpenSSH セットはバージョン 1 の接続をサポートしていません。
重要
可能な限り SSH バージョン 2 との互換性を持つサーバーとクライアントのみの使用が推奨されます。
以下の連続したイベントは、2つのホスト間の SSH 通信の統合性を保護するのに役に立ちます。
-
暗号方式ハンドシェークが行なわれ、クライアントは正しいサーバーと交信していることを確認します。
-
クライアントとリモートホスト間接続のトランスポートレイヤーは対象型暗号を使用して暗号化されます。
-
クライアントはサーバーに対して自身を認証します。
-
リモートクライアントは、暗号化した接続を通じてリモートホストと交信します。
トランスポートレイヤーの主な役割は認証時とその後の通信期間での2つのホスト間に於ける安全な交信を用意することです。トランスポートレイヤーは、データの暗号化と複合化すること、そして、データが送信と受信される時にデータパケットの統合性を保護することで、この役割を達成します。トランスポートレイヤーはまた、情報を圧縮して送信の高速化もします。
SSH クライアントがサーバーに接続すると、基本情報が交換されて両システムは正しくトランスポートレイヤーを構築することができるようになります。この交換の間に以下のようなステップが起こります:
-
鍵が交換されます
-
公開鍵暗号化アルゴリズムが決定されます
-
対象型暗号化アルゴリズムが決定されます
-
メッセージ認証アルゴリズムが決定されます
-
ハッシュアルゴリズムが決定されます
鍵交換の間、サーバーはそれ自身を独自の ホスト鍵 で、クライアントに対して証明します。クライアントがこの特定のサーバーと過去に通信したことがなければ、サーバーのホスト鍵はクライアントには未知であり、接続は成立しません。 OpenSSH は、サーバーのホスト鍵を承認することでこの問題を回避します。これは、ユーザーが通知を受けて新規のホスト鍵を承認し確証した後に起こります。それ以降の接続では、サーバーのホスト鍵は、クライアント上に保存してある情報と照らし合わせてチェックされ、クライアントが本当に目的のサーバーと通信していることの確証を与えます。時間が経過して、このホスト鍵が一致しない状態が起こると、ユーザーがクライアントに保存してある古い情報を削除することにより、新しい接続が可能になります。
注意
ローカルシステムは本来のサーバーと攻撃者が設定した偽のサーバーとの違いを理解しない為、攻撃者は初期交信の時点で SSH サーバーとして擬装することが可能になります。この防止への手助けとして、最初の接続の前に、又はホスト鍵の不一致が発生した場合にサーバー管理者へ連絡することで、新規の SSH サーバーの統合性を確認すると良いでしょう。
SSH はほとんど全ての公開鍵アルゴリズム、又はエンコード形式で機能するように設計されています。初期の鍵交換が、秘密値の交換と共有に使用されるハッシュ値を作成した後、2つのシステムは迅速に新しい鍵とアルゴリズムを算出してこの接続で送信される認証と将来のデータを保護します。
設定された鍵とアルゴリズムを使用して一定量のデータが送信された後 (この量は SSH の実装によりことなります)、別の鍵交換が発生してもう１つのハッシュ値セットと新しい共有秘密値が生成されます。攻撃者がハッシュ値と共有秘密値を判別できたとしても、その情報はほんの短い時間しか役に立ちません。
トランスポートレイヤーが安全なトンネルを構築して2つのシステム間で情報が渡されると、サーバーはクライアントに対して、秘密鍵のエンコードを持つ署名やパスワード入力の使用などサポートされている別の認証方法を伝えます。クライアントはその後、これらのサポートのある方法でサーバーに対して自身の認証を試みます。
SSH サーバーとクライアントは異なるタイプの認証方法を許可できるように設定されており、これが両側に高水準の制御を与えます。サーバーはそのセキュリティモデルに応じて、サポートする暗号化方法を決定することができ、クライアントは利用できるオプションの中から認証方法の順番を選択することができます。
SSH トランスポートレイヤーでの認証に成功した後、複数のチャンネルが multiplexing[4] と呼ばれる技術を通して開かれます。これらのチャンネル群内の各チャンネルは異なるターミナルセッションと転送された X11 セッション用の通信を処理します。
クライアントとサーバーの両方は新規のチャンネルを作成することができます。各チャンネルはその後、接続の両端で別々の番号が割り当てられます。クライアントが新規のチャンネルを開こうと試みる時、クライアントは要求と一緒にチャンネル番号を送信します。この情報はサーバーで保存され、そのチャンネルに通信を転送するのに使用されます。これは、異なるタイプのセッションがお互いに干渉しないようにするため、及び、あるセッションが終了した時にそのチャンネルが主要 SSH 接続を妨害せずに閉じることができるようにするためです。
チャンネルは、 flow-control もサポートしており、これはチャンネルが順序良くデータを送信/受信するのを可能にします。この方法では、クライアントがチャンネルが開いていると言うメッセージを受信するまで、データはチャンネルに送信されません。
クライアントが要求するサービスのタイプとユーザーがネットワークに接続されている方法に従って、クライアントとサーバーは、自動的に各チャンネルの構成を折衝します。これにより、プロトコルの基本構成を変更することなく、異なるタイプのリモート接続の処理に多大な柔軟性を得ることができます。
OpenSSH サーバーを実行するには、最初に適切な RPM パッケージがインストールされていることを確認する必要があります。 openssh-server パッケージが必要であり、これは openssh パッケージに依存します。
OpenSSH デーモンは、設定ファイル /etc/ssh/sshd_config を使用します。デフォルトの設定ファイルは、ほとんどの目的に十分なはずです。デフォルトの sshd_config が提供していない方法でデーモンを設定する場合は、 sshd の man ページで、設定ファイル内に定義できるキーワードの一覧を御覧下さい。
再インストールすると、インストールされたシステムは新しい識別鍵のセットを作成します。再インストールの前に OpenSSH ツールのいずれかでシステムに接続していたクライアントはすべて次のようなメッセージが表示されます。
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed.
システム用に生成されたホスト鍵を保持したい場合は、 /etc/ssh/ssh_host*key* ファイルをバックアップして再インストール後に復元します。この手順によりシステムの身元が保持され、クライアントが再インストール後にシステムへ接続試行した際に警告メッセージを受け取ることがなくなります。
SSH を本当に効果的にするには、 Telnet や FTP などの安全でないプロトコルを使用することは禁止すべきです。そうでないと、 SSH を １ セッション使用してユーザーのパスワードを保護しても、後で Telnet を使用してログインするときに捕まってしまいます。
無効にするサービスには、以下のようなものがあります:
-
telnet -
rsh -
rlogin -
vsftpd
システムへの安全でない接続方法を無効にするには、コマンドラインのプログラムである、 chkconfig か、 ncurses ベースのプログラムである、 /usr/sbin/ntsysv か、あるいは、 サービス設定ツール (system-config-services) のグラフィカルアプリケーションを使用します。これらの全ては、 root レベルのアクセスを必要とします。
OpenSSH には、2つの異なる設定ファイルがあります: １つはクライアントプログラム用 (ssh、 scp、 sftp) で、もう１つはサーバーデーモン用 (sshd) です。
システム全体の SSH 設定情報は、 /etc/ssh/ ディレクトリ内に格納されています:
-
moduli— Diffie-Hellman 鍵交換に使用される Diffie-Hellman グループを含んでおり、これは安全なトランスポートレイヤーを構成するのに重要となります。 SSH セッションの初めに鍵が交換される時、共有の秘密値が作成されますが、これは何方側も単独では決定できません。この値はそれからホスト認証の提供に使用されます。 -
ssh_config— システム全体用のデフォルトの SSH クライアント設定ファイルです。ユーザーのホームディレクトリ内にそれが１つある場合は、上書きされます (~/.ssh/config)。 -
sshd_config—sshdデーモン用の設定ファイルです。 -
ssh_host_dsa_key—sshdデーモンで使用する DSA 秘密鍵です。 -
ssh_host_dsa_key.pub—sshdデーモンで使用する DSA 公開鍵です。 -
ssh_host_key— SSH プロトコルの バージョン 1 対応のsshdデーモンで使用する RSA 秘密鍵です。 -
ssh_host_key.pub— SSH プロトコルのバージョン 1 対応のsshdデーモンで使用する RSA 公開鍵です。 -
ssh_host_rsa_key— SSH プロトコールのバージョン 2 対応のsshdデーモンで使用する RSA 秘密鍵です。 -
ssh_host_rsa_key.pub— SSH プロトコルのバージョン 2 対応のsshdで使用する RSA 公開鍵です。
ユーザー特定の SSH 設定情報はユーザーのホームディレクトリの ~/.ssh ディレクトリ内に保存されています。
-
authorized_keys— このファイルは サーバー用の認証公開鍵のリストを保持しています。クライアントがサーバーに接続する時、サーバーはこのファイル内に保存してある署名済み公開鍵をチェックしてクライアントを認証します。 -
id_dsa— ユーザーの DSA 秘密鍵を含んでいます。 -
id_dsa.pub— ユーザーの DSA 公開鍵です。 -
id_rsa— SSH プロトコルのバージョン 2 対応のsshで使用する RSA 秘密鍵です。 -
id_rsa.pub— SSH プロトコルのバージョン 2 対応のsshで使用する RSA 公開鍵です。 -
identity— SSH プロトコルのバージョン 1 対応のsshで使用する RSA 秘密鍵です。 -
identity.pub— SSH プロトコルのバージョン 1 対応のsshで使用する RSA 公開鍵です。 -
known_hosts— このファイルには、ユーザーがアクセスする SSH サーバーの DSA ホスト鍵が含まれています。このファイルは SSH クライアントが正しい SSH サーバーに接続していることを確認するのに非常に重要です。重要
SSH サーバーのホスト鍵が変更された場合、クライアントは、サーバーのホスト鍵がテキストエディタを使用して
known_hostsファイルから削除されるまで接続が進行できないことをユーザーに知らせます。しかしこれを実行する前に、 SSH サーバーのシステム管理者に連絡してサーバーが侵害を受けていないことを確認する必要があります。
SSH 設定ファイル内で利用できる各種のディレクティブに関する情報には、 ssh_config と sshd_config の man ページを参照して下さい。
クライアントマシンから OpenSSH サーバーへ接続するには、クライアントマシンに openssh-clients と openssh パッケージがインストールされている必要があります。
ssh コマンドは、 rlogin、 rsh、 telnet コマンドに代わる安全な手段です。これを使用してリモートマシンへログインし、リモートマシン上でコマンドを実行することができます。
ssh コマンドを使ってリモートマシンにログインする方法は telnet の場合と同様です。 penguin.example.net という名前のリモートマシンへログインするには、シェルプロンプトで次のコマンドを入力します：
ssh penguin.example.net
初めて ssh コマンドでリモートマシンへログインした場合には、次のようなメッセージが表示されます：
ホスト 'penguin.example.net' の信憑性は確立できません。 DSA キーのフィンガープリントは 94:68:3a:3a:bc:f3:9a:9b:01:5d:b3:07:38:e2:11:0c です。 本当に接続を続けたいですか (yes/no) ?
yes と入力して続行します。これによって、次のメッセージのように、ユーザーの既知ホスト一覧 (~/.ssh/known_hosts/) にそのサーバーが追加されます。
警告: 「penguin.example.net (RSA)」を既知のホスト一覧へ永久追加します。
次に、リモートマシンのパスワードの入力を求めるプロンプトが表示されます。パスワードを入力すると、リモートマシンのシェルプロンプトが現れます。ユーザー名を指定しない場合は、ローカルクライアントマシンにログインしてあるユーザー名がリモートマシンに渡されます。別のユーザー名を指定したい場合は、次のコマンドを使用します：
ssh username@penguin.example.net
ssh -l という構文も使用できます。
username penguin.example.net
ssh コマンドを使用すると、シェルプロンプトへログインせずに、リモートマシン上でコマンドを実行できます。構文は、 ssh です。たとえば、リモートマシンpenguin.example.net上で hostnamecommandls /usr/share/doc というコマンドを実行する場合は、シェルプロンプトで次のコマンドを入力します：
ssh penguin.example.net ls /usr/share/doc
正しいパスワードを入力すると、リモートディレクトリ /usr/share/doc の内容が表示され、その後ローカルのシェルプロンプトへ戻ります。
scp コマンドを使うと、安全な暗号化通信を介してマシン間でファイルを転送できます。これは、 rcp コマンドによく似ています。
ローカルファイルをリモートシステムへ転送するための一般的な構文は次の様になります：
scp<localfile>username@tohostname:<remotefile>
<localfile> には、 /var/log/maillog などのようにファイルへのパスを入れた転送元を指定します。 <remotefile> は転送先です。 /tmp/hostname-maillog などのように新しいファイル名でも構いません。リモートシステム側で / を先頭に付けないと、パスは username のホームディレクトリに相対になります。一般的には /home/username/ です。
shadowman というローカルファイルを penguin.example.net の自分のアカウントのホームディレクトリに転送するには、シェルプロンプトで次のように入力します （username には自分のユーザー名を入れます）。
scp shadowman username@penguin.example.net:shadowman
これでローカルファイル shadowman が penguin.example.net の /home/ に転送されます。代りに、 username/shadowmanscp コマンドで最後の shadowman を省略しても構いません。
リモートファイルをローカルシステムへ転送する一般的な構文は次の様になります：
scpusername@tohostname:<remotefile><newlocalfile>
<remotefile> でパスを入れた転送元を指定し、 <newlocalfile> でパスを入れた転送先を指定します。
転送元ファイルとして複数のファイルを指定できます。たとえば、 downloads/ ディレクトリの内容を、リモートマシン penguin.example.net の uploads/ という既存ディレクトリへ転送するには、シェルプロンプトで次のように入力します。
scp downloads/* username@penguin.example.net:uploads/
安全なコマンドラインインターフェイスは、 SSH が使用できる多くの方法の単なる一部分です。充分なバンド幅があれば、 X11 セッションは １ つの SSH チャンネル上で方向指定できます。又は、 TCP/IP 転送を使用することで、以前にシステム間で不安全であったポート接続は、特定の SSH チャンネルにマップすることができます。
SSH 接続で X11 セッションを開くには、 -Y オプションを使用して SSH サーバーに接続し、ローカルマシン上の X プログラムを開くだけのことです。
ssh -Y <user>@example.com
安全なシェルプロンプトから X プログラムが実行されると、 SSH クライアントとサーバーは新しい安全なチャンネルを作成し、 X プログラムデータはそのチャンネルを通じて透過的にクライアントマシンに送信されます。
X11 転送はとても便利なものです。例えば、 X11 転送は安全で、インタラクティブな プリンタ設定ツール のセッションを作成するのに使用できます。これを行なうには、 ssh を使用して、サーバーに接続して、以下を入力します:
system-config-printer &
サーバー用の root パスワードを入力した後に、 プリンタ設定ツール が表示されてリモートユーザーが安全にリモートシステム上の印刷を設定できるようになります。
SSH は、他では不安全なポート転送経由の TCP/IP プロトコルを安全にすることができます。この技術を使用する場合、 SSH サーバーは SSH クライアントに対する暗号化した導管になります。
ポート転送は、クライアント上のローカルポートをサーバー上のリモートポートにマッピングすることで機能します。 SSH ではサーバーのどんなポートからでもクライアント上のどんなポートにもマップ可能です。この技術が機能するのにポート番号が一致する必要はありません。
ローカルホスト上の接続をリスンする TCP/IP ポート転送チャンネルを作成するには、次のコマンドを使用します:
ssh -Llocal-port:remote-hostname:remote-portusername@hostname
注記
1024 以下のポートをリスンする為のポート転送をセットするには、 root レベルのアクセスが必要です。
暗号化した接続を経由して、 POP3 を使った mail.example.com と言うサーバー上のメールをチェックするには、次のコマンドを使用します:
ssh -L 1100:mail.example.com:110 mail.example.com
ポート転送チャンネルがクライアントマシンとメールサーバー間に配置されると、 POP3 メールクライアントに対しローカルホスト上のポート 1100 を使用して、新規メールをチェックするように指示します。クライアントシステム上のポート 1100 に送信される要求はいずれも安全に mail.example.com サーバーに向けられます。
mail.example.com が SSH サーバーを実行していなくて、同じネットワークの別のマシンが SSH サーバーを実行している場合、 SSH はそれでも使用可能であり、接続の一部を安全にすることができます。しかし、次のような少々異なるコマンドが必要です:
ssh -L 1100:mail.example.com:110 other.example.com
この例では、クライアントマシン上のポート 1100 からの POP3 要求がポート 22 上の SSH 接続を通じて SSH サーバー other.example.com に転送されます。それから、 other.example.com は mail.example.com 上のポート 110 に接続して、新規のメールをチェックします。この技術を使う場合、クライアントシステムと other.example.com の SSH サーバー間の接続のみが安全であることに注意して下さい。
ポート転送は、ネットワークのファイヤーウォールを通過して安全に情報を取得することにも使用できます。ファイヤーウォールがその標準ポート (22) を経由して SSH トラフィックを許可するように設定されていて、他のポートへのアクセスを阻止している場合、確立された SSH 接続上でそれらの通信を転送することにより、阻止されたポートを使用する二つのホスト間の接続が可能になります。
注記
この方法でポート転送を使って、接続を転送すると、そのクライアントシステム上のユーザーはいずれもそのサーバーに接続できるようになります。但し、クライアントシステムが侵略された場合、攻撃者は転送サービスにまでもアクセスが出来るようになります。
ポート転送に懸念のあるシステム管理者は、 /etc/ssh/sshd_config にある AllowTcpForwarding の行に No パラメータを指定して、 sshd サービスを再起動することでサーバー上のこの機能を無効にすることができます。
ssh、 scp、 sftp のいずれかを使用してリモートマシンに接続するたびにパスワードを入力したくない場合は、認証鍵ペアを生成できます。
鍵は、ユーザーごとに生成する必要があります。次の手順に従い、リモートマシンへの接続を要求するユーザーとしてユーザー鍵を生成します。 root として以下の手順を完了した場合、鍵を使用できるのは root だけです。
OpenSSH バージョン 3.0 始まった、 ~/.ssh/authorized_keys2、 ~/.ssh/known_hosts2、 /etc/ssh_known_hosts2 は古くなっています。 SSH Protocol 1 と2 は、 ~/.ssh/authorized_keys、 ~/.ssh/known_hosts、 /etc/ssh/ssh_known_hosts ファイルを共有しています。
Red Hat Enterprise Linux 5.2 uses SSH Protocol 2 and RSA keys by default.
ヒント
Red Hat Linux を再インストールするので生成された鍵ペアを保存したい場合は、ホームディレクトリの .ssh ディレクトリをバックアップします。再インストール後に、このディレクトリをホームディレクトリにコピーして戻します。この手順は、 root も含めて、システム上のすべてのユーザーに実行できます。
次の手順で、 SSH プロトコルバージョン 2 に対応する RSA 鍵ペアを生成します。これは OpenSSH 2.9 以降でのデフォルトです。
-
SSH プロトコルバージョン 2 で動作する RSA 鍵ペアを生成するには、シェルプロンプトで次のコマンドを入力します：
ssh-keygen -t rsa
デフォルトファイルの場所として、
~/.ssh/id_rsaを受け入れます。ユーザーアカウントのパスワードとは異なったパスフレーズを入力し、確定のためもう1度入力します。公開鍵は
~/.ssh/id_rsa.pubに書き込まれます。秘密鍵は~/.ssh/id_rsaに書き込まれます。秘密鍵を他人に配布してはいけません。 -
次のコマンドを使用して
.sshディレクトリのパーミッションを変更します。chmod 755 ~/.ssh
-
~/.ssh/id_rsa.pubの内容を接続するマシン上の~/.ssh/authorized_keysファイルにコピーします。~/.ssh/authorized_keysファイルが存在する場合は、~/.ssh/id_rsa.pubファイルの内容を相手マシン上の~/.ssh/authorized_keysファイルへ追加します。 -
次のコマンドを使用して
authorized_keysファイルのパーミッションを変更します。chmod 644 ~/.ssh/authorized_keys
-
GNOME を稼動しているか、又は GTK2+ ライブラリをインストールしてグラフィカルデスクトップを実行している場合は、 項7.7.3.4. 「GUI を使った
ssh-agentの設定」 へ進みます。 X Window System を稼動していない場合は、 項7.7.3.5. 「ssh-agentの設定」 へ進みます。
次の手順で、 SSH プロトコルバージョン 2 に対応する DSA 鍵ペアを生成します。
-
SSH プロトコルバージョン 2 で動作する DSA 鍵を生成するには、シェルプロンプトで次のコマンドを入力します：
ssh-keygen -t dsa
デフォルトファイルの場所として、
~/.ssh/id_dsaを受け入れます。ユーザーアカウントパスワードとは異なるパスフレーズを入力し、確定のためもう1度入力します。ヒント
パスフレーズとは、ユーザー認証に使用される一連の単語と文字です。パスフレーズは、スペースやタブを使用できる点でパスワードとは異なります。通常、パスフレーズでは、1つの単語の代わりに複数のフレーズを使用するため、パスワードより長くなります。
公開鍵は、
~/.ssh/id_dsa.pubに書き込まれます。秘密鍵は~/.ssh/id_dsaに書き込まれます。秘密鍵をほかの人に渡さないことが重要です。 -
次のコマンドを使用して
.sshディレクトリのパーミッションを変更します。chmod 755 ~/.ssh
-
~/.ssh/id_dsa.pubの内容を接続するマシン上の~/.ssh/authorized_keysにコピーします。~/.ssh/authorized_keysファイルが存在する場合は、~/.ssh/id_dsa.pubファイルの内容を相手マシン上の~/.ssh/authorized_keysファイルへ追加します。 -
次のコマンドを使用して
authorized_keysファイルのパーミッションを変更します。chmod 644 ~/.ssh/authorized_keys
-
GNOME を稼動しているか、又は GTK2+ ライブラリをインストールしてグラフィカルデスクトップ環境を実行している場合は、 項7.7.3.4. 「GUI を使った
ssh-agentの設定」 へ進みます。 X Window System を稼動していない場合は、 項7.7.3.5. 「ssh-agentの設定」 へ進みます。
次の手順で、 SSH プロトコルバージョン 1 が使用する RSA 鍵ペアを生成します。 DSA を使用するシステム同士を接続している場合は、 RSA バージョン 1.3 または RSA バージョン 1.5 鍵ペアは必要ありません。
-
RSA （バージョン1.3と1.5のプロトコルに対応） 鍵ペアを生成するには、シェルプロンプトで次のコマンドを入力します：
ssh-keygen -t rsa1
デフォルトのファイルの場所 （
~/.ssh/identity） を受け入れます。アカウントパスワードとは異なるパスフレーズを入力します。確定のため、もう1度入力します。公開鍵は
~/.ssh/identity.pubに書き込まれます。秘密鍵は~/.ssh/identityに書き込まれます。秘密鍵を他人に渡さないでください。 -
chmod 755 ~/.sshコマンドとchmod 644 ~/.ssh/identity.pubコマンドを使って、.sshディレクトリと鍵のパーミッションを変更します。 -
~/.ssh/identity.pubの内容を接続するマシン上の~/.ssh/authorized_keysファイルへコピーします。~/.ssh/authorized_keysファイルが存在しない場合は、~/.ssh/identity.pubファイルをそのリモートマシン上の~/.ssh/authorized_keysファイルへコピーすることができます。 -
GNOME を稼動している場合は、 項7.7.3.4. 「GUI を使った
ssh-agentの設定」 へ進みます。 GNOME を稼動していない場合は、 項7.7.3.5. 「ssh-agentの設定」 へ進みます。
ssh-agent ユーティリティを使用するとパスフレーズを保存できるため、 ssh や scp 接続を開始するたびにパスフレーズを入力する必要はありません。 GNOME を使用している場合は、 gnome-ssh-askpass パッケージに含まれるアプリケーションを使用するとユーザーが GNOME へログインするときにパスフレーズの入力が要求され、 GNOME からログアウトするまでパスフレーズを保存しておくことができます。つまり、 GNOME セッション中は、 ssh 接続または scp 接続を確立するたびに、パスワードやパスフレーズを入力する必要はありません。 GNOME を使用していない場合は、 項7.7.3.5. 「ssh-agent の設定」 を参照してください。
GNOME セッションが終了するまでパスフレーズを保存するための手順は次のとおりです：
-
gnome-ssh-askpassパッケージがインストールされている必要があります。rpm -q openssh-askpassコマンドを使用して、インストールされているかどうかを判別できます。インストールされていない場合は、 Red Hat Enterprise Linux CD-ROM セット、 Red Hat FTP ミラーサイト、 Red Hat Network のいずれかを利用してインストールします。 -
(パネル上の) メインメニューボタン => 個人設定=> その他の設定 => セッション の順で選択して 起動プログラム タブをクリックします。 追加 をクリックして、 起動コマンド のテキスト欄に
/usr/bin/ssh-addと入力します。必ず最後に実行されるように、優先順位を既存のコマンドより大きい数字に設定します。ssh-addには 70 以上の優先番号が適しています。優先順位の数字が大きいほど、優先順位は低くなります。他のプログラムが一覧にある場合は、このプログラムが最も低い優先順となる必要があります。 閉じる ボタンをクリックしてプログラムを終了します。 -
ログアウトして、再び GNOME にログインします。つまり、 X を再起動します。 GNOME が起動すると、パスフレーズの入力を求めるダイアログボックスが表示されます。要求されたパスフレーズを入力します。 DSA 鍵ペアと RSA 鍵ペアの両方が設定されている場合は、両方の入力が求められます。この後は、
ssh、scp、sftpのいずれかを実行したときにパスワードの入力が求められることはないはずです。
ssh-agent コマンドを使用してパスフレーズを保存することができます。これにより、 ssh 接続または scp 接続を確立するたびにパスフレーズを入力する必要がなくなります。 X Window System を稼動していない場合は、シェルプロンプトから次の手順を実行します。 GNOME を稼動していても、ログイン時にパスフレーズの入力を求めないように設定する場合は （項7.7.3.4. 「GUI を使った ssh-agent の設定」を参照）、この手順を XTerm などのターミナルウィンドウで実行します。 X は稼動して、 GNOME は稼動していない場合、この手順はターミナルウィンドウで実行します。ただし、パスフレーズはそのターミナルウィンドウにだけ記憶されるので、グローバルな設定ではありません。
OpenSSH と OpenSSL プロジェクトの開発は常に進められているため、これらに関する最新情報は該当する Web サイトを参照してください。 OpenSSH と OpenSSL ツールの man ページでも詳細情報を参照することができます。
-
ssh、scp,sftp、sshd、 及びssh-keygenコマンドの man ページ — これらの man ページには、各コマンドの使用方法と指定できるすべてのパラメータに関する情報が記載されています。
-
http://www.openssh.com/ —OpenSSH FAQページ、バグレポート、メーリングリスト、プロジェクトの目標、セキュリティ機能に関する技術的な詳細情報を参照できます。
-
http://www.openssl.org/ — OpenSSL FAQページ、メーリングリスト、プロジェクトの目標に関する説明を参照できます。
-
http://www.freessh.org/ — その他のプラットフォームに対応する SSH クライアントソフトウェアを確認できます。
[1] X11 とは、 X11R7 ウィンドウ表示システムであり、伝統的に X Window システム、又は X と呼ばれます。 Red Hat Enterprise Linux には、オープンソース X Window システムである X11R7 が格納されています。
[2] DNS ポイゾニングは、侵入者が DNS サーバーをクラックした時に発生します。クライアントシステムを悪意のある複製ホストにポイントします。
[3] IP スプーフィングは、侵入者が、ネットワーク上の信頼できるホストから来たように見える偽りのネットワークパケットを送信する時に発生します。
[4] 複合化接続 (multiplexed connection) は、共有した共通の経路を通じて送信される数種の信号で構成されます。 SSH では、異なるチャンネルが共通の安全な接続で送信されます。
Samba はオープンソースのサーバメッセージブロックプロトコル (SMB) の実装です。Microsoft Windows®、Linux、UNIX、その他オペレーティングシステムをネットワーク化して、Windows ベースのファイルやプリンタ共有へのアクセスを実現します。Samba で SMB を使用することにより Windows クライアントに対しては Windows サーバとして表示させることができます。
Samba の 3 番目のメジャーリリースとなる バージョン 3.0.0 は 旧バージョンから数多くの改良が導入されました。
-
LDAP と Kerberos による Active Directory ドメインへの参加機能
-
国際化のためのビルトインユニコードサポート
-
ローカルレジストリにハッキングすることなく Samba サーバへの Microsoft Windows XP Professional クライアント接続のサポート
-
Samba.org チームによって新しいドキュメントが 2 つ開発されています。 400 ページに及ぶリファレンス関連のマニュアルと 300 ページに及ぶインプルメンテーション及び統合関連のマニュアルです。発行されているドキュメントのタイトルについては 項8.12.2. 「関連書籍」 を参照してください。
Samba はパワフルで用途の広いサーバアプリケーションです。経験豊富なシステム管理者であってもその機能や限界を学んでからインストール及び設定は行ってください。
Samba で行えること:
-
Linux、UNIX、Windows のクライアントへのディレクトリツリーとプリンタの提供
-
ネットワークブラウジング支援 (NetBIOS ありまたはなし)
-
Windows ドメインログインの認証
-
Windows インターネットネームサービス (WINS) ネームサーバ解決の提供
-
Windows NT® 系プライマリドメインコントローラ (PDC) として動作
-
Samba ベース PDC の バックアップドメインコントローラ (BDC) として動作
-
Active Directory ドメインメンバーサーバとして動作
-
Windows NT/2000/2003 PDC に参加
Samba で行えないこと:
-
Windows PDC の BDC として動作 (また、その逆)
-
Active Directory ドメインコントローラとして動作
下記は、各 Samba デーモン及びサービスに関する簡単な概要です。
Samba は、3 つのデーモンで構成されています(smbd、nmbd、winbindd)。 2 つのサービス(smb と windbind)がそのデーモンの開始、停止、その他サービス関連機能の作動方法を制御します。各デーモンごとの詳細、それを制御する特定サービスを一覧表示します。
smbd
smbd サーバデーモンはファイル共有と印刷サービスをWindows クライアントに提供します。さらに、ユーザー認証、リソースのロック、SMB プロトコルでのデータ共有も行います。SMB 通信をリッスンするサーバ上のデフォルトポートは TCP ポート 139 と 445 です。
smbd デーモンは smb サービスに制御されます。
nmbd
nmbd サーバデーモンは、Windows ベースのシステムで SMB/CIFS により生成される要求などの NetBIOS ネームサービス要求を理解してそれに応答します。こうしたシステムには Windows 95/98/ME、Windows NT、Windows 2000、Windows XP、LanManager などのクライアントがあります。また、ブラウジングプロトコルにも加わり Windows のマイネットワーク、ネットワークコンピュータなどの表示にも現れます。サーバが NMB 通信を待機するデフォルトのポートは UDP ポート 137 です。
nmbd デーモンは smb サービスに制御されます。
winbindd
winbind サービスは、 Windows NT、 2000 サーバー又はウィンドウズサーバー 2003 上のユーザーとグループ情報を解決します。これによりユーザーとグループ情報を UNIX プラットフォームで理解できるようにします。これは、 Microsoft RPC コール、 Pluggable Authentication Modules (PAM)、Name Service Switch (NSS) を使用して行なわれます。これにより、Windows NT ドメインのユーザーが UNIX マシン上で UNIX ユーザーとして操作することが可能になります。 Samba ディストリビューションにバンドルされていますが、 winbind サービスは smb サービスとは別に制御されます。
winbindd デーモンは、 winbind サービスに制御されるので、動作するのに smb サービスを開始する必要はありません。 Winbindd は、 Samba がアクティブディレクトリメンバーである場合も使用され、 Samba ドメインコントローラ上でも使用されるかもしれません (ネストされたグループ及び/又はドメイン間の信頼関係を実装するため) 。 winbind はクライアント側のサービスであり、 Windows NT ベースのサーバに接続するのに使用されるからです。 winbind に関する詳細はこのガイドの範疇を越えますのでここには記しません。
注記
Samba ディストリビューションに含まれているユーティリティのリストに関しては、 項8.11. 「Samba ディストリビューションプログラム」 を参照してください。
ネットワーク上の使用可能な Samba 共有を表示するのに Nautilus を使用することができます。 Places (パネル上の) => ネットワークサーバー を選択して、ネットワーク上の Samba ワークグループのリストを見ます。Nautilusの ファイル => 場所を開く バーで、 smb: とタイプして、ワークグループを見ることもできます。
図 8.1. 「Nautilus の SMB ワークグループ」 に見られるように、ネットワーク上の利用可能な SMB ワークグループそれぞれにアイコンが表示されます。
ワークグループ内のコンピュータのリストを表示するには、ワークグループアイコンの１つをダブルクリックします。
図 8.2. 「Nautilus の SMB ワークグループ」 から見えるように、ワークグループ内にそれぞれのマシンのアイコンがあります。マシン上の Samba 共有を見るには、アイコンをダブルクリックしてください。もしユーザー名とパスワードの組み合わせが必要な場合は、その入力を促されます。
代わりに、 Nautilus の 場所: バーで、以下の構文を使用して (<servername> and <sharename> を適切な値で置き換える) 、 Samba サーバーや共有名を指定することもできます。
smb://<servername>/<sharename>
Samba サーバーをネットワークで検索するには、 findsmb コマンドを使用してください。見つかったそれぞれのサーバーは、 IP アドレス、 NetBIOS 名、ワークグループ名、オペレーティングシステム、および SMB サーバーのバージョンを表示します。
シェルプロンプトから Samba 共有に接続するには、以下のコマンドをタイプします。
smbclient //<hostname>/<sharename> -U <username>
<hostname> を接続したい Samba サーバーのホスト名、もしくは IP アドレスとリプレイスし、 <sharename> をブラウズしたい共有ディレクトリ名とリプレイスし、 <username> をシステムの Samba ユーザー名とリプレイスしてください。正しいパスワードを入力するか、そのユーザーにパスワードが要求されなかったら、 press Enter を押してください。
smb:\> が見えたら、ログインに成功しています。一旦ログインしたら、コマンドのリストを見るのに help とタイプしてください。もしホームディレクトリのコンテンツをブラウズしたい場合は、 sharename をユーザー名とリプレイスしてください。もし、 -U スイッチが使用されなかったら、現在のユーザーのユーザー名は、 Samba サーバーに渡されます。
smbclient を終了するには、 smb:\> プロンプトで exit とタイプしてください。
時には、 Samba 共有をディレクトリにマウントすることが有効です。そうすることにより、ディレクトリ内のファイルがあたかもローカルファイルシステムの一部であるかのように扱われます。
Samba 共有をディレクトリにマウントするには、 (もし存在しなかったら) それをマウントするディレクトリを作成し、以下のコマンドを root で実行してください:
mount -t cifs -o <username>,<password> //<servername>/<sharename>/mnt/point/
このコマンドは、ローカルディレクトリ /mnt/point/ で、 <servername> から <sharename> をマウントします。 Samba 共有の更なる情報については、 man mount.cifs をご参照ください。
デフォルトの設定ファイル (/etc/samba/smb.conf) では、ユーザーにそのホームディレクトリを Samba 共有として見せることを許可します。それはまた、システムのために設定された全てのプリンタを Samba 共有のプリンタとして共有します。言い換えると、プリンタをそのシステムに接続でき、ネットワーク上の Windows マシンからプリントができます。
グラフィックなインターフェースを使用して Samba を設定するには、 Samba サーバ設定ツール を使用します。コマンドラインの設定をするには、 項8.4.2. 「コマンドラインの設定」 にスキップしてください。
Samba サーバ設定ツール は、 Samba 共有、ユーザー、および基本的なサーバー設定を管理するグラフィカルインターフェースです。これは、 /etc/samba/ ディレクトリ内の設定ファイルを変更します。アプリケーションを使用されずになされたこれらのファイルへのいかなる変更も保存されます。
このアプリケーションを使用するには、 X Window System を起動し、 root 権限を持ち、さらに system-config-samba RPM パッケージをインストールしなければなりません。デスクトップから Samba サーバ設定ツール を起動するには、システム (パネル上) => Administration => サーバー設定 => Samba に行くか、シェルプロンプトでコマンド system-config-samba をタイプしてください (例えば、 XTerm や GNOME)。
注記
Samba サーバ設定ツール は、共有プリンタや Samba サーバー上でユーザーが自分のホームディレクトリを見ることを可能にするデフォルトのスタンザを表示しません。
Samba サーバーを設定する最初のステップは、サーバーといくつかのセキュリティオプションの基本設定を設定することです。アプリケーションを開始させた後、プルダウンメニューから ユーザー設定 => サーバー設定 を選択してください。基本 タブは、 図 8.4. 「基本的なサーバーセッティングの設定」 で見えるように表示されます。
基本 タブでは、コンピュータの簡単な説明だけでなく、どのワークグループにそのコンピュータがいるべきかを指定します。それらは、 smb.conf の中の workgroup と server string オプションに対応します。
セキュリティ タブは以下のオプションを含んでいます。
-
認証モード — これは、
securityオプションに対応します。以下の認証のタイプから1つを選択してください。-
ADS — Samba サーバーは、 Active Directory Domain (ADS) レルム内で、ドメインメンバーとして動作します。このオプションでは、 Kerberos はサーバー上でインストールされ、設定されなければなりません。また、 Samba は、
samba-clientパッケージの一部であるnetユーティリティを使用して、 ADS レルムのメンバーにならなければなりません。詳細については、netman ページを参照してください。このオプションは Samba が ADS コントローラになるようには設定しません。 ケルベロス領域 フィールドで、 Kerberos サーバーのレルムを指定してください。注記
ケルベロス領域 フィールドは、
EXAMPLE.COMのように、すべて大文字で提供されなければなりません。ADS レルム内のドメインメンバーとしての Samba サーバーの使用は、
/etc/krb5.confファイルを含む Kerberos の適切な設定を前提とします。 -
ドメイン — Samba サーバーは、ユーザーを確認するのに、 Windows NT のプライマリまたはバックアップドメインコントローラに依存しています。サーバーは、ユーザー名とパスワードをそのコントローラーに渡し、返答を待ちます。 認証サーバー フィールドで、プライマリまたはバックアップドメインコントローラの NetBIOS 名を指定してください。
もしこれが選択されていれば、 暗合化パスワード オプションは、 はい に設定しなくてはなりません。
-
サーバー — Samba サーバーは、ユーザー名とパスワードの組み合わせを他の Samba サーバーに渡すことにより、それを確認しようとします。もしそれができなかったら、サーバーはユーザー認証モードを使用して確認しようとします。 認証サーバー で、その他の Samba サーバーの NetBIOS 名を指定してください。
-
共有 — Samba ユーザーは、 Samba サーバー毎にユーザー名とパスワードの組み合わせを入力する必要はありません。それらは、 Samba サーバーから特定の共有ディレクトリに接続しようとするまで、ユーザー名とパスワードは要求されません。
-
ユーザー — (デフォルト) Samba ユーザーは、 Samba サーバー毎に有効なユーザー名とパスワードを提供しなければなりません。 Windows ユーザー名 オプションを機能させる場合は、このオプションを選択してください。詳細については、 項8.4.1.2. 「Samba ユーザーの管理」 をご参照ください。
-
-
暗合化パスワード — もしクライアントが Windows 98、Windows NT 4.0 Service Pack 3、もしくは他の Microsoft Windows のより最近のバージョンのシステムから接続している場合、このオプションを有効にしなければなりません。パスワードが傍受可能なプレーンテキストの代わりに暗合化されたフォーマットでサーバーとクライアント間に転送されます。これは、
encrypted passwordsオプションに対応します。暗合化された Samba パスワードについての多くの情報については、 項8.4.3. 「暗合化されたパスワード」 をご参照ください。 -
ゲストアカウント — ユーザー、またはゲストユーザーが Samba サーバーにログインするとき、サーバー上の有効なユーザーとマップされなければなりません。ゲスト Samba アカウントになるには、システム上の存在するユーザー名の１つを選択してください。ゲストが Samba サーバーにログインするとき、このユーザーと同じ権限を持っています。これは、
guest accountオプションに対応します。
OK をクリックした後、変更は設定ファイルに書き込まれてデーモンは再起動します。従って、変更は即座に反映されます。
Samba サーバ設定ツール は、 Samba ユーザーが追加される前に、 Samba サーバーとして動作するシステム上で既存のユーザーアカウントがアクティブであることを要求します。その Samba ユーザーは既存のユーザーアカウントと結びついています。
Samba ユーザーを追加するには、プルダウンメニューから ユーザー設定 => Samba ユーザー を選択して、 ユーザーの追加 ボタンをクリックしてください。 新規の Samba ユーザーを作成 ウィンドウで、ローカルシステム上の既存のユーザーのリストから Unix ユーザー名 を選択してください。
もしユーザーが Windows マシン上で違うユーザー名を持っていて、その Windows マシンから Samba サーバーにログインする必要がある場合、 Windows ユーザー名 フィールドで Windows ユーザー名を指定してください。 サーバー設定 設定の セキュリティ タブ上の 認証モード を、このオプションを機能させるために ユーザー と設定しなければなりません。
また、 Samba ユーザーのために Samba のパスワード を設定し、もう一度それをタイプして確認してください。たとえ Samba で暗合化されたパスワードを使用することを選んだとしても、全てのユーザーの Samba パスワードは、それらのシステムパスワードとは違く設定することが推奨されています。
既存のユーザーを編集するには、リストからユーザーを選択し、 ユーザーの編集 をクリックしてください。既存の Samba ユーザーを削除するには、ユーザーを選択し、 ユーザーの削除 ボタンをクリックしてください。 Samba ユーザーの削除は、関連するシステムユーザーアカウントを削除しません。
OK ボタンをクリックするとすぐに、ユーザーは変更されます。
Samba シェアを作成するには、メイン Samba 設定ウィンドウから 追加 ボタンをクリックしてください。
基本 タブは以下のオプションを設定します。
-
ディレクトリ — Samba を通じて共有するディレクトリ。ここで入力される前にディレクトリは存在しなければなりません。
-
共有名 — リモートマシンから見える実際の共有名。デフォルトでは、 ディレクトリ と同じ値ですが、設定可能です。
-
記述 — シェアの簡単な説明。
-
読み込み／書き込み — ユーザーが共有ディレクトリで読み込み、書き込みすることを可能にします。
-
読み込み専用 — 共有ディレクトリのためにユーザーに読み取り専用の権限を与える。
アクセス タブでは、特定のユーザーだけ共有にアクセスするか、全ての Samba ユーザーが共有にアクセスするかを選択してください。もし特定のユーザーだけにアクセスを許可することを選択したら、利用可能な Samba ユーザーのリストからユーザーを選択してください。
OK をクリックするとすぐにシェアは追加されます。
Samba は、 /etc/samba/smb.conf をその設定ファイルとして使用します。もしこの設定ファイルを変更したら、 Samba デーモンをコマンド service smb restart で再起動するまでその変更は有効になりません。
Windows ワークグループや Samba サーバーの簡単な説明を指定するには、 smb.onf ファイルで以下の行を編集してください。
workgroup =WORKGROUPNAMEserver string =BRIEF COMMENT ABOUT SERVER
WORKGROUPNAME をこのマシンが属する Windows ワークグループ名とリプレイスしてください。 BRIEF COMMENT ABOUT SERVER はオプションで、 Samba システムについての Windows のコメントとして使用されます。
Linux システムで Samba 共有ディレクトリを作成するには、以下のセクションを smb.conf ファイルに加えてください (自分の要求とシステムを変更しそれに反映させた後)。
[sharename] comment =Insert a comment herepath =/home/share/valid users =tfox carolepublic = no writable = yes printable = no create mask = 0765
上記の例では、ユーザーに Samba クライアントから、 Samba サーバー上のディレクトリ /home/share の読み書きを許可しています。
Samba サーバを開始するには、root でログインしてシェルプロンプトで次のコマンドを入力します。
/sbin/service smb start
重要
ドメインメンバーサーバをセットアップするには、まず、net join コマンドを使ってそのドメインまたは Active Directory に参加してからsmb サービスを開始します。
サーバを停止するには、root でログインしてシェルプロンプトに次のコマンドを入力します。
/sbin/service smb stop
restart オプションは Samba を停止してから開始するのに便利です。Samba の設定ファイルを編集してからその設定変更を有効にする最も確実な方法です。再起動オプションはもともと動作していなかったデーモンも起動するので注意してください。
サーバを再起動するには、root でログインしてシェルプロンプトに次のコマンドを入力します。
/sbin/service smb restart
condrestart (条件付き再起動)オプションは、smb が現在実行中である場合のみそれを再起動します。このオプションは、作動していなければデーモンを起動しないのでスクリプトに役立ちます。
注記
smb.conf ファイルが変更されると、 Samba は数分後、自動的に再ロードします。手動で restart や reload を発行するのも同様に有効です。
条件付きでサーバを再起動するには、root で次のコマンドを入力します。
/sbin/service smb condrestart
smb.conf ファイルの手動による再ロードは、smb サービスが自動再ロードに失敗した場合に役に立ちます。サービスを再起動せずに Samba サーバ設定ファイルが たしかに再ロードされたか確認するには、root で次のコマンドを入力します。
/sbin/service smb reload
デフォルトでは、 smb サービスはブート時に自動的には 開始しません 。 Samba がブート時に開始するよう設定するには、 /sbin/chkconfig 、 /usr/sbin/ntsysv 、 サービス設定ツール プログラムなどの initscript ユーティリティを使用します。これらのツールの詳細に関しては 章 5. サービスへのアクセスの制御 を参照してください。
Samba の設定はシンプルです。Samba に対する変更はすべて /etc/samba/smb.conf 設定ファイル内で行われます。デフォルトの smb.conf ファイルは適切に記述されていますが、LDAP、Active Directory、数多くのドメインコントローラの実装などの複雑なトピックは対処していません。
次のセクションでは Samba サーバのさまざまな設定方法について解説しています。ニーズを把握し、正しく設定するために smb.conf ファイルに必要とされる変更に留意してください。
スタンドアローンのサーバーはワークグループサーバーでもワークグループ環境のメンバーでも構いません。スタンドアローンサーバーはドメインコントローラではなく、ドメインに参加するわけでもありません。次の例は anonymous 共有レベルのセキュリティ設定と単一ユーザーレベルのセキュリティ設定をいくつか示しています。共有レベル及びユーザーレベルのセキュリティモードについての詳細は、 項8.7. 「Samba のセキュリティモード」 を参照してください。
次の smb.conf ファイルは anonymous 読み取り専用ファイルの共有の実装に必要な設定の例です。 security = share パラメータで共有が anonymous になります。単一の Samba サーバのセキュリティレベルは混在できないので注意してください。security ディレクティブは smb.conf ファイルの [global] 設定セクションにあるグローバル Samba パラメータです。
[global] workgroup = DOCS netbios name = DOCS_SRV security = share [data] comment = Documentation Samba Server path = /export read only = Yes guest only = Yes
次の smb.conf ファイルは anonymous 読み取り/書き込みファイルの共有を実装するのに必要な設定の例です。anonymous 読み取り/書き込みファイルの共有を有効にするには、read only ディレクティブを no に設定します。また、force user と force group ディレクティブが追加されおり、 共有内で新規に配置されるファイルの所有権を強制指定しています。
注記
サーバを anonymous 読み取り/書き込みにすることはできますがお勧めしません。共有スペースに置かれるファイルはすべて、ユーザーに関係なく smb.conf ファイル内の汎用ユーザ (force user) とグループ (force group) で指定されているユーザー/グループの組合わせが割り当てられます。
[global] workgroup = DOCS netbios name = DOCS_SRV security = share [data] comment = Data path = /export force user = docsbot force group = users read only = No guest ok = Yes
次の smb.conf ファイルは anonymous プリントサーバの実装に必要な設定の例です。設定例のbrowsable を no にすると Windows のマイネットワーク(または、ネットワークコンピュータなど)にあるプリンタの一覧を表示しなくなります。ブラウジングからは隠されますが、プリンタを明示的に設定することはできます。NetBIOS を使って DOCS_SRV に接続すると、クライアントも DOCS ワークグループの一部であればそのクライアントはプリンタにアクセスすることができます。また、use client driver ディレクティブが Yes に設定され、クライアントが正しいローカルプリンタドライバをインストールしていると仮定しています。この場合、Samba サーバはクライアントに対する 共有プリンタドライバの役割は果たしません。
[global] workgroup = DOCS netbios name = DOCS_SRV security = share printcap name = cups disable spools= Yes show add printer wizard = No printing = cups [printers] comment = All Printers path = /var/spool/samba guest ok = Yes printable = Yes use client driver = Yes browseable = Yes
次の smb.conf ファイルは安全な読み取り/書き込みプリントサーバの実装に必要な設定の例です。security ディレクティブを user に設定することで Samba がクライアント接続を認証するよう強制します。[homes]共有にはforce user や force group ディレクティブがなく、[public] 共有にはこれらのディレクティブがあるのがわかります。[homes] 共有は [public] のforce user と force group に対立するすべての新規ファイルに認証ユーザーの情報を使用します。
[global] workgroup = DOCS netbios name = DOCS_SRV security = user printcap name = cups disable spools = Yes show add printer wizard = No printing = cups [homes] comment = Home Directories valid users = %S read only = No browseable = No [public] comment = Data path = /export force user = docsbot force group = users guest ok = Yes [printers] comment = All Printers path = /var/spool/samba printer admin = john, ed, @admins create mask = 0600 guest ok = Yes printable = Yes use client driver = Yes browseable = Yes
スタンドアローンサーバに似ていますが、ドメインメンバーはドメインコントローラ(Windows または Samba のどちらか)にログインされ、ドメインのセキュリティルールに従います。ドメインメンバーサーバの例としては、Samba を実行している部門別サーバでプライマリドメインコントローラ (PDC) にマシンアカウント持つものでしょう。その部門のクライアントすべてはまだ PDC で認証しているので、デスクトッププロファイルやすべてのネットワークポリシーファイルが含まれています。違いは部門別サーバはプリンタとネットワーク共有の制御機能があるということです。
次の smb.conf ファイルは Active Directory ドメインメンバーサーバの実装に必要な設定の例です。この例では、Samba はローカルに実行されているサービスに対してユーザーを認証するだけでなく、Active Directory のクライアントも認証します。ご使用の kerberos realm パラメータがすべて大文字で表示されていることを確認します(例、realm = EXAMPLE.COM)。Windows 2000/2003 は Active Directory 認証に Kerberos が必要となるので、realm ディレクティブが必要です。Active Directory と Kerberos が異なるサーバで実行している場合は、区別できるよう password server ディレクティブが必要になる場合があります。
[global] realm = EXAMPLE.COM security = ADS encrypt passwords = yes # Optional. Use only if Samba cannot determine the Kerberos server automatically. password server = kerberos.example.com
メンバーサーバを Active Directory ドメインに参加させるためには、次の手順にしたがってください。
-
メンバーサーバにある
smb.confファイルの設定 -
メンバーサーバにある
/etc/krb5.confファイルを含む Kerberos の設定 -
Active Directory ドメインサーバにあるマシンアカウントの作成
-
メンバーサーバの Active Directory ドメインへの関連付け
マシンアカウントを作成して Windows 2000/2003 Active Directory に参加するには、まず、メンバーサーバが Active Directory ドメインに参加要請するよう Kerberos を初期化する必要があります。管理 Kerberos チケットを作成するには、root としてメンバーサーバ上で次のコマンドを入力します。
kinit administrator@EXAMPLE.COM
Active Directory サーバ (windows1.example.com) に参加するには、メンバーサーバで root として次のコマンドを入力します。
net ads join -S windows1.example.com -U administrator%password
マシン windows1 は自動的に該当 Kerberos で見つかったので (kinit コマンドの成功)、net コマンドが必要される管理者アカウントとパスワードを使って Active Directory に接続します。これにより Active Directory 上に適切なマシンアカウントが作成され、Samba ドメインメンバーサーバがそのドメインに参加する許可を与えます。
注記
security = ads が使用され security = user は使用されていないため、smbpasswd などのローカルなパスワードバックエンドは必要ありません。security = adsをサポートしていない旧式のクライアントは security = domain が設定されているように認証されます。この変更は機能に影響せず、ドメインにいなかったローカルユーザーを許可します。
次の smb.conf ファイルは Windows NT4 ベースのドメインメンバーサーバの実装に必要な設定の例です。NT4 ベースのドメインのメンバーサーバになるというのは、Active Directory に接続するのに似ています。主な違いは NT4 ベースのドメインはその認証方法に Kerberos を使用しないことです。このため、smb.conf ファイルは簡潔になります。この例では、Samba メンバーサーバは NT4 ベースのドメインサーバへ通じるパスの役割を果たします。
[global] workgroup = DOCS netbios name = DOCS_SRV security = domain [homes] comment = Home Directories valid users = %S read only = No browseable = No [public] comment = Data path = /export force user = docsbot force group = users guest ok = Yes
Samba をドメインメンバーサーバにするとさまざまな状況で役に立ちます。 Samba サーバはファイルやプリンタ共有の他にも別な用途で使用できる機会があります。ドメイン環境で Linux のみ対応のアプリケーションを使用する必要がある場合などに Samba をドメインメンバーサーバにすると便利なことがあります。管理者は Windows ベースではなくてもドメイン内のマシンすべてを追跡しておく 傾向にあります。Windows ベースのサーバハードウェアが廃止になった場合、smb.conf ファイルを変更してサーバを Samba ベースの PDC に非常に簡単に転向することができます。Windows NT ベースのサーバが Windows 2000/2003 にアップグレードされる場合、必要であれば Active Directory へのインフラストラクチャ変更を統合するのにsmb.conf ファイルを簡単に変更することができます。
重要
smb.conf ファイルを設定したら、ドメインに参加し、その後、次のコマンドを root で入力して Samba を起動します。
net rpc join -U administrator%password
ドメインサーバのホスト名を指定する -S オプションは net rpc join コマンドに指定する必要はありませんので注意してください。Samba は smb.conf ファイルにある workgroup ディレクティブで指定されるホスト名を使用するので明示的には記述しません。
Windows NT のドメインコントローラは機能的に Linux 環境の Network Information Service (NIS) サーバに似ています。ドメインコントローラと NIS サーバはいずれもユーザー/グループ情報のデータベース及び関連サービスをホストします。ドメインコントローラは主にユーザーのドメインリソースへのアクセス認証などセキュリティの目的で使用されます。ユーザー/グループデータベースの整合性を管理するサービスは Security Account Manager (SAM) と呼ばれています。SAM データベースは Windows と Linux Samba ベースのシステムでは保管が異なるため、SAM の複製は作成できず、PDC/BDC 環境でプラットフォームは混在できません。
Samba 環境では、PDC は 1 台のみ、BDC はいくつでも置くことができます。
重要
Samba は Samba/Windows 混在のドメインコントローラ環境では存在できません(Samba は Windows PDC の BDC にはなれず、その逆もできません)。これに対し、Samba PDC と BDC は共存することができます。
最も簡単で一般的な Samba PDC の実装は tdbsam パスワードデータベースのバックエンドを使用します。古い smbpasswd バックエンドをリプレイスする予定があるなら、tdbsam は数多くの改良が加えられていますので、詳細は項8.8. 「Samba のアカウント情報データベース」 をご覧ください。passdb backend ディレクティブは PDC にどのバックエンドを使用するかを管理します。
[global]
workgroup = DOCS
netbios name = DOCS_SRV
passdb backend = tdbsam
security = user
add user script = /usr/sbin/useradd -m %u
delete user script = /usr/sbin/userdel -r %u
add group script = /usr/sbin/groupadd %g
delete group script = /usr/sbin/groupdel %g
add user to group script = /usr/sbin/usermod -G %g %u
add machine script = /usr/sbin/useradd -s /bin/false -d /dev/null -g machines %u
# The following specifies the default logon script
# Per user logon scripts can be specified in the user
# account using pdbedit logon script = logon.bat
# This sets the default profile path.
# Set per user paths with pdbedit
logon drive = H:
domain logons = Yes
os level = 35
preferred master = Yes
domain master = Yes
[homes]
comment = Home Directories
valid users = %S
read only = No
[netlogon]
comment = Network Logon Service
path = /var/lib/samba/netlogon/scripts
browseable = No
read only = No
# For profiles to work, create a user directory under the
# path shown. mkdir -p /var/lib/samba/profiles/john
[Profiles]
comment = Roaming Profile Share
path = /var/lib/samba/profiles
read only = No
browseable = No
guest ok = Yes
profile acls = Yes
# Other resource shares ... ...
注記
ドメインコントローラが複数台またはユーザー数が250以上必要な場合、tdbsam 認証バックエンドは使用しないでください。このような場合は LDAP をお勧めします。
Samba のセキュリティモードは共有レベル と ユーザーレベルの 2 種類のみで、まとめてセキュリティレベルと呼ばれています。共有レベルセキュリティの実装方法は 1 つだけですが、ユーザーレベルセキュリティは 4 種類の実装方法から選ぶことができます。セキュリティレベルの異なる実装方法はセキュリティモードと呼ばれます。
ユーザーレベルセキュリティは Samba のデフォルト設定です。security = user ディレクティブが smb.conf ファイルに一覧表示されていなくても、Samba はこれを使用します。サーバがクライアントのユーザー名/パスワードを受け取ると、クライアントは各インスタンスのパスワードを指定しなくても複数の共有をマウントすることができます。また、Samba はセッションベースのユーザー名/パスワード要求を受け取ることができます。クライアントは各ログオンに固有の UID を使って複数の認証を管理します。
smb.conf 内のユーザーレベルセキュリティを設定する security = user ディレクティブは次のようになっています。
[GLOBAL] ... security = user ...
次のセクションでは、ユーザーレベルセキュリティのその他の実装について説明します。
ドメインセキュリティモードでは、Samba サーバはマシンアカウント(ドメインセキュリティトラストアカウント)を持つので、すべての認証要求がドメインコントローラを通過するようになっています。Samba サーバはsmb.conf で次のディレクティブを使ってドメインメンバーサーバに構築されます。
[GLOBAL] ... security = domain workgroup = MARKETING ...
Active Directory 環境の場合、ネイティブの Active Directory メンバーとしてそのドメインに参加することができます。セキュリティポリシーが NT 互換の認証プロトコルの使用を制限するものであっても、Samba サーバは Kerberos を使って ADS に参加することができます。
smb.conf にある次のディレクティブで Samba を Active Directory メンバーサーバにします。
[GLOBAL] ... security = ADS realm = EXAMPLE.COM password server = kerberos.example.com ...
Samba 最新のリリースでは多くの新機能が提供されており、以前はなかったパスワードデータベースのバックエンドなどがあります。Samba バージョン 3.0.0 は Samba の旧バージョンで使用されていたすべてのデータベースをサポートします。ただし、サポートされていますが多くのバックエンドは実稼働環境での使用には向いていないことがあります。
以下は、 Samba と使用できる異なるバックエンドのリストです。ここでリストにないその他のバックエンドも利用可能かもしれません。
- プレーンテキスト
-
プレーンテキストのバックエンドは
/etc/passwdタイプのバックエンドと変わりありません。プレーンテキストのバックエンドを使用すると、すべてのユーザー名とパスワードはクライアントと Samba サーバ間を暗号化されずに送信されます。この方法は非常に危険なのでまったくお勧めできません。プレーンテキストのパスワードを使って異なる Windows クライアントが Samba サーバへ接続するとこのような認証方法をサポートできない可能性があります。 -
smbpasswd -
以前の Samba パッケージで使用されている一般的なバックエンド、
smbpasswdバックエンドは MS Windows LanMan と NT アカウントを含むプレーン ASCII テキストレイアウト及び暗号化パスワード情報を利用しています。smbpasswdバックエンドには Windows NT/2000/2003 SAM 拡張制御が不足しています。smbpasswdバックエンドは NT ベースのグループの RID など Windows 情報をうまく処理または保持しませんのでお勧めしません。tdbsamバックエンドは小規模のデータベース(ユーザー数 250)での使用におけるこうした問題を解決しますが、大規模な企業クラスのソリューションにはまだなり得ません。 -
ldapsam_compat -
ldapsam_compatバックエンドではアップグレードした Samba バージョンを使った使用に継続した OpenLDAP サポートが可能になります。このオプションは Samba 3.0 にマイグレートするときに通常は使用されます。 -
tdbsam -
tdbsamバックエンドは、ビルトインのデータベースの複製を必要としないサーバ、LDAP のスケーラビリティや複雑性が不要なサーバなどのローカルサーバに理想的なデータベースバックエンドを提供します。tdbsamバックエンドにはすべてのsmbpasswdデータベース情報の他に以前に拡張された SAM 情報も入っています。拡張 SAM データを含ませることにより Samba が Windows NT/2000/2003 ベースのシステムを使って見られるような同じアカウントとシステムアクセスのコントロールを実行できるようになります。tdbsamバックエンドは最高 250 までのユーザー数にお勧めします。これより規模が大きい場合は Active Directory か LDAP の統合がスケーラビリティとネットワークインフラストラクチャ関連のため必要となるでしょう。 -
ldapsam -
ldapsamバックエンドでは Samba 用の最適分散アカウントインストール法を提供します。LDAP はそのデータベースを OpenLDAPslurpdデーモンを使って複数台のサーバに複製する機能があるため最適です。LDAP データベースは軽量でスケーラブル、ほとんどの企業に申し分なく、特に大企業向けです。もし以前のバージョンから Samba 3.0 にアップグレードする場合は、
/usr/share/doc/samba-が変更になっていることに注意してください。このファイルは、<version>/LDAP/samba.schemaldapsamバックエンドが適切に機能するのに必要な attribute syntax definitions や objectclass definitions を含みます。そのように、 Samba サーバーのために
ldapsamを使用する場合は、このスキーマファイルを含めてslapdを設定する必要があります。この設定方法については、 項13.5. 「/etc/openldap/schema/ディレクトリ」 を参照してください。注記
もし
ldapsamバックエンドを使用したい場合は、openldap-serverパッケージをインストールする必要があります。 -
mysqlsam -
mysqlsamバックエンドは MySQL ベースのデータベースバックエンドを使用します。これは、すでに MySQL を実装しているサイトで役立ちます。現在では、mysqlsamは Samna から分離されたモジュールに含まれているので、 Samba によりオフィシャルにサポートされていません。
ネットワークブラウジングにより、 Windows と Samba サーバを Windows Network Neighborhood で表示を可能にします。 Network Neighborhood 内で、アイコンがサーバとして表され、アイコンを開くと利用できるサーバの共有とプリンタが表示されます。
ネットワークブラウジング機能には TCP/IP を介した NetBIOS が必要です。NetBIOS ベースのネットワーキングはブロードキャスト (UDP) メッセージングを使用してブラウズリスト管理を行います。TCP/IP ホスト名解決のプライマリメソッドとして NetBIOS and WINS が無い場合は、静的ファイル (/etc/hosts) や DNS など他の方法を使用しなければなりません。
ドメインマスターブラウザはすべてのサブネット上のローカルマスターブラウザから閲覧リストを照合しますので、ブラウジングがワークグループとサブネット間で発生することができます。また、ドメインマスターブラウザは自身のサブネットのローカルマスターブラウザになるでしょう。
デフォルトでは、ドメインの Windows PDC もそのドメインのドメインマスターブラウザです。このような場合、 Samba サーバはドメインマスターサーバとして設定する必要があります。
Windows NT PDC を含まないサブネットに関しては、 Samba サーバをローカルマスターブラウザとして実装できます。ドメインコントローラ環境でのローカルマスターブラウザの smb.conf 設定(または全くブラウズしない)はワークグループの設定と同じです。
Samba サーバまたは Windows NT サーバのどちらかが WINS サーバとして機能することができます。WINS を NetBIOS 有効にして使用すると UDP ユニキャストを送信することができ、ネットワーク全体にわたって名前解決が可能になります。WINS サーバがないと、UDP ブロードキャストはローカルサブネットに限られ、他のサブネットやワークグループ、ドメインに送信できなくなります。WINS レプリケーションが必要な場合は、プライマリ WINS サーバとして Samba を使用しないでください。Samb は現在 WINS レプリケーションをサポートしていません。
NT/2000/2003 サーバと Samba の混在する環境では、Microsoft WINS 機能を使用することをおすすめします。Samba のみの環境なら WINS には Samba サーバの使用は 1 台のみにすることをお勧めします。
次の例では、Samba サーバが WINS サーバとして動作している smb.conf ファイルを示します。
[global] wins support = Yes
ヒント
すべてのサーバ (Samba も含めて)は WINS サーバに接続して NetBIOS 名を解決する必要があります。 WINS なしではブラウジングはローカルサブネットのみなります。また、ドメイン全体の一覧を何からの形で取得しても、 WINS なしではホストはクライアントを解決することはできません。
Samba ではクライアントマシンが Samba サーバに接続されているプリンタを共有できるようにする他に、Linux ドキュメントを Windows プリンタ共有に送信することもできます。Red Hat Enterprise Linux で機能する印刷システムは他にもありますが、Samba と密接な統合をするため 印刷システムには CUPS (Common UNIX Print System) をお勧めします。
次の例では非常に基本的な CUPS サポートの smb.conf の設定を示します。
[global] load printers = Yes printing = cups printcap name = cups [printers] comment = All Printers path = /var/spool/samba/print printer = IBMInfoP browseable = No public = Yes guest ok = Yes writable = No printable = Yes printer admin = @ntadmins [print$] comment = Printer Drivers Share path = /var/lib/samba/drivers write list = ed, john printer admin = ed, john
その他の印刷設定も可能です。機密ドキュメントの印刷にセキュリティとプライバシーを補強するには、ユーザーはパブリックパスにはない自分のプリントスプーラを持つことができます。ジョブが失敗した場合、他のユーザーはそのファイルにアクセスできません。
print$ 共有には、プリンタドライバがローカルにない場合にクライアントがアクセスするプリンタドライバを含んでいます。print$ 共有はオプションですので企業によっては必要としないこともあります。
browseable を Yes にすると、プリンタが Windows のマイネットワーク(またはネットワークコンピュータ)で表示できるようになり、ドメイン/ワークグループで Samba サーバが正しく設定されるようになります。
findsmb
findsmb
<subnet_broadcast_address>
findsmb プログラムは Perl スクリプトです。特定のサブネットで SMB 認識システムに関する情報を報告します。サブネットが指定されていないとローカルサブネットが使用されます。表示アイテムには IP アドレス、NetBIOS 名、ワークグループまたはドメイン名、オペレーティングシステム、バージョンなどがあります。
次の例ではシステムで有効なユーザーとして findsmbを実行したときの出力を示します。
findsmb
IP ADDR NETBIOS NAME WORKGROUP/OS/VERSION
------------------------------------------------------------------
10.1.59.25 VERVE [MYGROUP] [Unix] [Samba 3.0.0-15]
10.1.59.26 STATION22 [MYGROUP] [Unix] [Samba 3.0.2-7.FC1]
10.1.56.45 TREK +[WORKGROUP] [Windows 5.0] [Windows 2000 LAN Manager]
10.1.57.94 PIXEL [MYGROUP] [Unix] [Samba 3.0.0-15]
10.1.57.137 MOBILE001 [WORKGROUP] [Windows 5.0] [Windows 2000 LAN Manager]
10.1.57.141 JAWS +[KWIKIMART] [Unix] [Samba 2.2.7a-security-rollup-fix]
10.1.56.159 FRED +[MYGROUP] [Unix] [Samba 3.0.0-14.3E]
10.1.59.192 LEGION *[MYGROUP] [Unix] [Samba 2.2.7-security-rollup-fix]
10.1.56.205 NANCYN +[MYGROUP] [Unix] [Samba 2.2.7a-security-rollup-fix]
net
net
<protocol> <function> <misc_options> <target_options>
net ユーティリティは、Windows や MS-DOS に使用される net ユーティリティに似ています。1 番目の引数はコマンド実行中に使用するプロトコルを指定します。<protocol>ads、rap、rpc のいずれかをとることができます。Active Directory には ads、Win9x/NT3 は rap、Windows NT4/2000/2003 は rpc を使用します。プロトコルを省略すると、net は自動的に検索を開始します。
次の例ではホスト名 wakko の利用可能な共有の一覧を表示しています。
net -l share -S wakko
Password:
Enumerating shared resources (exports) on remote server:
Share name Type Description
---------- ---- -----------
data Disk Wakko data share
tmp Disk Wakko tmp share
IPC$ IPC IPC Service (Samba Server)
ADMIN$ IPC IPC Service (Samba Server)
次の例ではホスト名 wakko の Samba ユーザー一覧を表示しています。
net -l user -S wakko
root password:
User name Comment
-----------------------------
andriusb Documentation
joe Marketing
lisa Sales
nmblookup
nmblookup
<options> <netbios_name>
nmblookup プログラムは NetBIOS 名を IP アドレスに解決します。プログラムは目的のマシンが応答するまでローカルサブネットでそのクエリをブロードキャストします。
次がその例です。
nmblookup trek
querying trek on 10.1.59.255
10.1.56.45 trek<00>
pdbedit
pdbedit プログラムは SAM データベースにあるアカウントを管理します。smbpasswd、LDAP、NIS+、tdb データベースライブラリなどすべてのバックエンドをサポートします。
次にユーザーの追加、削除、一覧表示の例を示します。
pdbedit -a kristinnew password: retype new password: Unix username: kristin NT username: Account Flags: [U ] User SID: S-1-5-21-1210235352-3804200048-1474496110-2012 Primary Group SID: S-1-5-21-1210235352-3804200048-1474496110-2077 Full Name: Home Directory: \\wakko\kristin HomeDir Drive: Logon Script: Profile Path: \\wakko\kristin\profile Domain: WAKKO Account desc: Workstations: Munged dial: Logon time: 0 Logoff time: Mon, 18 Jan 2038 22:14:07 GMT Kickoff time: Mon, 18 Jan 2038 22:14:07 GMT Password last set: Thu, 29 Jan 2004 08:29:28 GMT Password can change: Thu, 29 Jan 2004 08:29:28 GMT Password must change: Mon, 18 Jan 2038 22:14:07 GMTpdbedit -v -L kristinUnix username: kristin NT username: Account Flags: [U ] User SID: S-1-5-21-1210235352-3804200048-1474496110-2012 Primary Group SID: S-1-5-21-1210235352-3804200048-1474496110-2077 Full Name: Home Directory: \\wakko\kristin HomeDir Drive: Logon Script: Profile Path: \\wakko\kristin\profile Domain: WAKKO Account desc: Workstations: Munged dial: Logon time: 0 Logoff time: Mon, 18 Jan 2038 22:14:07 GMT Kickoff time: Mon, 18 Jan 2038 22:14:07 GMT Password last set: Thu, 29 Jan 2004 08:29:28 GMT Password can change: Thu, 29 Jan 2004 08:29:28 GMT Password must change: Mon, 18 Jan 2038 22:14:07 GMTpdbedit -Landriusb:505: joe:503: lisa:504: kristin:506:pdbedit -x joepdbedit -Landriusb:505: lisa:504: kristin:506:
rpcclient
rpcclient プログラムは Microsoft RPC を使って管理コマンドを発行します。これにより、システム管理用の Windows 管理グラフィカルユーザーインターフェース (GUI) を提供します。複雑な Microsoft RPC を完全に理解しているアドバンスユーザーによって最も頻繁に使用されます。
smbcacls
smbcacls
<//server/share> <filename> <options>
smbcacls プログラムは Samba サーバで共有されているファイルやディレクトリに関する Windows ACL を変更します。
smbclient
smbclient
<//server/share> <password> <options>
smbclient プログラムは用途の広い UNIX クライアントで、ftp に似た機能を提供しています。
smbcontrol
smbcontrol
<options> <destination> <messagetype> <parameters>
smbcontrol プログラムは制御メッセージを実行中の smbd または nmbd デーモンに送ります。smbcontrol -i を実行すると空白行または 'q' が入力されるまでインテラクティブにコマンドを実行します。
smbpasswd
smbpasswd
<options> <username> <password>
smbpasswd プログラムは暗号化パスワードを管理します。このプログラムはスーパーユーザーで実行してすべてのユーザーのパスワードを変更できる他、普通のユーザーとして実行してそのユーザー自身の Samba パスワードを変更することもできます。
smbspool
smbspool
<job> <user> <title> <copies> <options> <filename>
smbspool プログラムは Samba に対する CUPS 互換の印刷インターフェースです。CUPS プリンタでの使用を目的としていますが、smbspool は CUPS プリンタ以外でも機能します。
smbstatus
smbstatus プログラムは Samba サーバへの現在の接続状態を表示します。
smbtar
smbtar プログラムは Windows ベースの共有ファイルやディレクトリのバックアップや復元をローカルテープアーカイブに行います。tar コマンドに似ていますが、この 2 つは互換性がありません。
testparm
testparm
<options> <filename> <hostname IP_address>
testparm プログラムは smb.conf ファイルの構文をチェックします。smb.conf ファイルがデフォルトの場所 (/etc/samba/smb.conf) にある場合は、その場所を指定する必要はありません。ホスト名と IP アドレスを testparm プログラムに指定すると、hosts.allow と host.deny ファイルが正しく設定されていることを検証します。また、testparm プログラムは チェックが終了すると smb.conf ファイルの概要とサーバの役割(スタンドアローン、ドメインなど)を表示します。デバッグするときにコメントを除外して簡潔に情報を表示するので経験のある管理者が読み取るのに便利です。
例、
testparmLoad smb config files from /etc/samba/smb.conf Processing section "[homes]" Processing section "[printers]" Processing section "[tmp]" Processing section "[html]" Loaded services file OK. Server role: ROLE_STANDALONE Press enter to see a dump of your service definitions<enter># Global parameters [global] workgroup = MYGROUP server string = Samba Server security = SHARE log file = /var/log/samba/%m.log max log size = 50 socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 dns proxy = No [homes] comment = Home Directories read only = No browseable = No [printers] comment = All Printers path = /var/spool/samba printable = Yes browseable = No [tmp] comment = Wakko tmp path = /tmp guest only = Yes [html] comment = Wakko www path = /var/www/html force user = andriusb force group = users read only = No guest only = Yes
wbinfo
wbinfo プログラムは winbindd デーモンからの情報を表示します。wbinfo が機能するために winbindd デーモンは実行されている必要があります。
次のセクションでは Samba をさらに詳しく学ぶための資料を示します。
-
/usr/share/doc/samba-<— Samba ディストリビューションにはすべての追加ファイルが含まれています。ここにすべての支援スクリプト、サンプル設定ファイル、ドキュメントなどが含まれています。version-number>/このディレクトリは、 The Official Samba-3 HOWTO-Collection や Samba-3 by Example のオンラインバージョンも含んでいて、両方共以下で述べられています。
-
The Official Samba-3 HOWTO-Collection John H. Terpstra、Jelmer R. Vernooij 共著 ; Prentice Hall — Samba 開発チームによって発行されている Samba-3 オフィシャルドキュメントです。ステップバイステップガイドに比べより詳しいリファレンスガイドになります。
-
Samba-3 by Example John H. Terpstra 著 ; Prentice Hall — Samba これも開発チームで発行されているオフィシャルリリースです。OpenLDAP、DNS、DHCP、印刷設定ファイルの詳細な事例を解説しています。実際の実装に役立つステップバイステップ関連の情報が記述されています。
-
Using Samba, 2nd Edition Jay T's、Robert Eckstein、David Collier-Brown 共著 ; O'Reilly — 初心者からアドバンスユーザーまで広く役立つ参考資料です。総合的なリファレンスが解説されています。
-
http://www.samba.org/ — Samba ディストリビューションのホームページです。Samba 開発チームによって作成されたすべてのオフィシャルドキュメントがあります。多くのリソースが HTML 及び PDF 形式で入手可能になっていますが、購入しないと利用できないものもあります。これらリンクの多くが Red Hat Enterprise Linux 固有ではありませんが、適用できるコンセプトもあります。
-
http://samba.org/samba/archives.html — Samba コミュニティのアクティブなメーリングリストの一覧があります。アクティビティがかなり活発なのでダイジェストモードを有効にすることをお勧めします。
-
Samba ニュースグループ — NNTP プロトコルを使用する gmane.org など Samba のスレッド式ニュースグループ も利用できます。メーリングリストで電子メールを受け取る代りになります。
-
http://samba.idealx.org/ — Idealx.org は Samba と OpenLDAP 統合のためのインストールと設定スクリプトを配信しています。LDAP 関連のリソースを管理する上で役立つので強くお勧めします。スクリプトは
/usr/share/doc/samba-にあります。また、Idealx ウェブサイトからダウンロードもできます。version_number/LDAP/smbldap-tools
DHCP （Dynamic Host Configuration Protocol） は、クライアントマシンに自動的に TCP/IP 情報を割り当てるネットワークプロトコルです。各 DHCP クライアントは、中央に配置された DHCP サーバーに接続し、このサーバーが IP アドレス、ゲートウェイ、 DNS サーバーなどクライアントのネットワーク設定情報 (IP アドレス、ゲートウェイ、 DNS サーバーを含む) を返します。
DHCP はクライアントのネットワークインターフェースを自動で設定するのに便利です。クライアントシステムを設定するとき DHCP を選択すれば、 IP アドレス、ネットマスク、ゲートウェイ、 DNS サーバーを入力する必要がありません。クライアントはこれらの情報を DHCP サーバーから受け取ります。また、管理者が多数のシステムの IP アドレスを変更する場合も DHCP は便利です。すべてのシステムの再設定を行う代わりに、サーバー上の DHCP 設定ファイルを編集することによって、新規の IP アドレスセットを設定できます。組織の DNS サーバーが変更された場合は、 DHCP クライアントで変更を行うのではなく、 DHCP サーバーで変更を行います。クライアントでネットワークが再起動 （またはクライアントがリブート） されると、変更が反映されます。
組織が、機能中の DHCP サーバーをネットワークに正しく接続している場合、ラップトップや他の携帯コンピュータの使用者はそのようなデバイスをオフィスからオフィスへと移動して使用できます。
DHCP サーバーを設定するには、 /etc/ ディレクトリ内に dhcpd.conf 設定ファイルを作成する必要があります。サンプルファイルは /usr/share/doc/dhcp-< で参照できます。
version>/dhcpd.conf.sample
また、 DHCP はファイル /var/lib/dhcpd/dhcpd.leases を使用してクライアントのリースデータベースを保存します。詳細については 項9.2.2. 「リースデータベース」 を参照してください。
The first step in configuring a DHCP server is to create the configuration file that stores the network information for the clients. Use this file to declare options and global options for client systems.
設定ファイルは、任意のタブや空白行を使用して書式をわかりやすく整えることができます。キーワードは大文字小文字の区別がなく、行頭がシャープ記号 (#) で始まる行はコメントとみなされます。
現在、2つの DNS 更新スキーム — ad-hoc DNS 更新モードと interim DHCP-DNS インタラクションドラフト更新 (Interaction Draft Update) モード: が実装されています。これらの2つのモードが IETF (Internet Engineering Task Force) 標準プロセスの一部として承認されると、3番目のモード — 標準 DNS 更新モードを使用できます。 DHCP サーバは、これらのスキームとの互換性の為に設定する必要があります。バージョン 3.0b2pl11 及び以前のバージョンでは ad-hoc モードが使用されていましたが、現在このモードは廃止されています。同じような動作を維持するには、設定ファイルの先頭に次の行を追加します:
ddns-update-style ad-hoc;
推奨されるモードを使用するには、設定ファイルの上に次の行を追加します：
ddns-update-style interim;
これらのモード別の詳細については、 dhcpd.conf の man ページを参照してください。
設定ファイルのステートメントには、次の2タイプがあります：
-
パラメータ — タスクの実行方法、タスクを実行するかどうか、あるいはクライアントに送信するネットワーク設定オプションを表記します。
-
宣言 — ネットワークのトポロジの記述、クライアントの記述、クライアントのアドレスの指定、あるいは宣言グループに対するパラメータグループの適用を行います。
キーワードオプションでスタートするパラメータは オプション と呼ばれます。これらのオプションは、 DHCP オプションを制御するものです：一方、パラメータは、オプションでない値を設定したり、 DHCP サーバーの動作を制御したりするものです。
中かっこ （{ }） で囲まれたセクションの前に宣言されたパラメータとオプションは、グローバルパラメータとみなされます。グローバルパラメータは、それ以降のすべてのセクションに適用されます。
重要
設定ファイルが変更された場合、 service dhcpd restart コマンドで DHCP デーモンを再起動するまでは変更内容は反映されません。
ヒント
DHCP 設定ファイルを変更し、サービスをその度に再開する代わりに、 omshell コマンドを使用すると、 DHCP サーバーの設定に対するアクセス、照会、変更を対話的に行なえます。 omshell を使用することにより、 DHCP サーバーの実行中でも変更を行なうことができるようになります。 omshell の詳細については、 omshell manページを参照してください。
例 9.1. 「サブネット宣言」 では、 routers、 subnet-mask、 domain-name、 domain-name-servers、及び time-offset オプションは、その下で宣言される host ステートメント用に使用されます。
また、 サブネット を宣言することもできます。 サブネット 宣言は、ネットワークのすべてのサブネットに対して記述する必要があります。宣言されていない場合、 DHCP サーバーは起動できません。
この例では、サブネット内のすべての DHCP クライアントに対するグローバルオプションが存在し、 範囲 が宣言されています。クライアントには、 範囲 内の IP アドレスが割り当てられます。
subnet 192.168.1.0 netmask 255.255.255.0 {
option routers 192.168.1.254;
option subnet-mask 255.255.255.0;
option domain-name "example.com";
option domain-name-servers 192.168.1.1;
option time-offset -18000; # Eastern Standard Time
range 192.168.1.10 192.168.1.100;
}
例 9.1. サブネット宣言
同じ物理ネットワークを共有するすべてのサブネットは、 例 9.2. 「共有ネットワーク宣言」 に示すように 共有ネットワーク 内で宣言する必要があります。共有ネットワーク 内のパラメータで、 サブネット 宣言の外にあるものは、グローバルパラメータとみなされます。共有ネットワーク の名前は、たとえばテストラボ環境のすべてのサブネットを表現する「test-lab」のように、ネットワークの記述名にします。
shared-network name {
option domain-name "test.redhat.com";
option domain-name-servers ns1.redhat.com, ns2.redhat.com;
option routers 192.168.0.254;
more parameters for EXAMPLE shared-network
subnet 192.168.1.0 netmask 255.255.252.0 {
parameters for subnet
range 192.168.1.1 192.168.1.254;
}
subnet 192.168.2.0 netmask 255.255.252.0 {
parameters for subnet
range 192.168.2.1 192.168.2.254;
}
}
例 9.2. 共有ネットワーク宣言
例 9.3. 「グループ宣言」 に示すように、 グループ 宣言を使用して、宣言のグループにグローバルパラメータを適用できます。例えば、共有ネットワーク、サブネット、ホストはグループ化することができます。
group {
option routers 192.168.1.254;
option subnet-mask 255.255.255.0;
option domain-name "example.com";
option domain-name-servers 192.168.1.1;
option time-offset -18000; # Eastern Standard Time
host apex {
option host-name "apex.example.com";
hardware ethernet 00:A0:78:8E:9E:AA;
fixed-address 192.168.1.4;
}
host raleigh {
option host-name "raleigh.example.com";
hardware ethernet 00:A1:DD:74:C3:F2;
fixed-address 192.168.1.6;
}
}
例 9.3. グループ宣言
サブネット内のシステムに動的 IP アドレスをリースする DHCP サーバーを設定するには、 例 9.4. 「範囲パラメータ」 を変更して実際に使用する値を記述します。これにより、クライアントのデフォルトのリース期間、最大リース期間、ネットワークの設定値を宣言します。この例では、 範囲 192.168.1.10 から 192.168.1.100 の範囲内の IP アドレスがクライアントシステムに割り当てられます。
default-lease-time 600;
max-lease-time 7200;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
option routers 192.168.1.254;
option domain-name-servers 192.168.1.1, 192.168.1.2;
option domain-name "example.com";
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.10 192.168.1.100;
}
例 9.4. 範囲パラメータ
ネットワークインターフェースカードの MAC アドレスを基にしてクライアントに IP アドレスを割り当てるには、 ホスト 宣言内の ハードウェア イーサネット パラメータを使用します。 例 9.5. 「DHCP を使用した静的 IP アドレス」 の参考例では、 ホストアペックス 宣言は、 MAC アドレス 00:A0:78:8E:9E:AA のネットワークインターフェースカードが常に IP アドレス 192.168.1.4 を受け取るように指定しています。
クライアントにホスト名を割り当てるためにオプションパラメータ host-name を使用することができます。
host apex {
option host-name "apex.example.com";
hardware ethernet 00:A0:78:8E:9E:AA;
fixed-address 192.168.1.4;
}
例 9.5. DHCP を使用した静的 IP アドレス
ヒント
提供されたサンプル設定ファイルをひな型として使用し、カスタム設定オプションをそれに追加できます。サンプルファイルを適切な場所にコピーするには、
cp /usr/share/doc/dhcp-<version-number>/dhcpd.conf.sample /etc/dhcpd.conf
（<version-number> は DHCP のバージョンを表わします）というコマンドを使用します。
オプションのステートメントの全一覧とその機能については、dhcp-options のmanページを参照してください。
DHCP サーバーでは、ファイル /var/lib/dhcpd/dhcpd.leases を使用して DHCP クライアントのリースデータベースを保存します。このファイルは、手動で変更すべきではありません。リースデータベースには、最近割り当てられた各 IP アドレスの DHCP リース情報が自動的に保存されます。この情報には、リース期間、 IP アドレスの割り当て先、リースの開始/終了日、リースの取得に使用されたネットワークインターフェイスカードの MAC アドレスが含まれます。
リースデータベースにおける時刻はすべて、ローカル時でなく UTC (Coordinated Universal Time) を使用します。
リースデータベースは、サイズが大きくなり過ぎるのを避けるために、適宜再作成されます。最初に、すべての既知のリースが一時リースデータベースに保存されます。 dhcpd.leases ファイルの名前が dhcpd.leases~ に変更され、一時リースデータベースが dhcpd.leases に書き込まれます。
リースデータベースの名前がバックアップファイルの名前に変更された後、新規ファイルが書き込まれる前に、 DHCP デーモンが kill されたりシステムがクラッシュしたりすることも考えられます。この場合、 dhcpd.leases ファイルは存在しませんが、サービスを起動する必要があります。その際に新しいリースファイルを作成しないようにしてください。新しいファイルを作成すると、それまでのリースはすべて失われ、問題が発生します。これを解決するには、 dhcpd.leases~ バックアップファイルの名前を dhcpd.leases に変更して、デーモンを起動してください。
重要
DHCP サーバーを初めて起動するとき、 dhcpd.leases ファイルがなければサーバーは起動できません。このファイルが存在しない場合は、コマンド touch /var/lib/dhcpd/dhcpd.leases を使用してファイルを作成してください。
named を起動すると dhcpd.leases ファイルが自動的にチェックされるため、同じサーバーで BIND が DNS サーバーとしても実行されている場合は、この手順を実行する必要はありません。
DHCP サービスを起動するには、 /sbin/service dhcpd start コマンドを使用します。 DHCP サーバーを停止するには、 /sbin/service dhcpd stop コマンドを使用します。
システムに複数のネットワークインターフェースを組み込むが、そのうちの1つのインターフェースだけで DHCP サーバーを起動する必要がある場合には、そのデバイスだけでサービスを起動するように DHCP サーバーを設定します。 /etc/sysconfig/dhcpd にある DHCPDARGS のリストにインターフェース名を追加します:
# Command line options here DHCPDARGS=eth0
これは、ネットワークカードが2つあるファイアウォールマシンに便利な機能です。一方のネットワークカードを DHCP クライアントとして設定してインターネット用の IP アドレスを取得します。もう一方のネットワークカードは、ファイアウォール内の内部ネットワーク用の DHCP サーバーとして使用できます。内部ネットワークに接続されたネットワークカードだけを指定することにより、ユーザーがインターネット経由でデーモンに接続できなくなるので、システムがより安全になります。
/etc/sysconfig/dhcpd で指定できるその他のコマンドラインオプションには次のようなものがあります：
-
-p—<portnum>dhcpdが監視する UDP ポート番号を指定します。デフォルト値はポート 67 です。 DHCP サーバーは、指定された UDP ポートよりも1つ大きな番号のポートにある DHCP クライアントに応答を送信します。たとえば、デフォルトポート 67 をそのまま使用する場合、サーバーはポート 67 をリスンして要求を監視し、ポート 68 にあるクライアントに応答します。ここでポートが指定され、 DHCP リレーエージェントが使用された場合、 DHCP リレーエージェントがリスンするポートと同じポートが指定されなければなりません。詳細については、 項9.2.4. 「DHCP リレーエージェント」 を参照してください。 -
-f— フォアグラウンドプロセスとしてデーモンを実行します。これは主にデバッグに使用されます。 -
-d— 標準エラー記述子に DCHP サーバーデーモンをログします。これは主にデバッグに使用されます。このオプションを指定しなかった場合、ログは/var/log/messagesに書きこまれます。 -
-cf— 設定ファイルの場所を指定します。デフォルトの場所は<filename>/etc/dhcpd.confです。 -
-lf— リースデータベースファイルの場所を指定します。リースデータベースファイルがすでに存在する場合、 DHCP サーバーを起動するたびに、同じファイルが使用されるようにすることが非常に重要です。このオプションは、実稼働環境以外のマシンでのデバッグのためだけに使用することを強くお勧めします。デフォルトの場所は<filename>/var/lib/dhcpd/dhcpd.leasesです。 -
-q— デーモンを開始するときに、著作権に関するメッセージを表示しません。
DHCP リレーエージェント （dhcrelay） により、 DHCP や BOOTP の要求を、 DHCP サーバーを持たないサブネットからほかのサブネットの DHCP サーバーへと中継することが可能になります。
DHCP クライアントが情報を要求すると、 DHCP リレーエージェントは自身の起動時に指定された一覧に含まれる DHCP サーバーに要求を転送します。 DHCP サーバーのいずれかから応答が返されると、その応答はオリジナルの要求を送信したネットワークにブロードキャストされたりユニキャストされたりします。
INTERFACES の指示文 (directive) で /etc/sysconfig/dhcrelay 内にインターフェースが指定されている場合を除き、 DHCP リレーエージェントは全てのインターフェース上で DHCP 要求を監視します。
DHCP リレーエージェントを開始するには、 service dhcrelay start コマンドを使用します。
DHCP クライアントを手動で設定するには、 /etc/sysconfig/network ファイルを修正して、 /etc/sysconfig/network-scripts ディレクトリにある各ネットワークデバイスのネットワークと設定ファイルを有効にします。このディレクトリには、デバイスごとに設定ファイル ifcfg-eth0 があります。 eth0 はネットワークデバイス名です。
/etc/sysconfig/network ファイルには、次の行が必要です：
NETWORKING=yes
ブート時にネットワークを起動するには、 NETWORKING 変数が yes に設定されている必要があります。
/etc/sysconfig/network-scripts/ifcfg-eth0 ファイルには、次の行が必要です：
DEVICE=eth0 BOOTPROTO=dhcp ONBOOT=yes
DHCP を使用するよう設定するデバイスごとに設定ファイルが必要です。
ネットワークスクリプト用に含まれるその他のオプション:
-
DHCP_HOSTNAME— このオプションは、 IP アドレスを受信する前にクライアントがホスト名を指定することが DHCP サーバーにとって必要な場合にのみ使用します。 (Red Hat Enterprise Linux の DHCP サーバーのデーモンはこの機能をサポートしていません。) -
PEERDNS=の、<answer><answer>-
yes— サーバーからの情報で/etc/resolv.confを変更します。 DHCP を使用する場合は、yesがデフォルトです。 -
no—/etc/resolv.confを変更しません。
-
-
SRCADDR=の、<address><address> -
USERCTL=の、<answer><answer>-
yes— root 以外のユーザーがこのデバイスをコントロールすることを許可します。 -
no— root 以外のユーザーがこのデバイスをコントロールすることを許可しません。
-
DHCP クライアントの設定にグラフィカルインターフェースを使用する場合は、 章 4. ネットワーク設定 に記載されている ネットワーク管理ツール (Network Administration Tool) の使用法を参照して、 DHCP を使用するネットワークインターフェースを設定してください。
ヒント
プロトコルのタイミング、リース要件および要求、動的 DNS サポート、エイリアス、そしてクライアントサイド設定に対して上書きまたは追加するさまざまな値などの DHCP オプションの高度な設定については、 dhclientとdhclient.conf の man ページを参照してください。
他の設定オプションについては、以下の資料を参考にして下さい。
-
dhcpdの man ページ — DHCP デーモンの動作を説明しています。 -
dhcpd.confの man ページ — DHCP 設定ファイルの設定方法の説明と、いくつかの例が含まれています。 -
dhcpd.leasesの man ページ — DHCP リースファイルの設定方法の説明と、いくつかの例が含まれています。 -
dhcp-optionsの man ページ —dhcpd.confの DHCP オプション宣言の構文の説明と、いくつかの例が含まれています。 -
dhcrelayの man ページ — DHCP リレーエージェントとその設定オプションが説明されています。 -
/usr/share/doc/dhcp-<— DHCP サービスの現在のバージョン用のサンプルファイル、 README ファイル、及びリリースノートが含まれます。version>/
Apache HTTP Server は、 Apache Software Foundation （http://www.apache.org/） で開発された強力な商用オープンソース Web サーバーです。 Red Hat Enterprise Linux には Apache HTTP Server 2.2 が含まれており、その機能を強化するために設計された多くのサーバーモジュールも含まれています。
Apache HTTP Server でインストールされるデフォルトの設定ファイルは、ほとんどの状況に対して変更することなく機能します。この章では、カスタム設定を必要とする方、旧 Apache HTTP Server 1.3 形式から設定ファイルの変換を必要とされる方の助けとなるよう、この設定ファイル (/etc/httpd/conf/httpd.conf) に含まれる多くのディレクティブの概略を説明します。
警告
グラフィカルな HTTP Configuration Tool (system-config-httpd ) を使用する場合は、 Apache HTTP Server の設定ファイルを手動編集 しないでください 。このファイルが使用されるたびに、 HTTP Configuration Tool がファイルを再生成してしまいます。
Apache HTTP Server 2.2 とバージョン 2.0 (バージョン 2.0 は Red Hat Enterprise Linux 4 及びそれ以前の製品に含まれていました) には重要な違いがあります。このセクションでは Apache HTTP Server 2.2 のいくつかの機能について検討しながら、重要な変更の概要を説明していきます。バージョン 1.3 からアップグレードするのであれば、バージョン 1.3 からバージョン 2.0 に移行する方法についてもお読みください。バージョン 1.3 の設定ファイルを 2.0 形式に移行する方法については、 項10.2.2. 「Apache HTTP Server 1.3 設定ファイルを 2.0 に移行する」 を参照してください。
Apache HTTP Server 2.2 は、バージョン 2.0 に対して、以下の改良点を特長としています:
-
改良されたキャッシングモジュール (mod_cache, mod_disk_cache, mod_mem_cache) 。
-
認証モジュールを置き換える、認証と承認のサポートの新しい構成は、前のバージョンで提供されました。
-
プロキシロードバランスのサポート (mod_proxy_balancer)
-
32 ビットのプラットフォーム上での、ラージファイル (2GB 以上) 対応のサポート
デフォルトの httpd 設定には以下の変更がなされました。
-
mod_cern_meta と mod_asis modules は、もはやデフォルトでロードされません。
-
mod_ext_filter module はデフォルトでロードされます。
もし Red Hat Enterprise Linux の前のバージョンからアップグレードをする場合は、 httpd 設定を httpd 2.2 にアップグレードする必要が有ります。更なる情報については、 http://httpd.apache.org/docs/2.2/upgrading.html をご参照ください。
このセクションは、バージョン 2.0 から 2.2 への移行の概要を説明したものです。もしバージョン 1.3 から移行する場合は、 項10.2.2. 「Apache HTTP Server 1.3 設定ファイルを 2.0 に移行する」 をご参照ください。
-
バージョン 2.0 の設定ファイルとスタートアップスクリプトは、特に変更があった可能性のあるモジュール名について、軽微な修正が必要です。バージョン 2.0 で機能していたサードパーティのモジュールは、バージョン 2.2 でも機能しますが、それらをロードする前に再コンパイルする必要があります。注意すべきキーモジュールは、認証と承認のモジュールです。
LoadModuleラインをリネームされたそれぞれのモジュールをアップデートする必要があります。 -
mod_userdirモジュールは、ディレクトリ名を表示するUserDirディレクティブを提供するときのみ要求に答えます。もしバージョン 2.0 で使用された手順を維持したければ、設定ファイルの中にディレクティブUserDir public_htmlを追加します。 -
SSL を有効にするには、
httpd.confファイルを編集し、必要なmod_sslディレクティブを追加します。apachectl startをapachectl startsslとして使用することは、バージョン 2.2 ではできません。 httpd の SSL 設定の例をconf/extra/httpd-ssl.confで見ることができます。 -
設定をテストするには、設定エラーを検知する
service httpd configtestの使用が推奨されています。
バージョン 2.0 から 2.2 のアップグレードに関する詳細は http://httpd.apache.org/docs/2.2/upgrading.html をご覧ください。
このセクションは Apache HTTP Server 1.3 設定ファイルを Apache HTTP Server 2.0 で使用するために移行する方を説明します。
Red Hat Enterprise Linux 2.1 から Red Hat Enterprise Linux 5 にアップグレードする場合は、 Apache HTTP Server 2.0 パッケージ用の新しい設定ファイルが /etc/httpd/conf/httpd.conf.rpmnew としてインストールされ、元のバージョン 1.3 httpd.conf は影響を受けません。もちろん、新しい設定ファイルを使用して古い設定を移行するか、既存のファイルをベースとして使用して変更を加えるかはユーザー次第です。ただし、ファイルの一部分は他より大きく変更してあり、ミックスした方法が一般的には最適です。バージョン 1.3 と 2.0 で提供されたいずれの設定ファイルも3つのセクションに別けられます。
/etc/httpd/conf/httpd.conf ファイルが、新しくインストールしたデフォルトの修正バージョンであり、元の設定ファイルを保存したコピーがある場合は、次の例のように、 diff コマンドを起動するのが最も簡単でしょう (root としてログイン):
diff -u httpd.conf.orig httpd.conf | less
このコマンドは変更が加えられた箇所すべてをハイライトします。元のファイルのコピーがない場合、 rpm2cpioとcpio コマンドを使って以下の例のように RPM パッケージから抽出します。
rpm2cpio apache-<version-number>.i386.rpm | cpio -i --make
上記のコマンドの <version-number> の部分は apache パッケージのバージョン番号に置き換えます。
最後に、 Apache HTTP Server は設定エラーをチェックするテストモードがあるのを知っておくと便利です。アクセスするには以下のコマンドを入力します：
apachectl configtest
設定ファイルのグローバル環境のセクションには、処理できる多くの同時並行要求や各種ファイルの場所など、 Apache HTTP Server の全体的な動作に影響するディレクティブが含まれています。このセクションでは、かなり多くの変更が必要となり、 Apache HTTP Server 2.0 設定ファイルを元にして古い設定をここに移行することが推奨されます。
BindAddress と Port ディレクティブは なくなりました。これらの機能はより柔軟性のあるListen ディレクティブで提供されるようになります。
Port 80 が 1.3 バージョンの設定ファイルで設定されていた場合、 2.0 の設定ファイルでListen 80に変更します。Port が80 以外の値 に設定されていた場合、 ServerName ディレクティブのコンテンツにポート番号を追加します。
例として、 Apache HTTP Server 1.3 ディレクティブの例を以下に示します。
Port 123 ServerName www.example.com
この設定を Apache HTTP Server 2.0 に移行するには、以下の構成を使用します：
Listen 123 ServerName www.example.com:123このテーマに関する詳細は、 Apache Software Foundation のウェブサイトにある以下のドキュメントを参照してください。
Apache HTTP Server が要求を受け付けると、それを処理するために子プロセスまたはスレッドをディスパッチします。この子プロセスまたはスレッドのグループは サーバープール として知られています。 Apache HTTP Server 2.0 の作動環境では、このサーバープールの作成と管理の責任は、 マルチプロセッシングモジュール (MPMs) と呼ばれるモジュールのグループに抽出されています。他のモジュールとは異なり、 MPM グループのうちの1つのモジュールのみが Apache HTTP Server によって読み込まれます。 2.0 では、 prefork 、 worker 、 perchild の3つの MPM モジュールが出荷されています。現在、 prefork MPM と worker MPM のみが利用可能です。 perchild MPM は将来的には利用できるようになる可能性があります。
元の Apache HTTP Server 1.3 の動作は prefork MPM に移動しています。 prefork MPM は Apache HTTP Server 1.3 と同じディレクティブを受けるので、以下のディレクティブが直接移行できるかもしれません。
-
StartServers -
MinSpareServers -
MaxSpareServers -
MaxClients -
MaxRequestsPerChild
worker MPM は、マルチプロセス、マルチスレッド対応のサーバーを実装しており、優れたスケーラビリティを提供します。この MPM を使用すると、要求がスレッドによって処理され、システムリソースを維持しながら効率的に大量の要求を処理できるようになります。 worker が受けるディレクティブのいくつかは、 prefork MPM が受けるディレクティブと同じものですが、このディレクティブの値は Apache HTTP Server 1.3 インストールからそのまま転送しないでください。代わりに、ガイドとしてデフォルト値を使用するのが最もよく、どの値が最も機能するか試してから決定してください。
重要
worker MPM を使用するには、 /etc/sysconfig/httpd ファイルを作成し、以下のディレクティブを追加します:
HTTPD=/usr/sbin/httpd.worker
MPM に関するテーマの詳細については、Apache Software Foundation のウェブサイトにある以下のドキュメントを参照してください。
ここでは多くの変更が必要になります。 Apache HTTP Server 1.3 の設定をバージョン 2.0 に合わせて変更しようとしている方は (変更をバージョン 2.0 設定に移行するのではなく) 、提供された Apache HTTP Server 2.0 設定ファイルからこのセクションをコピーすることを強くおすすめします。
提供された Apache HTTP Server 2.0 設定からそのセクションをコピーしたくない方は、以下の点に注意してください:
-
AddModuleとClearModuleListディレクティブはなくなりました。このディレクティブは、正しい順序でモジュールが有効化されることを確認するのに使用されていました。 Apache HTTP Server 2.0 API では、モジュールがその順序を指定することができ、この2つのディレクティブの必要性が解消されました。 -
LoadModule行の順番はほとんどの場合に意味が無くなっています。 -
多くのモジュールに追加、削除、名前の変更、分割、他モジュールと統合、などが行なわれています。
-
自身の RPM (
mod_ssl、php、mod_perlなどの系列) にパッケージ化されているモジュールのLoadModule行は、/etc/httpd/conf.d/ディレクトリ内の関連ファイルにあるため、必要性がなくなりました。 -
各種の
HAVE_XXX定義は定義されなくなります。
重要
元のファイルを変更する場合は、 httpd.conf が以下のディレクティブを含むことが非常に重要なこととなりますので注意してください:
Include conf.d/*.conf
このディレクティブを省略すると、それらの RPM (mod_perl、 php、mod_ssl など) にパッケージ化されているすべてのモジュールで障害が起きる要因となります。
以下のディレクティブが Apache HTTP Server 2.0 の設定から削除されています:
-
ServerType— Apache HTTP Server はServerType standaloneとしてのみ実行することができ、このディレクティブは不適切になります。 -
AccessConfigとResourceConfig— これらのディレクティブは、Includeディレクティブの機能をミラーリングするので削除されています。AccessConfigとResourceConfigディレクティブが設定されると、Includeディレクティブに置き換わります。古いディレクティブが順番にファイルを読むようにするためには、
Includeディレクティブを、AccessConfigの前に、対応するResourceConfigでhttpd.confの終わりに配置してください。もしデフォルトの値を使用している場合は、それらをconf/srm.confとconf/access.confファイルとして明確に含めてください。
設定ファイルのメインサーバー設定セクションはメインサーバーを設定します。これは、 <VirtualHost> コンテナ内に定義された仮想ホストによって処理されないすべての要求に応答します。ここの値も定義されるすべての <VirtualHost> コンテナに対してデフォルトを提供します。
このセクションで使用されるディレクティブは Apache HTTP Server 1.3 とバージョン 2.0 で変更はほとんどありません。メインサーバーの設定が大幅にカスタマイズされる場合は、既存の設定ファイルを Apache HTTP Server 2.0 に合わせて変更する方が簡単かもしれません。メインサーバーのセクションを少ししかカスタマイズしないユーザーは変更をデフォルトの 2.0 設定に移行してください。
UserDir ディレクティブは、 http://example.com/~bob/ などの URL を有効にして /home/bob/public_html/ などのユーザー bob のホームディレクトリ内のサブディレクトリにマップするために使用されます。この機能の副作用で、潜在的な攻撃者によって特定ユーザー名がシステム上に存在するかどうかを確認できるようになってしまいます。これは、 Apache HTTP Server 2.0 のデフォルト設定がこのディレクティブを無効にするためです。
UserDir マッピングを有効にするには、 httpd.conf の以下のディレクティブを
UserDir disable
以下のディレクティブに変更します。
UserDir public_html
このテーマに関する詳細は、 Apache Software Foundation のウェブサイトにある以下のドキュメントを参照してください。
以下のロギングディレクティブが削除されています。
-
AgentLog -
RefererLog -
RefererIgnore
ただし、 agent ログ及び referrer ログは、 CustomLog と LogFormatディレクティブを使用して利用することができます。
このテーマに関する詳細は、 Apache Software Foundation のウェブサイトにある以下のドキュメントを参照してください。
古くなった FancyIndexing ディレクティブは削除されています。同じ機能が IndexOptions ディレクティブ内の FancyIndexingオプション を使って利用することができます。
IndexOptions ディレクティブへの VersionSort オプションで、ファイルがより自然な形でソートされたバージョン番号を含むようになります。例えば、ディレクトリインデックスページで、 httpd-2.0.6.tar は、 httpd-2.0.36.tar の前に現れます。
ReadmeName と HeaderName ディレクティブのデフォルトが、 README と HEADER から README.htmlとHEADER.html に変更になっています。
このテーマに関する詳細は、 Apache Software Foundation のウェブサイトにある以下のドキュメントを参照してください。
CacheNegotiatedDocs ディレクティブが引数の on または off をとるようになります。既存の CacheNegotiatedDocs のインスタンスは CacheNegotiatedDocs on に置き換えてください。
このテーマに関する詳細は、 Apache Software Foundation のウェブサイトにある以下のドキュメントを参照してください。
ErrorDocument ディレクティブでハードコードされたメッセージを使用するには、 Apache HTTP Server 1.3 で行なっていたように1つの二重引用符 " を先頭に付けるのではなく、2つの二重引用符 " でメッセージを囲む必要があります。
例として、 Apache HTTP Server 1.3 ディレクティブの例を以下に示します。
ErrorDocument 404 "ドキュメントは見つかりませんでした
ErrorDocument 設定を Apache HTTP Server 2.0 に移行するには、以下の構成を使用します：
ErrorDocument 404 "ドキュメントは見つかりませんでした"
ErrorDocument ディレクティブの例で二重引用符を後に付けることに注意してください。
このテーマに関する詳細は、 Apache Software Foundation のウェブサイトにある以下のドキュメントを参照してください。
すべての <VirtualHost> コンテナのコンテンツは、 項10.2.2.2. 「メインサーバーの設定」 で説明しているメインサーバーのセクションと同じ方法で移行してください。
重要
SSL/TLS 仮想ホストの設定はメインサーバーの設定ファイルから /etc/httpd/conf.d/ssl.conf に移動しているので注意してください。
Apache HTTP Server 2.0 では、モジュールシステムが変更になり、複数モジュールが新しい方法で連鎖または結合されるようになりました。例えば、 Common Gateway Interface (CGI) スクリプトはサーバー解析された HTML ドキュメントを生成することができ、このドキュメントは mod_include で処理できます。これにより、特定の目的を達成するためにモジュールを結合する方法に関して、飛躍的な可能性をもたらすことになります。
これが機能する方法は、正確に1つの handler モジュールと 0 または複数の filter モジュールを後に付けて各要求に応じます。
Apache HTTP Server 1.3 稼動環境では、例えば、 Perl スクリプトはその中で Perl モジュール (mod_perl) によって処理されます。 Apache HTTP Server 2.0 では、要求が最初に核のモジュール — 静的ファイルを処理 — で 処理されてから 、 mod_perl で フィルタされます 。
正確にこれを使用する方法、及びその他すべての新しい Apache HTTP Server 2.0 の機能は、このガイドの範囲を超えてしまいますが、 PATH_INFO ディレクティブをフィルタとして実装されるようになったモジュールで処理するドキュメントに使用する場合、それぞれが本当のファイル名の後に後続のパス情報を含むため、変更は複数に分岐します。要求を最初に処理する核のモジュールは、デフォルトでは PATH_INFO を理解せず、このような情報を含む要求に対して 404 Not Found エラーを返します。別の方法として、 AcceptPathInfo ディレクティブを使用して核のモジュールが PATH_INFO で要求を受けるよう強制します。
以下にこのディレクティブの例を示します。
AcceptPathInfo on
このテーマに関する詳細は、 Apache Software Foundation のウェブサイトにある以下のドキュメントを参照してください。
Apache HTTP Server 2.0 では、 mod_suexec モジュールは、仮想ホストの設定に User と Group ディレクティブではなく、 SuexecUserGroup ディレクティブを使用します。 User と Group ディレクティブは一般的にはまだ使用されますが、仮想ホストの設定には無用となりました。
例として、 Apache HTTP Server 1.3 ディレクティブの例を以下に示します。
<VirtualHost vhost.example.com:80> User someone Group somegroup </VirtualHost>
この設定を Apache HTTP Server 2.0 に移行するには、以下の構成を使用します：
<VirtualHost vhost.example.com:80> SuexecUserGroup someone somegroup </VirtualHost>
mod_ssl の設定は httpd.conf ファイルから /etc/httpd/conf.d/ssl.conf ファイルに移動されています。このファイルがロードされ、 mod_ssl が機能するには、 項10.2.2.1.3. 「Dynamic Shared Object (DSO) のサポート」 で説明しているように、ステートメントの Include conf.d/*.conf が httpd.conf ファイルになければなりません。
SSL 仮想ホストの ServerName ディレクティブは、明示的にポート番号を指定する必要があります。
例として、 Apache HTTP Server 1.3 ディレクティブの例を以下に示します。
<VirtualHost _default_:443> # General setup for the virtual host ServerName ssl.example.name ... </VirtualHost>
この設定を Apache HTTP Server 2.0 に移行するには、以下の構成を使用します：
<VirtualHost _default_:443> # General setup for the virtual host ServerName ssl.host.name:443 ... </VirtualHost>
また、 SSLLog と SSLLogLevel のいずれのディレクティブも削除されていることに十分注意してください。 mod_ssl モジュールは ErrorLog と LogLevel ディレクティブに従うようになります。これらのディレクティブの詳細については、 エラーログ と LogLevel を参照してください。
このテーマに関する詳細は、 Apache Software Foundation のウェブサイトにある以下のドキュメントを参照してください。
プロキシアクセス制御のステートメントは、 <Directory proxy:> ではなく、 <Proxy> ブロック内に配置されるようになります。
旧 mod_proxy のキャッシュ機能は次の3つのモジュールに分割されています。
-
mod_cache -
mod_disk_cache -
mod_mem_cache
これらは一般的には mod_proxy モジュールの旧バージョンと類似したディレクティブを使用しますが、キャッシュの設定を移行する前に、各ディレクティブを確認するのが賢明です。
このテーマに関する詳細は、 Apache Software Foundation のウェブサイトにある以下のドキュメントを参照してください。
mod_include モジュールがフィルタとして実装されるようになったので、有効にする方法が異なります。フィルタに関しての詳細は、 項10.2.2.4. 「モジュールと Apache HTTP Server 2.0」 を参照してください。
例として、 Apache HTTP Server 1.3 ディレクティブの例を以下に示します。
AddType text/html .shtml AddHandler server-parsed .shtml
この設定を Apache HTTP Server 2.0 に移行するには、以下の構成を使用します：
AddType text/html .shtml AddOutputFilter INCLUDES .shtml
Options +Includes ディレクティブは、従来通りに <Directory> コンテナまたは .htaccess ファイルに必要となるので注意してください。
このテーマに関する詳細は、 Apache Software Foundation のウェブサイトにある以下のドキュメントを参照してください。
Apache HTTP Server 1.3 は2つの認証モジュール、 mod_auth_db と mod_auth_dbm をサポートしていました。これらはそれぞれ Berkeley データベースと DBM データベースを使用していました。 Apache HTTP Server 2.0 では、これらのモジュールが1つのモジュールに結合され、 mod_auth_dbm という名前になり、いくつかの異なるデータベース形式にアクセスすることができます。 mod_auth_db から移行するには、 AuthDBUserFile と AuthDBGroupFile を mod_auth_dbm に相当する AuthDBMUserFile と AuthDBMGroupFile に置き換えて、設定ファイルを調整する必要があります。また、ディレクティブ AuthDBMType DB が、使用中のデータベースファイルのタイプを示すために追加されなければなりません。
以下の例では、 Apache HTTP Server 1.3 の mod_auth_db 設定の例を示します。
<Location /private/> AuthType Basic AuthName "My Private Files" AuthDBUserFile /var/www/authdb require valid-user </Location>
この設定を Apache HTTP Server のバージョン 2.0 に移行するには、以下の構成を使用します。
<Location /private/> AuthType Basic AuthName "My Private Files" AuthDBMUserFile /var/www/authdb AuthDBMType DB require valid-user </Location>
AuthDBMUserFile ディレクティブも .htaccess ファイルで使用することができるので注意してください。
Apache HTTP Server 2.0 では、ユーザー名とパスワードデータベースを処理するのに使用される dbmmanage Perl スクリプトが、 htdbm で置き換えられています。 htdbm プログラムは同等の機能を提供し、 mod_auth_dbm の様に、さまざまなデータベース形式を管理することができます; 使用する形式を指定するには、 -T オプションをコマンドラインで使用できます。
表 10.1. 「dbmmanage から htdbm に移行する」 DBM 形式のデータベースを dbmmanage を使用して htdbm 形式に移行する方法を示しています。
| 動作 | dbmmanage コマンド (1.3) | 相当する htdbm コマンド (2.0) |
|---|---|---|
| ユーザーをデータベースに追加 (特定パスワードを使用) |
dbmmanage authdb add username password
|
htdbm -b -TDB authdb username password
|
| ユーザーをデータベースに追加 (パスワードを要求) |
dbmmanage authdb adduser username
|
htdbm -TDB authdb username
|
| データベースからユーザーを削除 |
dbmmanage authdb delete username
|
htdbm -x -TDB authdb username
|
| データベース内のユーザーの一覧 |
dbmmanage authdb view
|
htdbm -l -TDB authdb
|
| パスワードの確認 |
dbmmanage authdb check username
|
htdbm -v -TDB authdb username
|
表 10.1. dbmmanage から htdbm に移行する
-mと-s オプションは、 dbmmanage、 htdbm のいずれでも機能し、パスワードのハッシュ用のMD5アルゴリズムの使用、 SHA1 アルゴリズムの使用をそれぞれ有効にします。
htdbm で新しいデータベースを作成するときは、 -c オプションを使う必要があります。
このテーマに関する詳細は、 Apache Software Foundation のウェブサイトにある以下のドキュメントを参照してください。
mod_perl の設定は、 httpd.conf から /etc/httpd/conf.d/perl.conf ファイルに移動しています。このファイルが読み込まれ、 mod_perl が機能するためには、 Include conf.d/*.conf ステートメントが 項10.2.2.1.3. 「Dynamic Shared Object (DSO) のサポート」 で示すように、 httpd.conf に含まれている必要があります。
httpd.conf にある Apache:: のオカレンスが、 ModPerl:: に置き換えられる必要があります。さらに、ハンドラが登録される方法が変更になりました。
これは Apache HTTP Server 1.3 mod_perl 設定の例です。
<Directory /var/www/perl> SetHandler perl-script PerlHandler Apache::Registry Options +ExecCGI </Directory>
これが Apache HTTP Server 2.0 に相当する mod_perl です。
<Directory /var/www/perl> SetHandler perl-script PerlResponseHandler ModPerl::Registry Options +ExecCGI </Directory>
mod_perl 1.x のモジュールはほとんど mod_perl 2.x で修正を行なわなくても機能するはずです。 XS モジュールは再コンパイルが必要で、マイナーな Makefile の修正が必要かもしれません。
mod_python の設定は、 httpd.conf から /etc/httpd/conf.d/python.conf ファイルに移動しています。このファイルがロードされ、 mod_python が機能するには、 Include conf.d/*.conf ステートメントが、 項10.2.2.1.3. 「Dynamic Shared Object (DSO) のサポート」 で示すように、 httpd.conf になければなりません。
PHP の設定は、 httpd.conf から /etc/httpd/conf.d/php.conf ファイルに移動しています。このファイルがロードされるためには、 Include conf.d/*.conf ステートメントが、 項10.2.2.1.3. 「Dynamic Shared Object (DSO) のサポート」 で示すように、 httpd.conf になければなりません。
注記
Apache HTTP Server 1.3 で使用されていた PHP 設定ディレクティブは、 Red Hat Enterprise Linux 5 上で Apache HTTP Server 2.0 に移行する時に完全な互換性があります。
PHP バージョン 4.2.0 及びそれ以降のバージョンでは、 global scope で利用可能なあらかじめ設定されたデフォルトの変数が変更しています。個別のインプットとサーバーの変数は、デフォルトでは global scope に直接は置かれなくなります。この変更によりスクリプトが壊れる可能性があります。 /etc/php.ini ファイル内で register_globals を On に設定して旧動作に戻します。
このテーマについての詳細は、 global scope の変更に関する詳細を以下の URL で参照してください。
Red Hat Enterprise Linux は Apache HTTP Server 用の mod_authz_ldap モジュールを含んで配送されます。このモジュールは1つの題目とクライアント SSL 証書の発行者の為の識別名の短い形式を使用して、 LDAP ディレクトリ内の識別したユーザー名を決定します。また、このモジュールはそのユーザーの LDAP ディレクトリのエントリを元にしてユーザーへの認証を発行でき、資源のユーザーとグループ権限を元にして資源へのアクセスを決定し、パスワードが満期になったユーザーのアクセスを拒否します。 mod_authz_ldap モジュールを使用する場合には、 mod_ssl が必要となります。
重要
mod_authz_ldap モジュールは、暗号化したパスワードハッシュを使用するユーザーの LDAP ディレクトリへの認証はしません。この機能は実験的な mod_auth_ldap モジュールにより提供されています。このモジュールの状況の詳細はオンラインアドレス http://httpd.apache.org/docs-2.0/mod/mod_auth_ldap.html の mod_auth_ldap モジュールドキュメントを参照して下さい。
/etc/httpd/conf.d/authz_ldap.conf ファイルは mod_authz_ldap モジュールを設定します。
mod_authz_ldap サードパーティモジュールの設定に関する詳細は /usr/share/doc/mod_authz_ldap- (<version>/index.html<version> をパッケージのバージョン番号で入れ換え) 又は http://authzldap.othello.ch/ で参照して下さい。
httpd パッケージをインストールしたら、 Apache HTTP Server のドキュメントをオンラインの http://httpd.apache.org/docs/2.2/ で見直してください。
httpd RPM は /etc/init.d/httpd をインストールし、 /sbin/service コマンドを使用してアクセスすることができます。
この値は、 worker MPM でのみ使用されます。各子プロセス内のスレッドの数を設定します。このディレクティブのデフォルト値は、 25 です。
apachectl を使ってサーバーをスタートさせるには、ルートタイプとしてスクリプトを制御します。
apachectl start
/sbin/service httpd start を使って httpd 起動させることもできます。 Order ディレクティブは、 allow ディレクティブと deny ディレクティブが評価される順序を制御します。サーバーは、 DocumentRoot の Deny ディレクティブの前に Allow ディレクティブを評価するように設定されます。
サーバーを停止するには、 root になり次のコマンドを入力します。
apachectl stop
/sbin/service httpd stop を使って httpd を停止することもできます。 restart オプションは、 Apache HTTP Server を停止してから起動する短縮形の方法です。
サーバーを再起動するには、 root で次のコマンドを入力します。
apachectl restartor:/sbin/service httpd restart
起動中にエラーに遭遇した場合、 Apache はコンソールもしくは ErrorLog にメッセージを表示します。
デフォルトでは、 httpd サービスは起動時に自動的に開始 しません。もし、起動時に Apache startup を持ちたいなら、コールを rc.N ディレクトリ内のスタートアップファイルの apachectl に加える必要があります。一般的に使用されるファイルは、 rc.local です。これは、 Apache を root として起動するので、このコールを与える前にセキュリティと認証を適切に設定することを推奨します。
/sbin/chkconfig 、 /usr/sbin/ntsysv 、または Services Configuration Tool プログラムなどの initscript ユーティリティを使用して httpd サービスをブート時に起動するように設定することができます。
次をタイプすることによって、 httpd サーバーの状態を表示することができます。
apachectl status
mod_ssl ディレクティブについての詳細は、オンラインのドキュメント、 http://httpd.apache.org/docs-2.0/mod/mod_ssl.html で参照してください。
注記
Apache HTTP Server をセキュアサーバーとして実行している場合、暗号化されたプライベート SSL キーを使用していると、セキュアサーバーのパスワードがマシンのブート後に要求されます。
詳細についてはオンラインの http://httpd.apache.org/docs/2.2/ssl をご覧ください。
HTTP Configuration Tool により、 Apache HTTP Serverの /etc/httpd/conf/httpd.conf 設定ファイルを設定できます。これは、古い srm.conf や access.conf 設定ファイルを使用せずに、それらを空にします。グラフィカルインターフェースを通して、バーチャルホストやロギング属性、および最大接続数のようなディレクティブを設定することが可能です。 HTTD Configuration Tool を開始するには、 System => Administration => Server Settings => HTTP をクリックします。
Red Hat Enterprise Linux と一緒に提供されているモジュールのみ、 HTTP Configuration Tool で設定が可能です。もし追加のモジュールがインストールされたら、このツールを使用してそれらを設定することはできません。
警告
もしこのツールを使用したいのであれば、 /etc/httpd/conf/httpd.conf 設定ファイルを手で編集しないでください。変更を保存し、プログラムを閉じた後に HTTP Configuration Tool がこのファイルを生成します。 HTTP Configuration Tool で利用できない追加モジュールや設定オプションを追加したいのであれば、このツールを使用できません。
HTTP Configuration Tool を使って Apache HTTP Server を設定する通常の方法は以下の通りです。
-
Main タブの下に基本セッティングを設定します。
-
Virtual Hosts タブをクリックしてデフォルトセッティングを設定します。
-
Virtual Hosts タブのデフォルトの仮想ホストを設定します。
-
2つ以上の URL もしくは仮想ホストを扱うには、追加の仮想ホストを追加します。
-
Server タブの下のサーバーセッティングを設定します。
-
Performance Tuning タブの下のコネクションセッティングを設定します。
-
必要なファイル全てを
DocumentRootとcgi-binディレクトリにコピーします。 -
アプリケーションを終了し、設定を保存するために選択します。
基本のサーバーセッティングの設定に Main を使います。
サーバー名 テキストエリアの中で使用する権利がある、完全修飾ドメイン名を入力します。このオプションは、 httpd.conf の中の ServerName ディレクティブに対応します。 ServerName ディレクティブは Web サーバーのホスト名を設定します。これは、リダイレクション URL を作成している時に使用されます。サーバー名を定義しない場合は、 Web サーバーは、それをシステムの IP アドレスから解決しようとします。サーバー名は、サーバーの IP アドレスから解決されたドメイン名である必要はありません。例えば、サーバーの実 DNS 名が foo.example.com であっても、サーバー名を www.example.com に設定することができます。
Webmaster email address テキストエリアの中で Web サーバーを保守する個人のメールアドレスを入力します。このオプションは、 httpd.conf の中の ServerAdmin ディレクティブに対応します。サーバーのエラーページをメールアドレスを含むように設定した場合、ユーザーはこのメールアドレスを使用して、サーバーの管理者に問題を報告することができます。デフォルト値は root@localhost です。
サーバーが着信要求を受けいれるポートを定義するには Available Addresses エリアを使用します。このオプションは httpd.conf の中の Listennk > ディレクティブに対応します。デフォルトでは Red Hat は、 Apache HTTP Server がセキュアでない Web 通信のポート 80 をリッスンするように設定しています。
要求を受け入れるための追加のポートを定義するには Add ボタンをクリックします。 図 10.2. 「Available Addresses」 に見られるように、ウィンドウが現れます。定義したポートで全ての IP アドレスをリッスンするためのオプション Listen to all addresses を選択するか、 Address フィールドの中でサーバーが接続を許可する特定の IP アドレスを指定するかしてください。ポート番号毎に１つの IP アドレスだけを指定してください。同じポート番号で1つ以上の IP アドレスを指定するには、それぞれの IP アドレスにエントリを作成してください。もし可能ならば、 DNS ルックアップの失敗を避けるために、ドメイン名の代わりに IP アドレスを使用してください。 DNS と Apache に関する問題 についての更なる情報については、 http://httpd.apache.org/docs/2.2/dns-caveats.html をご参照ください。
Address フィールドにアスタリスク (*) を入力することは、 Listen to all addresses を選択することと同じです。 Available Addresses フレームで Edit ボタンをクリックすると、選択されたエントリのために追加されたフィールドを除き Add ボタンと同じウィンドウが見られます。エントリを削除するには、それを選択し、 Delete ボタンをクリックしてください。
ヒント
1024 の下のポートをリスニングするようにサーバーを設定する場合、起動できるのは root ユーザーのみです。ポート 1024 以上の場合は、通常のユーザーとして httpd を起動できます。
Server Name、 Webmaster email address、および Available Addresses を定義した後、 Virtual Hosts タブをクリックしてください。以下の図は Virtual Hosts を示しています。
Edit をクリックすると、 Virtual Host Properties ウィンドウが現れ、そこから好みの設定をすることができます。新しい設定を追加するには、 Virtual Host Properties をまた表示する Add ボタンをクリックしてください。 Edit Default Settings ボタンをクリックすると、 通常のオプション がない Virtual Host Properties ウィンドウが現れます。
通常のオプション タブでは、ホスト名やドキュメントルートディレクトリを変更でき、またウェブマスターのメールアドレスも設定できます。ホスト情報では、バーチャルホストの IP アドレスやホスト名を設定できます。以下の図は、 通常のオプション タブを示しています。
もし仮想ホストを追加する場合は、仮想ホストに対して行なう設定がその仮想ホストに優先します。仮想ホスト設定で定義されないディレクティブは、デフォルト値が使用されます。
下の図は Directory Page Search List や Error Pages を設定できる Page Options タブを表わしています。この設定について詳しくない場合は、これらを変更しないでください。
DirectoryIndex は、ユーザーがディレクトリ名の終わりにスラッシュ （/） を指定してディレクトリのインデックスを要求したときにサーバーで処理されるデフォルトページです。
例えば、ユーザーが http://www.example.com/this_directory/ のページを要求すると、 DirectoryIndex ページが存在すればそのページを取得し、なければサーバーが生成したディレクトリ一覧を取得します。サーバーは DirectoryIndex ディレクティブに記載されたファイルのうちの１つを探し、最初に見つかったファイルを返します。 DirectoryIndex のデフォルトは index.html と index.html.var タイプのマップです。サーバーはこれらのどちらかのファイルを探し、最初に見つかったファイルを返します。これらのファイルが見つからず、そのディレクトリに対して Options Indexes が設定されると、ディレクトリ一覧機能がオフになっていない限り、サーバーはディレクトリ内のサブディレクトリとファイルの一覧を HTML 形式で生成して返します。
問題発生時やエラーの際にクライアントをローカルもしくは外部の URL にリダイレクトするために Apache HTTP Server を設定するには Error Code セクションを使用してください。このオプションは、 ErrorDocument ディレクティブに対応します。クライアントが Apache HTTP Server に接続しようとしたときに、もし問題やエラーが発生したら、デフォルトのアクションでは、 Error Code カラムに短いエラーメッセージが表示されます。このデフォルト設定をオーバーライドするには、エラーコードを選択し、 Edit ボタンをクリックしてください。デフォルトの短いエラーメッセージを表示するには、 Default を選択してください。クライアントを外部の URL にリダイレクトさせるには、 URL を選択し、 Location フィールドに http:// を含む完全な URL を入れてください。クライアントを内部の URL にリダイレクトさせるには、 File を選択し、ウェブサーバーのドキュメントルート以下にファイルのロケーションを入れてください。ロケーションは、スラッシュ (/) から始まり、ドキュメントルートと関連してなければなりません。
例えば、 404 Not Found エラーコードを、 404.html ファイルの内のウェブページにリダイレクトする場合は、 404.html を DocumentRoot/../error/404.htmlDocumentRoot は、定義したドキュメントルートディレクトリ (デフォルトは /var/www/html/) です。もしドキュメントルートがデフォルトロケーションとして残されたら、ファイルを /var/www/error/404.html にコピーしてください。それから、 File を 404 - Not Found エラーコードのための Behavior として選択し、 Location として、 /error/404.html を入れてください。
Default Error Page Footer メニュから、以下のオプションの中の1つを選択することができます。
-
メールアドレスとフッターの表示 —
ServerAdminディレクティブで指定し、デフォルトのフッターをウェブサイトの管理者のメールアドレスとともに全てのエラーページの下に表示します。 -
フッターの表示 — エラーページの下にデフォルトのフッターのみを表示する。
-
No footer — エラーページの
mod_ssl は SSL 上で HTTP プロトコルの暗号化を有効にします。 SSL (Secure Sockets Layer) プロトコルは、 TCP/IP ネットワークでコミュニケーションと暗号化のために使用されます。 SSL タブでは、サーバーの SSL を設定することができます。 SSL を設定するには、パスを以下に提供する必要があります:
-
証明書ファイル - パスを PEM (Privacy Enhanced Mail) のエンコードされたサーバー証明書ファイルに示す
SSLCertificateFileディレクティブを使用することと同等。 -
キーファイル - パスを PEM のエンコードされたサーバー秘密鍵ファイルに示す
SSLCertificateKeyFileディレクティブを使用することと同等。 -
証明書チェーンファイル - パスを全てのサーバーの証明書のチェーンを含む証明書ファイルに示す
SSLCertificateChainFileディレクティブを使用することと同等。 -
証明書権限ファイル - サーバーと通信するパーティの認証や ID を確認するために使用される暗号化されたファイル。
http://httpd.apache.org/docs/2.2/mod/directives.html#S で SSL のための設定ディレクティブについてのより多くの情報を見つけることができます。また、どの SSL オプションを有効にするかを決定する必要もあります。これらは、 SSLOptions を以下のオプションと使用するのと同等です:
-
FakeBasicAuth - Apache で使用される標準認証メソッドを有効にします。これは、 Client X509 証明書の Subject Distinguished Name (DN) が通常の HTTP username にトランスレートされていることを意味します。
-
ExportCertData -
SSL_SERVER_CERT、SSL_CLIENT_CERT、 およびSSL_CLIENT_CERT_CHAIN_n(n は数字の 0,1,2,3,4) における CGI 環境変数を作成します。これらのファイルは CGI スクリプトにより証明書チェックのために使用されます。 -
CompatEnvVars - CGI 環境変数を追加することにより、 Apache SSL の下位互換性を有効にする。
-
StrictRequire -
SSLRequireSSLやSSLRequireディレクティブがアクセス禁止を示すときは、いつでもアクセス拒否を強制する strict access を有効にする。 -
OptRenegotiate - セーフパラメータチェックを実行する
mod_sslにより不必要なハンドシェークの回避を有効にする。ディレクトリ毎に OptRenegotiate を有効にすることが推奨されています。
上記の SSL オプションについての詳細は、 http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#ssloptions を参照してください。下記の図は SSL タブと上記で述べられたオプションについて図解しています。
特定の転送やエラーログのオプションを設定するには、 Logging タブを使います。
デフォルトで、サーバーは転送ログを /var/log/httpd/access_log ファイルに書き込み、エラーログを /var/log/httpd/error_log ファイルに書き込みます。
転送ログは、ウェブサーバーへアクセスする全ての試行のリストを含んでいます。それは、接続を試みるクライアントの IP アドレス、その試行の日時、および取得しようとしたウェブサーバー上のファイルを記録します。この情報を格納するパスとファイルの名前を入力してください。もし、パスおよびファイル名がスラッシュ (/) から始まらない場合は、パスは設定したようにサーバーのルートディレクトリと相対的になります。このオプションは、 TransferLog ディレクティブに対応します。
カスタムのロギングファシリティの使用 のチェックすることと、 Custom Log String フィールドにカスタムログストリングを入力することにより、カスタムのログフォーマットを設定することができます。これは、 LogFormat ディレクティブを設定します。このディレクティブの詳細については、 http://httpd.apache.org/docs/2.2/mod/mod_log_config.html#logformat をご参照ください。
エラーログは、発生したサーバーのエラーのリストを含んでいます。この情報を格納するパスおよびファイルの名前を入力してください。もしパスおよびファイルの名前がスラッシュ (/) から始まらない場合は、パスは設定したようにサーバーのルートディレクトリと相対的になります。このオプションは、 ErrorLog に対応します。
エラーログにおけるエラーメッセージの冗長性を設定するために Log Level メニューを使用してください。それは、 (最小限の冗長性から最大限の冗長性まで) emerg、 alert、 crit、 error、 warn、 notice、 info または debug に設定できます。このオプションは、 LogLevel ディレクティブに対応します。
Reverse DNS Lookup メニューと共に選択された値は、 HostnameLookups ディレクティブを定義します。 No Reverse Lookup を選択することにより、値を off に設定します。 Reverse Lookup を選択することにより、値を on に設定します。 Double Reverse Lookup を選択することにより、値を2倍に設定します。
もし Reverse Lookup を選択すると、サーバーはウェブサーバーからのドキュメントを要求するそれぞれの接続の IP アドレスを自動的に解決します。 IP アドレスの解決は、特定の IP アドレスに対応するホスト名を見つけるためにサーバーは１つかそれ以上の接続を DNS に対してしていることを意味します。
もし Double Reverse Lookup を選択すると、サーバーは double-reverse DNS を実行します。つまり、 reverse lookup が実行された後、結果として forward lookup が実行されます。最低でも forward lookup での１つの IP アドレスが、はじめの reverse lookup からのアドレスと一致しなければなりません。
一般的には、このオプションを No Reverse Lookup にしておくべきです。なぜならば、 DNS のリクエストはサーバーに負荷を与え、スピードを落とす可能性があります。もしサーバーがビジーだったら、これらの reverse lookup か double reverse lookup を実行する影響は、極めて明らかでしょう。
Reverse lookup と double reverse lookup は、インターネット全体の問題でもあります。それぞれの個々の接続が、それぞれのホスト名を検索します。したがって、自分のウェブサーバーとインターネットのために、このオプションを No Reverse Lookup に設定しておくべきです。
特定の変数を CGI スクリプトのために set、 pass、および unset するオプションを設定するには、 環境 タブを使用してください。
ときには、 CGI スクリプトや server-side include (SSI) ページのために環境変数を変更する必要があります。 Apache HTTP Server は、 CGI スクリプトや SSI ページに渡される環境変数を設定するために mod_env モジュールを使用することができます。このモジュールのためのディレクティブを設定するには、 環境変数 ページを使用してください。
CGI スクリプトや SSI ページに渡される環境変数を設定するには、 Set for CGI Scripts セクションを使用してください。例えば、環境変数 MAXNUM を 50 に設定するには、 図 10.8. 「環境変数」 にあるように Set for CGI Script の中の 追加 ボタンをクリックし、 環境変数 テキストフィールドに MAXNUM と、 Value to set テキストフィールドに 50 とタイプしてください。それをリストに加えるには、 OK をクリックしてください。 Set for CGI Scripts セクションは、 SetEnv ディレクティブを設定します。
サーバーがはじめに CGI スクリプトを起動したときに環境変数の値を渡すには、 Pass to CGI Scripts セクションを使用してください。環境変数の値を見るには、シェルプロンプトで env コマンドをタイプしてください。Pass to CGI Scripts セクションの中の 追加 ボタンをクリックし、結果ダイアログボックスに環境変数の名前を入力してください。それをリストに追加するには、 OK をクリックしてください。 Pass to CGI Scripts セクションは、 PassEnv ディレクティブを設定します。
CGI スクリプトや SSI ページに値が渡されないようにするために環境変数を削除するには、 Unset for CGI Scripts セクションを使用してください。 Unset for CGI Scripts セクションの中の 追加 をクリックし、設定を解除する環境変数の名前を入力してください。それをリストに追加するには、 OK をクリックしてください。これは、 UnsetEnv ディレクティブに対応します。
これらの環境のどの値を編集するのにも、リストからそれを選択し、対応する 編集 ボタンをクリックしてください。リストからエントリーを削除するのには、それを選択し、対応する 削除 ボタンをクリックしてください。
Apache HTTP Server の環境変数に関しての詳細は http://httpd.apache.org/docs/2.2/env.html をご覧ください。
特定のディレクトリのためのオプションを設定するには、 パフォーマンス タブの中の ディレクトリ ページを使用してください。これは、 <Directory> ディレクティブに対応します。
以下の ディレクトリ リスト内で指定されていない全てのディレクトリのための デフォルトディレクトリオプション を設定するには、右上にある 編集 ボタンをクリックしてください。選択したオプションは、 <Directory> ディレクティブ内の Options ディレクティブとしてリストされます。以下のオプションを設定できます:
-
ExecCGI — CGI スクリプトの実行が可能です。このオプションが選択されていない場合は、 CGI スクリプトは実行されません。
-
FollowSymLinks —
-
Includes — サーバー側インクルードを許可します。
-
IncludesNOEXEC — サーバー側インクルードを許可しますが、 CGI スクリプトの
#execおよび#includeコマンドを無効にします。 -
Indexes — 要求されたディレクトリに
DirectoryIndex(index.htmlのような) が存在しなければ、ディレクトリのコンテンツの定様式リストを表示します。 -
Multiview —
-
SymLinksIfOwnerMatch — ターゲットファイルもしくはディレクトリがリンクと同じオーナーを持っている場合のみ、シンボリックリンクに従います。
特定のディレクトリのためにオプションを指定するには、 ディレクトリ リストボックスの横の 追加 ボタンをクリックしてください。 図 10.10. 「ディレクトリの設定」 で見られるウィンドウが現われます。 ディレクトリ テキストフィールドで設定するには、ウィンドウの一番下でディレクトリを入れてください。右側のリストでオプションを選択し、左側のオプションで Order ディレクティブを設定してください。 Order ディレクティブは、許可や拒否ディレクティブが評価される順番をコントロールします。 このホストを許可 や このホストを拒否 テキストフィールドでは、以下から１つを指定できます。
-
全ホストを許す — 全てのホストのアクセスを許可するには、
allとタイプしてください。 -
一部のドメイン名 — ホストの名前が特定したストリングと一致するか、それで終わる全てのホストを許可する。
-
完全な IP アドレス — 特定の IP アドレスにアクセスできます。
-
サブネット —
192.168.1.0/255.255.255.0のようなもの。 -
ネットワーク CIDR 仕様 —
10.3.0.0/16のようなもの。
ディレクトリ オプションより .htaccess に優先する をチェックすると、 .htaccess ファイルの中の設定ディレクティブを優先します。
Apache HTTP Server の設定ファイルは /etc/httpd/conf/httpd.conf です。 httpd.conf ファイルは十分にコメントが記入されており改めて説明する必要はないでしょう。デフォルトの設定でほとんどの状況に機能しますが、より重要となる設定オプションを理解しておいた方が良いでしょう。
警告
Apache HTTP Server 2.0 のリリースで、多くの設定オプションが変更しています。バージョン 1.3 の設定ファイルを 2.0 形式に移行する場合は、 項10.2.2. 「Apache HTTP Server 1.3 設定ファイルを 2.0 に移行する」 を参照してください。
Apache HTTP Server を設定する場合、 /etc/httpd/conf/httpd.conf を編集し、次に 項10.3. 「httpd の起動と httpd 停止」 に概略されているように、 httpd プロセスの再ロード、再起動、停止して起動、のいずれかを行ないます。
httpd.conf を編集する前に、まず、オリジナルファイルをコピーする必要があります。バックアップを作成することにより、設定ファイルの編集中に生じた間違いを元に戻す作業が楽になります。
編集を間違ってしまい Web サーバーが正常に機能しなくなった場合は、まず、最近 httpd.conf で編集したパッセージを見直し、タイプミスがないことを確認します。
次に、 Web サーバーのエラーログ /var/log/httpd/error_log を調べます。エラーログは、経験が少ない方には解釈が難しいかもしれませんが、エラーログ内の最後のエントリで役に立つ情報を提示しているはずです。
次のサブセクションには、 httpd.conf に含まれている多くのディレクティブに関する簡単な説明の一覧があります。この説明は完全な詳細ではありません。詳しい詳細については、オンラインの Apache ドキュメント、 http://httpd.apache.org/docs/2.2/ で参照してください。
mod_ssl ディレクティブについての詳細は、オンラインのドキュメント、 http://httpd.apache.org/docs/2.2/mod/mod_ssl.html で参照してください。
AccessFileName
AccessFileName では、サーバーが各ディレクトリ内のアクセス制御情報用に使用するファイルを指定します。デフォルトは .htaccess です。
AccessFileName ディレクティブの直後で、一連の Files タグを使って .ht から始まるファイルにアクセス制御を適用します。これらのディレクティブは、セキュリティのために .htaccess ファイル （あるいは .ht から始まる他のファイル） への Web アクセスを拒否します。
動作
Action は、 MIME の内容のタイプと CGI スクリプトペアを指定します。したがって、該当するメディアタイプのファイルが要求された場合にはその指定の CGI スクリプトが実行されます。
AddDescription
FancyIndexing を IndexOptions パラメータとして使用する際、 AddDescription は、サーバー生成のディレクトリ一覧で特定ファイルのユーザー指定詳細やファイルタイプを表示するのに使用できます。 AddDescription ディレクティブは、一覧特殊ファイル、ワイルドカード表記、ファイル拡張子をサポートします。
AddEncoding
AddEncoding は、特定のエンコードタイプを指定する必要のあるファイル名拡張子を指定します。 AddEncoding を使用すれば、ある種のブラウザに対して、特定のファイルのダウンロード時にそれらのファイルを解凍するように指示することもできます。
AddHandler
AddHandler は、ファイル拡張子を特定のハンドラにマッピングします。たとえば、 .cgi で終わるファイルを自動的に CGI スクリプトとして扱うために、 cgi-script ハンドラを拡張子 .cgi に合致させることができます。以下は、 .cgi 拡張子に対する AddHandler ディレクティブの例です。
AddHandler cgi-script .cgi
このディレクティブで、 cgi-bin の外にある CGI が、ディレクトリコンテナ内に ExecCGI オプションを持つサーバー上にあるどのディレクトリでも機能するようできます。ディレクトリの ExecCGI オプションを設定する方法についての詳細は、 ディレクトリ を参照してください。
CGI スクリプトだけではなく、 AddHandler ディレクティブは、サーバー解析された HTML やイメージマップファイルを処理するのに使用されます。
AddIcon
AddIcon は、サーバー生成のディレクトリ一覧で、特定の拡張子を持つファイルに表示するアイコンを指定します。たとえば、 Web サーバーは、 binary.gif アイコンを拡張子が .bin か、 .exe のファイルに表示するよう設定されています。
AddIconByEncoding
このディレクティブは、サーバー生成のディレクトリ一覧で、 MIME エンコードされたファイルごとに表示するアイコンを指定します。デフォルトでは、 Web サーバーは、 compressed.gif アイコンをサーバー生成のディレクトリ一覧で MIME エンコードされた x-compress ファイルと x-gzip ファイルの隣に表示します。
AddIconByType
このディレクティブは、サーバー生成のディレクトリ一覧で、 MIME タイプを持ったファイルの隣に表示するアイコンを指定します。たとえば、サーバーは、 text.gif アイコンをサーバー生成のディレクトリ一覧で mime タイプが text であるファイルの隣に表示します。
AddLanguage
AddLanguage は、ファイル名拡張子と特定の言語を関連付けます。このディレクティブは、クライアントの Web ブラウザの言語設定に基づいて、複数の言語でコンテントを処理する Apache HTTP Servers に便利です。
AddType
AddType ディレクティブを使用して、デフォルトの MIME タイプとファイル拡張子の組み合わせを定義または上書きします。以下のディレクティブの例は、 Apache HTTP Server に .tgz ファイル拡張子を認識するよう伝えています。
AddType application/x-tar .tgz
Alias
Alias を設定すれば、 DocumentRoot ディレクトリの外にあるディレクトリにもアクセスできるようになります。末尾がエイリアスである URL はすべて自動的に解決され、エイリアスのパスに変換されます。デフォルトで、 icons/ ディレクトリのエイリアスが1つすでに設定されています。 Web サーバーは icons/ ディレクトリに対してアクセスできますが、このディレクトリは DocumentRoot にはありません。
Allow
Allow は、特定のディレクトリにアクセスできるクライアントを指定します。クライアントは、 all 、ドメイン名、 IP アドレス、部分的な IP アドレス、ネットワーク/ネットマスクのペアなどで指定することができます。 DocumentRoot ディレクトリは all 、つまりすべての人からの要求を Allow （許可）するように設定されます。
AllowOverride
AllowOverride ディレクティブは、 .htaccess ファイル内の宣言で Options をオーバーライドできるかどうかを設定します。デフォルトでは、 root ディレクトリと DocumentRoot はともに .htaccess のオーバーライドを可能にしないように設定されます。
BrowserMatch
BrowserMatch ディレクティブを使用すれば、サーバーは環境変数を定義したり、ユーザーエージェントの HTTP ヘッダフィールドに基づいて、適切なアクションを実行したりすることができます — クライアントの Web ブラウザを識別します。デフォルトでは、 Web サーバーは BrowserMatch を使用して、既知の問題を含む特定のブラウザに対する接続を拒否したり、 keepalive や HTTP ヘッダーフラッシュに関して問題のあるブラウザについてそれらのアクションを無効化したりします。
キャッシュ関連ディレクティブ
コメントされた多くのキャッシュディレクティブがデフォルトの Apache HTTP Server 設定ファイルで提供されています。ほとんどの場合、コメントを外すには、行の先頭にあるハッシュマーク # を削除すれば十分です。しかし、以下に重要なキャッシュ関連のディレクティブをいくつか一覧にして示します。
-
CacheEnable— そのキャッシュが、ディスクのキャッシュ、メモリのキャッシュ、ファイルディスクリプタのキャッシュのいずれになるのか指定します。デフォルトで、CacheEnableは、/あるいは その配下で URL 用のディスクキャッシュを設定します。 -
CacheRoot— キャッシュされたファイルを格納するディレクトリの名前を指定します。デフォルトのCacheRootは/var/httpd/proxy/ディレクトリです。 -
CacheSize— キャッシュとして使用できる領域のサイズを KB (キロバイト) 単位で指定します。デフォルトのCacheSizeは5KB です。
以下の一覧は、その他一般的なキャッシュ関連のディレクティブです。
-
CacheMaxExpire— HTML ドキュメントが (元の Web サーバーからの再ロードなしで) キャッシュに保存される期間を指定します。デフォルトは24時間です (86400秒) 。 -
CacheLastModifiedFactor— 独自の有効期限セット付きで元のサーバーから送信されなかったドキュメントの有効期限の作成を指定します。デフォルトのCacheLastModifiedFactorは0.1に設定されています。つまり、このようなドキュメントの有効期限は、そのドキュメントが最後に修正されてから経過した時間の長さの10分の1に等しくなります。 -
CacheDefaultExpire— 有効時間をサポートしていないプロトコルを使用して受信されたドキュメントの有効時間を時間単位で指定します。デフォルトは1時間に設定されています (3600秒) 。 -
NoProxy— サブネット、 IP アドレス、ドメイン、またはホストの空白で区切られた一覧を指定します。これらのコンテントはキャッシュされません。この設定はイントラネットサイトにたいへん便利です。
CacheNegotiatedDocs
デフォルトでは、 Web サーバーは内容に基づいてネゴシエートされたすべてのドキュメント （すなわち、一定期間に変化する可能性があるか、リクエスタからの入力があったため） をキャッシュしないようにプロキシサーバーに依頼します。 CacheNegotiatedDocs が on に設定されると、この機能が無効になり、プロキシサーバーはドキュメントのキャッシュを許可されます。
CustomLog
CustomLog はログファイルとログファイル形式を識別します。デフォルトで、アクセスログは /var/log/httpd/access_log ファイルに記録され、エラーログは /var/log/httpd/error_log ファイルに記録されます。
デフォルトの CustomLog 形式は、以下に示すように、 combined ログファイルの形式です。
remotehost rfc931 user date "request" status bytes referrer user-agentDefaultIcon
DefaultIcon は、サーバー生成のディレクトリ一覧で、アイコンが特別に指定されていないファイルに表示するアイコンを指定します。 unknown.gif イメージファイルがデフォルトです。
DefaultType
DefaultType は、 MIME タイプを決定できない文書に使用する、 Web サーバーのデフォルト ContentType を設定します。デフォルトは text/plain です。
Deny
Deny は Allow と似たような機能ですが、誰がアクセスを拒否されるかを指定します。 DocumentRoot は、デフォルトでは誰からの要求も Deny （拒否する） ようには設定されていません。
ディレクトリ
<Directory /path/to/directory> タグと </Directory> タグは、特定ディレクトリとそのサブディレクトリだけに適用する設定ディレクティブのグループを囲むのに使用されるコンテナを作成します。ディレクトリに適用できるディレクティブはすべて、 Directory タグで囲んで使用できます。
デフォルトでは、 Options ディレクティブ （Optionsを参照） と AllowOverride ディレクティブ （AllowOverride を参照） を使って、非常に制限的なパラメータがルートディレクトリ (/) に適用されます。この設定では、寛容な設定を必要とするシステム上のすべてのディレクトリにこれらの設定を明示的に与える必要があります。
デフォルトの設定では、別の Directory コンテナが、厳密ではないパラメータをディレクトリツリーに割り当てる DocumentRoot 用に設定されます。これにより、 Apache HTTP Server がそこにあるファイルにアクセスすることができます。
Directory コンテナは、 ScriptAlias ディレクティブ内で指定されているディレクトリの外にあるサーバー側アプリケーション用の追加の cgi-bin ディレクトリを設定するのにも使用することができます。 (詳細は ScriptAlias を参照して下さい) 。
これを行なうには、 Directory コンテナが、そのディレクトリに ExecCGI オプションを設定する必要があります。
例えば、 CGI スクリプトが /home/my_cgi_directory にある場合、以下の Directory コンテナを httpd.conf ファイルに追加します。
<Directory /home/my_cgi_directory> Options +ExecCGI </Directory>
次に、 AddHandler ディレクティブのコメントを外して、 .cgi 拡張子を持つファイルを CGI スクリプトとして認識する必要があります。 AddHandler の設定方法については、 AddHandler を参照してください。
これを機能させるには、 CGI スクリプトのパーミッションとスクリプトへのパス全体を 0755 に設定する必要があります。
ディレクトリインデックス
DirectoryIndex は、ユーザーがディレクトリ名の終わりにスラッシュ （/） を指定してディレクトリのインデックスを要求したときにサーバーで処理されるデフォルトページです。
ユーザーが http://example/this_directory/ のページを要求すると、 DirectoryIndex ページが存在すればそのページを取得し、なければサーバーが生成したディレクトリ一覧を取得します。 DirectoryIndex のデフォルトは index.html と index.html.var タイプのマップです。サーバーはこれらのどちらかのファイルを探し、最初に見つかったファイルを返します。これらのファイルが見つからず、そのディレクトリに対して Options Indexes が設定されると、ディレクトリ一覧機能がオフになっていない限り、サーバーはディレクトリ内のサブディレクトリとファイルの一覧を HTML 形式で生成して返します。
ドキュメントルート
DocumentRoot は、要求に対応して処理されるほとんどの HTML ファイルを含むディレクトリです。非セキュア Web サーバー及びセキュア Web サーバーのデフォルト DocumentRoot はいずれも /var/www/html/ ディレクトリです。たとえば、サーバーは次のドキュメントに対する要求を受信したとします:
http://example.com/foo.html
サーバーは、デフォルトのディレクトリで次のファイルを探します。
/var/www/html/foo.html
セキュア Web サーバーと非セキュア Web サーバーで共有されないように、 DocumentRoot を変更するには、 項10.7. 「仮想ホスト」 を参照してください。
エラードキュメント
ErrorDocument ディレクティブは、 HTTP レスポンスコードをクライアントに返信されるメッセージや URL に関連付けます。デフォルトでは、 Web サーバーはエラーが発生するとシンプルで通常は暗号化されたエラーメッセージを出力します。 ErrorDocument ディレクティブは、代わりに Web サーバーがカスタマイズされたメッセージやページを出力するよう強制します。
重要
有効にするには、メッセージが2つの二重引用符 " で囲まれる 必要があります。
エラーログ
ErrorLog は、サーバーのエラーを記録するファイルを指定します。デフォルトでは、このディレクティブは /var/log/httpd/error_log に設定されます。
ExtendedStatus
ExtendedStatus ディレクティブは、 server-status ハンドラが呼び出されるときに、 Apache が基本サーバーステータス情報を作成するか （off） 、詳細なサーバーステータス情報を作成するか （on） を管理します。 server-status は、 Location タグで呼び出されます。 server-status を呼び出す手順の詳細は、 Location に示されています。
グループ
Apache HTTP Server プロセスのグループ名を指定します。
このディレクティブは、仮想ホスト設定には役に立たなくなっています。
デフォルトで、 Group は apache に設定されています。
HeaderName
HeaderName は、サーバー生成のディレクトリ一覧の先頭に追加されるファイルがディレクトリ内に存在すれば、それを指定します。 ReadmeName と同様に、可能であればサーバーはそのファイルを HTML ドキュメントとして含むことを試み、不可能であればプレーンテキストとして含むことを試みます。
HostnameLookups
HostnameLookups は、 on 、 off 、 double のどれかに設定できます。 HostnameLookups が on に設定されると、サーバーは自動的に各接続の IP アドレスを解決します。 IP アドレスの解決とは、サーバーが DNS サーバーに1つまたは複数の接続を行ない、オーバーヘッド処理を追加します。 HostnameLookups が double に設定されると、サーバーは二重逆引き DNS 検索を実行し、さらに多くのオーバーヘッド処理を追加します。
サーバー上のリソースを節約するために、 HostnameLookups はデフォルトで off に設定されます。
サーバーログファイル内のホスト名が必要とされる場合は、効率よく一括で DNS の検索を行える多数のログアナライザツールの1つを、 Web サーバーログファイルを巡回するときに実行してみるのもよいでしょう。
IfDefine
IfDefine タグは、「テスト」で IfDefine タグが真 (true) である場合に、適用される設定ディレクティブを囲みます。「テスト」が偽 (false) である場合には、ディレクティブは無視されます。
IfDefine タグ内のテストはパラメータ名です （例、 HAVE_PERL） 。パラメータが定義される、つまりサーバーの起動コマンドに対して引数として与えられる場合、テストは真 (true) になります。この場合、 Web サーバーが起動すると、テストは真 (true) になり、 IfDefine タグを含むディレクティブが適用されます。
IfModule
<IfModule> タグと </IfModule> タグは、条件付きのコンテナを作成し、指定されたモジュールが読み込まれる場合にのみ起動されます。 IfModule コンテナ内のディレクティブは、2つの条件のうちの1つで処理されます。ディレクティブは、開始 <IfModule> タグ内のモジュールが読み込まれると処理されます。または、モジュール名の前に「!」 （感嘆符） が付いて指定されている場合、 <IfModule> タグに指定されているモジュールが 読み込まれなかった 場合にのみディレクティブは処理されます。
Apache HTTP Server モジュールの詳細については、 項10.6. 「モジュールを追加する」 を参照してください。
Include
Include で、実行時に他の設定ファイルを含むようにすることができます。
これらの設定ファイルへのパスは絶対パスか ServerRoot に対する相対パスにします。
重要
個別にパッケージ化されたモジュールを使用するサーバーの場合、 mod_ssl 、 mod_perl 、 php など、以下のディレクティブが httpd.conf の Section 1: Global Environment に含まれる必要があります。
Include conf.d/*.conf
IndexIgnore
IndexIgnore は、ファイル拡張子、部分ファイル名、ワイルドカード表記、完全なファイル名などを一覧表示します。 Web サーバーは、これらのパラメータと一致するファイルをサーバーが生成するディレクトリ一覧から除外します。
IndexOptions
IndexOptions は、アイコン、ファイルの説明などを追加することによって、サーバーが生成するディレクトリ一覧の外見を制御します。 Options Indexes を設定すると （Optionsを参照） 、 Web サーバーがインデックスのないディレクトリの HTTP 要求を受信した際に、ディレクトリ一覧を生成します。
Web サーバーは、まず、 DirectoryIndex ディレクティブに記載されている名前と合致するファイル （通常、 index.html） を要求されたディレクトリで調べます。 index.html ファイルが見つからなかった場合、 Apache HTTP Server は要求されたディレクトリの HTML ディレクトリ一覧を作成します。このディレクトリ一覧の外観は、部分的に、 IndexOptions ディレクティブで制御されます。
デフォルトの設定では FancyIndexing が on になっています。コラムヘッダをクリックすると、ユーザーは表示順序を並べ替えることができます。同じヘッダーをもう一度クリックすると、昇順と降順が切り替わって元に戻ります。 FancyIndexing は、ファイル拡張子の種類に基づいて、ファイルごとに異なるアイコンを表示します。
AddDescription オプションは、 FancyIndexing と連結して使用すると、サーバー生成のディレクトリ一覧のファイルに対して簡単な説明を表示します。
IndexOptions にはほかにもいくつかのパラメータがあり、それらを設定することで、サーバーが生成するディレクトリの外見を制御することができます。 IconHeight と IconWidth パラメータはサーバー生成の web ページ内のアイコン用の HTML HEIGHT と WIDTH のタグを含めるようにサーバーに要求します。 IconsAreLinks パラメータは、 URL リンクターゲットを収納した HTML リンクアンカーをグラフィカルアイコンに組み合わせます。
KeepAlive
KeepAlive は、サーバーが接続あたり複数の要求を許可するかどうかを設定し、あるクライアントがサーバーのリソースを消費しすぎないようにするために使用することができます。
デフォルトでは、 Keepalive は off に設定されます。 Keepalive を on に設定しサーバーが非常にビジーになると、サーバーは素早く最大数の子プロセスを生成します。この状況では、サーバーは重大なスローダウンに陥ります。 Keepalive を有効にする場合は、 KeepAliveTimeout （KeepAliveTimeout を参照） を低く設定し、サーバー上の /var/log/httpd/error_log ログファイルを監視します。このログは、サーバーに子プロセスが不足した時にレポートします。
KeepAliveTimeout
KeepAliveTimeout は、要求がなされてから接続を閉じるまでの、サーバーが待機する時間を秒数で設定します。サーバーが要求を受信すると、代わりに Timeout ディレクティブが適用されます。デフォルトでは、 KeepAliveTimeout は15秒に設定されます。
LanguagePriority
LanguagePriority は、クライアントの Web ブラウザに言語選択の設定がない場合、異なる言語の優先順位を設定します。
Listen
Listen コマンドは、着信要求を受ける Web サーバー上のポートを識別します。デフォルトでは、 Apache HTTP Server は、非セキュア Web 通信用のポート 80 と、 （セキュアサーバーを定義する /etc/httpd/conf.d/ssl.conf ファイル内で） セキュア Web 通信用のポート 443 をリスニングするように設定されます。
1024 の下のポートをリスニングするように Apache HTTP Server を設定する場合、起動できるのは root ユーザーのみです。ポート 1024 以上の場合は、通常のユーザーとして httpd を起動できます。
また、 Listen ディレクティブは、接続を受けるサーバーで特定の IP アドレスを指定するのに使用することもできます。
LoadModule
LoadModule は、ダイナミック共有オブジェクト （DSO） モジュールをロードするのに使用します。 LoadModule ディレクティブの使用方法など、 Apache HTTP Server の DSO サポートの詳細は、 項10.6. 「モジュールを追加する」 を参照してください。 Apache HTTP Server 2.0 では、モジュールをロードする順序は 重要ではなくなりました 。 Apache HTTP Server 2.0 DSO サポートについての詳細は、 項10.2.2.1.3. 「Dynamic Shared Object (DSO) のサポート」 を参照してください。
Location
<Location> タグと </Location> タグは、 URL に基づくアクセス制御を指定できるコンテナを作成します。
例えば、サーバーのドメイン内から接続している人にサーバーステータスレポートの参照を許可するには、次のディレクティブを使用します。
<Location /server-status> SetHandler server-status Order deny,allow Deny from all Allow from <.example.com> </Location>
<.example.com> の部分には、 Web サーバーのセカンドレベルのドメイン名を入れます。
ドメイン内部からの要求に対してサーバー設定レポート （インストール済みのモジュールと設定ディレクティブを含む） を提供するには、以下のディレクティブを使用します。
<Location /server-info> SetHandler server-info Order deny,allow Deny from all Allow from <.example.com> </Location>
ここでも、 <.example.com> の部分には、 Web サーバーのセカンドレベルのドメイン名を入れます。
LogFormat
LogFormat ディレクティブは各種の Web サーバーログファイルの 形式を設定します。実際に使用される LogFormat は、 CustomLog ディレクティブで与えられる設定によります (CustomLog を参照してください) 。
CustomLog ディレクティブが combined に設定される場合の形式オプションを以下に示します。
-
%h(リモートホストの IP アドレスまたはホスト名) -
要求クライアントのリモート IP アドレスを一覧表示します。
HostnameLookupsがonに設定されると、クライアントホスト名は、 DNS から取得できない場合を除いて記録されます。 -
%l(rfc931) -
未使用。ログファイルの中の該当フィールドに - (ハイフン) が表示されます。
-
%u(認証されたユーザー) -
認証が要求された場合、記録されるユーザーのユーザー名を一覧表示します。通常、これは使用されないので、ログファイルの該当フィールドには - (ハイフン) が表示されます。
-
%t(日付) -
要求の日時を一覧表示します。
-
%r(要求文字列) -
ブラウザまたはクライアントから送信されたものとまったく同じ要求文字列を一覧表示します。
-
%s(ステータス) -
クライアントホストに返された HTTP ステータスコードを一覧表示します。
-
%b(バイト) -
ドキュメントのサイズを一覧表示します。
-
%\"%{Referer}i\"(参照) -
Web サーバーにクライアントホストを参照したウェブページの URL を一覧表示します。
-
%\"%{User-Agent}i\"(ユーザーエージェント) -
要求を行っている Web ブラウザのタイプを一覧表示します。
LogLevel
LogLevel は、エラーログのエラーメッセージの詳細区分レベルを設定します。 LogLevel は、 （詳細区分が少いものから最も高いレベルまでの順に） emerg、 alert、 crit、 error、 warn、 notice、 info、 debug のいずれかに設定できます。デフォルトの LogLevel は warn です。
MaxKeepAliveRequests
このディレクティブは、永続的な接続ごとに可能な最大要求数を設定します。 Apache Project では、サーバーのパフォーマンスを向上する高い設定を推奨しています。 MaxKeepAliveRequests はデフォルトで 100 に設定されますが、ほとんどの場合変更する必要はないでしょう。
NameVirtualHost
NameVirtualHost ディレクティブは、必要に応じて、名前ベースの仮想ホスト用の IP アドレスとポート番号を関連付けます。名前ベースの仮想ホストで、 Apache HTTP Server が複数の IPアドレスを使うことなく異なるドメインを処理することができます。
注記
名前ベースの仮想ホストは非セキュアな HTTP 接続で のみ 機能します。セキュアサーバーで仮想ホストを使用している場合は、代わりに、 IP アドレスベースの仮想ホストを使用します。
名前ベースの仮想ホストを有効にするには、 NameVirtualHost 設定ディレクティブのコメントマークを外し、正しい IP アドレスを追加します。次に、設定の必要に応じて各仮想ホスト用の VirtualHost コンテナを更に追加します。
Options
Options ディレクティブは、どのサーバー機能が特定のディレクトリで使用できるかを制御します。たとえば、ルートディレクトリに対して指定された制限的なパラメータで、 Options は FollowSymLinks ディレクティブだけに設定されます。サーバーはルートディレクトリ内のシンボリックリンクをたどることが許されているという点以外、有効にされる機能はありません。
デフォルトでは、 DocumentRoot ディレクトリで、 Indexes と FollowSymLinks を含むように Options が設定されます。 Indexes を使用すると、指定された DirectoryIndex （例、index.html） がない場合、サーバーはディレクトリ一覧を表示するディレクトリを作成します。 FollowSymLinks を使用すると、サーバーはそのディレクトリ内のシンボリックリンクをたどることができます。
注記
メインサーバーの設定セクションにある Options ステートメントが、各 VirtualHost コンテナに個別に複製される必要があります。詳細情報は、 VirtualHost を参照してください。
Order
Order ディレクティブは、 allow ディレクティブと deny ディレクティブが評価される順序を制御します。サーバーは、 DocumentRoot の Deny ディレクティブの前に Allow ディレクティブを評価するように設定されます。
PidFile
PidFile は、サーバーがプロセス ID （PID） を記録するファイルを指定します。デフォルトでは、 PID は /var/run/httpd.pid に記載されます。
Proxy
<Proxy *> タグと </Proxy> タグは、プロキシサーバーにのみ適用するよう設定ディレクティブのグループを囲むコンテナを作成します。 <Directory> コンテナ内で使用できる多くのディレクティブは、 <Proxy> コンテナ内でも使用できる可能性があります。
ProxyRequests
プロキシサーバーとして Apache HTTP Server が機能するよう設定するには、 <IfModule mod_proxy.c> 行の先頭にあるハッシュマーク (#) 、 ProxyRequests 及び <Proxy> スタンザの各行を削除します。 ProxyRequests ディレクティブを On にセットし、 <Proxy> スタンザの Allow from ディレクティブ内でどのドメインがサーバへのアクセス許可をされるかを設定します。
ReadmeName
ReadmeName は、サーバー生成のディレクトリ一覧の末尾に追加されるファイルがディレクトリ内に存在すれば、それを指定します。 Web サーバーはまずそのファイルを HTML ドキュメントとして含むことを試み、次にプレーンテキストとして含むことを試みます。デフォルトでは、 ReadmeName は README.html に設定されます。
Redirect
web ページを移動する場合は、 Redirect を使用してファイルの場所を新しい URL にマッピングすることができます。フォーマットは以下のとおりです。
Redirect /<old-path>/<file-name> http://<current-domain>/<current-path>/<file-name>
この例では、 <old-path> の部分には、 <file-name> の古いパス情報を入れ、 <current-domain> と <current-path> の部分には、現在のドメインと <file-name> の現在のパス情報を入れます。
この例では、古い場所での <file-name> に対する要求はすべて自動的に新しい場所へリダイレクトされます。
高度なリダイレクト技術には、 Apache HTTP Server と共に含まれている mod_rewrite モジュールを使用します。 mod_rewrite モジュールの設定方法についての詳細は、 Apache Software Foundation のドキュメントをオンラインの http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html で参照してください。
ScriptAlias
ScriptAlias ディレクティブは、 CGI スクリプトの場所を定義します。一般的には、それらのスクリプトがテキスト文書として参照される恐れがあるので、 CGI スクリプトを DocumentRoot の中に残しておくべきではありません。この理由から、 DocumentRoot ディレクトリの外にありサーバー側で実行可能ファイルやスクリプトを含む特殊ディレクトリは、 ScriptAlias ディレクティブで指定されます。このディレクトリは、 cgi-bin として知られ、デフォルトで /var/www/cgi-bin/ に設定されます。
cgi-bin/ ディレクトリの外に実行可能形式のファイルを収納するためのディレクトリを設置することが可能です。これを行なう手順については、 AddHandler と ディレクトリ を参照してください。
ServerAdmin
ServerAdmin ディレクティブを Web サーバー管理者の電子メールアドレスに設定します。このメールアドレスは、サーバーが生成した Web ページのエラーメッセージに表示されるので、ユーザーが電子メールをサーバー管理者に送信することで問題を報告することができます。
デフォルトで、 ServerAdmin は root@localhost に設定されます。
ServerAdmin を設定する一般的な方法は、 webmaster@example.com に設定することです。次に、 webmaster を /etc/aliases 内で Web サーバー担当者にエイリアスし、 /usr/bin/newaliases を実行します。
ServerName
ServerName は、サーバーのホスト名とポート番号 (Listen ディレクティブと合致する) を指定します。 ServerName は、マシンの実際のホスト名と合致する必要はありません。例えば、 Web サーバーは www.example.com で、サーバーのホスト名は実際には foo.example.com であっても構いません。 ServerName で指定される値は、システムで解決できる有効な DNS (Domain Name Service) 名でなければなりません。 — 無効な値を作成しないでください。
以下に ServerName ディレクティブの例を示します。
ServerName www.example.com:80
ServerName を指定する場合は、その IP アドレスとサーバー名の組が /etc/hosts ファイルに含まれていることを確認してください。
ServerRoot
ServerRoot ディレクティブは、ウェブサイトのコンテントを含むトップレベルのディレクトリです。デフォルトでは、セキュアサーバー、非セキュアサーバーいずれに対しても、 ServerRoot は "/etc/httpd" に設定されます。
ServerSignature
ServerSignature ディレクティブは、 Apache HTTP Server サーバーのバージョンと ServerName を含む行を、クライアントに返信したエラーメッセージなどのサーバーが生成する文書に追加します。デフォルトで、 ServerSignature は on に設定されます。
Order ディレクティブは、 allow ディレクティブと deny ディレクティブが評価される順序を制御します。サーバーは、 DocumentRoot の Deny ディレクティブの前に Allow ディレクティブを評価するように設定されます。
ServerTokens
もしサーバーのレスポンスヘッダーフィールドがクライアントに返された場合、オペレーティングシステムやコンパイルされたモジュールについての詳細を含めるべきかを ServerTokens ディレクティブが決定します。デフォルトでは、 ServerTokens は、 OS のタイプとコンパイルされたモジュールについての情報を送信する Full に設定されています。 ServerTokens を Prod に設定すると、製品名のみを送信します。また、多くのハッカーが脆弱性をスキャンするときサーバーヘッダーの情報をチェックるので推奨されています。また、 ServerTokens を Min (最小) もしくは OS (オペレーティングシステム) に設定することもできます。
SuexecUserGroup
mod_suexec モジュールを基点にする SuexecUserGroup ディレクティブは CGI プログラムの為のユーザーとグループの権限実行の指定を許可します。非 CGI 要求は未だに、 User と Group ディレクティブ内に指定されたユーザーとグループで処理されています。
注記
バージョン 2.0 から SuexecUserGroup ディレクティブは VirtualHosts セクションの設定の中で、 User と Group の使用に関して Apache HTTP Server 1.3 の設定の入れ替わりとなります。
Timeout
Timeout は、サーバーが通信中に送受信を待つ時間を秒単位で定義します。デフォルトでは、 Timeout は300秒に設定されており、ほとんどの場合変更する必要はないでしょう。
TypesConfig
TypesConfig は、 MIME タイプマッピング （ファイル名拡張子から ContentTypeへ） のデフォルト一覧を設定するファイルを指定します。デフォルトの TypesConfig ファイルは /etc/mime.types です。 /etc/mime.types を編集する代わりに、 MIME タイプマッピングを追加する方法として望ましいのは、 AddType ディレクティブを使用する方法です。
AddType の詳細については、 AddType を参照してください。
UseCanonicalName
on に設定すると、このディレクティブは、 ServerName ディレクティブと Port ディレクティブで指定された値を使って、 Apache HTTP Server が自身を参照するよう設定します。 UseCanonicalName が off に設定されると、代わりにサーバーは自身を参照するときにクライアントの要求で使われる値を使用します。
デフォルトで、 UseCanonicalName は off に設定されます。
User
User ディレクティブは、サーバープロセスのユーザー名を設定し、サーバーがアクセスを許可されるファイルを決定します。このユーザーがアクセスできないファイルはすべて、 Apache HTTP Server に接続しているクライアントにもアクセスできません。
デフォルトで、 User は apache に設定されます。
このディレクティブは、仮想ホスト設定には役に立たなくなっています。
注記
セキュリティの理由で、 Apache HTTP Server は root ユーザーによる実行を拒否します。
UserDir
UserDir は、 Web サーバーで処理されるパーソナル HTML ファイルを配置する各ユーザーのホームディレクトリ内のサブディレクトリです。このディレクティブはデフォルトでは disable に設定されます。
デフォルトの設定では、サブディレクトリの名前は public_html に設定されます。たとえば、サーバーは次のような要求を受信する場合があります。
http://example.com/~username/foo.html
この場合、サーバーは次のファイルを探します。
/home/username/public_html/foo.html
上記の例では、 /home/username はユーザーのホームディレクトリです （ユーザーのホームディレクトリへのデフォルトパスは異なる場合があるので注意してください）。
ユーザーのホームディレクトリ上の権限が正しく設定されていることを確認してください。ユーザーのホームディレクトリは、 0711 に設定する必要があります。 read （r） ビットと execute （x） ビットは、ユーザーの public_html ディレクトリ （0755 も有効） に設定する必要があります。ユーザーの public_html ディレクトリ内で処理されるファイルは、少なくとも 0644 に設定する必要があります。
VirtualHost
<VirtualHost> タグと </VirtualHost> タグで、仮想ホストの特性を外接するコンテナを作成します。 VirtualHost コンテナはほとんどの設定ディレクティブに応じます。
コメントアウトされた VirtualHost コンテナが httpd.conf に提供されており、各仮想ホストに必要な設定ディレクティブの最小限の組み合わせを例示しています。仮想ホストについての詳細は、 項10.7. 「仮想ホスト」 を参照してください。
注記
デフォルトの SSL 仮想ホストコンテナは /etc/httpd/conf.d/ssl.conf ファイルに移動しています。
/etc/httpd/conf.d/ssl.conf ファイルのディレクティブを使用して、 SSL と TLS でセキュア Web 通信を有効にすることができます。
SetEnvIf
SetEnvIf で受信接続のヘッダに基づき環境変数を設定します。単独の SSL ディレクティブ ではありません が、供給されている /etc/httpd/conf.d/ssl.conf ファイルにあります。このコンテクストの目的は、 HTTP keepalive を無効にして、 SSL がクライアントブラウザからのクローズ通知案内なしに接続を閉じることができるようにすることです。この設定は、 SSL 接続を確実にシャットダウンしない特定ブラウザに必要となります。
SSL 設定ファイル内の他のディレクティブに関する詳細については、以下の URL アドレスで参照して下さい:
-
http://localhost/manual/mod/mod_ssl.html
注記
ほとんどの場合、 SSL ディレクティブは Red Hat Enterprise Linux のインストール時に適切に設定されます。誤った設定はセキュリティ上の脆弱性を招く恐れがあるので、 Apache HTTP セキュアサーバーのディレクティブを変更するときは十分注意してください。
項10.2.2.1.2. 「サーバープールのサイズ規定」 で説明されているように、 Apache HTTP Server 2.0 環境下では、サーバープールの特性を管理するのは、 MPM と呼ばれるモジュールグループに任されます。サーバープールの特性は使用される MPM によって異なります。このため、使用中の MPM 用のサーバープールを定義するために、 IfModule コンテナが必要となります。
デフォルトでは、 Apache HTTP Server 2.0 は、 prefork と worker 、両方の MPM のサーバープールを定義します。
MPM 固有サーバープールのコンテナ内にあるディレクティブの一覧を以下に示します。
MaxClients
MaxClients は、サーバープロセスの総数または同時に接続されるクライアントの数に制限を設定します。これは一度に実行できます。このディレクティブの主な目的は、 Apache HTTP Server がオペレーティングシステムをクラッシュさせるのを防ぐためです。ビジーなサーバーの場合には、この値を高く設定する必要があります。サーバーのデフォルトは使用中の MPM に関わらず 150 に設定されます。ただし、 prefork MPM を使用するときには、 MaxClients の値が 256 を超えることはおすすめできません。
MaxRequestsPerChild
MaxRequestsPerChild は、子プロセスが停止するまでそれぞれの子サーバープロセスが処理する要求の総数を設定します。 MaxRequestsPerChild を設定する主な理由は、長期に生き続けるプロセスで誘導されるメモリリークを回避するためです。 prefork MPM のデフォルトの MaxRequestsPerChild は 4000 で、 worker MPM のデフォルトは 0 です。
MinSpareServers と MaxSpareServers
これらの値は prefork MPM でのみ使用されます。これらの値は、着信要求の数に基づいて適切な数のスペアサーバープロセスを維持することで、 Apache HTTP Server が検出された負荷に対して動的に適応する方法を調整します。このサーバーは要求を待つサーバーの数をチェックして、 MaxSpareServers 以上ある場合にはいくつかのサーバーを停止し、 MinSpareServers 以下の場合にはいくつかのサーバーを作成します。
デフォルトの MinSpareServers 値は 5 で、デフォルトの MaxSpareServers 値は 20 です。ほとんどの場合、これらのデフォルト設定を変更する必要はないでしょう。 MinSpareServers を大きい数字にしないよう注意してください。数字を大きくすると、トラフィックが軽くてもサーバーに重い処理負荷がかかることになります。
MinSpareThreads と MaxSpareThreads
これらの値は worker MPM でのみ使用されます。これらの値は、着信要求の数に基づいて適切な数のスペアサーバースレッドを維持することで、 Apache HTTP Server が検出された負荷に動的に適応する方法を調整します。このサーバーは要求を待つサーバースレッドの数をチェックして、 MaxSpareThreads 以上ある場合にはいくつかのサーバーを停止し、 MinSpareThreads 以下の場合にはいくつかのサーバーを作成します。
デフォルトの MinSpareThreads 値は 25 で、 デフォルトの MaxSpareThreads 値は 75 です。これらのデフォルト設定は、ほとんどの場合において適しています。 MaxSpareThreads の値は、 MinSpareThreads と ThreadsPerChild の合計値と同等またはそれ以上にしてください。あるいは、 Apache HTTP Server が自動的に調整します。
StartServers
StartServers ディレクティブは、起動時に作成されるサーバープロセス数を設定します。 Web サーバーがトラフィックの負荷に基づいて動的にサーバープロセスを停止したり作成したりするので、このパラメータを変更する必要はありません。 Web サーバーは、起動時に、 prefork MPM 用に 8 サーバープロセスを、 worker MPM 用に 2 サーバープロセスを起動するように設定されます。
ThreadsPerChild
この値は、 worker MPM でのみ使用されます。各子プロセス内のスレッドの数を設定します。このディレクティブのデフォルト値は、 25 です。
Apache HTTP Server は多くのモジュールと共に配布されます。 Apache HTTP モジュールに関する全詳細はオンラインの http://httpd.apache.org/docs/2.2/mod/ をご覧ください。
Apache HTTP Server は Dynamically Shared Objects (DSO) またはモジュールをサポートしています。これは、必要に応じて、ランタイムに簡単にロードすることができます。
Apache Project は、完全な DSO のドキュメントを http://httpd.apache.org/docs/2.2/dso.html で公開しています。あるいは、 http-manual パッケージをインストールしている場合は DSO に関するドキュメントがオンラインの http://localhost/manual/mod/ でご覧になれます。
Apache HTTP Server が DSO を使用するためには、 /etc/httpd/conf/httpd.conf 内にある LoadModule ディレクティブで指定する必要があります。モジュールが別のパッケージで提供されている場合は、その行が /etc/httpd/conf.d/ ディレクトリのモジュール設定ファイル内になければなりません。詳細は、 LoadModule を参照してください。
http.conf からモジュールを追加、消去する場合、 項10.3. 「httpd の起動と httpd 停止」 で説明してあるように、 Apache HTTP Server を再ロードまたは再起動しなければなりません。
新しいモジュールを作成している場合は、まず、インクルードファイル、ヘッダファイルを含む httpd-devel パッケージ及び、 DSO をコンパイルするのにインクルードファイルとヘッダファイルを使用する APache eXtenSion (/usr/sbin/apxs) アプリケーションをインストールします。
モジュールを書き終ったら、 /usr/sbin/apxs を使用して Apache ソースツリーの外のモジュールソースをコンパイルします。 /usr/sbin/apxs コマンドの使い方についての詳細は、 Apache ドキュメントオンラインの http://httpd.apache.org/docs/2.2/dso.html 及び、 apxs man ページで参照してください。
コンパイルが完了したら、モジュールを /usr/lib/httpd/modules/ ディレクトリに置きます。 default-64-bit ユーザースペース (x86_64, ia64, ?) を使用したこのパスは /usr/lib64/httpd/modules/ になります。次に、 LoadModule の行を httpd.conf に、以下のような構成を使って追加します。
LoadModule <module-name> <path/to/module.so>
<module-name> では、モジュールの名前にして、 <path/to/module.so> では DSO へのパスに変更します。
Apache HTTP Server に組込みの仮想ホスト機能を使用すれば、要求されている IP アドレス、ホスト名、ポートに基づいて、サーバーが異なる情報を提供できるようにします。仮想ホストの使い方についての詳細ガイドはオンラインの http://httpd.apache.org/docs/2.2/vhosts/ でご覧になれます。
名前ベースの仮想ホストを作成するには、範例として httpd.conf に提供されている仮想ホストコンテナを使用するのが最適です。
仮想ホストの範例は以下のようになります。
#NameVirtualHost *:80 # #<VirtualHost *:80> # ServerAdmin webmaster@dummy-host.example.com # DocumentRoot /www/docs/dummy-host.example.com # ServerName dummy-host.example.com # ErrorLog logs/dummy-host.example.com-error_log # CustomLog logs/dummy-host.example.com-access_log common #</VirtualHost>
名前ベースの仮想ホスト機能を起動するには、ハッシュマーク (#) を削除して、アスタリスク (*) をマシンに割り当てられた IP アドレスに置き換えることで、 NameVirtualHost 行のコメントを外します。
次に、 <VirtualHost> コンテナのコメントマークを外してカスタマイズすることで、仮想ホストを設定します。
<VirtualHost> 行で、アスタリスク (*) をサーバーの IP アドレスに変更します。 ServerName をマシンに割り当てられた 有効な DNS 名に変更し、必要に応じて他のディレクティブを設定します。
<VirtualHost> コンテナは非常にカスタマイズしやすく、メインサーバーの設定内で使用できるディレクティブのほとんどすべてに応じます。
ヒント
仮想ホストがデフォルトではないポートをリスニングするよう設定している場合には、そのポートを /etc/httpd/conf/http.conf ファイルのグローバル設定セクション内の Listen ディレクティブに追加する必要があります。
新たに作成した仮想ホストを起動するには、 Apache HTTP Server を再ロードまたは再起動する必要があります。これを行なう手順については、 項10.3. 「httpd の起動と httpd 停止」 を参照してください。
名前ベースの仮想ホスト及び IP アドレスベースの仮想ホストの作成と設定に関する総合情報は、オンラインの http://httpd.apache.org/docs/2.2/vhosts/ を参照してください。
このセクションでは、 Apache HTTP Server と OpenSSL ライブラリとツールキットの使用を有効化する mod_ssl セキュリティモジュールについての基本的な情報を提供します。これら3つのコンポーネントの組み合わせは、このセクションでセキュアウェブサーバー、もしくは単にセキュアサーバーとして称されます。
mod_ssl モジュールは、 Apache HTTP Server のためのセキュリティモジュールです。 mod_ssl モジュールは、 OpenSSL Project により提供されたツールを使用し、とても重要な機能である通信を暗合化する能力を Apache HTTP Server — に追加します。対照的に、ブラウザとウェブサーバー間の通常の HTTP 通信は、プレーンテキストで送信され、それはブラウザとサーバー間のルートで誰かに遮断され読まれる可能性があります。
このセクションは、これらのどのプログラムにとっても完全で独占的なドキュメントになることを意味していません。可能なときは、このガイドは特定の件についてのより詳細なドキュメントを見つけることのできる適切な場所を指摘します。
このセクションは、これらのパッケージをインストールする方法を示します。また、秘密鍵や証明書のリクエストに必要なステップ、自己署名証明書の生成方法、およびセキュアサーバーを使用しての証明書のインストール方法等について学びます。
mod_ssl 設定ファイルは /etc/httpd/conf.d/ssl.conf にあります。このファイルがロードされ、 mod_ssl が機能するには、ステートメントの Include conf.d/*.conf が /etc/httpd/conf/httpd.conf ファイルになければなりません。このステートメントは、デフォルトの Apache HTTP Server 設定ファイルの中にデフォルトで含まれています。
セキュアサーバーを有効にするには、最低でも以下のパッケージがインストールされている必要があります。
-
httpd -
httpdパッケージは、httpdデーモン、関連するユーティリティ、アイコン、 Apache HTTP Server モジュール、 man ページ、および Apache HTTP Server で使用されるその他のファイルを含みます。 -
mod_ssl -
mod_sslパッケージは、 Secure Sockets Layer (SSL) と Transport Layer Security (TLS) プロトコル経由で Apache HTTP Server に強力な暗合化を提供するmod_sslモジュールを含みます。 -
openssl -
opensslパッケージは、 OpenSSL ツールキットを含みます。 OpenSSL ツールキットは SSL と TLS プロトコルを実装し、汎用の暗合ライブラリも含みます。
更に、他のソフトウェアパッケージは一定のセキュリティ機能を提供します (しかし機能することはセキュアサーバーでは要求されません)。
セキュアサーバーは、 Secure Sockets Layer (SSL) プロトコルと (大抵の場合において) 認証局 (CA) からのデジタル証明書の組み合わせを使用するセキュリティを提供します。 SSL は、ブラウザとセキュアサーバー間の相互認証だけでなく、暗合化された通信を処理します。 CA が承認したデジタル証明書は、セキュアサーバーへの認証を提供します (CA はその評価を組織の ID の裏につけます)。ブラウザが SSL 暗合を使用して通信するとき、プレフィックス https:// がナビゲーションバーの URL のはじめに使用されます。
暗合化は、鍵の使用に依存します (それらをデータフォーマットにおけるエンコーダ/デコーダのリングとして考えてください)。慣用暗号や対称暗号にでは、それらは両方共トランザクションの終わりに同じ鍵を持っています。公開鍵暗号や非対称暗号では、2つの鍵が共存します: 公開鍵と秘密鍵です。個人または組織は、秘密鍵を秘密にし、公開鍵を公開します。公開鍵でエンコードされたデータは、秘密鍵でのみデコードできます; 秘密鍵でエンコードされたデータは、公開鍵でのみデコードできます。
セキュアサーバーをセットアップするには、公開鍵と秘密鍵のペアを作成するのに公開鍵暗号を使用してください。大抵の場合で、証明書リクエスト (公開鍵も含めて)、自分の会社の ID の証明、および支払金を CA に送ります。 CA は証明書リクエストと ID を検証してから、セキュアサーバーのために証明書を送信します。
セキュアサーバーは、それ自信をウェブブラウザに識別させるために証明書を使用します。自分自身の証明書 ("自己署名"証明書と呼ばれます) を生成することや、 CA から証明書を得ることができます。名声のある CA からの証明書は、ウェブサイトが特定の会社や組織と関係があることを保証します。
代わりに、自分自身の自己署名証明書を作成することができます。しかし、その自己署名証明書を本番環境で使用するべきではありません。自己署名証明書はユーザーのウェブブラウザ — では自動的に受諾されません。ユーザーは、ウェブブラウザに証明書を受諾し、セキュアな接続を確立するように促されます。自己署名証明書と CA 発行の証明書の違いについてのより多くの情報については、 項10.8.4. 「証明書のタイプ」 をご参照ください。
自己署名証明書か自分で選択した CA からの署名付き証明書を一旦手にしたら、それをセキュアサーバーにインストールしなければなりません。
もし、既存の鍵と証明書を所有している場合は (例えば、他社のセキュアサーバー製品をリプレイスするためにセキュアサーバーをインストールしている場合等)、おそらくその既存の鍵と証明書をそのセキュアサーバーで使用することができます。以下の2つの状況では、既存の鍵と証明書を使用できない場合の例を提供します。
-
IP アドレスかドメイン名を変更する場合 — 証明書は、特定の IP アドレスとドメイン名のペアに対して発行されます。もし IP アドレスやドメイン名を変更している場合は、新しい証明書を入手しなければなりません。
-
VeriSign からの証明書を所有していて、サーバーソフトウェアを変更する場合 — VeriSign は広く使用されている CA です。もし他の目的で VeriSign の証明書を既に所有している場合、新しいセキュアサーバーで既存の VeriSign の証明書を使用することは検討するほうがいいでしょう。しかし、 VeriSign は１つの特定のサーバーソフトウェアや IP アドレス/ドメイン名の組み合わせに対して証明書を発行しているので、許可されません。
もし、これらのパラメータを1つでも変更したら (例えば、もし以前に別のセキュアサーバー製品を使用した場合)、以前の設定で使用するために入手した VeriSign の証明書は、新しい設定では機能しません。新しい証明書を入手する必要があります。
もしユーザーが使用できる既存の鍵と証明書を持っていれば、ユーザーは新しい鍵を生成する必要も、新しい証明書を入手するも必要もありません。しかし、ユーザーの鍵と証明書を含むファイルは、移動および名前変更する必要があります。
既存のキーファイルを移動する。
/etc/pki/tls/private/server.key
既存の証明書ファイルを移動する。
/etc/pki/tls/certs/server.crt
もし、 Red Hat Secure Web Server からアップグレードする場合、古い鍵 (httpsd.key) や証明書 (httpsd.crt) は、 /etc/httpd/conf/ にあります。鍵と証明書を移動して名前の変更することにより、セキュアサーバーがそれらを使用することができます。鍵と証明書ファイルを移動し名前変更するには、以下の2つのコマンドを使用してください。
mv /etc/httpd/conf/httpsd.key /etc/pki/tls/private/server.key mv /etc/httpd/conf/httpsd.crt /etc/pki/tls/certs/server.crt
それから、コマンドでセキュアサーバーを起動します。
/sbin/service httpd start
もし、 Red Hat から提供された RPM パッケージからセキュアサーバーをインストールした場合、秘密鍵がランダムに生成され、テスト証明書が作成され、適切なディレクトリに配置されます。セキュアサーバーの使用を始める前に、自分の鍵を生成し、サーバーを正しく証明する証明書を入手しなければなりません。
セキュアサーバー — を機能させるには、鍵と証明書が必要になります。これは、自己署名証明書を生成するか、 CA が署名した証明書を CA から購入するかどちらかを意味します。これら2つの違いは何でしょうか?
CA が署名した証明書は、サーバーに2つの重要な機能を提供します:
-
ブラウザは (通常) 証明書を自動で認識し、ユーザーに促すことなくセキュアな接続が確立されるのを許可します。
-
CA が署名付き証明書を発行するとき、ブラウザにウェブページを表示する組織の同一性を保証します。
もしセキュアサーバーが広く一般からアクセスされる場合は、そのセキュアサーバーは CA が署名した証明書が必要になります。そうすることにより、ウェブサイトを訪れた人々が、このウェブサイトはこれを所有すると主張している組織によって所有されている、ということを知ります。証明書に署名する前に、 CA は証明書をリクエストしている組織が実際にそれを主張している組織かどうかを確認します。
SSL をサポートするほとんどのウェブブラウザは、 CA のリストを持っていて、それらの証明書を自動的に受諾します。もしブラウザがリストにない CA が承認する証明書に出会った場合、ブラウザはユーザーに接続を受諾するか拒否するかを確認します。
自分のセキュアサーバーのために自己署名証明書を生成することができますが、自己署名証明書は CA が署名した証明書と同じ機能を提供しないことに注意してください。自己署名証明書は、ほとんどのウェブブラウザで自動認識されず、ウェブサイトを提供する組織の ID に関する保証を提供しません。 CA が署名した証明書は、セキュアサーバーにこれら2つの重要な機能を提供します。もしセキュアサーバーが本番環境で使用される場合は、 CA が署名した証明書が推奨されています。
CA から証明書を手に入れる方法はとても簡単です。簡単な概略は以下の通りです。
-
暗合化された秘密鍵と公開鍵のペアを作成してください。
-
公開鍵に基づいて証明書のリクエストを作成してください。証明書のリクエストは、サーバーとそれをホスティングする会社の情報が含まれます。
-
自分の ID を証明するドキュメントと一緒に証明書のリクエストを CA に送ってください。 Red Hat はどの CA を選択すべきかについて推奨はしません。その決定は、過去の経験、友達や同僚の経験、または純粋に金銭的要因に基づくでしょう。
一度 CA を決定すると、証明書を CA から入手するのに、 CA が提供するインストラクションに従う必要があります。
-
実際に自分自身が自分が主張するものと CA が認めた場合、 CA はデジタル証明書を提供します。
-
この証明書をセキュアサーバーにインストールし、セキュアトランザクションの処理を始めてください。
CA から証明書を得るにしても、自己署名証明書を生成するにしても、第一のステップは鍵を生成することです。説明については、 項10.8.5. 「キーの生成」 をご参照ください。
キーを生成するには、 root でなければなりません。
はじめに、 /etc/httpd/conf/ ディレクトリに変更するのに cd コマンドを使います。インストール中に生成された偽の鍵と証明書を以下のコマンドで削除してください。
rm ssl.key/server.keyrm ssl.crt/server.crt
crypto-utils パッケージは、名前が示すように鍵を生成するのに使用することができる genkey ユーティリティを含みます。自分自身の秘密鍵を生成するには、 crypto-utils パッケージがインストールされていることを確認してください。ターミナルで man genkey とタイプすることにより、より多くのオプションを見ることができます。 genkey ユーティリティを使用して、仮に www.example.com のための鍵を生成するには、ターミナルで以下のコマンドを入力してください:
genkey www.example.com
make ベースのプロセスは、 RHEL 5 と一緒には出荷されないことにご注意ください。これは、 genkey グラフィカルユーザーインターフェースを開始させます。以下の図がはじめのスクリーンを示しています。ナビゲートするには、キーボードの矢印キーとタブキーを使用してください。このウィンドウは、鍵が格納される場所を示したり、操作を進めるかキャンセルするかを指示します。次のステップに進むには、 Next を選択し、 Return (Enter) キーを押してください。
次の画面は、鍵の大きさを選択することを指示します。示されているように、鍵のサイズが小さければ小さいほど、サーバーからのレスポンスが速くなり、セキュリティのレベルが低くなります。自分の好みの鍵のサイズを矢印キーを使用して選択し、次のステップに進むには、 次 を選択してください。以下の図は、鍵の大きさを選択する画面を示しています。
次のステップを選択することにより、選択した鍵の大きさによって時間がかかる可能性があるランダムビット生成プロセスを開始します。鍵のサイズが大きければ大きいほど、生成するのに時間が長くかかります。
鍵を生成すると、証明書リクエスト (CSR) を認証局 (CA) に送ることを指示されます。
はい を選択することにより、リクエストを送りたい CA を選択するように指示されます。 いいえ を選択すると、自己署名証明書を生成できます。これの次のステップは 図 10.17. 「自分のサーバーに自己署名証明書を生成する」 で示されています。
好みのオプションを選択し、次のステップに進むために 次 を選択します。次の画面では、証明書の詳細を入力できます。
もし自己署名証明書を生成したいならば、 CSR を生成しないでください。こうするには、 Generate CSR 画面で好みのオプションで いいえ を選択してください。こ証明書の詳細を入力できる以下の画面が表示されます。証明書の詳細を入力し、 Return キーを押すことにより、 図 10.19. 「秘密鍵を保護する」 を表示し、秘密鍵を暗合化するかどうかを選択できます。
証明書の詳細を入力し、 次 を選択して進んでください。以下の図は、 Equifax へ送信される証明書の詳細が完成した後に表示される次の画面の例を示しています。もし自分のサーバーのために自己署名鍵を生成している場合は、この画面は表示されないことにご注意ください。
Return キーを押すと、秘密鍵の暗合化を有効または無効にすることができる次の画面が表示されます。これを有効または無効にするには、スペースキーを使用してください。有効のときは、 [*] キャラクタが表示されます。お好みのオプションを選択して、 次 を選択し次のステップに進んでください。
次の画面では、鍵のパスフレーズを設定できます。パスフレーズがないとサーバーを起動できないので、このパスフレーズをなくさないでください。新しい秘密鍵と公開鍵のペアを再生成し、指示されているように新しい証明書を CA にリクエストすることが必要になります。セキュリティのためにパスフレーズはタイプしたように表示されません。お好みのパスフレーズをタイプしたら、ターミナルに戻るために 次 を選択してください。
もし既存の鍵のペアがあるサーバー上で genkey makeca を起動させるようとすると、以下で示されているようにエラーメッセージが表示されます。新しい鍵のペアを生成するには、既存の鍵ファイルを指示されているように削除する必要があります。
新しいキーを使うには、 Apache HTTP Server を以下のように設定します。
-
CSR を送信した後、 CA から署名付き証明書を入手してください。
-
パスに認証をコピーします。例えば
/etc/pki/tls/certs/www.example.com.crtです。 -
/etc/httpd/conf.d/ssl.confを編集してください。 SSLCertificateFile と SSLCertificateKey 行を次のように変更してください。SSLCertificateFile /etc/pki/tls/certs/www.example.com.crt SSLCertificateKeyFile /etc/pki/tls/private/www.example.com.key
"www.example.com" の部分は
genkeyコマンドで渡された引数に一致します。
Apache HTTP Server に関してさらに詳細をお知りになりたい場合は、以下のリソースを参照してください。
-
http://httpd.apache.org/ — すべてのディレクティブとデフォルトモジュールに関するドキュメントがあるApache HTTP Server の公式 Web サイト。
-
http://www.modssl.org —
mod_sslの公式 Web サイト。 -
http://www.apacheweek.com/ — Apache 全般に関する総合オンラインウィクリーニュースレター。
ファイル転送プロトコル (FTP) は、今日のインターネット上で最も古く、最も一般的に使用されるプロトコルです。その目的は、ユーザーによるリモートホストへのログインの必要性やリモートシステムを扱う知識の必要性がなく、ネットワーク上のコンピューターホスト間で信頼できるファイルの転送をすることです。これにより、ユーザーは標準の簡単なコマンドセットを使用してリモートシステム上のファイルにアクセスできます。
この章では、 FTP プロトコルの基本と、さらに Red Hat Enterprise Linux で配給されるプライマリー FTP サーバー用の設定オプション、 vsftpd を概説しています。
しかしながら、 FTP はインターネットで普及している為、しばしば公共と一緒にファイルを共有する必要が出てきます。その為、システム管理者は FTP プロトコルの独特の性質について認知しておく必要があります。
インターネットで使用されるほとんどのプロトコルと違って FTP は的確に機能する為に複数のネットワークポートを必要とします。 FTP クライアントアプリケーションが FTP サーバーへの接続を開始する時、そのアプリケーションはサーバー上のポート 21 — (コマンドポート と呼ばれます) を開きます。このポートはサーバーへの全てのコマンドを発行する為に使用されます。サーバーで要求されるデータは データポート を経由してクライアントに返還されます。データ接続用のポート番号とデータ接続が開始される方法は、クライアントがデータを アクティブ モードか パッシブ モードで要求するかにより、左右されます。
以下の説明はこれらの方法を示します:
- アクティブモード
-
アクティブモードはデータをクライアントアプリケーションに転送する為に FTP プロトコルで使用されるオリジナルの方法です。 FTP クライアントによってアクティブモードのデータ転送が開始された場合、サーバーはサーバー上のポート 20 から該当 IP アドレス及び、不定の非特権ポート (1024 以上) への接続を開きます。この設定は、クライアントマシンが 1024 以上のポートにはすべて、接続許可される必要があるという意味になります。インターネットなどの不安全なネットワークが増加するにつれて、クライアントマシンを保護するファイアウォールの使用が普及してきますが、このクライアント側のファイアウォールは多くの場合、アクティブモードの FTP サーバーからの接続を拒否する為、パッシブモードが設定されることになります。
- パッシブモード
-
パッシブモードは、アクティブモードと同じく、 FTP クライアントアプリケーションによって開始されます。サーバーからデータを要求する時、 FTP クライアントはパッシブモードでデータにアクセスしたいことを示し、サーバーはサーバー上の該当 IP アドレスと不特定の非特権ポート (1024 以上) を提供します。そうするとクライアントはサーバー上のそのポートに接続して要求された情報をダウンロードします。
パッシブモードがデータ接続でのクライアント側のファイアウォール干渉問題を解決しても、サーバー側のファイアウォールの管理を複雑にする可能性があります。 FTP サーバーの非特権ポートの幅を制限することで、サーバー上の開いたポートの数を低減することができます。これがファイアウォール規則の作成工程も簡素化します。パッシブポートの制限に関する詳細情報については 項11.5.8. 「ネットワークオプション」 を参照して下さい。
Red Hat Enterprise Linux では 2 種の異なる FTP サーバーを提供します:
-
Red Hat Content Accelerator — カーネルベースの Web サーバーとして、ハイパフォーマンスの Web サーバーと FTP サービスを提供します。速度がその第一の設計目標である為、機能的には制限があり、匿名の FTP サーバーとしてのみ動作します。設定と Red Hat Content Accelerator の管理に関する詳細情報についてはオンラインサイトの http://www.redhat.com/docs/manuals/tux/ にあるドキュメントを参照して下さい。
-
vsftpd— 迅速で安全な FTP デーモンで、 Red Hat Enterprise Linux の為に推奨の FTP サーバーです。この章の残りの部分ではvsftpdについて説明します。
高度に安全な FTP デーモンである vsftpd は、迅速で安定していて、特に安全性を求めて基礎から設計されました。大量の接続を効率的で安全に処理できる能力が、 vsftpd が Red Hat Enterprise Linux で配布される唯一の独立型 FTP となる理由です。
vsftpd で使用されるセキュリティモデルは3つの主要な側面を持ちます:
-
特権と非特権プロセスの確実な分離— 分離されたプロセスは別々のタスクを処理して、それぞれのプロセスがそのタスクに要求される最小限の特権で動作します。
-
高い権限を要するタスクは最低限必要な権限を持つプロセスによって処理されます。 —
libcapライブラリが持つ互換性を利用して、通常完全な root 権限を要求するタスクでも、権限の低いプロセスから安全に実行できます。 -
chrootjail で実行される多くのプロセス — 可能な時はいつでもプロセスは共有されるディレクトリに対しルート変更されます; このディレクトリはそこでchrootjail と見なされます。例えば、ディレクトリ/var/ftp/が主要共有ディレクトリならvsftpdは、/var/ftp/を/として知られる新しいルートディレクトリへ再割り当てします。これにより新規のルートディレクトリ以下に含まれないディレクトリへの如何なる悪質なハッカー行為を許可しません。
これらのセキュリティ活動の使用は、要求に対して vsftpd がどの様に取扱うかについて次のような影響を持ちます:
-
親プロセスは最低限の必要権限で動作します。 — 親プロセスは動的に必要な権限レベルを計算して、リスクレベルを低減します。子プロセスは直接、 FTP クライアントとの対応を処理して可能な限り、「権限なし」に近い状態で動作します。
-
高い権限を要求する全てのオペレーションは、1つの小さな親プロセスによって処理されます。 — Apache HTTP サーバーとほぼ同じく、
vsftpdは権限のない子プロセスを開始して着信の接続を処理します。これにより権限のある親プロセスは可能な限り小規模になることができ、比較的に少量のタスクを処理します。 -
権限のない子プロセスからの要求は全て親プロセスに信用されません。 — 子プロセスとの通信はソケット上で受理されて、子プロセスからの情報の正当性はいずれも処理をする前にチェックされます。
-
FTP クライアントとの対応はほとんどの場合、
chrootjail の中で、権限のない子プロセスによって処理されます。 — これらの子プロセスは、権限を持たなくて共有されているディレクトリのみにアクセスする為に、クラッシュしたプロセスは攻撃者に対して共有ファイルへのアクセスを許可するだけです。
vsftpd RPM はシステム上にデーモン ( /usr/sbin/vsftpd) 、その設定と関連ファイル、さらには FTP ディレクトリをインストールします。以下に vsftpd 設定と関連のあるファイルとディレクトリを表示します。
-
/etc/rc.d/init.d/vsftpd—vsftpdを開始、停止、及び再ロードする為に/sbin/serviceコマンドで使用される 初期化スクリプト (initscript) です。このスクリプトの使用法についての詳細情報は 項11.4. 「vsftpdの起動と停止」 を参照して下さい。 -
/etc/vsftpd/vsftpd.conf—vsftpd用の設定ファイルです。このファイルに含まれる重要なオプションリストについては 項11.5. 「vsftpdの設定オプション」 を参照して下さい。 -
/etc/vsftpd.ftpusers—vsftpdへのログを許可されていないユーザーの一覧です。デフォルトで、この一覧は、root、bin及びdaemonユーザーとその他を含んでいます。 -
/etc/vsftpd.user_list—/etc/vsftpd/ vsftpd.confの中でuserlist_denyがYES(default) か又はNOにセットされているかによってリストされたユーザーへアクセスを拒否したり、認可したりする設定にできるファイルです。もし、/etc/vsftpd.user_listがユーザーへアクセスを許可するのに使用される場合、リストしてあるユーザー名は/etc/vsftpd.ftpusersにあっては いけません。 -
/var/ftp/ディレクトリ —vsftpdでサービスされるファイルを含むディレクトリです。これはまた、匿名ユーザーの為の/var/ftp/pub/ディレクトリも含んでいます。これらの両方のディレクトリは全てに読み取り可能ですが、書き込みは root ユーザーのみ可能となります。
vsftpd RPM は /etc/rc.d/init.d/vsftpd スクリプトをインストールし、これは /sbin/service コマンドを使用してアクセスが可能になります。
サーバーを起動するには root として次を入力します:
/sbin/service vsftpd start
サーバーを停止するには root として次を入力します:
/sbin/service vsftpd stop
restart オプションは、マシンを停止してそれから起動する動作の vsftpd の短縮手法です。これは、 vsftpd 用の設定ファイルを編集した後で、その設定変更を反映させる最も効率的な方法です。
サーバーを再起動するには、 root として次を入力します:
/sbin/service vsftpd restart
condrestart (条件付き再起動) オプションはもし、現時点で動作中の場合のみ vsftpd を起動します。動作中でない場合にはデーモンを起動しないのでスクリプトにとって便利なオプションです。
サーバーを条件つきで再起動するには、 root として次を入力します:
/sbin/service vsftpd condrestart
時として1台のコンピューターが複数の FTP ドメインのサービスに使用されます。このテクニックはマルチホーミングと呼ばれます。 vsftpd を使用したマルチホームの1つの方法はデーモンの複数コピーを実行することで、その1つ1つが自身の設定ファイルを持ちます。
これを実現するには、まずすべての関連 IP アドレスをシステム上のネットワークデバイスまたはエイリアスのネットワークデバイスに割り当てます。ネットワークデバイス及びデバイスエイリアスの設定方法については 章 4. ネットワーク設定 を参照してください。ネットワーク設定スクリプトに関する詳細は 章 3. ネットワークインターフェース をご覧ください。
次に、 FTP ドメイン用の DNS サーバーが正しいマシンを参照するよう設定する必要があります。 BIND とその設定ファイルについての詳細は 章 6. Berkeley Internet Name Domain (BIND) を参照してください。
vsftpd が異なる IP アドレス上の要求に応えるには、デーモンの複数コピーが動作している必要があります。1番目のコピーは、 項11.4. 「vsftpd の起動と停止」 に説明がある通り、 vsftpd initscripts を使用して動作している必要があります。このコピーは標準の設定ファイルである /etc/vsftpd/vsftpd.conf を使用します。
それぞれの追加の FTP サイトは、 /etc/vsftpd/ ディレクトリ内に /etc/vsftpd/vsftpd-site-2.conf などの独自の名前1つの設定ファイルを持っている必要があります。各設定ファイルは root によってのみ読み込みと書き込みが可能です。 IPv4 ネットワークをリッスンしている各 FTP サーバー用のそれぞれの設定ファイルの中では、次のディレクティブが独自のものでなければなりません:
listen_address=N.N.N.N
N.N.N.N の部分は、サービスを受けている FTP サイト用の 独自 の IP アドレスで入れ換えます。もし、そのサイトが IPv6 を使用している場合、代わりに listen_address6 ディレクティブを使用します。
各追加のサーバーが設定ファイルを持つと、 vsftpd デーモンが、次のコマンドを使用して root のシェルプロンプトから起動される必要があります:
vsftpd /etc/vsftpd/<configuration-file> [amp ]
上記のコマンドでは、 <configuration-file> の部分をサーバーの設定ファイル用に /etc/vsftpd/vsftpd-site-2.conf など独特の名前で入れ換えます。
サーバー単位基準で変更を考慮すべき他のディレクティブは次の物です:
-
anon_root -
local_root -
vsftpd_log_file -
xferlog_file
vsftpd の設定ファイル内で利用できるディレクティブの詳細リストに関しては 項11.5. 「vsftpd の設定オプション」 を参照して下さい。
追加のサーバーをブート時に自動的に起動するように設定するには、次のコマンドを /etc/rc.local ファイルの末尾に追加します。
vsftpd は、 FTP サーバーが持つ幅広く利用できる他のカスタマイズレベルを提供しませんが、システム管理者のニーズのほとんどを充足するオプションを提供します。機能過剰でない現実性が設定やプログラムの不要なエラーを抑制しています。
vsftpd の全ての設定はその設定ファイルである /etc/ vsftpd/vsftpd.conf によって処理されます。各ディレクティブはファイル内に独自の行を持ち、次の形式に従います:
<directive>=<value>
各ディレクティブでは、 <directive> の部分を有効なディレクティブで入れ換え、 <value> の部分を有効な値に入れ換えます。
重要
ディレクティブ内では <directive> とイコールマークと <value> の間にスペースがあってはいけません。
コメント行はハッシュマーク (#) が先頭に付き、デーモンには無視されます。
利用できるディレクティブの総括的なリストに関しては vsftpd.conf の man ページを参照して下さい。
以下に /etc/vsftpd/vsftpd.conf 内でより重要なディレクティブのいくつかをリストで示します。 vsftpd の設定ファイル内ではっきりと見ることの出来ないディレクティブはすべて、デフォルトの値で設定してあります。
以下に vsftpd デーモンの全ての動作を制御するディレクティブをリストで示します。
-
listen— 有効になっている場合、vsftpdはスタンドアロンモードで実行します。 Red Hat Enterprise Linux は、この値をYESにセットします。このディレクティブはlisten_ipv6ディレクティブと一緒には使用できません。デフォルトの値は
NOです。 -
listen_ipv6— 有効になっている場合、vsftpdはスタンドアロンモードで実行します。しかし、 IPv6 ソケットのみしかリッスンしません。このディレクティブはlistenディレクティブと一緒に使用することは出来ません。デフォルトの値は
NOです。
以下にログインの動作とアクセス制御のメカニズムをコントロールするディレクティブをリストで示します。
-
anonymous_enable— 有効になっている場合、匿名ユーザーはログインできます。ユーザー名anonymousとftpが認可されます。デフォルトの値は
YESです。匿名ユーザーに関係するディレクティブのリストに関しては 項11.5.3. 「匿名ユーザーオプション」 を参照して下さい。
-
banned_email_file— もし、deny_email_enableディレクティブがYESに設定してある場合は、このディレクティブは、サーバーへのアクセスを許可されない匿名の電子メールパスワードのリストを含んだファイルを指定します。デフォルトの値は
/etc/vsftpd.banned_emailsです。 -
banner_file— サーバーへの接続が確立された時点で、表示されるテキストを含むファイルを指定します。このオプションはftpd_bannerディレクティブ内で指定してあるテキストを上書きします。このディレクティブ用のデフォルト値はありません。
-
cmds_allowed— サーバーに許可された FTP コマンドのコンマで区切られたリストを指定します。他のコマンドはすべて拒絶されます。このディレクティブ用のデフォルト値はありません。
-
deny_email_enable— 有効になっている場合、/etc/ vsftpd.banned_emailsに指定された電子メールパスワードを使用している全ての匿名ユーザーはサーバーへのアクセスを拒否されます。このディレクティブで参照されているファイルの名前はbanned_email_fileディレクティブを使用して指定できます。デフォルトの値は
NOです。 -
ftpd_banner— 有効になっている場合、このディレクティブで指定してあるストリングはサーバーに接続が確立した時点で表示されます。このオプションは、banner_fileディレクティブで上書き出来ます。デフォルトでは、
vsftpdは標準バナーを表示します。 -
local_enable— 有効になっている場合、ローカルユーザーはシステムにログインが許可されます。デフォルトの値は
YESです。ローカルユーザーに関連するディレクティブのリストに付いては 項11.5.4. 「ローカルユーザーオプション」 を参照して下さい。
-
pam_service_name—vsftpd用の PAM サービスネームを指定します。デフォルトの値は
ftpです。 Red Hat Enterprise Linux では、その値がvsftpdにセットしてあることに注意して下さい。 -
デフォルトの値は
NOです。 Red Hat Enterprise Linux では、その値がYESにセットしてあることに注意して下さい。 -
userlist_deny—userlist_enableのディレクティブと組合せで使用されて、NOにセットされた場合、全てのローカルユーザーは、userlist_fileディレクティブに指定されたファイルにユーザー名がリストされている場合以外は、アクセスを拒否されます。アクセスは、クライアントがパスワードを問われる前に、拒否されることから、このディレクティブをNOにセットするとローカルユーザーがネットワーク上で平文のパスワードを渡すことを防止します。デフォルトの値は
YESです。 -
userlist_enable— 有効な場合、userlist_fileディレクティブに指定されたファイルにリストしてあるユーザーはアクセスを拒否されます。クライアントがパスワードを問われる前にアクセスが拒否されますので、ユーザーがネットワーク上で平文のパスワードを渡すのが防止されます。デフォルトの値は
NOですが、 Red Hat Enterprise Linux では、その値がYESにセットしてあります。 -
userlist_file—userlist_enableのディレクティブが有効な場合、vsftpdによって参照されるファイルを指定します。デフォルトの値は、
/etc/vsftpd.user_listです。そしてインストール中に作成されます。 -
cmds_allowed— サーバーが許可する FTP コマンドのコンマで分離されたリストを指定します。このディレクティブ用のデフォルト値はありません。
以下にサーバーへの匿名ユーザーアクセスを制御するディレクティブのリストを示します。これらのオプションを使用するには、 anonymous_enable のディレクティブが YES にセットされる必要があります。
-
anon_mkdir_write_enable—write_enableディレクティブと組合せで有効になっている場合、匿名ユーザーは、書き込み権限を持つ親ディレクトリ内で新規のディレクトリを作成することが許可されます。デフォルトの値は
NOです。 -
anon_root— 匿名ユーザーがログインした後にvsftpdが移行する先のディレクトリを指定します。このディレクティブ用のデフォルト値はありません。
-
.
anon_upload_enable—write_enableのディレクティブと組合せで有効になっている場合、匿名ユーザーは書き込み権限を持つ親ディレクトリ内でファイルをアップロードすることが許可されます。デフォルトの値は
NOです。 -
anon_world_readable_only— 有効な場合、匿名ユーザーは全てが読み取り出来るファイルのダウンロードすることを許可されます。デフォルトの値は
YESです。 -
ftp_username— 匿名の FTP ユーザー用に使用されるローカルユーザーアカウント (/etc/passwd内にリスト) を指定します。そのユーザー用の/etc/passwd内に指定されたホームディレクトリは匿名 FTP ユーザーのルートディレクトリです。デフォルトの値は
ftpです。 -
no_anon_password— 有効な場合、匿名ユーザーはパスワードを要求されません。デフォルトの値は
NOです。 -
secure_email_list_enable— 有効な場合、匿名ログイン用の指定された電子メールパスワードリストのみが認可されます。これが、仮想ユーザーの必要なしに公共コンテンツへ限定的セキュリティを提供する便利な手段となります。用意されたパスワードが
/etc/vsftpd.email_passwordsにリストされていない限り、匿名ログインは防止されます。ファイル形式は空白のない１行に付き１パスワードとなります。デフォルトの値は
NOです。
以下にローカルユーザーがサーバーにアクセスする方法を特徴付けるディレクティブのリストを示します。これらのオプションを使用するには、 local_enable ディレクティブが YES にセットされている必要があります。
-
chmod_enable— 有効な場合、 FTP コマンドのSITE CHMODはローカルユーザーにより使用可能です。このコマンドはユーザーがファイルの権限を変更することを許可します。デフォルトの値は
YESです。 -
chroot_list_enable— 有効な場合、chroot_list_fileディレクティブ内に指定されたファイルにリストされたローカルユーザーはログイン時にchroot環境に配置されます。chroot_local_userディレクティブと共に有効になっている場合、chroot_list_fileディレクティブ内で指定されたファイルのリストにあるローカルユーザーは、ログイン時にchroot環境に配置 されません。デフォルトの値は
NOです。 -
chroot_list_file—chroot_list_enableディレクティブがYESにセットしてある場合、参照されるローカルユーザーのリストを含むファイルを指定します。デフォルトの値は
/etc/vsftpd.chroot_listです。 -
chroot_local_user— 有効な場合、ローカルユーザーは、ログインの後にそのホームディレクトリにルート変更されます。デフォルトの値は
NOです。警告
chroot_local_userを有効にすると多くのセキュリティ問題、特にアップロードの権限を持つユーザーにとっての問題に遭遇します。この理由で推薦 できません。 -
guest_enable— 有効な場合、全ての非匿名ユーザーはguestユーザーとしてログインされます。これはすなわちguest_usernameディレクティブに指定されたローカルユーザーです。デフォルトの値は
NOです。 -
guest_username—guestユーザーがマップされているユーザー名を指定します。デフォルトの値は
ftpです。 -
local_root— ローカルユーザーがログインした後にvsftpdが移動するディレクトリを指定します。このディレクティブ用のデフォルト値はありません。
-
local_umask— ファイル作成の umask の値を指定します。デフォルトの値は 8 進法 (8 を基準にした数値システム) 形式で、これは接頭辞「0」を持ちます。それ以外では、値は 10 ベースの整数として扱います。デフォルト値は
022です。 -
passwd_chroot_enable—chroot_local_userディレクティブと共に有効な場合、vsftpdは/etc/ passwd内のホームディレクトリフィールドの/./の発動を基にしてローカルユーザーのルート変更をします。デフォルトの値は
NOです。 -
user_config_dir— ユーザー用の特定の設定を含むローカルユーザーシステムユーザーの名前を持つ設定ファイルを含んだディレクトリへのパスを指定します。そのユーザーの設定ファイル内のディレクティブはいずれも/etc/ vsftpd/vsftpd.confの中にあるディレクティブを上書きします。このディレクティブ用のデフォルト値はありません。
以下にディレクトリに関連するディレクティブのリストを示します。
-
dirlist_enable— 有効な場合、ユーザーはディレクトリのリストを表示することが許可されます。デフォルトの値は
YESです。 -
dirmessage_enable— 有効な場合、あるユーザーがメッセージファイルを持つディレクトリの1つに入った時に、メッセージを表示します。このメッセージは入り込んだディレクトリの中に残ります。このファイルの名前はmessage_fileディレクティブ内に指定されており、デフォルトでは.messageです。デフォルトの値は
NOです。 Red Hat Enterprise Linux では、その値がYESにセットしてあることに注意して下さい。 -
force_dot_files— 有効な場合、ドット (.) で始まるファイルはディレクトリ一覧に示してありますが、.と..ファイルは例外です。デフォルトの値は
NOです。 -
hide_ids— 有効な場合、全てのディレクトリ一覧は各ファイルのユーザーとグループとしてftpを示します。デフォルトの値は
NOです。 -
message_file—dirmessage_enableのディレクティブを使用している場合、メッセージファイルの名前を指定します。デフォルトの値は
.messageです。 -
text_userdb_names— 有効な場合、ユーザー名とグループ名のテストは UID と GID のエントリーの代用として使用されます。このオプションを有効にすると、サーバーのパフォーマンスを低下させる可能性があります。デフォルトの値は
NOです。 -
use_localtime— 有効な場合、ディレクトリ一覧は GMT の代わりにコンピュータのローカル時間を表示します。デフォルトの値は
NOです。
以下にディレクトリに関連するディレクティブのリストを示します。
-
download_enable— 有効な場合、ファイルのダウンロードが許可されます。デフォルトの値は
YESです。 -
chown_uploads— 有効な場合、匿名ユーザーによってアップロードされたファイルの全てはchown_usernameディレクティブに指定されたユーザーの所有となります。デフォルトの値は
NOです。 -
chown_username—chown_uploadsのディレクティブが有効な場合、匿名でアップロードされたファイルの所有権を指定します。デフォルトの値は
rootです。 -
write_enable— 有効な場合、DELE、RNFR及びSTORなどのファイルシステムを変更できる FTP コマンドが許可されます。デフォルトの値は
YESです。
以下に vsftpd ロギングの動作に影響するディレクティブのリストを示します。
-
dual_log_enable—xferlog_enableと一緒に有効になっている場合、vsftpdは、xferlog_fileディレクティブ内に指定されたファイルへwu-ftpd互換のログ (デフォルトで/var/log/xferlog) ログ、及びvsftpd_ log_fileディレクティブ内に指定されたログファイル (デフォルトで/ var/log/vsftpd.log) の2つのファイルを同時に書き込みます。デフォルトの値は
NOです。 -
log_ftp_protocol—xferlog_enableとxferlog_std_formatと一緒に有効になっている状態で、さらにNOにセットしてある場合、 FTP コマンドと反応はすべてログされます。このディレクティブはデバッグに役に立ちます。デフォルトの値は
NOです。 -
syslog_enable—xferlog_enableと一緒に有効になっている場合、vsftpd_log_fileディレクティブ内に指定されたログファイル (デフォルトで/var/log/vsftpd.log) へ通常に書き込まれた全てのロギングは、 FTPD の環境にではなく、システムロガーに転送されます。デフォルトの値は
NOです。 -
vsftpd_log_file—vsftpdログファイルを指定します。このファイルを使用するには、xferlog_enableが有効になっている必要があり、xferlog_std_formatがNOにセットされている必要があります。あるいはxferlog_std_formatがYESにセットされている場合、dual_log_enableが有効になっている必要があります。syslog_enableがYESにセットされていない場合、このディレクティブ内に指定されたファイルの代わりに、システムログが使用されることに留意して下さい。デフォルトの値は
/var/log/vsftpd.logです。 -
xferlog_enable— 有効な場合、vsftpdは、接続 (vsftpd形式のみ) とvsftpd_log_fileのディレクティブ内に指定されたログファイルへのファイル転送情報 (デフォルトでは/var/log/vsftpd.log) のログを取ります。xferlog_std_ formatがYESへセットされている場合、ファイル転送情報はログされますが、接続はログされません。そしてxferlog_file内に指定されたログファイル (デフォルトで/var/log/xferlog) が代わりに使用されます。dual_log_enableがYESにセットされている場合、両方のログファイルとログ形式が使用されることに留意して下さい。デフォルトの値は
NOです。 Red Hat Enterprise Linux では、その値がYESにセットしてあることに注意して下さい。 -
xferlog_file—wu-ftpd互換のログファイルを指定します。このファイルを使用するには、xferlog_enableが有効でなければならず、xferlog_std_formatがYESにセットされている必要があります。dual_log_enableがYESにセットされている場合も、これが使用されます。デフォルトの値は
/var/log/xferlogです。 -
xferlog_std_format—xferlog_enableと一緒に有効になっている場合、wu-ftpd互換のファイル転送ログのみがxferlog_fileディレクティブ内に指定されたファイルへ書き込まれます。 (デフォルトで/var/log/xferlog)。このファイルはファイル転送のみをログして、サーバーへの接続はログしないことに留意して下さい。デフォルトの値は
NOです。 Red Hat Enterprise Linux では、その値がYESにセットしてあることに注意して下さい。
重要
古い wu-ftpd FTP サーバーで書かれたログファイルとの互換性を維持するには、 xferlog_std_format ディレクティブは、 Red Hat Enterprise Linux の中では YES にセットされている必要があります。しかし、この設定では、サーバーへの接続がログされないという意味になります。
vsftpd 形式で接続をログして、さらに wu-ftpd 互換のファイル転送ログを維持するには、 dual_log_enable を YES にセットします。
wu-ftpd 互換のファイル転送ログの維持が重要でない場合は、 xferlog_std_format を NO にセットするか又はその行をハッシュマーク (#) でコメント化するか、あるいはその行を全て削除します。
以下に vsftpd が、ネットワークに対応する仕方に影響するディレクティブのリストを示します。
-
accept_timeout— 接続を確立する為にパッシブモードを使用しているクライアント用の時間を指定します。デフォルト値は
60です。 -
anon_max_rate— 匿名ユーザー用に最大データ転送レートを秒単位のバイト数で指定します。デフォルトの値は
0で、これは転送レートを制限しません。 -
connect_from_port_20が有効な場合、vsftpdはアクティブモードのデータ転送中にサーバー上のポート20を開く為に十分な権限で実行 されます。このオプションを無効にすると、vsftpdをより少ない権限で実行させることになりますが、幾つかの FTP クライアントとの互換がなくなる可能性があります。デフォルトの値は
NOです。 Red Hat Enterprise Linux では、その値がYESにセットしてあることに注意して下さい。 -
connect_timeout— アクティブモードを使用しているクライアントがデータ接続に反応する必要のある最大限時間を秒数で指定します。デフォルト値は
60です。 -
data_connection_timeout— データ転送が停止を許される最大限の時間を秒数で指定します。これが開始されるとリモートクライアントへの接続は閉じられます。デフォルト値は
300です。 -
ftp_data_port—connect_from_port_20がYESにセットされている時に、アクティブデータ接続用に使用されるポートを指定します。デフォルト値は
20です。 -
idle_session_timeout— 1つのクライアントからのコマンドとコマンドの間の最大許容時間を指定します。これが開始されるとリモートクライアントへの接続は閉じられます。デフォルト値は
300です。 -
listen_address—vsftpdがネットワーク接続用にリッスンする IP アドレスを指定します。このディレクティブ用のデフォルト値はありません。
ヒント
別々の IP アドレスにサービスしている
vsftpdの複数コピーを実行している場合、vsftpdデーモンの各コピーはこのディレクティブ用に別の値を持つことが必要です。マルチホームの FTP サーバーに関する詳細情報は 項11.4.1. 「vsftpdの複数コピーを起動」 を参照して下さい。 -
listen_address6—listen_ipv6がYESにセットされている場合、ネットワーク接続用にvsftpdがリッスンする為の IPv6 アドレスを指定します。このディレクティブ用のデフォルト値はありません。
ヒント
別々の IP アドレスにサービスしている
vsftpdの複数コピーを実行している場合、vsftpdデーモンの各コピーはこのディレクティブ用に別の値を持つことが必要です。マルチホームの FTP サーバーに関する詳細情報は 項11.4.1. 「vsftpdの複数コピーを起動」 を参照して下さい。 -
listen_port— ネットワーク接続用にvsftpdがリッスンする為のポートを指定します。デフォルト値は
21です。 -
local_max_rate— サーバーにログされたローカルユーザー用に転送されるデータの最大許容レートを秒単位のバイト数で指定します。デフォルトの値は
0で、これは転送レートを制限しません。 -
max_clients— スタンドアロンモードで実行中の時のサーバーへ同時接続を許可されたクライアントの最大許容数を指定します。余分のクライアント接続は、エラーメッセージとなります。デフォルト値は
0で、これは接続を制限しません。 -
max_per_ip— 同じソースの IP アドレスから接続を許可されるクライアントの最大許容数を指定します。デフォルト値は
0で、これは接続を制限しません。 -
pasv_address— Network Address Translation (NAT)の ファイヤウォールの背後にあるサーバー用のサーバーの公共向けの IP アドレスの為の IP アドレスを指定します。このディレクティブ用のデフォルト値はありません。
-
pasv_enable— 有効な場合、パッシブモードの接続を許可します。デフォルトの値は
YESです。 -
pasv_max_port— パッシブモード接続用の FTP クライアントに送られる最高限度のポートを指定します。この設定は、ファイアウォール規則がより簡単に作成できるようにポートの範囲を制限するのに使用されます。デフォルト値は
0で、これはパッシブポート範囲の最高限度を制限しません。この値は、65535を越えてはいけません。 -
pasv_min_port— パッシブモートの接続用の FTP クライアントへ送られる最低限度のポートを指定します。この設定はファイアウォール規則をより簡単に作成できるようにポートの範囲を制限するのに使用されます。デフォルト値は
0で、これはパッシブポート範囲の最低限度を制限しません。この値は1024より低くてはいけません。 -
pasv_promiscuous— 有効な場合、データ接続は同じ IP アドレスから出てきているかの確認をしません。この設定は単にトンネリングの一部のタイプに役に立つだけです。注意
このオプションは絶対に必要な時以外は、有効にしないで下さい。有効にすると、データ転送を開始する制御接続と同一の IP アドレスからでてくるパッシブモード接続を確証する重要なセキュリティ機能を解除してしまいます。
デフォルトの値は
NOです。 -
port_enable— 有効な場合、アクティブモードの接続が許可されます。デフォルトの値は
YESです。
vsftpd に関する詳細情報は、以下の資料を参照して下さい。
-
/usr/share/doc/vsftpd-ディレクトリ —<version-number>/<version-number>の部分はインストールされているvsftpdパッケージ名に入れ換えます。このディレクトリには、ソフトウェアに関する基本的な情報があるREADMEが含まれています。TUNINGファイルには、基本的なパフォーマンスチューンのヒントが含まれており、SECURITY/ディレクトリにはvsftpdで使用されているセキュリティモデルに関する情報が含まれています。 -
vsftpd関連の man ページ — デーモンや設定ファイルに関する多くの man ページがあります。以下により重要な man ページの一覧を示します。- サーバーアプリケーション
-
-
man vsftpd—vsftpd用に利用できるコマンドラインのオプションを説明します。
-
- 設定ファイル
-
-
man vsftpd.conf—vsftpd用の設定ファイルの中で利用できるオプションの詳細一覧を含んでいます。 -
man 5 hosts_access— TCP ラッパーの設定ファイルでる次ぎの２つ：hosts.allowとhosts.denyの中で利用できる形式とオプションを説明します。
-
-
http://vsftpd.beasts.org/ —
vsftpdプロジェクトページは最新のドキュメントを見ることと、ソフトウェアの作者に連絡を取るのに役に立つ場所です。 -
http://slacksite.com/other/ftp.html — この web サイトは、アクティブモードとパッシブモードの FTP 間での差異について簡単な説明を提供します。
-
http://www.ietf.org/rfc/rfc0959.txt — IETF からの FTP プロトコールに関連したオリジナルの RFC (Request for Comments) です。
電子メール (email) の誕生は1960年代の初期でした。メールボックスはユーザーにのみ読み込み可能なユーザーのホームディレクトリにあるファイルでした。原始的なメールアプリケーションでは、そのファイルの下にテキストメッセージを付けるため、ユーザーは常時増加するファイルを押し退けて目的のメッセージを探す必要がありました。このようなシステムでは、同じシステム上のユーザーにだけメッセージを送信できる状態でした。
電子メールメッセージファイルの最初のネットワーク送信は、コンピュータエンジニアである Ray Tomlinson がテストメッセージを ARPANET を経由した2つのマシン間で送信した 1971 年に始まりました。 (インターネットの前身です)。電子メールでの通信はすぐに有名になり、2年以内に ARPANET のトラフィックの 75 %を占めていました。
今日、標準化したネットワークプロトコル上の電子メールシステムは、インターネット上で最も使用されるサービスになるまで発展しています。 Red Hat Enterprise Linux では、電子メールのサービスとアクセスの為の高度なアプリケーションを多く提供しています。
この章では、今日使用されている最近の電子メールプロトコルと電子メールで送受信ができるように設計されているプログラムを説明します。
現在の電子メールはクライアント/サーバーアーキテクチャーを使用して配送されます。電子メールのメッセージはメールクライアントプログラムを使用して作成します。このプログラムがメッセージをサーバーに送り、そのサーバーは受信者側の電子メールサーバーにメッセージを転送します。そこからメッセージが受信者の電子メールクライアントに供給されます。
このプロセスを有効にするために、多種多様の標準ネットワークプロトコルが異なるマシンを、殆どの場合、異なるオペレーティングシステムと異なる電子メールプログラムで電子メールの送受信を可能にします。
以下で説明してあるプロトコルは、電子メール転送で最も一般に使用されているプロトコルです。
クライアントアプリケーションからサーバーまで、及び送信側のサーバーから受信側のサーバーまでのメールの配送は SMTP (Simple Mail Transfer Protocol) により処理されます。
SMTP の主要目的は、メールサーバー間でメールを転送することです。しかし、それが電子メールクライアントにとっても重要になります。メールを送るためには、クライアントはメッセージを配送元のサーバーに送り、そのサーバーが配送先のメールサーバーに配達の連絡をします。この理由で、電子メールクライアントを設定する時に、 SMTP サーバーを指定する必要がある訳です。
Red Hat Enterprise Linux では、ユーザーは SMTP サーバーをローカルマシン上で設定してメール配送を処理できます。そして、さらに発信メール用のリモート SMTP サーバーの設定もすることができます。
SMTP プロトコルで重要なポイントの1つは、これが認証を必要としないことです。このため、インターネット上の誰でも他の誰かに、あるいは大規模な団体にさえも電子メールを送信することができます。実はこれがジャンクメール、すなわち spam を可能にする SMTP の性格なのです。リレー制限を課すことで、インターネットでの無作為のユーザーが、あなたの SMTP サーバーからインターネット上の他のサーバーへメールを送信するのを制限します。そのような制限を課してないサーバーは、 open relay サーバーと呼ばれます。
Red Hat Enterprise Linux では、デフォルトで Sendmail (/usr/sbin/sendmail) をそのデフォルトの SMTP プログラムとして使用します。しかし、より簡単なメールサーバーアプリケーション、 Postfix (/usr/sbin/postfix) も利用できます。
電子メールをメールサーバーから取り出すために、電子メールアプリケーションで使用される2つの主要プロトコルがあります。 POP (Post Office Protocol) と IMAP (Internet Message Access Protocol) です。
Red Hat Enterprise Linux のデフォルト用の POP サーバーは /usr/lib/cyrus-imapd/pop3d であり、 cyrus-imapd パッケージによって用意されています。 POP サーバーを使用する時、電子メールメッセージはメールクライアントアプリケーションによりダウンロードされます。デフォルトで、メールサーバーからメッセージが正常に転送された後には、殆どの電子メールクライアントは自動的にメッセージを削除するように設定されています。しかし、通常この設定は変更できます。
POP は、 MIME (Multipurpose Internet Mail Extensions) などの重要なインターネットメッセージング標準にも互換性があり、これでメールの添付が可能になります。
POP は、電子メールの読み取りに使用するシステムが1台しかないユーザーに最適です。また、インターネットへの固定接続がない場合やメールサーバーを含むネットワークがない場合にも機能します。 POP は認証した時点でクライアントプログラムに各メッセージの内容すべてをダウンロードするように要求しますので、遅いネットワークに接続しているユーザーにとっては大変です。これは、特にメッセージが大きいサイズの添付ファイルを持っている時には長い時間がかかります。
最新の標準バージョンの POP プロトコルは POP3 です。
但し、使用頻度の低い他の POP プロトコルの変種は多種存在します：
-
APOP — MDS 認証付きの POP3 です。暗号化なしでパスワードを送るのではなくユーザーパスワードの暗号化されたハッシュ (語群) が電子メールクライアントからサーバーに送ります。
-
RPOP — RPOP 認証付きの POP3 です。これは、パスワードに似た、ユーザー毎の ID を使用して POP 要求を認証します。しかし、 ID は暗号化されていないので、 RPOP が通常の POP より安全であることはありません。
追加のセキュリティとして、クライアント認証とデータ転送のセッション用に Secure Socket Layer (SSL) 暗号化を使用することも出来ます。これは、 ipop3s サービス、又は、 /usr/sbin/stunnel プログラムを使用して有効にすることができます。その詳細は 項12.6.1. 「通信のセキュリティ」 で御覧下さい。
Red Hat Enterprise Linux のデフォルト IMAP サーバーは、 /usr/lib/cyrus-imapd/imapd であり、これは imap パッケージで用意されています。 IMAP メールパッケージを使用すると電子メールのメッセージはサーバーに残りますので、ユーザーはそこから読み取ったり、削除したりすることが出来ます。 IMAP により、クライアントアプリケーションはサーバー上のメールディレクトリを作成、名前変更、あるいは削除して電子メールの編成や保存ができます。
IMAP は、複数のマシンを使用して電子メールにアクセスするユーザーに特に便利です。このプロトコルは、また遅い回線経由でメールサーバーに接続しているユーザーにも便利です。それは電子メールのヘッダ (頭書き) だけがメッセージの代理でダウンロードされますので、それを開くまでは回線も節約できるからです。ユーザーはさらにメッセージを表示あるいはダウンロードせずに削除することも出来ます。
また、便利なように IMAP アプリケーションは、メッセージのコピーをローカルにキャッシュすることが可能で、これにより IMAP サーバーに直接接続されていない時も保存しているメッセージを閲覧することができます。
IMAP は、 POP と同様に MIME などの重要なインターネットメッセージング基準に互換性をもつため、電子メールの添付も可能です。
セキュリティの補強の為に、クライアント認証とデータ転送セッションの為の SSL 暗号法を使用することができます。これは imaps サービス、又は /usr/sbin/stunnel プログラムの使用をすることで有効にすることが出来ます。詳細については 項12.6.1. 「通信のセキュリティ」 を参照して下さい。
他にもフリータイプと商用タイプの IMAP クライアントとサーバーが利用できます。その殆どは IMAPプロトコルを拡張して、追加の機能を提供しています。総合的な一覧はオンラインで、以下のサイトで確認できます。 http://www.imap.org/products/longlist.htm.
IMAP と POP3 プロトコルを実装する imap-login と pop3-login デーモンは、 dovecot パッケージに含まれています。 IMAP と POP の使用は、 dovecot を通じて設定されます。デフォルトでは、 dovecot は IMAP だけを起動します。 POP を使用するために dovecot を設定するためです。
-
/etc/dovecot.confを編集して以下の行を加えます:protocols = imap imaps pop3 pop3s
-
コマンドを起動させることによって、現在のセッションのための変更を操作可能にします。
/sbin/service dovecot restart
-
コマンドを起動させることによって、次回のリブート後に変更を操作可能にします。
chkconfig dovecot on
dovecotは、それが IMAP サーバーを起動させたことだけを報告しますが、 POP3 サーバーも起動させることに注意してください。
SMTP とは異なり、これらのプロトコルは両方とも、ユーザー名とそのパスワードを使用して認証する接続を要求します。デフォルトでは、この両方のプロトコルはネットワーク上で暗号化なしで渡されます。
dovecot に SSL を設定する:
-
dovecotの設定ファイル/etc/pki/dovecot/dovecot-openssl.confを自分の好みで編集してください。しかし、一般的なインストールでは、このファイルには変更は必要ありません。 -
ファイル
/etc/pki/dovecot/certs/dovecot.pemと/etc/pki/dovecot/private/dovecot.pemをリネームか、移動、もしくは、削除します。 -
dovecot の自己署名証明書を作成するスクリプト
/usr/share/doc/dovecot-1.0/examples/mkcert.shを実行します。証明書は、/etc/pki/dovecot/certsと/etc/pki/dovecot/privateディレクトリにコピーされます。変更を実装するには、dovecot(/sbin/service dovecot restart) で再起動してください。
dovecot についての詳細は、 http://www.dovecot.org を参照してください。
一般的に、全ての電子メールプログラムには3つの分類のうちのひとつに分けられます。それらはすべて電子メールメッセージの移動と管理のプロセスで特定の役割を果たします。大半のユーザーは、メッセージを送受信するための特定の電子メールプログラムしか意識しません。これらのタイプはそれぞれ、電子メールが正しい宛先に着信するかどうかを確認するために重要です。
Mail Transport Agent (MTA) は SMTP を使用してホスト間で電子メールを転送します。1つのメッセージが目的地まで移動する間に幾つかの MTA が関与することもあります。
マシン間のメッセージの配信はかなり単純なものに見えますが、特定の MTA がリモートホストに配信するためのメッセージを受け入れることができるか、あるいは受け入れなければならないかを決定するプロセスは非常に複雑です。更には、スパムかによる問題のため、特定の MTA を使用することは通常、 MTA 自体の設定、あるいは MTA が存在するネットワークアドレスへのアクセス設定のいずれかで制限されます。
最新の電子メールクライアントプログラムの多くは、メールを送信する時に、 MTA として動作します。しかし、この動作を実際の MTA の役目と混同しないで下さい。電子メールクライアントプログラムが電子メールを (MTA のように) 発信できる唯一の理由はアプリケーションを実行しているホストが自分自身の MTA を所有していないからです。これは、特に非 Unix ベースのオペレーティングシステム上の電子メールクライアントプログラムで明確です。しかし、これらのクライアントプログラムは、使用許可のある MTA に対し発信メッセージを送信するだけで、受信者の電子メールサーバーにメッセージを直接配達することはありません。
Red Hat Enterprise Linux が2つの MTA (Sendmail と Postfix) をインストールするため、電子メールクライアントプログラムは多くの場合、 MTA として動作する必要はありません。 Red Hat Enterprise Linux には Fetchmail と言う特殊目的用の MTA も含まれています。
Sendmail と Postfix と Fetchmail の詳細については、 項12.3. 「Mail Transport Agent」 を参照して下さい。
MDA (Mail Delivery Agent) は、 MTA によって喚起され着信メールを正式なユーザーのメールボックスにファイルします。多くの場合、 MDA が実際に mail 又は Procmail のように LDA (Local Delivery Agent) (ローカル配送エージェント) となります。
電子メールクライアントによって読まれる場所まで配達するメッセージを扱うプログラムはどれも MDA と考えられます。この理由で、幾つかの MTA (Sendmail や Postfix) は、それらが新規メールのメッセージをローカルユーザーのメールスプールファイルの追加する時、 MDA の役目を果たすと言えます。一般的に MDA はシステム間でメッセージを配送しませんし、ユーザーインターフェイスも提供することはありません。 MDA は電子メールクライアントアプリケーションがアクセスできるようにローカルマシン上のメッセージを分配したり分類したりします。
Red Hat Enterprise Linux には2つの主要な MTA 、 Sendmail と Postfix が含まれています。 Sendmail はデフォルトの MTA として設定されていますが、デフォルト MTA を Postfix に切り替えるのは簡単です。
Sendmail の基本目的は、他の MTA のようにホスト間の電子メールを、通常は SMTP プロトコルを使用して転送することです。しかし、 Sendmail は高度な設定柔軟度を持つことから、使用されるプロトコルを含めてどのように電子メールを取り扱うかの側面ほとんどすべてを制御できます。この MTA が持つパワーと拡張性のため、多くのシステム管理者によって Sendmail の使用が選択されています。
重要なことは、 Sendmail が出来ないことを考えるのでなく、 Sendmail が何であるか、及び何ができるかを知ることです。複数の役割を果たすモノリシックアプリケーションの時代では、 Sendmail が組織内で電子メールサーバーを実行するために必要な唯一のアプリケーションであると思うことがあり得ます。技術的には事実で、 Sendmail がメールをユーザーのディレクトリにスプールし、送信子メールをユーザーの為に配送することができます。しかしほとんどのユーザーは実際に簡単なメールの配達だけを求めているのではありません。通常、ユーザーは POP か IMAP を利用する MUA を使ってローカルマシンにメッセージをダウンロードして電子メールによる交流を望んでいます。または、メールボックスにアクセスする為に Web インターフェイスを好む場合もあるでしょう。これらの他のアプリケーションは Sendmail との併用で動作することができますが実際には別の理由で存在し、当然独立して稼働することが出来ます。
Sendmail がすべき、又は出来る設定の全てを言及することはこのセクションの担当範囲を越えてしまいます。文字通りに数百の異なるオプションと規則のセットがある中で、このマニュアル全項目では実行できるすべてと、物事がうまく行かない時の修正法を説明することに従事しています。 Sendmail のリソースに関する情報は 項12.7. 「その他のリソース」 でお読み下さい。
このセクションでは、デフォルトで Sendmail と共にインストールされているファイルの説明をして、さらに迷惑メール (spam) 停止の仕方及び Lightweight Directory Access Protocol (LDAP) を使った Sendmail の拡張法などの基本的設定変更を説明していきます。
Sendmail の実行ファイルは /usr/sbin/sendmail です。
Sendmail の長くて詳細に渡る設定ファイルは /etc/mail/sendmail.cf です。直接 sendmail.cf を編集することは避けて下さい。 Sendmail に対し設定の変更をするには、 /etc/mail/sendmail.mc ファイルを代わりに編集します。オリジナルの /etc/mail/sendmail.cf をバックアップして、以下の代わりのものを使用して、新しい設定ファイルを生成してください:
-
/etc/mail(make all -C /etc/mail) に含まれている makefile を使用して、新しい/etc/mail/sendmail.cf設定ファイルを作成します。/etc/mail(db ファイル) に生成される他の全てのファイルは、必要であれば再生成されます。古い makemap コマンドはまだ使用可能です。 make コマンドは、もしmakeパッケージがインストールされていたらservice sendmail start | restart | reloadにより自動的に使用されます。 -
代わりに、新しい
/etc/mail/sendmail.cfを作成するのにm4マクロプロセッサを使用できます。
Sendmail の設定についての詳細は、 項12.3.1.3. 「一般的な Sendmail 設定変更」 を参照してください。
さまざまな Sendmail 設定ファイルは、次のような /etc/mail/ ディレクトリにインストールされます。
-
access— 発信電子メール用の Sendmail を使用するシステムを指定します。 -
domaintable— ドメイン名マッピングを指定します。 -
local-host-names— ホストのエイリアスを指定します。 -
mailertable— 特定ドメインのルーティングを無効にする命令を指定します。 -
virtusertable— エイリアスのドメイン特有の形式を指定します。これにより、複数の仮想ドメインが1つのマシン上でホストされます。
Several of the configuration files in /etc/mail/, such as access, domaintable, mailertable and virtusertable, must actually store their information in database files before Sendmail can use any configuration changes. To include any changes made to these configurations in their database files, run the following command:
makemap hash /etc/mail/
<name> < /etc/mail/<name>
ここで、 <name> は、変換する設定ファイルの名前で入れ換えます。
例えば、 example.com ドメインに宛てられた全てのメールを <bob@other-example.com>
に転送してもらう場合、次の行を virtusertable ファイルに追加します：
@example.com bob@other-example.com
この変更を完結するには、次のコマンドを root として使用して virtusertable.db ファイルを更新する必要があります：
makemap hash /etc/mail/virtusertable < /etc/mail/virtusertable
これにより、新しい設定を持つ新規の virtusertable.db ファイルが作成できます。
Sendmail の設定ファイルを変更する時は、既存のファイルを編集するのではなく、 全く新しい /etc/mail/sendmail.cf ファイルを生成することが推奨されます。
重要
sendmail.cf ファイルを変更する前に、そのファイルのバックアップを作成するのが良いでしょう。
Sendmail に必要な機能を追加するには、 root として /etc/mail/sendmail.mc ファイルを編集します。編集が終ったら、 m4 マクロプロセッサを使って新しい sendmail.cf を生成します。それには以下のコマンドを実行します:
m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
デフォルトで、 Sendmail に m4 マクロプロセッサーがインストールされています。 m4 パッケージの一部となっています。
新規に /etc/mail/sendmail.cf ファイルを作成した後に、 Sendmail を再起動してその変更を反映させます。その為の最も簡単な方法として以下のコマンドをタイプします:
/sbin/service sendmail restart
重要
デフォルトの sendmail.cf ファイルは、ローカルコンピュータ以外のいかなるホストからも、ネットワーク接続の受け入れを Sendmail に許可しません。 Sendmail を他のクライアントのサーバーとして設定したい場合は、 /etc/mail/sendmail.mc ファイルを編集し、 DAEMON_OPTIONS ディレクティブの Addr= オプションに指定されたアドレスを 127.0.0.1 からアクティブネットワークデバイスの IP アドレスに変更するか、又は DAEMON_OPTIONS ディレクティブの行の先頭に dnl を置いてその行の全てをコメントアウトします。これが終了すると、以下のコマンドを実行して /etc/mail/sendmail.cf を再生成します:
m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
配送される Red Hat Enterprise Linux のデフォルト設定は、ほとんどの SMTP のみのサイトで動作します。しかし、 UUCP (UNIX から UNIX へのコピー) サイトでは動作しません。 UUCP メール転送を使用している場合は、 /etc/mail/sendmail.mc ファイルを再構成して新規の /etc/mail/sendmail.cf を生成する必要があります。
/usr/share/sendmail-cf ディレクトリの下のディレクトリ内にあるファイルを編集する前に /usr/share/sendmail-cf/README ファイルを参照してください。ディレクトリ内のファイルが将来の /etc/mail/sendmail.cf ファイルの設定に影響を与える可能性があります。
一般的な Sendmail の設定では、ネットワーク上にあるすべてのマシンのためのメールゲートウェイとしての役割を1つのマシンに果たさせます。たとえば、ある会社はすべての電子メールを処理し、発信メールに返信用アドレスを添付する mail.example.com と呼ぶマシンを持ちたいと想定しましょう。
この様な状況では、 Sendmail サーバーは会社のネットワーク上のマシンをマスカレードしてその返信用アドレスが user@host.example.com ではなく、 user@example.com となるようにする必要があります。
そうするには、以下の行を /etc/mail/sendmail.mc に追加します：
FEATURE(always_add_domain)dnl FEATURE(`masquerade_entire_domain')dnl FEATURE(`masquerade_envelope')dnl FEATURE(`allmasquerade')dnl MASQUERADE_AS(`bigcorp.com.')dnl MASQUERADE_DOMAIN(`bigcorp.com.')dnl MASQUERADE_AS(bigcorp.com)dnl
m4 を使用して新しい sendmail.cf を生成した後はこの設定では、このネットワーク内部からのメールがすべて bigcorp.com から送信されたように見えます。
電子メールスパムとは、通信を要求していないユーザーが受け取る、不要で欲しくもない電子メールと定義出来ます。それは、非常に破壊的でコストのかかる広範囲なインターネット通信標準の乱用です。
Sendmail は、ジャンクメールを送信するための新しいスパミング手法が採用されないように阻止することを比較的容易にしました。デフォルトでさらに一般的なスパミング手法の多くを阻止します。 Sendmail の主なアンチスパム機能は、 ヘッダーチェック、リレー妨害 (バージョン 8.9 以上はデフォルト) 、データベースへのアクセス及び送信者情報チェック です。
たとえば、中継とも呼ばれている SMTP メッセージの転送は、 Sendmail バージョン 8.9 以降、デフォルトで無効になっています。この変更が行われる前であれば、 Sendmail はある部署 (y.com) からメッセージを受け入れて別の部署 (z.net) に送るようにメールホスト (x.edu) に指示できました。しかし、現在では、こちらのサーバーを通じてメールを中継することをドメインに許可するように Sendmail を設定する必要があります。ドメインへの中継を設定するには、 /etc/mail/relay-domains ファイルを編集し、 Sendmail を再起動します。
しかし、多くの場合、ユーザーはインターネットを通じて制御できないような他のサーバーからのスパムの砲撃を受けるおそれがあります。そのような場合、 /etc/mail/access ファイルから提供されている Sendmail のアクセス制御機能を使用して、歓迎できないホストからの接続を防止出来ます。次の例では、ファイルが阻止、及び Sendmail サーバーへのアクセスの許可との両方に使用されています：
badspammer.com ERROR:550 "Go away and do not spam us anymore" tux.badspammer.com OK 10.0 RELAY
この例は、 badspammer.com から送られたすべての電子メールが、スパマーに戻されるメッセージ付きで 550 RFC-821 対応エラーコードによりブロックされることを示しています。ただし、 tux.badspammer.com サブドメインから送られた電子メールは受理されます。最後の行は、 10.0.*.* ネットワークから送られたすべての電子メールがメールサーバーを通じて中継されることを示します。
/etc/mail/access.db はデータベースであるため、変更をするには makemap を起動します。これには、 root で次のコマンドを使用します：
makemap hash /etc/mail/access < /etc/mail/access
メッセージヘッダーアナリシスは、ヘッダーコンテンツに基づきメールを拒否することを可能にします。 SMTP サーバーは、メッセージヘッダーの中に電子メールの行路についての情報を格納します。メッセージが、ひとつの MTA から他の MTA に行くと、それぞれが他の全ての Received ヘッダーの上に、 "Received" ヘッダーを加えます。しかし、この情報はスパマーにより変更される可能性があることに注意してください。
この例はアクセスの許可とその阻止に関して、 Sendmail が出来ることのほんの一部しか示していません。詳細と他の例については /usr/share/sendmail-cf/README を御覧下さい。
Sendmail は、メールを配送する時に、 Procmail MDA をコールしますので SpamAssassin などのスパムフィルタを使用してユーザーはスパムを識別し、ファイルすることも出来ます。 SpamAssassin の使用の詳細については 項12.5.2.6. 「スパムフィルタ」 を参照して下さい。
LDAP (Lightweight Directory Access Protocol) を使用すると非常に大きいグループから特定のユーザーに関する特定情報を非常に高速かつ強力に検索できます。たとえば、 LDAP サーバーを使用して、ユーザーのラストネームで一般的な法人ディレクトリから特定の電子メールアドレスを調べることができます。このような実践形態では、 LDAP は Sendmail と大きく異なり、 LDAP は階層的なユーザー情報を保存し、 Sendmail にはすでにアドレス指定された電子メールメッセージ内の LDAP クエリの結果が与えられるだけです。
しかし、 Sendmail は LDAP との非常に大きな統合化をサポートします。この場合、 Sendmail は LDAP を使用して、中型から企業レベルの組織をサポートするために協調動作する各種メールサーバー上で aliases や virtusertables などの個別に保守されるファイルを置き換えます。簡単に言えば、 Sendmail とその個別の設定ファイルから、多数の異なるアプリケーションでサポートされている強力な LDAP クラスタへ、メールルーティングレベルを抽出することができます。
Sendmail の現在のバージョンには、 LDAP に対するサポートが含まれています。 LDAP を使用して Sendmail サーバーを拡張するには、まず、 OpenLDAP などの LDAP サーバーを動作させ正しく設定します。その後、次をインクルードできるように、 /etc/mail/sendmail.mc を編集します：
LDAPROUTE_DOMAIN('yourdomain.com')dnl
FEATURE('ldap_routing')dnl
注意
これは、 LDAP による Sendmail の非常に基本的な設定のためだけのものです。特に共通の LDAP サーバーを使用した数台の Sendmail マシンを設定する場合、 LDAP の実装の仕方によってはユーザーの設定はこの基本的な設定とは非常に異なる可能性があります。
詳細な LDAP ルーティング設定の手順と例については、 /usr/share/ sendmail-cf/README を参照してください。
次に、 m4 を実行して Sendmail を再起動することによって、 /etc/mail/sendmail.cf ファイルを作成しなおします。これを行う手順については、 項12.3.1.3. 「一般的な Sendmail 設定変更」 を参照して下さい。
LDAP の詳細については、 章 13. LDAP（Lightweight Directory Access Protocol） を参照してください。
元来、 IBM のセキュリティ専門家でありプログラマーの Wietse Venema によって開発された Postfix は、安全で迅速で設定が容易であるようにデザインされた Sendmail 対応の MTA です。
セキュリティを改善する為に、 Postfix はモジュラーデザインを使用して、 master デーモンによって制限付の権限を持つ小規模のプロセスが起動できるようにします。より小規模で、権限の低いプロセスは、メール配送の各種段階における特定のタスクを実行し、外部攻撃からの影響を低減する為に変更したルート環境で動作します。
ローカルコンピューター以外のホストからのネットワーク接続を承認するように Postfix を設定するのは、その設定ファイルを幾つか変更するだけです。そして、もっと複雑な設定が必要な場合は、 Postfix が各種の設定オプションの他に、柔軟で多機能の MTA にできるサードパーティの追加機能も提供します。
Postfix の設定ファイルは人間に判読できるもので、 250 以上のディレクティブをサポートします。 Sendmail とは異なり、変更が反映されるのにマクロプロセッシングは必要でなく、通常使用されるオプションのほとんどは大幅なコメントが付いているファイルに記述されています。
重要
Postfix を使用する前に、デフォルトの MTA を Sendmail から Postfix に切り替える必要があります。
Postfix の実行可能ファイルは /usr/sbin/postfix です。このデーモンがメール配送に必要な関連プロセスをすべて起動します。
Postfix はその設定ファイルを /etc/postfix/ ディレクトリ内に保存します。以下により一般的に使用されるファイルの一覧を示します:
-
access— アクセス制御に使用され、このファイルは Postfix に接続が許可されるホストを指定します。 -
aliases— メールプロトコルで必要となる設定ファイルです。 -
main.cf— グローバルな Postfix の設定ファイル。設定オプションのほとんどはこのファイル内に指定してあります。 -
master.cf— メール配送を達成する為の各種プロセスに対し Postfix がやり取りをする方法を指定します。 -
transport— ホストを中継する email アドレスのマップを示します。
重要
デフォルトの /etc/postfix/main.cf ファイルはローカルコンピューター以外のホストからのネットワーク接続を Postfix が承認することを許可しません。他のクライアント用に Postfix をサーバーとして設定する案内については 項12.3.2.2. 「Postfix の基本的な設定」 を参照して下さい。
/etc/postfix/ ディレクトリのファイル内にあるオプションを変更する場合、変更を反映する為には postfix サービスを再スタートする必要があります。これを実行する為の最も簡単な方法は次のコマンドを入力することです:
/sbin/service postfix restart
デフォルトでは、 Postfix はローカルホスト以外のホストからのネットワーク接続を受け付けません。以下のようなステップを root として実行するとネットワーク上の他のホスト用にメール配送が可能になります:
-
viなどのテキストエディタで/etc/postfix /main.cfファイルを編集します。 -
mydomainの行にあるハッシュマーク (#) を削除してコメント解除し、domain.tldをexample .comなど、メールサーバーがサービスしているドメインに入れ換えます。 -
myorigin = $mydomain行をコメント解除します。 -
myhostname行をコメント解除して、host.domain. tldをマシン用のホスト名に入れ換えます。 -
mydestination = $myhostname, localhost.$mydomainの行をコメント解除します。 -
mynetworksの行をコメント解除し、168.100.189.0/28をサーバーに接続できるホスト用の有効なネットワーク設定に入れ換えます。 -
inet_interfaces = allの行をコメント解除します。 -
postfixサービスを再起動します。
これらのステップが終了すると、ホストは配送の為に外部の電子メールを受け付けます。
Postfix には多種に渡る設定オプションがあります。 Postfix の設定の方法を学ぶ最良の手段は /etc/postfix/main.cf の中にあるコメントを読むことです。 LDAP や SpamAssassin の統合に関する情報を含む追加の案内は http://www.postfix.org/ でオンライン情報を見て下さい。
Fetchmail は、リモートサーバーから電子メールを呼び込んでローカルの MTA へそれを配送します。多くのユーザーが、リモートサーバーにあるメッセージをダウンロードするプロセスを、 MUA の中で電子メールの読み込みと編成のプロセスから分離できる能力を評価しています。ダイヤルアップをするユーザーのニーズを考慮してデザインされており、 Fetchmail は、 POP3 や IMAP などのプロトコルを使用して接続し、電子メールスプールファイルにすべての電子メールメッセージを高速にダウンロードします。 Fetchmail は、必要に応じて、 SMTP サーバーに電子メールメッセージを転送することもできます。
Fetchmail は、ユーザーのホームディレクトリ内の .fetchmailrc ファイルを使用してユーザーごとに設定されます。
Fetchmail は .fetchmailrc ファイルの設定内容を使用して、リモートサーバー上の電子メールの有無をチェックして抜き出し、電子メールを正しいユーザーのスプールファイルに配置するためにローカル MTA を使用して電子メールをローカルマシンのポート 25 に配信します。 Procmail が使用できる場合は、それを使用して電子メールをフィルタ処理してメールボックスに配置し、 MUA で読み取れるようにます。
Fetchmail を実行する時、リモートサーバー上の電子メールの有無をチェックする為にコマンドライン上のすべての必要なオプションをパスすることはできますが、 .fetchmailrc ファイルを使用した方がはるかに簡単です。 .fetchmailrc ファイル内に希望の設定オプションを配置すると fetchmail コマンドが発行される度にこれらのオプション用が使用できます。コマンドライン上でオプションを指定すると Fetchmail を実行する時にそのオプションを上書きすることができます。
ユーザーの .fetchmailrc ファイルには、3つのタイプの設定オプションが含まれています:
-
グローバルオプション — プログラムの動作を制御したり、電子メールの有無をチェックするすべての接続に設定を与えるための手順を Fetchmail に示します。
-
サーバーオプション — ポーリングされるサーバーに関するホスト名などの必要な情報を指定したり、特定の電子メールサーバーでチェックするポートやタイムアウトまで待つ秒数などの表示したい個人設定を指定したりします。これらのオプションは、そのサーバーで使用するユーザーオプションに影響を与えます。
-
ユーザーオプション — 特定の電子メールサーバーを使用した電子メールの認証やメールのチェックを行うのに必要なユーザー名やパスワードなどの情報が含まれています。
グローバルオプションは .fetchmailrc ファイルの一番上にあり、その後に1つ又は複数のサーバーオプションがあり、各サーバーオプションは Fetchmail がチェックしなければならない異なる電子メールサーバーを指定します。その電子メールサーバー上でチェックしたいユーザーアカウントごとに、サーバーオプションの後にユーザーオプションがあります。サーバーオプションと同様に、特定のサーバー上にある複数の電子メールアカウントをチェックしたいときなど、そのサーバーで使用する複数のユーザーオプションを指定できます。
サーバーオプションは、サーバー情報の前にある特別なオプションの動詞、すなわち、 poll や skip を使用して .fetchmailrc ファイル内のサービスに呼び出されます。 poll アクションは、このサーバーオプションの実行時にそのサーバーオプションを使用するように Fetchmail に指示し、そのサーバーオプションは指定のユーザーオプションを使用して電子メールの有無をチェックします。しかし、 Fetchmail を呼び出すときにこのサーバーのホスト名を指定しないと、 skip アクションの後のサーバーオプションはチェックされません。 skip オプションを使用すると、現在機能している設定に影響を与えずに、 .fetchmailrc 内にテスト設定を構成する時、特に呼び出された場合に、スキップしたサーバーだけをチェックします。
.fetchmailrc ファイルの簡単なサンプルは、次のように表示されます:
set postmaster "user1" set bouncemail poll pop.domain.com proto pop3 user 'user1' there with password 'secret' is user1 here poll mail.domain2.com user 'user5' there with password 'secret2' is user1 here user 'user7' there with password 'secret3' is user1 here
この例では、グローバルオプションは、最終手段としてユーザーに電子メールを送り (postmaster オプション)、すべての電子メールエラーを送信者ではなく、ポストマスターに送るように (bouncemail オプション) 指定します。 set アクションは、この行にグローバルオプションが含まれていることを Fetchmail に伝えます。その後、2つのメールサーバーが指定され、その1つは POP3 を使用してチェックするようにセットされ、もう1つは機能するものを検索するために各種のプロトコルを試行するようにセットされます。2つ目のサーバーオプションを使用して2人のユーザーがチェックされますが、ユーザーのいずれかの為のメールはすべて user1 のメールスプールに送られます。これにより、複数のサーバー上で複数のメールボックスがチェックできるようになり、1つの MUA インボックスに表示されます。各ユーザー特有の情報は、 user アクションで始まります。
注意
.fetchmailrc ファイルにパスワードを設定する必要はありません。 with password '<password>' を省略すると、 Fetchmail が起動された時にパスワードを要求するようになります。
Fetchmail には、多くのグローバル、サーバー、及びローカルのオプションが含まれています。これらのオプションの多くは、稀にしか使用されないか、又は非常に特別な場合のみの使用となります。 fetchmail の man ページでは、各オプションを詳細に説明していますが、殆どの一般的なものはここでリストしてあります。
各グローバルオプションは、 set アクションの後の1行に設定してください。
-
daemon— Fetchmail がバックグランドにいる状態のデーモンモードを指定します。<seconds><seconds>は、 Fetchmail がサーバーをポーリングする前の待ち時間の秒数で入れ換えます。 -
postmaster— 配達の問題がある場合、メールを送るためのローカルユーザーを指定します。 -
syslog— エラーとステータスメッセージ用のログファイルを指定します。デフォルトでこれは、/var/log/maillogです。
サーバーオプションは poll 又は skip のアクションの後に .fetchmailrc のそれ自身の行に配置します。
-
auth—<auth-type><auth-type>を使用する認証のタイプに入れ換えます。デフォルトでは、password認証が使用されますが、プロトコルによってはkerberos_v5、kerberos_v4、sshなどの他のタイプの認証もサポートするものがあります。any認証タイプを使用すると、 Fetchmail はまず、パスワードを必要としない方法を試し、次にパスワードをマスクする方法を試し、最後に認証するためのパスワードを平文でサーバーに送ろうとします。 -
interval— すべての設定済みサーバー上で電子メールの有無をチェックする<number><number> -
port—<port-number><port-number>を実際のポート番号で入れ換えます。この値は指定されたプロトコルのデフォルトポート番号を上書きします。 -
proto—<protocol><protocol>をpop3やimapなどのプロトコルに入れ換えてサーバー上でメッセージの有無をチェックする為に使用します。 -
timeout—<seconds><seconds>を Fetchmail が接続試行を諦めるまでのサーバーの不活動期間を秒数で入れ換えます。この値が指定されていない場合、デフォルトの300秒が採用されます。
ユーザーオプションは、サーバーオプションの下の独自の行か、サーバーオプションと同じ行に配置できます。いずれの場合も、定義したオプションは user オプション（以下で定義している）の後に表示されます。
-
fetchall— すでに表示されているメッセージを含むキュー内のすべてのメッセージをダウンロードするように Fetchmail に指示します。デフォルトでは、 Fetchmail は新しいメッセージだけをプルダウンします。 -
fetchlimit—<number><number>を停止する前に取り込むメッセージ数で入れ換えます。 -
flush— 新しいメッセージを取り込む前にキュー内のすでに表示されているすべてのメッセージを削除します。 -
limit—<max-number-bytes><max-number-bytes>の部分を Fetchmail で呼び込む時に許可する最大限メッセージのバイト数で入れ換えます。このオプションは、大きいメッセージをダウンロードするのに時間がかりすぎるような低速ネットワークリンクで便利です。 -
password '—<password>'<password>をこのユーザーのパスワードで入れ換えます。 -
preconnect "—<command>"<command>の部分をこのユーザーに対するメッセージの呼び込み前に実行されるコマンドに入れ換えます。 -
postconnect "—<command>"<command>の部分をこのユーザーに対するメッセージの取り込み後に実行するコマンドで入れ換えます。 -
ssl— SSL 暗号化を有効にします。 -
user "—<username>"<username>の部分を、メッセージを取り込む為に Fetchmail が使用するユーザー名に入れ換えます。 このオプションは、ほかのユーザーオプションの前に表示する必要があります。
コマンドラインで使用できる Fetchmail オプションの大半は、 fetchmail コマンドを実行するときに、 .fetchmailrc 設定オプションをミラー化します。このミラー化が行われるのは、設定ファイルがあっても、なくても Fetchmail を使用できるようにするためです。大半のユーザーは、コマンドラインでこれらのオプションを使用しません。それは、使用される .fetchmailrc ファイルにこれらのオプションを残すほうが簡単だからです。
しかし、特定目的のために他のオプションを付けて fetchmail コマンドを実行したい場合があります。コマンドラインで指定されたすべてのオプションは設定ファイルオプションを無効にするので、コマンドオプションを発行して、エラーを発生させている .fetchmailrc の設定を一時的に無効にすることもできます。
fetchmail コマンドの後に使用されるある種のオプションは、重要な情報を与える可能性があります。
-
--configdump—.fetchmailrcと Fetchmail のデフォルトからの情報に基づいてすべての可能なオプションを表示します。このオプションを使用すると、ユーザーに対する電子メールは検索されません。 -
-s— Fetchmail をサイレントモードで実行し、エラー以外のメッセージがfetchmailコマンドの後に表示されないようにします。 -
-v— Fetchmail を詳細モードで実行し、 Fetchmail とリモート電子メールサーバーの間のすべての通信を表示します。 -
-V— このオプションを選択すると、 Fetchmail は詳細バージョン情報を表示し、そのグローバルオプションを一覧し、電子メールプロトコルや認証方法などの各ユーザーで使用される設定を示します。このオプションを使用すると、ユーザーに対する電子メールは検索されません。
これらのオプションは、 .fetchmailrc ファイルでよく見られるデフォルトを無効にする場合に便利です。
-
-a— （新しいメッセージかすでに表示されたメッセージかに関係なく） Fetchmail はリモート電子メールサーバーからすべてのメッセージをダウンロードします。デフォルトでは、 Fetchmail は、新しいメッセージだけをダウンロードします。 -
-k— Fetchmail はメッセージをダウンロードした後でもリモート電子メールサーバー上にメッセージを残します。このオプションは、メッセージをダウンロードした後にメッセージを削除するデフォルト動作を無効にします。 -
-l— Fetchmail は特定サイズ以上のメッセージはダウンロードせず、リモート電子メールサーバー上にそれらを残すようにします。<max-number-bytes> -
--quit— Fetchmail デーモンプロセスを終了します。
fetchmail マニュアルページには、以上のコマンド以外のコマンドや .fetchmailrc オプションが表示されています。
Mail Transport Agent (MTA) は、電子メールを送るのに必須のものです。 Evolution、 Thunderbird 及び Mutt のような Mail User Agent (MUA) は、電子メールを読んだり作成するのに使用されます。ユーザーが MUA から電子メールを送信するときは、それが宛先に届くまで一連の MTA からメッセージを送信する MTA にメッセージを引き渡します。
たとえユーザーがシステムから電子メールを送信するつもりでなくても、いくつかの自動化タスク又はシステムプログラムは、ログメッセージを含む電子メールをローカルシステムの root ユーザーに送信するために /bin/mail コマンドを使用するかもしれません。
Red Hat Enterprise Linux 5 は、 Sendmail 、 Postfix 、 及び Exim の3つの MTA を提供します。もし3つすべてがインストールされていれば、 sendmail がデフォルトの MTA になります。 メール転送エージェント切り替え は、 sendmail、 postfix、および exim のいずれかから、システムのデフォルトの MTA として選択することを可能にします。
メール転送エージェント切り替え プログラムのテキストベースのバージョンを使用するには、 system-switch-mail RPM パッケージがインストールされている必要があります。グラフィックなバージョンを使用したい場合は、 system-switch-mail-gnome パッケージもインストールされている必要があります。
メール転送エージェント切り替え を起動するには、 システム (パネル上のメインメニュ) => 管理 => メール転送エージェント切り替え を選択するか、シェルプロンプトで (例えば XTerm 又は GNOME ターミナルで) コマンド system-switch-mail を入力します。
X Window システムが起動している場合、プログラムは自動検出します。もしそれが起動してきる場合、 図 12.1. 「メール転送エージェント切り替え」 で見られるようなグラフィカルモードで起動します。 X が検出されない場合、それはテキストモードで起動します。 メール転送エージェント切り替え を強制的にテキストモードで起動させるには、 system-switch-mail-nox コマンドを使用してください。
MTA を変更するために OK を選択した場合、選択されたメールデーモンはブート時に起動するために有効になっていて、選択されていないメールデーモンは無効になっているのでブート時に起動されません。選択されたメールデーモンが起動し、その他のメールデーモンは停止しているので、変更は即座に行われます。
Red Hat Enterprise Linux には2種類の主要 MDA (Procmail と mail) が含まれています。これらのアプリケーションは両方とも、 LDA と考えられ、その両方が電子メールを MTA のスプールファイルからユーザーのメールボックスへ転送します。しかし、 Procmail は強健なフィルターシステムを提供します。
このセクションは、 Procmail のみについて詳細を説明します。 mail コマンドについての情報は、その man ページを御覧下さい。
Procmail を使用すると、ローカルホストのメールスプールファイルにある電子メールのフィルターと配送をします。 Procmail は強力で、システムリソースにやさしく、広範囲で使用されています。これは、電子メールクライアントアプリケーションで読み込まれる予定の電子メールを配送する時点で重要な役割りを果たします。
Procmail は幾つかの方法で喚起されます。 MTA が電子メールをメールスプールファイルに配置すると Procmail が起動します。その後 Procmail は MUA の為に電子メールをフィルタしファイルして終了します。別の方法では、メッセージが受信された時に Procmail を実行するように MUA を設定してメッセージが正しいメールボックスに移動されるようにします。デフォルトでは、 /etc/procmailrc 、又はユーザーのホームディレクトリ内の .procmailrc ファイル (あるいは rc ファイルとも呼ばれる) の存在は、 MTA が新しいメッセージを受信する度に Procmail を喚起します。
Procmail が電子メールでとるアクションは、メッセージが rc ファイルの中の特定の条件、又は レシピ に適合するかにより左右されます。メッセージがレシピに一致すると、電子メールは特定のファイル内に設定されるか、削除されるか、またはそれ以外の方法で処理されます。
Procmail が起動すると、電子メールメッセージを読み取り、ヘッダー情報から本体を分離します。次に、 Procmail はデフォルトのシステム全体の Procmail 環境変数とレシピ用の /etc/procmailrcs ディレクトリ内の /etc/procmailrc ファイルと rc ファイルを探します。次に、 Procmail はユーザーのホームディレクトリ内の . procmailrc ファイルを探します。多くのユーザーは、自己のホームディレクトリ内の .procmailrc で参照される Procmail 用の追加 rc ファイルも作成します。
デフォルトでは、システム全体の rc ファイルが /etc ディレクトリに存在せず、ユーザーのホームディレクトリ内の .procmailrc ファイルも存在しません。その為 Procmail の使用を開始するには、特定の環境変数と、特定の規則をもって、 .procmailrc ファイルを作成する必要があります。
Procmail 設定ファイルには、重要な環境変数が含まれています。これらの変数は、どのメッセージをソートするか、レシピに一致しないメッセージをどう処理するかなどを指定します。
これらの環境変数は通常、 .procmailrc の先頭に表示されます。以下のような形式になります：
<env-variable>="<value>"
この例では、 <env-variable><value>
環境変数の多くはほとんどの Procmail ユーザーに使用されず、それより重要な環境変数の多くはすでにデフォルト値が定義されています。ほとんどの場合、次のような変数が使用されます：
-
DEFAULT— レシピに一致しないメッセージが設定されるデフォルトのメールボックスを設定します。デフォルトの
DEFAULT値は、$ORGMAILと同じです。 -
INCLUDERC— チェックするメッセージのためのより多くのレシピを含む追加のrcファイルを指定します。このため、スパムのブロッキングや電子メールリストの管理などのさまざまな役割を満たす個々のファイルに Procmail レシピを分離し、ユーザーの.procmailrcファイル内のコメント文字を使用してそれらの役割をオン/オフに切り替えることができます。例えば、ユーザーの
.procmailrcファイルの行は次のようになります：MAILDIR=$HOME/Msgs INCLUDERC=$MAILDIR/lists.rc INCLUDERC=$MAILDIR/spam.rcユーザーが電子メールリストの Procmail フィルタ処理をオフに切り替えて、スパム制御は所定の位置に残したい場合、
#文字で最初のINCLUDERC行をコメント化します。 -
LOCKSLEEP— Procmail が特定のロックファイルを使おうとする試行と試行の間の時間数を秒単位で設定します。デフォルトは 8 秒です。 -
LOCKTIMEOUT— ロックファイルが古くて削除できると Procmail が判断するまでに、ロックファイルが最後に変更されてから経過しなければならない時間数を秒単位で設定します。デフォルトは 1,024 秒です。 -
LOGFILE— Procmail の情報メッセージかエラーメッセージのいずれかを含むファイル。 -
MAILDIR— Procmail にカレント作業ディレクトリを設定します。設定すると、他の Procmail パスはすべてこのディレクトリを起点にします。 -
ORGMAIL— オリジナルメールボックスを指定するか、メッセージを、デフォルトロケーションかレシピが要求するロケーションに設定できない場合に、メッセージを設定する別の場所を指定します。デフォルトでは、
/var/spool/mail/$LOGNAMEの値が使用されます。 -
SUSPEND— スワップスペースなどの必要なリソースがない場合に Procmail が休止する時間数を秒単位で設定します。 -
SWITCHRC— このオプションを使用すると、追加の Procmail レシピを含む外部ファイルを指定できます。レシピチェックが実際に参照用設定ファイル上で停止し、SWITCHRCで指定されたファイルのレシピだけが使用されること以外、INCLUDERCオプションと非常に似ています。 -
VERBOSE— このオプションの使用で、 Procmail は多くの詳細情報をログにとることができます。このオプションはデバッグに便利です。
他の重要な環境変数は、ログイン名である LOGNAME 、ホームディレクトリのロケーションである HOME 、デフォルトシェルである SHELL などのシェルから抜き出されます。
すべての環境変数とそれらのデフォルト値に関する総合的な説明は、 procmailrc の man ページで御覧下さい。
新規ユーザーには、多くの場合、レシピの作成が Procmail を使用するための最も困難な学習領域と思われるかも知れません。ある程度理解できるものです。それは、レシピが照合用文字列に修飾を指定するための特別なフォーマットである 正規表現 を使用してメッセージの照合を行うからです。ただし、正規表現はそれほど設定しにくかったり、読み取るときに理解しにくかったりするものではありません。また、 Procmail レシピを書く方法の一貫性は、正規表現とは無関係に、何が行われているかを例で容易に見ることが出来ます。 Procmail レシピの例を見るには 項12.5.2.5. 「レシピの例」 を参照して下さい。
Procmail レシピは、次の形式をとります:
:0<flags>: <lockfile-name> * <special-condition-character><condition-1> * <special-condition-character><condition-2> * <special-condition-character><condition-N><special-action-character><action-to-perform>
Procmail レシピの最初の2文字はコロン（:）と 0 です。このレシピを処理するときに Procmail が何をするかを制御するには、 0 の後に各種フラグを設定できます。 <flags><lockfile-name>
レシピには、メッセージと照合するいくつかの条件を含めることができます。条件がない場合、すべてのメッセージはレシピに一致します。正規表現にはメッセージとの照合を実施するために、いくつかの条件が設定されます。複数の条件を使用する場合、アクションを実行するためにこれらの条件がすべて一致しなければなりません。条件は、レシピの最初の行で設定されたフラグに基づいてチェックされます。 * 文字の後に設定されたオプションの特別な文字は、さらに条件を制御できます。
<action-to-perform>
レシピが特定メッセージに一致する場合に使用されるアクションは、レシピが 配信 と 非配信 のいずれかであるかを決定します。「配信レシピ」には、ファイルにメッセージを書き込んだり、別のプログラムにメッセージを送ったり、別の電子メールアドレスにメッセージを転送したりするアクションが含まれています。「非配信レシピ」は、 ネスト用ブロック などの他のアクションをカバーします。ネスト用ブロックとは、レシピの条件に一致するメッセージで実行する括弧 {と } に囲まれたアクションのセットです。ネスト用ブロックをさらにネストして、メッセージ上のアクションを識別して実行するためのさらに大きな制御を与えることができます。
メッセージが配信レシピと一致する場合、 Procmail はその特定アクションを実行し、他のレシピとメッセージの比較を停止します。非配信レシピと一致するメッセージは他のレシピに対して比較が続けられます。
フラグは、いかにレシピの条件をメッセージと比較するか、あるいはレシピの条件をメッセージと比較するかどうかを決定する際に非常に重要です。次のフラグが一般に使用されます:
-
A— このレシピがAフラグやaフラグのない以前のレシピもこのメッセージに一致した場合のみ使用されることを指定します。 -
a— このレシピがAフラグやaフラグのある以前のレシピもこのメッセージに一致し さらに 正常に完了した場合のみ使用されることを指定します。 -
B— メッセージの本文を構文解析し、一致する条件を探します。 -
b— メッセージをファイルに書き込んだり転送したりするなどの結果的なアクションで本文を使用します。これはデフォルトの動作です。 -
c— 電子メールのカーボンコピーを作成します。これが配信レシピで便利なのは、必要なアクションをメッセージ上で実行でき、メッセージのコピーをrcファイルで処理し続けることができるからです。 -
D—egrepの比較を大文字と小文字を区別するものにします。デフォルトでは、比較プロセスは大文字と小文字を区別しません。 -
E—Aフラグと似ていますが、Eフラグのない直前のレシピが一致しなかった場合にこのレシピ内の条件がメッセージと比較されます。これは、 else アクションに匹敵します。 -
e— 直前のレシピに指定されたアクションが失敗した時のみ、レシピはメッセージと比較されます。 -
f— パイプをフィルタとして使用します。 -
H— メッセージのヘッダーを構文解析し、一致する条件を探します。これは、デフォルトで行われます。 -
h— 結果のアクションでヘッダーを使用します。これはデフォルトの動作です。 -
w— 指定されたフィルタか、プログラムが終了するまで待機し、フィルタ処理されたメッセージを考慮する前にそのフィルタか、プログラムが成功したかどうかを報告するように Procmail に指示します。 -
W— "Program failure" メッセージが抑制されていること以外はwと同一です。
追加フラグの詳細一覧は、 procmailrc man ページを参照して下さい。
ロックファイルは、 Procmail で複数のプロセスが同時に一定のメッセージを変更することを止めるのに非常に便利です。レシピの最初の行のフラグの後にコロン (:) を設定することによって、ローカルロックファイルを指定できます。このため、宛先のファイル名と LOCKEXT グローバル環境変数で設定されたすべてのものに基づいて、ローカルロックファイルが作成されます。
別の方法として、コロンの後にこのレシピで使用するローカルロックファイルの名前を指定します。
Procmail レシピの条件とアクションの前に使用される特別な文字は、それら条件とアクションを解釈する方法を変更します。
レシピの条件行の先頭にある * 文字の後に、次の文字を使用できます。
-
!— 条件の行でこの文字は条件を反転するため、条件がメッセージと一致しない場合のみ照合が行われます。 -
<— メッセージが指定のバイト数より少ないかどうかを確認します。 -
>— メッセージが指定数のバイトより多いかどうかを確認します。
特別なアクションを実行するには、次の文字を使用します。
-
!— アクションの行では、この文字が指定され電子メールアドレスにメッセージを転送するように Procmail に指示します。 -
$—rcファイル内で以前に設定された変数を参照します。これは通常、各種レシピで参照される共用メールボックスを設定する場合に使用します。 -
|— メッセージをプロセスする為に特定のプログラムを起動します。 -
{and}— 追加レシピを組み込んで照合用メッセージに適用するためのネスト用ブロックを作成します。
アクション行で特別な文字を使用しない場合、 Procmail はメッセージを書く為のメールボックスをそのアクション行が指定していると判定します。
Procmail は非常に柔軟性のあるプログラムで、この柔軟性の結果、初めから Procmail レシピを作成することは、新規ユーザーにとって困難である可能性があります。
Procmail レシピの条件を設定する技能を開発する最善の手段は、他の人が組み立てた多くの例を参考にすることと共に、正規表現の十分な理解から始まります。正規表現についての完全な説明は、このセクションの担当範囲を越えています。 Procmail レシピの構成と、役立つサンプルの Procmail レシピがインターネットのさまざまなサイトで参照できます。 (例えば：http://www.iki.fi/era/procmail/links.html) 正規表現の正しい使用とその応用はこれらのレシピサンプルを参照することで理解できます。さらに、基本的な正規表現規則の入門情報は、 grep の man ページで参照することが出来ます。
次の簡単なサンプルが Procmail レシピの基本的な組み立てを示し、そしてより複雑な構成の基盤を提供します。
基本的なレシピには、次の例で示すように条件が付いていないものさえあります：
:0: new-mail.spool
第1行では、ローカルロックファイルを作成しても名前を指定しないように指示して Procmail が宛先のファイル名を使用して、 LOCKEXT 環境変数にある値を付けます。条件は指定されないので、すべてのメッセージがこのレシピに一致して、 MAILDIR 環境変数で指定されたディレクトリ内にある new-mail.spool と呼ぶ単一のスプールファイルに設定されます。この場合、 MUA はこのファイル内のメッセージを見ることができます。
このような基本的なレシピは、全ての rc ファイルの末尾に配置して、メッセージをデフォルトの場所に転送します。
次のサンプルは特定の電子メールアドレスからのメッセージと一致しており、それを廃棄します。
:0 * ^From: spammer@domain.com /dev/null
この例では、 spammer@domain.com から送られたメッセージはすべて、ただちに /dev/null デバイスに移動され削除されます。
重要
メッセージを永久削除の為に /dev/null に移動する前に規則が正しく機能していることに注意してください。レシピ条件で不注意に意図していないメッセージを取り込んで、そのメッセージが跡形もなく消滅した場合、規則をトラブルシュートすることが困難になります。
改善案としてはレシピのアクションを特定のメールボックスにポイントして、それが、定期的に false positives を探すようにします。すなわち偶然に条件と一致したメッセージを探すためにチェックするようにします。偶然に一致したメッセージがないと確認できた後は、メールボックスを削除してアクションに対しメッセージを /dev/null に送るように指示します。
次のレシピは特定のメーリングリストから配送された電子メールを取り込み、それを指定されたフォルダーに配置します。
:0: * ^(From|CC|To).*tux-lug tuxlug
tux-lug@domain.com メーリングリストから送られたメッセージはすべて、 MUA のために tuxlug メールボックスに自動的に配置されます。メールの From 行、 CC 行、 To 行のどれかにメーリングリストの電子メールアドレスがあれば、この例の条件はメッセージに一致することに注意してください。
より詳細で強力なレシピを調べるには 項12.7. 「その他のリソース」 で確認できる、多数の Procmail オンラインリソースを参照して下さい。
新しい電子メールの受信時に Sendmail 、 Postfix 、 Fetchmail によってコールされますので、 Procmail はスパムと戦う強力なツールとして使用されます。
これは特に Procmail が SpamAssassin と併用される時に明確になります。一緒に使用するとこれらの2つのアプリケーションは素早くスパムを認識して、分類するか又は破壊します。
SpamAssassin はヘッダ解析、テキスト解析、ブラックリスト、スパム追跡データベース、及び学習機能のある Bayesian スパム解析を使用し、スパムを正確に素早く識別してタグを付けます。
ローカルユーザーにとって最も簡単な SpamAssassin の使用法は、以下の行を ~/.procmailrc ファイルの先頭近くに置くことです：
INCLUDERC=/etc/mail/spamassassin/spamassassin-default.rc
/etc/mail/spamassassin/spamassassin-default.rc には、着信の電子メールすべての為に SpamAssassin を起動する簡単な Procmail 規則が含まれています。電子メールがスパムだと判定された場合、そのようにヘッダにタグが付けられ、タイトルは次のパターンでその前に付けられます：
*****SPAM*****
電子メールのメッセージ本文もまた、何が原因してスパムと診断されたのかという流動符号が前付けされます。
スパムとしてタグの付く電子メールをファイルするには、次の規則と良く似たものが使用されます：
:0 Hw * ^X-Spam-Status: Yes spam
この規則はヘッダ内でスパムとタグの付いた電子メールの全てを spam と呼ばれるメールボックスにファイルします。
SpamAssassin は Perl スクリプトなので、負荷の大きいサーバー上ではバイナリ SpamAssassin デーモン (spamd) およびクライアントアプリケーション (spamc) を使用する必要があるかも知れません。このような SpamAssassin の設定にはルートでホストにアクセスしなければいけません。
spamd デーモンをスタートするには、ルートで以下のように入力します：
/sbin/service spamassassin start
システムが起動するときに SpamAssassin デーモンをスタートさせるには、 サービスの設定ツール (system-config-services) などの initscript ユーティリティを使用して spamassassin サービスを始動します。 initscript ユーティリティに関する詳細情報を参照して下さい。
Perl スクリプトの代わりに、 Procmail を設定して SpamAssassin クライアントアプリケーションを使用する場合、以下の行を ~/.procmailrc ファイルの上部に配置します。システム全体の設定には、その行を /etc/procmailrc の中に入れます：
INCLUDERC=/etc/mail/spamassassin/spamassassin-spamc.rc
Red Hat Enterprise Linux には、多数のメールプログラムが揃っています。その中には Ximian Evolution などの機能満載でグラフィカル電子メールクライアントプログラムと、さらには mutt のようなテキストベースの電子メールプログラムも含まれています。
このセクションの後の部分では、クライアントとサーバー間の通信のセキュリティに焦点をおいて説明していきます。
Ximian Evolutionmuttなど、 Red Hat Enterprise Linux に組み込まれた人気のある MUA は、 SSL で暗号化された電子メールセッションを提供します。
暗号化されずにネットワーク上を流れる他のサービスと同様に、ユーザー名、パスワード、メッセージ全体などの重要な電子メール情報はすべて、傍受して見られるおそれがあります。標準の POP プロトコルと IMAP プロトコルでは、すべての認証情報は「平文」 (暗号化なし) で送られますので侵入者が、ネットワーク上を通過するユーザー名とパスワードを取得することにより、ユーザーのアカウントにアクセスする可能性があります。
リモートサーバー上の電子メールをチェックするような設計のほとんどの Linux MUA は、 SSL 暗号化をサポートします。電子メールを検索するときに SSL を使用するには、電子メールを電子メールクライアントとサーバー上で有効にする必要があります。
SSL はクライアント側で簡単に有効にできます。これは多くの場合、 MUA の設定領域でボタンをクリックするか、 MUA 設定ファイル内でオプションを使用します。安全な IMAP と POP は、 MUA がメッセージの認証とダウンロードに使用する既知のポート番号 （それぞれ 993 と 995） を持っています。
電子メールサーバー上の IMAP ユーザーと POP ユーザーに SSL 暗号化を提供するのは、簡単にできます。
先ず、 SSL 証明書を作成します。これは2つの方法で達成できます： SSL 証明書を取得できるように CA (Certificate Authority) へ申請する方法と、自己署名付き証明書を作成する方法です。
重要
自己署名付き証明書は、テスト目的の為にのみ使用すべきものです。生産環境で使用するサーバーはすべて CA により認可された SSL 証明書を使用すべきです。
IMAP 用に自己署名付き SSL 証明書を作成するには、 /etc/pki/tls/certs/ ディレクトリに入り、次のコマンドをルートとして入力します：
rm -f cyrus-imapd.pem make cyrus-imapd.pem
すべての質問に答えるとプロセスを完了します。
POP 用に自己署名付き SSL 証明書を作成するには、 /etc/pki/tls/certs/ ディレクトリに入り、ルートとして次のコマンドを入力します：
rm -f ipop3d.pem make ipop3d.pem
ここでも全ての質問に答えてプロセスを完了します。
重要
デフォルトの imapd.pem および ipop3d.pem ファイルを確実に削除してから、それぞれの make コマンドを発行して下さい。
その終了後、 /sbin/service xinetd restart コマンドを実行して imapd および ipop3d を制御する xinetd デーモンを再起動します。
別の方法としては、 stunnel コマンドを、標準の安全でない imapd デーモン又は pop3d デーモンの周りを囲む SSL 暗号化ラッパーとして使用することも出来ます。
stunnel プログラムは Red Hat Enterprise Linux に収納されている外部 OpenSSL ライブラリを使用して強力な暗号化法と接続保護を提供します。これには、 SSL 証明書を取るためには証明書権限 (Certificate Authority) に申請するのが適切です。但し、自己署名付き証明書を作成することも可能です。
自己署名付き SSL 証明書を作成するには、 /etc/pki/tls/certs/ ディレクトリに入り、以下のコマンドを入力します：
make stunnel.pem
ここでも全ての質問に答えてプロセスを完了します。
証明書が生成されると、 stunnel コマンドを使用して、 imapd メールデーモンがスタートできるようになります。次のコマンドを入力します：
/usr/sbin/stunnel -d 993 -l /usr/sbin/imapd imapd
このコマンドが発行されると、 IMAP 電子メールクライアントを開くことが出来て、 SSL 暗号を使用した電子メールサーバーへの接続ができます。
stunnel コマンドを使用して pop3d をスタートするには、以下のコマンドを入力します：
/usr/sbin/stunnel -d 995 -l /usr/sbin/pop3d pop3d
stunnel の使用法に関する詳細は stunnel の man ページを参照するか、又は次のディレクトリにあるドキュメントを参照して下さい。 /usr/share/doc/stunnel-/ ディレクトリ。ここで <version-number><version-number> は、 stunnel のバージョン番号です。
以下に電子メールアプリケーションに関するその他のドキュメントの一覧を示します。
-
Sendmail の設定に関する情報は、
sendmailとsendmail-cfのパッケージの中に収納されています。-
/usr/share/sendmail-cf/README—m4、 Sendmail のファイルロケーション、サポートされるメイラー、高度な機能にアクセスする方法などに関する情報を示します。
その他に
sendmailの man ページ及びaliasesの man ページには、それぞれ各種 Sendmail オプションと Sendmail/etc/mail/aliasesファイルの正しい設定に関する役立つ情報が含まれています。 -
-
/usr/share/doc/postfix-— このディレクトリには、 Postfix 設定する為の方法に関する多くの情報が含まれています。<version-number><version-number>では、 Postfix のバージョン番号を入れます。 -
/usr/share/doc/fetchmail-—<version-number>FEATURESファイル内の Fetchmail 機能と導入用FAQドキュメントの完全なリストを含んでいます。<version-number>は、 Fetchmail のバージョン番号で入れ換えます。 -
/usr/share/doc/procmail-— Procmail の概要を示す<version-number>READMEファイル、すべてのプログラム機能を探索するためのFEATURESファイル、及び多数の一般的な設定の質問に対する回答を示すFAQファイルが含まれています。<version-number>は Procmail のバージョン番号で入れ換えます。Procmail の機能を学習したり新しいレシピを作成する場合、以下の Procmail マニュアルページは非常に役に立ちます。
-
procmail— Procmail の機能の概要と電子メールのフィルタ処理に関連するステップを示します。 -
procmailrc— レシピの作成に使用するrcファイルフォーマットについて説明しています。 -
procmailex— 多数の有効な現実世界の Procmail レシピの例を示します。 -
procmailsc— 特定のレシピをあるメッセージに照合するために、 Procmail で使用されるウェイト付きスコア計算手法について説明しています。 -
/usr/share/doc/spamassassin-— このディレクトリには、 SpamAssassin に関する大量の情報が含まれています。ここで<version-number>/<version-number>の部分はspamassassinパッケージのバージョン番号で入れ換えます。
-
-
http://www.sendmail.org/ — Sendmail の機能、文書及び設定の例の徹底的な技術分析を提供しています。
-
http://www.sendmail.com/ — 提供されている多数のオプションの拡大ビューなど、 Sendmail に関するニュース、インタビュー、記事などを含んでいます。
-
http://www.postfix.org/ — Postfix プロジェクトのホームページには Postfix についての豊富な情報が含まれています。情報を得るにはそのメーリングリストが特に役に立ちます。
-
http://fetchmail.berlios.de/ — Fetchmail のホームページで、オンラインマニュアルと総括的な FAQ を特徴とします。
-
http://www.procmail.org/ — Procmail 専用のメーリングリストと各種 FAQ ドキュメントへのリンクを持つ Procmail のホームページ。
-
http://partmaps.org/era/procmail/mini-faq.html — トラブルシューティングのヒントや、ファイルロッキングとワイルドカード文字の使い方などに関する詳細を示す、優れた Procmail FAQ。
-
http://www.uwasa.fi/~ts/info/proctips.html —
.procmailrcファイルをテストし、 Procmail スコア機能を使用して特定のアクションをとる必要があるかどうかを決定するなど、さまざまな状況での Procmail の使用を非常に簡単にする多数のヒントを提供しています。 -
http://www.spamassassin.org/ — SpamAssassin プロジェクト本部のサイトです。
-
Bryan Costales と Marcia Flynt 箸 Sendmail Milters: A Guide for Fighting Spam; Addison-Wesley — メールフィルタをカスタマイズするのに役立つ、良い Sendmail のガイドです。
-
Sendmail Bryan Costales、 Eric Allman、その他共著。 O'Reilly & Associates — Delivermail と Sendmail の最初の作成者の支援を受けて書かれた優れた Sendmail リファレンス。
-
Removing the Spam: Email Processing and Filtering Geoff Mulligan著 ; Addison-Wesley Publishing Company — Sendmail や Procmail などの定評のあるツールを使用してスパムの問題を管理する電子メール管理者が使用するさまざまな方法を考察した本。
-
Internet Email Protocols: A Developer's Guide Kevin Johnson 箸; Addison-Wesley Publishing Company — 主要な電子メールプロトコルやそれらのプロトコルが提供するセキュリティについて徹底的に検討しています。
-
Managing IMAP Dianna Mullet と Kevin Mullet 箸; O'Reilly & Associates — IMAP サーバーを設定するのに必要なステップについて詳述しています。
LDAP (Lightweight Directory Access Protocol) とは、ネットワーク上の中枢にある保存情報にアクセスするための一連のオープンプロトコルです。ディレクトリ共有用に X.500 基準をベースとしていますが、複雑ではなくリソース集中型です。このため、 LDAP は時には "X.500 Lite" とも呼ばれます。 X.500 基準は、階級化され分類化された情報を含んでおり、その中には名前、住所、電話番号などの情報を含ませることができます。
X.500 の様に LDAP は、ディレクトリを使用して情報を階級式に構成します。これらのディレクトリは各種の情報を保存でき、さらにはネットワーク情報サービス (NIS) と似た方法で使用することができます。 LDAP が有効になっているネットワーク上では誰でも、どのマシンからも自分のアカウントにアクセスできます。
多くの場合、 LDAP は仮想電話帳として使用され、ユーザーが他のユーザーの連絡先情報に簡単にアクセスすることができます。 LDAP は従来の電話帳よりも柔軟性があり、世界中の他の LDAP サーバーへ参照できることから、臨時的な情報のグローバルリポジトリを提供します。ただし現在、 LDAP は大学、政府の各部門、民間企業などの個々の組織内での使用が一般的です。
LDAP はクライアント/サーバー型のシステムです。サーバーは、ディレクトリを保存するのに各種のデータベースを使用し、それぞれが迅速で大量の読み込み操作を行なうために最適化されています。 LDAP のクライアントアプリケーションが LDAP サーバーにアクセスする時は、ディレクトリに問い合わせするか、あるいはそれを変更しようとします。問い合わせの場合は、サーバーはそれに答えるか、又はローカルで回答出来ない場合、サーバーはその問い合わせの回答を持つ LDAP サーバーへ案内します。クライアントアプリケーションが LDAP ディレクトリの情報を変更しようとしている場合は、サーバーはそのユーザーが変更する権限を持っているかどうかを検証してから情報の追加なり更新なりをします。
本章では、 LDAPv2 及び LDAPv3 プロトコルのオープンソース実装である OpenLDAP 2.0 の設定とその使用法を参照します。
LDAP を使用することの主要なメリットは、全組織内の情報を中央のリポジトリに統合できることです。例えば、組織内のそれぞれのグループのユーザー一覧を管理するのではなく、 LDAP をネットワーク上のどこからでもアクセスできる中央ディレクトリとして使用します。その上、 LDAP は Secure Sockets Layer (SSL)と Transport Layer Security (TLS) をサポートしますので、機密データを外部の侵入から保護することができます。
LDAP はまた、ディレクトリを収納するバックエンドデータベースを数多くサポートします。これにより、管理者はサーバーが分配する情報のタイプに最も適したデータベースを起用できる柔軟性を持つことになります。 LDAP はまた、適切に定義されたクライアントアプリケーションプログラミングインターフェイス (API) を持つ為、 LDAP 対応のアプリケーションの数は多く、更にはその質と量も上昇中です。
OpenLDAP は数多くの重要な機能を含んでいます。
-
LDAPv3 サポート — OpenLDAP は、他の改良と共に SASL (Simple Authentication and Security Layer)、 TLS (TLS Transport Layer Security)、及び SSL (Secure Sockets Layer) をサポートします。 LDAPv2 以後、プロトコル内の多くの変更は、 LDAPに より高度なセキュリティを与えるように設計されています。
-
IPv6 サポート — OpenLDAP は次世代のインターネットプロトコルのバージョン 6 に対応しています。
-
IPC上でのLDAP — OpenLDAP は インタープロセスコミュニケーション (IPC) を使用するシステム内で通信できます。これで、ネットワーク上で通信する必要がなくなりセキュリティが向上します。
-
C APIの更新 — これによりプログラマーが LDAP ディレクトリサーバーに接続して使用する方法が向上します。
-
LDIFv1 サポート — LDAP Data Interchange Format (LDIF) バージョン 1 に対して、完全に準拠しています。
-
機能拡張されたスタンドアロンLDAPサーバー — アップデートされたアクセス制御システム、スレッドプーリング、より優れたツール、その他の機能拡張が含まれています。
LDAP に関する論議には、 LDAP 特有の用語群の基本的な理解を必要とします：
-
エントリ — エントリとは、 LDAP ディレクトリ内でのユニット1つのことです。各エントリはその固有の Distinguished Name(区別名) (DN) で識別されます。
-
属性 — 属性とは、エントリと直接関連した情報です。例えば、ある組織は LDAP エントリとして表示出来ます。組織と関連した属性には、 fax 番号、その住所、などがあります。 LDAP ディレクトリでは、人もエントリとして表示できます。人の一般的な属性には、その人の電話番号と電子メールアドレスなどが含まれます。
属性の幾つかは必須で、その他の属性はオプションになります。それぞれのエントリに対して、 オブジェクトクラス の定義は、どの属性が必須かを設定します。オブジェクトクラスの定義は、
/etc/openldap/schema/ディレクトリ内にある各種のスキーマファイルで確認できます。詳細は 項13.5. 「/etc/openldap/schema/ディレクトリ」 を参照してください。属性及びその該当値のアサーションも Relative Distinguished Name (RDN) と呼ばれます。 RDN はエントリ内でのみ固有であるのに対して、 DN は全体的に固有となります。
-
LDIF — LDAP Data Interchange Format (LDIF) は、 LDAP エントリの ASCII テキスト表示です。 LDAP サーバーへインポートするデータ用のファイルは LDIF 形式でなければなりません。 LDIF エントリは以下の例のようになります：
[<
id>] dn: <distinguished name> <attrtype>: <attrvalue> <attrtype>: <attrvalue> <attrtype>: <attrvalue>各エントリは必要な数の
<ペアを含むことができます。空白の行はエントリの終了を示します。attrtype>: <attrvalue>注意
この情報を使用するには
<とattrtype><のペア全てが、対応するスキーマで定義されなければ なりません。attrvalue><と、>に囲まれている全ての値は変数であるため、新規の LDAP エントリが作成されるたびに設定できます。しかし、この規則は<には適用されません。id><は、エントリの編集に使用するアプリケーションによって決定される番号です。id>
OpenLDAP ライブラリとツールのセットは以下のパッケージに含まれています:
-
openldap— OpenLDAP サーバーとクライアントアプリケーションを実行するのに必要なライブラリを含んでいます。 -
openldap-clients— LDAP サーバー上でディレクトリの表示と変更の為のコマンドラインツールを含んでいます。 -
openldap-servers— LDAP サーバーの設定と実行に必要なサーバーと他のユーティリティを含んでいます。
2種類のサーバーが openldap-servers パッケージの中に含まれています： スタンドアロン LDAP デーモン (/usr/sbin/slapd) と スタンドアロン LDAP 更新複製デーモン (/usr/sbin/slurpd) です。
slapd デーモンはスタンドアロン LDAP サーバーであり、 slurpd デーモンはネットワーク上の1つの LDAP サーバーから別の LDAP サーバーへの変更を同期するのに使用されます。 slurpd デーモンは複数の LDAP サーバーを利用している時にのみに使用されます。
管理の作業をするには、 openldap-servers パッケージが /usr/sbin/ ディレクトリへ、以下のユーティリティをインストールする必要があります：
-
slapadd— LDIF ファイルから LDAP ディレクトリへエントリを追加します。例えば、/usr/sbin/slapadd -lコマンドは新規のエントリを含む LDIF ファイル、ldif-inputldif-input重要
root ユーザーのみ
/usr/sbin/slapaddを使用できます。しかし、ディレクトリサーバーはldapユーザーとして動作します。そのため、ディレクトリサーバーはslapaddで作成されたファイルはどれも変更できません。この問題を修正するには、slapaddを使用した後に、次のコマンドを入力します。chown -R ldap /var/lib/ldap
-
slapcat— デフォルトフォーマット、 Sleepycat Software の Berkeley DB システム内の LDAP ディレクトリからエントリを取り出して、 LDIF ファイルの中に保存します。例えば、/usr/sbin/slapcat -lコマンドは、 LDAP ディレクトリからのエントリを含むldif-outputldif-output -
slapindex— 現在のコンテンツに基づいてslapdディレクトリの索引を再構成します。このツールは、/etc/openldap/slapd.conf内のインデックスオプションが変更されるたびに実行する必要があります。 -
slappasswd—ldapmodifyで使う暗号化されたユーザーパスワードの値、あるいはslapdの設定ファイル/etc/openldap/slapd.confのrootpw値を生成します。パスワードを作成するには、/usr/sbin/slappasswdコマンドを実行します。
警告
slapadd、 slapcat、又は slapindex を使う前に、 /sbin/service slapd stop を発行して必ず slapd を停止させてください。そうしないと LDAP ディレクトリの一貫性を失う可能性があります。
これらのユーティリティの使用方法の詳細については、それぞれの man ページを参照して下さい。
openldap-clients パッケージは、 LDAP ディレクトリのエントリを追加、変更、削除するのに使う /usr/bin/ の中へツールをインストールします。これらのツールには以下の項目が含まれます：
-
ldapadd— ファイル又は標準入力からの入力を受け付け、 LDAP ディレクトリにエントリを追加します。ldapaddは実際にはldapmodify -aへのハードリンクです。 -
ldapdelete— シェルプロンプトかファイルからのユーザー入力を受領し LDAP ディレクトリからエントリを削除します。 -
ldapmodify— ファイル又は標準入力からの入力を受け付け、 LDAP ディレクトリのエントリを変更します。 -
ldappasswd— LDAP ユーザーのパスワードを設定します。 -
ldapsearch— shell プロンプトを使用して LDAP ディレクトリ内のエントリを検索します。 -
ldapcompare— LDAP サーバーへの接続を開き、バインドして特定パラメータを使い比較を行います。 -
ldapwhoami— LDAP サーバーへの接続を開き、バインドしてwhoamiオペレーションを行います。 -
ldapmodrdn— LDAP サーバーへの接続を開き、バインドしてエントリの RDN を修正します。
ldapsearch を例外として、これらのユーティリティは LDAP ディレクトリで変更をしたいそれぞれのエントリ用のコマンドをタイプするのでなく、変更したいファイルを参照するのでより簡単に使用できます。このようなファイルの形式については、それぞれのユーティリティの man ページに概要があります。
OpenLDAP パッケージに加えて、 Red Hat Enterprise Linux には Linux 及び他の UNIX 環境に統合するために LDAP の機能を強化する nss_ldap と呼ばれるパッケージが含まれています。
nss_ldap パッケージは以下のモジュールを提供します (<version> は使用中の libnss_ldap のバージョン)。
-
/lib/libnss_ldap-<version>.so -
/lib/security/pam_ldap.so
nss_ldap パッケージは、 Itanium 又は AMD64 アーキテクチャ用に以下のモジュールを提供します：
-
/lib64/libnss_ldap-<version>.so -
/lib64/security/pam_ldap.so
libnss_ldap- モジュールにより、アプリケーションは <version>.soglibc の NSS ( Nameservice Switch) インターフェースを経由した LDAP ディレクトリを使用しユーザー、グループ、ホスト、そしてその他の情報を検索できるようになります。 NSS により、アプリケーションは NIS ネームサービスと単層の認証ファイルを併用して LDAP で認証できるようになります。
pam_ldap モジュールの使用で、 PAM-認識のアプリケーションが LDAP ディレクトリ内に保存してある情報を使用してユーザーを認証することができます。 PAM-認識のアプリケーションには、コンソールログイン、 POP と IMAP のメールサーバー、及び Samba が含まれます。ネットワーク上で LDAP サーバーを起用することにより、これらのアプリケーションのすべてが、同じユーザー ID とパスワードの組合せを使用して認証できるようになり、管理が大幅に簡略化します。
Red Hat Enterprise Linux には、 PHP サーバー側のスクリプト言語用の LDAP モジュールを収納したパッケージが含まれています。
php-ldap パッケージは /usr/lib/php4/ldap.so モジュールで PHP4 HTML 組み込みスクリプト言語に LDAP サポートを追加します。このモジュールにより PHP4 スクリプトは LDAP ディレクトリに保存されている情報にアクセスできるようになります。
Red Hat Enterprise Linux には Apache HTTP Server 用の mod_authz_ldap モジュールが同梱されています。このモジュールはサブジェクト及びクライアント SSL 証明書の発行元の識別名に短縮形式を使用して LDAP ディレクトリ内のユーザーの識別名を判別します。また、ユーザーの LDAP ディレクトリエントリの属性を基にそのユーザーを許可する、アセットのユーザー及びグループ特権を基にアセットへのアクセスを判別する、またパスワードが期限切れのユーザーのアクセスを拒否するなどが可能です。 mod_authz_ldap モジュールを使用する時は mod_ssl モジュールが必要になります。
重要
mod_authz_ldap モジュールは暗号化パスワードハッシュを使用して LDAP ディレクトリに対するユーザーの認証を行ないません。この機能は実験的な mod_auth_ldap モジュールにより提供され、 Red Hat Enterprise Linuxには含まれていません。このモジュールの状況詳細などに関しては、 Apache Software Foundation のウェブサイト、 http://www.apache.org/ を参照してください。
ディレクトリの作成及び変更に対応するグラフィカルな LDAP クライアントがありますが、 Red Hat Enterprise Linux では 配付されていません。 このようなアプリケーションの 1 つが LDAP Browser/Editor です。 — Java ベースのツールでオンラインの http://www.iit.edu/~gawojar/ldap で入手できます。
その他の LDAP クライアントは読み込み専用でディレクトリにアクセスし、組織全体の情報を参照するのに使用しますが変更はしません。このようなアプリケーションの例としては、 Sendmail、 Mozilla、 Gnome Meeting、 Evolution などがあります。
OpenLDAP 設定ファイルは /etc/openldap/ ディレクトリの中にインストールされています。以下に最も重要なディレクトリとファイルの簡単な一覧を示します：
-
/etc/openldap/ldap.conf— これは、ldapsearch、ldapadd、 Sendmail、 Evolution、 Gnome Meeting などの OpenLDAP ライブラリを使用する、すべての クライアント アプリケーションのための設定ファイルです。 -
/etc/openldap/slapd.conf—slapdデーモンの設定ファイルです。詳細は 項13.6.1. 「/etc/openldap/slapd.confの編集」 を参照してください。 -
/etc/openldap/schema/ディレクトリ — このサブディレクトリには、slapdデーモンによって使用されるスキーマが含まれます。詳細は 項13.5. 「/etc/openldap/schema/ディレクトリ」 を参照してください。
注記
nss_ldap パッケージがインストールされている場合、 /etc/ldap.conf と言う名前のファイルが作成されます。このファイルは nss_ldap パッケージが供給する PAM 及び NSS モジュールによって使用されます。詳細については 項13.7. 「システムが OpenLDAP を使用して認証を実行するように設定する」 を参照してください。
/etc/openldap/schema/ ディレクトリには LDAP 定義が収納されています。以前は slapd.at.conf ファイルと slapd.oc.conf ファイルに収納されていました。 /etc/openldap/schema/redhat/ ディレクトリには、 Red Hat Enterprise Linux 用に Red Hat が配布するカスタマイズスキーマが収納されています。
すべての 属性構文定義 と オブジェクトクラス定義 は現在、別のスキーマファイルに配置されています。各種スキーマファイルは、 include の行を使用して /etc/openldap/slapd.conf を参照します。以下のようになります：
include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/rfc822-MailMember.schema include /etc/openldap/schema/redhat/autofs.schema
注意
OpenLDAP によりインストールされたスキーマファイル内で定義されている、スキーマの項目を変更しないでください。
OpenLDAP が使用するスキーマを、デフォルトのスキーマファイルを参考にして追加の属性の種類やオブジェクトクラスをサポートするように拡張することができます。これを行なうには、 /etc/openldap/schema ディレクトリ内に local.schema ファイルを作成します。その後デフォルトのスキーマの include 行の下に次の行を追加して、この新しいスキーマが slapd.conf において参照されるようにします。
include /etc/openldap/schema/local.schema
次に、 local.schema ファイルの内部で属性タイプとオブジェクトクラスを定義します。多くの組織では、デフォルトでインストールされているスキーマファイルからの既存の属性タイプを使用し、新規のオブジェクトクラスを local.schema ファイルに追加しています。
特定の専門的な要求に合うようにスキーマを拡張すると、かなり複雑になりこの章の説明範囲を越えてしまいます。詳細情報については http://www.openldap.org/doc/admin/schema.html で御覧ください。
このセクションは、 OpenLDAP ディレクトリのインストールと設定についての簡潔な概要を提供します。詳細については以下の URL を参照して下さい：
-
http://www.openldap.org/doc/admin/quickstart.html — OpenLDAP についての web サイト。 Quick-Start Guide
-
http://www.tldp.org/HOWTO/LDAP-HOWTO/index.html — Linux Documentation Project による LDAP Linux HOWTO です。
LDAP サーバー構築の基本的なステップは次の通りです：
-
openldap、openldap-servers、及びopenldap-clientsRPM をインストールします。 -
/etc/openldap/slapd.confファイルを編集して、 LDAP ドメインとサーバーを指定します。詳細については 項13.6.1. 「/etc/openldap/slapd.confの編集」 を参照してください。 -
以下のコマンドを使用して
slapdをスタートします：/sbin/service ldap start
LDAP を設定したら、
chkconfig、/usr/sbin/ntsysv、または サービス設定ツール を使用して LDAP がブート時に起動するよう設定します。サービスの設定については、 章 5. サービスへのアクセスの制御 を参照してください。 -
ldapaddで、 LDAP ディレクトリにエントリを追加します。 -
ldapsearchを使用してslapdが情報に正しくアクセスしているか確認します。 -
この時点で、 LDAP ディレクトリは正常に機能しているはずで、 LDAP が有効になったアプリケーションで設定することができます。
slapd LDAP サーバーを使用するには、その設定ファイル、 /etc/openldap/slapd.conf を変更して、正しいドメインとサーバーを指定します。
suffix の行は、 LDAP サーバーが情報を提供するためのドメインに名前を付けるため、以下の行を変更します。
suffix "dc=your-domain,dc=com"
それを完全修飾のドメイン名が表示されるようにします。例えば、
suffix "dc=example,dc=com"
rootdn エントリは、 LDAP ディレクトリ上の操作に対して管理制限のパラメータが設定されているかアクセス制御で制限のないユーザー用の識別名 (DN) です。 rootdn ユーザーは、 LDAP ディレクトリの root ユーザーとも考えられます。設定ファイルの中で、 rootdn の行をデフォルトの値から次の例のように変更します。
rootdn "cn=root,dc=example,dc=com"
ネットワーク上で LDAP ディレクトリを配置するとき、 rootpw の行を変更します。 — デフォルトの値を暗号化したパスワード文字列に入れ換えます。暗号化したパスワード文字列を生成するには、次のコマンドを入力します。
slappasswd
入力が求められたら、パスワードを入力、確認のため再度入力します。プログラムが生成された暗号化パスワードの結果をシェルプロンプトに出力します。
次に、新規に作成された暗号化パスワードを rootpw 行の1つにある /etc/openldap/slapd.conf にコピーし、 # マークを削除します。
終了すると、その行は次と同様な形になります：
rootpw {SSHA}vv2y+i6V6esazrIv70xSSnNAJE18bb2u
警告
/etc/openldap/slapd.conf に指定してある rootpw ディレクティブを含む LDAP パスワードは、 TLS 暗号化を有効にしない限り、ネットワーク上に 暗号化なし で送信されます。
TLS 暗号化を有効にするには、 /etc/openldap/slapd.conf 内のコメントを再確認して、 slapd.conf 用の man ページを参照してください。
セキュリティ強化の為には、 LDAP ディレクトリを充填した後に先頭に # マークを付け、 rootpw ディレクティブをコメントアウト (無効化) します。
ローカルで /usr/sbin/slapadd コマンドラインツールを使用している時は、 LDAP ディレクトリを充填するのに、 rootpw ディレクティブを使う必要はありません。
重要
root ユーザーのみが /usr/sbin/slapadd を使用できます。しかし、ディレクトリサーバーは ldap ユーザーとして動作します。そのため、ディレクトリサーバーは slapadd で作成されたファイルはどれも変更できません。この問題を修正するには、 slapadd を使用した後、次のコマンドを入力します:
chown -R ldap /var/lib/ldap
このセクションでは、 OpenLDAP のユーザー認証を設定する方法について簡単に概要を説明します。 OpenLDAP に関して熟達していない限り、本書の説明以外にも詳しいドキュメントが必要となります。詳細については 項13.9. 「その他のリソース」 に記載している参考文献を参照してください。
必要となる LDAP パッケージをインストールします。
最初に、 LDAP サーバーと LDAP クライアントの両方のマシンに該当するパッケージがインストールされていることを確認します。 LDAP サーバーには openldap-servers パッケージが必要です。
LDAP クライアントマシンでは、 openldap、 openldap-clients、 nss_ldap のパッケージをインストールする必要があります。
設定ファイルを編集します。
-
サーバー上で、 LDAP サーバーにある
/etc/openldap/slapd.confファイルを編集して、必ず組織の特質に一致するようにします。slapd.confの編集については 項13.6.1. 「/etc/openldap/slapd.confの編集」 の説明を参照してください。 -
クライアントマシン上では、
/etc/ldap.confと/etc/openldap/ldap.confの両方が組織の適切なサーバーと検索ベースの情報を含んでいる必要があります。これを行なうには、グラフィカルな 認証設定ツール (
system-config-authentication) を実行して、 ユーザー情報 タブで LDAP サポートを有効にする を選択します。また、これらのファイルは手動でも編集することができます。
-
LDAP を使用する為には、クライアントのマシンで、
/etc/nsswitch.confを編集する必要があります。これを行なうには、 認証設定ツール (
system-config-authentication) を実行して、 ユーザー情報 タブで LDAP サポートを有効にする を選択します。手動で
/etc/nsswitch.confを編集する場合、適当な行にldapを追加します。例えば次のようにします：
passwd: files ldap shadow: files ldap group: files ldap
/usr/share/openldap/migration ディレクトリには、認証情報を LDAP フォーマットに移行するための一連のシェルと Perl スクリプトが含まれています
注記
これらのスクリプトを使用するには、システムに Perl をインストールしている必要があります。
最初に、 migrate_common.ph ファイルを修正し、正しいドメインを反映するようにします。デフォルトの DNS ドメインは、そのデフォルトの値から次のように変更してください。
$DEFAULT_MAIL_DOMAIN = "example";
デフォルトのベースも次のように変更する必要があります。
$DEFAULT_BASE = "dc=example,dc=com";
ユーザーデータベースを LDAP 読み込み可能なフォーマットに移行する作業は、同じディレクトリにインストールしてある一連の移行スクリプトに任されます。 表 13.1. 「LDAP 移行スクリプト」 を使用して、ユーザーデータベースの移行に実行するスクリプトを決定してください。
既存のネームサービスに基づいて適切なスクリプトを実行します。
/usr/share/openldap/migration/ ディレクトリ内の README 及び migration-tools.txt ファイルは移行の方法に関する詳細情報を提供します。
| 既存のネームサービス | LDAP は動作しているか | 使用するスクリプト |
|---|---|---|
/etc 単層ファイル
|
はい |
migrate_all_online.sh
|
/etc 単層ファイル
|
いいえ |
migrate_all_offline.sh
|
| NetInfo | はい |
migrate_all_netinfo_online.sh
|
| NetInfo | いいえ |
migrate_all_netinfo_offline.sh
|
| NIS (YP) | はい |
migrate_all_nis_online.sh
|
| NIS (YP) | いいえ |
migrate_all_nis_offline.sh
|
表 13.1. LDAP 移行スクリプト
With Red Hat Enterprise Linux, OpenLDAP uses Sleepycat Software's Berkeley DB system as its on-disk storage format for directories. Earlier versions of OpenLDAP used GNU Database Manager (gdbm). For this reason, before upgrading an LDAP implementation to Red Hat Enterprise Linux 5.2, original LDAP data should first be exported before the upgrade, and then reimported afterwards. This can be achieved by performing the following steps:
-
オペレーティングシステムをアップグレードする前に、
/usr/sbin/slapcat -lコマンドを実行します。これは、 LDAP ディレクトリからのエントリを含むldif-outputldif-output -
オペレーティングシステムをアップグレードします。 LDIF ファイルを含むパーティションを再フォーマットしないように注意してください。
-
/usr/sbin/slapadd -lコマンドを実行して、 LDAP ディレクトリをアップグレードした Berkeley DB 形式に再度インポートします。ldif-output
次のリソースが LDAP に関する追加情報を提供します。システムで LDAP の設定を開始する前に、特に OpenLDAP の Web サイトと LDAP HOWTO を再確認することが推奨されます。
-
/usr/share/docs/openldap-ディレクトリ — 一般的な<versionnumber>/READMEドキュメントとその他の情報が含まれています。 -
LDAP 関連の man ページ — LDAP に関連する各種アプリケーションや設定ファイルの man ページが数多くあります。以下はいくつか重要な man ページの一覧です。
- クライアントアプリケーション
-
-
man ldapadd— LDAP ディレクトリにエントリを追加する方法を説明しています。 -
man ldapdelete— LDAP ディレクトリ内のエントリを削除する方法を説明しています。 -
man ldapmodify— LDAP ディレクトリ内のエントリを変更する方法を説明してます。 -
man ldapsearch— LDAP ディレクトリ内でエントリを検索する方法を説明しています。 -
man ldappasswd— LDAP ユーザーパスワードの設定と変更の方法を説明しています。 -
man ldapcompare—ldapcompareツールの使用法を説明しています。 -
man ldapwhoami—ldapwhoamiツールの使用法を説明しています。 -
man ldapmodrdn— エントリの RDN を修正する方法を説明しています。
-
- サーバーアプリケーション
-
-
man slapd— LDAP サーバー用のコマンドラインオプションを説明しています。 -
man slurpd— LDAP レプリケーションサーバー用のコマンドラインオプションを説明しています。
-
- 管理アプリケーション
-
-
man slapadd—slapdデータベースにエントリを追加するためのコマンドラインオプションを説明しています。 -
man slapcat—slapdデータベースから LDIF ファイルを生成するために使用するコマンドラインオプションを説明しています。 -
man slapindex—slapdデータベースのコンテンツに基づいたインデックスを再生成するために使用するコマンドラインオプションを説明しています。 -
man slappasswd— LDAP ディレクトリ用のユーザーパスワードを生成するために使用するコマンドラインオプションを説明しています。
-
- 設定ファイル
-
-
man ldap.conf— LDAP クライアントの設定ファイル内で使用できる形式とオプションを説明しています。 -
man slapd.conf— LDAP サーバーアプリケーション (slapd及びslurpd) と LDAP 管理ツール (slapadd、slapcat、slapindex) の両方で参照される設定ファイル内で使用できる形式とオプションを説明しています。
-
-
http://www.openldap.org/ — OpenLDAP プロジェクトの本部です。この web サイトには OpenLDAP の設定に関する豊富な情報と将来のバージョン変更についてのロードマップが含まれています。
-
http://www.padl.com/ — 各種の便利な LDAP ツールと共に
nss_ldapとpam_ldapに開発をしている企業です。 -
http://www.kingsmountain.com/ldapRoadmap.shtml—Jeff Hodges' LDAP Road Mapには、 LDAP プロトコルに関するいくつかの便利な FAQ や最新ニュースへのリンクがあります。
-
http://www.ldapman.org/articles/ — ディレクトリツリーの設計やディレクトリ構造のカスタマイズの方法など、 LDAP の優れた入門書となるような記述があります。
ユーザーが Red Hat Enterprise Linux システムにログインするとき、ユーザー名とパスワードの組み合わせが、有効でアクティブなユーザーであることが確認、または 認証 されなければなりません。ときには、ユーザーを確認する情報がローカルシステム上にあったり、リモートシステム上にあるユーザーのデータベースに対する認証に時間がかかることもあります。
認証設定ツール は、 NIS 、 LDAP 、 Hesiod サーバーからユーザー情報取得の設定するためのグラフィカルインターフェースを提供します。このツールはまた、認証プロトコルとしての LDAP 、 Kerberos 、 および SMB の設定を可能にします。
注記
インストール中に、 (あるいは セキュリティレベル設定ツール を使用して) 中または高のセキュリティレベル設定を行なった場合、ファイアウォールは NIS (Network Information Service) や LDAP などの認証を遮断します。
この章は異なる認証タイプについてそれぞれの詳細は説明していません。代わりに、 認証設定ツール を使用して認証を設定する方法を説明しています。
デスクトップから 認証設定ツール のグラフィカルバージョンを起動するには、 System (on the panel) => 認証 => 認証 を選択するか、シェルプロンプト (例えば XTerm か GNOME ターミナル) で、コマンド system-config-authentication を入力してください。
重要
認証プログラムを終了すると直ちにその変更は有効となります。
ユーザー情報 タブには、どのようにユーザーが認証されるかを設定したり、いくつかのオプションがあります。オプションを有効にするには、横にある空のチェックボックスをクリックします。オプションを解除するには、横にあるチェックボックスをクリックしてチェックを消します。 OK をクリックしてプログラムを終了し、変更を適用します。
以下の一覧は各オプションの説明です。
NIS
NIS サポートを有効にする オプションは、ユーザーとパスワードの認証に (NIS クライアントとして) NIS サーバーに接続するシステムを設定します。 NIS の設定... ボタンをクリックして、 NIS ドメインと NIS サーバーを指定します。 NIS サーバーが指定されないと、デーモンがブロードキャストを介して検出を試みます。
このオプションを機能させるには ypbind パッケージをインストールする必要があります。 NIS サポートが有効になると、 portmap サービスと ypbind サービスが開始します。また、ブート時にも有効になり開始します。
LDAP
LDAP サポートを有効にする このオプションは、 LDAP 経由でユーザー情報を取得するようにシステムに指示します。 LDAP の設定... ボタンをクリックして以下を指定します:
-
LDAP 検索ベース DN — リストにある Distinguished Name (DN) を使用してユーザー情報を取得するように指定します。
-
LDAP サーバー — LDAP サーバーの IP アドレスを指定します。
-
TLS を使用して接続を暗合化する — 有効になっているときは、 LDAP サーバーに送信するパスワードの暗合化に Transport Layer Security が使用されます。 CA 証明書をダウンロード オプションでは、有効な CA (Certificate Authority) 証明書 をダウンロードする URL を指定することが可能です。有効な CA 証明書 は PEM (Privacy Enhanced Mail) フォーマットになければなりません。
このオプションを機能させるには openldap-clients パッケージをインストールする必要があります。
Hesiod
Hesiod サポートを有効にする オプションは、リモート Hesiod データベースから情報 (ユーザー情報を含む) を取得するようにシステムを設定します。以下を指定するには、 Hesiod の設定... ボタンをクリックしてください。
-
Hesiod LHS — Hesiod クエリのために使用されるドメインプレフィックスを指定します。
-
Hesiod RHS — デフォルトの Hesiod ドメインを指定します。
このオプションを機能させるには、hesiod パッケージをインストールする必要があります。
Hesiod についての詳細は、コマンド man hesiod を使用して、 man ページを参照してください。 LHS と RHS の詳細については、 hesiod.conf の man ページ (man hesiod.conf) も参照できます。
Winbind
Winbind サポートを有効にする オプションは、 Windows Active Directory や Windows ドメインに接続するようにシステムを設定します。特定のディレクトリやドメインコントローラからのユーザー情報はアクセス可能です。また、サーバー認証オプションも設定できます。以下を指定するには、 Winbind の設定... をクリックしてください:
-
Winbind ドメイン — 接続する Windows Active Directory やドメインコントローラを指定します。
-
セキュリティモデル — クライアントが Samba にどのように返答するかを設定するセキュリティモデルを選択することができます。ドロップダウンリストからは、以下のどれでも選択できます:
-
user — これはデフォルトのモードです。このレベルのセキュリティで、クライアントは有効なユーザー名とパスワードではじめのログインをしなければなりません。このセキュリティモードでは、暗合化されたパスワードも使用されます。
-
server — このモードでは、 Samba は、ユーザー名/パスワードを他の SMB サーバーを通して認証して確認することを試みます (例えば、 Windows NT Server)。もし試みが失敗したら、 user モードが、代わりに有効になります。
-
domain — このモードでは、 Samba は、 Windows NT Server がするようにユーザー名/パスワードを Windows NT のプライマリまたはバックアップドメインコントローラを通して認証して確認することを試みます。
-
ads — このモードは Active Directory Server (ADS) レルムで Samba がドメインメンバーとして機能するように指示します。このモードで操作するには、
krb5-serverがインストールされ、 Kerberos が正しく設定されなければなりません。
-
-
Winbind ADS Realm — ads セキュリティモデルが選択されるとき、 Samba サーバーがドメインメンバーとして機能する ADS レルムを指定することが可能になります。
-
テンプレートシェル — Windows NT ユーザーのユーザー情報を埋めるときは、
winbinddデーモンがここで選択された値を使用し、そのユーザーのためにログインシェルを指定します。
認証 タブでネットワーク認証方法の設定ができます。オプションを有効にするには、横にある空のチェックボックスをクリックします。オプションを解除するには、横にあるチェックボックスをクリックしてチェックを消します。
以下は各オプション設定の説明です:
Kerberos
Kerberos サポートを有効にする オプションを選択すると Kerberos 認証が有効になります。 Kerberos Settings ダイアログを開いて、以下を設定するには、 Kerberos の設定... ボタンをクリックしてください。
-
Realm — Kerberos サーバー用のレルムを設定します。レルムは Kerberos を使用するネットワークで、ひとつ以上の KDC と場合によっては多数のクライアントから構成されます。
-
KDC — Kerberos チケットを発行するサーバーの Key Distribution Center (KDC) を定義します。
-
管理サーバー —
kadmindを実行する管理サーバーを指定します。
Kerberos Settings ダイアログは、 DNS を使用して、ホストからレルムを解決し、レルムのために KDC を特定します。
LDAP
LDAP サポートを有効にする オプションは、認証に LDAP を使用するように標準の PAM が有効になっているアプリケーションに指示します。 LDAP の設定... ボタンは、 ユーザー情報 タブ以下の LDAP の設定... にあるのと同じオプションで LDAP サポートの設定が可能です。これらのオプションについての詳細は、 項14.1. 「ユーザー情報」 を参照してください。
このオプションを機能させるには openldap-clients パッケージをインストールする必要があります。
Smart Card
Smart Card サポートを有効にする オプションは、 Smart Card 認証を有効にします。これにより Smart Card に格納されている証明書と鍵を使用してユーザーがログインできます。より多くのオプションは Smart Card の設定... をクリックしてください。
SMB
SMB サポートを有効にする オプションでは、 PAM が Server Message Block (SMB) サーバーを使用してユーザーを認証するように設定します。 SMB は cross-system の通信で使用される client-server プロトコルを参照します; これはまた、 Windows クライアントにとって Windows サーバーとして見える Samba により使用されるプロトコルでもあります。 SMB の設定... ボタンをクリックして、以下を指定してください:
-
ワークグループ — 使用する SMB ワークグループを指定します。
-
ドメインコントローラ — 使用する SMB ドメインコントローラを指定します。
Winbind
Winbind サポートを有効にする オプションは、システムを Windows Active Directory または Windows ドメインコントローラに接続させるように設定します。特定のディレクトリまたはドメインコントローラからのユーザー情報はアクセス可能です。またサーバー認証オプションは設定可能です。
Winbind の設定... オプションは、 ユーザー情報 タブにある Winbind の情報... ボタンと同一のものです。詳細については、 Winbind (項14.1. 「ユーザー情報」 以下) を参照してください。
以下にリストされているように、このタブには他の設定オプションもあります。
Cache ユーザー情報
このオプションを選択すると、ネームサービスのキャッシュデーモン (nscd) が有効になり、ブート時にスタートする設定になります。
このオプションを機能させるには nscd パッケージをインストールする必要があります。 nscd についての詳細は、コマンド man nscd を使用して、その man ページを参照してください。
シャドウパスワードの使用
このオプションを選択すると、パスワードをシャドウパスワード形式で /etc/passwd ファイルではなく /etc/shadow ファイルに格納します。シャドウパスワードはインストール中にデフォルトで有効になります。システムのセキュリティを増強するためにシャドウパスワードの使用を強くおすすめします。
MD5 Password の使用
このオプションを選択すると MD5 パスワードが有効になります。パスワードの制限が8文字以下から256文字まで広くなります。インストール中にデフォルトで選択され、セキュリティを増強するために MD5 パスワードの使用を強くおすすめします。
ローカルユーザーにはローカルの承認で十分です
このオプションが有効になっているときは、システムは、その /etc/passwd ファイルで保持されているユーザーアカウントのためにネットワークサービス (LDAP や Kerberos 等) からの承認をチェックしません。
ネットワークサービスによる認証システムアカウント
このオプションを有効にすることにより、マシンでシステムアカウント (root を含む) を認証するのにネットワークサービス (LDAP や Kerberos) を許可するようにシステムを設定します。
認証設定ツール はインターフェースなしのコマンドラインツールとしても実行できます。コマンドラインバージョンは設定スクリプトまたは、キックスタートスクリプトで使用できます。 表 14.1. 「コマンドラインのオプション」 に認証オプションの要約があります。
ヒント
これらのオプションは authconfig の man ページにもあります。また、シェルプロンプトで authconfig --help とタイプして見つけることもできます。
| オプション | 説明 |
|---|---|
--enableshadow
|
シャドウパスワードを有効にする |
--disableshadow
|
シャドウパスワードを解除する |
--enablemd5
|
MD5 パスワードを有効にする |
--disablemd5
|
MD5 パスワードを解除する |
--enablenis
|
NIS を有効にする |
--disablenis
|
NIS を解除する |
--nisdomain=
|
NIS ドメインを指定する |
--nisserver=
|
NIS サーバーを指定する |
--enableldap
|
ユーザー情報の LDAP を有効にする |
--disableldap
|
ユーザー情報の LDAP を解除する |
--enableldaptls
|
LDAP で TLS の使用を有効にする |
--disableldaptls
|
LDAP で TLS の使用を解除する |
--enableldapauth
|
認証の LDAP を有効にする |
--disableldapauth
|
認証の LDAP を解除する |
--ldapserver=
|
LDAP サーバーを指定する |
--ldapbasedn=
|
LDAP 基本 DN を指定する |
--enablekrb5
|
Kerberos を有効にする |
--disablekrb5
|
Kerberos を解除する |
--krb5kdc=
|
Kerberos の KDC を指定する |
--krb5adminserver=
|
Kerberos の管理サーバーを指定する |
--krb5realm=
|
Kerberos の realm を指定する |
--enablekrb5kdcdns
|
Kerberos KDC の検索に DNS の使用を有効にする |
--disablekrb5kdcdns
|
Kerberos KDC の検索に DNS の使用を無効にする |
--enablekrb5realmdns
|
Kerberos realm の検索に DNS の使用を有効にする |
--disablekrb5realmdns
|
Kerberos realm の検索に DNS の使用を無効にする |
--enablesmbauth
|
SMB を有効にする |
--disablesmbauth
|
SMB を解除する |
--smbworkgroup=
|
SMB のワークグループを指定する |
--smbservers=
|
SMB のサーバーを指定する |
--enablewinbind
|
デフォルトでユーザー情報に対する winbind を有効にする |
--disablewinbind
|
デフォルトでユーザー情報に対する winbind を無効にする |
--enablewinbindauth
|
デフォルトで認証に対する winbindauth を有効にする |
--disablewinbindauth
|
デフォルトで認証に対する winbindauth を無効にする |
--smbsecurity=
|
Samba 及び winbind に使用するセキュリティモード |
--smbrealm=
|
security=ads を指定する際の Samba 及び winbind のデフォルト realm
|
--smbidmapuid=
|
winbind がドメインまたは ADS ユーザーに割り当てる UID の範囲 |
--smbidmapgid=
|
winbind がドメインまたは ADS ユーザーに割り当てる GID の範囲 |
--winbindseparator=
|
winbindusedefaultdomain が有効になっていない場合、 winbind ユーザー名のドメインとユーザー部分を区切るために使用する文字
|
--winbindtemplatehomedir=
|
winbind ユーザーがホームとするディレクトリ |
--winbindtemplateprimarygroup=
|
winbind ユーザーが最初のグループとするグループ |
--winbindtemplateshell=
|
winbind ユーザーがデフォルトのログインシェルとするシェル |
--enablewinbindusedefaultdomain
|
ユーザー名にドメインのないユーザーはドメインユーザーであると winbind に仮定させる |
--disablewinbindusedefaultdomain
|
ユーザー名にドメインのないユーザーはドメインユーザーではないと winbind に仮定させる |
--winbindjoin=
|
winbind ドメインまたは ADS realm をこの administrator として今すぐに参加させる |
--enablewins
|
ホスト名の解決に WINS を有効にする |
--disablewins
|
ホスト名の解決に WINS を無効にする |
--enablehesiod
|
Hesiod を有効にする |
--disablehesiod
|
Hesiod を解除する |
--hesiodlhs=
|
Hesiod LHS を指定する |
--hesiodrhs=
|
Hesiod RHS を指定する |
--enablecache
|
nscd を有効にする
|
--disablecache
|
nscd を解除する
|
--nostart
|
たとえ設定されても、 portmap や、 ypbind や、 nscd のサービスをスタートあるいは停止しないで下さい
|
--kickstart
|
ユーザーインターフェースを表示しない |
--probe
|
ネットワークデフォルトを調査して表示する |
表 14.1. コマンドラインのオプション
システム管理者の仕事の一部として各種タスクを各種タイプのユーザー用にシステム設定し、各種ハードウェアを設定をする仕事があります。このセクションでは、 Red Hat Enterprise Linux システムの設定について説明しています。
目次
- 15. コンソールのアクセス
-
16.
sysconfigディレクトリ -
-
16.1.
/etc/sysconfig/ディレクトリ内のファイル -
-
16.1.1.
/etc/sysconfig/amd -
16.1.2.
/etc/sysconfig/apmd -
16.1.3.
/etc/sysconfig/arpwatch -
16.1.4.
/etc/sysconfig/authconfig -
16.1.5.
/etc/sysconfig/autofs -
16.1.6.
/etc/sysconfig/clock -
16.1.7.
/etc/sysconfig/desktop -
16.1.8.
/etc/sysconfig/dhcpd -
16.1.9.
/etc/sysconfig/exim -
16.1.10.
/etc/sysconfig/firstboot -
16.1.11.
/etc/sysconfig/gpm -
16.1.12.
/etc/sysconfig/hwconf -
16.1.13.
/etc/sysconfig/i18n -
16.1.14.
/etc/sysconfig/init -
16.1.15.
/etc/sysconfig/ip6tables-config -
16.1.16.
/etc/sysconfig/iptables-config -
16.1.17.
/etc/sysconfig/irda -
16.1.18.
/etc/sysconfig/keyboard -
16.1.19.
/etc/sysconfig/kudzu -
16.1.20.
/etc/sysconfig/named -
16.1.21.
/etc/sysconfig/network -
16.1.22.
/etc/sysconfig/nfs -
16.1.23.
/etc/sysconfig/ntpd -
16.1.24.
/etc/sysconfig/radvd -
16.1.25.
/etc/sysconfig/samba -
16.1.26.
/etc/sysconfig/selinux -
16.1.27.
/etc/sysconfig/sendmail -
16.1.28.
/etc/sysconfig/spamassassin -
16.1.29.
/etc/sysconfig/squid -
16.1.30.
/etc/sysconfig/system-config-securitylevel -
16.1.31.
/etc/sysconfig/system-config-selinux -
16.1.32.
/etc/sysconfig/system-config-users -
16.1.33.
/etc/sysconfig/system-logviewer -
16.1.34.
/etc/sysconfig/tux -
16.1.35.
/etc/sysconfig/vncservers
-
16.1.1.
-
16.2.
/etc/sysconfig/ディレクトリ内のディレクトリ - 16.3. その他のリソース
-
16.1.
- 17. 日付と時刻の設定
- 18. X Window System
- 19. X Window System の設定
- 20. ユーザーとグループ
- 21. プリンタの設定
- 22. 自動化タスク
- 23. ログファイル
root 以外の一般ユーザーがコンピュータにローカルからログインすると、2種類の特殊な権限が与えられます。
-
ユーザーは、他では実行できないような特定のプログラムを実行できます。
-
ユーザーは、他ではアクセスできないような特定のファイル （通常はディスケット、 CD-ROM などへのアクセスに使用される特別なデバイスファイル） にアクセスできます。
1台のコンピュータ上に複数のコンソールがあり、複数のユーザーが同時にローカルにコンピュータへログインできるため、ユーザーのうちの1人がこのファイルにアクセスする競争に「勝つ」ことになります。最初にコンソールにログインするユーザーがファイルの所有権を取得します。最初のユーザーがログアウトすると、ファイルはログインしている次のユーザーの権利となります。
逆に、コンソールからログインしている すべての ユーザーは、通常 root ユーザーに制限されているタスクを行うプログラムを実行できます。 X が動作している場合、これらの動作はグラフィカルユーザーインターフェースのメニュー項目として取り込むことができます。製品パッケージには、コンソールからアクセスできるプログラムには、 halt 、 poweroff 、 reboot などがあります。
デフォルトでは、 /etc/inittab によって、コンソールで Ctrl-Alt-Del キーの組み合わせを使用した場合にシステムのシャットダウンとリブートを行うよう指定されています。この機能を完全に無効にするには、 /etc/inittab 内にある次の行の先頭にシャープ記号 (#) を付けてコメントアウトします。
ca::ctrlaltdel:/sbin/shutdown -t3 -r now
あるいは、 Ctrl-Alt-Del キーを使用してコンソールからシステムをシャットダウンまたは再起動する権利を特定の非 root ユーザーに限り許可したい場合もあります。次の手順で、この権限を特定のユーザーに制限できます。
-
上に示した
/etc/inittab行に-aオプションを追加すると、次のように表示されます。ca::ctrlaltdel:/sbin/shutdown -a -t3 -r now-aフラグは、/etc/shutdown.allowファイルを探すようにshutdownに指示します。 -
/etcにshutdown.allowというファイルを作ります。shutdown.allowファイルには、 Ctrl-Alt-Del キーを使ってシステムをシャットダウンすることが許されているユーザーのユーザー名を一覧表示します。shutdown.allowファイルのフォーマットは、1行に1ユーザー名ずつの次のような一覧になります。stephen jack sophie
この shutdown.allow ファイルの例では、ユーザー stephen 、 jack 、 sophie が Ctrl-Alt-Del キーを使ってコンソールからシステムをシャットダウンすることが許可されています。このキーコンビネーションを使用したとき、 /etc/shutdown.allow ファイルのユーザー (または root) が仮想コンソールにログインされているかどうかが /etc/inittab の shutdown -a で確認されます。このファイルのユーザーの誰か (または root) がログインしている場合は、システムのシャットダウンが続行されます。誰もログインしていなければ、代わりにシステムコンソールにエラーメッセージが書き込まれます。
shutdown.allow の詳細については、 shutdown の man ページを参照してください。
コンソールプログラムへのユーザーのアクセスを無効にするには、以下のコマンドを root として実行してください。
rm -f /etc/security/console.apps/*
コンソールの安全性がそれ以外の方法で保証されている環境 （BIOSとブートローダーの各パスワードが設定されている環境、 Ctrl-Alt-Delete キーが無効化されている環境、電源スイッチやリセットスイッチが無効化されている環境など） では、デフォルトでコンソールからアクセスできる poweroff 、 halt 、 reboot を、コンソールにいるユーザーからは実行できないようにしたい場合があります。
これらの機能を解除するには、 root として次のコマンドを実行します。
rm -f /etc/security/console.apps/poweroffrm -f /etc/security/console.apps/haltrm -f /etc/security/console.apps/reboot
pam_console.so モジュールは、 /etc/security/console.perms ファイルを使ってシステムコンソールにいるユーザーの権限を決定します。このファイルの構文は非常に柔軟性があります。つまり、これらの指示が適用されないようにファイルを編集できます。ただし、デフォルトファイルには次のような行があります：
<console>=tty[0-9][0-9]* vc/[0-9][0-9]* :[0-9]\.[0-9] :[0-9]
ユーザーがログインすると、特定の名前の付いたターミナル （:0 や mymachine.example.com:1.0 のような名前の X サーバー、または /dev/ttyS0 や /dev/pts/2 のようなデバイス） に接続されます。デフォルトでは、ローカルの仮想コンソールやローカルの X サーバーがローカルとみなされるように定義されますが、隣の /dev/ttyS1 ポート上のシリアルターミナルもローカルとみなしたい場合は、次のようにその行を変更できます。
<console>=tty[0-9][0-9]* vc/[0-9][0-9]* :[0-9]\.[0-9] :[0-9] /dev/ttyS1
個別デバイスクラスや権限定義のデフォルト設定は、 /etc/security/console.perms.d/50-default.perms の中で定義されています。ファイルやデバイスの権限を編集するには、指定のファイルやデバイスのための好みの設定を含めた新しいデフォルトファイルを /etc/security/console.perms.d/ に作成することが推奨されています。新しいデフォルトファイルの名前は、 50-default.perms をオーバーライドするために、 50 よりも大きな数字で始まる必要があります (例えば、 51-default.perms) 。
これを行なうには、 /etc/security/console.perms.d/ に 51-default.perms という新しいファイルを作成します。
touch /etc/security/console.perms.d/51-default.perms
オリジナルのデフォルトの perms ファイル、 50-default.perms を開いてください。はじめのセクションは、以下と似たような行で device classes を定義します。
<floppy>=/dev/fd[0-1]* \ /dev/floppy/* /mnt/floppy* <sound>=/dev/dsp* /dev/audio* /dev/midi* \ /dev/mixer* /dev/sequencer \ /dev/sound/* /dev/beep \ /dev/snd/* <cdrom>=/dev/cdrom* /dev/cdroms/* /dev/cdwriter* /mnt/cdrom*
括弧の中にあるアイテムはデバイスの名前です; 上記の例の <cdrom> は、 CD-ROM ドライブを意味しています。新しいデバイスを追加するには、それをデフォルトの 50-default.perms ファイルで定義しないでください; 代わりに、 51-default.perms で定義してください。例えば、スキャナを定義するには、以下の行を 51-default.perms に加えてください。
<scanner>=/dev/scanner /dev/usb/scanner*
もちろん、デバイスには適当な名前を使わなければなりません。 /dev/scanner が、ハードディスクドライブなどでなく、実際にスキャナーであることを確認する必要があります。
デバイスやファイルを適切に設定したら、次のステップは、その permission definitions を指定することです。 /etc/security/console.perms.d/50-default.perms の2番目のセクションが、以下と似たような行でこれを定義します。
<console> 0660 <floppy> 0660 root.floppy <console> 0600 <sound> 0640 root <console> 0600 <cdrom> 0600 root.disk
スキャナーに権限を定義するには、 51-default.perms にある下記のような行を追加してください。
<console> 0600 <scanner> 0600 root
次に、コンソールからログインすると、 /dev/scanner デバイスの所有権が与えらます。デバイスの権限は 0600 （自分だけが読み取り可能かつ書き込み可能） です。ログアウトすると、デバイスは root のものになり、引き続き、権限は 0600 （今度は root のみが読み取り可能かつ書き込み可能） です。
警告
デフォルトの 50-default.perms ファイルを、 決して 編集しないでください。デバイスの権限が既に定義されている 50-default.perms を編集するには、 51-default.perms のデバイスに必要な権限定義を追加してください。これは 50-default.perms で設定されている、いかなる権限もオーバーライドします。
コンソールユーザーがほかのアプリケーションにアクセスできるようするには、もう少し作業が必要になります。
まず、コンソールアクセスは /sbin/ と /usr/sbin/ のいずれかに存在するアプリケーションに対して のみ 有効なので、実行したいアプリケーションがそこになければいけません。それを確認した後、次のステップを実行します。
-
アプリケーションの名前から
/usr/bin/consolehelperアプリケーションへのリンクを作成します （ここの例としてはfooプログラム）：cd /usr/bin ln -s consolehelper foo -
/etc/security/console.apps/fooファイルを作成します：touch /etc/security/console.apps/foo -
/etc/pam.d/内にfooサービスのための PAM 設定ファイルを作成します。これを行う簡単な方法として、まずhaltサービスの PAM 設定ファイルをコピーし、その後、その動作を変更したい場合はファイルを変更します。cp /etc/pam.d/halt /etc/pam.d/foo
これで、 /usr/bin/ が実行されると、 fooconsolehelper が呼び出されます。このコマンドは、 /usr/sbin/userhelper を利用してユーザーを認証します。ユーザーを認証するために、 /etc/pam.d/ が foo/etc/pam.d/halt のコピーであれば、 consolehelper はユーザーのパスワードを要求し （それ以外は/etc/pam.d/ で指定されている内容を正確に実行します)、次に root 権限で foo/usr/sbin/ を実行します。
foo
PAM 設定ファイルの中で、成功した認証試行を記憶 (キャッシュ) するために pam_timestamp モジュールをアプリケーションが使用するよう設定できます。アプリケーションが起動して正しい認証が行なわれると (root パスワード入力)、タイムスタンプが生成されます。デフォルトでは、成功した認証はキャッシュに5分間記憶されます。この5分間は、 pam_timestamp を使用して同じセッションから実行するように設定されている他のアプリケーションはいずれもそのユーザーに対しては自動的に認証されます。このユーザーは再度 root パスワードを入力する必要はありません。
このモジュールは pam パッケージの中に含まれています。この機能を有効にするには etc/pam.d/ の中の PAM 設定ファイルに以下の行を追加してください。
auth include config-util account include config-util session include config-util
これらの行は、いずれの /etc/pam.d/system-config- 設定ファイルからもコピーできます。これらの行は、 PAM 設定ファイル内のその他の *auth sufficientsession optional 行の 下に 追加することにご注意ください。
pam_timestamp を使用するように設定されているアプリケーションが Applications (the main menu on the panel) から認証されると、 GNOME または KDE デスクトップ環境を使用している場合には、パネルの通知エリアに
アイコンが表示されます。認証が時間切れになると (デフォルトでは5分間) 、アイコンが消えます。
ユーザーは、アイコンをクリックして、認証を無視するオプションを選択することによりキャッシュにある認証を無視できます。
-
16.1.
/etc/sysconfig/ディレクトリ内のファイル -
-
16.1.1.
/etc/sysconfig/amd -
16.1.2.
/etc/sysconfig/apmd -
16.1.3.
/etc/sysconfig/arpwatch -
16.1.4.
/etc/sysconfig/authconfig -
16.1.5.
/etc/sysconfig/autofs -
16.1.6.
/etc/sysconfig/clock -
16.1.7.
/etc/sysconfig/desktop -
16.1.8.
/etc/sysconfig/dhcpd -
16.1.9.
/etc/sysconfig/exim -
16.1.10.
/etc/sysconfig/firstboot -
16.1.11.
/etc/sysconfig/gpm -
16.1.12.
/etc/sysconfig/hwconf -
16.1.13.
/etc/sysconfig/i18n -
16.1.14.
/etc/sysconfig/init -
16.1.15.
/etc/sysconfig/ip6tables-config -
16.1.16.
/etc/sysconfig/iptables-config -
16.1.17.
/etc/sysconfig/irda -
16.1.18.
/etc/sysconfig/keyboard -
16.1.19.
/etc/sysconfig/kudzu -
16.1.20.
/etc/sysconfig/named -
16.1.21.
/etc/sysconfig/network -
16.1.22.
/etc/sysconfig/nfs -
16.1.23.
/etc/sysconfig/ntpd -
16.1.24.
/etc/sysconfig/radvd -
16.1.25.
/etc/sysconfig/samba -
16.1.26.
/etc/sysconfig/selinux -
16.1.27.
/etc/sysconfig/sendmail -
16.1.28.
/etc/sysconfig/spamassassin -
16.1.29.
/etc/sysconfig/squid -
16.1.30.
/etc/sysconfig/system-config-securitylevel -
16.1.31.
/etc/sysconfig/system-config-selinux -
16.1.32.
/etc/sysconfig/system-config-users -
16.1.33.
/etc/sysconfig/system-logviewer -
16.1.34.
/etc/sysconfig/tux -
16.1.35.
/etc/sysconfig/vncservers
-
16.1.1.
-
16.2.
/etc/sysconfig/ディレクトリ内のディレクトリ - 16.3. その他のリソース
/etc/sysconfig/ ディレクトリには、 Red Hat Enterprise Linux のさまざまなシステム設定ファイルが収納されています。
この章では、 /etc/sysconfig/ にあるファイル、その機能、その内容等の概要を説明していきます。これらのファイルの多くは、特別な、あるいは稀な状況でしか使用しない各種のオプションを含んでいるため、本章の情報は完全性を意図しているものではありません。
次のセクションでは、通常 /etc/sysconfig/ ディレクトリで見つかるファイルの説明をしています。ここには記載されていないファイル、及びその他のファイルオプションについては /usr/share/doc/initscripts- ファイルをご覧ください。 (<version-number>/sysconfig.txt<version-number> には、 initscripts パッケージのバージョンを入れます) 。又は、 /etc/rc.d/ ディレクトリにある initscript も役に立ちます。
注記
上記のファイルの内の幾つかが /etc/sysconfig/ ディレクトリにない場合、その関連のプログラムがインストールされていない可能性があります。
/etc/sysconfig/apmd ファイルは、サスペンドやレジューム機能で開始/停止/変更する電源セッティングの構成をする apmd によって使用されます。このファイルはブート時の apmd 機能を設定して、その動作はハードウェアが APM (Advanced Power Management) をサポートするかどうか、又はユーザーがそれを使用するようにシステムを設定しているかどうかによって左右されます。 apm デーモンは Linux カーネル内でパワー管理コードと共に機能するモニタプログラムです。ノート型 PC や他の電源関連の設定でバッテリー低下をユーザーに通知する機能があります。
/etc/sysconfig/arpwatch ファイルは、ブート時に引数を arpwatch デーモンに渡すのに使用されます。 arpwatch デーモンはイーサネットのマックアドレスとその IP アドレスのペアリングのテーブルを保全します。デフォルトでは、このファイルは arpwatch プロセスのオーナーをユーザー pcap に設定して、 root メールキューにメッセージを送信します。このファイルに利用できるパラメータについての詳細は arpwatch の man ページを御覧下さい。
/etc/sysconfig/authconfig ファイルは、ホスト上で使用される認証を設定します。これには以下の行の1つ又は複数が含まれます：
-
USEMD5=、ここで<value><value>-
yes— MD5 は認証に使用されます。 -
no— MD5 は認証に使用されません。
-
-
USEKERBEROS=、ここで<value><value>-
yes— Kerberos は認証に使用されます。 -
no— Kerberos は認証に使用されません。
-
-
USELDAPAUTH=、ここで<value><value>-
yes— LDAP は認証に使用されます。 -
no— LDAP は認証に使用されません。
-
/etc/sysconfig/autofs ファイルはデバイスの自動マウント用のカスタムオプションを定義します。このファイルが自動マウントデーモンの動作を制御して、使用時に自動的にファイルシステムをマウントし、一定の停止時間でアンマウントします。ファイルシステムには、ネットワークファイルシステム、CD-ROM、フロッピー、及びその他のメディアを含むことが可能です。
/etc/sysconfig/autofs ファイルは以下の項目を含む事ができます：
-
LOCALOPTIONS="、ここで<value>"<value>は、マシン特定の自動マウント規則を定義する為の文字列です。デフォルト値は空文字列です ("") 。 -
DAEMONOPTIONS="、ここで<value>"<value>は、デバイスがアンマウントされるまでの時間幅の秒数です。デフォルト値は 60 秒です。 ("--timeout=60") -
UNDERSCORETODOT=、この<value><value>は、ファイル名内のアンダースコアをドットに変換するかどうかを制御するバイナリの値です。例えば、auto_homeからauto.homeへ、又はauto_mntからauto.mntへと変更します。デフォルトの値は 1 (true)です。 -
DISABLE_DIRECT=、ここで、<value><value>とは、ダイレクトマウントサポートを無効にするかどうかを制御するバイナリの値です。 Linux の実装は Sun Microsystems のオートマウンターの動作に従いません。デフォルトの値は 1 (true) で、これにより、 Sun オートマウンターオプション仕様の構文と互換性を持つ事ができます。
/etc/sysconfig/clock ファイルは、システムのハードウェアクロックから読み込んだ値の翻訳を制御します。
その正しい値は次のようになります ：
-
UTC=、ここで<value><value>-
true又はyes— ハードウェアクロックは世界標準時にセットされます。 -
false又はno— ハードウェアクロックはローカル時にセットされます。
-
-
ARC=、この<value><value>-
false又はno— この値は、標準 UNIX エポックが使用中であることを示しています。その他の値は、 Red Hat Enterprise Linux サポートされていないシステムによって使用されています。
-
-
SRM=、ここで<value><value>-
false又はno— この値は、標準 UNIX エポックが使用中であることを示しています。その他の値は、 Red Hat Enterprise Linux サポートされていないシステムによって使用されています。
-
-
ZONE=—<filename>/etc/localtimeのコピー元である/usr/share/zoneinfoの中のタイムゾーンファイル。このファイルには以下のような情報が含まれます。ZONE="アメリカ/ニューヨーク"
ZONEパラメータは 日付と時刻プロパティツール (system-config-date) によって読みこまれますので、手動で編集してもシステムタイムゾーンは変更できません。
以前のリリースの Red Hat Enterprise Linux は以下の値を使用していました (現在無視されています):
-
CLOCKMODE=、ここで<value><value>-
GMT— クロックは世界標準時にセットされています。 (グリニッジ標準時間) -
ARC— ARC コンソールの 42-年のタイムオフセットは有効になっています (Alpha ベースシステムのみ)。
-
/etc/sysconfig/desktop ファイルは、ランレベル 5 で稼働時に新しいユーザーと実行されるディスプレイマネージャ用のデスクトップを指定します。
その正しい値は次のようになります。
-
DESKTOP="、ここで<value>""は以下のいずれかになります:<value>"-
GNOME— GNOME デスクトップ環境を選択します。 -
KDE— KDE デスクトップ環境を選択します。
-
-
DISPLAYMANAGER="、ここで<value>""は以下のいずれかになります:<value>"-
GNOME— GNOME ディスプレイマネージャ を選択します。 -
KDE— KDE ディスプレイマネージャ を選択します。 -
XDM— X ディスプレイマネージャ を選択します。
-
詳細は、 章 18. X Window System を参照してください。
/etc/sysconfig/dhcpd ファイルは、ブート時に引数を dhcpd デーモンに渡す為に使用されます。 dhcpd デーモンは DHCP (Dynamic Host Configuration Protocol) と BOOTP (Internet Bootstrap Protocol) を実装するものです。 DHCP と BOOTP はネットワーク上のマシンにホスト名を割り当てます。このファイルで利用出来るパラメータに関する詳細は dhcpd の man ページを参照してください。
/etc/sysconfig/exim ファイルにより、必要なネットワーク上でメッセージを配送して、1つ又は複数のクライアントにメッセージを送ることができます。このファイルは、 exim が実行されるようにデフォルトの値を設定します。そのデフォルトの値は、デーモンをバックグラウンドで動作するようにして、何かがバックアップされた場合の為に1時間毎にキューをチェックするようになっています。
その値は以下を含みます：
-
DAEMON=、ここで<value><value>-
yes— は、eximは受信メール用にポート 25 をリッスンするように設定する必要があります。yesは Exim の-bdオプションの使用を意味します。 -
no—eximは、受信メール用にポート 25 をリッスンするように設定する必要がありません。
-
-
QUEUE=1heximにそれを-q$QUEUEとして与えます。-qオプションは、/etc/sysconfig/eximが存在していて、QUEUEが空又は、未定義の場合は、eximに与えられません。
最初にシステムがブートする時、 /sbin/init プログラムは etc/rc.d/init.d/firstboot スクリプトをコールし、それが セットアップエージェント を開始させます。このアプリケーションによってユーザーは最新の更新のみならず、追加のアプリケーションやドキュメントをインストールすることが出来ます。
/etc/sysconfig/firstboot ファイルは セットアップエージェント アプリケーションに対しその後の再起動では実行しないよう指示をします。次回システムがブートする時に実行するには、 /etc/sysconfig/firstboot を削除して、 chkconfig --level 5 firstboot on を実行します。
/etc/sysconfig/gpm ファイルは、ブート時に引数を gpm デーモンに渡す為に使用されます。 gpm デーモンは、マウスの加速と中ボタンクリックの貼り付けを可能にするマウスサーバーです。このファイルで利用できるパラメータに関する詳細は gpm の man ページを参照してください。デフォルトでは、 DEVICE ディレクティブを /dev/input/mice にセットします。
/etc/sysconfig/hwconf ファイルは、システム上で kudzu が検出するハードウェアの全て、及び使用されるドライバ、ベンダー ID、デバイス ID 情報などの一覧表示します。 kudzu プログラムはシステム上の新規、及び変更のあったハードウェアを検出し、設定します。 /etc/sysconfig/hwconf ファイルは手動で編集されるべきものではありません。もし編集された場合は、デバイスの一部が突然、追加や削除された項目として表示される可能性があります。
/etc/sysconfig/i18n ファイルは、デフォルトの言語、サポートする言語、及びデフォルトシステムのフォントを設定します。例えば次のような表示になります：
LANG="en_US.UTF-8" SUPPORTED="en_US.UTF-8:en_US:en" SYSFONT="latarcyrheb-sun16"
/etc/sysconfig/init ファイルはブートプロセスでシステムの表示法と機能を制御します。
次のような値を使用することが出来ます：
-
BOOTUP=、ここで<value><value>-
color— 標準のカラーブート表示を意味し、これでデバイスの成功か失敗か、そしてサービスが開始しているかを別々のカラーで表示することになります。 -
verbose— 古いスタイルのディスプレイで、単なる成功/失敗のメッセージのみでなく、より多くの情報を提供します。 -
それ以外は、新しいディスプレイとなります。しかし ANSI-形式はありません。
-
-
RES_COL=、この<value><value> -
MOVE_TO_COL=、この<value><value>echo -enコマンドを経由してRES_COL行の値までカーソルを動かすという意味です。 -
SETCOLOR_SUCCESS=、この<value><value>echo -enコマンドを経由して成功表示のカラーを設定します。デフォルトはグリーンにセットされています。 -
SETCOLOR_FAILURE=、この<value><value>echo -enコマンドを経由して失敗表示のカラーを設定します。デフォルトは黄色にセットされています。 -
SETCOLOR_WARNING=、この<value><value>echo -enコマンドを経由して警告のカラーを設定します。デフォルトは黄色にセットされています。 -
SETCOLOR_NORMAL=、この<value><value>echo -enコマンドを経由して "ノーマル" のカラーをリセットします。 -
LOGLEVEL=、この<value><value>syslogdデーモンは一度開始するとこの設定を上書きします。 -
PROMPT=、ここで<value><value>-
yes— 対話式モードのキーチェックを有効にします。 -
no— 対話式モードのキーチェックを無効にします。
-
/etc/sysconfig/ip6tables-config ファイルは、ブート時や ip6tables サービスが開始された時はいつでも、 IPv6 パケットフィルタを設定する為にカーネルが使用する情報を保存します。
ip6tables ルールの構築方法をよく理解している方以外は、直接このファイルを手動で変更しないでください。また、ルールは /sbin/ip6tables コマンドを使用して手動で作成することもできます。作成が完了したら、次のコマンドを入力して /etc/sysconfig/ip6tables ファイルにルールを追加します。
/sbin/service ip6tables save
このファイルが存在すると、そこに保存されたファイアウォールルールはシステムの再起動やサービスの再スタートの後でも継続されます。
/etc/sysconfig/iptables-config ファイルは、ブート時やサービスが開始された時はいつでも、パケットフィルタサービスを設定する為にカーネルが使用する情報を保存します。
Do not modify this file by hand unless you are familiar with constructing iptables rules. The easiest way to add rules is to use the セキュリティレベル設定ツール (system-config-securitylevel) application to create a firewall. These applications automatically edit this file at the end of the process.
ルールは /sbin/iptables を使用して手動でも作成できます。作成後に、次のコマンドを入力してルールを /etc/sysconfig/iptables ファイルに追加します:
/sbin/service iptables save
このファイルが存在すると、そこに保存されたファイアウォールルールはシステムの再起動やサービスの再スタートの後でも継続されます。
/etc/sysconfig/irda ファイルは、システム上の赤外線デバイスがスタート時に設定される状態を制御します。
次のような値を使用することが出来ます：
-
IRDA=、この<value><value>-
yes—irattachが実行されて、ネットワーク接続を確立しようとする別のノートブックコンピュータなどが赤外線ポートに接続を試みているかどうかを定期的にチェックします。このシステム上で赤外線デバイスが動作するには、この行がyesに設定されている必要があります。 -
no—irattachは実行されず、赤外線デバイスの通信は阻止されます。
-
-
DEVICE=、ここで<value><value>/dev/ttyS2があります。 -
DONGLE=、ここで<value><value>actisys+があります。 -
DISCOVERY=、ここで<value><value>-
yes—irattachを発見モードでスタートします。つまり、他の赤外線デバイスを積極的にチェックするという意味です。マシンが赤外線接続を積極的に探すようにするには、これをオンにする必要があります (ピアは接続を開始しないという意味です)。 -
no—irattachを発見モードでスタートしません。
-
/etc/sysconfig/keyboard ファイルはキーボードの動きを制御します。次の値を使用できます：
-
KEYBOARDTYPE="sun|pc"ここで、sunとは、 Sun キーボードが/dev/kbdに付帯していることと、pcとは、 PS/2 キーボードが PS/2 ポートに付帯しているを意味します。 -
KEYTABLE="、ここで<file>"<file>例えば：
KEYTABLE="us"。/lib/kbd/keymaps/i386の中でキーテーブルがスタートして、そこから別々のキーボード配列に別れる時にこのファイルが使用されます。すべて<file>.kmap.gz/lib/kbd/keymaps/i386の下あり、KEYTABLEセッティングにマッチする最初のファイルが使用されます。
/etc/sysconfig/kuzdu ファイルは、ブート時に kudzu によりシステムハードウェアの安全検出を開始します。安全検出ではシリアルポート検出は無効です。
-
SAFE=、ここで<value><value>-
yes—kuzduは安全検出を実行します。 -
no—kuzduはノーマル検出を実行します。
-
/etc/sysconfig/named ファイルは、ブート時に引数を named デーモンに渡すのに使用されます。 named デーモンは、 BIND (Berkeley Internet Name Domain) バージョン 9 ディストリビューションを実装する DNS (Domain Name System) サーバです。このサーバはネットワーク上の IP アドレスと関連しているホスト名のテーブルを管理します。
現在、次の値だけが使用できます：
-
ROOTDIR=、ここで"</some/where>"</some/where>namedが実行される設定済みの chroot 環境のフルディレクトリのパス(経路)を示します。この chroot 環境が最初に設定される必要があります。詳細を得るにはinfo chrootと入力して、 info 案内を御覧下さい。 -
OPTIONS=、この"<value>"<value>namedman ページにリストされている内、-t以外のオプションです。-tの代わりに、上記のROOTDIRを使用します。
このファイルに利用できるパラメータの詳細情報は、 named の man ページを参照してください。 BIND DNS サーバーを設定する方法についての詳細は 章 6. Berkeley Internet Name Domain (BIND) を参照してください。このファイルはデフォルトでパラメータを含んでいません。
/etc/sysconfig/network ファイルは、目的のネットワーク設定に関する情報を指定するのに使用されます。以下の値が使用できます：
-
NETWORKING=、ここで<value><value>-
yes— ネットワークを設定する必要があります。 -
no— ネットワークを設定する必要がありません。
-
-
HOSTNAME=、ここで<value><value>hostname.expample.comなどの 完全修飾型ドメイン名 (FQDN) である必要があります。しかしこれは必要な名前なら何でも結構です。 -
GATEWAY=、ここで、<value><value> -
GATEWAYDEV=, where<value><value>eth0. Configure this option if you have multiple interfaces on the same subnet, and require one of those interfaces to be the preferred route to the default gateway. -
NISDOMAIN=、ここで<value><value> -
NOZEROCONF=、 ここで<value><value>trueに設定すると zeroconf route は 無効になります。zeroconf route (169.254.0.0) は、デフォルトでシステム起動時に有効になって います。zeroconf に関する詳細情報には、http://www.zeroconf.org/ を参照して下さい。
Warning
Do not use custom initscripts to configure network settings. When performing a post-boot network service restart, custom initscripts configuring network settings that are run outside of the network init script lead to unpredictable results.
NFS requires the portmap, which dynamically assigns ports for RPC services. This causes problems for configuring firewall rules. To overcome this problem, use the /etc/sysconfig/nfs file to control which ports the required RPC services run on.
The /etc/sysconfig/nfs may not exist by default on all systems. If it does not exist, create it and add the following variables (alternatively, if the file exists, un-comment and change the default entries as required):
-
MOUNTD_PORT="x" -
control which TCP and UDP port mountd (rpc.mountd) uses. Replace
xwith an unused port number. -
STATD_PORT="x" -
control which TCP and UDP port status (rpc.statd) uses. Replace
xwith an unused port number. -
LOCKD_TCPPORT="x" -
control which TCP port nlockmgr (rpc.lockd) uses. Replace
xwith an unused port number. -
LOCKD_UDPPORT="x" -
control which UDP port nlockmgr (rpc.lockd) uses. Replace
xwith an unused port number.
If NFS fails to start, check /var/log/messages. Normally, NFS will fail to start if you specify a port number that is already in use. After editing /etc/sysconfig/nfs restart the NFS service by running the service nfs restart command. Run the rpcinfo -p command to confirm the changes.
To configure a firewall to allow NFS:
-
Allow TCP and UDP port 2049 for NFS.
-
Allow TCP and UDP port 111 (portmap/sunrpc).
-
Allow the TCP and UDP port specified with
MOUNTD_PORT="x" -
Allow the TCP and UDP port specified with
STATD_PORT="x" -
Allow the TCP port specified with
LOCKD_TCPPORT="x" -
Allow the UDP port specified with
LOCKD_UDPPORT="x"
/etc/sysconfig/ntpd ファイルは、ブート時に引数を ntpd デーモンへ渡す為に使用されます。 ntpd デーモンはインターネット標準時間サーバーと同期をとる為にシステムクロックを設定して管理します。ネットワーク時間プロトコル (NTP) のバージョン 4 を実装するものです。このファイルに利用できるパラメータについての詳細は Web ブラウザで次のファイルを表示します: /usr/share/doc/ntp- (ここで< version>/ntpd.htm<version> とは ntpd のバージョン番号です)。デフォルトでは、このファイルは ntpd プロセスのオーナーをユーザー ntp に設定します。
/etc/sysconfig/radvd ファイルは、ブート時に引数を radvd デーモンに渡すために使用されます。 radvd デーモンはルーターの要求をリッスンして IP バージョン 6 プロトコル用のルーター広報を送信します。このサービスによって、ネットワーク上のホストはこれらのルーター広報をベースにして動的にそのデフォルトのルーターを変更することが出来ます。このファイルに利用できるパラメータについての詳細は radvd の man ページを参照してください。デフォルトでは、このファイルは radvd プロセスのオーナーをユーザー radvd に設定します。
/etc/sysconfig/samba ファイルは、ブート時に引数を smbd デーモンと nmbd デーモンに渡す為に使用されます。 smbd デーモンはネットワーク上の Windows クライアントとのファイル共有の接続を提供します。 nmbd デーモンは、 IP ネーミングサービス上で NetBIOS を提供します。このファイルに利用できるパラメータに関する詳細は、 smbd の man ページを参照してください。デフォルトでは、このファイルは smbd と nmbd をデーモンモードで実行するように設定します。
/etc/sysconfig/selinux ファイルには、 SELinux 用の基本設定オプションが含まれています。このファイルは、 /etc/selinux/config へのシンボリックリンクです。
/etc/sysconfig/sendmail ファイルにより、必要なネットワーク上でメッセージを配送して、1つ又は複数のクライアントにメッセージを送ることができます。このファイルは、 Sendmail アプリケーションが実行されるようにデフォルトの値を設定します。そのデフォルトの値は、デーモンをバックグラウンドで動作するようにして、何かがバックアップされた場合、1時間毎にキューをチェックします。
値は次を含みます:
-
DAEMON=、ここで<value><value>-
yes— Sendmail は、受信メール用にポート 25 をリッスンするように設定する必要があります。yesは Sendmail の-bdオプションの使用を意味します。 -
no— Sendmail は、受信メール用にポート 25 をリッスンするように設定する必要がありません。
-
-
QUEUE=1hSendmail にそれを-q$QUEUEとして与えます。-qオプションは、/etc/sysconfig/sendmailが存在していて、QUEUEが空又は、未定義の場合は、 Sendmail に与えられません。
/etc/sysconfig/spamassassin ファイルは、ブート時に引数を spamd デーモン (Spamassassin のデーモン版) に渡す為に使用されます。 Spamassassin は、電子メールスパム用のフィルタアプリケーションです。利用できるオプションの一覧は、 spamd の man ページを参照してください。デフォルトでは、 spamd をデーモンモードで実行し、ユーザーの個人設定をし、そして白紙リスト (許可されたバルク配送元) を自動作成します。
Spamassassin に関する詳細は、 項12.5.2.6. 「スパムフィルタ」 を参照してください。
/etc/sysconfig/squid ファイルは、ブート時に引数を squid デーモンに渡すのに使用されます。 squid デーモンは、 Web クライアントアプリケーション用のプロキシキャッシングサーバです。 squid プロキシサーバに関する詳細情報は、 Web ブラウザを使用して /usr/share/doc/squid- ディレクトリを開いて御覧下さい (<version>/<version> の部分はシステムにインストールされている squid のバージョン番号です)。デフォルトでは、このファイルは squid をデーモンモードでスタートする様に設定して、停止するまでの時間の値をセットします。
/etc/sysconfig/system-config-users ファイルは、グラフィカルアプリケーションの ユーザーマネージャ 用の設定ファイルです。このファイルは、 root 、 daemon 、 lp などのシステムユーザーをフィルターにかける為に使用されます。このファイルは、 ユーザーマネージャ アプリケーションで 個人設定 => システムユーザとグループをフィルタ のプルダウンメニューで編集されますので、手動で編集するものではありません。このアプリケーションの使い方についての詳細は、 項20.1. 「ユーザーとグループの管理」 を参照して下さい。
/etc/sysconfig/system-logviewer ファイルはグラフィカルで、対話式のログ表示アプリケーション ログビューア 用の設定ファイルです。このファイルは、 ログビューア 内の 編集 => 個人設定 プルダウンメニューにより編集されるため、手動で編集しないで下さい。このアプリケーションの使い方についての詳細は 章 23. ログファイル を参照してください。
/etc/sysconfig/tux ファイルは、 Red Hat Content Accelerator (旧名：TUX) と言う、カーネルベースの Web サーバ用の設定ファイルです。 Red Hat Content Accelerator の設定に関する詳細は、 Web ブラウザを使用して、 /usr/share/doc/tux- ファイルを開いてその内容を確認して下さい (<version>/tux/index.html<version> は、システムにインストールされている TUX の実際のバージョン番号で入れ換えます) 。このファイルで利用出来るパラメータは /usr/share/doc/tux- に一覧表示してあります。
<version>/tux/parameters.html
/etc/sysconfig/vncservers ファイルは VNC (Virtual Network Computing) サーバがスタートする方法を設定します。
VNC を使用するとユーザーは実行中のマシン上の環境だけでなく、各種アーキテクチャの別のネットワークを通したマシンのデスクトップ環境もリモート表示できます。
以下のような項目が該当します：
-
VNCSERVERS=、この<value><value>"1:fred"のように設定します。ユーザー fred は、リモートリモート VNC サーバに接続する前に、vncpasswdを使用して VNC パスワードを設定しておく必要があります。
通常、 /etc/sysconfig/ には、以下のようなディレクトリがあります。
-
apm-scripts/ -
このディレクトリには、 APM サスペンド/復帰スクリプトが含まれています。このファイルは直接編集しないで下さい。カスタマイズが必要な場合は、
/etc/sysconfig/apm-scripts/apmcontinueと言うファイルを作成すると、スクリプトの最後にコールされます。また、/etc/sysconfig/apmdを編集することでもこのスクリプトを制御できます。 -
cbq/ -
このディレクトリには、ネットワークインターフェイスのバンド幅管理の為の クラスベースのキュー (Class Based Queuing) を実践する為に必要な設定ファイルが含まれています。 CBQ は、ユーザーのトラフィックを IP アドレス、プロトコル、及びアプリケーションタイプの組み合わせを基にしたクラス階級へ分割します。
-
networking/ -
このディレクトリは ネットワーク管理ツール (
system-config-network) によって使用されており、その内容は手動で編集しないで下さい。 ネットワーク管理ツール を使用したネットワークインターフェイスの設定に関する情報は、 章 4. ネットワーク設定 を参照して下さい。 -
network-scripts/ -
このディレクトリには次のネットワーク関連の設定ファイルが含まれています：
-
eth0イーサネットインターフェイス用のifcfg-eth0などのようなそれぞれの設定されたネットワークインターフェイスの為のネットワーク設定ファイル。 -
ifupとifdownのようなネットワークインターフェイスを起動 (up) したり停止 (down) したりするのに使用されるスクリプト。 -
ifup-isdnやifdown-isdnのように ISDN インターフェイスを起動したり停止したりする為に使用するスクリプト。 -
直接編集すべきではない各種共有のネットワーク機能スクリプト。
network-scriptsディレクトリに関する詳細は、 章 3. ネットワークインターフェース を参照してください。 -
-
rhn/ -
このディレクトリには、 Red Hat Network の設定ファイルと GPG キーが含まれています。このディレクトリ内のファイルは手動で編集しないで下さい。 Red Hat Network に関する詳細は、以下の URL で Red Hat Network の web サイトを御覧下さい。 https://rhn.redhat.com/.
日付と時刻プロパティツール で、ユーザーは、システムの日付と時刻の変更、システムで使用するタイムゾーンの設定、及びタイムサーバーとシステムクロックを同期するためのネットワークタイムプロトコル (Network Time Protool=NTP) の設定をすることができます。
このツールを使用するには、 X Window システムを実行していて、 root 権限を持っている必要があります。このアプリケーションは次の三つの方法で開始できます:
-
デスクトップから Applications (the main menu on the panel) => システム設定 => 日付と時間 へと進みます。
-
デスクトップからツールバー上の時間を右クリックして、 日付と時刻の調整 を選択します。
-
コマンド
system-config-dateか、system-config-timeか、又はdateconfigをプロンプトで入力します (例えば、 XTerm 又は GNOME ターミナルを使用)。
図 17.1. 「時刻と日付のプロパティ」 で示すように、最初に現れるタブ付きのウィンドウでは、システムの日付と時刻の設定をします。
日付変更をするには、「月」の左右矢印を使って月を変更し、「年」の左右の矢印を使って年を変更し、週の中の日付をクリックすると日付を変更できます。
時刻の変更は、 時刻 セクションの 時、 分、 秒 のとなりにあるそれぞれの上下矢印を使います。
OK ボタンをクリックすることによって、日付と時刻、 NTP デーモンの設定、タイムゾーンの設定などに加えられたすべての変更が適用され、プログラムが終了します。
図 17.2. 「NTP のプロパティ」 で示すように、二つ目のタブ付きのウィンドウでは、 NTP の設定をします。
ネットワークタイムプロトコル (Network Time Protocol＝NTP) デーモンは、 遠隔タイムサーバーまたはタイムソースとシステムクロックを同期します。このアプリケーションを使用すると NTP デーモンによりご使用のシステムクロックを遠隔サーバーと同期するよう設定できます。この機能を有効にするには、 ネットワークタイムプロトコール (ntp) を有効にする を選択します。これで、 NTP サーバー リストと他のオプションが有効になります。事前設定されているサーバーのひとつを選び、 編集 をクリックして事前設定サーバーを編集したり、 追加 をクリックして新しいサーバー名を追加することができます。システムは、 OK をクリックするまで NTP サーバーとの同期を開始しません。 OK をクリックすると、設定が保存され NTP デーモンが起動します (すでに実行している場合は再起動する)。
OK ボタンをクリックすることによって、日付と時刻、 NTP デーモンの設定、タイムゾーンの設定などに加えられたすべての変更が適用され、プログラムが終了します。
図 17.3. 「タイムゾーンのプロパティ」 で示すように、三つめのタブ付きのウィンドウでは、システムのタイムゾーンを設定をします。
システムのタイムゾーンを設定するには、 タイムゾーン タブをクリックします。タイムゾーンは、インテラクティブマップを使用しても、マップの下にある一覧から目的のタイムゾーンを選択しても変更できます。マップを使って変更するには、目的のタイムゾーンを代表する地域をクリックします。赤の X が現れ、マップの下にある一覧内のタイムゾーン選択が変わりますので、その中からタイムゾーンの都市を選択します。
別の方法としては、マップ下のリストを使用することもできます。マップが地域に都市の選択選択を可能にするのと同様に、タイムゾーンリストでも指定大陸の中でグループ化された国と都市が表示されて、タイムゾーンがツリーリストで出ます。ここには、科学調査コミュニティの需要に応じて地図上区別のないゾーンも追加されています。
OK ボタンをクリックすると、変更を適用し、プログラムを終了します。
システムクロックが UTC を使用するように設定されている場合は、 システムクロックで UTC を使用 オプションを選択します。 UTC とは、 Universal Time, Coordinated の略で、 Greenwich mean time (GMT) とも呼ばれています。その他のタイムゾーンは UTC 時間から加算/減算して決定されます。
Red Hat Enterprise Linuxの心臓部と言えるのがカーネルであり、多くのユーザーにとっては、オペレーティングシステムの顔となるのが X Window System または X とも呼ばれるグラフィカル環境です。
1984 年の X Window System リリースより以前のウィンドウ環境も含めて、 UNIX の世界では各種のウィンドウ環境が存在してきました。それでもなお、 X は Red Hat Enterprise Linux を含めてほとんどの UNIX ライクなオペレーティングシステムで長年デフォルトのグラフィカル環境となってきています。
Red Hat Enterprise Linux のグラフィカル環境は、 X Window System 及び関連テクノロジーの開発と方針の管理を行うために設立されたオープンソース機関である X.Org Foundation によって供給されています。 X.Org は世界中に散らばる何百人もの開発者によって急速な成長を遂げている大規模なプロジェクトです。各種ハードウェアデバイスとアーキテクチャへの幅広いサポートを特徴とし、様々なオペレーティングシステムやプラットホームで動作することができます。特に、本 Red Hat Enterprise Linux リリースには X Window System の X11R7.1 リリースが含まれています。
X Window System は、クライアント/サーバーアーキテクチャーを使用します。 X サーバー (Xorg バイナリ) は、ネットワーク又はローカルループバックインターフェイスを経由した X クライアント からの接続を監視します。サーバーは、ビデオカード、モニター、キーボード、マウスなどハードウェアとの通信をもちます。 X クライアントアプリケーションは、ユーザースペース内にあり、ユーザーとそのユーザーの要求を X サーバーに渡すための GUI (グラフィカルユーザーインターフェイス) を構成します。
Red Hat Enterprise Linux 5.0.0 では X11R7.1 リリースをベースの X Window System として使用するようになります。特に、ビデオドライバ、 EXA 、及び以前のリリースに対するプラットフォームサポートの機能強化が含まれています。また、本リリースには X サーバー用に複数の自動設定機能が含まれています。
X11R7.1 is the first release to take specific advantage of the modularization of the X Window System. This modularization, which splits X into logically distinct modules, makes it easier for open source developers to contribute code to the system.
重要
Red Hat Enterprise Linux では XFree86™ サーバーパッケージの提供を行わなくなります。システムを Red Hat Enterprise Linux の最新バージョンにアップグレードする前に、 http://hardware.redhat.com/ の Red Hat ハードウェア互換一覧をオンラインで確認してシステムのビデオカードに X11R7.1 リリースとの互換性があることを確認してください。
X11R7.1 リリースでは、すべてのライブラリ、ヘッダ、バイナリは /usr/ 配下に格納されるようになります。 /usr/X11R6 ではありません。 /etc/X11/ ディレクトリには X クライアント及びサーバーのアプリケーション用設定ファイルがあります。これには、 X サーバー自体と xfs フォントサーバー、 X ディスプレイマネージャ、その他ベースのコンポーネントなどの設定ファイルが含まれています。
新しい Fontconfig ベースのフォントアーキテクチャーの設定ファイルは変らず /etc/fonts/fonts.conf にあります。 フォントの設定及び追加についての詳細は、 項18.4. 「フォント」 を参照してください。
X サーバーはさまざまなハードウェア上で高度なタスクを実行するため、動作するハードウェアに関する詳細情報を必要とします。 X サーバーは自動的にこうした情報のいくつかを検出してきます。その他の詳細情報については設定を行う必要があります。
インストールプログラムは、 X11R7.1 リリースパッケージがインストールの選択項目から外されない限り X を自動的にインストールして設定を行います。ただし、 X サーバーが管理するモニター、ビデオカードまたはその他のデバイスに変更がある場合、 X を再設定しなければなりません。特に手作業で検出されないデバイスには、 X 設定ツール (system-config-display) を使用するのが最適でしょう。
Red Hat Enterprise Linux のデフォルトのグラフィカル環境では、 X 設定ツール は System (on the panel) => 管理 => ディスプレイ にあります。
X 設定ツール で行った変更は一旦ログアウトしてから再度ログインし直すと反映されます。
X 設定ツール についての詳細は、 章 19. X Window System の設定 を参照してください。
場合によっては、 X サーバーの再設定には、その設定ファイル /etc/X11/xorg.conf を手作業で編集する必要があるかもしれません。このファイルの構造に関する詳細は 項18.3. 「X サーバー設定ファイル」 を参照してください。
X サーバーが実行されると、 X クライアントアプリケーションはそれに接続して、ユーザー用の GUI を作成します。 Red Hat Enterprise Linux では、ごく基本的な タブウィンドウマネージャ から高度に開発された対話式の GNOME デスクトップ環境まで、ほとんどの Red Hat Enterprise Linux ユーザーにお馴染みの幅広い GUI が利用できます。
後者のより包括的な GUI を構成するには、 X クライアントアプリケーションの 2 つの主要クラスである デスクトップ環境 と ウィンドウマネージャ が X サーバーに接続される必要があります。
デスクトップ環境は、各種の X クライアントを統合して共通のグラフィカルユーザー環境と開発プラットフォームを構築します。
デスクトップ環境は、幾つかの高度な機能を持ち、これにより X クライアントと他の実行中プロセスが次々に交信できるようになり、またその環境で動作するように書き込まれているすべてのアプリケーションがドラッグアンドドロップ操作などの高度なタスクを実行できるようになります。
Red Hat Enterprise Linux は 2 種類のデスクトップ環境を提供しています。
-
GNOME — GTK+ 2 グラフィカルツールキットをベースにした Red Hat Enterprise Linux 用のデフォルトのデスクトップ環境です。
-
KDE — Qt 3 グラフィカルツールキットをベースにした代替用デスクトップ環境です。
GNOME と KDE はいずれもワープロ、表計算、 Web ブラウザなどの高度な作業効率を向上させるアプリケーションを持っており、また GUI の外観をカスタマイズできるツールも提供しています。さらには、 GTK+ 2 と Qt の両方のライブラリが揃っている場合、 KDE アプリケーションを GNOME の中で実行することができ、またその逆も可能になります。
ウィンドウマネージャ は、 X クライアントプログラムであり、デスクトップ環境の一部、または場合によってはスタンドアローンのこともあります。その主要目的はグラフィカルウィンドウの配置、サイズ変更、移動などを制御することです。ウィンドウマネージャは、タイトルバー、ウィンドウの焦点調節、ユーザー設定のキーやマウスボタンの連携なども制御します。
4 種類のウィンドウマネージャが Red Hat Enterprise Linux に収納されています。
-
kwin -
KWin ウィンドウマネージャは KDE のデフォルトウィンドウマネージャです。カスタムのテーマをサポートしている効率的なウィンドウマネージャです。
-
metacity -
Metacity ウィンドウマネージャは、 GNOME のデフォルトウィンドウマネージャです。こちらもカスタムテーマをサポートするシンプルで効率的なウィンドウマネージャです。このウィンドウマネージャを実行するには、
metacityパッケージをインストールする必要があります。 -
mwm -
Motif ウィンドウマネージャ (
mwm) は、基本的なスタンドアローンのウィンドウマネージャです。単独で機能するように設計されているため、 GNOME や KDE と一緒に使用するべきではありません。このウィンドウマネージャを実行するには、openmotifパッケージをインストールする必要があります。 -
twm -
すべてのウィンドウマネージャの中で最も基本的なツールセット、必要最小限の機能を提供する タブウィンドウマネージャ は、単独または別のデスクトップ環境との併用でも使用できます。 X11R7.1 リリースの一部としてインストールされています。
前述のウィンドウマネージャいずれを実行する場合も、まずランレベル 3 で起動する必要があります。これについては 項5.1. 「ランレベル」 を参照してください。
ランレベル 3 でログインすると、グラフィカル環境ではなくターミナルプロンプトが表示されます。ウィンドウマネージャを起動するには、プロンプトで xinit -e と入力します。
<path-to-window-manager>
<path-to-window-manager>which と入力すると見つけることができます。 window-manager-namewindow-manager-name
例えば、
user@host#which twm/usr/bin/twmuser@host#xinit -e /usr/bin/twm
上記の 1 番目のコマンドは twm ウィンドウマネージャへの絶対パスを返し、 2 番目のコマンドは twm を起動します。
ウィンドウマネージャを終了するには、最後のウィンドウを閉じるか Ctrl-Alt-Backspace の組み合わせを押します。ウィンドウマネージャを終了したら、プロンプトで startx と入力してランレベル 5 で再度ログインし直すことができます。
X サーバーは単一のバイナリ実行可能ファイル (/usr/bin/Xorg) です。関連する設定ファイルは /etc/X11/ ディレクトリに格納されています (/usr/bin/Xorg を指すシンボリックリンク — X — のため)。 X サーバーの設定ファイルは /etc/X11/xorg.conf にあります。
ディレクトリ /usr/lib/xorg/modules/ は起動時に動的にロード可能な X サーバーのモジュールが格納されています。デフォルトでは、 X サーバーによってロードされるのは /usr/lib/xorg/modules/ にあるいくつかのモジュールのみです。
オプションのモジュールをロードするには、 X サーバーの設定ファイル /etc/X11/xorg.conf で指定しなければなりません。モジュールのロード方法については、 項18.3.1.5. 「Module」 を参照してください。
When Red Hat Enterprise Linux 5.2 is installed, the configuration files for X are created using information gathered about the system hardware during the installation process.
/etc/X11/xorg.conf を手動で編集する必要性はあまりありませんが、トラブルシューティングの時などにさまざまなセクションとオプションパラメータについて知っておくと便利です。
/etc/X11/xorg.conf のファイルは、多くの異なるセクションの集まりで構成されており、システムハードウェアの特定の機能を担当します。
各セクションは Section " 行で始まり (<section-name>"<section-name> はセクションのタイトル)、 EndSection 行で終了します。各セクションにはオプション名と 1 つまたは複数のオプション値から構成される複数の行があります。これらは二重引用符で囲まれている場合もあります (")。
# マークで始まる行は、人間が読むためのコメントとして使用され X サーバーには読み込まれない行です。
/etc/X11/xorg.conf ファイルの幾つかのオプションはブール値スィッチを取り、これが機能のオンとオフの切替えをします。有効なブール値は以下のようになります：
-
1、on、true、yes— これらはいずれも、オプションをオンにします。 -
0、off、false、no— これらはいずれもオプションをオフにします。
以下に、標準的な /etc/X11/xorg.conf ファイルに表示されている順序で重要なセクションの一部を示します。 X サーバーの設定ファイルに関する詳細情報は xorg.conf の man ページで確認することができます。
オプションの ServerFlags セクションには、さまざまなグローバル X サーバーの設定が含まれています。このセクションの設定はすべて ServerLayout セクションに配置されているオプションで上書きされてしまう場合があります (詳細は、 項18.3.1.3. 「ServerLayout」 を参照)。
ServerFlags セクション内の各エントリーは、それぞれ独自の行にあり、 Option という用語で始まり、その後に2重引用符 (") で囲まれたオプションが続きます。
以下に ServerFlags セクションのサンプルを示します：
Section "ServerFlags" Option "DontZap" "true" EndSection
特に役立つオプションの幾つかを以下に一覧表示します：
-
"DontZap" "—<boolean>"<boolean>の値が、「true」の場合、 X サーバーを直ちに停止するような Ctrl-Alt-Backspace キーの使用を防止します。 -
"DontZoom" "—<boolean>"<boolean>の値が、「true」の場合、 Ctrl-Alt-Keypad-Plus キーの使用と、 Ctrl-Alt-Keypad-Minus キーを使用した、設定済のビデオ解像度を切替える操作を防止します。
ServerLayout セクションは、 X サーバーによって制御されている入力用デバイスと出力用デバイスをバインドします。このセクションは、最低でも出力デバイスを 1 つ、入力デバイスを 1 つ指定する必要があります。デフォルトでは、モニター (出力デバイス) とキーボード (入力デバイス) が指定されます。
次の例では、標準的な ServerLayout セクションを示しています：
Section "ServerLayout" Identifier "Default Layout" Screen 0 "Screen0" 0 0 InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard" EndSection
以下に ServerLayout セクションで一般的に使用されるエントリーを示します：
-
Identifier— このServerLayoutセクション用の独自の名前を指定します。 -
Screen— X サーバーで使用されるScreenセクションの名前を指定します。複数のScreenオプションが存在することができます。以下に標準的な
Screenエントリーの例を示します：Screen 0 "Screen0" 0 0この例の
Screenエントリー (0) は、最初のモニターコネクター、あるいはビデオカード上の head がScreenセクションの指定した設定を識別子"Screen0"で使用することを示しています。識別子
"Screen0"を使用したScreenセクションの例は 項18.3.1.9. 「Screen」 でご覧になれます。ビデオカードが複数のヘッドを持っている場合、別の番号と別の
Screenセクション識別子を持つもう 1 つのScreenエントリが必要になります。"Screen0"の右の番号は、画面の左上隅に使う X と Y の絶対座標です (デフォルトは0 0)。 -
InputDevice— X サーバーと併用するInputDeviceセクションの名前を指定します。少なくとも 2 つの
InputDeviceエントリがあった方が良いでしょう。 1 つはデフォルトのマウスで、もう1つはデフォルトのキーボードです。オプションのCorePointerとCoreKeyboardは、これらが主要なマウスとキーボードであることを示します。 -
Option "— このセクションのエクストラパラメーターを指定するオプションのエントリーです。ここにリストされているエントリーは<option-name>"ServerFlagsセクションにリストされているものを上書きします。<option-name>には、xorg.confの man ページにあるこのセクションに記載の有効なオプションを入れます。
/etc/X11/xorg.conf ファイルに複数の ServerLayout セクションを置くことができます。デフォルトでは、ただし、サーバーは一番最初に拾うセクションしか読み込みません。
代替となる ServerLayout セクションがある場合、 X セッション起動時にコマンドライン引数として指定することができます。
Files セクションは、フォントパスのように X サーバーに対して重要となるサービスのパスを設定します。これはオプションのセクションになります。これらのパスは通常、自動的に検出されます。このセクションは自動的に検出されるデフォルトを上書きするのに使用できます。
以下の例で、標準的な Files セクションを示します：
Section "Files" RgbPath "/usr/share/X11/rgb.txt" FontPath "unix/:7100" EndSection
以下に一般的に Files セクションで使用されるエントリーを示します：
-
RgbPath— RGB カラーデータベースの場所を指定します。このデータベースは X の全ての有効なカラー名を定義し、それを特定の RGB 値と結合させます。 -
FontPath— X サーバーが、xfsフォントサーバーからフォントを取り出す為に接続する必要のある場所を指定します。デフォルトで、
FontPathはunix/:7100です。これは、 X サーバーに対して、ポート 7100 にある IPC (inter-process communication) 用の UNIX ドメインソケットを使用してフォント情報を得るように指示します。X 及びフォントに関する詳細は、 項18.4. 「フォント」 を参照してください。
-
ModulePath— オプションのパラメーターで、これは X サーバーモジュールを保存する代替のディレクトリを指定します。
デフォルトでは、 X サーバーは自動的に次のモジュールを /usr/lib/xorg/modules/ ディレクトリからロードします。
-
extmod -
dbe -
glx -
freetype -
type1 -
record -
dri
これらのモジュールをロードするデフォルトのディレクトリは変更することができます。 Files セクションにあるオプションの ModulePath パラメータを使って別のディレクトリを指定します。このセクションについての詳細は、 項18.3.1.4. 「Files」 を参照してください。
Module セクションを /etc/X11/xorg.conf に追加すると、 X サーバーにデフォルトのモジュールではなくこのセクションに記載されているモジュールをロードするよう指示することになります。
例えば、次のような一般的な Module セクションの場合、
Section "Module" Load "fbdevhw" EndSection
X サーバーにデフォルトのモジュールではなく fbdevhw をロードするよう指示することになります。
このように、 Module セクションを /etc/X11/xorg.conf に追加すると、ロードしたいデフォルトモジュールの他、追加モジュールも指定する必要があります。
各 InputDevice セクションは X サーバーに対して 1 つの入力デバイスを設定します。システムには一般的には最低 1 つのキーボード用 InputDevice セクションがあります。ほとんどのマウス設定は自動検出されるため、マウス用のエントリがないのが正常です。
以下の例では、キーボード用の標準的な InputDevice セクションを示します。
Section "InputDevice" Identifier "Keyboard0" Driver "kbd" Option "XkbModel" "pc105" Option "XkbLayout" "us" EndSection
一般に InputDevice セクションで使用されるエントリーは以下のようになります：
-
Identifier—InputDeviceセクションの独自の名前を指定します。これは必須のエントリーです。 -
Driver— デバイス用に X がロードする必要のあるデバイスドライバーの名前を指定します。 -
Option— そのデバイスに関係する必要なオプションを指定します。マウスを指定してデバイス用に自動検出されるデフォルトを上書きすることもできます。
xorg.confにマウスを追加する場合、次のようなオプションが一般的に含まれます。-
Protocol—IMPS/2など、マウスで使用するプロトコルを指定します。 -
Device— 物理デバイスの場所を指定します。 -
Emulate3Buttons— 2つのマウスボタンを同時に押した時に 3 ボタンマウスのように動作させるかどうか指定します。
このセクションの有効なオプションの一覧については、
xorg.confの man ページを参照してください。 -
各 Monitor セクションは、システムによって使用されるモニターのタイプを 1 つ設定します。現在、ほとんどのモニターは自動検出されるため、これもオプションエントリになります。
モニターを設定するのに最適な方法は、インストールのプロセス中に X を設定するか、 X 設定ツール を使用することです。 X 設定ツール の使い方については、 章 19. X Window System の設定 を参照してください。
次の例は、モニター用の標準的な Monitor セクションを示しています：
Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName "DDC Probed Monitor - ViewSonic G773-2" DisplaySize 320 240 HorizSync 30.0 - 70.0 VertRefresh 50.0 - 180.0 EndSection
警告
/etc/X11/xorg.conf の Monitor セクション内で値を手作業で編集する場合は細心の注意を払ってください。不適切な値によりモニターを損傷したり、破損させる可能性があります。モニターのマニュアルにて安全な操作のためのパラメータ一覧を確認してください。
以下に Monitor セクションで一般的に使用されるエントリーを示します：
-
Identifier—Monitorセクション用の独自に名前を指定します。これは必須のエントリーです。 -
VendorName— モニターのベンダーを指定するオプションのパラメータです。 -
ModelName— モニターのモデル名を指定するオプションのパラメータです。 -
DisplaySize— モニターの表示面積をミリメーターで指定するオプションのパラメータです。 -
HorizSync— モニターで互換性のある水平同期周波数の幅を kHz 単位で指定します。この値は X サーバーがモニター用の組込みまたは指定されたModelineエントリの適合性を判定するのに役立ちます。 -
VertRefresh— モニターでサポートされている垂直リフレッシュ周波数の幅を kHz 単位で指定します。これらの値は、 X サーバーが、モニター用の組込みの、あるいは指定されたModelineエントリーの適合性を判定するのに役立ちます。 -
Modeline— 特定の水平同期と垂直リフレッシュ解像度で、特定の解像度におけるモニター用の追加ビデオモードを指定するオプションのパラメータです。Modelineエントリーに関する詳しい説明は、xorg.confの man ページを参照してください。 -
Option "— このセクションのエクストラパラメータを指定するオプションのエントリーです。<option-name>"<option-name>には、xorg.confの man ページにあるこのセクションに記載された有効なオプションを入れます。
各 Device セクションは、システム上のビデオカード1つを設定します。1つの Device セクションが最低限ですが、マシン上にインストールされている各ビデオカードの為に追加分の設定も有り得ます。
ビデオカードを設定する最適な方法は、インストールプロセス中に X を設定するか、 X 設定ツール を使用することです。 X 設定ツール の使い方については、 章 19. X Window System の設定 を参照してください。
次の例は、ビデオカード用の標準的な Device セクションを示しています：
Section "Device" Identifier "Videocard0" Driver "mga" VendorName "Videocard vendor" BoardName "Matrox Millennium G200" VideoRam 8192 Option "dpms" EndSection
以下に Device セクションで一般的に使用されるエントリーを示します：
-
Identifier— このDeviceセクション用の独自の名前を指定します。これは必須のエントリーです。 -
Driver— ビデオカードを使用するために X サーバーがロードする必要があるドライバーを指定します。hwdataパッケージでインストールされる/usr/share/hwdata/videodriversの中にドライバの一覧があります。 -
VendorName— ビデオカードのベンダーを指定するオプションのパラメータです。 -
BoardName— ビデオカードの名前を指定するオプションのパラメータです。 -
VideoRam— ビデオカード上で利用できる RAM の容量をキロバイトで指定するオプションのパラメータです。この設定は X サーバーがビデオ RAM の容量を検出できなかった時にのみ必要です。 -
BusID— ビデオカードのバスの場所を指定するエントリです。ビデオカードが 1 つしかないシステムでは、BusIDエントリはオプションになるため、デフォルトの/etc/X11/xorg.confファイルにもないかもしれません。ただし、複数のビデオカードがあるシステムでは、BusIDエントリがなければなりません。 -
Screen—Deviceセクションが設定するビデオカード上のモニターコネクター又はヘッドを指定するオプションのエントリーです。このオプションは複数ヘッドを持つビデオカードだけに役立ちます。複数のモニターが同一のビデオカードの異なるヘッドに接続されている場合、別々の
Deviceセクションが必要となり、各セクションは異なるScreen値を持つ必要があります。Screenエントリーの値は、整数である必要があります。ビデオカード上の最初のヘッドは、値0を持ちます。各追加ヘッドの値はこの値から1つずつ加算されていきます。 -
Option "— このセクションのエクストラパラメータを指定するオプションのエントリーです。<option-name>"<option-name>には、xorg.confの man ページにあるこのセクションに記載された有効なオプションを入れます。一般的なオプションの 1 つは
"dpms"で (Display Power Management Signaling の略、 VESA 標準)、 モニターの Service Star 省電力規定機能を起動します。
各 Screen セクションは、1つのビデオカード (又は ビデオカードヘッド) を、 Device セクションと Monitor セクションをそれぞれ参照することにより、1つのモニターに結合します。1つの Screen は最低限ですが、マシン上にあるビデオカードとモニターのそれぞれの組み合わせの為に、追加の構成も有り得ます。
以下の例は、標準的な Screen セクションを示しています：
Section "Screen" Identifier "Screen0" Device "Videocard0" Monitor "Monitor0" DefaultDepth 16 SubSection "Display" Depth 24 Modes "1280x1024" "1280x960" "1152x864" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 16 Modes "1152x864" "1024x768" "800x600" "640x480" EndSubSection EndSection
以下に一般的に使用される Screen セクションのエントリーを示します：
-
Identifier— このScreenセクションの独自の名前を指定します。これは必須のエントリーです。 -
Device—Deviceセクションの独自の名前を指定します。これは必須のエントリーです。 -
Monitor—Monitorセクション固有の名前を指定します。xorg.confファイルで特定のMonitorセクションが定義されている場合にのみ必要になります。通常、モニターは自動的に検出されます。 -
DefaultDepth— デフォルトの色の深さをビットで指定します。上記の例では、16がデフォルトになります (数千の色を提供する)。DefaultDepthは 1 つしか指定できませんが、 Xorg コマンドラインオプションの-depthで上書きされる場合があります。<n><n> -
SubSection "Display"— 特定の色の深さで利用できるスクリーンモードを指定します。Screenセクションは複数のDisplayサブセクションを使用できます。スクリーンモードは自動的に検出されるため、これは完全なオプションになります。このサブセクションは通常、自動検出されたモードの上書きに使用します。
-
Option "— このセクションのエクストラパラメータを指定するオプションのエントリーです。<option-name>"<option-name>には、xorg.confの man ページにあるこのセクションに記載された有効なオプションを入れます。
オプションの DRI セクションは、 DRI (Direct Rendering Infrastructure) 用のパラメータを指定します。 DRI は、最新のビデオハードウェアに組込みの 3D ハードウェア高速化機能の利点を 3D ソフトウェアアプリケーションが利用できるようにするインターフェースです。また、 DRI は、ビデオカードドライバでサポートされていれば、ハードウェア高速化から 2D のパフォーマンスも向上させることができます。
DRI Group と Mode は自動的にデフォルト値に初期化されるため、このセクションはめったに現われません。別の Group または Mode にする場合に、このセクションを xorg.conf ファイルに追加するとデフォルト値を上書きします。
以下の例は、標準的な DRI セクションを示します：
Section "DRI" Group 0 Mode 0666 EndSection
異なるビデオカードは、異なる方法で DRI を使用しますので、最初に http://dri.sourceforge.net/ を参照するまでは、このセクションに変更を行わないでください。
Red Hat Enterprise Linux は、 Fontconfig と xfs の 2 つのサブシステムを使って X 稼動下のフォントを管理、表示します。
より新しい Fontconfig フォントサブシステムはフォント管理を単純化し、 anti-aliasing などの高度な表示機能を提供します。このシステムは、 Qt 3 または GTK+ 2 グラフィカルツールキットを使用してプログラムされたアプリケーションに対して自動的に利用されます。
互換性を保つために Red Hat Enterprise Linux にはコア X フォントサブシステムと呼ばれるオリジナルのフォントサブシステムが含まれています。このシステムは 15 年の歴史を持ち、 X Font Server (xfs) をベースにしています。
このセクションでは、上記の両方のシステムを使用して X の為のフォントの設定法を説明していきます。
Fontconfig フォントサブシステムを使用すると、アプリケーションがシステム上のフォントに直接アクセスできるようになり、 Xft 又は他のレンダリング機構を使って高度な anti-aliasingでのFontconfig フォントを描写できます。グラフィカルアプリケーションは Fontconfig と共に Xft ライブラリを使用してテキストを画面に描くことが出来ます。
そのうち、 Fontconfig/Xft フォントサブシステムがコア X フォントサブシステムに取って替ることになります。
重要
Fontconfig フォントサブシステムは、いまのところ OpenOffice.org には機能しません。このアプリケーションは独自のフォントレンダリング技術を使用しています。
Fontconfig は、 /etc/fonts/fonts.conf 設定ファイルを使用することに注意してください。 Fontconfig の設定ファイルは手作業で編集すべきではありません。
ヒント
新しいフォントシステムへの移行のため、 GTK+ 1.2 アプリケーションは フォント設定 のダイアログ(System (on the panel) => 個人設定 => フォント の順で選択してアクセス) での変更には影響されません。これらのアプリケーションには、以下の行をファイル ~/.gtkrc.mine に追加することでフォントが設定できます。
style "user-font" { fontset = "<font-specification>" } widget_class "*" style "user-font"
<font-specification> には、 -adobe-helvetica-medium-r-normal--*-120-*-*-*-*-*-* などの従来の X アプリケーションで使用されるスタイルでのフォント指定を入れます。コアフォントの完全一覧は、 xlsfonts を実行して表示するか、 xfontsel コマンドを使用してインテラクティブに作成することができます。
新しいフォントを Fontconfig サブシステムに追加することは簡単明快なプロセスです。
-
システム全体にフォントを追加するには、追加する新しいフォントを
/usr/share/fonts/ディレクトリにコピーします。local/など新しいサブディレクトリをその中に作成してユーザーがインストールしたフォントとデフォルトのフォントを区別しておくと便利です。フォントを個人のユーザー用に追加するには、その新しいフォントをユーザーのホームディレクトリ内の
.fonts/ディレクトリにコピーします。 -
fc-cacheコマンドを使用して、以下の例に示すようにフォント情報のキャッシュを更新します：fc-cache<path-to-font-directory>このコマンドでは、
<path-to-font-directory>には、その新しいフォントを収納しているディレクトリ (/usr/share/fonts/local/または/home/) を入れます。<user>/.fonts/
ヒント
個人ユーザーは、 Nautilus アドレスバーに fonts:/// と入力、新しいフォントファイルをそこへドラッグすることでフォントをグラフィカルにインストールすることもできます。
重要
フォントファイル名が拡張子 .gz で終っている場合、それは圧縮してあり、解凍するまで使用できません。これを実行するには、 gunzip コマンドを使用するか、又はファイルをダブルクリックして、フォントを Nautilus 内の１つのディレクトリにドラッグします。
互換性を保つために、 Red Hat Enterprise Linux はコア X フォントサブシステムを提供しています。 X フォントサーバー (xfs) を使用してフォントを X クライアントアプリケーションに提供します。
X サーバーは、 /etc/X11/xorg.conf 設定ファイルの Files セクション内 FontPath ディレクティブに指定してあるフォントサーバーを探します。 FontPath エントリの詳細については 項18.3.1.4. 「Files」 を参照してください。
X サーバーは、指定ポート上で xfs サーバーに接続しフォント情報を取得します。この理由から、 X が起動するには xfs サービスは実行中でなければなりません。特定のランレベルに対するサービスの設定方法については、 章 5. サービスへのアクセスの制御 を参照してください。
/etc/rc.d/init.d/xfs スクリプトは xfs サーバーを開始します。設定ファイル、 /etc/X11/fs/config の中で数種のオプションが設定できます。
次は一般的なオプションの一覧です：
-
alternate-servers— このフォントサーバーが利用できない場合に、使用する代替フォントサーバーの一覧を指定します。一覧内の各フォントサーバーはコンマで区切る必要があります。 -
catalogue— 使用するフォントパスの順番の一覧を指定します。一覧内の各フォントパスはコンマで区切る必要があります。フォントパスの直後に文字列
:unscaledを使用して、そのパス内の無倍率のフォントを最初にロードさせます。その後全体のパスを再度指定すると、他の倍率付きのフォントもロードされるようになります。 -
client-limit— そのフォントサーバーが処理するクライアントの最大数を指定します。デフォルトは10です。 -
clone-self—client-limitが打ち込まれた時、フォントサーバーにそれ自身の新しいバージョンをクローンできる様にします。デフォルトでは、このオプションはonです。 -
default-point-size— この値を指定しないフォント用にデフォルトのフォントを指定します。このオプションの値はデシポイントで設定してあります。デフォルトの120は、 12 ポイントのフォントに相当します。 -
default-resolutions— X サーバーによりサポートされている解像度のリストを指定します。リスト内の各解像度はカンマで区切る必要があります。 -
deferglyphs— glyphs (フォントを可視的に表示するために使用されるグラフィックス) のロードを遅延させるかどうか指定します。この機能を無効にするには、noneを使用し、すべてのフォントに対してこの機能を有効にするにはallを使用します。この機能を 16 ビットフォント用にのみ有効にするには16を使用します。 -
error-file—xfsのエラーが記録された場所のパスとファイル名を指定します。 -
no-listen—xfsが特定のプロトコルをリッスンしないように防止します。デフォルトでは、このオプションはtcpに設定されており、セキュリティの目的でxfsが TCP ポートをリッスンしないようにしています。ヒント
ネットワーク上でフォントを処理するために
xfsを使用する場合は、この行を削除します。 -
port—no-listenが存在しない、又はそれがコメントアウトしてある場合、xfsがリッスンする TCP ポートを指定します。 -
use-syslog— システムエラーログを使用するかどうかを指定します。
コア X フォントサブシステム (xfs) にフォントを追加するには、次のステップに従います：
-
すでに存在していない場合は、ルートで次のコマンドを使用して
/usr/share/fonts/local/というディレクトリを作成します：mkdir /usr/share/fonts/local//usr/share/fonts/local/ディレクトリの作成が必要な場合、次のコマンドをルートで入力してディレクトリをxfsのパスに追加します：chkfontpath --add /usr/share/fonts/local/ -
新しいフォントファイルを
/usr/share/fonts/local/ディレクトリにコピーします。 -
ルートとして次のコマンドを発行して、フォント情報を更新します：
ttmkfdir -d /usr/share/fonts/local/ -o /usr/share/fonts/local/fonts.scale -
root になり次のコマンドを発行して
xfsフォントサーバーを再ロードします。service xfs reload
ほとんどの場合、 Red Hat Enterprise Linux のインストーラーは ランレベル 5 として知られるグラフィカルなログイン環境でマシンが起動するよう設定します。ただし、 ランレベル 3 と呼ばれるテキストのみの複数ユーザーモードで起動して、そこから X のセッションを開始することも可能です。
ランレベルに関する詳細は 項5.1. 「ランレベル」 を参照してください。
次のサブセクションでは、 X がランレベル 3 及びランレベル 5 でどのようにスタートするかを説明します。
ランレベル 3 にいる場合、 X のセッションを開始する最適な方法は、ログインして startx と入力することです。 startx コマンドは xinit コマンドへのフロントエンドであり、 X サーバー (Xorg) を起動してそれを X クライアントアプリケーションと接続します。ユーザーはすでにシステムにランレベル 3 でログインしているため、 startx はディスプレイマネージャを起動したり、ユーザーを認証したりはしません。ディスプレイマネージャに関する詳細は 項18.5.2. 「ランレベル 5」 を参照してください。
startx コマンドが実行されると、ユーザーのホームディレクトリ内の .xinitrc ファイルを検索して、デスクトップ環境を定義し、恐らく実行すべき他の X クライアントアプリケーションも定義します。 .xinitrc ファイルがない場合、システムデフォルトの /etc/X11/xinit/xinitrc ファイルを代わりに使用します。
デフォルトの xinitrc スクリプトは、次にユーザーのホームディレクトリ内の .Xresources、 .Xmodmap、 .Xkbmap、 及び /etc/X11/ ディレクトリ内の Xresources、 Xmodmap、 Xkbmap などのユーザー定義のファイルやデフォルトのシステムファイルを探します。 Xmodmap ファイルと Xkbmap ファイルが存在していれば、 xmodmap ユーティリティによりキーボードの設定に使用されます。 Xresources ファイルはアプリケーションに対する特定のユーザー設定値を割り当てるために読み込まれます。
これらのオプションの設定のあとは、 xinitrc スクリプトが /etc/X11/xinit/xinitrc.d/ ディレクトリに置かれている全てのスクリプトを実行します。このディレクトリの重要なスクリプトの 1 つはデフォルト言語の設定などを行う xinput.sh です。
次に、 xinitrc スクリプトはユーザーのホームディレクトリ内の .Xclients を実行を試み、それが見つからない場合には /etc/X11/xinit/Xclients を実行します。 Xclients ファイルの目的はデスクトップ環境または単に基本のウィンドウマネージャを起動するためです。ユーザーのホームディレクトリ内にある .Xclients スクリプトは .Xclients-default ファイル内のユーザー指定のデスクトップ環境を起動します。ユーザーのホームディレクトリ内に .Xclients がなければ、標準の /etc/X11/xinit/Xclients スクリプトがもう 1 つのデスクトップ環境の起動を試行します。最初に GNOME、 次に KDE、 そして twm の順で試行します。
ランレベル 3 の場合、 X セッションを終了するとユーザーはテキストモードのユーザーセッションに戻ります。
システムがランレベル 5 で起動すると、 ディスプレイマネージャ と呼ばれる特殊な X クライアントアプリケーションが起動します。ユーザーは、デスクトップ環境またはウィンドウマネージャが起動する前にディスプレイマネージャを使用して認証する必要があります。
システム上にインストールされているデスクトップ環境によっては 3 種類のディスプレイマネージャがユーザー認証に利用できます。
-
GNOME— Red Hat Enterprise Linux のデフォルトのディスプレイマネージャであるGNOMEを使用してユーザーは言語設定、シャットダウン、再起動、システムへのログインを設定することができます。 -
KDE— KDE のディスプレイマネージャによりユーザーはシャットダウン、再起動、及びシステムへのログインができます。 -
xdm— 非常に基本的なディスプレイマネージャでこれにより、ユーザーがシステムにログインできるようになります。
ランレベル 5 で起動する場合、 prefdm スクリプトは /etc/sysconfig/desktop ファイルを参照して優先するディスプレイマネージャを決定します。このファイルのオプション一覧は以下の通りです。
/usr/share/doc/initscripts-<version-number>/sysconfig.txt
<version-number> は initscripts パッケージのバージョン番号になります。
それぞれのディスプレイマネージャは /etc/X11/xdm/Xsetup_0 を参照して、ログイン画面をセットします。ユーザーがシステムにログインすると、 /etc/X11/xdm/GiveConsole スクリプトが実行され、コンソールの所有者をユーザーに割り当てます。その後、 /etc/X11/xdm/Xsession スクリプトが実行されて、通常はランレベル 3 からX をスタートする時に xinitrc スクリプトにより実践される多くのタスクが達成されます。これにはシステムとユーザーリソースの設定、及び /etc/X11/xinit/xinitrc.d/ ディレクトリのスクリプトの実行が含まれます。
ユーザーは GNOME または KDE のディスプレイマネージャを使って認証を行う場合、使用するデスクトップ環境を指定することができます。どちらにするかは セッション メニューアイテムから選択します (System (on the panel) => 個人設定 => 他の個人設定 => セッション の順でアクセス)。ディスプレイマネージャでデスクトップ環境が指定されない場合、 /etc/X11/xdm/Xsession スクリプトがユーザーのホームディレクトリにある .xsession ファイルと .Xclients ファイルをチェックして、ロードするデスクトップ環境を決定します。最後の手段は、ランレベル 3 と同様に /etc/X11/xinit/Xclients ファイルを使用して利用するデスクトップ環境またはウィンドウマネージャを選択します。
ユーザーがデフォルトのディスプレイ (:0) で X セッションを終了してログアウトすると、 /etc/X11/xdm/TakeConsole スクリプトが実行しコンソールの所有権を root ユーザーに割り当て直します。ユーザーがログインした後、実行を継続しているオリジナルのディスプレイマネージャは、新しいディスプレイマネージャを生成して制御権を得ます。これにより X サーバーが再起動し、新しいログインウィンドウを表示して再度プロセス全体を起動します。
ユーザーがランレベル 5 からX のログアウトをすると、ディスプレイマネージャに戻ります。
ディスプレイマネージャによるユーザー認証に関しては /usr/share/doc/gdm- (<version-number>/README<version-number> はインストールされている gdm パッケージのバージョン番号) 及び xdm man ページを参照してください。
X サーバー、このサーバーに接続されているクライアント、及びさまざまなデスクトップ環境とウィンドウマネージャについては他にも多量の詳細情報があります。
-
/usr/share/X11/doc/— X Window System アーキテクチャに関する詳細なドキュメントが含まれている他、 Xorg プロジェクトに関する初心者向け情報なども含まれています。 -
man xorg.conf—xorg.conf設定ファイルに関する情報が入っています。ファイル内のさまざまなセクションの構文とその意味も収納しています。 -
man Xorg—Xorgディスプレイサーバーについて説明しています。
-
http://www.X.org/ — X.Org Foundation のホームページです。 X Window System の X11R7.1 リリースを製作しています。 X11R7.1 リリースは、必須ハードウェアの制御、及び GUI 環境を提供するため Red Hat Enterprise Linux に同梱されています。
-
http://dri.sourceforge.net/ — DRI（Direct Rendering Infrastructure） プロジェクトのホームページ。 DRI は、 X のコアハードウェア 3D アクセラレーションコンポーネントです。
-
http://www.gnome.org/ — GNOME プロジェクトのホームページ。
-
http://www.kde.org/ — KDE デスクトップ環境のホームページ。
インストール中に、システムのモニタ、ビデオカード、表示設定などの設定が行なわれます。インストール終了後に、これらの設定を変更するには、 X 設定ツール を使用します。
X 設定ツール を起動するには、 System (on the panel) => 管理 => ディスプレイ の順で進み選択するか、シェルプロンプト (例、XTerm、GNOME ターミナルなど) で system-config-display コマンドを入力します。 X Window System を実行していない場合は、プログラムを実行するために X の縮小版が起動します。
設定を変更したら、一旦、グラフィックデスクトップをログアウトしてからログインし直すと変更が反映されます。
設定 タブで、ユーザーは 解像度 と 色の深さ を変更できます。モニタのディスプレイは ピクセル と呼ばれる小さな点 (ドット) の集りで構成されています。一度に表示されるピクセルの数が解像度と呼ばれます。例えば、解像度が 1024x768 とは、水平ピクセルが 1024 、垂直ピクセルが 768 使用されるということになります。解像度が高いほど、モニタが一度に表示できるイメージ (画像を構成する情報) が多くなります。
ディスプレイの色の深さは、表示可能な色の数を決定します。色の深さが大きいほど、色彩のコントラストが豊かになります。
X 設定ツール が起動されると、モニタとビデオカードが検出されます。ハードウェアが正しく検出されると、図 19.2. 「ディスプレイハードウェアの設定」 に示すように、 ハードウェア タブにその情報が表示されます。
モニタタイプ、その他モニタの設定を変更するには、該当する 設定 ボタンをクリックします。ビデオカードタイプ、その他ビデオカードの設定を変更するには、そのとなりにある 設定 ボタンをクリックします。
複数のビデオカードがシステムにインストールされている場合、デュアルヘッドモニタサポートが利用可能となり、 図 19.3. 「デュアルヘッドディスプレイの設定」 に示してあるように、 デュアルヘッド タブを通して設定ができます。
デュアルヘッドを有効にするには、 デュアルヘッドを使用 のチェックボックスにチェックを入れます。
二つめのモニタタイプの設定を変更するには、該当する 設定 ボタンをクリックします。そして該当するドロップダウンリストを使用して、他のデュアルヘッド事項の設定も出来ます。
デスクトップレイアウト オプションでは、 拡張デスクトップ を選択すると、両方のモニタで拡張した作業エリアとして使用できます。 個別のデスクトップ を選択すると、マウスとキーボードは両画面で共有できますが、同一画面となります。
ユーザー と グループ の管理は、 Red Hat Enterprise Linux システム管理の中核をなします。
ユーザー とは、特定のアプリケーションを使用する人 (実在のユーザーと連結するアカウントの意) またはアカウントのことです。
グループ は、共通の目的の為にユーザーを統合して組織を論理的に表したものです。同一グループのユーザーにはそのグループ所有ファイルの読み込み、書き込み、又は実行が可能です。
各ユーザーとグループは、 userid (UID) と groupid (GID) という数字で表される固有の識別番号をそれぞれ持っています。
あるファイルを作成するユーザーは、そのファイルの所有者でありグループとしての所有者でもあります。ファイルは、所有者、グループ、その他に対して読み込み、書き込み、実行の権限をそれぞれ別々に割り当てられます。ファイルの所有者を変更できるのは root ユーザーだけで、またアクセス権限を変更できるのは root ユーザーとファイルの所有者のみになります。
ユーザーマネージャ を使用するとローカルのユーザー及びグループの表示、変更、追加、削除ができます。
ユーザーマネージャ を使用するには、 X Window システムを実行中の状態で root 特権があり、 system-config-users RPM パッケージがインストールされていなければなりません。デスクトップから System (on the panel) => 管理 => ユーザーとグループ と進みます。また、シェルプロンプトで system-config-users コマンドを入力することもできます (XTerm や GNOME ターミナルなど)。
システム上のローカルユーザーの一覧を表示するには、 ユーザー タブをクリックします。システム上のローカルグループの一覧を表示するには、 グループ タブをクリックします。
特定のユーザーまたはグループを検索するには、 検索フィルタ フィールドにその名前の最初の数文字を入力します。 エンター を押すか フィルタの適用 ボタンをクリックします。フィルタされた一覧が表示されます。
ユーザーまたはグループを分類するには、目的の欄をクリックします。その欄の値に応じてユーザーまたはグループが分類されます。
Red Hat Enterprise Linux はシステムユーザー用に 500 未満のユーザー ID を保留しています。デフォルトでは、 ユーザーマネージャ はシステムユーザーを表示しません。システムユーザーを含めすべてのユーザーを表示するには、 編集 => 個人設定 に行き、ダイアログボックスで システムユーザーとグループを非表示 のチェックを外します。
新規ユーザーを追加するには、 ユーザーの追加 ボタンをクリックします。 図 20.2. 「新規ユーザー」 に示すようなウィンドウが表示されます。各フィールドに新規ユーザーのユーザー名とフルネームを入力します。 パスワード と パスワードの確認 フィールドにそのユーザーのパスワードを入力します。パスワードは最低でも 6 文字にしてください。
ヒント
できるだけこれより長いパスワードを使用することをお勧めします。長いパスワードを使うことにより、侵入者にとってはパスワードを推測してパーミッションなしにアカウントにアクセスするのが難しくなるためです。また、辞書に載っているような単語をベースとするパスワードは避け、文字と数字、特殊文字を組み合わせて作成してください。
ログインシェルを選択します。どのシェルを選択して良いのかわからない場合はデフォルトの /bin/bash にしてください。デフォルトのホームディレクトリは /home/ になります。ユーザー用に作成されるディレクトリを変更することができます。あるいは ホームディレクトリの作成 の選択を外すとホームディレクトリを作成しない選択を行うこともできます。
<username>/
ホームディレクトリの作成を選択すると、デフォルトの設定ファイルが /etc/skel/ ディレクトリから新しいホームディレクトリにコピーされます。
Red Hat Enterprise Linux は ユーザープライベートグループ (UPG - user private group) スキームを使用しています。 UPG スキームは標準 UNIX でのグループ処理法に対して全く追加も変更もしておらず、新しい取り決めを提供しています。新規ユーザーを作成すると必ず、デフォルトでユーザー名と同じ名前の固有のグループが作成されます。このグループを作成したくない場合、 ユーザーのプライベートグループを作成 の選択を外します。
このユーザーのユーザー ID を指定するには、 ユーザー ID を手動で指定 を選択します。オプションが選択されないと、新規ユーザーには 500 以上のユーザー ID 番号から順次割り当てられて行きます。 Red Hat Enterprise Linux はシステムユーザー用に 500 未満のユーザー ID を保留しているため、手動でユーザー ID を割り当てる際に 1 から 499 の番号は避けた方が良いでしょう。
OK をクリックしてユーザーを作成します。
パスワードの有効期限など高度なユーザープロパティを設定するには、ユーザーを追加してからそのユーザーのプロパティを変更します。詳細については 項20.1.2. 「ユーザーのプロパティを変更する」 を参照してください。
既存ユーザーのプロパティを表示するには、 ユーザー タブをクリックしてユーザーの一覧からそのユーザーを選択、メニューから プロパティ をクリックします(または、プルダウンメニューから ファイル => プロパティ の順で選ぶ)。 図 20.3. 「ユーザーのプロパティ」 のようなウィンドウが表示されます。
ユーザーのプロパティ ウィンドウは複数のタブページに分かれています。
-
ユーザーデータ — ユーザーを追加したときに設定されたユーザーの基本情報を表示します。このタブを使ってユーザーのフルネーム、パスワード、ホームディレクトリ、ログインシェルを変更します。
-
アカウント情報 — アカウントの期限が特定の日付で切れるようにする場合は、 アカウントの有効期限を有効にする を選択します。該当フィールドに日付を入れます。 ローカルパスワードがロックされます を選択してユーザーアカウントをロックしユーザーがシステムにログインできなくなるようにします。
-
パスワード情報 — ユーザーのパスワードが最後に変更された日付を表示します。特定日数が経過したらユーザーに強制的にパスワードを変更させるには、 パスワード失効を有効にする を選択して 変更が要求されるまでの日数: フィールドに値を入力します。また、ユーザーのパスワードが失効するまでの日数、ユーザーがパスワード変更の警告を受けるまでの日数、アカウントが無効になるまでの日数などが変更できます。
-
グループ — ユーザーのプライマリグループを表示、設定できる他、このユーザーをメンバーにしたいグループを表示して設定することもできます。
新規ユーザーグループを追加するには、 グループの追加 ボタンをクリックします。 図 20.4. 「新規グループ」 のようなウィンドウが表示されます。作成する新規グループの名前を入力します。新規グループのグループ ID を指定するには、 グループ ID を手動で指定 を選択し GID を選択します。 Red Hat Enterprise Linux はシステムグループ用に 500 未満のグループ ID も保留しているので注意してください。
OK をクリックしてグループを作成します。新規グループがグループの一覧に表示されます。
既存グループのプロパティを表示するには、グループの一覧からグループを選択してメニューから プロパティ をクリックします (または、プルダウンメニューから ファイル => プロパティ の順で選択する)。 図 20.5. 「グループのプロパティ」 のようなウィンドウが表示されます。
グループユーザー タブではどのユーザーがこのグループのメンバーか表示しています。このタブを使ってグループからユーザーを追加または削除します。 OK をクリックして変更を保存します。
ユーザーとグループの管理は退屈な作業になり得るため、 Red Hat Enterprise Linux は管理が行いやすいようツールや取り決めを提供しています。
ユーザーとグループを管理する最も簡単な方法は、グラフィカルアプリケーション ユーザーマネージャ (system-config-users) を使用することです。 ユーザーマネージャ の詳細については 項20.1. 「ユーザーとグループの管理」 を参照してください。
次のコマンドラインツールを使用してユーザーとグループを管理することもできます：
-
useradd、usermod、及びuserdel— ユーザーアカウントの追加、削除、及び修正をする業界標準の方法です。 -
groupadd、groupmod、及びgroupdel— ユーザーグループの追加、削除、及び修正をする業界標準の方法です。 -
gpasswd—/etc/groupファイルを管理するための業界標準の方法です。 -
pwck、grpck— パスワード、グループ、及び関連のシャドーファイルの検証に使用するツールです。 -
pwconv、pwunconv— シャドーパスワードへの変換と標準パスワードへの復元に使用するツールです。
システムにユーザーを追加するには、
useradd のコマンドラインオプションは 表 20.1. 「useradd コマンドラインのオプション」 に記載されています。
| オプション | 説明 |
|---|---|
-c '<comment>'
|
<comment> に入れる文字列は任意です。このオプションは一般的にはユーザーのフルネームを指定するために使われます。
|
-d<home-dir>
|
デフォルトの /home/ の代わりに使用するホームディレクトリです。
|
-e<date>
|
YYYY-MM-DD の形式でアカウントを無効にする日付を指定します。 |
-f<days>
|
パスワードが失効してからアカウントが無効になるまでの日数です。 0 を指定すると、アカウントはパスワード失効直後に無効になります。 -1 を指定すると、アカウントはパスワードが失効しても無効になりません。
|
-g<group-name>
|
ユーザーのデフォルトグループのグループ名とグループ番号です。グループはここに指定される以前から存在していなければなりません。 |
-G<group-list>
|
ユーザーがメンバーとなる追加グループ (デフォルト以外) のグループ名とグループ番号をコンマで区切って入れます。グループはここに指定される以前から存在していなければなりません。 |
-m
|
存在しない場合に、ホームディレクトリを作成します。 |
-M
|
ホームディレクトリを作成しません。 |
-n
|
ユーザー用のユーザープライベートグループを作成しません。 |
-r
|
UID が 500 未満のシステムアカウントを作成してホームディレクトリを作成しません。 |
-p<password>
|
パスワードを crypt で暗号化します。
|
-s
|
ユーザーのログインシェルです。 /bin/bash にデフォルト設定されます。
|
-u<uid>
|
ユーザーのユーザー ID です。固有の番号で 499 より大きい数でなければなりません。 |
表 20.1. useradd コマンドラインのオプション
システムにグループを追加するには、 groupadd コマンドを実行します。
groupadd <group-name>
groupadd コマンドラインのオプションについては 表 20.2. 「groupadd コマンドラインのオプション」 に記載されています。
| オプション | 説明 |
|---|---|
-g<gid>
|
グループのグループ ID です。固有の番号で 499 より大きい数でなければなりません。 |
-r
|
GID が 500 未満のシステムグループを作成します。 |
-f
|
-g<gid> と併用した場合に、この <gid> がすでに存在すると groupadd はこれとは別の固有なグループ用 <gid> を選びます。
|
表 20.2. groupadd コマンドラインのオプション
セキュリティ上、ユーザーは定期的にパスワードの変更が求められることが推奨されます。 ユーザーマネージャ の パスワード情報 タブでユーザーを追加または編集するときに行うことができます。
シェルプロンプトからユーザーのパスワード失効の設定をするには、 chage コマンドを使用し、次に 表 20.3. 「chage コマンドラインオプション」 にあるオプションを付けてから最後にユーザーのユーザー名を付けます。
重要
chage コマンドを使用するにはシャドーパスワードを有効にする必要があります。
| オプション | 説明 |
|---|---|
-m<days>
|
ユーザーがパスワードを変更できる最小日数を指定します。値が 0 ならパスワードはいつでも変更が可能になります。 |
-M<days>
|
パスワードが有効である最大日数を指定します。このオプションで指定された日数と -d オプションで指定された日数の和が過去になる場合、ユーザーはこのアカウントを使用する前にパスワードを変更する必要があります。
|
-d<days>
|
1970 年 1 月 1 日から起算して指定した日数がパスワードの変更が行われた日付とします。 |
-I<days>
|
パスワードが失効してからアカウントがロックされるまでのアクティブな日数を指定します。値が 0 ならパスワードが失効してもアカウントはロックされません。 |
-E<date>
|
アカウントがロックされる日付を YYYY-MM-DD の形式で指定します。日付を指定する代わりに、 1970 年 1 月 1 日からの起算日数で指定することも可能です。 |
-W<days>
|
ユーザーにパスワード失効の日付を警告するまでの日数を指定します。 |
表 20.3. chage コマンドラインオプション
ヒント
chage コマンドの直後にユーザー名を付けると (オプションなし) 、現在のパスワードエージングの値を表示してからその値の変更ができます。
ユーザーがはじめてログインしたときにパスワードの期限が切れるよう設定することができます。これによりユーザーは、はじめてのログインでパスワードの変更が強制されます。
注記
ユーザーが SSH プロトコルを使ってログインする場合、この方法は使用できません。
-
ユーザーパスワードをロックする — ユーザーが存在しない場合、
useraddコマンドを使用してユーザーアカウントを作成しますが、そのアカウントをロックしたままにするためにはパスワードを与えないようにします。パスワードがすでに有効になっている場合、次のコマンドを使ってロックします。
usermod -Lusername -
直ちにパスワードを強制的に失効させる — 次のコマンドを入力します。
chage -d 0usernameこのコマンドは、パスワードが最後に変更された日付の値を 1970 年 1 月 1 日に設定します。この値は、いかなるパスワードエージングのポリシーが設定されていようと関係なく、直ちにパスワードを強制的に失効させます。
-
アカウントのロックを解除する — 一般的には 2 通りの方法があります。管理者によって初期パスワードまたは空のパスワードを割り当てます。
警告
パスワードの設定に
passwdを使用しないでください。設定したばかりの即時パスワード強制失効を無効にしてしまいます。初期パスワードを割り当てるには、次の手順に従います。
-
pythonコマンドでコマンドライン Python インタプリタを起動します。次のように出力されます。Python 2.4.3 (#1, Jul 21 2006, 08:46:09) [GCC 4.1.1 20060718 (Red Hat 4.1.1-9)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> -
プロンプトで、次のコマンドを入力します。
<password>には暗号化するパスワードを、<salt>には英数字、斜線 (/)、 ドット (.)、から少くとも 2 種類選んで組み合わせたものを入れます。import crypt; print crypt.crypt("<password>","<salt>")出力は暗号化されたパスワードで、
'12CsGd8FRcMSM'ようになります。 -
Ctrl-D を押して Python インタプリタを終了します。
-
シェルで、次のコマンドを入力します (
<encrypted-password>には Python インタプリタからの暗号化された出力を入れる)。usermod -p "<encrypted-password>"<username>
代わりに、初期パスワードではなく空のパスワードを割り当てることもできます。これを行うには、次のコマンドを実行します。
usermod -p ""username注意
空のパスワードは便利ですが、安全性のないユーザー名を使用しているシステムへのアクセスにサードパーティが最初にログインしてしまう恐れがあるため非常に危険な行為でもあります。空パスワードのアカウントのロックを解除する前には、必ず、ユーザーのログイン準備が整っていることを確認します。
いずれの場合も、初めてのログインでユーザーは新しいパスワードの入力を求められます。
-
次の手順では、シャドーパスワードが有効になっているシステム上でコマンド useradd juan を発行すると何が起こるのかを説明しています。
-
/etc/passwd内にjuanの新しい行が作成されます。この行は次のような特徴を持っています。-
ユーザー名
juanで始まる。 -
パスワードのフィールドに
xがあり、システムがシャドーパスワードを使用していることを示している。 -
499 より大きい数の UID が作成される。 (Red Hat Enterprise Linux 環境下では、 500 未満の UID 及び GID はシステムが使用するため保留される)
-
499 より大きい GID が作成される。
-
オプションの GECOS 情報は空白のままになっている。
-
juanのホームディレクトリは/home/juan/に設定される。 -
デフォルトのシェルは
/bin/bashに設定される。
-
-
/etc/shadow内にjuan用の新しい行が作成されます。この行には次のような特徴があります。-
ユーザー名
juanで始まる。 -
/etc/shadowファイルのパスワードフィールドには感嘆符が 2 つ表示され (!!)、これがこのアカウントをロックする。注記
-pフラグを使って暗号化されたパスワードが渡されると、/etc/shadowファイルのそのユーザーの新しい行に配置されます。 -
パスワードは失効期限無しに設定される。
-
-
/etc/group内にグループ名juanの新しい行が作成されます。ユーザーと同じ名前を持つグループは ユーザープライベートグループ と呼ばれます。ユーザープライベートグループについての詳細は、 項20.1.1. 「新規ユーザーを追加する」 を参照してください。/etc/groupに作成された行には次のような特徴があります。-
グループ名
juanで始まる。 -
パスワードフィールドに
xが表示され、システムがシャドーグループパスワードを使用していることを示す。 -
GID は
/etc/passwd内のユーザーjuanに記載されている番号と一致する。
-
-
/etc/gshadow内にグループ名juanの新しい行が作成されます。この行には次のような特徴があります。-
グループ名
juanで始まる。 -
/etc/gshadowファイルのパスワードフィールドに感嘆符が表示され (!)、これはグループをロックする。 -
その他フィールドはすべて空白になっている。
-
-
ユーザー
juanのディレクトリが/home/ディレクトリ内に作成されます。このディレクトリはユーザーjuanとグループjuanによって所有されます。ただし、 ユーザーjuanに対する読み取り、書き込み、実行の特権しかありません。その他のパーミッションは拒否されます。 -
/etc/skel/ディレクトリ (デフォルトのユーザー設定を格納している) 内のファイルが新しいディレクトリ/home/juan/にコピーされます。
この時点で、 juan というロックされたアカウントがシステム上に存在することになります。これをアクティブにするには、管理者が passwd コマンドを使ってアカウントにパスワードを割り当て、オプションでパスワードエージングのガイドラインを設定します。
表 20.4. 「標準的なユーザー」 では、 すべて を選択してインストールした場合の /etc/passwd ファイル内で設定されている標準ユーザーを一覧表示しています。この表の GID (グループid) はユーザーの プライマリグループ です。標準のグループの一覧に関しては、 項20.4. 「標準的なグループ」 を参照してください。
| ユーザー | UID | GID | ホームディレクトリ | シェル |
|---|---|---|---|---|
| root | 0 | 0 |
/root
|
/bin/bash
|
| bin | 1 | 1 |
/bin
|
/sbin/nologin
|
| daemon | 2 | 2 |
/sbin
|
/sbin/nologin
|
| adm | 3 | 4 |
/var/adm
|
/sbin/nologin
|
| lp | 4 | 7 |
/var/spool/lpd
|
/sbin/nologin
|
| sync | 5 | 0 |
/sbin
|
/bin/sync
|
| shutdown | 6 | 0 |
/sbin
|
/sbin/shutdown
|
| halt | 7 | 0 |
/sbin
|
/sbin/halt
|
| 8 | 12 |
/var/spool/mail
|
/sbin/nologin
|
|
| news | 9 | 13 |
/etc/news
|
|
| uucp | 10 | 14 |
/var/spool/uucp
|
/sbin/nologin
|
| operator | 11 | 0 |
/root
|
/sbin/nologin
|
| games | 12 | 100 |
/usr/games
|
/sbin/nologin
|
| gopher | 13 | 30 |
/var/gopher
|
/sbin/nologin
|
| ftp | 14 | 50 |
/var/ftp
|
/sbin/nologin
|
| nobody | 99 | 99 |
/
|
/sbin/nologin
|
| rpm | 37 | 37 |
/var/lib/rpm
|
/sbin/nologin
|
| vcsa | 69 | 69 |
/dev
|
/sbin/nologin
|
| dbus | 81 | 81 |
/
|
/sbin/nologin
|
| ntp | 38 | 38 |
/etc/ntp
|
/sbin/nologin
|
| canna | 39 | 39 |
/var/lib/canna
|
/sbin/nologin
|
| nscd | 28 | 28 |
/
|
/sbin/nologin
|
| rpc | 32 | 32 |
/
|
/sbin/nologin
|
| postfix | 89 | 89 |
/var/spool/postfix
|
/sbin/nologin
|
| mailman | 41 | 41 |
/var/mailman
|
/sbin/nologin
|
| named | 25 | 25 |
/var/named
|
/bin/false
|
| amanda | 33 | 6 |
var/lib/amanda/
|
/bin/bash
|
| postgres | 26 | 26 |
/var/lib/pgsql
|
/bin/bash
|
| exim | 93 | 93 |
/var/spool/exim
|
/sbin/nologin
|
| sshd | 74 | 74 |
/var/empty/sshd
|
/sbin/nologin
|
| rpcuser | 29 | 29 |
/var/lib/nfs
|
/sbin/nologin
|
| nsfnobody | 65534 | 65534 |
/var/lib/nfs
|
/sbin/nologin
|
| pvm | 24 | 24 |
/usr/share/pvm3
|
/bin/bash
|
| apache | 48 | 48 |
/var/www
|
/sbin/nologin
|
| xfs | 43 | 43 |
/etc/X11/fs
|
/sbin/nologin
|
| gdm | 42 | 42 |
/var/gdm
|
/sbin/nologin
|
| htt | 100 | 101 |
/usr/lib/im
|
/sbin/nologin
|
| mysql | 27 | 27 |
/var/lib/mysql
|
/bin/bash
|
| webalizer | 67 | 67 |
/var/www/usage
|
/sbin/nologin
|
| mailnull | 47 | 47 |
/var/spool/mqueue
|
/sbin/nologin
|
| smmsp | 51 | 51 |
/var/spool/mqueue
|
/sbin/nologin
|
| squid | 23 | 23 |
/var/spool/squid
|
/sbin/nologin
|
| ldap | 55 | 55 |
/var/lib/ldap
|
/bin/false
|
| netdump | 34 | 34 |
/var/crash
|
/bin/bash
|
| pcap | 77 | 77 |
/var/arpwatch
|
/sbin/nologin
|
| radiusd | 95 | 95 |
/
|
/bin/false
|
| radvd | 75 | 75 |
/
|
/sbin/nologin
|
| quagga | 92 | 92 |
/var/run/quagga
|
/sbin/login
|
| wnn | 49 | 49 |
/var/lib/wnn
|
/sbin/nologin
|
| dovecot | 97 | 97 |
/usr/libexec/dovecot
|
/sbin/nologin
|
表 20.4. 標準的なユーザー
表 20.5. 「標準的なグループ」 では、 すべて を選択したインストールで設定される標準のグループを一覧表示しています。グループは /etc/group ファイルに保存されています。
| グループ | GID | メンバー |
|---|---|---|
| root | 0 | root |
| bin | 1 | root, bin, daemon |
| daemon | 2 | root, bin, daemon |
| sys | 3 | root, bin, adm |
| adm | 4 | root, adm, daemon |
| tty | 5 | |
| disk | 6 | root |
| lp | 7 | daemon, lp |
| mem | 8 | |
| kmem | 9 | |
| wheel | 10 | root |
| 12 | mail, postfix, exim | |
| news | 13 | news |
| uucp | 14 | uucp |
| man | 15 | |
| games | 20 | |
| gopher | 30 | |
| dip | 40 | |
| ftp | 50 | |
| lock | 54 | |
| nobody | 99 | |
| users | 100 | |
| rpm | 37 | |
| utmp | 22 | |
| floppy | 19 | |
| vcsa | 69 | |
| dbus | 81 | |
| ntp | 38 | |
| canna | 39 | |
| nscd | 28 | |
| rpc | 32 | |
| postdrop | 90 | |
| postfix | 89 | |
| mailman | 41 | |
| exim | 93 | |
| named | 25 | |
| postgres | 26 | |
| sshd | 74 | |
| rpcuser | 29 | |
| nfsnobody | 65534 | |
| pvm | 24 | |
| apache | 48 | |
| xfs | 43 | |
| gdm | 42 | |
| htt | 101 | |
| mysql | 27 | |
| webalizer | 67 | |
| mailnull | 47 | |
| smmsp | 51 | |
| squid | 23 | |
| ldap | 55 | |
| netdump | 34 | |
| pcap | 77 | |
| quaggavt | 102 | |
| quagga | 92 | |
| radvd | 75 | |
| slocate | 21 | |
| wnn | 49 | |
| dovecot | 97 | |
| radiusd | 95 |
表 20.5. 標準的なグループ
Red Hat Enterprise Linux は ユーザープライベートグループ (UPG) 体系を使用しているので UNIX のグループ管理が楽になります。
UPG は新規のユーザーがシステムに追加される度に、生成されます。 UPG はそれが生成される元であるユーザーと同名を持っており、そのユーザーのみが UPG のメンバーです。
UPG の使用により、新規のファイルやディレクトリに対し安全にデフォルトの権限を設定することが可能なため、ユーザー及び そのユーザーのグループ の両者がそれらのファイルやディレクトリに修正を加えることができるようになります。
新規に作成されたファイルやディレクトリに対してどの権限を与えるかを決定する設定は umask と呼ばれ、 /etc/bashrc ファイル内で構成されています。伝統的に UNIX システムでは、 umask は 022 に設定されており、この設定では、ファイル又はディレクトリを作成したユーザー本人のみが変更できます。この体系下では、他のユーザーと ユーザーグループのメンバー でもそのユーザーのファイルは変更出来ません。しかし UPG 体系の中では、各ユーザーが自己のプライベートグループを持つ為、このグループ保護は必要ではありません。
多くの IT 組織は、主要プロジェクト毎にグループを作成し、そのプロジェクトのファイルにアクセスする必要のある人をグループに割り当てる傾向にあります。こうした従来のやり方でいくと、誰かがファイルを作成した場合に、それは属するプライマリグループと関連があるためファイルの管理が困難でした。1人の人間が複数のプロジェクトに従事する場合、正しいファイルを正しいグループと関連付けるのは難しくなります。しかし、 UPG 体系では、 setgid ビットセットを持つディレクトリ内で作成されたファイルに、グループが自動的に割り当てられます。ユーザーがあるディレクトリ内で作成するファイルはすべて、そのディレクトリを所有するグループにより所有される為、 setgid ビットの利用で、共通ディレクトリを共有するグループプロジェクトの管理が非常に簡単になります。
例としてあげると、あるグループが /usr/share/emacs/site-lisp/ ディレクトリ内のファイルで作業する必要があるとします。ディレクトリの修正に関して信頼できる人もいますが、全員が信頼できるわけではありません。最初に、 emacs グループを次のコマンドで作ります。
/usr/sbin/groupadd emacs
そのディレクトリの内容を emacs グループと関連づけるには次のように入力します。
chown -R root.emacs /usr/share/emacs/site-lisp
ここで gpasswd コマンドを使用してこのグループに正式なユーザーを追加することが可能になります。
/usr/bin/gpasswd -a <username> emacs
ユーザーに、ディレクトリ内でファイルを作成する権限を与えるには次のコマンドを使用します:
chmod 775 /usr/share/emacs/site-lisp
ユーザーが新しいファイルを作成すると、そのファイルのグループとしてユーザーのデフォルトであるプライベートグループが割り当てられます。次に setgid ビットを設定して、そのディレクトリに作成された全てにディレクトリ自身 (emacs) と同じグループ権限を割り当てます。次のコマンドを使用します。
chmod 2775 /usr/share/emacs/site-lisp
この時点で、各ユーザーのデフォルト umask が 002 であるために、ユーザーが新しいファイルを書き込む度に管理者がファイルの権限を変更することなく、 emacs グループの全てのメンバーは /usr/share/emacs/site-lisp/ ディレクトリ内でファイルを作成及び編集することができます。
マルチユーザー環境では、 シャドウパスワード (shadow-utils パッケージで提供) の使用がかなり重要になってきます。これによりシステム認証ファイルのセキュリティが強化されます。この理由でインストールプログラムはデフォルトでシャドウパスワードを有効にしています。
従来の UNIX ベースのシステムでパスワードを保存する方法より優れたシャドウパスワードの利点を以下の一覧で示します:
-
暗号化されたパスワードハッシュを全て読み取り可能な
/etc/passwdか root にしか読み取れない/etc/shadowに移動することでシステムセキュリティを向上。 -
パスワードエージングに関連する情報を保存。
-
/etc/login.defsファイルを使用してセキュリティポリシーを執行。
shadow-utils パッケージによって提供される殆どのユーティリティはシャドウパスワードが有効/無効に関係なく、正しく動作します。ただし、パスワードエージング情報が専用の /etc/shadow ファイルに収納されている為、パスワードエージング情報の作成や編集をするコマンドは動作しません。
最初にシャドウパスワードを有効にしないと動作しないコマンドを以下の一覧でしめします：
-
chage -
gpasswd -
/usr/sbin/usermod-e又は-fion > -
/usr/sbin/useradd-e又は-fオプション
ユーザーとグループについての詳細、及びユーザーとグループを管理するツールについては、次のリソースを参照してください。
-
関連の man ページ — ユーザーとグループの管理に関連する各種アプリケーションや設定ファイルに関する man ページが数多くあります。より重要な man ページの幾つかをここに示します:
- ユーザーとグループ管理アプリケーション
-
-
man chage— パスワードエージングのポリシーとアカウントの有効期限を変更するコマンドです。 -
gpasswd—/etc/groupファイルを管理するコマンドです。 -
man groupadd— グループを追加するコマンドです。 -
man grpck—/etc/groupファイルを検証するコマンドです。 -
man groupdel— グループを削除するコマンドです。 -
man groupmod— グループのメンバーシップを変更するコマンドです。 -
man pwck—/etc/passwdファイルと/etc/shadowファイルを検証するコマンドです。 -
man pwconv— 標準のパスワードをシャドウパスワードに変換するツールです。 -
man pwunconv— シャドウパスワードを標準のパスワードに変換するツールです。 -
man useradd— ユーザーを追加するコマンドです。 -
man userdel— ユーザーを削除するコマンドです。 -
man usermod— ユーザーを変更するコマンドです。
-
- 設定ファイル
-
-
man 5 group— システムのグループ情報が格納されているファイルです。 -
man 5 passwd— システムのユーザー情報が格納されているファイルです。 -
man 5 shadow— システムのパスワードとアカウントの有効期限情報が格納されているファイルです。
-
ユーザーは プリンタ設定ツール を使用してプリンタを設定することができます。このツールはプリンタ設定ファイル、印刷スプールディレクトリ、印刷フィルタ、プリンタクラスの管理に役立ちます。
Red Hat Enterprise Linux 5.2 uses the Common Unix Printing System (CUPS). If a system was upgraded from a previous Red Hat Enterprise Linux version that used CUPS, the upgrade process preserves the configured queues.
プリンタ設定ツール を使用するには root の権限が必要です。このアプリケーションを開始するには、 System (on the panel) => 管理 => 印刷 の順で選択するか、シェルプロンプトでコマンド system-config-printer を入力します。
以下のようなタイプの印刷キューを設定できます。
-
AppSocket/HP JetDirect — コンピュータにではなく、 HP JetDirect または Appsocket インターフェース経由でネットワークに直接接続されているプリンタ。
-
インターネット印刷プロトコル (IPP) — インターネット印刷プロトコル (IPP) を経由して TCP/IP ネットワーク上でアクセスできるプリンタ (例えば、ネットワーク上で CUPS を実行している別の Red Hat Enterprise Linux システムに接続されているプリンタ)。
-
LPD/LPR ホストまたはプリンタ — TCP/IP ネットワーク上でアクセスできる別の UNIX システムに接続されたプリンタ (例えば、ネットワーク上で LPD を実行している別の Red Hat Enterprise Linux に接続されているプリンタ)。
-
ネットワーク上の Windows (SMB) — SMB ネットワークでプリンタを共有する別のシステムに接続されているプリンタ (例えば、 Microsoft Windows™ マシンに接続されているプリンタ)。
-
ネットワーク上の JetDirect — コンピュータにではなく、 HP JetDirect 経由でネットワークに直接接続されているプリンタ。
Apply ボタンをクリックすると、設定した変更で再起動させるためにプリンタデーモンが表示されます。
戻る ボタンをクリックすると適用されていない変更を破棄します。
ローカルプリンタを追加するには、使用しているコンピュータのパラレルポートまたは USB ポート経由で接続されているプリンタと同じように、メインの プリンタ設定ツール ウィンドウにある 新規プリンタ ボタンをクリックして 図 21.2. 「プリンタの追加」 のようなウィンドウを表示させます。
進む をクリックして続けます。
プリンタ名 フィールドにプリンタ用の固有の名前を入力します。プリンタ名は文字、数字、ハイフン(-)、下線 (_) を含むことができます。 空白を含むことはできません。
説明 と 場所 フィールドを使ってさらにシステムに設定されている別のプリンタとこのプリンタを区別させることもできます。いずれのフィールドもオプションになり、また空白を含ませることができます。
進む をクリックして 新規プリンタ のダイアログを開きます (図 21.3. 「ローカルプリンタの追加」 を参照)。プリンタが自動的に検出されている場合は、そのプリンタモデルは 接続の選択 に表示されます。プリンタモデルを選択して 進む をクリックし続行します。
デバイスが自動的に表示されない場合、 接続の選択 でプリンタが接続されるデバイスを選択します (LPT #1、 Serial Port #1 など)。
次にプリンタの種類を選択します。詳細は 項21.5. 「プリンタモデルの選択と終了」 を参照してください。
IPP プリンタは同じ TCP/IP ネットワーク上にある別のシステムに接続されたプリンタです。このプリンタが接続されるシステムは CUPS を実行しているか単純に IPP を使用するよう設定されているかのどちらかです。
プリンタサーバーでファイアウォールを有効にしている場合、ファイアウォールは受信の UDP ポート 631 で送受信の接続を許可するよう設定する必要があります。クライアント (印刷要求を送るシステム)でファイアウォールを有効にしている場合、ファイアウォールはポート 631 を通じた接続で受信及び生成を許可される必要があります。
ネットワーク上の IPP プリンタを追加することができます。メインの プリンタ設定ツール ウィンドウ内の 新規プリンタ ボタンをクリックして 図 21.2. 「プリンタの追加」 のようなウィンドウを表示させます。 プリンタ名 (プリンタ名に空白を含ませることはできません。含ませることができるのは文字、数字、ハイフン (-)、下線 (_) のみ)、 説明、 場所 を入力し、システムで別のプリンタを設定する場合にこのプリンタと区別させます。 進む をクリックして続行します。
図 21.4. 「IPP プリンタの追加」 で示すウィンドウで、 IPP プリンタのホスト名を ホスト名 フィールドに、プリンタ用に固有の名前を プリント名 フィールドにそれぞれ入力します。
進む をクリックして続行します。
次にプリンタの種類を選択します。詳細は 項21.5. 「プリンタモデルの選択と終了」 を参照してください。
Samba (SMB) ベースのプリンタ共有を追加することができます。メインの プリンタ設定ツール ウィンドウにある 新規プリンタ ボタンをクリックして 図 21.2. 「プリンタの追加」 に示すようなウィンドウを表示します。 プリンタ名 フィールドにプリンタ固有の名前を入力します。プリンタ名には文字、数字、ハイフン (-)、下線 (_) を含ませることができますが、 空白は含ませることができません。
説明 と 場所 フィールドを使ってさらにシステムに設定されている別のプリンタとこのプリンタを区別させることもできます。いずれのフィールドもオプションになり、また空白を含ませることができます。
図 21.5. 「SMB プリンタの追加」 で示すように、使用可能な SMB 共有は自動的に検出され 共有 欄に表示されます。ワークグループの横にある矢印 (
) をクリックすると展開します。展開した一覧からプリンタを選択します。
さがしているプリンタが一覧に表示されない場合、 smb:// フィールドに SMB アドレスを入力します。 computer name/printer share の形式で入力してください。 図 21.5. 「SMB プリンタの追加」 では、 computer name は dellbox、 printer share は r2 になっています。
ユーザー名 フィールドには、プリンタにアクセスするユーザー名を入力します。このユーザーは SMB システム上に存在していなければならず、またこのプリンタへのアクセス権を有していなければなりません。デフォルトのユーザー名は、 Windows サーバーなら guest、 Samba サーバーなら nobody が一般的なユーザー名になります。
ユーザー名 フィールドに指定したユーザーの パスワード を (必要であれば) 入力します。
これで 確認 をクリックすると接続確認のテストを行うことができます。確認に成功すると、ダイアログボックスが表示されプリンタ共有へのアクセスが確認されます。
次にプリンタの種類を選択します。詳細は 項21.5. 「プリンタモデルの選択と終了」 を参照してください。
警告
Samba プリンタのユーザー名とパスワードは root 及び lpd によって読み取り可能な暗号化されていないファイルとしてプリンタサーバーに格納されます。したがって、プリンタサーバーに root アクセスを有するユーザーであれば他のユーザーが Samba プリンタへのアクセスに使用するユーザー名とパスワードを閲覧することができます。
このように、 Samba プリンタへのアクセスに使用するユーザー名とパスワードを選択する際は、ローカルの Red Hat Enterprise Linux システムへのアクセスに使用するものとは異なるパスワードを選択することをお勧めします。
また、 Samba プリンタサーバー上に共有されるファイルがある場合も同様にプリントキューで使用されるものとは異なるパスワードを使用することを推奨します。
JetDirect または AppSocket 接続プリンタ共有を追加するには、メインの プリンタ設定ツール ウィンドウで 新規プリンタ ボタンをクリックして 図 21.2. 「プリンタの追加」 に示すようなウィンドウを表示させます。 プリンタ名 フィールドにプリンタ固有の名前を入力します。プリンタ名には文字、数字、ハイフン (-)、及び下線 (_) を含ませることができますが、 空白を含ませることはできません。
説明 と 場所 フィールドを使ってさらにシステムに設定されている別のプリンタとこのプリンタを区別させることもできます。いずれのフィールドもオプションになり、また空白を含ませることができます。
進む をクリックして続行します。
次のオプションを持つテキストフィールドが表示されます：
-
ホスト名 — JetDirect プリンタのホスト名または IP アドレスになります。
-
ポート番号 — 印刷ジョブを監視する JetDirect プリンタのポートです。デフォルトでは 9100 になっています。
次にプリンタの種類を選択します。詳細は 項21.5. 「プリンタモデルの選択と終了」 を参照してください。
適切なプリンタキューのタイプを選択したら、次のいずれかのオプションを選択できます。
-
データーベースからプリンタを選択する - このオプションを選択する場合、 製造元 の一覧からプリンタの製造元を選択します。ご使用のプリンタの製造元が一覧にない場合は 汎用 を選択してください。
-
PPD ファイルを入力する - PostScript Printer Description (PPD) ファイルはプリンタによって 用意されることもあります。このファイルは通常、メーカーによって提供されています。 PPD ファイルがある場合には、このオプションを選択してオプション詳細の下にあるブラウザバーを使い PPD ファイルを選択することができます。
図 21.7. 「プリンタモデルの選択」 を参照してください。
オプションを選択したら、 進む をクリックして続行します。 図 21.7. 「プリンタモデルの選択」 が表示されます。 ここでプリンタに該当するモデルとドライバを選択する必要があります。
推奨のプリンタドライバーは、選択したプリンタモデルを元にして自動的に選択されます。プリンタドライバーは、印刷したいデータをプリンタが理解できる形式に処理します。ローカルプリンタは直接コンピュータに接続されているため、プリンタに送られるデータを処理するためのプリンタドライバーが必要になります。
デバイス用の PPD ファイルがある場合 (通常はメーカーによって提供される)、 PPD ファイルを提供する を選択してそのファイルを選ぶことができます。次に、 ブラウズする をクリックするとファイルシステム内で PPD ファイルの検索を行うことができます。
最後のステップはプリンタ設定の確認です。設定内容が正しければ 適用 ボタンをクリックして印刷キューを追加します。 戻る ボタンをクリックするとプリンタ設定を修正できます。
変更を適用したら、その設定が正しいかどうか確認するためにテストページを印刷します。詳細については 項21.6. 「テストページの印刷」 を参照してください。
プリンタを設定したら、プリンタが正常に機能していることを確認するためテストページを印刷してください。テストページを印刷するには、プリンタの一覧からプリンタを選択して、プリンタの 設定 タブから テストページの印刷 をクリックします。
プリンタドライバーを変更したり又は、ドライバーオプションを修正したりする場合、テストページを印刷して異なった設定をテストする必要があります。
既存のプリンタを削除するには、そのプリンタを選択してツールバーの 削除 ボタンをクリックします。プリンタ設定の削除を確認するとプリンタ一覧からこのプリンタは削除されます。
デフォルトのプリンタを設定するには、プリンタ一覧からプリンタを選択し 設定 タブの デフォルトのプリンタにする ボタンをクリックします。
プリンタドライバの設定を変更するには、 プリンタ 一覧内の該当名をクリックして 設定 をクリックします。
製造元とモデル、デフォルトのプリンタにする、テストページの印刷、デバイスの場所の変更 (URI) などさまざまなプリンタの設定を修正することができます。
印刷出力の設定を変更するには、 ポリシー タブをクリックします。
例えば、 バナーページ (送信元プリンタ、ジョブ発信元のユーザー名、印刷中ドキュメントのセキュリティ状態などの印刷ジョブの特徴を説明するページ) を作成するには、ドロップメニューの 開始バナー または 終了バナー をクリックして印刷ジョブの性質を最も適切に説明しているオプションを選択します (topsecret、 classified、 confidential など)。
また、ドロップダウンメニューからオプションを選択するとプリンタの エラーポリシー を設定することもできます。印刷ジョブの中断、再試行、停止を選択できます。
アクセス制御 タブをクリックすると設定プリンタへのユーザーレベルのアクセスを変更することができます。
テキストボックスを使ってユーザーを追加し、横にある 追加 ボタンをクリックします。次に、そのサブセットのユーザーに対してのみプリンタの使用を許可または拒否の選択をすることができます。
プリンタオプション タブにはプリンタメディア及び出力に関する各種の設定オプションがあります。
-
ページサイズ — 用紙サイズの選択ができます。 US Letter、 US Legal、 A3、 A4 などの選択オプションがあります。
-
メディアソース — デフォルトでは 自動 に設定されています。別のトレイの用紙を使用するにはこのオプションを変更します。
-
メディアタイプ — 用紙タイプの変更ができます。プレーン、厚紙、ボンド紙、 OHP などの選択オプションがあります。
-
解像度 — 印刷の画質やきめ細かさを設定します 300 ドット/インチ（dpi） がデフォルトです。
-
トナー節約 — トナー節約のためプリンタによる消費量を少くするかを選択します。
また、 ジョブオプション タブを使ってプリンタのジョブオプションを設定することもできます。ドロップメニューを使って 横長 モード (水平または垂直の印刷)、 両面、 拡大縮小 (印刷可能領域のサイズを拡大または縮小する、印刷領域を超えてしまうものを印刷媒体となる用紙などに合うよう縮小させる) など使用したいジョブオプションを選択します。
Emacs からのテキストファイル印刷や、 GIMP からのイメージ印刷など印刷ジョブをプリンタデーモンに送ると、ジョブはプリントスプールキューに追加されます。プリントスプールキューは、要求のステータス、ジョブ番号などプリンタに送られた印刷ジョブと各印刷要求の情報を持つ一覧です。
印刷のプロセス中、プリンタの状態アイコンがパネルの 通知エリア に表示されます。印刷ジョブの状態を確認するには、プリンタの状態をダブルクリップします。 図 21.12. 「GNOME 印刷状態」 のようなウィンドウが表示されます。
GNOME 印刷状態 に表示されている特定の印刷ジョブを取り消すには、一覧からそのジョブを選択しプルダウンメニューから 編集 => ドキュメントの取り消し を選択します。
シェルプロンプトでプリントスプールの印刷ジョブ一覧を表示するには、コマンド lpq を入力します。一覧の最後の方は次のような表示なります。
Rank Owner/ID Class Job Files Size Time active user@localhost+902 A 902 sample.txt 2050 01:20:46
例 21.1. lpq 出力の例
印刷ジョブを取り消す場合、コマンド lpq で取り消したいジョブ番号を見つけてから、次にコマンド lprm を使用します。例えば、 job numberlprm 902 は 例 21.1. 「lpq 出力の例」 に示すような印刷ジョブを取り消します。印刷ジョブを取り消すには適切な権限を持っている必要があります。プリンタが接続してあるマシン上で root としてログインしている場合以外は、他のユーザーが開始した印刷ジョブを取り消すことはできません。
シェルプロンプトから直接、ファイルを印刷することもできます。例えば、コマンド lpr sample.txt はテキストファイル sample.txt を印刷します。印刷フィルタがファイルの種類を判別し、プリンタに対応する形式に変換します。
Red Hat Enterprise Linux 環境での印刷に関する詳細は、以下のリソースを参照してください。
-
map lpr— コマンドラインからのファイル印刷を許可するlprコマンドのマニュアルページです。 -
man lprm— 印刷キューから印刷ジョブを削除するコマンドラインユーティリティのマニュアルページです。 -
man mpage— 1 枚の紙面に複数ページを印刷するコマンドラインユーティリティのマニュアルページです。 -
man cupsd— CUPS プリンタデーモンのマニュアルページです。 -
man cupsd.conf— CUPS プリンタデーモン設定ファイルのマニュアルページです。 -
man classes.conf— CUPS 用クラス設定ファイルのマニュアルページです。
-
http://www.linuxprinting.org — GNU/Linux Printingには、 Linux での印刷に関する大量の情報が含まれています。
-
http://www.cups.org/ — CUPS に付いてのドキュメント、良く有る質問、ニュースグループなどです。
Linux のタスクは、指定した日付の所定時間内に自動的に実行する、またはシステムの平均負荷が指定した値以下の場合に自動的に実行するよう設定することができます。 Red Hat Enterprise Linux は、重要なシステムタスクを実行して常にシステムを最新の状態に保つよう予め設定されています。例えば、 locate コマンドにより使用される slocate データベースは毎日更新されます。システム管理者は自動化タスクによって、定期的なバックアップ、システムのモニタ、カスタムスクリプトの実行などを行うことができます。
Red Hat Enterprise Linux にはいくつかの自動タスクユーティリティが用意されています。 cron 、 at 、 batch です。
Cron は、繰り返し行われるタスクを実行するためのデーモンで、時刻、日付、月、曜日、週の組み合わせに従ってタスクを実行します。
Cron は、システムが継続して稼動していることを前提としています。タスクの実行予定時にシステムが稼動していない場合、タスクは実行されません。1回きりのタスクをスケジュールする方法については、 項22.2. 「at コマンドと batch コマンド」 を参照してください。
cron サービスを使用するには、 vixie-cron RPM パッケージがインストールされ、 crond サービスを実行している必要があります。このパッケージがインストールされているか確認するには、 rpm -q vixie-cron コマンドを使用します。このサービスが実行されているか確認するには、 /sbin/service crond status コマンドを使用します。
cron のメイン設定ファイル /etc/crontab には次の行が含まれています。
SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ # run-parts 01 * * * * root run-parts /etc/cron.hourly 02 4 * * * root run-parts /etc/cron.daily 22 4 * * 0 root run-parts /etc/cron.weekly 42 4 1 * * root run-parts /etc/cron.monthly
最初の 4 行は、 cron タスクが実行される環境の設定に使用する変数です。 SHELL 変数は、システムが使用するシェル環境 （この例では bash シェル） を指定し、 PATH 変数はコマンドの実行に使用するパスを定義します。 cron タスクの出力は、 MAILTO 変数で定義されるユーザー名に電子メールにて送信されます。MAILTO 変数に空の文字列が定義されている場合 （MAILTO=""） 、電子メールは送信されません。 HOME 変数は、コマンドやスクリプトを実行する際に使用するホームディレクトリの設定に使用することができます。
/etc/crontab ファイル内の各行はそれぞれ1タスクに該当し、次の形式をとります。
分 時間 日 月 曜日 コマンド
-
minute— 0から59の整数 -
hour— 0から23の整数 -
day— 1から31の整数 （月を指定した場合はその月にある日付） -
month— 1から12の整数 （または jan や feb など月の短縮名） -
dayofweek— 0から7の整数。0や7は日曜を表す （または sun や mon など曜日の短縮名） -
command— 実行するコマンド (コマンドは、ls /proc >> /tmp/procのようなコマンドにするか、ユーザーが作成したカスタムスクリプトを実行するコマンドのいずれかにすることができます)
上記のいずれの値にも、アスタリスク （*） を使用すると、すべての有効な値が指定されます。たとえば、月の値にアスタリスクを使用すると、コマンドはその他の値による制約の範囲内で毎月実行されます。
整数間にハイフン （-） を使用すると、整数の範囲を指定できます。たとえば、 1-4 は、整数1、2、3、4を表します。
値をコンマ （,） で区切ると、値の一覧を指定できます。たとえば、 3, 4, 6, 8 はこれら4つの値を指定します。
スラッシュ （/） を使用すると、ステップ値を指定できます。範囲に /< を付けると、範囲内でその整数の値をスキップできます。たとえば 整数>0-59/2 とした場合、分フィールドにおける1分おきの間隔が定義されます。ステップ値は、アスタリスクと組み合わせることも可能です。たとえば、値 */3 を月フィールドで使用すると、3ヶ月ごとにタスクが実行されます。
先頭がシャープ記号 （#） の行はコメント行で処理の対象外です。
/etc/crontab ファイルが示すように、 run-parts スクリプトが /etc/cron.hourly 、 /etc/cron.daily 、 /etc/cron.weekly 、 /etc/cron.monthly のディレクトリ内のスクリプトをそれぞれ毎時間、毎日、毎週、または毎月ベースで実行します。これらディレクトリにあるファイルは、シェルスクリプトである必要があります。
毎時間、毎日、毎週、あるいは毎月の設定以外の予定で cron タスクを実行する必要がある場合、 /etc/cron.d/ ディレクトリに追加することができます。このディレクトリ内のファイルはすべて /etc/crontab と同じ構文を使用します。用例は、 例 22.1. 「crontab の例」 を参照してください。
# record the memory usage of the system every monday # at 3:30AM in the file /tmp/meminfo 30 3 * * mon cat /proc/meminfo >> /tmp/meminfo # run custom script the first day of every month at 4:10AM 10 4 1 * * /root/scripts/backup.sh
例 22.1. crontab の例
root 以外のユーザーが cron タスクを設定するには、 crontab ユーティリティを使用します。ユーザー定義の crontab はいずれも /var/spool/cron ディレクトリに保存され、これを作成したユーザーのユーザー名を使用して実行されます。1ユーザーとして crontab を作成するには、そのユーザーとしてログインしてから crontab -e コマンドを入力し VISUAL か EDITOR 環境変数で指定されたエディタを使用してユーザーの crontab を編集します。このファイルの形式は、 /etc/crontab ファイルと同じです。 crontab への変更が保存されると、crontab はユーザー名に従って保存され、ファイル /var/spool/cron/ に書き込まれます。
username
cron デーモンは、 etc/crontab ファイル、 etc/cron.d/ ディレクトリ、 /var/spool/cron ディレクトリを毎分チェックして変更がないかを確認します。変更が見付かれば、メモリにロードされます。したがって crontab ファイルを変更した場合でもこのデーモンを再起動する必要はありません。
/etc/cron.allow ファイルや /etc/cron.deny ファイルは、 cron へのアクセスを制限するために使用されます。どちらのアクセスコントロールファイルも、1行にユーザー名を1つという形式で記述されています。また、どちらのファイルも空白文字は使えません。これらのアクセスコントロールファイルを変更したときに、 cron デーモン （crond） を再起動する必要はありません。アクセスコントロールファイルはユーザーが cron タスクを追加したり、削除したりしようとするたびに読み込まれます。
アクセスコントロールファイルにリストされているユーザー名に関係なく、 root ユーザーはいつでも cron を使用できます。
ファイル cron.allow が存在する場合、このファイルに記載されているユーザーだけが cron を使用することができます。このとき、 cron.deny ファイルは無視されます。
cron.allow が存在しない場合、 cron.deny に記載されているユーザーは cron を使用できません。
cron は繰り返し行われるタスクをスケジュールするために使用されますが、 at コマンドは、指定した時刻に1度だけ行われるタスクをスケジュールするために使用されます。また、 batch コマンドはシステムの平均負荷が 0.8 を下回ったときに実行される1度限りのタスクをスケジュールするために使用されます。
at または batch を使用するには、 at RPM パッケージをインストールし、 atd サービスを実行しておく必要があります。このパッケージがインストールされているか確認するには、 rpm -q at コマンドを使用します。このサービスが実行しているか確認するには、 /sbin/service atd status コマンドを使用します。
指定した時刻に1度だけ実行されるジョブのスケジュールを設定するには、コマンド at を入力します。 timetime
引数 time は次のいずれかを指定できます。
-
HH:MM 形式 — 例えば、04:00 は 4:00 a.m を表します。その時刻がすでに過ぎてしまっている場合、次の日の同時刻に実行されます。
-
midnight — 12:00 a.m を表します。
-
noon — 正午 （12:00 p.m） を表します。
-
teatime — 4:00 p.m を表します。
-
month-name day year 形式 — たとえば、「January 15 2002」は 2002 年 1 月 15 日を表します。年は省略できます。
-
MMDDYY 、MM/DD/YY 、または MM.DD.YY 形式 — たとえば、「011502」は 2002 年 1 月 15 日を表します。
-
now + time — time は minutes （分）、 hours （時）、 days （日）、 weeks （週） などの単位で指定します。たとえば、「now + 5 days」はこのコマンドが今から5日後の同時刻に実行されることを表します。
最初に時刻を指定して、その次にオプションの日付を指定します。日付と時刻の書式については /usr/share/doc/at- テキストファイルを参照してください。
<version>/timespec
at コマンドに引数 time を付けて実行すると、 at> プロンプトが表示されます。実行するコマンドを入力し、 Enter キーを押して、 Ctrl-D キーを押します。複数のコマンドを指定する場合は、コマンドを1つ入力するたびに Enter キーを押します。コマンドをすべて入力したら、 Enter キーを押して空白行に移動、 Ctrl-D キーを押します。代わりに、プロンプトでシェルスクリプトを入力し、スクリプトで1行ごとに Enter キーを押し、空白行で Ctrl-D を押して終了することもできます。スクリプトを入力した場合、ユーザーの SHELL 環境で設定されたシェル、ユーザーのログインシェル、または /bin/sh のいずれかのシェルが使用されます (最初に見つかったシェル)。
標準出力に情報を表示するコマンドやスクリプトを入力した場合、この出力はユーザーに電子メールで送信されます。
保留ジョブを表示するには、 atq コマンドを使用します。詳細については 項22.2.3. 「保留ジョブの表示」 を参照してください。
at コマンドの使用法を制限することができます。詳細については 項22.2.5. 「at と batch へのアクセスの制御」 を参照してください。
平均負荷が 0.8 を下回ったときに、1度きりのタスクを実行するには、 batch コマンドを使用します。
batch コマンドを実行すると、 at> プロンプトが表示されます。実行するコマンドを入力し、 Enter キーを押して、 Ctrl-D キーを押します。複数のコマンドを指定する場合は、コマンドを1つ入力するたびに Enter キーを押します。コマンドをすべて入力したら、 Enter キーを押して空白行に移動し、 Ctrl-D キーを押します。代わりに、プロンプトでシェルスクリプトを入力し、スクリプトで1行ごとに Enter キーを押し、空白行で Ctrl-D を押して終了することもできます。スクリプトを入力した場合、ユーザーの SHELL 環境で設定されたシェル、ユーザーのログインシェル、または /bin/sh のいずれかのシェルが使用されます (最初に見つかったシェル) 。平均負荷が 0.8 を下回ると同時に、コマンドのセットまたはスクリプトが実行されます。
標準出力に情報を表示するコマンドやスクリプトを入力した場合、この出力はユーザーに電子メールで送信されます。
保留ジョブを表示するには、 atq コマンドを使用します。詳細については 項22.2.3. 「保留ジョブの表示」 を参照してください。
batch コマンドの使用法を制限することができます。詳細については 項22.2.5. 「at と batch へのアクセスの制御」 を参照してください。
保留されている at ジョブや batch ジョブを表示するには、 atq コマンドを使用します。 atq コマンドは保留になっているジョブを1行に1ジョブずつ表示します。各行は、ジョブ番号、日付、時間、ジョブのクラス、ユーザー名の形式をとります。ユーザーは自分のジョブしか見ることができません。 root ユーザーが atq コマンドを実行した場合は、すべてのユーザーのすべてのジョブが表示されます。
at や batch には、その他にも次のようなコマンドラインオプションがあります。
| オプション | 説明 |
|---|---|
-f
|
コマンドやシェルスクリプトはプロンプトで指定するのではなく、ファイルから読み込む |
-m
|
ジョブが完了したら、ユーザーに電子メールを送信する |
-v
|
ジョブが実行される時刻を表示する |
表 22.1. at と batch のコマンドラインオプション
/etc/at.allow ファイルや /etc/at.deny ファイルは、 at コマンドや batch コマンドへのアクセスを制限するために使用されます。どちらのアクセスコントロールファイルも、1行にユーザー名が1つという形式で記述されています。また、どちらのファイルも空白文字は使えません。これらのアクセスコントロールファイルを変更したときに、 at デーモン （atd） を再起動する必要はありません。アクセスコントロールファイルはユーザーが at コマンドや batch コマンドを実行しようとするたびに読み込まれます。
アクセスコントロールファイルにリストされているユーザー名に関係なく、 root ユーザーはいつでも at コマンドや batch コマンドを使用できます。
at.allow ファイルが存在する場合、このファイルに記載されているユーザーだけが at コマンドや batch コマンドを使用することができます。このとき、 at.deny ファイルは無視されます。
at.allow が存在しない場合、 at.deny に記載されているユーザーは、 at コマンドや batch コマンドを使用できません。
自動化タスクに関する詳細は、次のリソースを参照してください。
-
cronmanページ — cron の概要 -
セクション1と5の
crontabman ページ — セクション1の man ページには、crontabファイルの概要が説明されています。セクション 5 の man ページには、ファイル形式といくつかのエントリの例が示されています。 -
/usr/share/doc/at-には、 cron ジョブで指定できる時刻に関する詳しい情報が含まれています。<version>/timespec -
atman ページ —atコマンドとbatchコマンド、およびこれらのコマンドラインオプションの説明
ログファイル は、システム上で動作しているカーネル、サービス、アプリケーションなどのシステムに関するメッセージが入っているファイルです。情報ごとに異なるログファイルがあります。例えば、デフォルトシステムログファイル、セキュリティメッセージだけのログファイル、 cron タスク用のログファイルなどがあります。
ログファイルは、カーネルドライバをロードするなどで問題を解決しようとしているとき、システムに無許可のログインがあったかをさがすとき、などに大変役に立ちます。この章は、ログファイルの場所、ログファイルの見方、ログファイルで見るべき項目などについて説明します。
ログファイルのいくつかは syslogd と呼ばれるデーモンにより制御されています。 syslogd によって保管されているメッセージの一覧は /etc/syslog.conf 設定ファイルで見ることができます。
ほとんどのログファイルは /var/log/ ディレクトリ内に収まっています。 httpd や samba など のいくつかのアプリケーションは /var/log/ の中に専用ログファイル用の個別ディレクトリを持っています。
ログファイルディレクトリにある複数のファイルの後ろに番号が付いているのに注目してください。これらはログファイルが入れ換えられた時に生成されたものです。ログファイルは、ファイルサイズが大きくなり過ぎないように入れ換えられます。 logrotate パッケージは cron タスクを含んでいて、それが /etc/logrotate.conf 設定ファイルと /etc/logrotate.d/ ディレクトリにある設定ファイルに従ってログファイルを自動的に入れ換えます。デフォルトでは、毎週入れ換えて、過去4週間分のログファイルを保存するように設定されています。
ほとんどのログファイルはプレーンテキスト形式です。 Vi や Emacs など、どのテキストエディタでも表示することができます。ログファイルのいくつかはシステムのすべてのユーザーが読み込めますが、ほとんどのログファイルは、読み込むために root の権限が要求されます。
対話式によるリアルタイムのアプリケーションでシステムログファイルを表示するには、 システムログビューワ を使います。このアプリケーションを起動するには、 アプリケーション (パネルのメインメニュー) => システム => システムのログと進むか、シェルプロンプトでコマンド gnome-system-log を入力します。
このアプリケーションは存在するログファイルしか表示しません。このため、 図 23.1. 「システムログビューワ」 に示してある例とは異なるかもしれません。
選択したログファイルの内容をフィルターするには、メニューから 表示 をクリックして以下に示すように フィルタ を選択します。
フィルタ メニューアイテムを選択すると、 フィルタ のテキストフィールドが表示されフィルタに使用するキーワードを入力できるようになります。フィルタを消去にするには 消去 ボタンをクリックします。以下の図はフィルタの例になります。
一覧に表示させたいログファイルを追加するには、 ファイル => 開く の順で選択します。 ログを開く のウィンドウが表示され表示したいログファイルのディレクトリとファイル名を選択できるようになります。以下に ログを開く のウィンドウの例を示します。
開く ボタンをクリックしてファイルを開きます。ファイルが直ちに表示している一覧に追加され、そのファイルを選択すると内容を表示することができます。
システムログビューワではファイル名が ".gz" で終る圧縮ログを開くこともできます。
システムログビューワ はデフォルトで開いているすべてのログを監視します。監視されているログファイルに新しい行が追加されると、ログ名が太字でログ一覧に表示されます。ログファイルを選択または表示すると、ログファイルの最下段に太字で新しい行が表示され、 5 秒経過すると通常の形式で表示されます。以下の図ではこれを示しています。図では、 messages ログファイルに新しい警報が出ているため、ログファイルは太字で表示されています。
メッセージ ログファイルをクリックすると、以下のように新しい行が太字になっているファイル内のログを表示します。
新しい行は 5 秒間太字で表示された後、通常の表示形式に戻ります。
システム管理者がビジネスに影響するシステムサービス、又はデータをセキュアにする必要がある時はいつでも、 Red Hat Enterprise Linux は多種多様のツールと手段を総括的なセキュリティ政策の一部として提供します。
本章ではセキュリティ全般について、特に Red Hat Enterprise Linux を使用する上での全般情報について説明しています。セキュリティの査定、よくある不正アクセス、侵入やインシデントレスポンスに関するエリアについて概念的に説明しています。また、 SELinux 使用したワークステーション、サーバー、 VPN 、ファイアウォール、その他実装の強化方法について概念的な説明及び特定の設定に関して説明しています。
本章は、 IT セキュリティに関する基本的な知識を有しているユーザーを対象しているため、物理的なアクセスの制御、健全なアカウント維持ポリシー及び手順、監査などセキュリティ上の一般的な実践方法については最小限しか説明されていません。必要に応じて、外部リソースや関連情報を参照してください。
目次
- 24. セキュリティ概要
- 25. ネットワークの安全性を図る
- 26. セキュリティと SELinux
- 27. 参考文献
企業経営を支援し企業内各自の個人情報を記録する、強力にネットワーク化されたコンピュータへの信頼度が高まったため、企業体はネットワークとコンピュータセキュリティの実施を構成するようになってきました。企業はシステムや適合ソリューションを正しく監査し、企業の運営に必要とされる条件に合うようセキュリティ専門知識と技能を求めています。従事者が会社または組織の IT リソースにローカルにも遠隔的にもアクセスするので、ほとんどの企業や団体は事実上、動的な運営となります。これが理由で、安全なコンピュータ環境のニーズはより顕著になってきています。
しかし、ほとんどの企業や団体 (個人ユーザーも含めて) は、セキュリティを補足的なものと考えており、機能、生産性、予算関連の向上の方ばかりに目をとらわれがちです。適切なセキュリティの実施は 事後検討 (許可のない侵入が発生してしまった後) で行われています。セキュリティの専門家の一致した意見として、ほとんどの侵入試行を遮断する効果的な方法は、インターネットなどの信頼できないネットワークへ接続する前に適切な手段を講じることであると言われています。
コンピュータセキュリティは、コンピューティングや情報処理の広義をカバーする一般的な用語です。日々のビジネストランザクションを行ったり、重要な情報にアクセスするのにコンピュータシステムやネットワークに依存している業界は、そのデータは全ての資産の中の重要な一部であると認識されています。いくつかの用語やメトリックは、 Total Cost of Ownership (TCP) や Quality of Service (QoSoSなどの) 日々のビジネス用語が入っています。これらのメトリックにおいて、業界は、計画やプロセス管理のコストの一部としてデータ整合性や高可用性などの面を計算します。 E コマースなどの業界では、データの可用性や信頼性は、成功と失敗の違いになる可能性があります。
情報セキュリティは、個人、ファイナンシャル、およびその他の制限されている情報を開示しないようにパブリックのネットワークの信頼性を増すために、何年もかけて進化してきました。 Mitnick や Vladimir Levin 等の事例により、全ての業界の組織は情報の伝達や開示を行う方法について再考しました。インターネットの流行は、データセキュリティにおける強化を促進する最も重要な進歩の1つです。
多くの人々がパーソナルコンピュータを使用して、インターネットが提供する情報にアクセスするようになってきました。研究や情報検索から電子メールや商取引まで、インターネットは20世紀の最も重要な発展の1つとして認められています。
しかし、インターネットとその初期のプロトコルは、 trust-based システムとして開発されました。つまり、 Internet Protocol はそれ自信がセキュアなものとしてデザインされていませんでした。 TCP/IP 通信スタックに組み込まれた、認証されたセキュリティ標準などはなく、ネットワーク間で悪意のある可能性のあるユーザーやプロセスに開かれています。近年の開発によりインターネット通信がよりセキュアになってきましたが、依然として世界的に注目を集めたりする事件があり、完全に安全なものはないという事実を私達に警告します。
2000年2月、インターネットで最もトラフィックが多い、いくつかのサイトで、分散型 Denial of Service (DDoS) 攻撃がなされました。その攻撃により、 ping flood とも呼ばれる large-byte の ICMP パケット転送でルーターが塞がってしまったので、 yahoo.com、 cnn.com、 amazon.com、 fbi.gov、およびいくつかの他のサイトへは、一般ユーザーからは完全にアクセスできなくなりました。その攻撃は、知られていない攻撃者により持ちこまれ、ネットワークサービスの脆弱性をスキャンする特別に作成された広く入手可能なプログラムを使用して、 trojans と呼ばれるクライアントアプリケーションをサーバーにインストールし、感染した全てのサーバーが犠牲になったサイトを一斉攻撃し、それらを利用不可にしたのです。使用されているルーターやプロトコルが、場所や目的に関係なく送られたパケットの全ての着信データを受けつけるという基本的なフローへの攻撃を多くの人が非難しました。
現在のところ、およそ9億4500万人の人々が世界中でインターネットを使用しています (Computer Industry Almanac, 2004)。同時に:
コンピュータセキュリティは、全ての IT の予算で定量化と正当化できる出費になってきました。データ整合性と高可用性を要求する組織は、システム管理者、開発者、およびエンジニアのスキルを引き出し、システム、サービス、および情報の 24x7 の信頼性を確保します。悪意のあるユーザーや、プロセス、または同時攻撃などの犠牲になることは、組織の成功への脅威に結びつきます。
残念ながら、システムやネットワークのセキュリティは、組織がどのようにその情報をみなし、使用し、操作し、また転送するかという込み入った知識が必要とされるので、難しい提案になる可能性があります。組織がビジネスを実行する手法の理解 (および組織を作っている人々) が適切なセキュリティプランを実装する最優先事項です。
全ての業界の企業は、 American Medical Association (AMA) や Institute of Electrical and Electronics Engineers (IEEE) などの標準化を作る機関により設定された規則やルールに依存しています。同じことが情報セキュリティ当てはまります。多くのセキュリティコンサルタントやベンダーが、 CIA つまり Confidentiality, Integrity, and Availability として知られている標準セキュリティモデルに同意しています。この3層のセキュリティモデルは、繊細な情報のリスクを評価したり、セキュリティポリシーを確立したりする一般的に認識されたコンポーネントです。以下では、 CIA モデルの詳細について既述しています:
-
機密性 — 繊細な情報は、事前に定義された個人にのみ利用可能であるべきです。未承認の転送や情報の使用は制限されるべきです。例えば、情報の機密性は、顧客の個人的または財務上の情報は、 ID 盗難やクレジット詐欺などの悪意のある目的のために、承認されていない個人による入手はできないことを保証します。
-
整合性 — 情報は、それを不完全にしたり不正確にするように変更されるべきではありません。承認されていないユーザーは、繊細な情報を変更したり破壊したりする能力から制限するべきです。
-
可用性 — 情報はそれを必要としている承認されているユーザーからはいつでもアクセス可能にしておいてください。可用性は、情報が頻度や適時性で取り決められて入手できるという保証です。これは、しばしばパーセンテージで計算され、ネットワークサービスプロバイダやその顧客により使用される Service Level Agreement (SLA) で正式に同意されます。
コンピュータセキュリティは、一般的に コントロール として言及される3つの主要なカテゴリに分類されます:
-
Physical
-
Technical
-
Administrative
これらの3つの広いカテゴリは、適切なセキュリティ実装の主要な目的を定義します。これらのコントロール内にサブカテゴリがあり、そこでコントロールの詳細や、どのように実装するかを説明します。
Physical コントロールは、繊細なマテリアルへの未承認のアクセスを阻止したり遮断したりするのに使用される定義された構造でのセキュリティ対策の実装です。 Physical コントロールの例は以下の通りです:
-
クローズドサーキット監視カメラ
-
動作または熱アラームシステム
-
セキュリティガード
-
ピクチャ ID
-
ロックされた安全錠のスチールドア
-
バイオメトリック (指紋、声、顏、虹彩、手書き、および個人を認識するのに使用されるその他の自動化されたメソッド)
時間、リソース、そして動機があれば、クラッカーはほぼどのシステムにでも侵入することができるでしょう。結局現在利用可能なすべてのセキュリティ対策とテクノロジーをもってしても侵入に対してシステムが安全であることを保証することはできません。ルータはインターネットへのゲートウェイの安全を確保をするのに役立ちます。ファイアウォールはネットワークの末端の安全を確保するのに役立ちます。VPN(Virtual Private Network) は暗号化したストリームで安全にデータをやりとりすることができます。侵入検知システムは悪意ある活動に関して警告することができます。しかし、これらひとつひとつのテクノロジーが成功するかは次のような可変的な要素によります:
-
テクノロジーの設定、監視、管理などの責任があるスタッフの専門的知識
-
迅速且つ効率的にサービス及びカーネルにパッチをあて、更新する能力
-
責任を持ってネットワークの警戒を怠らないようにする能力
ダイナミックなデータシステムとテクノロジーを導入している企業で、その企業のリソースの安全を確保することはたいへん複雑なことでしょう。この複雑性ゆえに、すべてのシステムに対して熟達した人材をさがすのは大変なことかもしれません。情報セキュリティの多くのエリアで高いレベルの知識を持つ人材がいるかもしれませんが、2つまたは3つ以上の対象エリアでエキスパートとなるスタッフを持つのは難しいでしょう。情報セキュリティは常に流動しているため、情報セキュリティの各対象エリアを絶え間なく注意し監視することが要求されるからです。
企業ネットワークを管理していると仮定します。このようなネットワークは一般的にオペレーティングシステム、アプリケーション、サーバー、ネットワークモニター、ファイアウォール、侵入検知システム、その他で構成されます。これらのひとつひとつを最新の状態に保とうとしているとします。今日のソフトウェアやネットワーク環境の複雑さから、不正アクセスやバグは間違いなく存在します。ネットワーク全体のパッチと更新を最新の状態に保つことは、異種雑多のシステムを持つ大企業では気が重い作業となるでしょう。
専門的知識の必要条件と最新の状態に保つ作業を合わせると、逆のインシデントが起こる、システムが侵害される、データが改ざんされる、サービスが割り込まれるなどが避けられないことです。
セキュリティのテクノロジーを強化してシステム、ネットワーク、データの保護を促進するためには、クラッカーになったつもりで考えてみて、弱点をチェックすることでシステムのセキュリティを評価します。システムとネットワークリソースに対しての予防的な脆弱性の査定によって、クラッカーが攻撃してくる前に対処が可能な起こりうる問題を明らかにしてくれます。
自宅の脆弱性査定を実施しようとしたなら、おそらく、各ドアがきちんと閉まっていて鍵がかかっているかどうかを確認するでしょう。また、それぞれの窓を確認して、こちらもきちんと閉まっているか、掛け金をかけたかを確認するでしょう。これと同じ考え方をシステム、ネットワーク、電子データにも適用します。悪意あるユーザーは泥棒であり、心ないデータ破壊者です。彼らのツール、心理、動機をよく注意してみると、その行動に対して迅速に反応できるようになります。
脆弱性の査定は2つのタイプに別けることができます。外部からのルックインと内部のルックアラウンド です。
外部からのルックイン脆弱性査定の実施とは、外部からシステムを侵害しようと試みることです。企業に対する外部者になり、クラッカーの視点でとらえます。クラッカーが公的に見るところをさがします — ルート可能なIPアドレス、 DMZ にあるシステム、ファイアウォールの外部インターフェース、その他。 DMZ とは「demilitarized zone」(不戦地区)の略で、企業の プライベート LAN などの信頼できる内部ネットワークと、公共インターネットなどの 信頼できない外部ネットワークの間にあるコンピュータ又は小規模のサブネットワークに相当します。通常、DMZ には、 Web (HTTP )サーバー、FTP サーバー、SMTP (e-mail)サーバー、及びDNS サーバーなど、インターネット通信にアクセス可能なデバイスが含まれます。
内部ルックアラウンド脆弱性査定の実施では、実施者が内部者であり信頼できるステータスを与えられるので優位な立場になります。自分と同僚がシステムにログオンしている視点から見ることになります。プリントサーバー、ファイルサーバー、データベース、その他のリソースなどを見ます。
この 2つの脆弱性査定には顕著な違いがあります。企業の内部者としての査定は特権を与えられることになり、外部者と比べて優位になります。今日でもいまだほとんどの企業では、外からの侵入者を防ぐというような方法でセキュリティが設定されます。ところが、企業や組織の内部の安全を確保すると言う方法はほとんど採られていません(部門別ファイアウォール、ユーザーレベルのアクセス制御、内部リソースの認証手続き、その他)。概して、ほとんどのシステムは企業に対して内部側となるため、内部ルックアラウンドにはより多くのリソースが存在します。外部者として自分を設定したら、直ちに信頼できないというステータスが与えられます。外部から利用可能となるシステムとリソースは非常に限られてしまいます。
脆弱性の査定と侵入力テストの違いを考慮して下さい。。 脆弱性の査定を侵入力テストへの最初のステップと考えます。査定で拾い集めてきた 情報はテストをする時に使われます。査定が穴開きや可能性のある脆弱性をチェック するのに対し、侵入力テストは実際にこれらの調査結果に対して不正アクセスを 試みます。
ネットワークのインフラストラクチャ査定は動的なプロセスです。 セキュリティは、情報と物理的の両方とも、動的です。 査定の実施は、false positive と false negative で表される概要を表示します。
セキュリティ管理者の仕事は使用するツールや自分の知識に依存します。現在、利用可能な査定ツールは何でも利用して、システムで実行します。少なくともいくつかの疑似症状(false positive)があることがほぼ確実になります。プログラムの 欠陥かユーザーの誤りによるものか関係なく、結果は同じです。ツールは現実には存在しない(false positive)脆弱性を発見するかもしれません。また悪くすると、ツールが実際に存在する(false negative)脆弱性を発見しないかもしれません。
さて、脆弱性の査定と侵入力テストの違いが定義されたところで、新しい最適な実行手段としての侵入力テストを開始する前に、査定の結果を注意深く見直してみましょう。
警告
業務リソース上で脆弱性への不正アクセスを試みるのは、 システムとネットワークの生産性と効率性に対して逆効果となり得ます。
以下の一覧は脆弱性の査定を実施することで利点となることをいくつかあげています。
-
情報セキュリティに先を見越した焦点を作成する
-
クラッカーが見つける前に可能性のある不正操作を発見
-
システムが更新され、パッチが当てられた状態になります
-
スタッフの専門的知識の発達を促進、援助する
-
財政的な損失と否定的なパブリシティを緩和します
脆弱性の査定に関するツール選択を容易にするために、脆弱性の査定体系を確立することが役に立ちます。残念ながら、事前設定された体系または産業認可を受けた体系はいまのところありません。しかし、常識と実践のくり返しが十分な指針となっていくでしょう。
対象とは何ですか? １つのサーバーを対象としているのでしょうか。 それとも、ネットワーク全体とネットワーク内のすべてのものを対象としている のでしょうか。査定担当者は企業に対して外部者ですか、内部者ですか? これに対する答は、ツールの選択を決める手助けになる ばかりでなく、その使用方法などを決めるのにも役立つので重要です。
体系の確立についての詳細は以下のウェブサイトを参照してください。
-
http://www.isecom.org/projects/osstmm.htmThe Open Source Security Testing Methodology Manual (OSSTMM)(オープンソースセキュリティテスト手法マニュアル)
-
http://www.owasp.org/The Open Web Application Security Project (オープン Web アプリケーションセキュリティプロジェクト)
査定はなんらかの情報収集ツールを使用することからはじめられます。ネットワーク全体を査定するとき、レイアウトを最初にマップして実行中のホストを見つけます。見つけたら、それぞれのホストを個別に調べます。こうしたホストに焦点を置くには別のツール一式が必要となります。どのツールを使うべきかは、脆弱性を見つける上で最も重要なステップとなるでしょう。
日々の生活の中にも、同じ仕事を行う異なるツールがたくさんあります。脆弱性の査定を実施するのにも同じことが言えます。オペレーティングシステムやアプリケーションに対しても特定のツールがあり、ネットワーク(使用されるプロトコールに基づく)に対してさえ特定のツールがあります。無償のツールもあれば有償のものもあります。直感的で使いやすいツールもあれば、わかりずらく説明も少なくても、他のツールにない機能を持つツールもあります。
適切なツールを見つけるのは気が重くなりそうな仕事です。結局は経験が大切です。 できれば、テストラボを設置してできるだけ多くのツールを試して長所と短所を記録 します。ツールの README ファイルか man ページを復習します。加えて、論説、 ステップバイステップガイド、ツールに関する特定メーリングリストなどの詳細情報を インターネットで調べてください。
以下に解説するツールは利用できるツールの数種類のサンプリングにすぎません。
Nmap は Red Hat Enterprise Linux に入っているポピュラーなツールで、 ネットワークのレイアウトを決定するのに使われます。Nmap は長い間利用されてきており、恐らく、情報を収集するときのツールとして最もよく使われるものです。man ページにはこのツールのオプションや使用方法が詳細に説明されています。管理者はネットワーク上で Nmap を使用してホストシステムとそのシステム上のオープンポートを見つけることができます。
Nmap は脆弱性の査定において有力な最初のステップとなります。ネットワーク内のすべてのホストをマップすることができ、特定ホストで実行しているオペレーティングシステムの識別を試みるオプションを渡すこともできます。Nmap は、安全なサービスの使用、及び未使用サービスの停止についての方針を確立するための適切な基礎となります。
Nmap はシェルプロンプトで、nmapと入力し、その後スキャン するマシンのホスト名又は IP アドレスを入力することで実行できます。
nmap foo.example.com
スキャンの結果 (ホストが見つかった場所によって2分ほどかかることもある) は以下のように表示されます。
Starting nmap V. 3.50 ( www.insecure.org/nmap/ ) Interesting ports on localhost.localdomain (127.0.0.1): (The 1591 ports scanned but not shown below are in state: closed) Port State Service 22/tcp open ssh 25/tcp open smtp 111/tcp open sunrpc 443/tcp open https 515/tcp open printer 950/tcp open oftep-rpc 6000/tcp open X11 Nmap run completed -- 1 IP address (1 host up) scanned in 71.825 seconds
Nmap はサービスをリッスンしているか、又は待機中の最も一般的なネットワーク 通信ポートをテストします。この知識は、不必要、又は使用しないサービスを終了 したい管理者にとって役に立ちます。
Nmapの使用方法についての詳細は、次の URL にある 公式ホームページを参照してください。
Nessus は総合的なセキュリティスキャナーです。Nessus のプラグインアーキテ クチャでユーザーはこのスキャナーをシステムやネットワーク用にカスタマイズする ことができます。他のスキャナーと同様に、Nessus は依存する署名データベースに 左右されます。幸いにも、Nessus は頻繁に更新され、完全リポート、ホストスキャン、 リアルタイム脆弱性検索の機能を持ちます。Nessus 程に頻繁に強力で、頻繁に更新 されていても、false positive と false negative があるかもしれないので注意 してください。
注記
Nessus は Red Hat Enterprise Linux には含まれていませんので、サポートされません。ポピュラーなこのアプリケーションの使用に興味のあるユーザーの参考として このドキュメントに収納されていました。
Nessus の使用方法についての詳細は、次の URL にある公式 web サイトを参照して ください:
Nikto は共通ゲートウェイインターフェイスの優れた CGI スキャナーです。Nikto には CGI 脆弱性のチェック機能のみならず、侵入検知システムを逃れる回避的な挙動も チェックする機能を持ちます。詳細なドキュメントも附随しています。 プログラムを実行する前によくお読み頂くべきドキュメントが付帯しています。 CGI スクリプトをサービスできる Web サーバーを所有している場合は、Nikto が こうしたサーバーのセキュリティチェックに素晴しいリソースとなり得ます。
注記
Nikto は Red Hat Enterprise Linux には含まれていませんので、サポートされません。 ポピュラーなこのアプリケーションに興味のあるユーザーの参考としてこのドキュメントに収納されていました。
Nikto についての詳細は次の URL でご覧頂けます。
VLAD は Bindview, Inc. の RAZOR チームによって開発された 脆弱性スキャナーです。よくあるセキュリティ問題の SANS トップ10リスト 項目を チェックします(SNMP 問題、ファイル共有の問題、など)。Nessus ほど総合機能型では ありませんが、VLAD は検討に値します。
注記
VLAD は Red Hat Enterprise Linux には含まれませんので、サポートされません。ポピュラーなこのアプリケーションに興味のあるユーザーの参考としてこのドキュメントに収納されていました。
VLADについての詳細は次の URL にある RAZOR チームのウェブサイトでご覧頂けます。
対象やリソースに応じて使用できるツールはたくさんあります。ワイヤレスネット ワーク用のツール、Novell ネットワーク用のツール、Windows システム用、Linux システム用、その他のツールといろいろあります。査定を実施するにあたってさらに欠かせないことは、物理的なセキュリティ、人事の選別、ボイス/PBX ネットワーク査定などの見直しです。ワイヤレスネットワークの脆弱性に 関して企業の物理的なストラクチャ周辺部をスキャンする war walking などの新しい概念は、調査して、必要であれば査定に組み入れることができる新生の概念です。 脆弱性査定の立案や実施は、想像力と課題露呈のレベルによってのみ制限されるものです。
有効なセキュリティ対策を計画し実施するために、まず、しつこい攻撃者が不正アクセスをしシステムの感染をさせるいくつかの問題について知っておいてください。しかし、これら問題を詳述する前に、攻撃者を識別するときに使用する用語を定義しておく必要があるでしょう。
現代の ハッカー という言葉の意味はその語原を 1960 年代までさかのぼります。マサチューセッツ工科大学の技術モデル鉄道クラブが大規模で複雑な鉄道セットを設計しました。ハッカーとは、巧妙なトリックや問題の回避方法を見つけたクラブメンバーに対して使われていた名前でした。
これ以降、ハッカーという用語はコンピュータ狂から天才プログラマーまで幅広く使われるようになりました。ほとんどのハッカーにみられる一般的な特徴は、自力でコンピュータのシステムとネットワークがどのように機能するかを詳細に探求する意欲に満ちていることです。オープンソースソフトウェアの開発者はよく自分自身と仲間をハッカーとみなしており、敬意を表してこの単語を使用します。
一般的には、ハッカーは ハッカーの倫理 を守っています。ハッカーの倫理とは、情報と専門知識の探求は不可欠であること、この知識の共有はコミュニティに対するハッカーの義務であることとなっています。この知識探求で、コンピュータシステムのセキュリティコントロールの裏をかくことに学究的な意欲を燃やし楽しむハッカーもいます。理由は、マスコミが頻繁にハッカーと言う言葉を使用して、節操なく、悪意を持って、あるいは犯罪的な意図でシステムやネットワークに不正にアクセスする者達を表現するからです。こうしたコンピュータハッカーに対する的確な呼び名は、 クラッカー になります — 2 つのコミュニティを差別化するため 1980 年代の中頃にハッカーによって作られた造語。
システムやネットワークに脆弱性を発見して不正アクセスをする人々のコミュニティには、いくつか異なるグループがあります。これらのグループは、セキュリティ調査を行なう際に "かぶる" 帽子の色によってよく表現され、この色がそのハッカーの意図を表します。
ホワイトハットハッカー とは、ネットワークやシステムをテストしてパフォーマンスを調べ、侵入に対してどのように攻撃を受けやすいかを測定する人です。通例、ホワイトハットハッカーは自分のシステム、または顧客のシステムにクラッキング行為を行ないます。顧客とはセキュリティ監査の目的でホワイトハットハッカーを雇用した人または企業・団体です。学術研究員やセキュリティコンサルタントの専門家などがその例です。
ブラックハットハッカー はクラッカーの同意語です。一般的に、クラッカーはプログラミングやシステム侵入に関する学究的な側面にはあまり焦点をおいていません。多くの場合、クラッカーはクラッキングできるプログラムをあてにしています。システムの既知の弱点に不正アクセスして、個人的な利得のためにセンシティブな情報を暴露したり、あるいは目標のシステムやネットワークに損害を与えます。
一方、 グレイハットハッカー は、ほとんどの場合、ホワイトハットハッカーの技術と意図を有しますが、ときにはあまり立派でない目的に自分の知識を活用することもあります。グレイハットハッカーとは、自分の行動予定を達成するときにはブラックハットをかぶるホワイトハットハッカーと考えてよいでしょう。
グレイハットハッカーは概して異なるハッカー倫理を持っていて、それは窃盗を働いたり機密漏洩などの違反を犯さない限り、システムに侵入するのは許容範囲とするものです。これに関しては議論のあるところですが、システムへの侵入行為それ自体は非倫理的な行為です。
侵入者の意図が何であれ、クラッカーが不正アクセスしそうな弱点を知っておくことが重要です。以降、この点に焦点をあてて解説していきます。
ネットワークを設定する際に次のような例は攻撃の危険性を増加させる恐れがあります。
ネットワークの誤った設定は許可のないユーザーにとって主要なエントリポイントとなります。信頼しているローカルネットワークの弱点をまったく安全性に欠けるインターネットに開放したままにするのは、犯罪多発地帯でドアを半開きにしたままのようなものです — すぐには何も起こらないかもしれませんが、 いずれ 誰かがこの好機に不正アクセスしてきます。
システム管理者はよくセキュリティ体系におけるネットワーキングハードウェアの重要性の認識に欠けることがあります。ハブとルータのような単純なハードウエアはブロードキャストまたはノンスイッチの仕組みに依存します。つまり、ノードがネットワークを介して受信者となるノードにデータを送信するときは常に、受信者となるノードがデータを受け取り処理するまでハブまたはルーターはデータパケットのブロードキャストを送信します。この方法は、アドレス解決プロトコール (arp) またはメディアアクセスコントロール (MAC) に対する外部侵入者及びローカルノード上の無許可のユーザーいずれによるアドレススプーフィングにも最も攻撃を受けやすくなります。
もうひとつのネットワーキングの落し穴は集中化コンピューティングの採用です。さまざまな企業における一般的な経費削減手段としてすべてのサービスを単一の強力なマシンに統合整理する方法があります。この手段だと、管理が楽な上、複数サーバー構成に比べて大幅な経費削減となるため都合がよいわけです。しかし、集中化サーバーはネットワーク上に単一障害ポイントをもたらします。中枢サーバーが感染した場合、ネットワークを完全に役に立たなくしてしまうか、最悪の場合データの不正操作や盗難を行ないやすくしてしまう恐れがあります。こうした場合、ひとつの中枢サーバーが侵入口となり、ネットワーク全体へのアクセスを許可してしまうことになります。
サーバーセキュリティはネットワークセキュリティと同様に重要となります。サーバーは頻繁に企業や組織の極めて重要な情報を取扱うからです。サーバーが感染した場合、サーバー内のすべての内容をクラッカーが自由に盗んだり操作したりできるようになってしまう可能性があります。次のセクションでは主要な問題のいくつかを説明していきます。
Red Hat Enterprise Linux のフルインストールには 1000 余りのアプリケーションとライブラリパッケージが入っています。しかし、ほとんどのサーバー管理者は製品に含まれるパッケージすべてをインストールに選択することはありません。代わりに、数種類のサーバーアプリケーションを含む、パッケージ群のベースインストールを行ないます。
デフォルトのインストールに含まれているほとんどのサーバーアプリケーションはソフトウェアの細部までテストされているので強固な作りになっています。長年に渡り実稼働環境で使用されていくに従い、コードが入念に改良されて、多くのバグが発見され修正されてきました。
しかし、完璧なソフトウェアというのはあり得ません。常に、改良点と言うのはあるものです。さらに、新しいソフトウェアには期待するほど厳格にテストされないことがよくあります。なぜなら、実稼働環境に対して最近現われたばかりのソフトウェアであったり、その他サーバーソフトウェアほど一般的ではないかもしれないからです。
開発者とシステム管理者はサーバーアプリケーションによく不正アクセスのバグを発見し、 Bugtraq メーリングリスト ( http://www.securityfocus.com) やコンピュータ緊急対応チーム (CERT) のウェブサイト (http://www.cert.org) などのバグ追跡とセキュリティ関連のウェブサイトに情報を公表します。これらの仕組みはセキュリティの脆弱性に対してコミュニティに警告する効果的な方法ですが、早急にシステムにパッチをあてるかどうかはシステム管理者次第です。なぜなら、クラッカーも同様にこれら脆弱性追跡サービスにアクセスしており、その情報を使用してパッチしていないシステムがあればいつでもクラッキングを行なうためです。有能なシステム管理者は警戒心を怠らず、絶えずバグ追跡を行ない、より安全なコンピュータ環境を確保するために適切なシステムメンテナンスを行ないます。
システムを最新の状態に維持するための詳細は、 項24.5. 「セキュリティの更新」 を参照してください。
システムにパッチをあてることを怠る管理者は、サーバーセキュリティへの最も脅威となるもののひとつです。 System Administration Network and Security Institute (SANS) によれば、コンピュータのセキュリティ脆弱性の主要因は "訓練を受けていない人にセキュリティの保守を任せて、その仕事ができるようにするための時間もトレーニングも与えていないこと"です。 [8] これは不慣れな管理者によく見受けられるのと同様、自信過剰な管理者や積極性のない管理者にも見られます。
サーバーやワークステーションにパッチをあてることを怠る管理者もいれば、システムのカーネルやネットワーク通信からのログメッセージの監視を怠る管理者もいます。また、もうひとつ一般的な誤りは、サービスのデフォルトパスワードまたはデフォルト鍵を変更しないまま放置することです。例えば、デフォルトの管理パスワードを持っているデーターベースがありますが、これは、インストール後すぐにシステム管理者がパスワードを変更するだろうとそのデータベースの開発者が仮定しているためです。データベース管理者がこのパスワード変更を怠ると、経験のないクラッカーであっても周知のデフォルトパスワードを使ってデータベースへの管理用特権を獲得することができてしまいます。これらは管理者の不注意が糸口となってサーバーの感染につながるほんの 2、3 の例にすぎません。
選択したネットワークサービスが本質的に不安定であれば、どんなに用心深い企業や組織であっても攻撃を受けやすい犠牲者となるかもしません。例えば、信頼できるネットワークで使用されることを仮定して開発された多くのサービスがあります。しかし、そのサービスがインターネット上で利用可能になると、この仮定条件は該当しなくなってしまいます — つまり、インターネット自身が本質的に信頼できないからです。
あるタイプの不安定なネットワークサービスは認証に暗号化されていないユーザー名とパスワードを要求します。 Telnet と FTP がこの種のサービスになります。パケットスニフィングソフトウェアがリモートユーザーとこのようなサービス間の通信を監視している場合、ユーザー名やパスワードは簡単に傍受されてしまいます。
また、このようなサービスは本質的にセキュリティ業界用語で言うところの man-in-the-middle 攻撃の餌食になりやすいのです。このタイプの攻撃では、ネットワーク上でクラッキングされたネームサーバーをだましてネットワーク通信をリダイレクトし、意図されたサーバーの代わりにクラッカーのマシンにポイントします。誰かがそのサーバーにリモートセッションを開くと、攻撃者のマシンが目に見えないパイプの役割を果たし、リモートサービスと何も知らないユーザー間に静かに存在しながら、情報を捕えます。このようにして、クラッカーはサーバーにもユーザーにもそれと気づかれずに管理用パスワードと生データを収集することができます。
もうひとつの不安定なサービスには、 NFS や NIS などのネットワークファイルシステムとネットワーク情報サービスがあります。これは LAN 使用専用に開発されていますが、残念ながら WAN (リモートユーザー用)も含めるよう拡張されています。デフォルトでは NFS は、クラッカーが NFS 共有をマウントしてそこに格納されているものすべてにアクセスしてしまうことを防止するため構成される認証やセキュリティの仕組みがありません。同様に、 NIS は、パスワードやファイルのパーミッションなど、ネットワーク上のすべてのコンピュータが知らなければならない重要な情報をプレーンテキストの ACSII または DBM (ASCIIから派生) データベースで格納しています。クラッカーがこのデータベースにアクセス権を得ると、管理者用アカウントも含めネットワーク上のすべてのユーザーアカウントにアクセスすることができるようになります。
ワークステーションと家庭用 PC は、ネットワークやサーバーに比べると攻撃を受けにくい方かもしれません。しかし、クレジットカード番号などの機密情報を持っていることが多いので、システムクラッカーに狙われます。また、ワークステーションは知らぬ間に吸収され、一連の攻撃で "スレーブ" マシンとして攻撃者に使用されていることがあります。これらの理由で、ワークステーションの脆弱性を知ると、オペレーティングシステムの再インストール、悪くすればデータ盗難によるリカバリなどの頭痛の種から解放されることになります。
管理者が十分な安全対策とパッチをあてたサーバーを管理していたとしても、リモートユーザーがアクセスするときにも安全であると言う意味ではありません。例えば、サーバーが Telnet か FTP サービスをパブリックネットワークに提供する場合、攻撃者はネットワークを通過するプレーンテキストのユーザー名とパスワードを捕獲することができます。そこから、アカウント情報を使ってリモートユーザーのワークステーションにアクセスすることができます。
SSH などの安全なプロトコールを使用していても、リモートユーザーがクライアントアプリケーションを定期的に更新していない場合、特定の攻撃者から攻撃を受けやすいかもしれません。例えば、 v.1 SSH クライアントは悪意ある SSH サーバーからの X 転送攻撃に弱いなどです。サーバーに接続すると、攻撃者はネットワークを介してクライアントのキーストロークやマウスのクリックをそっと捕獲します。この問題は v.2 SSH プロトコールで修正されましたが、どのアプリケーションがこのような脆弱性を持ち、また必要に応じて更新していくかはユーザー次第となります。
表 24.1. 「よくある不正アクセス」 侵入者が組織的なネットワークリソースにアクセスするために使用するエントリポイントとよくある不正アクセスをいくつか説明します。これらの不正アクセスに対する重要ポイントは、どのように不正アクセスが行なわれるか、及びこのような攻撃に対して管理者が実施すべきネットワークの適切保護の理解です。
| 不正アクセス | 詳細 | 注記 | |||
|---|---|---|---|---|---|
| 空白またはデフォルトのパスワード | 管理用パスワードを空白のままにしたり、製品ベンダー設定のデフォルトパスワードをそのまま使用したりすることは、ルーターやファイアウォールなどのハードウェアで最もよく見られますが、 Linux 上で動作するサービスにはデフォルトの管理者用パスワードが入っているものがあるかもしれません (Red Hat Enterprise Linux 5 では、パスワードをつけたまま出荷していません)。 |
|
|||
| デフォルトの共有鍵 | 安全なサービスは時として、開発や査定テストの目的でデフォルトのセキュリティ鍵をパッケージにしていることがあります。これらの鍵を変更せずにインターネット上の実稼働環境で配置した場合、同じデフォルトの鍵を持つユーザーは 全て その共有鍵のリソースや、そこにあるすべての機密情報にアクセス権を有することになります。 |
|
|||
| IP Spoofing (なりすまし) | リモートマシンがローカルネットワーク上でノードとして動作し、サーバーに脆弱性を見つけて、ネットワークリソース全体に渡って制御を獲得するためにバックドアプログラムあるいはトロイの木馬をインストールしてしまいます。 |
|
|||
| 盗聴 | 2つのノード間接続を盗聴することによりネットワーク上でそのアクティブなノード間が交わすデータを収集することです。 |
|
|||
| サービスの脆弱性 | 攻撃者はインターネット上で実行するサービスの弱点や盲点を発見します。この脆弱性を利用して、攻撃者はそのシステム全体そして格納されているデータをすべて感染させ、ネットワーク上の他のシステムをも感染させる可能性があります。 |
|
|||
| アプリケーションの脆弱性 | 攻撃者はデスクトップやワークステーションのアプリケーション (電子メールクライアントなど) に欠点を見つけだし、任意のコードを実行して今後のシステム感染破壊活動のためトロイの木馬を移植します。感染したワークステーションがネットワークのその他のシステムに対して管理用の特権を持っていた場合、さらなる不正アクセスが進められてしまう恐れがあります。 |
|
|||
| サービス停止攻撃 (DoS=Denial of Service) | 単独攻撃者または複数人数によるグループ攻撃は、目標のホスト (サーバー、ルーター、ワークステーションいずれか) に許可のないパケットを送ることによって企業や組織のネットワークやサーバーリソースに対して攻撃を仕掛けます。これにより正当なユーザーに対してリソースが強制的に利用不能となります。 |
|
表 24.1. よくある不正アクセス
セキュリティの脆弱性が発見された場合、セキュリティ上の危険を最小限に抑えるために、影響を受けるソフトウェアを更新する必要があります。そのソフトウェアが Red Hat Enterprise Linux 製品に入っているパッケージの一部で、現在サポートされている場合、 Red Hat, Inc. では、できる限り早急に脆弱性を修正する更新パッケージをリリースすることに献身しています。多くの場合、特定のセキュリティ不正アクセスに関する告知にはパッチ (または問題を解決するソースコード) が付いています。このパッチをその Red Hat Enterprise Linux パッケージに適用します。パッチは Red Hat 品質保証チームによって検証され、エラータ更新としてリリースされています。もしも、告知にパッチが付いていない場合は、 Red Hat の開発者がそのソフトウェアのメインテナーと共に問題の解決にあたっています。問題解決後に、パッケージをテストして、エラータ更新としてリリースします。
システムで使用しているソフトウェア用のエラータ更新がリリースされたら、影響を受けるパッケージをできるだけ早く更新し、システムが攻撃を受けやすくなる期間を最小限に抑えることを強くおすすめします。
システムのソフトウェアを更新する場合は、信頼できるソースから更新をダウンロードすることが重要です。攻撃者は簡単に、問題を解決するはずのパッケージと同じバージョン番号を使いながら、これに別のセキュリティ不正アクセスを付けてパッケージを構築し直し、インターネットでリリースすることができます。こうした事態が発生した場合、オリジナルの RPM に対してファイルを検証するなどのセキュリティ手段では不正アクセスは検知されません。従って、Red Hat, Inc. などの信頼できるソースからのみ RPM をダウンロードし、パッケージの署名を確認してその整合性を確かめることが非常に重要となります。
Red Hat ではエラータ更新に関して 2 通りの取得方法を提供しています:
-
Red Hat Network でのエラータ一覧があり、ダウンロード可能
-
Red Hat エラータ web サイト上のエラータ一覧があり、リンクなし
注記
Red Hat Enterprise Linux 製品ラインでは、更新パッケージのダウンロードは Red Hat Network からのみになります。 Red Hat エラータウェブサイトで更新情報が掲載されますがダウンロードできる実際のパッケージはありません。
Red Hat Network ならほとんどの更新処理を自動化することができます。ご使用のシステムに必要な RPMパッケージを判定して、それらを安全なリポジトリからダウンロードしてきます。 RPM 署名を検証し、改変されていないか確認、それから更新します。パッケージのインストールはすぐに行なうこともできますが、一定の時間をおいてから行なうようスケジュールすることもできます。
Red Hat Network では更新する各マシンに システムプロフィール を 作成する必要があります。システムプロフィールにはシステムに関するハードウェアとソフトウェアの情報が含まれます。この情報は機密扱いとされ他の人に渡ることはありません。各システムに適用すべきエラータ更新を判定する目的のためだけに使用されます。この情報がないと Red Hat Network は任意のシステムに更新が必要かどうかを判定することができません。セキュリティエラータが(または、いずれの種類のエラータでも)リリースされると、 Red Hat Network はエラータの解説及び影響を受けるシステムの一覧を電子メールで送信します。更新を適用するには、Red Hat Update Agent を使用するか、ウェブサイト、 http://rhn.redhat.com からそのパッケージを更新するようスケジュールに入れます。
ヒント
Red Hat Enterprise Linux には Red Hat Network Alert Notification Tool が入っています。登録している Red Hat Enterprise Linux システム用の更新があると、視覚的な警告を表示してくれる便利なパネルアイコンです。このアプレットについての詳細は次の URL を参照してください。 https://rhn.redhat.com/rhn/help/quickstart.jsp
重要
セキュリティエラータをインストールする前に、必ず、エラータ報告に特別な指示があるか確認してよくお読みください。指示がある場合には、それに従って実行してください。エラータ更新による変更の適用についての全般的な解説は、 項24.5.1.5. 「変更を適用する」 を参照してください。
セキュリティエラータ報告がリリースされると、 Red Hat のエラータウェブサイト、 http://www.redhat.com/security/ で公表されます。このページからご使用のシステムの製品とバージョンを選択して、ページの上部にある セキュリティ を選択すると、Red Hat Enterprise Linux セキュリティアドバイザリーのみを表示します。いずれかのアドバイザリーの概要がシステムで使用しているパッケージについて記述している場合は、その概要をクリックすると詳細が見られます。
詳細ページには、セキュリティ不正アクセスについての解説と、セキュリティの欠陥を修正するパッケージ更新と同時に行なう必要がある特別の指示について記載されています。
更新されたパッケージをダウンロードするには、そのリンクをクリックして Red Hat Network にログインし、パッケージ名をクリックしてハードドライブに保存します。/tmp/updates など新しいディレクトリを作成して、ダウンロードしたすべてのパッケージはそこに保存することを強くお推めします。
すべての Red Hat Enterprise Linux パッケージは Red Hat, Inc. の GPG キーで署名されています。GPG とは GNU Privacy Guard または GnuPG の略で、配信ファイルの正真性を保証するために使用されるフリーソフトフェアパッケージです。例えば、 Red Hat が保持するプライベートキー (秘密鍵) はパッケージをロックし、パブリックキーはパッケージのロックを外して検証します。 Red Hat が 配信するパブリックキーが RPM 検証中にプライベートキーと合致しない場合、そのパッケージは変更が加えられている可能性があるため信用できません。
Red Hat Enterprise Linux の RPM ユーティリティは自動的に RPM パッケージの GPG 署名の検証を試みてからそれをインストールします。 Red Hat の GPG 鍵がインストールされていない場合は、 Red Hat Enterprise Linux インストール CD-ROM などの安全で静的な場所からインストールしてください。
CD-ROM が /mnt/cdrom にマウントされていると仮定して、次のコマンドを使い キーリング にインポートします (システムの信頼できる鍵のデータベース)。
rpm --import /mnt/cdrom/RPM-GPG-KEY
RPM 検証用としてインストールされたすべての鍵の一覧を表示するには、次のコマンドを実行します。
rpm -qa gpg-pubkey*
Red Hat 鍵の場合、出力は以下のようになります:
gpg-pubkey-db42a60e-37ea5438
特定の鍵についての詳細を表示するには、 rpm -qi コマンドを入力、その後に前のコマンドからの出力をつけます。
rpm -qi gpg-pubkey-db42a60e-37ea5438
RPM をインストールする前に、 RPM ファイルの署名の検証を行なうことは極めて重要なことです。これにより RPM のパッケージリリースに改変が加えられていないことを確認します。ダウンロードしたパッケージすべてを一度に検証するには、次のコマンドを発行します:
rpm -K /tmp/updates/*.rpm
各パッケージに対して GPG 鍵が検証に成功すると、このコマンドは gpg OK を返してきます。検証に失敗した場合は、正しい Red Hat パブリック鍵を使用しているか確認すると共に、コンテンツのソースも確認してください。 GPG 検証に失敗したパッケージはインストールしないでください。第三者によって変更が加えられている可能性があります。
GPG 鍵の検証とエラータ報告に関連するすべてのパッケージのダウンロードを終了したら、シェルプロンプトでルートとしてこれらのパッケージをインストールします。
次のコマンドを発行すると、ほとんどのパッケージのインストールを安全に行うことができます (カーネルパッケージを除く)。
rpm -Uvh /tmp/updates/*.rpm
カーネルパッケージの場合には、次のコマンドを使用します。
rpm -ivh /tmp/updates/<kernel-package>
上記の例にある <kernel-package> の部分には、カーネル PRM の名前を入れてください。
新しいカーネルを使用してマシンが安全にリブートされたら、次のコマンドを使用して古いカーネルを削除することができます。
rpm -e <old-kernel-package>
上記の例にある <old-kernel-package> は、古いカーネル RPM の名前を入れてください。
注記
古いカーネルを削除する必要性はありません。デフォルトのブートローダ GRUB では、複数のカーネルをインストールしてから、ブート時にメニューから選ぶことができます。
重要
セキュリティエラータをインストールする前に、必ず、エラータ報告に特別な指示があるか確認してよくお読みください。指示がある場合には、それに従って実行してください。エラータ更新による変更の適用についての全般的な解説は、 項24.5.1.5. 「変更を適用する」 を参照してください。
Red Hat Network、または Red Hat のエラータウェブサイトからセキュリティエラータをダウンロードしてインストールしたら、古いソフトウェアの使用を中止し、新しいソフトウェアの使用を開始することが大切です。どのようにするかは更新したソフトウェアの種類によります。以下の一覧では、ソフトウェアの全般カテゴリを項目別に分け、パッケージアップグレード後の更新バージョンの使用方法について説明します。
注記
全般的には、ソフトウェアパッケージの最新バージョンが使用されていることを確認するには、システムをリブートするのが一番確実な方法です。しかし、システム管理者の場合、常にこの方法がとれるとは限りません。
- アプリケーション
-
ユーザースペースアプリケーションとは、システムのユーザーが開始できるすべてのプログラムのことです。一般的に、このようなアプリケーションはユーザー、スクリプト、自動化タスクユーティリティなどによって起動されたときのみ使用され、持続し続けるものではありません。
こうしたユーザースペースのアプリケーションを更新したら、システムのアプリケーションすべてのインスタンスを中止し、もう一度そのプログラムを起動し直し更新したバージョンを使用します。
- カーネル
-
カーネルは Red Hat Enterprise Linux オペレーティングシステムの核となるソフトウェアコンポーネントです。カーネルはメモリ、プロセッサ、周辺機器などへのアクセスを管理する他、すべてのタスクをスケジュールします。
中心的な役割を果たすため、カーネルはコンピュータを停止せずには再スタートできません。したがって、カーネルの更新バージョンはシステムがリブートするまで使用できません。
- 共有ライブラリ
-
共有ライブラリは
glibcなどのコードのユニットで、複数のアプリケーションやサービスによって使用されます。共有ライブラリを利用しているアプリケーションは、一般的に、初期化されたとき共有コードを読み込むので、更新したライブラリを使用するアプリケーションはすべて停止して起動し直す必要があります。特定ライブラリに対してリンクする実行中のアプリケーションを見つけるには、次の例のように、
lsofコマンドを使用します。lsof /usr/lib/libwrap.so*このコマンドは、ホストアクセス制御用 TCP ラッパーを使用するプログラムで稼働中のプログラム一覧を返してきます。従って、
tcp_wrappersパッケージを更新した場合には、これでリストアップされたプログラムはすべて停止して再起動し直す必要があります。 - SysV サービス
-
SysV サービスは、ブートプロセスのあいだ起動される持続的サーバープログラムです。 SysV サービスの例としては、
sshd、vsftpd、xinetdなどがあります。こうしたプログラムは、たいていメモリ内でマシンがブートしているあいだずっと持続しているため、パッケージをアップグレードした後で、更新した各々の SysV サービスは停止して再起動する必要があります。これは、 Services Configuration Tool を使用して行なうか、又はシェルプロンプトでルートとしてログインして、次のように
/sbin/serviceコマンドを発行します:/sbin/service<service-name>restart上記の例にある
<service-name>の部分は、sshdなどのサービス名を入れてください。 -
xinetdサービス -
xinetdスーパーサービスに制御されているサービスは、アクティブな接続があるときのみ実行します。xinetdに制御されているサービスの例としては、Telnet 、 IMAP、 POP3 などがあります。こうしたサービスの新規インスタンスは、新しいリクエストを受信する度に
xinetdで起動されるため、アップグレード後の接続は更新されたソフトウェアで扱われます。しかし、xinetd制御のサービスをアップグレードするときにアクティブな接続があった場合は、古いバージョンで扱われます。xinetdが制御する特定サービスの古いインスタンスを停止するには、サービスのパッケージをアップグレードしてから現在実行中のプロセスすべてを停止します。プロセスが実行しているか確認するには、psコマンドを使用してから、killコマンドまたはkillallコマンドで現在のサービスのインスタンスを停止します。例えば、セキュリティエラータの
imapパッケージがリリースされた場合、パッケージをアップグレードしたら、シェルプロンプトにルートとして次のコマンドを入力します。ps -aux | grep imapこのコマンドはすべてのアクティブな IMAPセッションを返してきます。これから、個々のセッションを次のコマンドを発行して終了できます。
kill<PID>これでセッションを終了できない場合、次のコマンドを使用します:
kill -9<PID>上記の例にある
<PID>の部分は、 IMAP セッションのプロセス ID 番号 (psコマンドの２番目のコラム内に存在) で入れ替えます。すべてのアクティブな IMAPセッションを終了するには、次のコマンドを発行します。
killall imapd
Linux 環境のセキュリティはワークステーションから始まります。パーソナルマシンのロックにも、企業システムのセキュリティにも、建前なセキュリティポリシーは個々のコンピュータから始まると言って良いでしょう。つまるところ、コンピュータネットワークは、その最も弱いノードのセキュリティしか持たないことになります。
Red Hat Enterprise Linux ワークステーションのセキュリティを評価する場合、次の点を考慮します:
-
BIOS とブートローダのセキュリティ — 許可のないユーザーが物理的にマシンにアクセスし、シングルユーザーモードでブートする、またはパスワードなしにレスキューモードでブートすることができますか?
-
パスワードのセキュリティ — マシンのユーザーアカウントパスワードはどのくらい安全ですか?
-
管理制御 — 誰がシステム上にアカウントを有していますか、そしてどの程度の管理制御を持っていますか?
-
利用できるネットワークサービス — どのサービスがネットワークからの要求をリスニングしていますか、また、常時稼動していますか?
-
パーソナルファイアウォール — ファイアウォールがある場合、どの種類のファイアウォールが必要ですか?
-
セキュリティ強化された通信ツール — ワークステーション間での通信に使用すべきツール、使用すべきではないツールは?
BIOS (または、 BIOS に相当するもの) 及びブートローダのパスワード保護で、システムに物理的にアクセスできる許可のないユーザーが、リムーバブルメディアを使用してブートしたり、シングルユーザーモードで root 権限を取得してブートするのを防ぐことができます。セキュリティ対策として、ワークステーションが保持する情報の機密度やマシンの設置場所の両方に従って、このような攻撃に対して防護するものを採用します。
例えば、マシンがトレードショーで使用されるため機密情報が保存されていない場合は、このような攻撃を防止することは重要なことにはならないかもしれません。しかし、会社のネットワーク用にプライベートで暗号化されていない SSH キーを持っている雇用者のノートブック型 PC を、そのトレードショーで放置した場合、会社全体のあらゆる部署に大きなセキュリティ侵害を招く結果となり得ます。
一方、許可のある人や信頼できる人しかアクセスできない場所にワークステーションが配置されている場合、 BIOS やブートローダにセキュリティを施行する必要はないかもしれません。
以下に、コンピュータの BIOS を保護するパスワードに関する 2 つの主な理由を示します [9]:
-
BIOS 設定への変更を防止する — 侵入者が BIOS にアクセスした場合、ディスケットや CD-ROM からブートすることができます。これにより、侵入者はレスキューモードないしはシングルユーザーモードで入り込むことが可能になり、そしてシステムに勝手なプログラムを埋めこんだり、機密データをコピーすることができるようになってしまいます。
-
システムのブートを防止する — BIOS のなかには、ブートプロセスのパスワード保護ができるものがあります。起動すると、攻撃者は BIOS がブートローダを起動する前にパスワードの入力を強要されます。
BIOS パスワードの設定方法についてはコンピュータのメーカーにより異なるため、特定の説明についてはコンピュータのマニュアルを参照してください。
BIOS パスワードを忘れてしまった場合、マザーボード上のジャンパでリセットするか、 CMOS バッテリを取り外すことができます。このため、できればコンピュータケースをロックするようにした方がよいでしょう。ただし、 CMOS バッテリを外す前に、コンピュータまたはマザーボードのマニュアルを参照してください。
以下に、 Linux ブートローダを保護する為のパスワードの主な理由を示します:
-
シングルユーザーモードヘのアクセスを防止する— 攻撃者がシングルユーザーモードでブートできる場合、 root パスワードを要求されずに自動的に root ユーザーとしてログインできます。
-
GRUB コンソールヘのアクセスを防止する — マシンが GRUB をそのブートローダとして使用する場合、攻撃者は GRUB エディタインターフェースを使用してその設定を変更したり、
catコマンドを使って情報を収集することができます。 -
セキュアでないオペレーティングシステムへのアクセスを防止する — デュアルブートシステムである場合、攻撃者はブート時にアクセス制御やファイルパーミッションを無視するオペレーティングシステム (例： DOS など) を選択することができます。
x86 プラットフォーム用に Red Hat Enterprise Linux で配付される GRUB ブートローダ。 GRUB の詳細については、 Red Hat インストレーションガイドを参照してください:
GRUB は、その設定ファイルにパスワードディレクティブを追加すると、 項25.1.2.2. 「ブートローダのパスワード」 に記載されている最初の 2 つの問題に対処します。これを行なうには、まず強固なパスワードを決め、シェルプロンプトを開きます。 root としてログインして次のコマンドを入力します:
/sbin/grub-md5-crypt
パスワードを要求されたら、 GRUB パスワードを入力して エンター を押します。パスワードの MD5 ハッシュを返してきます。
次に、 GRUB の設定ファイル /boot/grub/grub.conf を編集します。ファイルを開き、ドキュメントのメインセクションにある timeout 行の下に次の行を追加します。
password --md5 <password-hash>
<password-hash> には、 /sbin/grub-md5-crypt で返された値を入れます。 [10]
次回システムが起動すると、 GRUB メニューは、最初に p を押してその後に GRUB パスワードを入れないと、エディタやコマンドインターフェースへのアクセスを許可しなくなります。
残念ながら、このソリューションでは、デュアルブート環境でのセキュアではないオペレーティングシステムへ攻撃者がブートするのを防止しません。このため、 /boot/grub/grub.conf ファイルの別の部分を編集する必要があります。
セキュアにしたいオペレーティングシステムの title 行を探して、そのすぐ下に lock という行を追加します。
DOS システムなら、節は次のように始まります:
title DOS lock
警告
この方法が正常に機能するためには、 password 行が /boot/grub/grub.conf ファイルのメインセクションに表示されていなければなりません。これがないと、攻撃者は GRUB エディタインターフェースにアクセスして lock 行を削除できることになります。
特定のカーネルまたはオペレーティングシステム用に別のパスワードを作成するには、その節に lock 行とその後にパスワード行を付けて追加します。
固有のパスワードで保護された各節は、以下の例のような始まりになります:
title DOS lock password --md5 <password-hash>
パスワードは、 Red Hat Enterprise Linux がユーザー識別を検証する主要な手段です。これはパスワードセキュリティがユーザー、ワークステーション、ネットワークの保護にとって非常に重要であることの理由です。
セキュリティの目的で、インストールプログラムはシステムが メッセージダイジェストアルゴリズム (MD5) とシャドーパスワードを使用するよう設定します。これらの設定を変更しないようお願いいたします。
MD5 パスワードがインストール中にはずされる場合、古い Data Encryption Standard (DES) 形式が使われます。この形式はパスワードを 8 文字の英数字パスワードに制限し (句読点及び他の特殊文字は受け付けない)、適度な 56 ビットレベルの暗号化を提供します。
シャドーパスワードがインストール中に外される場合、すべてのパスワードは world-readable な /etc/passwd ファイルに一方向ハッシュとして格納されます。オフラインのパスワードクラッキング攻撃に対してシステムが攻撃を受けやすくなります。侵入者が正規のユーザーとしてマシンヘのアクセス権を取得した場合、 /etc/passwd ファイルを自分のマシンにコピーしてこれに何度でもパスワードクラッキングプログラムを実行することができるようになります。ファイルにセキュアではないパスワードがある場合、パスワードクラッカーがそれを発見するのは時間の問題です。
シャドーパスワードは、パスワードハッシュを /etc/shadow ファイルに格納して、この種の攻撃を排除します。これは、 root ユーザーによってのみ読み取り可能です。
これにより、攻撃者は SSH や FTP などマシン上のネットワークサービスにログインして遠隔からパスワードをクラックしようとします。この種の brute-force (総当たり) 攻撃は非常に緩慢で、数多くのログイン試行の失敗がシステムファイルに書き込まれるといった明らかな痕跡を残します。もちろん、攻撃者がいくつものパスワードを使って深夜にシステム攻撃を開始した場合には、夜明けまでにはアクセス権を取得して痕跡を消すためにログファイルを編集してしまう可能性もあります。
形式や格納以外にも、内容が問題となります。ユーザーがパスワードクラッキング攻撃に対してアカウントを守ることができる唯一最も重要なことは、強固なパスワードを作成することです。
堅固なパスワードを作成する際は、次のようなガイドラインに従うとよいでしょう。
-
単語または数字だけを使わない — パスワードに数字だけ、または単語だけを使用しないようにしてください。
次のような例は危険です:
-
8675309
-
juan
-
hackme
-
-
わかりやすい単語は使わない — 固有名、辞書にあるような単語、テレビ番組や小説に出て来るような言葉などは避けてください。これらの末尾に数字を付けただけのものも使用しないでください。
次のような例は危険です:
-
john1
-
DS-9
-
mentat123
-
-
外国語の単語を使わない — パスワードクラッキングプログラムは、数多の言語の辞書に含まれた単語リストでチェックします。堅固なパスワードとして外国語に頼っても意味がありません。
次のような例は危険です:
-
cheguevara
-
bienvenido1
-
1dumbKopf
-
-
ハッカー用語を使わない — パスワードにハッカー用語 —l337 (LEET) とも呼ばれる — を使えるからエリートだと考えるなら、もう一度考えなおしてみてください。多くの単語一覧には LEET が含まれています。
次のような例は危険です:
-
H4X0R
-
1337
-
-
個人情報を使わない — パスワードには個人の情報は一切使わないでください。攻撃者がユーザーの身元を知っている場合、パスワードを推測するのはより簡単なことになります。パスワードを作成する際に避けるべき情報の種類を以下に一覧表示します:
次のような例は危険です:
-
ユーザーの名前
-
ペットの名前
-
家族の名前
-
誕生日
-
ユーザーの電話番号や郵便番号
-
-
わかりやすい単語を逆さにして使わない — 優秀なパスワードチェッカーは常に一般的な単語を逆さにしてみますから、悪い例のパスワードを逆さにしても堅固なパスワードにはなりません。
次のような例は危険です:
-
R0X4H
-
nauj
-
9-DS
-
-
パスワードを記録しない — 紙などにパスワードを書いておかないようにしてください。記憶しておく方がずっと安全です。
-
すべてのマシンに同じパスワードを使わない — それぞれのマシンごとに異なるパスワードを作成することが重要です。この方法だと、ひとつのシステムが感染しても、他のマシンがすぐには危険な状態になりません。
以下のガイドラインを使用すれば、強靭なパスワードの作成を手伝ってくれます:
-
パスワードは少くとも 8 文字の長さにする — パスワードが長ければ長いほど堅固です。 MD5 パスワードを使う場合は、 15 文字以上にしてください。 DES パスワードの場合は最大長にします (8文字)。
-
大文字と小文字を組み合わせる — Red Hat Enterprise Linux は大文字と小文字を区別するので、パスワードの強度を高めるために大文字と小文字を組み合わせて使います。
-
文字と数字を組み合わせる — パスワードに数字を入れると、特に中間に入れると (先頭または末尾ではなく) 、パスワードの強度が増します。
-
英数字以外の文字を入れる — & や $ や > などの特殊文字がパスワードの強度を大幅に向上させます (DES パスワードを使用する場合は不可)。
-
憶えられるパスワードを選ぶ — どんなに堅固なパスワードであっても憶えられなければ役に立ちません。略語や憶えやすいデバイスを使ってパスワードを忘れないようにします。
これらすべてのルールを考慮して、悪い例のパスワードを使わないようにしながら、これらの基準すべてに合うようして、堅固なパスワードを作成するのは難しいことのように思えます。しかし幸運にも、憶えやすい堅固なパスワードを生成することができる手順があります。
堅固なパスワードを作成するのに使われる方法は数多くあります。なかでも人気のある方法のひとつが略語です。例えば:
-
憶えやすい言回しを使います。例えば:
"over the river and through the woods, to grandmother's house we go. (小川を渡り、木々の間を抜け、おばあちゃんの家へ行くんだ)"
-
次に、略語に変換します (句読点を入れる)。
otrattw,tghwg. -
略語の文字を数字やシンボルに置き換えて複雑にします。例えば、
7をtの代わりに置き換えて、@をaの代わりに置き換えます:o7r@77w,7ghwg. -
さらに複雑にするために、少くとも 1 文字を大文字に変えます、例えば
Hなど。o7r@77w,7gHwg. -
最後に、上記に紹介したパスワードの例をそのまま使わないでください。
堅固なパスワードを作成することは避けられないことですが、そのパスワードを適切に管理することも重要です。大規模の企業におけるシステム管理者にとっては特に重要になります。次のセクションでは、企業においてユーザーのパスワードを作成/管理するための実践について説明していきます。
企業内にかなりの数のユーザーがいる場合、システム管理者にとって強固なパスワードを使用させるための 2 つの基本オプションがあります。管理者がユーザーのパスワードを作成する、またはユーザーに自分のパスワードを作成させ、その後そのパスワードが条件を満たすものになっているか確認します。
ユーザーの代わりにパスワードを作成すると確実にパスワードを堅固なものにできますが、企業が大きくなるにつれ厄介な作業となってきます。また、ユーザーがそのパスワードをどこかに書き留めてしまう危険も増します。
これらの理由から、システム管理者はユーザーに自分のパスワードを作成させる方を好みますが、積極的にパスワードが堅固であるか確認し、場合によっては、一定期間経過したパスワードはパスワードエージングで定期的に変更させるようにします。
侵害行為からネットワークを守るためには、システム管理者が企業内で使用されているパスワードが堅固であることを確認するとよいでしょう。ユーザーがパスワードを作成/変更するよう求められたとき、コマンドラインアプリケーションの passwd を使うことができます。これは、 Pluggable Authentication Manager (PAM) 認識であるため、 pam_cracklib.so PAM モジュールを使ってパスワードがクラックされやすいか、または短すぎないかを確認します。この確認は、 pam_cracklib.so PAM モジュールを使用して実行されます。 PAM はカスタマイズが可能であるため、 pam_passwdqc (http://www.openwall.com/passwdqc/ で入手可能) などのパスワード整合性チェッカーをさらに追加したり、新しいモジュールを書くことも可能です。利用できる PAM モジュールの一覧については、 http://www.kernel.org/pub/linux/libs/pam/modules.html をご覧ください。 PAM についての詳細は、 項25.4. 「PAM（Pluggable Authentication Modules）」 を参照してください。
パスワードの作成時に行なわれるチェックは、そのパスワードにパスワードクラッキングプログラムを実行するのと同様の効率で、悪いパスワードを発見するわけではないことに注意してください。
Red Hat Enterprise Linux 稼動環境下で動作するパスワードクラッキングプログラムは数多くありますが、オペレーティングシステムと共に配付されているものはありません。以下に人気のあるパスワードクラッキングプログラムのいくつかを簡単な一覧にして示します:
注記
これらのいずれのツールも Red Hat Enterprise Linux には添付されていません。その理由で Red Hat, Inc. でのサポートはありません。
-
John The Ripper — 高速で柔軟なパスワードクラッキングプログラムです。複数の単語リストの使用が可能で、 brutee-force (総当たり) パスワードクラッキングの機能を備えています。オンラインの http://www.openwall.com/john/ で入手可能です。
-
Crack — 恐らく、最もよく知られているパスワードクラッキングソフトウェアです。 Crack も高速ですが、 John The Ripper ほどに使い勝手は簡単ではありません。オンラインの http://www.crypticide.com/users/alecm/ でご覧ください。
-
Slurpie — Slurpie は John The Ripper や Crack に似ていますが、複数のコンピュータ上で同時に作動するようデザインされています。配信されているパスワードクラッキング攻撃を作成します。配信されている多くの攻撃セキュリティ評価ツールとともにオンラインの http://www.ussrback.com/distributed.htm にあります。
警告
社内でパスワードをクラックする前に、必ず文書で許可をとってください。
パスワードエージングはシステム管理者が企業内の悪いパスワードに対して保護の為に使用するもう１つの技術です。パスワードエージングとは、設定した時間 (通常は90日間) を過ぎると、ユーザーが新しいパスワードの作成を求められるものです。背後にある理論は、ユーザーに定期的にパスワードの変更を強制すると、クラックされたパスワードは侵入者にとって限られた時間内でしか役に立たないということです。ただし、パスワードエージングの否定的な面としては、ユーザーがパスワードをどこかに書き留めてしまう可能性があるということです。
Red Hat Enterprise Linux 稼動環境下でパスワードエージングの指定に使われている主要なプログラムには、 chage コマンドとグラフィカルな User Manager (system-config-users) アプリケーションの2つがあります。
chage コマンドの -M オプションは、パスワード有効期間の最大日数を指定します。例えば、ユーザーのパスワードの有効期間が90日で切れるように設定するには、次のコマンドを使用します:
chage -M 90 <username>
上記のコマンドで、 <username> には、ユーザーの名前を入れます。パスワード有効期間の機能を無効にするには、従来通り、 99999 の値を -M の後に使います (ほぼ 273 年余りの有効期限になる) 。
インタラクティブモードで chage コマンドを 使用して、複数のパスワードエージングとアカウント詳細を修正することもできます。以下のコマンドを使用してインタラクティブモードに入ります:
chage <username>
このコマンドの使い方について簡単なインタラクティブのセッションを以下に示します:
[root@interch-dev1 ~]# chage davido Changing the aging information for davido Enter the new value, or press ENTER for the default Minimum Password Age [0]: 10 Maximum Password Age [99999]: 90 Last Password Change (YYYY-MM-DD) [2006-08-18]: Password Expiration Warning [7]: Password Inactive [-1]: Account Expiration Date (YYYY-MM-DD) [1969-12-31]: [root@interch-dev1 ~]#
chage に関して、利用できるオプションの詳細情報はその man ページを参照して下さい。
以下のように、パスワードエージングポリシーを作成するのに、グラフィカル User Manager を使用することもできます。注記: この手順を実行するのに、 Administrator 権限が必要です。
-
パネル上の システム メニューをクリックし、 Administration を選び、ユーザーマネージャを表示するのに ユーザーとグループ をクリックしてください。代わりに、シェルプロンプトで
system-config-users入力することもできます。 -
ユーザー タブをクリックして、ユーザーのリストから必要なユーザーを選択してください。
-
ユーザープロパティダイアログボックスを表示するには、ツールバー上の プロパティ をクリックしてください (または、 ファイル メニューの プロパティ を選択してください)。
-
パスワード情報 タブをクリックして、 パスワード失効を有効にする ためにチェックボックスを選択します。
-
変更までに必要な期限日数 フィールドに必要な値を入力し、 OK をクリックしてください。
自宅のマシンを管理する際は、 root ユーザーとしてあるいは sudo や su などの setuid プログラムから有効な root 権限を取得して、いくつかのタスクを実行する必要があります。 setuid プログラムは、ユーザーがプログラムを操作するのではなく、プログラムのオーナーのユーザー ID (UID) で動作するプログラムです。このようなプログラムは、次の例のように、長い形式一覧のオーナーセクションに小文字の s で表示されています:
-rwsr-xr-x 1 root root 47324 May 1 08:09 /bin/su
注記
s は、大文字でも、小文字でも通用します。大文字で出た場合、背後にある権限ビットは設定されていないという意味です。
しかし、組織のシステム管理者は、社内のユーザーに対し彼らのマシンへどのくらいの管理アクセスを持たせるかを決めなくてはなりません。 pam_console.so と呼ばれる PAM モジュールで、再起動やリムーバブルメディアのマウントなど通常は root ユーザー専用であるいくつかの作業が物理的なコンソールでログインした最初のユーザーに許可されます (pam_console.so モジュールについての詳細は、 項25.4. 「PAM（Pluggable Authentication Modules）」 を参照) 。ただし、ネットワークの設定変更、新しいマウスの設定、ネットワークデバイスのマウントなどの他の重要な管理タスクは管理権限がないと実行できません。その結果、システム管理者はネットワーク上のユーザーにどのくらいアクセスを与えるかを決定する必要があります。
企業内のユーザーが信頼できるコンピュータ知識の豊富な人達ばかりなら、 root アクセスの許可を与えるのは問題ではないでしょう。ユーザーに root アクセスを許可することで、デバイスの追加やネットワークインターフェースの設定などはユーザー個人で行なうことができるため、システム管理者はネットワークセキュリティや他の重要な問題の処理に時間を取ることができます。
一方、 root アクセスを個別のユーザーに与えると次のような問題の原因となる可能性があります (一部の例):
-
マシンの誤設定 — root アクセスを持つユーザーが彼らのマシンの設定を誤って助けが必要になったり、悪くすると知らずにセキュリティホールを作ってしまうことがあります。
-
セキュアではないサービスを実行する — root アクセスを持つユーザーが彼らのマシン上で FTP や Telnet などのセキュアではないサービスを実行してしまい、ネットワーク上でユーザー名やパスワードを危険に曝してしまう可能性があります。これらのサービスはネットワーク上で情報を平文で送信してしまいます。
-
root で電子メールの添付ファイルを実行する — 稀れですが、 Linux に影響をおよぼす電子メールウィルスが存在します。ただし、これらウィルスが危険なのは、 root ユーザーで実行したときのみです。
こうした理由や諸事情から、ユーザーに root としてのログイン許可を与えることが不安に思われる場合、 root パスワードは機密とし、ランレベル 1 やシングルユーザーモードへのアクセスはブートローダパスワード保護 (詳細は 項25.1.2.2. 「ブートローダのパスワード」 を参照) で禁止してください。
表 25.1. 「root アクセスを使用禁止にする方法」 管理者が root ログインを確実に禁止する方法を示します:
| 方法 | 説明 | 効果 | 対象外 | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| root シェルを変更する。 |
/etc/passwd ファイルを編集して、シェルを /bin/bash から /sbin/nologin に変更します。
|
|
|
|||||||||||||||
| すべてのコンソールデバイス (tty) からの root アクセスを使用禁止にする。 |
空の /etc/securetty ファイルはコンピュータに接続しているすべてのデバイスでの root ログインを妨げます。
|
|
|
|||||||||||||||
| root の SSH ログインを使用禁止にする。 |
/etc/ssh/sshd_config ファイルを編集して、 PermitRootLogin パラメータを no に設定します。
|
|
|
|||||||||||||||
| PAM を使ってサービスへの root アクセスを制限する。 |
/etc/pam.d/ ディレクトリで目的のサービスのファイルを編集します。 pam_listfile.so が認証の為に必要となることを確認します。[a]
|
|
|
|||||||||||||||
|
[a] 詳細は 項25.1.4.2.4. 「PAM を使う root を使用禁止にする」 を参照して下さい。 |
||||||||||||||||||
表 25.1. root アクセスを使用禁止にする方法
ユーザーが直接 root としてログインしないようにするために、システム管理者は root アカウントのシェルを /etc/passwd ファイルで /sbin/nologin に設定できます。これにより、 su コマンドや ssh コマンドなど、シェルを必要とするコマンドから root アカウントへのアクセスが妨げられます。
重要
シェルにアクセスする必要のないプログラム。電子メールクライアントや sudo コマンドなどは、 root アカウントにアクセスできます。
root アカウントへのアクセスを更に制限するには、管理者は /etc/securetty ファイルを編集してコンソールで root ログインを無効にすることができます。このファイルは、 root ユーザーがログインする許可のあるデバイスすべてを一覧表示しています。ファイルがまったく存在しない場合は、 root ユーザーはコンソールか raw ネットワークインターフェース経由でシステム上のあらゆる通信デバイスから、ログインできます。これはユーザーが Telnet を通じて root として自身のマシンにログインできるため危険であり、ネットワーク上で自分のパスワードを平文で送信してしまいます。デフォルトでは、 Red Hat Enterprise Linux の /etc/securetty ファイルは、 root ユーザーにマシンに物理的に接続されているコンソールでのログインのみを許可しています。 root がログインしないようにするには、以下のコマンドを入力してこのファイルの内容を削除します:
echo > /etc/securetty
警告
空白の /etc/securetty ファイルは、認証までコンソールが開かないため、 OpenSSH ツールセットを使う遠隔からの root ユーザーログインは 防ぎません 。
SSH プロトコルからの root ログインを防ぐには、 SSH デーモンの設定ファイル (/etc/ssh/sshd_config) を編集します。次のように表示されている行を変更します:
# PermitRootLogin yes
次のように変更します。
PermitRootLogin no
PAM は、 /lib/security/pam_listfile.so モジュールを通して、特定アカウントを拒否するのに柔軟性を発揮します。これで、管理者はログイン許可のないユーザーの一覧でこのモジュールを参照することができます。 /etc/pam.d/vsftpd PAM 設定ファイルにある vsftpd FTP サーバー用に、このモジュールが使用される方法の例を以下に示します (例の中の最初の行の末尾にある \ 文字は、ディレクティブが1行であれば 必要ありません) 。
auth required /lib/security/pam_listfile.so item=user \ sense=deny file=/etc/vsftpd.ftpusers onerr=succeed
これは、 PAM に対し /etc/vsftpd.ftpusers ファイルを参照して、記載されているユーザーすべてに対してサービスへのアクセスを拒否するように指示します。管理者はこのファイルの名前は変更しても構いません。そして各サービスの一覧を別々に保持したり、複数のサービスへのアクセスを拒否するために1つの中央一覧を使うこともできます。
管理者が複数のサービスへのアクセスを拒否したい場合、メールクライアント用の /etc/pam.d/pop や /etc/pam.d/imap 、あるいは SSH クライアント用の /etc/pam.d/ssh などの PAM 設定サービスに、似たような行を加えることができます。
PAM に関する詳細は、 項25.4. 「PAM（Pluggable Authentication Modules）」 を参照して下さい。
root ユーザーへアクセスを完全に拒否する代わりに、管理者は su や sudo などの setuid プログラムからのアクセスのみを許可すると良いでしょう。
su コマンドを入力すると、ユーザーは root パスワードを求められ、認証された後で root シェルプロンプトが与えられます。
su コマンドからログインすると、ユーザーは root ユーザー であり 、システムに対して絶対的な管理アクセス権を持ちます。 [11] さらに、ユーザーが root になると、パスワードを求められることなく su コマンドを使ってシステム上の他のユーザーになることが可能になります。
このプログラムは非常に強力であるため、企業内の管理者はそのコマンドへのアクセスを持つ人を限定したいことがあるかもしれません。
これを行なう簡単な方法は、ユーザーを wheel と呼ばれる特殊管理グループに追加することです。追加するには、 root になり次のコマンドを入力します。
usermod -G wheel <username>
上記のコマンドで、 <username> には、 wheel グループに追加するユーザー名を入れます。
以下のように、グループメンバーシップを変更するために User Manager も使用することができます。注記: この手順を実行するのに、 Administrator 権限が必要です。
-
パネル上の システム メニューをクリックし、 Administration を選び、ユーザーマネージャを表示するのに ユーザーとグループ をクリックしてください。代わりに、シェルプロンプトで
system-config-users入力することもできます。 -
ユーザー タブをクリックして、ユーザーのリストから必要なユーザーを選択してください。
-
ユーザープロパティダイアログボックスを表示するには、ツールバー上の プロパティ をクリックしてください (または、 ファイル メニューの プロパティ を選択してください)。
-
グループ タブを選択して、 wheel グループのチェックボックスを選択します。それから、 OK をクリックします。 図 25.2. 「"wheel" グループにユーザーを追加する。」 を参照してください。
-
次に、
su(/etc/pam.d/su) の PAM 設定ファイルをテキストエディタで開き、以下の行から # コメントを削除します。auth required /lib/security/$ISA/pam_wheel.so use_uid
これを行なうと、管理グループ
wheelのメンバーだけにそのプログラムの使用を許可します。
注記
デフォルトでは、 root ユーザーは wheel グループのメンバーです。
sudo コマンドでは、ユーザーに管理アクセスを与えるもう１つの方法を提供しています。信頼できるユーザーが管理コマンドに sudo を先に付けて実行すると、このユーザーは 自身の パスワードを要求されます。その後、認証され、そのコマンドが許可されれば、管理コマンドは root ユーザーで行なわれたかのように実行されます。
sudo コマンドの基本形式は次のようになります:
sudo <command>
上記の例で、 <command> には、 mount などの通常は root ユーザー専用のコマンドを入れます。
重要
sudoer は 5 分間パスワードを求められることなく再度そのコマンドを使用できるため、 sudo コマンドのユーザーは、マシンから離れる前にログアウトするよう十分に気をつける必要があります。このセッティングは設定ファイルの /etc/sudoers から変更できます。
sudo コマンドは高い柔軟性を備えています。例えば、 /etc/sudoers 設定ファイルに記載されているユーザーのみが sudo コマンドの使用を許可され、そのコマンドは root シェルではなく そのユーザーの シェルで実行されます。つまり、 項25.1.4.2.1. 「root シェルを使用禁止にする」 で示すように root シェルを完全に使用禁止にすることができます。
sudo コマンドは広範囲の追跡監査も行ないます。成功した認証はそれぞれ /var/log/messages ファイルに記録され、発行されたコマンドは発行者のユーザー名と共に /var/log/secure ファイルに記録されます。
sudo コマンドのもうひとつの利点は、管理者が必要に応じて特定コマンドに別々のユーザーアクセスを許可することができることです。
sudo 設定ファイルの /etc/sudoers を編集する管理者は、 visudo コマンドを使用してください。
誰かに完全な管理権限を与えるには、 visudo を入力してからユーザーの権利指定セクションで以下のような行を追加します。
juan ALL=(ALL) ALL
この例では、ユーザ juan がどのホストからも sudo を使用してどのコマンドも実行できるように決めています。
下記の例は sudo を設定する際に、以下のように特定コマンドを設定できます。
%users localhost=/sbin/shutdown -h now
この例では、コンソールでならいずれのユーザーも /sbin/shutdown -h now コマンドを発行できるように決めています。
sudoers の man ページにはこのファイル用オプションの詳細一覧が記述されています。
管理制御へのユーザーアクセスが企業のシステム管理者にとって重要な問題である一方、アクティブになっているネットワークサービスを監視することは、 Linux システムを動作させて管理する人すべてにとって非常に重要なことになります。
Red Hat Enterprise Linux 稼動環境下にある多くのサービスはネットワークサービスとして動作します。ネットワークサービスがマシン上で稼動している場合、 デーモン と呼ばれるサーバーアプリケーションは1つまたは複数のネットワークポートで接続をリスニングしています。これらの各サーバーは攻撃される可能性のある通路として考えるべきでしょう。
ネットワークサービスは Linux システムにとって多くの危険性をもたらします。以下に主な問題のいくつかを一覧で示します。
-
サービス停止攻撃 (DoS) — 要求でサービスを溢れさせることにより、サービス停止攻撃は、システムがこの各要求すべてをログして応答するようにさせ、そのシステムを使用不可にします。
-
スクリプトの脆弱性攻撃 — 一般的に Web サーバーがするように、サーバーがサーバー側の動作を実行するためにスクリプトを使用している場合、クラッカーは貧弱な書き方のスクリプトに攻撃を加えることができます。これらのスクリプトの脆弱性への攻撃は、バッファのオーバーフロー状態を招いたり、攻撃者にシステム上のファイルを改変させてしまうことになる恐れがあります。
-
バッファのオーバーフロー攻撃 — ポート番号 0 から 1023 へ接続するサービスは管理ユーザーとして実行しなければなりません。アプリケーションに侵害可能なバッファオーバーフローがある場合、攻撃者はデーモン実行中のユーザーとしてシステムにアクセス権を得ることができます。これは侵害可能なバッファオーバーフローがあると、クラッカーは自動ツールを使用して脆弱性のあるシステムを識別することができ、一度アクセス権を取得すると、自動 root キットを使ってシステムへのアクセスを維持するからです。
注記
Red Hat Enterprise Linux では、バッファオーバーフローの脆弱性への脅威は ExecShield で軽減されています。これは、実行可能なメモリ分割と x86-互換のシングル及びマルチプロセッサーカーネルでサポートされる保護技術です。 ExecShield は仮想メモリを実行可能と非実行可能な部分に分割することでバッファオーバーフローのリスクを軽減します。実行可能部分外で実行しようとするプログラムコード (バッファオーバーフロー悪用で投入された悪意のあるコードなど) は分割化失敗を発生し、終了します。
Execshield には、 AMD64 プラットフォーム上の No eXecute (NX) 技術と Itanium 及び Intel® EM64T システム上の eXecute Disable (XD) 技術へのサポートが含まれます。これらの技術は ExecShield と共に機能して悪意のあるコードが実行可能コードの 4kb 区分を持つ仮想メモリの実行可能部分で実行するのを防止して、見えないバッファオーバーフローの悪用からの攻撃のリスクを低減します。
ヒント
ネットワーク上で攻撃を受ける可能性を制限するには、使用していないサービスを全てオフにしてください。
セキュリティを強化する為に、 Red Hat Enterprise Linux でインストールされているほとんどのネットワークサービスはデフォルトでオフになっています。但し、幾つか例外があります:
-
cupsd— Red Hat Enterprise Linux 用のデフォルトの印刷サーバー -
lpd— 代替の印刷サーバー -
xinetd—gssftpやtelnetなど、従属サーバー群への接続を制御するスーパーサーバーです。 -
sendmail— デフォルトでは、 Sendmail Mail Transport Agent (メールトランスポートエージェント) (MTA) が有効になっていますが、 localhost からの接続のみリスニングします。 -
sshd— Telnet のセキュアな代替となる OpenSSH サーバー
これらのサービスを実行したままにしておくかどうかを決めるときは、常識を持って判断し、注意しすぎる位がベストです。例えば、プリンタが利用できない場合には cupsd を実行したままにしておかないようにします。 portmap についても同じです。 NFSv3 ボリュームをマウントしなかったり NIS (ypbind サービス) を使用しない場合には、 portmap は無効にしてください。
特定のサービスに関してその目的が不確かな場合は、 図 25.3. 「サービス設定ツール」 に示してあるように、 Services Configuration Tool に説明フィールドがあり、そこで追加の情報を提供しています。
ブート時に起動できるネットワークサービスを確認するだけでは十分とは言えません。システム管理者は、どのポートが開いていてリスニングしているかも確認してください。これに関する詳細は、 項25.2.8. 「リッスンするポートの確認」 を参照してください。
ネットワークプロトコルの中には他に比べて本質的にセキュアでないものがあります。以下のようなサービスはいずれもこれに該当します:
-
暗号化していないユーザー名とパスワードをネットワーク上で渡す — Telnet や FTP など、多くの旧式プロトコルは認証セッションを暗号化しないので、できるだけ避けてください。
-
暗号化していない機密データをネットワーク上で渡す — 多くのプロトコルは暗号化していないデータをネットワーク上で渡します。これらのプロトコルには、 Telnet、 FTP、 HTTP、 SMTP などがあります。 NFS や SMB などの多くのネットワークファイルシステムもまた暗号化していない情報をネットワーク上で渡します。これらのプロトコルを使用するときに、送信するデータのタイプを制限するのはユーザーの責任です。
また、
netdumpのようなリモートメモリダンプサービスもネットワーク上で暗号化していないメモリの内容を渡します。メモリダンプにはパスワード、ときにはデータベースのエントリや他の機密情報なども含まれていることがあります。finger及びrwhodのような他のサービスは、システムのユーザーに関する情報を明かしてしまいます。
本質的に安全度の低いサービスの例としては、rlogin、 rsh、telnet、vsftpd があります。
すべてのリモートログインとシェルプログラム (rlogin、 rsh、 telnet) は避けて SSH にして下さい。 sshd についての詳細は、 項25.1.7. 「セキュリティ強化された通信ツール」 を参照してください。
FTP は、システムのセキュリティに対してリモートシェルほど本質的に危険ではありませんが、問題を避けるために、 FTP サーバーは十分に注意して設定、監視する必要があります。 FTP サーバーの安全確保についての詳細は、 項25.2.6. 「FTP の保護」 を参照してください。
十分に注意して実装すると共に、ファイアウォールの後に配置すべきサービスには以下のようなものがあります:
-
finger -
authd(これは以前の Red Hat Enterprise Linux リリースではidentdと呼ばれていました。) -
netdump -
netdump-server -
nfs -
rwhod -
sendmail -
smb(Samba) -
yppasswdd -
ypserv -
ypxfrd
ネットワークサービスの安全確保に関する詳細は、 項25.2. 「サーバーセキュリティ」 にあります。
次のセクションでは、シンプルなファイアウォールを設定するのに利用できるツールについて説明します。
必要な ネットワークサービスを設定したら、ファイアウォールを実装することが重要です。
重要
先ず、必要なサービスの設定とファイヤーウォールを実装して、 それから インターネットやその他の信頼できないネットワークに接続する必要があります。
ファイアウォールはネットワークパケットがシステムのネットワークインターフェースにアクセスするのを防ぎます。ファイアウォールでブロックされたポートに対して要求が発生すると、この要求は無視されます。サービスがこれらのブロックされているポートのひとつをリスニングしている場合、パケットを受け取らず事実上無効にされます。このため、使用していないポートへのアクセスをブロックしながら、設定されているサービスが使用するポートへのアクセスはブロックしないようにファイアウォールを設定する際は、注意する必要があります。
For most users, the best tool for configuring a simple firewall is the graphical firewall configuration tool which ships with Red Hat Enterprise Linux: the セキュリティレベル設定ツール (system-config-securitylevel). This tool creates broad iptables rules for a general-purpose firewall using a control panel interface.
インターネットの規模や普及率の拡大に準じて、通信妨害の脅威も増しつつあります。通信はネットワーク上で交信されるため、長年にわたって通信を暗号化するツールが開発されています。
Red Hat Enterprise Linux では2つの基本ツールが配付されており、これらのツールはレベルの高い、公開鍵暗号ベース暗号化アルゴリズムを使用して、ネットワーク上を移動する情報を保護します。
-
OpenSSH — ネットワーク通信の暗号化用 SSH プロトコルのフリーな実装
-
Gnu Privacy Guard (GPG) — データ暗号化用 PGP (Pretty Good Privacy) 暗号化アプリケーションのフリーな実装
OpenSSH はリモートマシンにアクセスするためのより安全な方法で、 telnet や rsh などのように旧式で暗号化されないサービスに代わります。 OpenSSH には sshd と呼ばれるネットワークサービスと3つのコマンドラインクライアントアプリケーションが含まれます。
-
ssh— 安全なリモートコンソールアクセスクライアント -
scp— 安全なリモートコピーコマンド -
sftp— インタラクティブなファイル転送セッションを可能にする安全な pseudo-ftp クライアント
GPG はプライベートな電子メールを守る１つの方法です。公開ネットワーク上で機密データを電子メール送信するのにも、ハードドライブ上で機密データを保護するのにも使用できます。
システムが公共ネットワーク上でサーバーとして使用される場合,攻撃の対象になります。このため、システムの強化とサービスのロックダウンはシステム管理者にとって最も重要となります。
特定の問題について調べる前に、次にあげるサーバーのセキュリティ強化に関する一般的なヒントを再検討してください。:
-
すべてのサービスを更新して、最新の攻撃手段などから保護して下さい。
-
できる限り安全なプロトコールを使用します。
-
できる限りマシン1台につき１タイプのネットワークサービスのみ供給します。
-
不審な行為がないか注意してすべてのサーバーを監視します。
TCP ラッパー はさまざまなサービスにアクセス制御を提供します。 SSH、 Telnet、 FTP などの殆んどの最新ネットワークサービスは TCP ラッパーを使用します。 TCP ラッパーは受信要求と要求されたサービスの間で防護の役割を果たします。
TCP ラッパーによる利点は、追加アクセス、ロギング、バインド、リダイレクト、リソースの利用制御などを提供するスーパーサービス、 xinetd と関連付けて使用すると増強されます。
次のサブセクションでは各トピックの基本知識があることを想定し、特定のセキュリティオプションに焦点を置いています。
TCP ラッパーはサービスへのアクセスを拒否する以外にも多くの機能があります。このセクションでは接続バナーの送信、特定ホストからの攻撃警告、ロギング機能の向上などを行なうための使用方法を説明しています。 TCP ラッパーの機能と制御言語の詳細情報は hosts_options の man ページを参照してください。
ユーザーが１つのサービスに接続する時に適切なバナーを表示するのは、想定攻撃者に対して管理者が警戒していることを知らせる良い手段です。また、ユーザーに提供される情報を制御することも可能です。サービスの TCP ラッパーバナーを実行するには、 banner オプションを使用します。
この例では、 vsftpd のバナーを実行しています。まず、バナーファイルを作成します。ファイルはシステムのどこに格納されても構いませんが、デーモンと同じ名前でなければなりません。この例では、ファイル名を /etc/banners/vsftpd とし、以下の行を含みます:
220-Hello, %c 220-All activity on ftp.example.com is logged. 220-Inappropriate use will result in your access privileges being removed.
%c トークンは、ユーザー名とホスト名、あるいはユーザー名と IP アドレスなどのさまざまなクライアント情報を供給してその接続をさらに威嚇的にします。
受信接続に対してこのバナーを表示するには、次の行を /etc/hosts.allow ファイルに追加します:
vsftpd : ALL : banners /etc/banners/
サーバーを攻撃しているホストまたはネットワークが検知された場合、 TCP ラッパーは spawn ディレクティブを使用して、そのホストまたはネットワークからのその後の攻撃を管理者に警告することができます。
この例では、 206.182.68.0/24 ネットワークからのクラッカーがサーバーの攻撃を試みて感知されています。 /etc/hosts.deny ファイルに以下の行を入力すると、そのネットワークからの接続試行は拒否されその試みは特別なファイルにログされます。
ALL : 206.182.68.0 : spawn /bin/ 'date' %c %d >> /var/log/intruder_alert
%d トークンは攻撃者がアクセスを試みたサービスの名前を提供します。
接続とログを許可するには spawn 指令を /etc/hosts.allow ファイルに配置します。
注記
spawn ディレクティブがシェルコマンドを実行するため、特定のクライアントがサーバーへの接続を試みた場合、特別なスクリプトを作成して管理者に知らせるか、連続のコマンドを実行するようにします。
特定の接続タイプが他の接続タイプより懸念される場合、 severity オプションを介してそのサービスのログレベル上げることができます。
この例で FTP サーバー上のポート 23 (Telnet ポート) に接続を試みている者はクラッカーだとします。クラッカーだと示すためにはデフォルトの info フラグの代わりに emerg フラグをログファイルに配置し、接続を拒否します。
これを実行するには次の行を /etc/hosts.deny に配置します:
in.telnetd : ALL : severity emerg
これはデフォルトの authpriv ロギング機構を使用しますが、 info のデフォルト値から、ログメッセージを直接コンソールに置く emerg に優先度を上げます。
このセクションでは xinetd での trap サービス設定や如何なる xinetd サービスにでも利用可能なリソースレベルの制御の為の使用に焦点を置きます。サービスにリソース制限を設定することは Denial of Service (サービス停止攻撃) (DoS) の防御に役に立ちます。使用可能オプションの詳細一覧は xinetd と xinetd.conf の man ページをご参照下さい。
xinetd の重要機能の1つとしてグローバル no_access リストへのホスト追加機能があげられます。このリストに掲載されているホストは特定の期間、又は xinetd が再起動するまで xinetd が管理するサービスへの接続を拒否されます。これは SENSOR 属性を使用することにより達成されます。サーバーのポートスキャンを試みるホストをブロックする簡単な方法です。
SENSOR 設定の第一歩として利用予定のないサービスを選択します。この例では Telnet が使用されています。
/etc/xinetd.d/telnet ファイルを編集し、 flags の行を次の通り変更します:
flags = SENSOR
次の行を追加します:
deny_time = 30
これによりポートへ接続を試みるホストは30分間拒否されます。その他 deny_time 属性に使用可能な値として、 xinetd が再起動されるまで接続を拒否する FOREVER や接続を許可しログする NEVER があります。
そして、下記ラインを最後のラインとして下さい:
disable = no
これがトラップ自身を有効にします。
SENSOR を使用することにより極悪なホストを検出し、接続を拒否することができますが、難点が 2 つほどあります:
-
SENSORはステルススキャンには対応できません。 -
SENSORが実行されていることを知る攻撃者は、 IP アドレスを偽造し、アクセス禁止ポートに接続することで、特定のホストに対してサービス停止攻撃を仕掛けることができます。
xinetd のもう1つの重要な機能は、その管理下のサービスが使用するリソース量を制御する能力です。
この機能は下記ディレクティブを使って実行されます:
-
cps = <number_of_connections> <wait_period>— 受信接続のレートを制限します。このディレクティブは2つのつの引数を使用します。-
<number_of_connections>— 秒単位で処理する接続の数量。受信接続のレートがこの数値より高い場合は、サービスは一時的に無効になります。デフォルト値は 50 です。 -
<wait_period>— サービスが無効になった後で、再確立するまで待つ秒数。デフォルトの期間は 10 秒です。
-
-
instances = <number_of_connections>— サービスに許可された総接続数を指示します。このディレクティブには整数値、又はUNLIMITEDが使用できます。 -
per_source = <number_of_connections>— サービスに許可された各ホスト当たりの接続数を指定します。このディレクティブには整数値、又はUNLIMITEDが使用できます。 -
rlimit_as = <number[K|M]>— サービスが占有可能なメモリーアドレススペースの量をキロバイト又はメガバイト単位で指定します。このディレクティブには整数値、又はUNLIMITEDが 使用できます。 -
rlimit_cpu = <number_of_seconds>— サービスの CPU 占有可能時間を秒単位で指定します。このディレクティブには整数値、又はUNLIMITEDが使用できます。
このようなディレクティブを使用することにより、サービス停止の原因となる単独の xinetd によるシステム過大負荷を防止します。
portmap サービスは NIS や NFS など RPC サービス向けのダイナミックなポート指定デーモンです。脆弱な認証メカニズムのうえ、管理下のサービスに広範囲なポートを指定する機能を持ち合わせているため、保護するのは困難です。
注記
portmap を保護することは、 NFSv4 では必要ない為、単に NFSv2 と NFSv3 の実装に影響するだけです。 NFSv2 と NFSv3 サーバーを実装する予定であれば、 portmap が必要となり、以下のセクションが適用されます.
RPS サービスを実行している時は、次の基本ルールを守って下さい。
portmap サービスには内蔵の認証形式がないため、 TCP ラッパーを使用し、このサービスへアクセス可能なネットワークやホストを制限することが重要になります。
更に、サービスのアクセスを制限する時は IP アドレスのみを使用して下さい。 DNS poisoning などによって偽造される可能性のため、ホストネームは使用しないで下さい。
portmap サービスへのアクセスを更に規制するには、 iptables ルールをサーバーに追加し、特定ネットワークへのアクセスを規制するとよいでしょう。
192.168.0.0/24 ネットワークとローカルホスト （Nautilus が使用する sgi_fam サービスに必要） から portmap （ポート 111 でリッスン）への TCP 接続を許可する IPTables コマンドの 2 例を下記に説明しています。
iptables -A INPUT -p tcp -s! 192.168.0.0/24 --dport 111 -j DROP iptables -A INPUT -p tcp -s 127.0.0.1 --dport 111 -j ACCEPT
同様に UDP トラフィックを制限するには、下記コマンドを使用して下さい。
iptables -A INPUT -p udp -s! 192.168.0.0/24 --dport 111 -j DROP
NIS は ネットワークインフォメーションサービス の略です。 NIS は ypserv と呼ばれる RPC サービスで、ユーザー名やパスワードなどの機密情報をドメイン内にあるされるコンピューターに配信するため、 portmap と他の関連サービスと併せて使用されます。
NIS サーバーは下記を含むいくつかのアプリケーションによって構成されます。:
-
/usr/sbin/rpc.yppasswdd—yppasswddサービスとも呼ばれます。このデーモンはユーザーの NIS パスワード変更を許可します。 -
/usr/sbin/rpc.ypxfrd—ypxfrdサービスとも呼ばれるデーモンで、 NIS マップをネットワーク上で転送します。 -
/usr/sbin/yppush— このアプリケーションは NIS データベースの変更を複数の NIS サーバーに伝搬します。 -
/usr/sbin/ypserv— これが NIS サーバーのデーモンです。
今日の水準では、 NIS の安全性は不十分と言えます。ホスト認証のメカニズムもありませんし、パスワードハッシュなどで情報を暗号化しないままネットワークに送られます。そのため、 NIS を使用するネットワークの設定には細心の注意を払わなければなりません。更に悪いことに、 NIS のデフォルト設定自体が安全性に欠けています。
NIS サーバーの導入を予定している場合、 項25.2.2. 「ポートマップの保護」 の説明通り、初めに portmap サービスの安全性を確認して下さい。その後、ネットワーク計画など次にあげる問題に対応して下さい。
NIS は機密情報を暗号化しないままネットワーク上に配信するため、安全で、セグメント化されたネットワーク上のファイヤウォールの裏でサービスを実行することが重要です。 NIS の情報が安全でないネットワーク上で配信されるたび、妨害を受けるリスクにさらされます。慎重なネットワーク設計をすることが重大なセキュリティー侵害の防止につながります。
NIS サーバーの DNS ホスト名と NIS ドメイン名を知っているユーザーは、 NIS ドメイン内のコンピューターなら認証なしでコマンドを使ってサーバーから情報を引き出すことができます。
例えば、誰かがノート型 PCをネットワークに接続するか、外部からネットワークに侵入し、うまく内部 IP アドレスをごまかした場合、下記コマンドで /etc/passwd マップを確認することができます:
ypcat -d<NIS_domain>-h<DNS_hostname>passwd
この攻撃者がルートユーザである場合、次のコマンドを入力すると /etc/shadow ファイルを入手することができます:
ypcat -d<NIS_domain>-h<DNS_hostname>shadow
注記
Kerberos が使用された場合、 /etc/shadow ファイルには NIS マップには保存されません。
攻撃者による NIS マップへのアクセスを困難にするため、 o7hfawtgmhwg.domain.com のように無作為な DNS ホスト名を設定して下さい。同様に、 異なる 無作為な NIS ドメイン名を設定して下さい。これで、攻撃者による NIS サーバーへのアクセスは一層困難になります。
/var/yp/securenets ファイルが空か、存在しない場合 （デフォルトインストールの後に相当）、 NIS はすべてのネットワークをリッスンします。最初にすることの１つは、ネットマスクとネットワークのペアをファイルに格納して、 ypserv が正当なネットワークからの要求のみに応答するようにします。
/var/yp/securenets ファイルからのエントリー例は下記の通りです:
255.255.255.0 192.168.0.0
警告
初めて NIS サーバー起動する場合、必ず先に /var/yp/securenets を作成してから始めて下さい。
このテクニックでは IP になりすました攻撃から保護することはできませんが、少なくとも NIS サーバーがサービス提供するネットワークを制限することができます。
NIS に関連した全てのサーバーは rpc.yppasswdd (ユーザーにログインパスワードの変更を許可するデーモン) 以外の特定のポートに割り当てできます。他の NIS サーバーデーモンである rpc.ypxfrd と ypserv にポートを割り当てると、ファイアウォールルールの作成が可能となり、更に NIS サーバーデーモンを侵入者から守ります。
これを実行するには、以下の行を /etc/sysconfig/network に追加して下さい:
YPSERV_ARGS="-p 834" YPXFRD_ARGS="-p 835"
次の iptable ルールを実行することにより、ポートに対してサーバーがリッスンするネットワークを強制することができます。
iptables -A INPUT -p ALL -s! 192.168.0.0/24 --dport 834 -j DROP iptables -A INPUT -p ALL -s! 192.168.0.0/24 --dport 835 -j DROP
これは、要求が 192.168.0.0/24 のネットワークから来る場合、プロトコルに関係なく、サーバーがポート 834 と 835 への接続のみを許可すると言う意味です。
重要
Red Hat Enterprise Linux に収納されている NFS のバージョンは、 項25.2.2. 「ポートマップの保護」 に概要を示してある portmap サービスを必要としません。 NFS 通信は現在では全てのバージョンで、 UDP ではなく TCP を使用し NFSv4 の使用時に TCP を必要とします。 NFSv4 は RPCSEC_GSS カーネルモジュールの一部として Kerberos ユーザー及びグループ認証を含んでいます。 Red Hat Enterprise Linux が NFSv2 と NFSv3 をサポートしていますので、それで使用される portmap の情報はまだ含まれています。
NFSv4 はネットワーク上で Kerberos を使用して暗号化された情報を送る能力を持っているため、通信がファイヤーウォールの裏側やセグメント化したネットワークに渡る場合はサービスを正確に設定することが重要です。 NFSv2 と NFSv3 はデータを不安全な方法で渡しているため、用心する必要があります。すべての構成で注意深くネットワークをデザインすることが安全侵害を防止するのに役に立ちます。
ディレクトリを /etc/exports ファイル経由でエキスポートする先のファイルシステムやホストは NFS サーバーが決定します。このファイルを編集する時、無関係な空白を追加しないように気をつけて下さい。
例えば、 /etc/exports ファイルにある次の行は、ホスト bob.example.com に対して読み込み/書き込み権限付で、ディレクトリ /tmp/nfs/を共有します。
/tmp/nfs/ bob.example.com(rw)
/etc/exports ファイルにある以下の行は、ホスト bob.example.com に対して読み取り専用の権限で同じディレクトリを共有します。又、 world に対してはホスト名の後の空白１つによって、読み取り/書き込み権限でディレクトリを共有します。
/tmp/nfs/ bob.example.com (rw)
showmount コマンドを使用し、設定済みの NFS の共有をチェックして、それが正しく共有していることを確認すると良いでしょう:
showmount -e <hostname>
Apache HTTP サーバーは Red Hat Enterprise Linux で配布される最も安定した、安全なサービスです。 Apache HTTP サーバーには利用できるオプションと技術が数多くあります。 — 多すぎるため、ここでは全てを言及することは避けます。
以下の設定オプションを使用する場合、システム管理者は注意する必要があります:
このディレクティブはデフォルトで有効になっていますので、ウェブサーバーのドキュメントルートにシンボリックリンクを作成する場合は慎重に行なって下さい。例えば、 / にはシンボリックリンクを与えないようにします。
このディレクティブはデフォルトで有効になっていますが、望ましい設定ではありません。サーバー上のファイルをビジターが閲覧できなくするにはこのディレクティブを解除して下さい。
システムに存在するユーザーアカウントを確認してしまうため、 UserDir ディレクティブはデフォルトで無効となっています。サーバーのユーザーディレクトリ閲覧を有効にするには次のディレクティブを使用して下さい:
UserDir enabled UserDir disabled root
このようなディレクティブは /root/ 以外の全てのユーザーディレクトリのユーザーディレクトリ閲覧を有効にします。無効アカウントのリストにユーザーを追加する場合は、空白で区切ったユーザーのリストを UserDir disabled 行に追加して下さい。
デフォルトで、 SSI(Server-Side Includes) モジュールはコマンドを実行できません。攻撃者がシステム上でコマンド実行する恐れがあるので、絶対に必要でない限りはこの設定を変更しないで下さい。
ファイル転送プロトコル(FTP) はネットワーク上でファイル転送を行なうように設計された旧式の TCP プロトコルです。ユーザー認証を含む全てのサーバートランザクションが暗号化されておらず、安全性の低いプロトコルである為、注意深い設定が必要です。
Red Hat Enterprise Linux は3つの FTP サーバーを提供します。
-
gssftpd— ネットワーク上に認証情報を配信しない、 Kerberos 認知のxinetdベースの FTP デーモンです。 -
Red Hat Content Accelerator (
tux) — FTP 機能を持ち合わせた、カーネルスペースウェブサーバーです。 -
vsftpd— スタンドアローン、セキュリティー指向の FTP サービス実装です。
vsftpd FTP サービス設定のセキュリティーガイドラインは次の通りです。
ユーザー名とパスワードを入力する前にグリーティングバナーが表示されます。デフォルトのままではクラッカーがシステムの弱点を発見するのに便利なバージョン情報がこのバナーに含まれています。
vsftpd のグリーティングバナーを変更するには、次のディレクティブを /etc/vsftpd/vsftpd.conf ファイルに追加して下さい:
ftpd_banner=<insert_greeting_here>
上記ディレクティブの <insert_greeting_here> をグリーティングメッセージのテキストに置き換えます。
複数ラインのバナーの場合、バナーファイルの使用が最適です。複数バナーの管理を簡素化するには、バナーを /etc/banners/ という新しいディレクトリに格納します。この例では、 FTP 接続のバナーファイルは /etc/banners/ftp.msg になります。ファイルは下記例のように表示されます:
######### # Hello, all activity on ftp.example.com is logged. #########
注記
項25.2.1.1.1. 「TCP ラッパーと接続バナー」 の説明通りにファイルの各行を 220 で始める必要はありません。
vsftpd のグリーティングファイルを参照するには、次のディレクティブを /etc/vsftpd/vsftpd.conf ファイルに追加して下さい:
banner_file=/etc/banners/ftp.msg
項25.2.1.1.1. 「TCP ラッパーと接続バナー」 の説明通り、 TCP ラッパーを使用して受信接続に追加バナーを送信することもできます。
/var/ftp/ ディレクトリの存在が匿名アカウントを有効にします。
このディレクトリを簡単に作成するには vsftpd パッケージをインストールします。このパッケージが匿名ユーザーに対してディレクトリツリーを設定し、匿名ユーザー用にディレクトリを読み取り専用とします。
デフォルトでは匿名ユーザーの書き込み許可は無効となっています。
注意
FTP サーバーへの匿名アクセスを有効とする場合、機密データの保存場所に注意して下さい。
匿名ユーザーのファイルアップロードを許可する場合、 /var/ftp/pub/ への書き込み専用ディレクトリの作成が推奨されます。
これを実行するには、下記コマンド入力します:
mkdir /var/ftp/pub/upload
次に、匿名ユーザーにディレクトリ内を見せないようにするために、権限を変更して下さい:
chmod 730 /var/ftp/pub/upload
ディレクトリの長いフォーマット一覧は次のように表示されます:
drwx-wx--- 2 root ftp 4096 Feb 13 20:05 upload
警告
匿名ユーザーにディレクトリの読み取りと書き込みを許可する管理者のサーバーは盗難ソフトウェアのレポジトリ化してしまう亊がよくあります。
さらには vsftpd で、次の行を /etc/vsftpd/vsftpd.conf ファイルに追加して下さい:
anon_upload_enable=YES
FTP は安全でないネットワーク上で認証用のユーザー名やパスワードを暗号化しないまま配信してしまうため、ユーザーアカウントからのサーバーへのシステムユーザーアクセス拒否を設定するようお推めします。
vsftpd のユーザーアカウントを無効にするには、次のディレクティブを /etc/vsftpd/vsftpd.conf に追加して下さい:
local_enable=NO
Sendmail は SMTP (Simple Mail Transport Protocol) を使用して、他の MTA と電子メールクライアントへ、又はデリバリエージェントへ電子メッセージの送信を行うメール転送エージェント (Mail Transport Agent) (MTA) です。トラフィックを暗号化できる MTA も数多くありますが、暗号化できない MTA も多いため、公共ネットワーク上での電子メール送信は内在的に安全性が低いコミュニケーション手段だと言えます。
Sendmail サーバーの導入を予定している場合は、次にあげる問題に対応して下さい。
電子メールの本質的な問題もあり、断固とした攻撃者は比較的簡単にサーバーをメールで満杯にすることができ、その結果サービス停止を発生させます。 /etc/mail/sendmail.mc 内の次のディレクティブで制限を設定することにより、このようなアタックの効力が制限されます。
-
confCONNECTION_RATE_THROTTLE— 1秒毎のサーバーへの接続可能数です。デフォルトでは Sendmail による接続数制限はありません。接続制限が設定され、接続数が制限に達した場合、新しい接続は遅延されます。 -
confMAX_DAEMON_CHILDREN— サーバーが生成可能な子プロセスの最大数です。デフォルトでは Sendmail による子プロセス生成数の制限はありません。子プロセスの制限が設定され、生成が最大数に達した場合、新しい接続は遅延されます。 -
confMIN_FREE_BLOCKS— サーバーのメール受信に必要な最小フリーブロック数です。デフォルトでは 100 ブロックになっています。 -
confMAX_HEADERS_LENGTH— メッセージヘッダーの最大許容サイズ (バイト単位) です。 -
confMAX_MESSAGE_SIZE— 1メッセージの最大許容サイズ (バイト単位) です。
メールスプールディレクトリ /var/spool/mail/ を NFS 共有ボリュームに格納しないでください。
NFSv2 と NFSv3 はユーザーとグループの ID を管理しないため、複数ユーザーが同一 UID を保有することができ、そのため、そのユーザー同士が互いのメールを受信したり、読んだりすることができます。
注記
Kerberos を使用した NFSv4 では、これは該当しません。それは、 SECRPC_GSS カーネルモジュールが UID ベースの認証を使用しないからです。しかし、 NFS 共有のボリューム上にはメールスプールディレクトリを 置かない ことが良い政策となります。
ネットワークサービス設定の後、どのポートがシステムのネットワークインターフェースをリッスンしているか注意を払う必要があります。オープンポートは侵入を意味します。
ネットワークをリッスンするポートを一覧にする基本的方法は2つあります。信頼性の低い方法としては、 netstat -an や lsof -i などのコマンドを入力し、ネットワークスタックをクエリする方法があります。プログラムがネットワークからマシーンに接続せず、何がシステム上で実行されているかを確認する方法のため、信頼性は低いと言えます。そのため、アプリケーションの置換を試みる攻撃者のいいターゲットとなってしまいます。クラッカーは不当なネットワークポートをオープンした場合、 netstat と lsof を自分の編集バージョンと入れ換えて、その侵入経路を隠そうとします。
ネットワークをリッスンするポートを確認するより信頼性の高い方法として nmap などのポートスキャナーを使用する方法があります。
コンソールから発信される次のコマンドによってネットワークの TCP 接続をリッスンしているポートを特定することができます:
nmap -sT -O localhost
このコマンドの出力は次のようになります:
Starting nmap 3.55 ( http://www.insecure.org/nmap/ ) at 2004-09-24 13:49 EDT Interesting ports on localhost.localdomain (127.0.0.1): (The 1653 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 111/tcp open rpcbind 113/tcp open auth 631/tcp open ipp 834/tcp open unknown 2601/tcp open zebra 32774/tcp open sometimes-rpc11 Device type: general purpose Running: Linux 2.4.X|2.5.X|2.6.X OS details: Linux 2.5.25 - 2.6.3 or Gentoo 1.2 Linux 2.4.19 rc1-rc7) Uptime 12.857 days (since Sat Sep 11 17:16:20 2004) Nmap run completed -- 1 IP address (1 host up) scanned in 5.190 seconds
この出力は、 sunrpc が存在するため、システムが portmap を実行している状態を表示します。しかし、未知のサービスがポート 834 に存在しています。このポートが既知サービスの公式リストと関連しているかどうか調べるには次を入力して下さい:
cat /etc/services | grep 834
このコマンドからの出力はありませんでした。これはポートが指定された範囲 (0 から 1023) にあり、オープンするのにルート接続を必要とし、既知サービスとは関連がないことを示します。
次に netstat 又は lsof を使用し、ポート情報を確認して下さい。 netstat でポート 834 を確認するには、次のコマンドを使用します:
netstat -anp | grep 834
コマンドが次を出力しました:
tcp 0 0 0.0.0.0:834 0.0.0.0:* LISTEN 653/ypbind
侵入したシステムで内密にポートをオープンするクラッカーは、このコマンドによってそれが発覚することを避けようとするため、 netstat のオープンポートの存在は安心を与えるものです。また、 [p] オプションによって、ポートをオープンしたサービスのプロセス ID (PID) が判明します。このケースでは、オープンポートは portmap サービスと併せて使用される RPC サービスである ypbind (NIS) に属しています。
lsof コマンドはサービスとオープンポートをリンクする機能があるため、同様の情報を netstat に表示します:
lsof -i | grep 834
このコマンドからの出力の関連部分は次のようになります:
ypbind 653 0 7u IPv4 1319 TCP *:834 (LISTEN) ypbind 655 0 7u IPv4 1319 TCP *:834 (LISTEN) ypbind 656 0 7u IPv4 1319 TCP *:834 (LISTEN) ypbind 657 0 7u IPv4 1319 TCP *:834 (LISTEN)
このようなツールを使えばマシンで実行されているサービスの状態をかなり明らかにすることができます。また、ツールは柔軟性に富み、ネットワークサービスや設定に関する豊富な情報を提供してくれます。是非 lsof、 netstat、 nmap、 services の man ページを参照して下さい。
Red Hat Enterprise Linux SSO の機能は、デスクトップユーザーが入力しなければならないパスワードの回数を減らすことです Red Hat Enterprise Linux いくつかの主要なアプリケーションは、同じ様な基礎にある承認や認証のメカニズムを活用し、ユーザーがログインスクリーンからログインして、その後そのパスワードを入力する必要はありません。これらのアプリケーションは以下で述べていきます。
更に、ユーザーは、ネットワークがないときや (offline mode) ワイヤレスアクセスなどでネットワークの接続に信頼性がないときでも、自分のマシンにログインできます。後者の場合、サービスは低下します。
以下のアプリケーションが現在のところ Red Hat Enterprise Linux における統合ログインスキームによりサポートされています:
-
ログイン
-
スクリーンセーバー
-
Firefox と Thunderbird
Red Hat Enterprise Linux 現在のところ、以下の認証メカニズムをサポートしています:
-
Kerberos name/password ログイン
-
スマートカード /PIN ログイン
Red Hat Enterprise Linux は、 Cyberflex e-gate カードとリーダーでテストされていますが、 Java card 2.1.1 と Global Platform 2.0.1 の仕様に準じているカードや PCSC-lite によりサポートされているリーダーならどれでも正しく機能するはずです。
Red Hat Enterprise Linux も Common Access Cards (CAC) でテストされてきました。 CAC がサポートしているリーダーは、 SCM SCR 331 USB リーダーです。
As of Red Hat Enterprise Linux 5.2, Gemalto smart cards (Cyberflex Access 64k v2, standard with DER SHA1 value configured as in PKCSI v2.1) are now supported. These smart cards now use readers compliant with Chip/Smart Card Interface Devices (CCID).
現在は、多くのプロトコルやクレデンシャルを使用する非常に多くのセキュリティメカニズムが存在します。例としては、 SSL、 SSH、 IPsec、および Kerberos などです。 Red Hat Enterprise Linux SSO は、上にリストされた要求をサポートするため、これらのスキーマを統合しようとします。これは、 Kerberos を 509v3 の証明書とリプレイスすることを意味していません。むしろ、それらを統合し、両方のシステムのユーザーやそれらを管理する管理者の負担を減らします。
目的を達成する Red Hat Enterprise Linux:
-
それぞれのオペレーティングシステムで NSS 暗合ライブラリの1つの共有されたインスタンスを提供します。
-
ベースのオペレーティングシステムと一緒に、 Certificate System の Enterprise Security Client (ESC) を出荷します。 ESC アプリケーションは、スマートカードの挿入イベントを監視します。もし Red Hat Enterprise Linux Certificate System サーバーとともに使用されるようにデザインされたスマートカードをユーザーが挿入したのを検知すると、ユーザーにインターフェースを表示し、そのスマートカードをどのように登録するかを説明します。
-
Kerberos と NSS を統合すると、スマートカードを使用してオペレーティングシステムにログインするユーザーは、 Kerberos クレデンシャル (これによりファイルサーバー等へのログインを可能にする) を入手します。
スマートカードを使用してシステムにログインして、このテクノロジーが提供する増大したセキュリティオプションの利点を得る前に、いくつかのベーシックインストールと設定を行なう必要があります。これらは以下で説明します。
注記
このセクションは、スマートカードでの入門のハイレベルなビューを提供します。より詳細の情報は、 Red Hat Certificate System Enterprise Security Client Guide で入手可能です。
-
Kerberos の name と password でログインする
-
nss-toolsパッケージがロードされていることを確認してください。 -
会社の仕様のルート証明書をダウンロードしてインストールしてください。ルートの CA 証明書をインストールするには、以下のコマンドを使用してください:
certutil -A -d /etc/pki/nssdb -n "root ca cert" -t "CT,C,C" -i ./ca_cert_in_base64_format.crt
-
以下の RPM がシステムにインストールされていることを確認してください: esc、 pam_pkcs11、 coolkey、 ifd-egate、 ccid、 gdm、 authconfig、 および authconfig-gtk.
-
スマートカードログインのサポートを有効にする
-
Gnome タイトルバーで、 System->Administration->Authentication の順番で選択してください。
-
もし必要でしたら、自分のマシンの root のパスワードを入力してください。
-
認証の設定のダイアログで、 認証 タブをクリックしてください。
-
スマートカードのサポートを有効にする チェックボックスを選択してください。
-
スマートカードの設定... をクリックし、スマートカードの設定のダイアログを表示し、必要な設定を指定してください:
-
ログインにスマートカードを必要とする — このチェックボックスをクリアしてください。スマートカードでログインに成功した後で、スマートカードなしでログインするユーザーを遮断するためにこのオプションを選択することができます。
-
カード削除のアクション — ログインした後にスマートカードを取り出すときに起きることを制御します。利用できるオプションは以下になります:
-
ロック — スマートカードの取り出しは、 X スクリーンをロックします。
-
無視 — スマートカードを取り出すことによる影響はありません。
-
-
-
-
もし Online Certificate Status Protocol (OCSP) を有効にする必要があるなら、
/etc/pam_pkcs11/pam_pkcs11.confファイルを開き、以下のラインを指定してください:enable_ocsp = false;以下のように、値を true に変更してください:
enable_ocsp = true; -
スマートカードの登録
-
もし CAC カードを使用しているなら、以下のステップを実行する必要もあります:
-
root アカウントに変更し、
/etc/pam_pkcs11/cn_mapと呼ばれるファイルを作成してください。 -
cn_mapファイルに以下のエントリを追加してください:MY.CAC_CN.123454->myloginidCAC で
MY.CAC_CN.123454が Common Name だったら、myloginidは自分の UNIX ログイン ID になります。
-
-
ログアウト
スマートカードは、それが有効な認証局 (CA) によって署名された適切な証明書を受け取ったときに enrolled と呼ばれます。これは以下に説明するいくつかのステップを含みます:
-
ワークステーションのスマートカードリーダーにスマートカードを挿入します。このイベントは、 Enterprise Security Client (ESC) により認識されます。
-
ユーザーのデスクトップに登録ページが表示されます。ユーザーは必要な詳細やユーザーのシステムを完了してから、 Token Processing System (TPS) と CA に接続します。
-
TPS は、 CA により署名された証明書を使用してスマートカードを登録します。
このセクションは、スマートカードの使用におけるログインのプロセスの概要を提供します。
-
ユーザーがスマートカードリーダーにスマートカードを挿入するとき、このイベントは、ユーザーに PIN の入力を促す PAM ファシリティにより認識されます。
-
それから、このシステムはユーザーの現在の証明書を検索し、その有効性を確認します。その後、証明書はユーザーの UID とマップされます。
-
KDC に反して、こらは承認され、ログインが許可されました。
注記
登録されていないカードでログインすることはできません。たとえ、それがフォーマットされていてもです。フォーマットされ、登録されたカードか、新しいカードを登録する前にスマートカードを使用しないでログインする必要があります。
Single Sign-on のための Kerberos を使用するために Firefox を設定することができます。この機能が正しく機能するためには、 Kerberos クレデンシャルを KDC に送信するようにウェブブラウザを設定する必要があります。以下のセクションでは、設定変更やこれを実現するための必要条件を説明します。
-
Firefox のアドレスバーで、現在の設定オプションのリストを表示するために
about:configを入力してください。 -
フィルタ フィールドで、オプションのリストを制限するために
negotiateを入力してください。 -
Enter string value ダイアログボックスを表示するために、 network.negotiate-auth.trusted-uris エントリをダブルクリックしてください。
-
例えば、
.example.com等の、認証させたいドメイン名を入力してください。 -
同じドメインを使用して、 network.negotiate-auth.delegation-uris エントリのために上記の手順を繰り返してください。
注記
必須ではありませんが Kerberos チケットを渡すのを許可するので、この値をブランクにすることができます。
もし、リストされているこの2つの設定オプションが見えなかったら、 Firefox のバージョンが、 Negotiate 認証をサポートするには古すぎる可能性があるので、アップグレードを検討すべきです。
Kerberos チケットを持っていることを確認する必要があります。コマンドシェルで、 Kerberos チケットを取得するために kinit を入力してください。利用可能なチケットのリストを表示するには、 klist を入力してください。以下は、これらのコマンドからの出力例を示しています:
[user@host ~] $ kinit
Password for user@EXAMPLE.COM:
[user@host ~] $ klist
Ticket cache: FILE:/tmp/krb5cc_10920
Default principal: user@EXAMPLE.COM
Valid starting Expires Service principal
10/26/06 23:47:54 10/27/06 09:47:54 krbtgt/USER.COM@USER.COM
renew until 10/26/06 23:47:54
Kerberos 4 ticket cache: /tmp/tkt10920
klist: You have no tickets cached
もし上記の設定のステップに従って、 Negotiate 認証が機能していなかったら、認証プロセスの冗長ロギングを ON にすることができます。これにより、問題の原因を発見するのに役立ちます。冗長ロギングを有効にするには、以下の手順に従ってください:
-
Firefox の全てのインスタンスをクローズしてください。
-
コマンドシェルを開き、以下のコマンドを入力してください:
export NSPR_LOG_MODULES=negotiateauth:5 export NSPR_LOG_FILE=/tmp/moz.log
-
シェルから Firefox を再起動し、以前に認証できなかったウェブサイトを訪れてください。情報は
/tmp/moz.logにロギングされ、問題の解決の手掛かりが見つかるかもしれません。例えば:-1208550944[90039d0]: entering nsNegotiateAuth::GetNextToken() -1208550944[90039d0]: gss_init_sec_context() failed: Miscellaneous failure No credentials cache found
これは、 Kerberos チケットを持っていないので、
kinitを起動する必要があることを示しています。
もし自分のマシンから kinit を起動することに成功したのに認証できない場合は、ログファイルに以下のような既述が見えるかもしれません:
-1208994096[8d683d8]: entering nsAuthGSSAPI::GetNextToken() -1208994096[8d683d8]: gss_init_sec_context() failed: Miscellaneous failure Server not found in Kerberos database
これは、一般的に Kerberos の設定の問題を示しています。現在のエントリが /etc/krb5.conf ファイルの [domain_realm] セクションにあることを確認してください。例えば:
.example.com = EXAMPLE.COM example.com = EXAMPLE.COM
もしログに何も出力されなかったら、プロキシの後ろにいて、そのプロキシが Negotiate 認証に必要な HTTP ヘッダーをはく奪している可能性があります。ワークアラウンドとしては、代わりに要求を変更することなく渡すことができる HTTPS を使用してサーバーへの接続を試みてください。それから、上記のようにログファイルを使用してデバッグしてください。
ユーザーにシステムへのアクセスを認可するプログラムは 認証 を使用して、お互いの身元を確認します。 (これはユーザーが本人であると言うことを識別すると言うことです)。
過去には各プログラムが、ユーザー認証の為にそれ独自の手段を持っていました。 Red Hat Enterprise Linux では、多くプログラムが Pluggable Authentication Modules あるいは PAM と呼ばれる中央化された認証プロセスを使用するように設定されています。
PAM のプラグイン可能なモジュラー構造を用いることによって、システム管理者は担当のシステム用の認証ポリシー設定に多大の柔軟性を持つことが出来ます。
ほとんどの場合、 PAM 認識アプリケーションのために PAM 設定ファイルを変更する必要はありません。但し、場合によっては PAM 設定ファイルを編集する必要がでることがあります。 PAM の設定が間違っているとシステムセキュリティへの侵害につながりますので、変更をする前に、これらのファイルの構造を理解することが重要になります。詳細は 項25.4.3. 「PAM 設定ファイルの形式」 を参照して下さい。
PAM は以下のような利点を提供します：
-
幅広い各種アプリケーションで使用できる共通の認証設定です。
-
システム管理者やアプリケーション開発者に、認証に対する優れた柔軟性と制御性を与えます。
-
自身の認証プランを作成することなく、開発者がプログラムを書くことができるようにする単独の完全文書化されたライブラリ。
/etc/pam.d/ ディレクトリには、 PAM 認識アプリケーションのための、 PAM 設定ファイルがあります。 PAM の初期のバージョンでは、 /etc/pam.conf ファイルが使用されていました。しかし、このファイルはあまり使用されなくなってきており、現在は /etc/pam.d/ ディレクトリが存在しない場合に限って使用されます。
各 PAM 設定ファイルには、次のようなフォーマットされたディレクティブのグループが含まれています：
<module interface><control flag><module name><module arguments>
これらの各要素はそれぞれ次のセクションで説明してあります。
4 つのタイプの PAM モジュールインターフェースがあり、それぞれ認証プロセスの異なる側面に相当しています：
-
auth— このモジュールインターフェースはその使用を認証します。例えば、パスワードの有効性を要求して、それを確証します。このインターフェースのモジュールは、グループメンバーシップや、 Kerberos チケットなどの証明書も設定できます。 -
account— このモジュールインターフェースは、アクセスが許可されることを確認します。例えば、ユーザーのアカウントが期限切れでないか、あるいはユーザーがその日の特定時期にログインを認められているか、をチェックします。 -
password— このモジュールインターフェースは、ユーザーパスワードの変更に使用されます。 -
session— このモジュールインターフェイスは、ユーザーセッションを設定して管理します。このインターフェースのモジュールは、ユーザーのホームディレクトリのマウントやユーザーのメールボックスを使用可能にするなど、アクセスの許可に必要な追加のタスクも実行することができます。
注記
個々のモジュールはすべてのモジュールインターフェースあるいはそのいずれかを提供することができます。例えば、 pam_unix.so は 4 つのモジュールインターフェースをすべて提供できます。
PAM 設定ファイルでは、モジュールインターフェースは最初に定義されるフィールドです。例えば、設定内の標準的な行は次のようになります：
auth required pam_unix.so
これは PAM に対して pam_unix.so モジュールの auth インターフェースを使用するように指示しています。
モジュールインターフェースディレクティブは、 スタック できます、つまり次々に積み重ねることができるので1つの目的の為に複数のモジュールが一緒に使用できます。１つのモジュール制御フラグが 「sufficient」 か 「requisite」の値を使用すると (詳細は 項25.4.3.2. 「制御フラグ」 を参照)、認証プロセスにおいて、モジュールがリストされる順序は非常に重要になります。
スタックにより、管理者がユーザーに認証を与える前に存在すべき特定の条件を要求することが容易になります。例えば、 reboot コマンドは、以下の PAM 設定ファイルで示してあるように、通常、数種のスタックされたモジュールを使用します：
[root@MyServer ~]# cat /etc/pam.d/reboot #%PAM-1.0 auth sufficient pam_rootok.so auth required pam_console.so #auth include system-auth account required pam_permit.so
-
最初の行はコメントであり、プロセスされません。
-
auth sufficient pam_rootok.so— この行はpam_rootok.soモジュールを使用して、その UID が 0 であることを確認して、現在のユーザーが root かどうかをチェックします。このテストが成功すると、他のモジュールに依存せずに、このコマンドが実行されます。テストが失敗すると次のモジュールに依託されます。 -
auth required pam_console.so— この行はユーザーを認証するのにpam_console.soモジュールを使用します。このユーザーがすでにコンソールでログインしている場合は、pam_console.soは、/etc/security/console.apps/ディレクトリ内にサービス名 (reboot) と同じ名前を持ったファイルがあるかどうかをチェックします。そのようなファイルが存在すれば、認証は確定され、制御は次のモジュールに渡されます。 -
#auth include system-auth— この行はコメント化されており、プロセスされません。 -
account required pam_permit.so— この行はpam_permit.soモジュールを使用して、 root ユーザー、又はコンソールにログインしてシステムをリブートする人に許可を与えます。
すべての PAM モジュールは、コールがあると成功又は失敗の結果を生成します。制御フラグは、その結果に対する処理方法を PAM に告げます。モジュールは特定の順序でスタックされるので、制御フラグは、ユーザーにそのサービスへの認証をすることの全体的目的に対して、この特定のモジュールの成功あるいは失敗の重要度を判定します。
4つのタイプの制御フラグが定義されています：
-
required— 認証が続行するにはモジュールの結果は成功でなければいけません。テストがこの時点で失敗の結果を出すと、インターフェースを参照している全てのモジュールが完了するまで、ユーザーは結果報告を受け取りません。 -
requisite— 認可が続行するにはモジュールの結果は成功でなければいけません。但し、この時点でテストが失敗した場合、ユーザーは直ちに最初に失敗したrequired、 あるいはrequisiteモジュールテストに関するメッセージを受け取ります。 -
sufficient— チェックが失敗した場合、モジュールの結果は無視されます。ただし、sufficientフラグのモジュールのチェックが成功し、 且つ 、それ以前のrequiredフラグのモジュールがすべて成功した場合、これ以外の結果は必要とされず、ユーザーはそのサービスに対して認証されます。 -
optional— モジュールの結果は無視されます。認証の成功にoptionalフラグのモジュールが必要となるのは、そのインターフェースを参照する他のモジュールがない時だけです。
重要
required モジュールがコールされる順序は重要ではありません。 sufficient と requisite の制御フラグでのみその順序が重要になります。
より正確な制御を可能にする新しい制御フラグ構文が現在 PAM で利用できます。
pam.d の man ページと PAM ドキュメントは /usr/share/doc/pam- ディレクトリにあります。 <version-number>/<version-number> とは、ご使用の PAM のバージョンであり、この最新構文を詳細に説明しています。
モジュール名は、特定のモジュールインターフェースを含むプラグ可能なモジュール名を PAM に提供します。 Red Hat Enterprise Linux の旧バージョンでは、モジュールへのフルパスが PAM 設定ファイル内に提供されていました。しかし、 /lib64/security/ ディレクトリ下に 64ビット PAM モジュールを保存する multilib の出現により、アプリケーションがモジュールの正しいバージョンを検索する適切な libpam のバージョンにリンクされるため、そのディレクトリ名は省略されています。
PAM は、幾つかのモジュール用に認証をしている間、プラグ可能なモジュールへ情報を渡すために 引数 を使用します。
たとえば、 pam_userdb.so モジュールは、 Berkeley DB ファイルに保存された情報を使ってユーザーを認証します。 Berkeley DB は、多くのアプリケーションに組み込まれているオープンソースのデータベースシステムです。このモジュールが db 引数を使用することによって Berkeley DB は要求されたサービスに使用するデータベースを判断できます。
以下に PAM 設定ファイルの標準的な pam_userdb.so 行を示します。 <path-to-file> は Berkeley DB データベースファイルへのフルパスです:
auth required pam_userdb.so db=<path-to-file>
無効な引数は 一般的に 無視され、 PAM モジュールの成功あるいは失敗のどちらにも影響しません。但し、いくらかのモジュールでは無効な引数で失敗します。殆んどのモジュールはエラーを /var/log/secure ファイルに報告します。
以下に、 PAM アプリケーションの設定ファイルのサンプルを示します:
#%PAM-1.0 auth required pam_securetty.so auth required pam_unix.so nullok auth required pam_nologin.so account required pam_unix.so password required pam_cracklib.so retry=3 password required pam_unix.so shadow nullok use_authtok session required pam_unix.so
-
最初の行はコメントであり、行頭に「
#」マークが付加されています。 -
2行目から4行目ではログイン認証のモジュールを3つスタックしています。
auth required pam_securetty.so— このモジュールは もし ユーザーが root としてログインを試行し、 tty ファイルが存在する場合、/etc/securettyファイル内にユーザーがログインした tty が一覧表示されていることを確認します。ファイル内に tty リストされていないと、 root としてのログインは
Login incorrectのメッセージが出て失敗します。auth required pam_unix.so nullok— このモジュールはユーザーにパスワードを要求して、/etc/passwdに保存されている情報を使用してそのパスワードをチェックします。パスワードが存在する場合、/etc/shadowをチェックします。 -
auth required pam_nologin.so— これが最終認証ステップです。/etc/nologinファイルが存在するかどうかを確認します。ファイルが存在し、ユーザーが root でない場合、認証は失敗します。注記
この例では、最初の
authモジュールが失敗しても、3つのauthモジュールすべてがチェックされます。これはユーザーに、認証のどの段階で拒否されたかを悟られないようにするためです。そのような情報がアタッカーに使用可能になると、彼らにシステムをクラックする方法をたやすく類推する事を許します。 -
account required pam_unix.so— このモジュールで、必要なアカウントの確証が実行されます。たとえば、シャドウパスワードが有効な場合、pam_unix.soモジュールのアカウントインターフェイスは、アカウントの期限が切れていないか、ユーザーがパスワード猶予期間内にパスワードを変更していないかをチェックします。 -
password required pam_cracklib.so retry=3— パスワードの期限が切れている場合、pam_cracklib.soモジュールのパスワードコンポーネントは新しいパスワードの要求をします。それから、新規に作成されたパスワードに対してテストを実行することにより、それがパスワードに対する辞書ベースのクラックプログラムによって簡単に判明するものでないことを確認します。-
引数
retry=3はテストが最初に失敗した場合、ユーザーは牽強なパスワードを作成するのに２回のチャンスを与えられるように指定します。
-
-
password required pam_unix.so shadow nullok use_authtok— この行は、プログラムがユーザーのパスワードを変更する場合、それは、pam_unix.soモジュールのpasswordインターフェイスを使用して実行する必要があることを指定しています。-
引数
shadowはモジュールに対し、ユーザーのパスワードが更新される時にシャドーパスワードを作るように指示します。 -
引数
nullokは、モジュールにユーザーがパスワードをブランク から 変更するのを許可するように指示します。さもなければ、ブランクのパスワードは固定アカウントとして取り扱われます。 -
この行の最後の引数、
use_authtokは、 PAM モジュールのスタック順の重要性を示す良い例を提供します。この引数は、モジュールに対し、ユーザーの新しいパスワードを求めないように伝えます。その代わりに、それ以前のパスワードモジュールで記録されたいかなるパスワードも受け入れます。この方法では、全ての新しいパスワードが、受け入れられる前にセキュアなパスワードとしてpam_cracklib.soテストをパスしなければいけません。
-
-
session required pam_unix.so— 最後の行は、pam_unix.soモジュールのセッションインターフェイスに対し、セッションを管理することを指示しています。このモジュールは、各セッションの始めと終りで、/var/log/secureにユーザー名とサービスタイプのログを残します。このモジュールは他の機能の為に、他のセッションモジュールにスタックする事で補充できます。
PAM 認識のアプリケーションを使用する為に、いつでも PAM モジュールの作成、又は追加をすることができます。
例えば、開発者が1回制限のパスワード作成法を作り、そのサポートの為に PAM モジュールを書いた場合、 PAM-認識プログラムは、リコンパイルや他の修正なしに直ちにその新しいモジュールとパスワードの方法を使用できます。
これにより開発者とシステム管理者は、リコンパイルの必要なく、異るプログラム用の認証手法をテストするだけでなく、組み合わせて混ぜることもできるようになります。
モジュールを書くことに関するドキュメントは /usr/share/doc/pam- ディレクトリに含まれています。この <version-number>/<version-number> は、ご使用のシステムにある PAM のバージョン番号です。
Red Hat Enterprise Linux の各種グラフィック管理ツールは、 pam_timestamp.so モジュールを使用してユーザーに特権を 5 分間まで延長することができます。 pam_timestamp.so が有効になっている間にユーザーがターミナルから離れると、マシンを誰でもコンソールに物理的にアクセスして操作が行なえるような状態にするため、この機能の仕組みを理解しておくことが重要です。
PAM タイムスタンプ計画では、グラフィック管理アプリケーションはその起動時に、ユーザーに root パスワードを要求します。認証されると、 pam_timestamp.so モジュールはデフォルトで /var/run/sudo/ ディレクトリ配下にタイムスタンプファイルを作成します。タイムスタンプファイルがすでに存在している場合は、グラフィック管理プログラムはパスワードを要求せず、代わりに、 pam_timestamp.so モジュールはタイムスタンプファイルを更新して、ユーザーに絶対的な管理アクセス権をさらに 5 分間確保します。
タイムスタンプの実際の状態は、 /var/run/sudo/<user> ファイルを検証することで確認できます。デスクトップには、その関連ファイルは unknown:root です。それが存在して、そのタイムスタンプが 5 分よりも少ない場合に、証明書は有効です。
タイムスタンプファイルの存在は、パネルの通知エリア内に現われる認証アイコンで示されます。
PAM タイムスタンプが有効になっているコンソールから離れる場合、タイムスタンプファイルを破棄することをおすすめします。グラフィッカル環境でこれを行なうには、パネルの認証アイコンをクリックします。これでダイアログボックスが現われたら、 認証を無視(Forget Authorization) ボタンをクリックします。
PAM タイムスタンプファイルの次のような側面に注意して下さい :
-
sshを使用して遠隔からシステムにログインしている場合、/sbin/pam_timestamp_check -k rootコマンドを使用してタイムスタンプを破棄します。 -
/sbin/pam_timestamp_check -k rootは特権アプリケーションを起動したのと同じターミナルから実行する必要があります。 -
/sbin/pam_timestamp_check -kコマンドを使用するためには、最初にpam_timestamp.soを呼び出したユーザーとしてログインする必要があります。 root でログインしてこのコマンドを発行しないでください。 -
(アイコン上の Forget Authorization を使用しないで) デスクトップ上の証明書をキルしたい場合には、以下のコマンドを使用します:
/sbin/pam_timestamp_check -k root </dev/null >/dev/null 2>/dev/null
このコマンドの使用に失敗すると、このコマンドを実行する場所の pty から (ある場合は) 証明書を取り除くことになります。
pam_timestamp_check を使用してタイムスタンプファイルを破棄する方法についての詳細は、 pam_timestamp_check の man ページを参照してください。
pam_timestamp.so モジュールはいくつか異なるディレクティブを受け取ります。以下に最もよく使われるオプションを2つあげます:
-
timestamp_timeout— タイムスタンプファイルが有効になっている期間を秒数で指定します。デフォルト値は 300 秒 (５分間) です。 -
timestampdir— タイムスタンプファイルが保存されるディレクトリを指定します。デフォルト値は/var/run/sudoです。
pam_timestamp.so モジュールの操作方法についての詳細は、 項25.4.8.1. 「インストールされているドキュメント」 を参照してください。
Red Hat Enterprise Linux では、マシンの物理的コンソール上にログインする最初のユーザーはデバイスの操作や特殊タスクの実行など通常は root ユーザー用に保存してある能力を許可します。これは pam_console.so と呼ばれる、 PAM モジュールによって制御されるものです。
Red Hat Enterprise Linux システムにユーザーがログインすると、 pam_console.so モジュールが login またはグラフィカルログインプログラム gdm と kdm と xdm によって呼び出されます。このユーザーが物理的なコンソール —コンソールユーザー と呼ばれる — でログインする最初のユーザーの場合、モジュールは通常ルートに所有される様々なデバイスの所有権をこのユーザーに許可します。このユーザーの最後のローカルセッションが終了するまで、コンソールユーザーはこれらデバイスの所有権を持ちます。このユーザーがログアウトすると、デバイスの所有権は root ユーザーに戻ります。
これに影響され、しかしそれだけに制限されていない状態のデバイスにはサウンドカード、フロッピードライブ、 CD-ROM ドライブです。
この機能により、ローカルユーザーはルートアクセスを取得せずに、これらデバイスの操作ができるようになります。このようにして、コンソールユーザーのための一般的なタスクを単純化しています。
以下のファイルを編集することで、 pam_console.so で制御されるデバイスのリストを変更することができます:
-
/etc/security/console.perms -
/etc/security/console.perms.d/50-default.perms
上記のファイルに記載されているものとは別のデバイスの権限を変更したり、又は特定のデフォルトを書き変えたりすることができます。 50-default.perms ファイルを変更する代わりに、新しいファイルを作成 (例えば、xx-name.perms51-default.perms)。これが 50-default.perms ファイル内のデフォルトを書き変えます。
警告
gdm、 kdm、 または xdm のディスプレイマネージャ設定ファイルがリモートユーザーにログインを許可するように変更されていて、 且つ ホストがランレベル 5 で実行するよう設定されている場合、 /etc/security/console.perms 内の <console> と <xconsole> ディレクティブを以下の値に変更することが推奨されます:
<console>=tty[0-9][0-9]* vc/[0-9][0-9]* :0\.[0-9] :0 <xconsole>=:0\.[0-9] :0
これで、リモートユーザーがマシン上のデバイスや制限アプリケーションへアクセスするのを防止します。
gdm、 kdm、 または xdm のディスプレイマネージャ設定ファイルがリモートユーザーにログインを許可するよう変更されていて、 且つ ホストがランレベル 5 以外でいずれかの複数ユーザーランレベルでも実行するように 設定されている場合には、 <xconsole> ディレクティブを完全に削除して、 <console> ディレクティブを次の値に変更することが推奨されます:
<console>=tty[0-9][0-9]* vc/[0-9][0-9]*
コンソールユーザーはさらに /etc/security/console.apps/ ディレクトリ内で使用するように設定された特定のプログラムにアクセスを許可されます。
このディレクトリには、コンソールユーザーが /sbin と /usr/sbin 内の特定のアプリケーションを実行できるようにする設定ファイルが含まれています。
これらの設定ファイルはそれらがセットするアプリケーションと同じ名前を持ちます。
コンソールユーザーがアクセスを持つ注意すべきアプリケーショングループの一つは、システムを終了または再起動する3つのプログラムです。以下に示します:
-
/sbin/halt -
/sbin/reboot -
/sbin/poweroff
これらは PAM-認識アプリケーションであるため、使用要求として pam_console.so モジュールをコールします。
詳細については、 項25.4.8.1. 「インストールされているドキュメント」 を参照してください。
以下のリソースには、 PAM の使用と設定方法に関する詳細な説明があります。これらのリソースの他に、 PAM の設定ファイルがどの様に構成されているかを理解する為にシステム上の PAM の設定ファイルを読んで下さい。
-
PAM に関する man ページ — PAM に関連した各種アプリケーションや設定ファイルの man ページが存在します。なかでも、重要と思われる man ページを以下に一覧にします。
- 設定ファイル
-
-
pam— PAM 設定ファイルの構造とその目的を含む、 PAM の適切な入門情報です。この man ページは、
/etc/pam.d/ディレクトリ内の/etc/pam.confと個別の設定ファイルの両方について説明しています。デフォルトでは、 Red Hat Enterprise Linux は/etc/pam.confが存在している場合でも、それを無視して/etc/pam.d/ディレクトリ内の個別設定ファイルを使用します。 -
pam_console—pam_console.soモジュールの目的について説明しています。また、 PAM 設定ファイルで使用するエントリの適切な構文についても触れています。 -
console.apps— 設定ファイルの/etc/security/console.apps内で使用できる形式とオプションについて説明しています。この設定ファイルは、 PAM で割り当てられたコンソールユーザーがどのアプリケーションにアクセス可能かを定義します。 -
console.perms— PAM で割り当てられたコンソールユーザーの権限用の/etc/security/console.perms設定ファイル内で使用できる形式とオプションを説明しています。 -
pam_timestamp—pam_timestamp.soモジュールについて説明しています。
-
-
/usr/share/doc/pam-— これには システム管理者ガイド、モジュールライターガイド、アプリケーション開発者ガイド、及び、 PAM 標準のコピー、 DCE-RFC 86.0 が含まれています。ここで、<version-number><version-number>は PAM のバージョン番号です。 -
/usr/share/doc/pam-—<version-number>/txts/README.pam_timestamppam_timestamp.soの PAM モジュールに関連した情報が含まれています。<version-number>は、 PAM のバージョン番号です。
-
http://www.kernel.org/pub/linux/libs/pam/ — Linux-PAM プロジェクトのための初期配布 Web サイト。さまざまな PAM モジュール、 FAQ 、追加の PAM マニュアルの情報が含まれます。
注記
上記ウェブサイトのドキュメントは、 PAM に関する最後のリリースのアップストリームバージョンであるため、 Red Hat Enterprise Linux 内に収納されている PAM バージョンにとっては 100% 正確ではないかもしれません。
ネットワークサービスへのアクセス制御は、サーバー管理者にとって最も重要なセキュリティタスクのひとつです。 Red Hat Enterprise Linux には、アクセスの制御を行なうツールがいくつかあります。例えば、 iptables ベースのファイアウォールは、カーネルのネットワークスタック内で、歓迎できないネットワークパケットをフィルタ阻止します。これを利用するネットワークサービスに、 TCP ラッパー は、どのホストが "ラップした" ネットワークサービスに接続を許可されるか、許可されないかを定義することにより、追加の保護層を加えます。ラップしたネットワークサービスの1つは、 xinetdスーパーサーバー です。このサービスがスーパーサーバーと呼ばれる理由は、それがネットワークサービスのサブセットへの接続を制御して、アクセス制御をより向上するからです。
図 25.9. 「ネットワークサービスへのアクセス制御」 は、これらのツールがどのようにしてネットワークサービスを一緒に保護するかの基本的な描写をしています。
TCP ラッパーパッケージは (tcp_wrappers) デフォルトでインストールされ、ネットワークサービスに対しホストベースのアクセス制御を提供します。パッケージ内で最も重要なコンポーネントは /usr/lib/libwrap.a ライブラリです。一般的な表現では、 TCP でラップしたサービスは、 libwrap.a ライブラリに対してコンパイルされたものを指します。
TCP ラップのサービスに接続の試行があった場合、そのサービスは最初にホストアクセスファイル (/etc/hosts.allow および /etc/hosts.deny) を参照して、クライアントホストが接続を許可されているかどうかを判定します。ほとんどの場合、その後、 syslog デーモン (syslogd) を使用して /var/log/secure 又は /var/log/messages へその要求しているホスト名と要求サービスを書き込みます。
もし、クライアントホストが接続を許可された場合、 TCP ラッパーは要求されたサービスへの接続制御を開放し、それ以上クライアントホストとサーバーとの間の通信を邪魔しません。
アクセスの制御とロギングに加えて、 TCP ラッパーは先ずクライアントと折衝をするためのコマンドを起動して、それから要求されたネットワークサービスへの接続を拒否するか、制御の開放をします。
いずれのサーバー管理者にとっても数々の強力なセキュリティツールに加えて TCP ラッパーは役立つツールとなるので、 Red Hat Enterprise Linux 内の殆どのネットワークサービスは libwrap.a ライブラリに対してリンクされています。このようなアプリケーションには、 /usr/sbin/sshd 、 /usr/sbin/sendmail 、 /usr/sbin/xinetd などがあります。
注記
ネットワークサービスバイナリが libwrap.a に対してリンクされているかどうか判定するには、 root ユーザーとして以下のコマンドを入力します：
ldd <binary-name> | grep libwrap
<binary-name> にはネットワークサービスバイナリの名前を入れてください。
コマンドがアウトプットなしに直接プロンプトに戻ってきた場合、そのネットワークサービスは libwrap.a に対して リンクされていません 。
下記の例は /usr/sbin/sshd は libwrap.a にリンクしていることを示しています：
[root@myserver ~]# ldd /usr/sbin/sshd | grep libwrap
libwrap.so.0 =
> /usr/lib/libwrap.so.0 (0x00655000)
[root@myserver ~]#
TCP ラッパーは、他のネットワークサービス制御技術と比較して以下のような利点を持っています：
-
クライアントホストとラップしたネットワークサービス間の透視度 — 接続しようとしているクライアントとラップしたネットワークサービスからは TCP ラッパーが使用されているかどうか知ることができません。正式なユーザーは要求したサービスへログインして接続しますが、禁止されたクライアントからの接続は失敗します。
-
複数プロトコルの中央管理 — TCP ラッパーは、それが保護するネットワークサービスからは別に稼働するため、多くのサーバーアプリケーションは簡素な管理用設定ファイルの共通セットを共有することが出来ます。
サービスにクライアントマシンが接続を許可されるかどうか決定するために、 TCP ラッパーは次の2つのファイルを参照します。これは一般的に ホストアクセス ファイルと呼ばれるものです：
-
/etc/hosts.allow -
/etc/hosts.deny
TCP でラップしたサービスはクライアントの要求を受け取ったとき、以下の処置を実行します：
-
/etc/hosts.allowを参照する。 — TCP ラップしたサービスは順番に/etc/hosts.allowファイルを構文解析して、そのサービスに指定されている最初の規則を適用します。適合する規則があれば、接続を許可します。そうでなければ、次のステップへと移動します。 -
/etc/hosts.denyを参照する。 — TCP ラップしたサービスは順番に/etc/hosts.denyファイルを構文解析します。適合する規則があれば、接続は拒否されます。そうでなければ、そのサービスへのアクセスは認可されます。
TCP ラッパーを使用してネットワークサービスを保護する場合、次の重要な点を考慮する必要があります:
-
hosts.allow内のアクセスの規則が最初に適用される為、これらの規則はhosts.deny内に指定してある規則より優先されます。そのため、hosts.allowでサービスへのアクセスが許可された場合、hosts.denyの同じサービスに対するアクセス拒否の規則は無視されます。 -
各ファイル内の規則が上から下に読まれ、１つのサービスに対して適用されるのは最初に適合する規則の1つだけです。したがって、規則の配置順序は非常に重要です。
-
どちらのファイルにもそのサービス用の規則がない場合、あるいはどちらのファイルも存在しない場合、そのサービスへのアクセスは承認されます。
-
TCP ラップのサービスは、ホストのアクセスファイル規則をキャッシュしません。そのため、
hosts.allowまたはhosts.denyへの変更は、ネットワークサービスを再開始しなくても直ちに反映されます。
警告
ホストアクセスファイルの最後の行が改行マーク (Enter キーを押すと出るマーク) ではない場合、そのファイル内の最後の規則は失敗してエラーが /var/log/messages か /var/log/secure にログされます。また、行が逆スラッシュを使用せずに複数行にまたがる場合も同様です。次の例では、このどちらかの状況による規則違反についてのログメッセージの関連部分を表示します:
警告: /etc/hosts.allow, line 20: 改行の欠落または行が長すぎる
/etc/hosts.allow と /etc/hosts.deny のフォーマットは全く同じです。各規則はその独自の行になければなりません。 (#) マークで始まる行、又は空白行はすべて無視されます。
それぞれの規則は以下のような基本フォーマットを使用してネットワークサービスへのアクセスを制御します：
<daemon list>:<client list>[:<option>:<option>: ...]
-
<daemon list>— プロセス名 (サービス名ではない) 、または、全てのワイルドカードのカンマで区切られたリスト。また、デーモンリストには演算子を入れてより高い柔軟性を与えることができます。 (項25.5.2.1.4. 「演算子」 を参照)。 -
<client list>— ホスト名や、ホスト IP アドレスや、特殊パターンや、規則により影響するホストを識別するワイルドカードのカンマで区切られたリストです。また、クライアントリストには、 項25.5.2.1.4. 「演算子」 に記載されている演算子を入れてより高い柔軟性を与えることもできます。 -
<option>— 規則が発動された時に実施される1つのオプション動作、又はカンマで区切られた複数動作のリスト。オプションのフィールドは拡張のサポート、シェルコマンドの起動、アクセスの許可/拒否、ロギング動作の変更などを行ないます。
注記
上記の専門用語についての詳細は、このガイドの中でみることができます：
以下に基本的なホストのアクセス規則のサンプルを示します：
vsftpd : .example.com
この規則は、 example.com ドメインのホストすべてからの FTP デーモン (vsftpd) への接続を監視するよう TCP ラッパーに指示します。この規則が hosts.allow にある場合は、その接続は許可されます。この規則が hosts.deny にある場合は、その接続は拒否されます。
次のホストアクセス規則のサンプルは更に複雑で、2つのオプションフィールドを使用します。
sshd : .example.com \ : spawn /bin/echo `/bin/date` access denied>>/var/log/sshd.log \ : deny
各オプションフィールドが逆スラッシュ (\) の後に始まっていることに注意してください。逆スラッシュの使用は、長さによる規則違反を防止します。
このサンプルの規則は、 SSH デーモン (sshd) への接続が、 example.com ドメインのあるホストからの試行である場合、特別ファイルへの試行をログするために echo コマンドを実行して、接続を拒否するようになっています。オプションの deny ディレクティブが使用されている為、それが hosts.allow ファイル内に存在しても、この行はアクセスを拒否します。利用できるオプションの詳細は 項25.5.2.2. 「オプションフィールド」 を参照してください。
ワイルドカードの使用により、 TCP ラッパーはデーモンやホストのグループをより簡単に照合できます。これらはアクセス規則のクライアントリストフィールドの中で多く使用されます。
以下のようなワイルドカードが使用できます：
-
ALL— すべてを照合します。これはデーモンリストとクライアントリストの両方に使用できます。 -
LOCAL— ローカルホストなど、ピリオド (.) のないホストをすべて照合します。 -
KNOWN— ホスト名、ホストアドレス、あるいはユーザーが既に判っているホストを照合します。 -
UNKNOWN— ホスト名、ホストアドレス、あるいはユーザーが不明なホストをすべて照合します。 -
PARANOID— ホスト名とホストアドレスが一致しないホストをすべて照合します。
注意
KNOWN 、 UNKNOWN 、 PARANOID のそれぞれのワイルドカードは、正しい操作のために DNS サーバーを機能させることに依存しているので注意して使用してください。名前解決中で問題となると正式なユーザーがサービスへのアクセスを取得するのを阻止する可能性があります。
パターンは、アクセス規則のクライアントリストのフィールドに使用して、クライアントホストのグループをより正確に指定します。
以下は、クライアントフィールドの入力でよく見かけるパターンの一覧です:
-
ピリオド (.) で始まるホスト名 — ホスト名の先頭にピリオドを付けると、入力されたその名前の構成部分を共有するすべてのホストを照合します。以下の例は、
example.comドメイン内のすべてのホストに適用されます:ALL : .example.com
-
ピリオド (.) で終了する IP アドレス — ピリオドを IP アドレスの末尾に置くと、ある IP アドレスの最初の数字のグループを共有するすべてのホストを照合します。次の例は、
192.168.x.xネットワーク内のすべてのホストに適用されます。ALL : 192.168.
-
IPアドレス/ネットマスクの組合せ — ネットマスク表現も IP アドレスの特定グループに対するアクセスを制御する為に、パターンとして使用することができます。次の例は、
192.168.0.0から192.168.1.255までのアドレス幅を持つすべてのホストに適用されます。ALL : 192.168.0.0/255.255.254.0
重要
IPv4 アドレススペースで動作しているとき、アドレス/プレフィックスの長さ (prefixlen) の組み合わせ申告 (CIDR ノーテーション) はサポートされません。 IPv6 の規則しかこの形式を使用することができません。
-
[IPv6 アドレス]/prefixlen の組合せ — [net]/prefixlen の組合せもパターンとして、 IPv6 アドレスの特定グループへのアクセスを制御するために使用することができます。次の例は、
3ffe:505:2:1::から3ffe:505:2:1:ffff:ffff:ffff:ffffまでのアドレス幅内のすべてのホストに適用します:ALL : [3ffe:505:2:1::]/64
-
アスタリスク(*)— アスタリスクはホスト名のグループや IP アドレスの全体を照合するのに使用されます。これは他のタイプのパターンを含むようなクライアントリストが混合していない場合に有効です。次の例では、
example.comドメイン内の全てのホストに適用されます：ALL : *.example.com
-
スラッシュ(/) — クライアントリストがスラッシュで始まる場合、それはファイル名として取り扱います。これは、多量のホストを指定する規則が必要な場合に役に立つものです。次の例では、全ての Telnet 接続の為の
/etc/telnet.hostsファイルへの TCP ラッパーを対称にしています：in.telnetd : /etc/telnet.hosts
TCP ラッパーで認可されるパターンには、他に使用頻度の低いものがあります。詳細については hosts_access の man 5 ページを参照してください。
警告
ホスト名とドメイン名を使用するときは、十分に注意をしてください。攻撃者は多様なトリックを使って、正確な名前解決を邪魔します。また、 DNS サービスにおける妨害は、権限のあるユーザーでさえもネットワークサービスが使用できないようにしてしまいます。それ故、可能であればいつでも IP アドレスを使用するのが最善の策です。
TCP ラッパーの Portmap 実装はホストルックアップをサポートしません。それは、 portmap はホストを識別するためにホスト名を使用できないことを意味します。その結果、 hosts.allow または hosts.deny 内のポートマップのアクセス制御規則は、 IP アドレスまたはホストを指定するためにキーワード ALL を使用しなければなりません。
また、 portmap アクセスコントロール規則への変更は、 portmap サービスを再起動させないとすぐには反映されない場合があります。
NIS や NFS など幅広く使用されているサービスは portmap に依存して運用されているので、これらの制限に気をつけて下さい。
現在、アクセス制御規則は、1つの演算子、 EXCEPT を受け付けます。これはデーモンリストと規則内のクライアントリストで使用できます。
EXCEPT 演算子の使用により、同じ規則内でより幅広い照合への特別な拡張が可能になります。
次の hosts.allow ファイルからの例では、 cracker.example.com 以外の全ての example.com ホストからの、全てのサービスへの接続が許可されます：
ALL: .example.com EXCEPT cracker.example.com
もう1つの hosts.allow ファイルからの例では、 192.168.0. のネットワークからのクライアントは FTP 以外は、すべてのサービスを使用できます：
x
ALL EXCEPT vsftpd: 192.168.0.
注記
組織的には、 EXCEPT 演算子の使用を避けた方が管理が楽なことが多く、これにより、他の管理者が、 EXCEPT 演算子をソートせずに、どのホストがサービスに対するアクセスを許可/拒否されるべきかを判断するのに該当ファイルをすばやく調べることができます。
アクセスの許可と拒否についての基本的な規則の他に、 TCP ラッパーの Red Hat Enterprise Linux 実装は オプションフィールド を通じてアクセス制御言語への拡張をサポートしています。ホストアクセス規則内のオプションフィールドを使用することにより、管理者はログの動作の変更、アクセス制御の確定、及びシェルコマンドの始動などの各種タスクを達成することが出来ます。
オプションフィールドにより管理者は、 severity ディレクティブを使用してログ設備と規則の優先度を簡単に変更することができます。
以下の例では、 example.com ドメインのいずれのホストからの SSH デーモンへの接続も、 emerg の優先度を持つデフォルトの authprivsyslog 設備 (設備値が指定されていない為) にログされます。
sshd : .example.com : severity emerg
severity オプションを使用して設備を指定することもできます。次の例では、 alert の優先度を持つ local0 > 設備への example.com ドメインのホストによる SSH サービス接続の試行をログします：
sshd : .example.com : severity local0.alert
注記
実際には、この例は local0 設備へ syslog デーモン (syslogd) がログするように設定されるまで機能しません。カスタムログ設備の設定に関する詳細については syslog.conf の man ページをお読み下さい。
オプションフィールドにより、管理者は allow 又は deny ディレクティブを最終オプションとして追加することで、1つの規則内で明確に許可、あるいは拒否ができるようになります。
例えば、次の2つの例は、 client-1.example.com からの SSH 接続を許可しますが、 client-2.example.com からの接続を拒否します：
sshd : client-1.example.com : allow sshd : client-2.example.com : deny
アクセス制御を規則単位ベースで許可することにより、オプションフィールドは管理者が全てのアクセス規則を1つのシングルファイル、 hosts.allow 、又は hosts.deny に統合できるようにします。一部の管理者にとってはこの方法がアクセス規則を簡単に構成させてくれるでしょう。
オプションフィールドにより、アクセス規則は次の2つのディレクティブを通じてシェルコマンドを始動できます：
-
spawn— シェルコマンドを子プロセスとして始動できます。このディレクティブは/usr/sbin/safe_fingerの使用などのタスクを実行し、要求しているクライアントの情報を得たり、echoコマンドを使用して特殊なログファイルを作成したりします。次の例では、
example.comドメインから Telnet サービスへアクセスを試行するクライアントは、密かに特殊なファイルにログされます：in.telnetd : .example.com \ : spawn /bin/echo `/bin/date` from %h>>/var/log/telnet.log \ : allow -
twist— 要求されたサービスを指定されたコマンドで入れ換えます。このディレクティブは侵入者に対する仕掛け (「蜜の壷」といいます) をするのによく使用されます。また接続しているクライアントにメッセージを送信するためにも使用されます。twistディレクティブは、規則行の末尾に置く必要があります。以下の例では、
example.comドメインから FTP サービスへアクセスを試行しているクライアントがechoコマンドによりメッセージを送ります:vsftpd : .example.com \ : twist /bin/echo "421 This domain has been black-listed. Access denied!"
シェルコマンドのオプションに関する情報は hosts_options の man ページを参照してください。
拡張は、 spawn や twist ディレクティブと一緒に使用して、関連したクライアント、サーバー、関係するプロセスの情報を提供します。
以下にサポートされている拡張のリストを示します：
-
%a— クライアントの IP アドレスを提供 -
%A— サーバーの IP アドレスを提供 -
%c— ユーザー名とホスト名、又はユーザー名と IP アドレスなどのような各種のクライアントの情報を提供します。 -
%d— デーモンのプロセス名を提供 -
%h— クライアントのホスト名 (又は、それがない場合、 IP アドレス) を提供 -
%H— サーバーのホスト名 (又は、それがない場合、 IP アドレス) を提供。 -
%n— クライアントのホスト名を提供。ホスト名がない場合は、unknownが出力される。クライアントのホスト名とホストアドレスが一致しない場合は、paranoidが出力される。 -
%N— サーバーのホスト名を提供。ホスト名がない場合は、unknownが出力される。サーバーのホスト名とホストアドレスが一致しない場合、paranoidが出力される。 -
%p— デーモンのプロセス ID を提供 -
%s— デーモンのプロセスとサーバーのホスト又は IP アドレスなど、さまざまなタイプのサーバー情報を提供 -
%u— クライアントのユーザー名を提供。ユーザー名がない場合はunknownが出力される。
以下の規則のサンプルは、 spawn コマンドと一緒に拡張を使用してカスタマイズログファイルの中のクライアントホストを識別しています。
SSHデーモン (sshd) への接続が example.com ドメインのホストから試行されると、 echo コマンドを実行して、クライアントのホスト名 ( %h 拡張を使用) を含む試行を特殊ファイルへログします:
sshd : .example.com \
: spawn /bin/echo `/bin/date` access denied to %h>>/var/log/sshd.log \
: deny
同様に、拡張はクライアントに送り返すメッセージを個人化するのに使用されます。次の例では、 example.com ドメインから FTP サービスへアクセスを試行しているクライアントは、彼らがサーバーに立ち入り禁止となったことを通知されています：
vsftpd : .example.com \ : twist /bin/echo "421 %h has been banned from this server!"
利用できる拡張、及び追加のアクセス制御オプションに関する総合説明は、 hosts_access の man ページのセクション 5 (man 5 hosts_access) または hosts_options の man ページを参照してください。
TCP ラッパーについての詳細については 項25.5.5. 「その他のリソース」 を参照してください。
xinetd デーモンは、 FTP 、 IMAP 、 Telnet を含む人気のあるネットワークサービスのサブセットへのアクセスを制御する TCP ラップした スーパーサービス です。これは、アクセス制御、強化ロギング、結合、方向転換、リソース活用制御などの為にサービス特有の設定オプションを提供します。
xinetd によって制御されるネットワークサービスの接続をクライアントが試行する場合、スーパーサービスは要求を受け取り、すべての TCP ラッパーアクセス制御規則をチェックします。
アクセスが許可された場合、 xinetd は、そのサービスの独自のアクセス規則に従ってアクセスが許可されたかを検証します。それはさらにリソースを割り当てられないか、それが定められた規則に対して契約違反でないかをチェックします。
これら全ての条件が揃った場合、 (そのサービス用の自身のアクセス規則の元で接続が許可されることを確認し、サービスがその割り当て以上のリソースを消費していないことや、定義された規則に違反していないことも確認します) xinetd は、要求されたサービスのインスタンスを開始し、その接続の制御を通過させます。接続が確立されると、 xinetd はこれ以上、クライアントホストとサーバー間の通信には干渉しません。
xinetd の設定ファイルは以下のようになります：
-
/etc/xinetd.conf— グローバルなxinetd設定ファイル。 -
/etc/xinetd.d/— 全てのサービス特有のファイルを含んだディレクトリ。
/etc/xinetd.conf ファイルには、 xinetd の制御の元で全てのサービスが影響を受ける一般的な構成の設定が含まれています。 xinetd サービスが開始される時に1回だけ読み込まれるため、設定の変更が反映されるようにするためには、管理者は xinetd サービスを再起動する必要があります。以下は /etc/xinetd.conf のサンプルファイルです。
defaults
{
instances = 60
log_type = SYSLOG authpriv
log_on_success = HOST PID
log_on_failure = HOST
cps = 25 30
}
includedir /etc/xinetd.d
これらの行は、 xinetd の次のような側面を制御します。
-
instances—xinetdが1度に対処できる最大の要求数を設定します。 -
log_type—xinetdを設定してauthprivログ設備を使用します。これはログエントリを/var/log/secureファイルに書き込みます。FILE /var/log/xinetdlogのようなディレクティブを追加すると、/var/log/ディレクトリの中にxinetdlogと言うカスタムログファイルを作成します。 -
log_on_success—xinetdを設定して、接続が成功したかどうかをログします。デフォルトでは、リモートホストの IP アドレスと要求をプロセスしているサーバーのプロセス ID が記録されます。 -
log_on_failure—xinetdを設定して、接続失敗があるかどうか又は、接続が許可されていないかどうかをログします。 -
cps—xinetdを設定してどのサービスにも毎秒 25 接続以上は許可しないようにします。この限度に到達した場合は、サービスは 30 秒だけ休憩します。 -
includedir/etc/xinetd.d/—/etc/xinetd.d/ディレクトリにあるサービス特有の設定ファイルで宣言してあるオプションを含みます。詳細については 項25.5.4.2. 「/etc/xinetd.d/ ディレクトリ」 を参照して下さい。
注記
多くの場合、 /etc/xinetd.conf 内の log_on_success と log_on_failure の両方の設定も、サービス特有のログファイルでさらに修正されます。この理由で、 /etc/xinetd.conf ファイルが示す物より多くの情報が該当するサービスログに表示される可能性があります。詳細については 項25.5.4.3.1. 「ロギングオプション」 を参照してください。
/etc/xinetd.d/ ディレクトリ内には、 xinetd で管理されている各サービスの設定ファイルと、そのサービスに関連したファイルの名前が含まれています。 xinetd.conf の場合と同様に、このファイルは xinetd サービスが開始する時にだけ読み込まれます。変更を反映させるためには、管理者は xinetd サービスを再起動する必要があります。
/etc/xinetd.d/ ディレクトリ内のファイルのフォーマットは /etc/xinetd.conf と同じ記法を使用します。各サービスの設定が別々のファイルに格納される主な理由は、カスタマイズを簡単にすることと、他のサービスに影響を与える可能性を少なくするためです。
これらのファイルがどのように構成されるかを知るために、 /etc/xinetd.d/krb5-telnet ファイルを見てみます。
service telnet
{
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/kerberos/sbin/telnetd
log_on_failure += USERID
disable = yes
}
これらの行は、 telnet サービスのさまざまな側面を制御します：
-
service— サービス名を定義します。通常、/etc/servicesファイルに記載されるサービスのどれかになります。 -
flags— 接続の為の必要な数の属性をセットします。REUSEはxinetdに対して Telnet 接続のソケットを再使用するように指示します。注記
REUSEフラッグは推奨されていません。全てのサービスは現在暗黙的にREUSEフラッグを使用します。 -
socket_type— ネットワークソケットのタイプをstreamに設定します。 -
wait— サービスがシングルスレッド (yes) か又はマルチスレッド (no) かを定義します。 -
user— プロセスが実行に使用するユーザー ID を定義します。 -
server— 始動する予定のバイナリ実行ファイルを定義します。 -
log_on_failure— 既にxinetd.confに定義している物に追加して、log_on_failure用のロギングパラメータを定義します。 -
disable— サービスが無効になっているか (yes) 、有効になっているか (no) を定義します。
そのオプションと使用方法については xinetd.conf の man ページを参照してください。
xinetd で保護されているサービス用には利用できる多くの種類のディレクティブがあります。このセクションはより一般的に使用されているオプションの一部を強調して説明します。
以下のロギングオプションは、 /etc/xinetd.conf と /etc/xinetd.d/ ディレクトリ内のサービス特有の設定ファイルの両方で利用できます。
以下により一般的に使用されているロギングオプションの一覧を表示します：
-
ATTEMPT— 失敗の試行があった事実をログします (log_on_failure) 。 -
DURATION— リモートシステムによって使用されたサービスの時間の長さをログします (log_on_success) 。 -
EXIT— サービスの終了ステータス、又は終結シグナルをログします (log_on_success) 。 -
HOST— リモートホストの IP アドレス (log_on_failureとlog_on_success) をログします。 -
PID— 要求を受けているサーバーのプロセス ID をログします (log_on_success)。 -
USERID— 全てのマルチスレッドシステムの為に RFC 1413 で定義された方法を使用しているリモートユーザーをログします (log_on_failureとlog_on_success)。
ロギングオプションの総合リストについては、 xinetd.conf の man ページを参照して下さい。
xinetd サービスのユーザーは、 TCP ラッパーホストアクセス規則を使用するか、 xinetd 設定ファイル経由でアクセス制御をするか、あるいは両方を選択できます。 TCP ラッパーホストアクセス制御ファイルの使用に関する詳細は、 項25.5.2. 「TCP ラッパーの設定ファイル」 を参照してください。
このセクションでは、 xinetd を使用してのサービスへのアクセス制御について説明します。
注記
TCP ラッパーとは異なり、 xinetd の管理者が xinetd サービスを再起動した場合にのみ、アクセス制御への変更が反映されます。
また、 TCP ラッパーとは異なり、 xinetd を通してのアクセス制御は、 xinetd によって制御されるサービスにしか影響しません。
xinetd ホストアクセス制御は、 TCP ラッパーで使用されている方法と異なります。 TCP ラッパーが全てのアクセス設定を2つのファイル、 /etc/hosts.allow と /etc/hosts.deny に配置するのに対して、 xinetd のアクセス制御は /etc/xinetd.d/ ディレクトリ内の各サービスごとの設定ファイルにあります。
以下のホストアクセスオプションは、 xinetd によってサポートされています：
-
only_from— 特定のホストのみにサービスの使用を許可します。 -
no_access— リストにあるホストのサービス利用を拒否する。 -
access_times— 特定のサービスが利用できる時間幅を指定する。この時間幅は24時間形式で HH:MM-HH:MM の表示をする必要があります。
only_from と no_access オプションは IP アドレス又はホスト名の一覧を使用する、あるいはネットワーク全体を指定することができます。 TCP ラッパーの様に、強化ロギング設定で xinetd アクセス制御を結合することにより、それぞれの接続試行の記録を詳細に取りながら、禁止されているホストからの要求をブロックしてセキュリティを強化できます。
例えば、以下の /etc/xinetd.d/telnet ファイルは、特定のネットワークグループからの Telnet アクセスをブロックして、許可されたユーザーにさえも、ログイン可能な時間帯を制限する為に使用できます：
service telnet
{
disable = no
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/kerberos/sbin/telnetd
log_on_failure += USERID
no_access = 172.16.45.0/24
log_on_success += PID HOST EXIT
access_times = 09:45-16:15
}
この例では、 10.0.1.2 などの 10.0.1.0/24 ネットワークのクライアントシステムが、 Telnet サービスにアクセスを試みると、以下のようなメッセージを受け取ります:
コネクションは外部ホストによって閉じられます。
また、これらログイン試行は、次のように /var/log/messages の中に記録されます。
Sep 7 14:58:33 localhost xinetd[5285]: FAIL: telnet address from=172.16.45.107 Sep 7 14:58:33 localhost xinetd[5283]: START: telnet pid=5285 from=172.16.45.107 Sep 7 14:58:33 localhost xinetd[5283]: EXIT: telnet status=0 pid=5285 duration=0(sec)
TCP ラッパーを xinetd アクセス制御と併用する場合、2つのアクセス制御メカニズム間の関係を理解することが重要です。
クライアントが接続の要求をした時の xinetd による処理順序を以下に示します。
-
xinetdデーモンはlibwrap.aライブラリコールを経由して、 TCP ラッパーホストアクセス規則にアクセスします。もし拒否の規則がクライアントホストに適合するならば、その接続は切断されます。許可の規則がクライアントホストと適合する場合、接続がxinetdに渡されます。 -
xinetdデーモンは、xinetdサービスと要求されたサービスの両方の為に、自身のアクセス制御規則をチェックします。もし、拒否の規則がクライアントホストに適合する場合、接続は切断されます。その他の場合は、xinetdは要求されたインスタンスを開始して接続の制御を渡します。
重要
TCP ラッパーアクセス制御を xinetd アクセス制御と併用する場合、注意が必要です。設定ミスは良からぬ結果を招くことになります。
xinetd 用のサービス設定は、サービスをある IP アドレスにバインドし、そのサービス用の要求を別の IP アドレス、ホスト名、あるいはポートへリダイレクトします。
バインディングは、サービス特有の設定ファイルの中の bind オプションと共に制御されており、サービスをシステム上の IP アドレスと連結します。設定されると、 bind オプションは、正式な IP アドレスの為の要求のみをそのサービスへアクセスする許可をします。この方法で異なるサービスは異なるネットワークインターフェイスに需要ベースでバインドできます。
これは、特に複数のネットワークアダプターか、複数の IP アドレスを設定したシステムには便利なものです。このようなシステムでは、 Telnet などの安全でないサービスはプライベートなネットワークに接続されているインターフェイス上でのみリッスンするようにして、インターネット接続のインターフェイスではリッスンしないように設定できます。
redirect オプションは、 IP アドレス又はホスト名とそれに続くポート番号を受け付けます。サービスを設定して、このサービス用の要求を全て指定したホストか、又はポート番号にリダイレクトできるようにします。この機能は同じシステム上のポートから別のポートへポイントする、あるいは要求を同じマシン上の別の IP アドレスへリダイレクトする、あるいは要求を全く別のシステムとポート番号へ移動する、あるいはこれらのオプションの組合せをする場合に使用できます。この様にして、システム上の特定のサービスに接続しているユーザーは、問題なく他のシステムへ回送されるようにできます。
xinetd デーモンは、リクエストを送信したクライアントマシンと実際にサービスを提供するホストが接続されている間だけ有効なプロセスを生成し、2つのシステム間でデータを転送することによって、このリダイレクトを実現します。
bind と redirect オプションの利点は、それらが一緒に使用される時にはっきりと判別できます。サービスをシステム上の特定の IP アドレスにバインドして、その後そのサービス用の要求を1番目のマシンだけが見ることができる2番目のマシンにリダイレクトすることにより、内部のシステムが全く別のネットワークの為にサービスを提供することに使用できます。別の方法として複数ホームのマシン上の特定のサービスが、既知の IP アドレスへの露呈されることを制限したり、またそのサービスの要求をその目的用に特定の設定をしたマシンへリダイレクトするのに使用できます。
例えば、 Telnet サービス用にこの設定でファイアウォールとして使用されているシステムを考えてみましょう：
service telnet
{
socket_type = stream
wait = no
server = /usr/kerberos/sbin/telnetd
log_on_success += DURATION USERID
log_on_failure += USERID
bind = 123.123.123.123
redirect = 10.0.1.13 23
}
このファイル内の bind と redirect オプションは、マシン上の Telnet サービスがインターネットに向けた外部 IP アドレス (123.123.123.123) にバインドされていることを確定します。さらには、 123.123.123.123 に送信された Telnet サービスへの要求は2番目のネットワークアダプターを通じて、内部 IP アドレスの (10.0.1.13) にリダイレクトされ、これはファイアウォールと内部のシステムしかアクセスできないようになっています。ファイアウォールはその後、その2つのシステム間で通信をしますので、接続しているシステムは実際には別のマシンに接続されている状態でも 123.123.123.123 に接続されているように見えます。
この機能は、ブロードバンド接続で固定 IP アドレスが1つのみのユーザーに特に役に立ちます。 Network Address Translation (NAT) を使用するとき、内部専用の IP アドレスを使用するゲートウェイマシンの背後にあるシステムは、そのゲートウェイシステムの外部からの利用はできません。ただし、 xinetd で制御されている特定のサービスが bind と redirect オプションで設定されている場合、そのゲートウェイマシンは、外部システムとサービスを提供するように設定されている特定の内部マシン間でプロキシとして動作することができます。また、その他プロテクションとして各種の xinetd アクセス制御やロギングオプションがあります。
xinetd デーモンは、 Denial of Service (DoS) 攻撃からに対する基本的レベルの保護を追加することができます。以下のリストでは、そのような終りのない攻撃を制限できるディレクティブを表示します：
-
per_source— ソース IP アドレス毎のサービス用のインスタンスの最大数を定義します。これは整数のみを引数として受け付け、xinetd.conf内とxinetd.d/ディレクトリのサービス特有の設定ファイル内で使用できます。 -
cps— 毎秒の接続最大数を定義します。このディレクティブは中間にスペースを入れた2つの整数引数を使います。1番目は1秒間に接続が許可される最大数です。2番目はサービスを再開始する時にxinetdが待機する必要のある時間の秒数です。整数のみを引数として受け付け、xinetd.conf内とxinetd.d/ディレクトリのサービス特有の設定ファイル内の両方で使用できます。 -
max_load— サービスの CPU 使用方法とロード平均しきい値を定義します。これは引数に小数点を受け付けます。ロード平均は一定の時間の中で、どれくらいの処理がアクティブであるかの大まかな目安です。ロード平均についての詳細は
uptime、who、およびprocinfoコマンドを参照してください。
他にも利用できる xinetd 用のリソース管理オプションがあります。また、 xinetd.conf の man ページを参照して下さい。
TCP ラッパーと xinetd に関するその他の詳細はシステムドキュメントを参照するか、またはインターネットをご覧ください。
システムに附随するドキュメントは、 TCP ラッパー、 xinetd 、およびアクセス制御の追加の設定オプションを探し始めるには良い場所です。
-
/usr/share/doc/tcp_wrappers-— このディレクトリにある<version>/READMEファイルでは TCP ラッパーの動作説明と、存在する各種ホスト名及びホストアドレス偽装のリスクについて説明しています。 -
/usr/share/doc/xinetd-— このディレクトリにある<version>/READMEファイルでは、アクセス制御とsample.confファイルの側面と共に、/etc/xinetd.d/ディレクトリ内のサービス特有の設定ファイルを編集する各種アイデアを説明しています。 -
TCP ラッパーと
xinetd関連の man ページ — TCP ラッパーとxinetdに関係する各種のアプリケーションや設定ファイルの man ページがいくつかあります。以下により重要と思われる man ページをリストしています:- サーバーアプリケーション
-
-
man xinetd—xinetdの man ページ。
-
- 設定ファイル
-
-
man 5 hosts_access— TCP ラッパーのホスト制御アクセスファイルの為の man ページ。 -
man hosts_options— TCP ラッパーのオプションフィールドの man ページ。 -
man xinetd.conf—xinetdの設定オプションをリストした man ページ。
-
-
http://www.xinetd.org/ —
xinetdのホームページで、設定ファイルのサンプル、全機能の一覧、役に立つ FAQ などが含まれています。 -
http://www.macsecurity.org/resources/xinetd/tutorial.shtml — 特定のセキュリティ条件に合わせてデフォルトの
xinetd設定ファイルを修正するさまざまな方法を詳細に説明した講習です。
複数のサテライトオフィスを持つ企業では、通信中におけるデータの機密保護と効率化のために専用回線を使用して相互に接続することがよくあります。例えば、多くのビジネスはフレームリレーか 非同期転送モード (ATM-Asynchronous Transfer Mode) ラインをエンドツーエンドネットワーキングソリューションとして利用して他のオフィスとリンクしています。これは、特に、企業レベルの専用デジタル通信関連にかかる費用を抑えながら拡張したい中小規模のビジネス (SMB-small to medium sized business) にとっては高くつくことになります。
このニーズに対応するため、 VPN (Virtual Private Network) が開発されました。 専用回線と同じ機能原理で、 VPN により安全な 2 グループ間 (またはネットワーク間) でのデジタル通信が可能となり、既存の LAN (Local Area Network) から WAN (Wide Area Network) を創造します。フレームリレーや ATM との違いはそのトランスポート媒介です。 VPN はトランスポート層としてデータグラムを使用して IP を送出し、インターネット上に目的地までの安全なパイプを提供します。ほとんどのフリーソフトウェア VPN 実装は、トランジットにおいて更にデータをマスク化するためオープンスタンダードな暗号化メソッドを採用しています。
セキュリティ強化のためにハードウェア VPN ソリューションを採用する企業もあれば、ソフトウェアやプロトコルベースの実装を用いる企業もあります。 Cisco、 Nortel、 IBM、 Checkpoint などハードウェア VPN ソリューションを提供するベンダーがいくつかあります。 Linux 用には、標準化 IPSec (いわゆる Internet Protocol Security) 実装を利用する FreeS/Wan というフリーソフトウェアベースの VPN ソリューションがあります。こうした VPN ソリューションは、ソフトウェア又はハードウェアベースには関係なく、特殊なルータとして動作し、あるオフィスから別のオフィスへの IP 接続の間に位置します。
パケットがクライアントから発信された時、クライアントはルーティングと認証の為に AH (Authentication Header) を追加する VPN ルータ又はゲートウェイを通じてパケットを送信します。データは それから暗号化され、最後に ESPEncapsulating Security Payload で 包まれます。この ESP は復号化と処理方法で構成されています。
受信 VPN ルータはヘッダ情報を取り除いて、データを復号化し、目的地 (ワーク ステーションまたはネットワーク上のノード) へルーティングします。ネットワーク間接続を利用して、ローカルネットワークの受信ノードは、復号化されたパケットを受け取り処理のための準備を完了します。ネットワーク間の VPN 接続での暗号化/復号化のプロセスはローカルノードに対して透過的です。
このように強化されたセキュリティレベルであっても、攻撃者によってパケットが遮断されるだけでなく、そのパケットの解読もされてしまう恐れがあります。また、サーバーとクライアント間の man-in-the-middle 攻撃を使う侵入者は、認証セッション用のプライベートキーに対するアクセス権を持つことになる恐れもあります。彼らは認証及び暗号解読を行うために複数のレイヤーを使用するため、 VPN は一体化されたイントラネットとして動作する複数のリモートノードに接続する為の安全で効率の良い手段になります。
Red Hat Enterprise Linux は WAN への安全に接続するためのソフトウェアソリューションの実装に対してさまざまなオプションを提供しています。ユーザーは、自己の WAN への接続を安全にするソフトウェアの実装に使える各種オプションを持ちます。 IPsec 、いわゆる Internet Protocol Security は、 Red Hat Enterprise Linux 用の VPN 実装に対応しており、支店オフィスや遠隔地ユーザーを持つ、組織の使用ニーズに十分に応じることができます。
Red Hat Enterprise Linux は、インターネットなどの一般的なキャリアネットワーク上でセキュアなトンネルを使ってリモートホストとネットワークを互いに接続するための IPsec をサポートしています。 IPsec は、ホスト間接続 (あるコンピュータワークステーションから別のワークステーションへ) または、ネットワーク間接続 (ある LAN/WANから別のLAN/ WANへ) を使って実現されます。
Red Hat Enterprise Linuxでの IPsec 実装は IKE (Internet Key Exchange) を使用し、これは接続中のシステム間の相互認証や安全な接合に使用される IETF (Internet Engineering Task Force) で実装されるプロトコルです。
IPsec 接続は、 2 つの論理段階に分かれています。第１段階では、 IPsec ノードがリモートノードまたはネットワークとの接続を開始します。そのリモートノードまたはネットワークは、要求しているノードの信用度をチェックし、両者が接続の認証方法を交渉します。
Red Hat Enterprise Linux のシステムでは、 IPsec 接続は IPsec ノード認証の 事前共有キー メソッドを使用します。事前共有キーの IPsec 接続では、 IPsec 接続の第二段階へ移行するために両方のホストが同じキーを使用する必要があります。
IPsec 接続の第２段階では、 SA (Security Association ) が IPsec ノード間で作成されます。この段階は、暗号化手法、秘密セッションキー交換パラメータ、その他などの設定情報をもつ SA データベースを確立します。この段階は、リモートノードとネットワークとの実際の IPsec 接続を管理します。
Red Hat Enterprise Linux の IPsec 実装には、インターネットを介したホスト間のキーの共有に IKE を使用します。 racoon キーデーモンは、 IKE キー配付と交換を処理します。このデーモンに関する詳細は racoon man ページを参照してください。
IPsec を実装するには、すべての IPsec ホスト (ホスト間設定を使用する場合) 又は、ルータ (ネットワーク間設定を使用する場合) 上に ipsec-tools RPM パッケージをインストールする必要があります。 RPM パッケージには基本のライブラリ、デーモン、及び IPsec 接続の設定に役立つ設定ファイルが入っています。そして以下を含みます:
-
/sbin/setkey— カーネル内 IPsec のキー管理とセキュリティ属性を処理します。この実行可能ファイルはracoonキー管理デーモンにより制御されます。詳細はsetkey(8) manページを参照してください。 -
/sbin/racoon— IKE キー管理デーモンです。これは IPsec 接続システム間でのセキュリティ関連付けとキー共有の管理と制御に使用されます。 -
/etc/racoon/racoon.conf— 接続内で使用される認証方法や暗号化アルゴリズムなど、 IPsec 接続の各種事項を設定するのに使用されるracoonデーモン設定ファイルです。使用できるディレクティブの総合一覧は、racoon.conf(5) man ページを参照してください。
Red Hat Enterprise Linux 上で IPsec を設定するには、 ネットワーク管理ツール を使用するか、又はネットワーキングと IPsec 設定ファイルを手動で編集します。
-
それぞれネットワーク接続されている 2 台のホストを IPsec で接続するには、 項25.6.6. 「IPsec ホスト間 (Host-to-Host) 設定」 を参照してください。
-
ある LAN/WAN から別の LAN/WAN へ IPsec で接続するには、 項25.6.7. 「IPsec ネットワーク間 (Network-to-Network) 設定」 を参照してください。
IPsec は、ホスト間接続の方法であるデスクトップまたはワークステーション (ホスト) から別のデスクトップまたはワークステーションに接続するよう設定することができます。このタイプの接続は、ホスト間で安全なトンネルを作成するために各ホストが接続されるネットワークを使用します。ホスト間接続に必要なことはほとんどなく、各ホストでの IPsec 設定も同様に行なうことはあまりありません。ホストにはキャリアネットワークヘの専用接続 (インターネットなど) と、 IPsec 接続を作成するための Red Hat Enterprise Linux があれば十分です。
ホスト間の IPsec 接続は2つのシステムに於いて暗号化した接続を持ち、両方とも、同じ認証キーで IPsec を実行しています。IPsec 接続がアクティブな状態では、2つのホスト間のどんなネットワークトラフィックでも暗号化されています。
ホスト間 IPsec 接続を設定するには、各ホストに対して次の手順を適用します。
注記
設定している実際のマシン上で以下の操作を実行する必要があります。リモートでの IPsec 接続の設定と確立の試みは避けて下さい。
-
コマンドシェルで、
system-config-networkを入力して、 ネットワーク管理ツール を開始します。 -
IPsec タブ上で、 新規 をクリックして、 IPsec 設定ウィザードを開始します。
-
ホスト間 IPsec 接続の設定を開始するには 進む をクリックします。
-
ipsec0など、接続用の固有の名前を入力します。必要であれば、チェックボックスを選択して、起動時に自動的に接続が開始されるようにできます。 進む(Forward) をクリックして継続します。 -
接続タイプとして、 ホスト間暗号化 を選択し、それから 進む(Forward) をクリックします。
-
手動の暗号化を選択する場合、暗号化キーをプロセスの後で提供する必要があります。自動暗号化を選択した場合、
racoonデーモンが暗号化キーを担当します。自動暗号化を使用したい場合、ipsec-toolsパッケージをインストールしなければなりません。進む をクリックして続行します。
-
リモートホストの IP アドレスを入力します。
リモートホストの IP アドレスを確認するには、次のコマンドを リモートホスト上で 使用します。
[root@myServer ~] # /sbin/ifconfig
<device>ここで、
<device>は VPN 接続の 為に使用するイーサネットデバイスです。システム内にイーサネットが１つのみの場合は、デバイス名は標準的に eth0 となります。 以下の例では、このコマンドからの関連情報を示しています (これは例としての出力と言うことに注意して下さい):
eth0 Link encap:Ethernet HWaddr 00:0C:6E:E8:98:1D inet addr:172.16.44.192 Bcast:172.16.45.255 Mask:255.255.254.0IP アドレスは
inet addr:ラベルの後に続く、番号です。注記
ホスト対ホスト接続には、両方のホストとも公共の経路指定可能なアドレスを持つ必要が あります。別の方法としては、両方のホストが同じ LAN 上にある限りは、個人アドレスで、 経路指定不可のアドレス （例：10.x.x.x や 192.168.x.x の範囲）を持つことができます。
ホストが別々の LAN 上にある場合、又は一つのホストが公共アドレスを持ち、もう一つの ホストが個人アドレスを持っている場合には、項25.6.7. 「IPsec ネットワーク間 (Network-to-Network) 設定」 を 参照して下さい。
進む をクリックして続行します。
-
6 のステップで、手動の暗号化を選択した場合は、使用する暗号化キーを指定するか、又は、 生成(Generate) をクリックして、作成します。
-
認証キーを指定するか、又は 生成(Generate) をクリックして、作成します。番号又か文字のどんな組み合わせも使用できます。
-
進む をクリックして続行します。
-
-
IPsec — 要約 ページにある情報を確認し、それから 適用 をクリックします。
-
ファイル => 保存 とクリックして、設定を保存します。
変更を反映させる為には、ネットワークを再起動する必要があります。ネットワークを再起動するには、次のコマンドを使用します:
[root@myServer ~]# service network restart
-
リストから IPsec 接続を選択して、 アクティベート ボタンをクリックします。
-
他のホストにも全手順をくり返します。ステップ 8 からの同じキーが他のホストにも使用されることが基本となります。そうしないと IPsec は動作しません。
IPsec 接続を設定した後に、 図 25.10. 「IPsec 接続」 で 示されるように、 IPsec 内にそれが表示されます。
以下のファイルは、 IPsec 接続が設定された時に作成されます:
-
/etc/sysconfig/network-scripts/ifcfg-<nickname> -
/etc/sysconfig/network-scripts/keys-<nickname> -
/etc/racoon/<remote-ip>.conf -
/etc/racoon/psk.txt
自動暗号化が選択されると、 /etc/racoon/racoon.conf も作成されます。
インターフェイスが立ち上がると、 /etc/racoon/racoon.conf は変更されて、<remote-ip>.conf
接続を作成するには、まず、各ワークステーションからシステムとネットワークの情報を収集します。ホスト間接続には、次のような情報が必要になります。
-
各ホストの IP アドレス
-
例えば、
ipsec1のような独自の名前。これは IPsec 接続を識別する為と、それを他のデバイスや接続と区別する為に使用されます。 -
固定暗号化キーか
racoonで自動的に生成されるキー -
接続を開始しセッション中に暗号化キーを交換するのに使用される pre-shared 認証キー
例えば、ワークステーション A とワークステーション B を IPSec トンネルを使ってお互いに接続したいとします。ワークステーションは値 Key_Value01 を持つ事前共有キーを使い接続し、ユーザーは racoon で各ホスト間の認証キーを自動生成、共有することに同意しています。両方のホストユーザーはその接続名を ipsec1 にしました。
注記
大文字、小文字、数字、句読点を混合して使用する PSK を選択しなければなりません。容易に推測できるような PSK はセキュリティ上危険です。
各ホストに対して同じ接続名を使用する必要がありません。インストールに便利でわかりやすい名前を選択してください。
以下にワークステーション B とのホスト間 IPsec 接続の為のワークステーション A 用の IPsec 設定ファイルを示します。この例の接続を識別する個有名は ipsec1 ですので、その結果のファイル名は /etc/sysconfig/network-scripts/ifcfg-ipsec1 になります。
DST=X.X.X.X
TYPE=IPSEC
ONBOOT=no
IKE_METHOD=PSK
ワークステーション A では X.X.X.X にワークステーション B の IP アドレスを入れますが、ワークステーション B では X.X.X.X にワークステーション A の IP アドレスを入れます。起動時に接続は開始されないよう設定され (ONBOOT=no)、 認証には事前共有キーの方法を使用します (IKE_METHOD=PSK)。
以下に、 /etc/sysconfig/network-scripts/keys-ipsec1 と呼ばれる、事前共有キーファイルの内容を示します。両方のワークステーションがお互いを認証するのに使います。このファイルの内容は両方のワークステーションで同じでなければならず、また、 root ユーザーのみがこのファイルの読み取り/書き込みをできる状態であるべきものです。
IKE_PSK=Key_Value01
重要
root ユーザーだけがファイルを読み取り、編集できるよう、 keys-ipsec1 ファイルを変更するには、ファイルを作成してから次のコマンドを実行します:
[root@myServer ~] # chmod 600 /etc/sysconfig/network-scripts/keys-ipsec1
認証キーを変更するためには、両方のワークステーション上で keys-ipsec1 ファイルを編集します。 正常な接続には、両方のキーが同じでなければなりません。
次の例は、リモートホストへの段階１接続のための特殊設定です。ファイル名は X.X.X.X.confX.X.X.X には、リモート IPsec ホストの IP アドレスを入れます)。このファイルは、 IPsec トンネルが起動されると自動的に生成されるため、直接編集しないように注意してください。
remote X.X.X.X
{
exchange_mode aggressive, main;
my_identifier address;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 2 ;
}
}
IPsec 接続が開始される時に作成されるデフォルトの第１段階設定ファイルには、 Red Hat Enterprise Linux の IPsec 実装で使用される以下のステートメントが含まれています。
-
リモート
X.X.X.X -
この設定ファイルの結果となるスタンザが、
X.X.X.XIP アドレスで識別されたリモートノードに対してのみ適用されることを定義します。 - exchange_mode aggressive
-
Red Hat Enterprise Linux 上の IPsec 用のデフォルト設定は積極的な認証モードを使用し、複数のホストとの複数の IPsec 接続の設定を許可しながら、接続オーバーヘッドを低減します。
- my_identifier address
-
ノードの認証時に使用する識別手法を定義します。 Red Hat Enterprise Linux はノードの識別に IP アドレスを使用します。
- encryption_algorithm 3des
-
認証中に使用する暗号法を定義します。デフォルトでは、 3DES (Triple Data Encryption Standard) が使用されます。
- hash_algorithm sha1;
-
ノード間の第１段階交渉の間に使用するハッシュアルゴリズムを指定します。デフォルトでは、 Secure Hash Algorithm のバージョン１が使用されます。
- authentication_method pre_shared_key
-
ノード交渉中に使用する認証法を定義します。 Red Hat Enterprise Linux はデフォルトでは、認証に事前共有キーを使用します。
- dh_group 2
-
動的生成のセッションキーを確立する為の Diffie-Hellman グループ番号を指定します。デフォルトでは、 modp1024 (グループ2) が使用されます。
/etc/racoon/racoon.conf ファイルは、 include "/etc/racoon/ ステートメント 以外は 、全ての IPsec ノード上で同一でなければなりません。このステートメントは (及び、参照するファイル) は、 IPsec トンネルが起動すると生成されます。ワークステーション A では、 X.X.X.X.conf"include ステートメントの X.X.X.X をワークステーション B の IP アドレスにします。ワークステーション B ではその逆です。以下に、 IPsec 接続が起動したときの一般的な racoon.conf ファイルを示します。
# Racoon IKE daemon configuration file.
# See 'man racoon.conf' for a description of the format and entries.
path include "/etc/racoon";
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";
sainfo anonymous
{
pfs_group 2;
lifetime time 1 hour ;
encryption_algorithm 3des, blowfish 448, rijndael ;
authentication_algorithm hmac_sha1, hmac_md5 ;
compression_algorithm deflate ;
}
include "/etc/racoon/X.X.X.X.conf";
このデフォルトの racoon.conf ファイルには、 IPsec 設定用の定義されたパス、事前共有キー、及び証書が含まれています。 sainfo anonymous のフィールドは IPsec ノード間の第2段階 SA を 説明しています。 — IPsec 接続の性格 (使用されるサポート付暗号化アルゴリズムを含む) と交換キーの方法。次のリストは第2段階のフィールドを定義しています:
- sainfo anonymous
-
IPsec 証明証が合致する限り、どのピアとでも無記名で SA が開始することを示します。
- pfs_group 2
-
Diffie-Hellman キー交換プロトコルを定義し、これは IPsec ノードが IPsec 接続の第2段階の為に相互に臨時のセッションキーを確立する方法を決定します。デフォルトでは、 Red Hat Enterprise Linux の IPsec 実装は Diffie-Hellman 暗号化キー交換グループのグループ2 (いわゆる
modp1024) を使用します。グループ 2 は、 1024 ビットモジュラーべき乗を使い、 これはプライベートキーが侵略されても、 以前の IPsec 送信に対する攻撃者からの解読を防止します。 - 存続期間の時間は1時間
-
このパラメータは、 SA の存続期間を指定し、時間、またはデータのバイト数で数量化できます。デフォルトの Red Hat Enterprise Linux IPsec 実装は存続期間を1時間に指定しています。
- encryption_algorithm 3des, blowfish 448, rijndael
-
第2段階用にサポートされた暗号法を指定します。 Red Hat Enterprise Linux は 3DES 、 448 ビット Blowfish、 及び Rijndael (AES、 いわゆる Advanced Encryption Standard で使用される暗号表記) をサポートしています。
- authentication_algorithm hmac_sha1, hmac_md5
-
サポートされる認証用のハッシュアルゴリズムをリストします。サポートのモード は、 sha1 と md5 のハッシュメッセージ認証コードです (HMAC)。
- compression_algorithm deflate
-
IPCOMP (IP Payload Compression) サポート用の収縮コンプレッションアルゴリズムを定義して、これにより低速な接続上で IP データグラムのかなり高速な転送ができます。
接続を開始するには、次のコマンドを各ホストで実行します。
[root@myServer ~]# /sbin/ifup <nickname>
ここで、 <nickname> は、 IPsec 接続用に指定する名前です。
IPsec 接続をテストするには、 tcpdump ユーティリティを実行してホスト間で転送されているネットワークパケットを表示し、 IPsec で暗号化されていることを確認します。パケットには AH ヘッダが含まれ、 ESP パケットとして表示されていなければなりません。 ESP であれば暗号化されているということです。例えば、
[root@myServer ~]# tcpdump -n -i eth0 host <targetSystem> IP 172.16.45.107 > 172.16.44.192: AH(spi=0x0954ccb6,seq=0xbb): ESP(spi=0x0c9f2164,seq=0xbb)
IPsec は、ネットワーク間接続の方法を用いて、リモートネットワークにネットワーク全体 (LAN や WAN など) を接続するよう設定することもできます。ネットワーク間接続には、ある LAN 上の 1 ノードからリモート LAN 上の 1 ノードに情報を透過的に処理してルーティングするために、接続しているネットワークの両サイドで IPsec ルータの設定が必要です。 図 25.11. 「ネットワーク間 IPsec トンネル接続」 でネットワーク間 IPsec トンネル接続を示しています。
この図は、インターネットで区切られた 2 つの LAN を示しています。この 2 つの LAN は IPsec ルータを使い、インターネットを通るセキュアなトンネルで接続を認証、開始します。通過中に遮断されたパケットは、この 2 つの LAN の間の暗号保護パケットをクラックするためにブルートフォース復号化を要求します。 LAN パケットの処理、暗号化/復号化、及びルーティングは完全に IPsec ルータにより処理されるため、 192.168.1.0/24 IP 範囲のあるノードから 192.168.2.0/24 範囲の別ノードへの通信プロセスはノードに対して完全に透過的になります。
ネットワーク間接続に必要な情報には次のようなものがあります。
-
専用 IPsec ルータの外部アクセス可能な IP アドレス
-
IPsec ルータが対応する LAN/WAN のネットワークアドレス範囲 (192.168.0.0/24、 10.0.1.0/24 など)
-
ネットワークノードからインターネットにデータをルーティングするゲートウェイデバイスの IP アドレス
-
例えば、
ipsec1のような独自の名前。これは IPsec 接続を識別する為と、それを他のデバイスや接続と区別する為に使用されます。 -
固定暗号化キーか
racoonで自動的に生成されるキー -
接続を開始しセッション中に暗号化キーを交換するのに使用される pre-shared 認証キー
ネットワーク間の IPsec 接続では、2つの IPsec ルーターを使用します。各ネットワークに１つずつです。これを通じてプライベートサブネットのネットワークトラフィックがルートされます。
例えば、 図 25.12. 「ネットワーク間 IPsec」 で示すように、プライベートネットワークの 192.168.1.0/24 がネットワークトラフィックをプライベートネットワークの 192.168.2.0/24 に送信する場合、このパケットはゲートウェイ 0 から ipsec0 を通過し、インターネットを経由して ipsec1 からゲートウェイ 1 に、 そして 192.168.2.0/24 サブネットに到達します。
IPsec ルータにはパブリックにアドレス可能な IP アドレスと適切なプライベートネットワークに接続された 2 番めのイーサネットデバイスが必要になります。トラフィックの行先が暗号化された接続を有する別の IPsec ルータである場合、このトラフィックは必ず IPsec ルータを通過します。
別のネットワーク設定オプションとして、各 IP ルータとインターネット間のファイアウォール、及び各 IPsec ルータとサブネットゲートウェイ間のイントラネットファイアウォールなどがあります。 IPsec ルータとサブネットのゲートウェイは、 IPsec ルータとして動作するパブリックの IP アドレスとプライベートサブネット用のゲートウェイとして動作するプライベート IP アドレスの 2 つのイーサネットデバイスで 1 つのシステムとすることができます。各 IPsec ルータはゲートウェイをそのプライベートネットワークまたはパブリックのゲートウェイに使用してパケットを他の IPsec ルータに送信することができます。
ネットワーク間 IPsec 接続を設定するには次の手順に従います。
-
コマンドシェルで、
system-config-networkを入力して、 ネットワーク管理ツール を開始します。 -
IPsec タブ上で、 新規 をクリックして、 IPsec 設定ウィザードを開始します。
-
進む をクリックしてネットワーク間 IPsec 接続の設定を開始します。
-
接続に固有のニックネームを付けます。例えば、
ipsec0などです。必要であれば、チェックボックスを選んでコンピュータ起動時に自動的に接続が起動されるようにします。 進む をクリックして続行します。 -
接続タイプに ネットワーク間の暗号化 (VPN) を選択し、 進む をクリックします。
-
手動の暗号化を選択する場合、暗号化キーをプロセスの後で提供する必要があります。自動暗号化を選択した場合、
racoonデーモンが暗号化キーを担当します。自動暗号化を使用したい場合、ipsec-toolsパッケージをインストールしなければなりません。進む をクリックして続行します。
-
ローカルネットワーク のページで、次の情報を入力します。
-
ローカルネットワークアドレス — プライベートネットワークに接続される IPsec ルータ上のデバイスの IP アドレスです。
-
ローカルサブネットマスク — ローカルネットワーク IP アドレスのサブネットマスクです。
-
ローカルネットワークゲートウェイ — プライベートサブネット用のゲートウェイです。
進む をクリックして続行します。
-
-
リモートネットワーク のページで、次の情報を入力します。
-
リモート IP アドレス — その他のプライベートネットワーク用IPsec ルータのパブリックにアドレス可能な IP アドレスです。ここでは、 ipsec0 に対してパブリックにアドレス可能な IP アドレス ipsec1 を入力しています。
-
リモートネットワークアドレス — 他のIPsec ルータの内側にあるプライベートサブネットのネットワークアドレスです。ここでは、 ipsec1 の設定では
192.168.1.0を入力し ipsec0 の設定には192.168.2.0を入力しています。 -
リモートサブネットマスク — リモート IP アドレスのサブネットマスクです。
-
リモートネットワークゲートウェイ — リモートネットワークアドレス用ゲートウェイの IP アドレスです。
-
手順 6 で手動による暗号化が選択されていた場合は、使用する暗合キーを指定するか 生成 をクリックしてキーを作成します。
認証キーを指定するか 生成 をクリックしてキーを作成します。このキーは数字と文字の組み合わせなら何でも構いません。
進む をクリックして続行します。
-
-
IPsec — 要約 ページにある情報を確認し、それから 適用 をクリックします。
-
ファイル => 保存 と選択して、この設定を保存します。
-
リストから IPsec 接続を選択して、それから アクティベート をクリックして接続をアクティベートします。
-
IP 転送を有効にする:
-
/etc/sysctl.confを編集して、net.ipv4.ip_forwardを1に設定します。 -
次のコマンドを使って変更を有効にします。
[root@myServer ~]# /sbin/sysctl -p /etc/sysctl.conf
-
IPsec 接続を起動させるネットワークスクリプトは、必要であれば自動的にネットワークルートを作成して IPsec ルータ経由でパケットを送信します。
例えば、 LAN A (lana.example.com) と LAN B (lanb.example.com) を IPsec トンネルで接続したいとします。 LAN A のネットワークアドレスは 192.168.1.0/24 の範囲、一方、 LAN B は 192.168.2.0/24 の範囲を使用しています。ゲートウェイ IP アドレスは、 LAN A が192.168.1.254、 LAN B が 192.168.2.254 です。 IPsec ルータは各 LAN ゲートウェイとは別で、 2 つのネットワークデバイスを使用しています。 eth0 は外部アクセス可能な静的 IP アドレスに割り当てられインターネットにアクセスします。 eth1 はルーティングポイントとして動作し、あるネットワークノードからリモートネットワークノードに LAN パケットを処理、転送します。
各ネットワーク間の IPsec 接続は値 r3dh4tl1nux で事前共有キーを使用し、 A と B の管理者は各 IPsec ルータ間の認証キーが racoon により自動生成され共有されることに同意しています。 LAN A の管理者は IPsec 接続の名前を ipsec0 にし、 LAN B の管理者は IPsec 接続の名前を ipsec1 にしています。
以下の例は、 LAN A のネットワーク間 IPsec 接続用の ifcfg ファイルを示します。この例の接続を識別する固有名は ipsec0 ですので、そのファイルは /etc/sysconfig/network- scripts/ifcfg-ipsec0 という名前になります。
TYPE=IPSEC
ONBOOT=yes
IKE_METHOD=PSK
SRCGW=192.168.1.254
DSTGW=192.168.2.254
SRCNET=192.168.1.0/24
DSTNET=192.168.2.0/24
DST=X.X.X.X
以下のリストがこのファイルの内容を説明しています:
- TYPE=IPSEC
-
接続のタイプを指定します。
- ONBOOT=yes
-
ブートアップ時に接続が開始すべきことを指定します。
- IKE_METHOD=PSK
-
接続が、認証で事前共有キーメソッドを使用することを指定します。
- SRCGW=192.168.1.254
-
発信元ゲートウェイの IP アドレスです。 LAN A 用には、これが LAN A ゲートウェイであり、 LAN B 用には、これが LAN B ゲートウェイです。
- DSTGW=192.168.2.254
-
送信先のゲートウェイです。 LAN A 用には、これが LAN B ゲートウェイであり、 LAN B 用には、これが LAN A ゲートウェイです。
- SRCNET=192.168.1.0/24
-
IPsec 接続用の発信元ネットワークを指定し、この例では、 LAN A 用のネットワーク幅となります。
- DSTNET=192.168.2.0/24
-
IPsec 接続用の送信先ネットワークを指定し、この例では、 LAN B 用のネットワークとなります。
- DST=X.X.X.X
-
外部からアクセス可能な LAN B の IPアドレス
次の例は、両方のネットワークが互いに認証するために使用する、 /etc/sysconfig/network-scripts/keys-ipsec (XX は、 0 を LAN A 用に、 1 を LAN B 用に入れる) と呼ばれる事前共有キーファイルの内容を示します。このファイルの内容は同一でなければならず、また、このファイルを読み取り/書き込みできるのは root ユーザーだけにする必要があります。
IKE_PSK=r3dh4tl1nux
重要
root ユーザーだけがファイルを読み取り、編集できるように keys-ipsec ファイルを変更するには、ファイルを作成した後に次のコマンドを実行します:
X
chmod 600 /etc/sysconfig/network-scripts/keys-ipsec1
認証キーを変更するには、両方の IPsec ルータ上で keys-ipsec ファイルを編集します。 両方のキーが同一でなければ正しい接続はできません。
X
次の例は、 IPsec 接続用の /etc/racoon/racoon.conf 設定ファイルを示します。ファイルの下部の include 行は自動的に生成されますが、 IPsec トンネルが実行中の場合のみ、現れることに注意して下さい。
# Racoon IKE daemon configuration file.
# See 'man racoon.conf' for a description of the format and entries.
path include "/etc/racoon";
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";
sainfo anonymous
{
pfs_group 2;
lifetime time 1 hour ;
encryption_algorithm 3des, blowfish 448, rijndael ;
authentication_algorithm hmac_sha1, hmac_md5 ;
compression_algorithm deflate ;
}
include "/etc/racoon/X.X.X.X.conf"
以下は、リモートネットワークへ接続のための特殊設定です。ファイル名は X.X.X.X.confX.X.X.X は、リモート IPsec ルータの IP アドレスになります)。このファイルは、 IPsec トンネルが起動されると自動的に生成されるため、直接、変更しないよう注意してください。
remote X.X.X.X
{
exchange_mode aggressive, main;
my_identifier address;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 2 ;
}
}
IPsec 接続を開始する前に、 IP フォワーディングをカーネルで有効にしてください。 IP フォワーディングを有効にするには次を実行します。
-
/etc/sysctl.confを編集して、net.ipv4.ip_forwardを1に設定します。 -
次のコマンドを使って変更を有効にします。
[root@myServer ~] # sysctl -p /etc/sysctl.conf
IPsec 接続を開始するには、各ルータで次のコマンドを実行します。
[root@myServer ~] # /sbin/ifup ipsec0
接続が開かれ、 LAN A と B が互いに通信できるようになります。 IPsec 接続で ifup を実行して呼び出された初期化スクリプトを通じてルートが自動的に作成されます。ネットワークのルート一覧を表示するには、次のコマンドを実行します。
[root@myServer ~] # /sbin/ip route list
IPsec 接続をテストするには、外部ルーティング可能なデバイスで tcpdump ユーティリティを実行し (この例では eth0)、ホスト (またはネットワーク) 間で転送されているネットワークパケットを表示させ、 IPsec で暗号化されているか確認します。例えば、 LAN A の IPsec 接続性を確認するには、次のコマンドを使用します。
[root@myServer ~] # tcpdump -n -i eth0 host lana.example.com
パケットには AH ヘッダが含まれ、 ESP パケットとして表示されていなければなりません。 ESP とは、暗号化されているということです。例えば (バックスラッシュは 1 行続くと言う意味):
12:24:26.155529 lanb.example.com > lana.example.com: AH(spi=0x021c9834,seq=0x358): \
lanb.example.com > lana.example.com: ESP(spi=0x00c887ad,seq=0x358) (DF) \
(ipip-proto-4)
IPsec 接続がブート時に起動するよう設定されていなかった場合、コマンドラインで管理することができます。
接続を開始するには、ホスト間 IPsec なら各ホストで、ネットワーク間 IPsec の場合には各 IPsec ルータで、それぞれ次のコマンドを実行します。
[root@myServer ~] # /sbin/ifup <nickname>
<nickname> は前に定義した ipsec0 などのニックネームになります。
接続を停止するには、次のコマンドを実行します。
[root@myServer ~] # /sbin/ifdown <nickname>
情報セキュリティは1つのプロセスであり製品ではないとよく思われていますが、標準的なセキュリティのインプリメンテーションでは、通常、アクセス権を制御して許可があり識別及び追跡が可能なユーザーに対してネットワークリソースを制限する何らかの専用メカニズムを採用しています。 Red Hat Enterprise Linux には、ネットワークレベルでのアクセス制御に関して問題を抱えている管理者やセキュリティエンジニアの方々を支援する強力なツールがいくつか含まれています。
ファイアウォールはネットワークセキュリティ実装の核のひとつなるコンポーネントです。ホームユーザー向け 1 台の PC 保護から、企業の機密情報を安全に保護するデータセンターソリューションまで、市場の全レベルに合わせてファイアウォールソリューションを提供しているベンダーがいくつかあります。ファイアウォールには、 Cisco 、 Nokia 、 Sonicwall などが提供しているファイアウォール器機などの独立型ハードウェアソリューションもあります。また、 Checkpoint 、 McAfee 、 Symantec などのベンダーによって個人仕様からビジネス仕様まで商用ソフトウェアファイアウォールソリューションが開発されています。
ハードウェアのファイアウォールとソフトウェアのファイアウォールの違いは別にして、ソリューション毎にファイアウォールの機能の仕方も異なってきます。 表 25.2. 「ファイアウォールのタイプ」 では一般的な 3 種類のファイアウォールと、その機能について説明しています。
| 方法 | 詳細 | 長所 | 短所 | ||||||
|---|---|---|---|---|---|---|---|---|---|
| NAT | NAT (Network Address Translation) は、プライベート IP サブネットワークを １ つのパブリック IP アドレスまたは小規模なパブリック IP アドレスの集合の後に配置して、幾つかのソースにではなく１つのソースに全ての要求を出すようなマスカレード (偽装) をします。 Linux カーネルには Netfilter カーネルサブシステムを使用するビルトインの NAT 機能があります。 |
|
|
||||||
| パケットフィルタ | パケットフィルタリングファイアウォールは、 LAN を通過する各データパケットを読み取ります。ヘッダ情報でパケットを読み込んでから処理して、ファイアウォール管理者により実践されているプログラム可能なルールに基づいてパケットをフィルタします。 Linux カーネルには Netfilter カーネルサブシステムを使ったビルトインのパケットフィルタリング機能をがあります。 |
|
|
||||||
| プロキシ | プロキシファイアウォールは、 LAN クライアントからプロキシマシンへの特定のプロトコルまたはタイプの要求すべてをフィルタします。次に、その要求をローカルクライアントに代わってインターネットに送ります。プロキシマシンは、悪意あるリモートユーザーとネットワーククライアントマシン間のバッファとして動作します。 |
|
|
表 25.2. ファイアウォールのタイプ
Linux カーネルは、 netfilter と呼ばれる強力なネットワークサブシステムが特徴です。 netfilter サブシステムはステートフルまたはステートレスのパケットフィルタリング機能に加えて、 NAT 及び IP マスカレードサービスも提供します。また、 Netfilter には、高度なルーティング及び接続状態管理のための IP ヘッダ情報を mangle する機能もあります。 Netfilter は IPTables ツールで制御します。
Netfilter のパワーと柔軟性は iptables 管理ツールで実装します。構文は前身である ipchains に似ているコマンドラインツールです。
構文が似ているからといって実装も同じわけではありません。ただし、 ipchains は、送信元パスのフィルタリング、送信先パスのフィルタリング、送信元と送信先両方の接続ポートのフィルタリングのため複雑なルールセットを必要とします。
一方、 iptables は Netfilter サブシステムを使用してネットワーク接続、検閲、処理を強化します。 iptables は高度なログ機能、 pre- と post- のルーティング動作、ネットワークアドレス変換、ポートフォワーディング機能などをすべて1つのコマンドラインインターフェースで実現します。
このセクションでは iptables の概要を説明しています。詳細については 項25.8. 「IPTables」 を参照してください。
ビルなどに見られる火災の拡大を防ぐ防火壁と同様、コンピュータのファイアウォールは悪意あるソフトウエアがコンピュータに拡がるのを防ごうと試みます。また、許可のないユーザーによるコンピュータへのアクセスを防ぐのにも役立ちます。
デフォルトの Red Hat Enterprise Linux インストールでは、ファイアウォールはご使用のコンピュータまたはネットワークとインターネットなどの信頼できないネットワークとの間に存在します。ご使用のコンピュータ上でリモートユーザーがアクセスできるサービスを判別します。正しく設定されたファイアウォールはシステムの安全性を飛躍的に高めることができます。インターネット接続のある Red Hat Enterprise Linux システムはすべてファイアウォールを設定されることをお勧めします。
Red Hat Enterprise Linux インストールの ファイアウォールの設定 画面で、基本のファイアウォールを有効にする、また特定のデバイスや着信サービス、ポートを許可する機会が与えられていたはずです。
After installation, you can change this preference by using the セキュリティレベル設定ツール.
このアプリケーションを起動するには、次のコマンドを使用します。
[root@myServer ~] # system-config-securitylevel
注記
The セキュリティレベル設定ツール only configures a basic firewall. If the system needs more complex rules, refer to 項25.8. 「IPTables」 for details on configuring specific iptables rules.
以下のファイアウォール用のオプションを1つ選択します。
-
無効 — ファイアウォールを無効にするとシステムに対する完全なアクセスを提供することになり、セキュリティチェックを行いません。信頼できるネットワーク上で (インターネットではなく) 稼動しているか、 iptables コマンドラインツールを使ってカスタムのファイアウォールを設定する必要がある場合に限り選択します。
警告
ファイアウォールの設定及びカスタマイズされたファイアウォールのルールは
/etc/sysconfig/iptablesファイルに格納されます。 無効 を選択して OK をクリックすると、これらの設定とファイアウォールのルールは失われます。 -
有効 — このオプションでシステムは DNS 応答や DHCP 要求などの送信要求に応答しない着信接続を拒否するよう設定されます。このマシンで実行しているサービスにアクセスが必要な場合は、特定のサービスがファイアウォールを通過できるよう許可することができます。
システムをインターネットに接続しているがサーバーを稼動させる予定はない場合、これは最も安全な選択肢になります。
信頼できるサービス 一覧でオプションを有効にすると指定したサービスのファイアウォール通過を許可します。
- WWW (HTTP)
-
HTTP プロトコルは Apache (及び他のウェブサーバー) によってウェブページを提供するために使用されます。ウェブサーバーを公開する予定がある場合は、このチェックボックスを選択してください。このオプションはローカルでのページ表示や、ウェブページの開発には必要ありません。このサービスは
httpdパッケージがインストールされている必要があります。WWW (HTTP) を有効にしても HTTP の SSL バージョンである HTTPS のポートは開きません。このサービスが必要な場合は、 Secure WWW (HTTPS) のチェックボックスを選択します。
- FTP
-
FTP プロトコルはネットワーク上のマシン間でのファイル転送に使用されます。 FTP サーバーを公開する予定がある場合は、このチェックボックスを選択します。このサービスには
vsftpdパッケージがインストールされている必要があります。 - SSH
-
Secure Shell (SSH) はリモートマシン上にログインしてコマンドを実行するためのツール一式になります。マシンへのリモートアクセスを ssh 経由で許可するには、 このチェックボックスを選択します。このサービスには
openssh-serverパッケージがインストールされている必要があります。 - Telnet
-
Telnet はリモートマシンにログインするためのプロトコルです。 Telnet 通信は暗号化されず、ネットワークのスヌーピングに対するセキュリティがありません。 Telnet の着信アクセスの許可は避けた方が良いでしょう。 telnet を使ったマシンへのリモートアクセスを許可するには、このチェックボックスを選択します。このサービスには
telnet-serverパッケージがインストールされている必要があります。 - Mail (SMTP)
-
SMTP はリモートホストがメール配信のためマシンに直接接続するのを許可するプロトコルです。 ISP のサーバーから POP3 や IMAP を使ってメールを受信する場合、または
fetchmailなどのツールを使用する場合は、このサービスを有効にする必要はありあません。マシンへのメール配信を許可するには、このチェックボックスを選択します。 SMTP サーバーの設定を誤るとリモートマシンがサーバーを利用してスパムを送信してしまう恐れがありますので注意してください。 - NFS4
-
Network File System (NFS) は *NIX システムでよく使われるファイル共有プロトコルです。このプロトコルのバージョン 4 は前のバージョンよりさらに安全性が向上しています。他のネットワークユーザーとご使用のシステムにあるファイルやディレクトリを共有する場合は、このチェックボックスを選択します。
- Samba
-
Samba は Microsoft 専売特許の SMB ネットワークプロトコルです。ファイル、ディレクトリ、ローカルに接続したプリンタを Microsoft Windows のマシンと共有する必要がある場合は、このチェックボックスを選択します。
The セキュリティレベル設定ツール includes an Other ports section for specifying custom IP ports as being trusted by iptables. For example, to allow IRC and Internet printing protocol (IPP) to pass through the firewall, add the following to the Other ports section:
194:tcp,631:tcp
OK をクリックして変更を保存しファイアウォールを有効または無効にします。 ファイアウォールを有効にする を選んだ場合、選択したオプションは iptables コマンドに対して変換されて /etc/sysconfig/iptables ファイルに書き込まれます。また、 iptables サービスが起動されるため、選択オプションを保存すると直ちにファイアウォールが起動されます。 ファイアウォールを無効にする を選んだ場合、 /etc/sysconfig/iptables ファイルが削除されて直ちに iptables サービスが停止します。
The selected options are also written to the /etc/sysconfig/system-config-securitylevel file so that the settings can be restored the next time the application is started. Do not edit this file by hand.
直ちにファイアウォールがアクティブになっても、 iptables サービスはブート時に自動的に起動するよう設定されていません。詳細については 項25.7.2.6. 「IPTables サービスをアクティブにする」 を参照してください。
iptables サービスが実行中の場合にのみファイアウォールのルールはアクティブになります。手作業でこのサービスを起動するには、次のコマンドを使用します。
[root@myServer ~] # service iptables restart
システムがブートしたら iptables が必ず起動するようにするには、次のコマンドを使用します。
[root@myServer ~] # chkconfig --level 345 iptables on
ipchains サービスは Red Hat Enterprise Linux に含まれていません。ただし、 ipchains がインストールされている場合は (例えば、アップグレードを行いシステムに前回 ipchains がインストールされていた場合)、 ipchains サービスと iptables サービスを同時にアクティブにしないでください。 ipchains サービスが無効になっていてブート時に起動するよう設定されていないことを確認するには、次の 2 つのコマンドを使用します。
[root@myServer ~] # service ipchains stop [root@myServer ~] # chkconfig --level 345 ipchains off
iptablesを使うには、まず iptables サービスを起動します。次のコマンドを使用して iptables サービスを起動します。
[root@myServer ~] # service iptables start
注記
iptables サービスしか使用しない予定の場合は、 ip6tables サービスをオフにすることができます。 ip6tables サービスを解除する場合、 IPv6 ネットワークも解除するのを忘れないようにしてください。ファイアウォールと一致しないネットワークデバイスは、絶対にアクティブな状態にしないでください。
システムがブートしたらデフォルトで iptables を強制起動させるには、次のコマンドを使用します。
[root@myServer ~] # chkconfig --level 345 iptables on
これにより iptables はシステムがランレベル 3、 4、 5、のいずれかでブートすると必ず強制的に起動されます。
次の iptables コマンドの例では基本的なコマンドの構造を示しています。
[root@myServer ~ ] # iptables -A<chain>-j<target>
-A オプションは、ルールが <chain> に追加されることを定義しています。各チェーンは 1 つまたは複数の ルール によって構成されるので ruleset とも呼ばれます。
3 つのビルトインチェーンは、 INPUT、 OUTPUT、 FORWARD になります。これらのチェーンは永久のため削除できません。チェーンはパケットが操作されるポイントを定義します。
-j オプションはルールのターゲットを定義します。つまり、パケットがルールと一致したら何をするかなどです。ビルトインのターゲットの例としては、 ACCEPT、 DROP、 REJECT などがあります。
<target>
使用できるチェーン、オプション、ターゲットについては、 iptables の man ページを参照してください。
基本的なファイアウォールのポリシーの確立は、さらに細かなユーザー定義のルールを作る基礎となります。
各 iptables チェーンはデフォルトのポリシーと、デフォルトポリシーと連携して動作する 0 またはそれ以上のルールとで構成され、ファイアウォールの全体的なルールセットを定義します。
チェーンのデフォルトポリシーは DROP か ACCEPT のどちらかになります。セキュリティ志向の管理者はたいていデフォルトポリシーの DROP を実装し、状況に応じて特定パケットのみを許可しています。例えば、以下のポリシーではネットワークゲートウェイ上でのすべての着信及び発信パケットをブロックします。
[root@myServer ~ ] # iptables -P INPUT DROP [root@myServer ~ ] # iptables -P OUTPUT DROP
また、内部のクライアントの不注意によりインターネットに曝されてしまう危険を制限するため、 フォワードされたパケット — ファイアウォールから目的とするノードまでルーティングされるネットワークトラフィック— もすべて拒否することを推奨します。これを行うには、次のルールを使用します。
[root@myServer ~ ] # iptables -P FORWARD DROP
各チェーンのデフォルトポリシーを設定したら、特定のネットワーク及びセキュリティに必要な新しいルールを作成します。
次のセクションでは、 iptables ルールの保存方法及び iptables ファイアウォールを構築していく過程で実装するであろういくつかのルールについて概説していきます。
リモート攻撃者による LAN へのアクセスを防ぐことはネットワークセキュリティ上、最も重要な事項のひとつになります。制限の厳しいファイアウォールで、悪意あるリモートユーザーから LAN の完全性を保護しなければなりません。
しかし、着信、発信、フォワードされたパケットのすべてをブロックするデフォルトのポリシーでは、ファイアウォール/ゲートウェイと内部の LAN ユーザーがお互いに通信したり、また外部リソースと通信することは不可能になります。
ユーザーがネットワーク関連の機能を実行してネットワークアプリケーションを使用できるようにするには、管理者が通信用の特定ポートを開かなければなりません。
例えば、 ファイアウォール上で ポート 80 へのアクセスを許可するには、次のルールをアペンドします。
[root@myServer ~ ] # iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
これにより、ユーザーは標準ポート 80 経由で通信するウェブサイトを閲覧できるようになります。セキュアなウェブサイト (例えば、 https://www.example.com/ など) へのアクセスを許可するには、以下のようにしてポート 443 も開く必要があります。
[root@myServer ~ ] # iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
重要
iptables ルールセットを作成する場合、順序が重要になります。
192.168.100.0/24 サブネットからのパケットはすべてドロップするようにルールで指定され、このあとに 192.168.100.13 (これはドロップした制限サブネット内) からのパケットを許可するルールが続く場合、 2 番目のルールは無視されます。
192.168.100.13 からのパケットを許可するルールを先に指定し、その後にサブネットの残りすべてをドロップするルールを続けなければなりません。
既存のチェーン内の特定の場所にルールを挿入するには、 -I オプションを使用します。例えば、
[root@myServer ~ ] # iptables -I INPUT 1 -i lo -p all -j ACCEPT
このルールは、ローカルのループバックデバイストラフィックを許可するために INPUT チェーンに 1 番目のルールとして挿入されます。
LAN へのリモートアクセスが必要となる場合があります。 LAN サービスに対する暗号化されたリモート接続に関しては、例えば SSH のようなセキュアなサービスが使用できます。
PPP ベースのリソース (モデムバンクや大量の ISP アカウントなど) を管理する管理者の場合、ファイアウォールの壁を安全に回避するのにダイアルアップアクセスが使用できます。ダイアルアップは直接接続であり、モデムの接続は一般的にファイアウォール/ゲートウェイの背後にあるためです。
ブロードバンド接続のリモートユーザーの場合、特別な設定を行います。 iptables がリモート SSH クライアントからの接続を受けるよう設定します。例えば、次のようなルールによりリモート SSH アクセスを許可します。
[root@myServer ~ ] # iptables -A INPUT -p tcp --dport 22 -j ACCEPT [root@myServer ~ ] # iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT
これらのルールは、インターネットやファイアウォール/ゲートウェイに直接接続されている単独 PC など個別のシステムに対し、着信及び外部への送信のアクセスを許可します。しかし、ファイアウォール/ゲートウェイの後ろにあるノードには、これらのサービスへのアクセスを許可していません。これらのサービスに LAN アクセスを許可するには、 iptables フィルタールールを持つ Network Address Translation (NAT) を使用することができます。
ほとんどの ISP は顧客企業や組織に対しパブリックにルーティングが可能な IP アドレスは制限された数しか提供していません。
したがって、管理者は LAN 上の全ノードにパブリックな IP アドレスをそれぞれ振り分けることなく、インターネットサービスへのアクセスを共有できる方法を見つけなければなりません。プライベート IP アドレスの使用が LAN 上のすべてのノートに対してインターネット及び外部ネットワークサービスへの正常なアクセスを確保する最も一般的な方法となります。
エッジルータ (ファイアウォールなど) はインターネットから着信を受けそのパケットを目的の LAN ノードへルーティングすることができます。同時に、ファイアウォール/ゲートウェイは LAN ノートからリモートインターネットサービスへの発信要求をルーティングすることも可能です。
このネットワークトラフィックの転送は、特に 内部 IP アドレスになりすましてリモート攻撃者のマシンを LAN 上のノードのように見せかけることが可能な最近のクラッキングツール機能を使用されると非常に危険になります。
このような危険を防ぐために、 iptables はネットワークリソースの異常な使用を防ぐために実装できるルーティング及びフォワーディングのポリシーを提供しています。
FORWARD チェーンを使用することで管理者は LAN 内でパケットがルーティングされる場所を制御することができます。例えば、 LAN 全体にフォワーディングを許可するには (ファイアウォール/ゲートウェイが内部 IP アドレスを eth1 に持っていると仮定) 、次のルールを使用します。
[root@myServer ~ ] # iptables -A FORWARD -i eth1 -j ACCEPT [root@myServer ~ ] # iptables -A FORWARD -o eth1 -j ACCEPT
このルールはファイヤーウォール/ゲートウェイの裏にあるシステムに内部ネットワークへのアクセスを与えます。ゲートウェイは 1 つの LAN ノードからのパケットをその目的地ノードにルーティングし、その eth1 デバイス経由で全パケットを渡します。
注記
デフォルトでは、 Red Hat Enterprise Linux カーネル内の IPv4 ポリシーが IP フォワーディングのサポートを無効にしています。 Red Hat Enterprise Linux を稼動しているマシンが専用エッジルータとして機能しないようにしています。 IP フォワーディングを有効にするには、次のコマンドを実行します。
[root@myServer ~ ] # sysctl -w net.ipv4.ip_forward=1
この設定変更は現在のセッションにのみ有効です。つまり、再ブートやネットワークサービスの再起動を行うと持続しなくなります。 IP フォワーディングを永久的に設定するには、以下のように /etc/sysctl.conf ファイルを編集します。
次の行を探します。
net.ipv4.ip_forward = 0
これを次のように編集します。
net.ipv4.ip_forward = 1
次のコマンドを実行して sysctl.conf ファイルヘの変更を有効にします。
[root@myServer ~ ] # sysctl -p /etc/sysctl.conf
ファイアウォールの内部 IP デバイスを経由してフォワードパケットを受け付けることで、 LAN ノードは互いに通信できるようになります。しかし、インターネットへの外部通信はできません。
プライベート IP アドレスを持つ LAN ノードに外部の公共ネットワークとの通信を許可するには、 IP マスカレード 用にファイアウォールを設定します。これは LAN ノードからの要求をファイアウォールの外部デバイスの IP アドレスでマスクします (この場合、eth0)。
[root@myServer ~ ] # iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
このルールは、 NAT パケットの照合表 (-t nat) を使用してファイアウォールの外部ネットワークデバイス (-o eth0) にある NAT のビルトイン POSTROUTING チェーン (-A POSTROUTING) を指定します。
POSTROUTING により、パケットはファイアウォールの外部デバイスを出る時点で変化することができます。
-j MASQUERADE ターゲットは、あるノードのプライベート IP アドレスをファイアーウォール/ゲートウェイの 外部 IP アドレスでマスクするように指定されます。
内部ネットワーク上にサーバーがあり外部で使用できるようにしたい場合、 NAT 内 の PREROUTING チェーンの -j DNAT ターゲットを使用して、内部サービスへの接続を要求している着信パケットがフォワードできる目的地の IP アドレスとポートを指定することができます。
例えば、着信 HTTP 要求を 172.31.0.23 にある専用 Apache HTTP Server にフォワードしたい場合、次のコマンドを実行します。
[root@myServer ~ ] # iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to 172.31.0.23:80
このルールは nat の表がビルトイン PREROUTING チェーンを使用して着信 HTTP 要求を記載された目的 IP アドレスである 172.31.0.23 だけに独占的にフォワードするよう指定します。
注記
FORWARD チェーン内に DROP のデフォルトポリシーを持っている場合、 1 つルールを追加して目的地の NAT ルーティングが可能になるようにすべての着信 HTTP 要求を転送するようにします。これを実行するには、次のコマンドを入力します。
[root@myServer ~ ] # iptables -A FORWARD -i eth0 -p tcp --dport 80 -d 172.31.0.23 -j ACCEPT
このルールはすべての着信 HTTP 要求をファイアーウォールからファイアーウォール裏にあるその目的地 Apache HTTP Server に転送します。
非武装地帯 - demilitarized zone (DMZ) 内の専用 HTTP や FTP などの特定のマシンにトラフィックをルーティングするよう iptablesルールを設定することができます。 DMZ はインターネットなどの公共キャリア上でサービスを提供することを目的とした特殊なローカルサブネットワークです。
例えば、着信 HTTP 要求を 10.0.4.2 (LAN の 192.168.1.0/24 範囲外) にある専用 HTTP サーバーにルーティングするようルールを設定するには、 NAT に PREROUTING テーブルを使用させてパケットを適切な目的地に転送するようにさせます。
[root@myServer ~ ] # iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 10.0.4.2:80
このコマンドを使用すると、 LAN 外部からのポート 80 に対するすべての HTTP 接続は内部ネットワーク上にあるが他の内部ネットワークとは分離されている HTTP サーバーにルーティングされます。このようなネットワーク区分化は、ネットワーク上のマシンに HTTP 接続を許可するよりも安全です。
HTTP サーバーがセキュアな接続を受け取るよう設定されている場合、ポート 443 もフォワードされる必要があります。
特定のサブネットへのアクセス、あるいは LAN 内の特定のノードへのアクセスさえ制御する複雑なルールを作成することもできます。また、トロイやワーム、その他クライアント/サーバーのウィルスなど特定の不審なアプリケーションやプログラムがサーバーにコンタクトしないよう制限することもできます。
例えば、 31337 から 31340 のポートのサービスに対してネットワークをスキャンするトロイがあります (クラッキング用語では elite ポートと呼ばれています)。
このような非標準のポートで通信を行う合法的なサービスはないため、これらのサービスをブロックすることで自分のネットワーク上で感染している可能性のあるノードが独力でリモートマスターサーバーと通信する可能性を効果的に減少させることができます。
次のルールはポート 31337 の使用を試みるすべての TCP トラフィックをドロップします。
[root@myServer ~ ] # iptables -A OUTPUT -o eth0 -p tcp --dport 31337 --sport 31337 -j DROP [root@myServer ~ ] # iptables -A FORWARD -o eth0 -p tcp --dport 31337 --sport 31337 -j DROP
また、 LAN に潜入するためにプライベート IP アドレス範囲になりすまそうとする外部接続をすべてブロックすることもできます。
例えば、 LAN が 192.168.1.0/24 範囲を使用しているなら、インターネットに面しているネットワークデバイス (例、eth0) に LAN IP 範囲内のアドレスを持つそのデバイスへのパケットはすべてドロップするよう指示するルールを作成することができます。
デフォルトポリシーでフォワードされたパケットは拒否するよう推奨されているため、外部に面しているデバイス (eht0) への IP アドレスなりすましはいずれも自動的に拒否されます。
[root@myServer ~ ] # iptables -A FORWARD -s 192.168.1.0/24 -i eth0 -j DROP
注記
追加された ルールを扱う場合、 DROP ターゲットと REJECT ターゲットとの間には相異点があります。
REJECT ターゲットは、アクセスを拒否してそのサービスに接続を試行するユーザーに connection refused のエラーを返します。 DROP ターゲットは名前の通り、何の警告もせずにパケットをドロップします。
これらのターゲットは管理者の判断で使用することができますが、ユーザーが混乱して接続試行をくり返してしまうのを防ぐために REJECT ターゲットの使用が推奨されます。
接続状態 を基にしてサービスに対する接続を検査、制限することができます。 iptables 内のモジュールは 接続トラッキング と呼ばれるメソッドを使用して着信接続に関する情報を保存します。次のような接続状態を基にしてアクセスの許可や拒否をすることができます。
-
NEW— HTTP 要求などの新規の接続を要求しているパケット -
ESTABLISHED— 既存接続の一部であるパケット -
RELATED— 新規の接続を要求しているが、既存接続の一部であるパケット。例えば、 FTP は接続の確立にポート 21 を使用するが、データは別のポート上で転送される (一般的にはポート 20)。 -
INVALID— connection tracking 表内でのいずれの接続の一部でもないパケット。
プロトコル自身がステートレスであっても (UDP など)、いずれのネットワークプロトコルでも iptables の接続トラッキングのステートフル機能を使用できます。次の例では、接続トラッキングを使用して確立済みの接続に関連したパケットのみをフォワードするルールを示しています。
[root@myServer ~ ] # iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
次世代インターネットプロトコル、 IPv6 の導入により IPv4 (または IP) による 32 ビットアドレスの制限が拡大されます。 IPv6 は 128 ビットアドレスに対応するため、 IPv6 対応のキャリアネットワークは IPv4 より多くのルーティング可能なアドレスを扱うことができます。
Red Hat Enterprise Linux は、 Netfilter 6 サブシステムと ip6tables コマンドを使用する IPv6 ファイアウォールのルールに対応しています。 Red Hat Enterprise Linux 5 では、 IPv4 と IPv6 いずれもデフォルトで有効になっています。
ip6tables コマンド構文は、 128 ビットアドレスをサポートする点以外あらゆる面で iptables と同じです。例えば、 IPv6 対応のネットワークサーバー上の SSH 接続は以下のようなコマンドで有効にできます。
[root@myServer ~ ] # ip6tables -A INPUT -i eth0 -p tcp -s 3ffe:ffff:100::1/128 --dport 22 -j ACCEPT
IPv6 ネットワークについての詳細は、 http://www.ipv6.org/ にある IPv6 情報ページを参照してください。
ファイアウォール及び Linux Netfilter サブシステムについてこの章で触れていないことがいくつかあります。詳細については、次のリソースを参照してください。
-
さまざまなコマンドオプションの定義など、
iptablesコマンドについての詳細は 項25.8. 「IPTables」 を参照してください。 -
iptablesの man ページには、各種オプションの簡単な概要も記載されています。
-
http://www.netfilter.org/ — Netfilter 及び
iptablesプロジェクトの公式ホームページです。 -
http://www.tldp.org/ — Linux Documentation Project にはファイアウォール構築と管理に関連した役に立つガイドがいくつかあります。
-
http://www.iana.org/assignments/port-numbers — IANA (Internet Assigned Numbers Authority) によって割り当てられた一般的な登録サービスポートの公式一覧です。
-
Red Hat Linux Firewalls、 Bill McCarty 著、 Red Hat Press — Netfilter 及び
iptablesなどのオープンソースパケットフィルタリング技術を使用したネットワークとサーバーのファイアウォール構築に関する総合的な参考文献になります。ファイアウォールログの解析、ファイアウォールルールの開発、各種グラフィカルツールを使用したファイアウォールのカスタマイズなどについてのトピックが含まれています。 -
Linux Firewalls、 Robert Ziegler 著、 New Riders Press — 2.2 カーネル
ipchains、及び Netfilter とiptablesの両方を使ったファイアウォールの構築に関する豊富な情報が満載されています。リモートアクセスの問題や侵入検知システムなどのセキュリティ事項についても触れられています。
Red Hat Enterprise Linux にはネットワーク用の高度なツール: パケットフィルタリング がインストールされています — カーネル内でネットワークスタックを通じてネットワークパケットが進入、通過、退出するのを制御するプロセスです。 バージョン 2.4 以前のカーネルはパケットフィルタリングについて ipchains に依存しており、フィルタリングプロセスの各ステップでパケットに適用される規則の一覧を使用していました。バージョン 2.4 の到来により、 iptables (netfilter とも呼ばれる) が導入されました。これは ipchains と似ていますが、ネットワークパケットのフィルタリングに利用できる範囲や制御が大幅に拡張しています。
この章では、パケットフィルタリングの基礎に焦点をおき、 ipchains と iptables の違いを明確にして、 iptables コマンドで使用できるさまざまなオプションを説明します。また、システムを再起動する際にフィルタリング規則を保持する方法を説明しています。
iptables の規則の作成とこれらの規則に基づくファイアウォールの設定については、 項25.8.7. 「その他のリソース」 を参照してください。
警告
2.4 カーネルとそれ以降のカーネルでのデフォルトのファイアーウォール機能は iptables です。しかし、 ipchains が既に起動している場合、 iptables を使う事ができません。 ipchains がシステム起動時に存在すると、カーネルはエラーを表示し iptables の起動に失敗します。
これらのエラーメッセージは ipchains の機能に影響を与えるものではありません。
Linux カーネルはパケットをフィルタリングする Netfilter 機能を使用するので、他のパケットを阻止しながら一部のパケットだけがシステムに入ってくるようにすることができます。この機能は Linux カーネルに組みこまれており、三つの組みこみ テーブル 、すなわち 規則一覧 が含まれています。以下のようなものです:
-
filter— ネットワークパケットを処理するデフォルトのテーブル。 -
nat— 新規接続を作成するパケットの変更、及び Network Address Translation (NAT) に使用。 -
mangle— パケット変更の特定タイプに使用。
各テーブルは組込み型の チェーン のグループを１つ持ち、それぞれが netfilter によってパケットに実行されるアクションに相当します。
フィルタ テーブル用の組込み型チェーンは以下のようになります：
-
INPUT — ホスト用のターゲットとされているネットワークパケットに適用します。
-
OUTPUT — ローカル生成のネットワークパケットに適用します。
-
FORWARD — ホストを通ってルーティングしたネットワークパケットに適用します。
nat テーブル用の組込み型チェーンは以下のようになります：
-
PREROUTING — ネットワークパケットが到着するとそれを変更します。
-
OUTPUT — ローカル生成のネットワークパケットを送信される前に変更します。
-
POSTROUTING — ネットワークパケットが送信される前にそれを変更します。
mangle テーブルの組込み型チェーンは以下の様になります：
-
INPUT — ホスト用にターゲットされているネットワークパケットを変更します。
-
OUTPUT — ローカル生成のネットワークパケットを送信される前に変更します。
-
FORWARD — ホストを通してルーティングしたネットワークパケットを変更します。
-
PREROUTING — 着信のネットワークパケットをルーティングされる前に変更します。
-
POSTROUTING — ネットワークパケットが送信される前にそれを変更します。
Linux システムで受信/送信されたすべてのネットワークパケットは少くとも1つのテーブルに従います。しかし、チェーンの最後に現われる前に、パケットは各テーブル内の複数の規則に従うこともあります。これらの規則の構成や目的には相違がありますが、通常特定のプロトコル及びネットワークサービスを使用する時に、特定の IP アドレスまたは複数セットの IP アドレスに送受信するパケットを識別する為に使われます。
注記
デフォルトで、ファイヤーウォール規則は /etc/sysconfig/iptables か、又は /etc/sysconfig/ip6tables ファイルに保存されます。
iptables サービスは、 Linux システムの起動時に DNS-関連のサービスの前に始まります。このことは、ファイヤーウォール規則が数値の IP アドレス (例:192.168.0.1) のみを参照すると言う意味になります。ドメイン名 (例: host.example.com) はこのような規則ではエラーを発生します。
その目的地に関係なく、パケットがテーブルの１つの特定の規則に適合すると、ある ターゲット 、すなわちアクションがパケットに応用されます。規則に適合するパケットに ACCEPT ターゲットを指定している場合、パケットは規則チェックの残りの部分をスキップして、その目的地に進むことを許可されます。規則が DROP ターゲットを指定している場合、パケットはシステムへのアクセスを拒否されてパケットを発信したホストには何も返信されません。規則が QUEUE ターゲットを指定している場合、パケットはユーザースペースへパスされることになります。規則がオプションの REJECT ターゲットを指定している場合、パケットはドロップされますが、エラーパケットがパケットの発信元へ送られます。
それぞれのチェーンは ACCEPT、 DROP、 REJECT、 QUEUE のいずれかのデフォルトポリシーを持っています。このチェーン内の規則のどれもパケットに適応しない場合、パケットはデフォルトポリシーに従って扱われます。
iptables コマンドはこれらのテーブルを設定するだけでなく、必要であれば、新しいテーブルのセットアップもします。
ipchains と iptables は両方とも、指定規則や規則セットへの適合を基にしてパケットをフィルターする為に Linux カーネル内で動作する規則のチェーンを使用します。しかし、 iptables を使用するとより拡張性のある方法でパケットをフィルタリングできるので、管理者は複雑な作業をせずに、きめ細かい制御を行うことができます。
iptables と ipchains の重要な相違について以下の点に注意して下さい:
-
iptablesを使用すると、それぞれのフィルターされたパケットは、複数のチェーンではなく、１つのチェーンのみからのルールでプロセスされます。 -
例えば、
ipchainsを使用してシステムに入ってきた FORWARD パケットは、 INPUT、 FORWARD、 OUTPUT の各チェーンを通らないと送信先に進めません。ところが、iptablesでは、送信先がローカルシステムの場合は INPUT チェーンへ、ローカルシステムがパケットを生成した場合は OUTPUT チェーンのみにパケットが送信されます。この理由で、パケットを実際に調べる規則の中で特定のパケットを取り込む様に設計された規則を用意するのは重要なことになります。 - DENY ターゲットは DROP に変更されました。
-
ipchainsでは、チェーン内の規則に一致したパケットは DENY ターゲットに送られます。このターゲットはiptablesの中では DROP に変更されなければいけません。 - 規則にオプションを配置する時の順序は重要です。
-
ipchainsでは、規則オプションの順序は重要ではありません。iptablesコマンドでは、もっと厳密な構文を使用します。iptablesコマンドの中のプロトコル (ICMP、TCP、UDP) は、送信元、又は送信先のポートの前で指定する必要があります。 - ネットワークインターフェイスはファイヤーウォールの正しいチェーンとの関連づけが必要です。
-
例えば、着信インターフェース (
-iオプション) では FORWARD 又は OUTPUT チェーン内でのみ使用できます。同様に発信インターフェイス (-oオプション) は FORWARD 又は OUTPUT チェーン内でのみ使用できます。別の言い方をすると、 INPUT チェーンと受信インターフェイスは一緒に機能します。 OUTPUT チェーンと送信インターフェイスは一緒に機能します。 FORWARD チェーンは受信と送信の両インターフェイスと一緒に機能します。
OUTPUT チェーンは現在は、受信インターフェイスでは使用されません。そして、 INPUT チェーンは送信インターフェイスを通って移動するパケットには見えません。
このリストは変更の完全なリストではありません。詳細情報に関しては、 項25.8.7. 「その他のリソース」 を参照して下さい。
パケットをフィルタリングする規則は、 iptables コマンドを使用して作成されます。以下のようなパケットの要点が基準としてよく使用されます:
-
パケットタイプ — コマンドがフィルタするパケットのタイプを指定します。
-
パケットの送信元/送信先 — パケットの送信元、又は送信先に基づいてコマンドがフィルタするパケットを指定します。
-
ターゲット — 上記の基準に適合するパケットに対して実行されるアクションを指定します。
パケットのこのような側面に対応する特定のオプション関する詳細情報を得るには、 項25.8.3.4. 「IPTables 一致オプション」 と 項25.8.3.5. 「ターゲットオプション」 を参照して下さい。
特定の iptables 規則で使用されるオプションは、規則を有効にする為に、規則全体の目的と条件を元にして論理的にグループ化する必要があります。これ以降のセクションでは iptables コマンドによく使われるオプションを説明していきます。
多くの iptables コマンドの構成は、次のようになります:
iptables [-t <table-name>] <command><chain-name> \ <parameter-1><option-1> \ <parameter-n><option-n>
<table-name> — 規則が適用するテーブルを指定します。もし欠如している場合は、 filter テーブルが使用されます。
<command> — 規則の追加や削除などの実行するアクションを指定します。
<chain-name> — 編集、作成、削除などをするチェーンを指定します。
<parameter>-<option> pairs — 規則に適合するパケットをプロセスする方法を指定するパラメータと関連オプションです。
iptables コマンドの長さと複雑性は、その目的に応じて大幅に変更可能です。
例えば、チェーンから規則を削除するコマンドは非常に短くできます:
iptables -D
<chain-name> <line-number>
それに比べて、色々な指定のパラメータやオプションを使用した特定のサブネットからパケットをフィルターする規則を追加するコマンドはかなり長くなります。 iptables コマンドを構成する時には、幾つかのパラメータとオプションは、有効な規則を作る為に更なるパラメータとオプションが必要となることを忘れないで下さい。そうすることにより、別のパラメータを必要とするパラメータにより、キャスケード効果を創造できます。追加のオプションを必要とする全てのパラメータとオプションが全て満足された状態になるまで、規則は有効ではありません。
iptables -h と入力すると、 iptables コマンドの構成の総合一覧が表示されます。
コマンドオプションは、 iptables が特定の動作を行なうよう指示します。1つの iptables コマンドにつき使用できるコマンドオプションは1つだけです。ヘルプコマンドを除くすべてのコマンドは大文字で作成します。
iptables のコマンドには、次のようなものがあります：
-
-A— 指定されたチェーンの最後に規則を追加します。以下に説明のある-Iオプションとは異り、これは正数の引数は使用しません。規則は常に指定のチェーンの最後に追加します。 -
-C— 指定したチェーンに追加する前に特定の規則をチェックします。このコマンドは、パラメータとオプションを追加するときにプロンプトが表示されるので、複雑なiptables規則を作成する場合に便利です。 -
-D <integer> | <rule>— 番号、又は規則仕様別に規則を特定のチェーンから削除します (チェーン内の 5 番目の規則は5など)。規則仕様は終了規則に完全に一致する必要があります。 -
-E— ユーザー定義のチェーンを改名します。ユーザー定義のチェーンはデフォルトで既存チェーン以外の全てのチェーンのことです (ユーザー定義のチェーンの作成には、以下の-Nオプションを参照)。これは化粧的な変更であり、テーブルの構成には影響しません。注記
デフォルトチェーンの１つを改名しようと試みると、システムは
Match not foundエラーを表示します。デフォルトチェーンは改名できません。 -
-F— 選択したチェーンを洗浄して、そのチェーンからすべての規則を削除します。チェーンを指定しない場合は、すべてのチェーンのすべての規則が削除されます。 -
-h— コマンドの構成の一覧とコマンドパラメータ、オプションの簡単な説明などが表示されます。 -
-I [<integer>]— 指定のチェーン内のユーザー定義の数値で指定された位置に規則を挿入します。数値が指定されていない場合、規則はチェーンの最上部に置かれます。注意
上記に示してあるように、チェーン内の規則の順序が、パケットに適用される規則を決定します。これは、
-Aか-Iオプションを使用して規則を追加する場合に記憶しておくことが重要です。これは特に正数の引数で、
-Iを使って規則を追加する場合に重要になります。チェーンに規則を追加する時に既存の番号を指定すると、iptablesは 既存規則の 前に (又は、上に) 新しい規則を追加します。 -
-L— コマンドの後で指定するチェーン内にあるすべての規則を一覧表示します。チェーンとテーブルを指定しない場合は、デフォルトのfilterテーブル内にあるすべてのチェーンのすべての規則が一覧表示されます。それ以外の場合は、次の構文を使用して、規則を一覧するチェーンとテーブルを指定します。iptables -L<chain-name>-t<table-name>規則の番号を提供したり、規則の詳細説明を可能にする
-Lコマンドオプションの他の、追加オプションは、 項25.8.3.6. 「リストオプション」 で説明されています。 -
-N— 指定した名前で新しいチェーンを作成します。チェーン名は独自なものでなければ、エラーメッセージが表示されます。 -
-P— 指定したチェーンについてデフォルトのポリシーを設定します。これによって、パケットがチェーン内にあるどの規則をも満たさない場合には、 ACCEPT や DROP など指定されたターゲットに送られます。 -
-R— 指定されたチェーンの規則を置き換えます。規則の番号はチェーン名の後に指定する必要があります。チェーン内の最初の規則が、規則番号「1」になります。 -
-X— 指定したチェーンを削除します。組み込まれているチェーンは削除できません。 -
-Z— テーブル用のすべてのチェーンのバイトとパケットカウンタを 0 にします。
特定のチェーンにおける規則の追加、削除、挿入、交換などの規則を含む一定の iptables コマンドは、パケットフィルタリング規則を構築するためのパラメータを必要とします。
-
-c— 特定の規則のカウンタをリセットします。このパラメータでは、リセットするカウンタを指定するためのPKTSオプションと、BYTESオプションを受け付けます。 -
-d— 規則を満たすパケットの送信先ホスト名、 IP アドレス、ネットワークのどれかを設定します。ネットワークと一致する場合、以下のような IP アドレス/ネットマスク形式がサポートされます。-
N.N.N.N/M.M.M.MN.N.N.Nは IP アドレスの範囲であり、M.M.M.Mはネットマスクです。 -
N.N.N.N/MN.N.N.Nは IP アドレスの範囲であり、Mはネットマスクです。
-
-
-f— 断片化されたパケットのみに規則を適用します。このパラメータの後に感嘆符
!オプションを使用すると、断片化されていないパケットのみが適合するように指定できます。注記
フラグメント化したパケットは IP プロトコルの標準部分であることにも関わらず、フラグメント化したパケットとフラグメントのないパケットとの区別が理想的です。
異なるフレームサイズでネットワーク上を移動する IP パケットを許可するように本来設計されているのですが、今日では、フラグメンテーションは、一般に異常形成のパケットを使用した DoS 攻撃を生成するのに使われます。 IPv6 は全くフラグメンテーションを許可しないことに充分注意して下さい。
-
-i—eth0やppp0などの着信ネットワークインターフェースを設定します。iptablesでは、このオプションパラメータを使用できるのは、filterテーブルの場合は INPUT チェーンと FORWARD チェーンと共に、またnatテーブルとmangleテーブルの場合は PREROUTING チェーンと共に使用する時だけです。このパラメータはまた、以下のような特殊オプションもサポートします：
-
感嘆符
!— ディレクティブをリバースします、つまり指定されたインターフェースをこの規則から除外します。 -
プラス記号
+— 指定された文字列に一致するすべてのインターフェースを一致の対象とするワイルドカード文字です。たとえば、-i eth+というパラメータを指定すると、すべてのイーサネットインターフェースにこの規則が適用されますが、ppp0などの他のインターフェースは除外します。
-i— パラメータを使用する場合にインターフェースを指定しないと、すべてのインターフェースが対象となります。 -
-
-j— パケットが特定の規則に一致する場合に指定ターゲットにジャンプします。標準ターゲットには
ACCEPT、DROP、QUEUE、RETURNがあります。Red Hat Enterprise Linux
iptablesRPM パッケージにデフォルトでロードされているモジュールを経由して利用可能な拡張オプションもあります。そのようなモジュールには、LOG、MARK、REJECTなどがあります。これらのオプションと他のターゲットに関する詳細は、iptablesの man ページを参照してください。このオプションは、また特定の規則に一致するパケットを現在のチェーンの外にあるユーザー定義のチェーンへ転送するのに使用して、他の規則がそのパケットに適用できるようにします。
ターゲットを指定しない場合、いかなる動作も行わずにパケットが通過します。しかし、この規則のカウンタには1つ増加します。
-
-o— 1つの規則の為に発信ネットワークを設定します。このオプションは、filterテーブルの OUTPUT チェーンと FORWARD チェーン、natテーブルとmangleテーブルの POSTROUTING チェーンのみで有効です。このパラメータは、着信ネットワークインターフェースパラメータ （-i）と同じオプションを受け付けます。 -
-p <protocol>— 規則に影響を受ける IP プロトコルを設定します。icmp、tcp、udp、allのどれか、あるいはその１つの、又は別のプロトコルを代表する数値でも可能です。また/etc/protocolsに一覧表示してあるプロトコルも使用できます。"
all" プロトコルとは、規則が全てのサポートされたプロトコルに適用されるという意味です。この規則にプロトコルが記載されていない場合、これはデフォルトの "all"になります。 -
-s— 送信先パラメータ（-d）と同じ構文を使用して、特定のパケットの送信元を設定します。
異なるネットワークプロトコルは、特別な照合オプションを用意して、そのプロトコルを使用して特定のパケットと一致するように設定できます。ただし、このプロトコルは最初に、 iptables コマンドに指定される必要があります。 -p で、指定されたプロトコル用のオプションを利用できるようにします。また、プロトコル名の代わりにプロトコル ID も使用できます。それぞれが同じ効果を持つ以下の例を参照して下さい:
<protocol-name>
iptables -A INPUT -p icmp --icmp-type any -j ACCEPTiptables -A INPUT -p 5813 --icmp-type any -j ACCEPT
サービスの定義は /etc/services ファイル内に提供されています。読み易い表示には、ポート番号ではなくサービス名を使用して下さい。
重要
許可のない編集を防止するためには、 /etc/services ファイルを安全にします。このファイルが編集可能であると、停止しているはずのマシン上のポートを有効にするためにクラッカーがその編集を使用することができます。このマシンを安全にするには、 root として以下のコマンドを入力します:
[root@myServer ~]# chown root.root /etc/services [root@myServer ~]# chmod 0644 /etc/services [root@myServer ~]# chattr +i /etc/services
これが、このファイルの改名、削除、あるいはファイルへのリンクの作成などを防止します。
TCP プロトコル （-p tcp） では、以下の照合オプションを使用できます:
-
--dport— パケットの目的地ポートをセットします。このオプションを設定するには、 (www や smtp などの) ネットワークサービス名； ポート番号；又はポート番号の幅を使用します。
ポート番号の範囲を指定するには、
-p tcp --dport 3000:3200の ように2つの番号をコロン （:） で区切ります。最大の許容有効範囲は、0:65535です。--dportオプションの後で感嘆符 （!） を使用して、そのネットワークサービスあるいはポートを 使用しない すべてのパケットを照合します。ネットワークサービスとそれらが使用するポート番号の名前とエイリアスを閲覧するには、
/etc/servicesファイルを表示します。--destination-port照合オプションは--dportと同じです。 -
--sport—--dportと同じオプションを使用して、パケットの送信元ポートを設定します。--source-portの照合オプションは--sportと同義です。 -
--syn— 一般に SYNパケット と呼ばれる、通信を開始するよう設計されたすべての TCP パケットに適用されます。データペイロードを運搬するパケットはいずれも干渉されません。--synオプションの後に、感嘆符 (!) を使用すると、全ての非 SYN パケットが照合されます。 -
--tcp-flags <tested flag list> <set flag list>— 規則に適合するように特定のビット (フラグ) セットをもつ TCP パケットを許可します。--tcp-flags照合オプションは二つのパラメータを受けつけます。最初のパラメータはマスクであり、パケット内で検証されるフラグのコンマで隔離されたリストです。二番目のパラメータは照合する規則用にセットすべきフラグのコンマで隔離されたリストです。使用できるフラグは以下のようになります：
-
ACK -
FIN -
PSH -
RST -
SYN -
URG -
ALL -
NONE
たとえば、以下の仕様を含む
iptables規則は、 SYN フラグがセットされており、 ACK フラグと FIN フラグがセットされていない TCP パケットのみを照合します。--tcp-flags ACK,FIN,SYN SYN感嘆符 (
!) を--tcp-flagsの後で使用すると、照合オプションの効果が逆転されます。 -
-
--tcp-option— 特定のパケットで設定できる TCP 特有のオプションを照合しようとします。感嘆符 （!） を使用すると、意味を反対にすることができます。
UDPプロトコル（-p udp）では、以下の照合オプションを使用できます。
-
--dport— サービス名、ポート番号、ポート番号の範囲のどれかを使用して、 UDP パケットの送信先ポートを指定します。--destination-portの照合オプションは--dportと同義となります。 -
--sport— サービス名、ポート番号、ポート番号の範囲などのいずれかを使用して UDP パケットの送信元ポートを指定します。--source-portの照合オプションは--sportと同義です。
--dport と --sport のオプションに、ポート番号の範囲を指定するには、 -p tcp --dport 3000:3200 のように2つの番号をコロン （:） で区切ります。最大の許容有効範囲は、 0:65535 です。
ICMP（Internet Control Message Protocol）には (-p icmp)、次の照合オプションが使用できます。
-
--icmp-type— 規則と一致する ICMP タイプの番号か名前を設定します。有効な ICMP 名の一覧は、iptables -p icmp -hというコマンドを入力すると表示されます。
追加の照合オプションは iptables コマンドでロードできるモジュールを通じて使用できます。
照合オプションモジュールを使用するには、 -m を使用して、名前の指定でモジュールをロードする必要があります (<module-name><module-name> はモジュールの名前で入れ換えます)。
デフォルトで多くのモジュールが利用できるようになっています。追加機能を提供するモジュールを作成することもできます。
以下に、よく使われるモジュールのいくつかを挙げてみました。
-
limitmodule — 特定の規則に照合されるパケットの数量を規制します。LOGターゲットと一緒に使用すると、limitモジュールは大量の照合パケットが反覆メッセージでシステムログを満杯にしたり、システムリソースを満杯にしてしまうのを防止することができます。LOGターゲットに関する詳細情報には、 項25.8.3.5. 「ターゲットオプション」 を参照してください。limitモジュールは以下のようなオプションを有効にします：-
--limit— 特定の時間帯に照合する最大回数を設定します。<value>/<period>--limit 5/hourと指定すると、1時間に5回だけ規則が照合されます。期間は秒、分、時、あるいは日で指定できます。
回数と時間を指定しない場合は、デフォルト値の
3/hourが使用されます。 -
--limit-burst— 一度に照合できるパケットの数を制限します。このオプションは整数として指定されており、
--limitオプションと一緒に使用されるべきものです。値を指定しない場合は、デフォルト値の 5 が適用されます。
-
-
stateモジュール — 接続状態について照合を有効にします。stateモジュールは以下のようなオプションを有効にします：-
--state— 以下の接続状態についてパケットを照合します：-
ESTABLISHED— 照合パケットは確立された接続内にある他のパケットに関係関連付けられます。クライアントとサーバー間の接続を維持したい場合、この状態を受理する必要があります。 -
INVALID— 既知の接続に結び付けられないパケットが規則を満たします。 -
NEW— 照合パケットは新しい接続を作成しているか、又は以前に出現したことのないニ方向接続の一部です。新しい接続をサービスに許可したい場合、この状態を受理する必要があります。 -
RELATED— 照合パケットは既存の接続になんらかの関連を持つ新しい接続を開始しています。この一例は FTP であり、これは制御トラフィック (ポート21) 用に１つの接続を使用して、データ転送 (ポート20) 用に別の接続を使います。
これらの接続状態を複数組み合わせて使用するには、
-m state --state INVALID,NEWのようにカンマで区切ります。 -
-
-
macモジュール — ハードウェア MAC アドレスの照合を有効にします。macモジュールは以下のようなモジュールを有効にします：-
--mac-source— パケットの送信元であるネットワークインターフェースカードの MAC アドレスを照合します。ある規則から MAC アドレスを除外するには、--mac-source照合オプションの後に感嘆符 (!) を付けます。
-
モジュールを通じて利用できる照合オプションの詳細については、 iptables の man ページを参照してください。
パケットが特定の規則を満たすと、規則はそのパケットを異るの数種のターゲットへ向け、 これらのターゲットが適切な動作を決定します。各チェーンにはデフォルトのターゲットがあり、そのチェーンの規則を満たすパケットがない場合か、あるいはパケットが満たした規則のいずれもがターゲットを指定していない場合に使用されます。
標準(デフォルト)のターゲットには以下のようなものがあります：
-
<user-defined-chain> -
ACCEPT— パケットがその送信先または別のチェーンに移動する ことを許可します。 -
DROP— パケットを送信したシステムには何も通知せずに パケットをドロップします。パケットを送信したシステムは不具合の報告も受けません。 -
QUEUE— ユーザースペースのアプリケーションで処理されるように パケットをキューに登録します。 -
RETURN— 現在のチェーン内の規則に対するパケットのチェックを停止します。RETURNターゲットを持つパケットが別のチェーンから呼び出されたチェーンの規則を満たす場合、そのパケットは最初のチェーンに戻され、そこで規則チェックが再開されます。組み込み型のチェーンでRETURN規則を使用していてパケットが前のチェーンに戻れない場合は、現在のチェーンのデフォルトターゲットが使用されます。
更には、他のターゲットが指定されるように許可をする拡張も利用できます。これらの拡張は ターゲットモジュール、又は照合オプションモジュールと呼ばれ、ほとんどの場合、特定の テーブルと状況のみに適用されます。照合オプションモジュールの詳細については、項25.8.3.4.4. 「その他の照合オプションモジュール」 を参照してください。
多くの拡張ターゲットモジュールがありますが、ほとんどは特定のテーブルか状況のみに適用されます。デフォルトで Red Hat Enterprise Linux に含まれているターゲットモジュールでよく使用されるものには、次のようなものがあります:
-
LOG— 規則を満たすすべてのパケットを記録します。パケットを記録するのはカーネルなので、/etc/syslog.confファイルがこれらの記録の書き込み場所を決定します。デフォルトではこの場所は/var/log/messagesファイルです。ログが行なわれる方法を指定するために、
LOGターゲットの後に 追加オプションを使用できます。-
--log-level— イベントを記録する優先レベルを設定します。優先レベルの一覧は、syslog.confの manページを参照して ください。 -
--log-ip-options— IP パケットのヘッダ内で設定された オプションを記録します。 -
--log-prefix— ログを記録するときに、行の先頭に 29 文字までの文字列を設置します。これは、パケットの記録と共に使用する syslog フィルタを作成する場合にも便利です。注記
このオプションに存在する問題のため、
log-prefixの値に対して 後に空白を付加する必要があります。 -
--log-tcp-options— TCPパケットのヘッダーで設定してあるオプションをログします。 -
--log-tcp-sequence— パケットの TCPシーケンス番号を記録します。
-
-
REJECT— パケットを送信したシステムにエラーパケットを送り返して、パケットをドロップします。REJECTターゲットでは、--reject-with(<type><type>は 拒絶のタイプ)を受け、エラーパケットと共に返送される詳細情報を認可します。他のオプションが使用されていない場合、メッセージport-unreachableがデフォルトで与えられるエラータイプです。<type>iptablesの manページを参照してください。
nat テーブルを使用した IPマスカレード、又は mangle テーブルを使用したパケット変更で役に立つものなど、その他のターゲット拡張の幾つかは、iptables の manページを参照してください。
デフォルトのリストコマンド iptables -L [<チェーン名>]は、デフォルトのフィルタテーブルの現在のチェーンについて非常に基本的な概要情報を提供します。追加のオプションは更に詳細情報を提供します：
-
-v— 各チェーンが処理したパケット数とバイト数、各規則を満たしたパケット数とバイト数、特定の規則に適用されるインターフェースなど、冗長な出力を表示します。 -
-x— 数値の正確な値を出力します。負荷が大きいシステムでは、特定のチェーンか、あるいは規則が処理したパケット数とバイト数の終わりにKilobytes（キロ）、Megabytes（メガ）、Gigabytes（ギガ）を付けて表現を省略する場合があります。このオプションを指定すると、全数値が出力されます。 -
-n— IPアドレスとポート番号を、デフォルトのホスト名とネットワークサービスの形式ではなく数値形式で出力します。 -
--line-numbers— 各チェーンの規則の横にチェーン内の順序番号を出力します。このオプションは、特定の規則を削除する場合や規則を挿入する場所を探す場合に便利です。 -
-t <table-name>— テーブル名を指定します。それが ない場合、デフォルトではフィルターテーブルを使用します。
以下の例では、数種のオプションの使い方を説明しています。-x オプションを 含むことによるバイト表示の相違に注意して下さい。
[root@myserver ~]# iptables -L OUTPUT -v -n -x Chain OUTPUT (policy ACCEPT 64005 packets, 6445791 bytes) pkts bytes target prot opt in out source destination 1593 133812 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 [root@myserver ~]#iptables -L OUTPUT -v -n Chain OUTPUT (policy ACCEPT 64783 packets, 6492K bytes) pkts bytes target prot opt in out source destination 1819 153K ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 [root@myserver ~]#
iptables コマンドで作成した規則は、メモリに格納されます。設定した iptables の規則を保存する前にシステムを再起動すると、すべての規則は失われます。netfilter 規則が システムの再起動後に維持されるようにするには、それを保存する必要があります。その netfilter 規則を保存するには、root で次のコマンドを入力します:
/sbin/service iptables save
これが、iptables の initscript を実行し、 /sbin/iptables-save プログラムを実行して、現在の iptables の設定を /etc/sysconfig/iptables に書き込みます。既存の /etc/sysconfig/iptables ファイルは、/etc/sysconfig/iptables.save として保存されます。
次にシステムをブートすると、iptables init script は /sbin/iptables-restore コマンドを使うことで、/etc/sysconfig/iptables に保存されている規則を再び適用します。
/etc/sysconfig/iptables ファイルに保存する前に新しい iptablesの 規則をテストするのは良い考えですが、別のシステムにあるファイルから iptables の 規則をコピーすることもできます。この方法を使用すると、iptables の規則を複数のマシンに同時にすばやく配布することができます。
iptables 規則は、ディストリビューション用、バックアップ用、他の目的用に別々のファイルに 保存することができます。iptables 規則を保存するには、root として以下のコマンドを 入力します:
[root@myserver ~]# iptables-save >ここで<filename><filename>は規則セットの ユーザー定義名です。
重要
他のマシンに /etc/sysconfig/iptablesファイルを分配する場合は、/sbin/service iptables restart と入力して、新しい規則を有効にします。
注記
iptables 機能を構成するテーブルとチェーンの操作に使用されるiptablescommand(/sbin/iptables) に対する iptables サービス自身を有効/無効にするのに使用されるiptablesservice (/sbin/iptables service) の相違に注意して下さい。
Red Hat Enterprise Linux では、iptables を制御するための基本的な方法が 2つあります。
-
/sbin/service iptables— initscript を使用して<option>iptablesの各種機能を操作する為に使用されます。以下の オプションが使用できます:-
start— ファイアウォールが設定されていると(/etc/sysconfig/iptablesが存在すると言う意味)、 実行中のすべてのiptablesを完全に停止してから/sbin/iptables-restoreコマンドを使用して起動 します。このオプションは、ipchainsカーネルモジュールがロードされていない場合にのみ機能します。モジュールがロードされているかどうか チェックするには、以下のコマンドを root で入力します:[root@MyServer ~]# lsmod | grep ipchainsこのコマンドが出力を返さない場合は、モジュールがロードされていないと言う意味に なります。必要であれば、
/sbin/rmmodコマンドを使用して、モジュールを 削除します。 -
stop— ファイアウォールが実行中の場合、メモリ内のファイアウォールの規則がフラッシュされ、すべての iptable の モジュールとヘルパーがアンロードされます。/etc/sysconfig/iptables-config設定ファイル内のIPTABLES_SAVE_ON_STOPディレクティブがそのデフォルト値からyesに変更されると、現在の規則は/etc/sysconfig/iptablesに保存され、既存の規則はすべて/etc/sysconfig/iptables.saveファイルに移動されます。iptables-configファイルについての詳細は、 項25.8.5.1. 「IPTables 制御スクリプトの設定ファイル」 を参照してください。 -
restart— ファイアウォールを実行中の場合、メモリ内のファイアウォールの規則はフラッシュ され、 それが/etc/sysconfig/iptablesに設定されていれば、 ファイアウォールが再起動されます。このオプションはipchainsカーネルモジュールがロードされない場合にのみ機能します。/etc/sysconfig/iptables-config設定ファイル内のIPTABLES_SAVE_ON_RESTARTディレクティブがそのデフォルト値からyesに変更されると、現在の規則は/etc/sysconfig/iptablesに保存されて、既存の規則はすべて/etc/sysconfig/iptables.saveファイルに移動されます。iptables-configファイルについての詳細は、 項25.8.5.1. 「IPTables 制御スクリプトの設定ファイル」 を参照してください。 -
status— ファイヤーウォールと実行中の全規則 リストの状態を表示します。このオプションのデフォルト設定では、各規則内の IPアドレスを表示します。ドメインと ホスト名の情報を表示するには、
/etc/sysconfig/iptables-configファイルを編集して、IPTABLES_STATUS_NUMERICの値を、noに変更します。iptables-configファイルについての 詳細は、項25.8.5.1. 「IPTables 制御スクリプトの設定ファイル」 を参照してください。 -
panic— ファイアウォールの規則をすべてフラッシュします。設定されているすべてのテーブルのポリシーはDROPにセットされます。サーバーの侵害を受ける可能性が判っている場合に、このオプションが役に立ちます。 ネットワークから物理的に切断したり、システムを停止したりする代わりに、このオプションを 使用して、それ以降のネットワークトラフィックを全て停止しながら、分析や他の解明作業のために マシンを準備状態にしておくことができます。
-
save—iptables-saveを使用して、 ファイアウォールの規則を/etc/sysconfig/iptablesに保存します。詳細は、項25.8.4. 「IPTables 規則の保存」 を参照してください。
-
ヒント
同じ initscript コマンドを使用して IPv6 の netfilter を制御するには、 このセクションに記載されている /sbin/service コマンド内で iptables を ip6tablesに 置換します。 IPv6 及び netfilter についての詳細は、項25.8.6. 「IPTables と IPv6」 を参照してください。
iptables initscripts の動作は、 /etc/sysconfig/iptables-config 設定ファイルで制御されます。以下にこのファイル内に格納されているディレクティブの一覧を示します:
-
IPTABLES_MODULES— ファイアウォールが起動するときにロードする、追加のiptablesモジュールの スペースで区切られた一覧を指定します。これには接続トラッキングと NAT ヘルパーを 含むませることができます。 -
IPTABLES_MODULES_UNLOAD— 再起動と停止でモジュールをアンロードします。このディレクティブは以下の値を受け付けます:-
yes— デフォルトの値です。このオプションはファイアウォールの 再起動か停止の正しい状態を達成するのにセットします。 -
no— このオプションは netfilter モジュールのアンロードに 問題がある場合のみにセットするものです。
-
-
IPTABLES_SAVE_ON_STOP— ファイアウォールが停止されるときに、現在のファイアウォールの規則を/etc/sysconfig/iptablesに保存します。このディレクティブは以下の値を受け付けます:-
yes— ファイアウォールが停止されるときに、既存の規則を/etc/sysconfig/iptablesに保存して、 前のバージョンを/etc/sysconfig/iptables.saveに移動します。 -
no— デフォルトの値です。ファイアウォールが停止 されるときに既存の規則を保存しません。
-
-
IPTABLES_SAVE_ON_RESTART— ファイアウォールが再起動されるときに、現在のファイアウォール規則を保存します。 このディレクティブは次の値を受け付けます:-
yes— ファイアウォールが再起動されるときに、既存の規則を/etc/sysconfig/iptablesに保存して、 前のバージョンを/etc/sysconfig/iptables.saveに移動します。 -
no— デフォルトの値です。ファイアウォールが再起動 されるときに既存の規則を保存しません。
-
-
IPTABLES_SAVE_COUNTER— すべてのチェーン及び規則にある パケットとバイトの全カウンタを保存、復元します。このディレクティブは以下の値を受け付けます:-
yes— カウンタ値を保存します。 -
no— デフォルトの値です。カウンタの値を保存しません。
-
-
IPTABLES_STATUS_NUMERIC— ドメインやホスト名の代わりに、数値形式で IP アドレスを出力します。 このディレクティブは以下の値を受け付けます:-
yes— デフォルト値です。ステータス出力内で IP アドレスのみを 返します。 -
no— ステータス出力内でドメインかホスト名を返します。
-
iptables-ipv6 パッケージがインストールされている場合、 Red Hat Enterprise Linux に収納されている netfilter は次世代の IPv6 インターネットプロトコルをフィルター できます。IPv6 netfilter を操作するためのコマンドは ip6tables です。
このコマンド用の殆んどのディレクティブは、まだサポートされていない nat テーブル以外、iptables に使用されるディレクティブと同じです。 これは、マスカレードやポート転送などの IPv6 ネットワークアドレス変換タスクを実行するのは まだ可能ではないと言うことになります。
ip6tables 用の規則は /etc/sysconfig/ip6tables ファイルに格納されます。ip6tables initscripts で 保存された以前の規則は /etc/sysconfig/ip6tables.save ファイルに格納されます。
ip6tablesの initscript 用設定オプションは /etc/sysconfig/ip6tables-config に格納されていますが、 各ディレクティブ名はその iptables の相当名とは少々異なります。
例えば、iptables-config ディレクティブIPTABLES_MODULES:に対して、ip6tables-config ファイルでの相当物は IP6TABLES_MODULES です。
iptables を用いたパケットフィルタリングに関する追加情報は以下の情報を参照して下さい。
-
http://www.netfilter.org/ — netfilter/iptables プロジェクトのホームページです。Linux の IP ファイアウォールのメインテナー、Rusty Russell による各種の役立つガイドや、特定問題の対処方法に関する FAQ などを含む、
iptablesに関する多彩な情報が収納されています。このサイトの HOWTO ドキュメントでは、基本的なネットワークの概念、カーネルのパケットフィルタリング、NAT の設定などのテーマが掲載されています。 -
http://www.linuxnewbie.org/nhf/Security/IPtables_Basics.html — パケットが Linuxカーネルを通過する様子に関する入門的な説明に加え、基本的な
iptablesコマンドを構成する方法が含まれています。
SELinux(Security-Enhanced Linux) とは、 LSM (Linux Security Modules) を使用して 2.6.x カーネルにセキュリティアーキテクチャを統合したものです。これは、NSA (United States National Security Agency) と SELinux コミュニティのプロジェクトです。 Red Hat Enterprise Linux への SELinux の統合は NSA と Red Hat 共同活動です。
SELinux は Linux カーネルに埋めこまれている柔軟性のある MAC(Mandatory Access Control) システムを提供します。標準の Linux DAC(Discretionary Access Control) の元では、ユーザー(UID か SUID) として実行しているアプリケーションやプロセスは ファイル、ソケット、その他のプロセスなどのオブジェクトへユーザーの権限を持っています。MAC カーネルを実行するとシステムを損傷したり破壊する可能性のある悪意のある、又は問題のあるアプリケーションに対して システムを保護します。
SELinux はシステム上の各ユーザー、アプリケーション、プロセス、それにファイルのアクセス権と 移動権を定義付けます。SELinux は、それから、任意の Red Hat Enterprise Linux がどれ位厳格で、どれ位温和で あるべきかを指定するセキュリティポリシーを使用して、これらのエンティティの交流を 監督します。
毎日の作業では、システムユーザーは大体 SELinux を意識しないでしょう。システム管理者のみが そのサーバー環境に実装するポリシーの厳格さを配慮する必要があります。そのポリシーは必要に 応じて、厳格であるか温和であることが可能で、非常にきめ細かく分れています。この詳細がシステム 全体に渡って SELinux カーネルに完全で繊細な制御を与えます。
SELinux の判断決定プロセス
サブジェクト(例えば、アプリケーション)が、オブジェクト(例えば、ファイル)にアクセスを 試みた時に、カーネル内のポリシー強制サーバーは AVC (access vector cache) をチェックします。ここでサブジェクトとオブジェクトの権限がキャッシュされます。 AVC 内のデータに基づいて決定ができない場合、要求はセキュリティサーバーまで 継続され、ここでアプリケーションのセキュリティコンテキストとマトリックス内の ファイルが調べられます。権限はそれから、許可、又は否定され、否定された場合は、 /var/log/messages 内に詳細説明として、 avc: denied メッセージで示されます。サブジェクトとオブジェクトの セキュリティコンテキストはインストール済みのポリシーから適用されますが、このポリシーがセキュリティサーバーの マトリックスを充填する為の情報を提供します。
以下のダイアグラムを参照:
SELinux 操作モード
強制 (enforcing) モードで実行する代わりに、SELinux は 容認 (permissive) モードで実行することができ、その中では AVC はチェックされ、否定はログされますが、SELinux はポリシーを強制 しません。これは、トラブルシューティングと SELinux の開発や微調整に役に立ちます。
SELinux の作動に関する詳細情報は 項26.1.3. 「その他の資料」 を参照して下さい。
以下のセクションでは、SELinux の設定ファイルとその関連ファイルシステムを説明 しています。
/selinux/ 擬似ファイル(pseudo-file) システムには、カーネル サブシステムで一般に良く使用されるコマンドが含まれています。このタイプのファイルシステムは /proc/ 擬似ファイルシステムに似ています。
管理者とユーザーは通常、このコンポーネントを操作する必要はありません。
以下の例では、/selinux/ ディレクトリのサンプル内容を 示しています:
-rw-rw-rw- 1 root root 0 Sep 22 13:14 access dr-xr-xr-x 1 root root 0 Sep 22 13:14 booleans --w------- 1 root root 0 Sep 22 13:14 commit_pending_bools -rw-rw-rw- 1 root root 0 Sep 22 13:14 context -rw-rw-rw- 1 root root 0 Sep 22 13:14 create --w------- 1 root root 0 Sep 22 13:14 disable -rw-r--r-- 1 root root 0 Sep 22 13:14 enforce -rw------- 1 root root 0 Sep 22 13:14 load -r--r--r-- 1 root root 0 Sep 22 13:14 mls -r--r--r-- 1 root root 0 Sep 22 13:14 policyvers -rw-rw-rw- 1 root root 0 Sep 22 13:14 relabel -rw-rw-rw- 1 root root 0 Sep 22 13:14 user
例えば、enforce ファイルで cat コマンドを 実行すると、強制モードの 1 かあるいは、容認モードの 0 を 表示します。
次のセクションでは SELinux の設定法、ポリシーファイル、/etc/ ディレクトリ内に 置かれている関連ファイルシステムを説明しています。
There are two ways to configure SELinux under Red Hat Enterprise Linux: using the SELinux Administration Tool (system-config-selinux), or manually editing the configuration file (/etc/sysconfig/selinux).
/etc/sysconfig/selinux ファイルは SELinux を有効/無効にする為の、 そしてシステムでどのポリシーを強制するか、及びどのように強制するかを設定する 主要設定ファイルです。
注記
/etc/sysconfig/selinux には、実際の設定ファイル、 /etc/selinux/config へのシンボリックリンクが含まれています。
以下に設定において利用できるオプションのサブセットを説明しています:
-
SELINUX=— システム上の SELinux の最上レベルの状態を定義します。enforcing|permissive|disabled-
enforcing— SELinux セキュリティポリシーは強制されます。 -
permissive— SELinux システムは警告を表示しますが、 ポリシーは強制しません。これは、デバグやトラブルシューティング目的で便利です。容認(permissive)モードでは、 サブジェクトが、強制(enforcing)モードでは否定されるようなアクションを継続することが できる為、より多くの否定をログすることになります。例えば、容認モードでディレクトリツリーを 移動することは、全てのディレクトリレベルの読み込みで
avc: deniedのメッセージを発生させます。強制モードでは、SELinux は最初の移動で 停止して、それ移行の否定メッセージの発生を止めることになります。 -
disabled— SELinux は完全に無効になります。SELinux hooks は カーネルから離脱して、擬似ファイルシステムは登録が消えます。ヒント
SELinux が無効の時に作成されたアクションは、正しいセキュリティコンテキストを持たない ファイルシステムの原因となります。これはポリシーによって定義されたセキュリティコンテキスト のことです。ファイルシステムのラベル変えの最善の方法はフラグファイル:
/.autorelabelを作成して、マシンを再起動することです。これにより、プロセスがシステム上で実行される前に ラベル変えがブートプロセスの非常に早期に起こることになります。この手順を使用すると、プロセスは 誤って間違えたコンテキストのファイルを作成することもなく、間違ったコンテキストで開始することも なくなることになります。SELinux を有効にする前に
fixfiles relabelコマンドを使用して、 ファイルシステムをラベル変えすることができます。しかしこれが完了した後にでも、 システム上で間違えたコンテキストでプロセスが実行されている可能性がある為、この方法は 推奨できません。これらのプロセスは、間違えたコンテキストのままのファイルを作成する 可能性があります。
注記
設定行の最後の追加の空白、又は、ファイルの最後の余分な行としての空白は予期できない動作の 原因になる可能性があります。予防の為に不用な空白を削除して下さい。
-
-
SELINUXTYPE=— SELinux が強制するポリシーを指定します。targeted|strict-
targeted— ターゲットのネットワークデーモンのみが 保護されます。重要
以下のデーモンはデフォルトのターゲットポリシー:
dhcpd, httpd (apache.te)、 named、 nscd、 ntpd、 portmap、 snmpd、 squid、syslogdで 保護されています。システムのその他の機能は unconfined_t ドメインで 実行されます。このドメインはセキュリティコンテキストを持ったサブジェクトとオブジェクトが 標準の Linux セキュリティを使用して運用できるようにします。これらのデーモン用のポリシーファイルは
/etc/selinux/targeted/src/policy/domains/programに収納されています。これらの ファイルは Red Hat Enterprise Linux の新しいバージョンがリリースされると変更される可能性があります。Policy enforcement for these daemons can be turned on or off, using Boolean values controlled by the SELinux Administration Tool (
system-config-selinux).目標のデーモン用にブーリアン値を
0(ゼロ)にするとそのデーモンの ポリシー移動を無効にします。例えば、dhcpd_disable_transを0にして、initが unconfined_t ドメインからdhcpd.teに指定してあるドメインにdhcpdを 移動することを防止することができます。getsebool -aコマンドを使用すると、全ての SELinux ブーリアン値を 一覧表示します。以下に SELinux ブーリアン値を設定する為のsetseboolコマンドを使用した例を表示します。-Pオプションを使用すると、変更が 固定されます。このオプションが無いと、ブーリアン値は再起動時に1に リセットされます。setsebool -P dhcpd_disable_trans=0
-
strict— 全てのデーモン用の完全 SELinux 保護。 セキュリティコンテキストは全てのサブジェクトとオブジェクト用に定義され、 そして各アクションはポリシー強制サーバーによってプロセスされます。
-
-
SETLOCALDEFS=— ローカルの 定義(ユーザーとブーリアン)が設定される方法を制御します。この値を 「1」にセットすると、 これらの定義は0|1/etc/selinux/内のファイルの<policyname>load_policyで制御され、「0」にセットすると、 それらはsemanageで制御されるようになります。注意
変更がどのようなインパクトを与えるか完全に理解していない限りは、このデフォルト値 (0) を 変更すべきではありません。
/etc/selinux/ ディレクトリは、全てのポリシーファイルの本来の配置場所である と共に、又主要設定ファイルの場所でもあります。
以下に /etc/selinux/ ディレクトリの内容のサンプルをしめします:
-rw-r--r-- 1 root root 448 Sep 22 17:34 config drwxr-xr-x 5 root root 4096 Sep 22 17:27 strict drwxr-xr-x 5 root root 4096 Sep 22 17:28 targeted
二つのサブディレクトリ、strict/ と targeted/ は、同じ名前のポリシーファイルが含まれている特定のディレクトリです。 (strict と targeted)
以下に SELinux 一般的に使用されるユーティリティの一部を示します:
-
/usr/sbin/setenforce— SELinux が稼動するリアルタイムでモードを 変更します。例えば:
setenforce 1— SELinux は強制モードで実行されます。setenforce 0— SELinux は容認モードで実行されます。実際に SELinux を無効にするには、
/etc/sysconfig/selinux内で適切なsetenforceパラメータを指定するか、 あるいは、/etc/grub.conf内でか、起動時にカーネルに パラメータselinux=0を渡します。 -
/usr/sbin/sestatus -v— SELinux を実行しているシステムの詳細状態を 表示します。以下の例では、sestatus -v出力の一部を示しています:SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: enforcing Policy version: 21 Policy from config file: targeted Process contexts: Current context: user_u:system_r:unconfined_t:s0 Init context: system_u:system_r:init_t:s0 /sbin/mingetty system_u:system_r:getty_t:s0
-
/usr/bin/newrole— 新しいシェルを新しいコンテキスト、又は役割で 実行します。ポリシーが新しい役割への移行を許可する必要があります。注記
このコマンドは、厳格で、MLS のポリシーに必要となる
policycoreutils-newroleパッケージがインストールしてある場合にのみ、利用できます。 -
/sbin/restorecon— 適切なファイル、又はセキュリティコンテキストで 拡張属性を作ることにより、１つ、又は複数のファイルのセキュリティコンテキストを設定します。 -
/sbin/fixfiles— ファイルシステムにあるセキュリティコンテキストの データベースをチェック、又は修正します。
これらのユーティリティに関連した詳細情報は、man ページを参照してください。
全ての利用可能なバイナリユーティリティについての詳細情報は setools か policycoreutils パッケージの内容を参照して下さい。パッケージの内容を表示するには、次のコマンドを使用します:
rpm -ql
<package-name>
SELinux に関する詳細情報については、以下の資料を参照して下さい。
-
/usr/share/doc/setools-<version-number>/setoolsパッケージに含まれている ユーティリティ用の全てのドキュメントがあります。これには全てのヘルパースクリプト、サンプル 設定ファイル、ドキュメントが含まれます。
-
http://www.nsa.gov/selinux/ NSA SELinux 開発チームのホームページです。多くの資料が HTML と PDF 形式で 利用できます。これらのリンクの多くは SELinux 専用ではないのですが一部の概念が 適用できるはずです。
-
http://fedora.redhat.com/docs/ Fedora ドキュメントプロジェクトのホームページです。リリース間隔がより短い為、 ここにはより新しい Fedora Core 独自の資料が含まれています。
-
http://selinux.sourceforge.net SELinux コミュニティのホームページです。
SELinux は本来、ナショナルセキュリティエージェンシー(NSA )[12] と他の組織からの開発プロジェクトでした。これは、Flask オペレーティング システムセキュリティアーキテクチャ[13] の実装です。NSA は Linux セキュリティモジュール (LSM ) フレームワークを使用して、 SELinux を Linux カーネルに統合しました。Linus Torvalds は 単に SELinux をカーネルに承認するだけでなく、セキュリティへのモジュラーアプローチを望んで、彼の提言から、SELinux が LSM 作成の原動力となりました。
元来、 SELinux 実装は、 ext2 アイノード内の未使用フィールドに保存されている 持続セキュリティ ID (persistent security ID) (PSID) を使用していました。これらの (人間可読でない) 数値表示は、 SELinux によってセキュリティコンテキストラベルにマップされます。残念ながら、これは、 PSID をサポートする為に各ファイルシステムタイプの修正を必要とし、その理由でスケーラブルでなく、 Linux カーネルのアップストリームでサポートされるものではありません。
SELinux の次の展開は、Linux カーネルの 2.4.<x> シリーズ用のロード可能カーネルとしてでした。このモジュールは PSID を 普通のファイルに保存するため、SELinux はより多くのファイルシステムをサポートすることが できました。このソリューションは、パフォーマンスには、最良ではなく、プラットフォーム全体では、 不安定でした。最後に、SELinux コードは 2.6.x カーネルのアップストリームに統合されて、これが ext3 ファイルシステムで、LSM への完全サポートを 持ち、拡張属性(extended attributes)
(xattrs
)を持つようになりました。SELinux は xattrs を使用してセキュリティコンテキスト情報を保存するようになりました。 xattrs ネームスペースは、同じシステム上に存在する複数セキュリティ モジュール用に便利な分離機能を提供します。
アップストリーム用にカーネルの準備とその後の SELinux 開発の為に多くの労力が、NSA と Red Hat と SELinux 開発者のコミュニティの間で費やされました。
SELinux の歴史に関する詳細の決定的ウェブサイトは、http://www.nsa.gov/selinux/ です。
[12] NSA は米国の 連邦政府の暗号化エージェンシーであり、情報保護とシグナルインテリジェンスの責任を 持っています。NSA に関する情報は以下のサイトで閲覧できます。http://www.nsa.gov/about/
[13] Flask は、分散型信頼オペレーティングシステム(Distributed Trusted Operating System) (DTOS )を Fluke リサーチオペレーティングシステムに 統合したプロジェクトから成長したものです。Flask とは、そのアーキテクチャの名前であり、 Fluke オペレーティングシステムの活用です。
以下の参考文献は、 SELinux 及び Red Hat Enterprise Linux に関連する詳細方法へのポインタとなりますが、本ガイドの範疇を超えています。 SELinux の急速な進歩により、資料のなかには Red Hat Enterprise Linux の特定のリリースにしか対応しない場合がありますので注意してください。
書籍
- SELinux by Example
-
Mayer、 MacMillan、及び Caplan
Prentice Hall, 2007
チュートリアルとヘルプ
- Understanding and Customizing the Apache HTTP SELinux Policy (Apache HTTP SELinux ポリシーとそのカスタマイズ方法について)
- Russell Coker のチュートリアルとトーク
- SELinux ポリシー HOWTO 全般
-
https://sourceforge.net/docman/display_doc.php?docid=21959[amp ]group_id=21266
- Red Hat ナレッジベース
全般情報
- NSA SELinux のメインウェブサイト
- NSA SELinux FAQ
- Fedora SELinux FAQ
- SELinux NSA's Open Source Security Enhanced Linux
テクノロジー
- An Overview of Object Classes and Permissions
- Integrating Flexible Support for Security Policies into the Linux Operating System (Linux での Flask 実装の履歴)
- Implementing SELinux as a Linux Security Module
- A Security Policy Configuration for the Security-Enhanced Linux
コミュニティ
- SELinux コミュニティページ
- IRC
-
irc.freenode.net, #rhel-selinux
履歴
- Quick history of Flask
- Full background on Fluke