Show Table of Contents
第2章 ネットワークのセキュリティ保護
2.1. ワークステーションのセキュリティ
Linux 環境の安全を確保する作業はワークステーションから始めます。個人用のマシンをロックダウンするにしてもエンタープライズシステムのセキュリティ保護をするにしても、信頼できるセキュリティポリシーは個別のコンピューターが第一歩となります。コンピューターネットワークのセキュリティは、一番弱いノードのレベルで決められてしまいます。
2.1.1. ワークステーションのセキュリティ評価
Red Hat Enterprise Linux ワークステーションのセキュリティを評価する際は、以下の点を考慮してください。
- BIOS およびブートローダーのセキュリティ — 未承認ユーザーがマシンに物理的にアクセス可能で、パスワードなしでシングルユーザーモードまたはレスキューモードによる起動が可能ですか？
- パスワードのセキュリティ — マシンのユーザーアカウントのパスワードはどの程度安全ですか？
- 管理者コントロール — システムにアカウントを持っているのは誰で、どの程度の管理者コントロールがありますか？
- 利用可能なネットワークサービス — ネットワークからの要求をリッスンしているのはどのサービスで、それらは稼働しているべきですか？
- パーソナルファイアウォール — もし使うのであれば、どのタイプのファイアウォールが必要ですか？
- セキュリティ強化の通信ツール — ワークステーション間の通信で使用すべきツールはどれで、使用すべきでないツールはどれですか？
2.1.2. BIOS およびブートローダーのセキュリティ
BIOS (もしくは BIOS に相当するもの) およびブートローダーのパスワード保護により、システムに物理的にアクセス可能な未承認ユーザーがリムーバブルメディアを使って起動したり、シングルユーザーモードで root 権限を取得したりすることを防ぐことができます。このような攻撃に対するセキュリティ対策は、ワークステーション上の情報の機密性とマシンの場所によって異なります。
例えば、マシンが見本市で使われていて機密情報を含んでいない場合、このような攻撃を防ぐことは重要ではないかもしれません。しかし、同じ見本市で企業ネットワーク用のプライベートで暗号化されていない SSH 鍵のあるノートパソコンが誰も監視せずに置かれていた場合、重大なセキュリティ侵害につながり、その影響は企業全体に及ぶ可能性があります。
ただし、ワークステーションが権限のあるユーザーもしくは信頼できるユーザーのみがアクセスできる場所に置かれてるのであれば、BIOS もしくはブートローダーの安全確保は必要ない可能性もあります。
2.1.2.1. BIOS パスワード
コンピューターの BIOS をパスワードで保護する主な理由は、以下の 2 つです[3]。
- BIOS 設定の変更を防止する — 侵入者が BIOS にアクセスした場合、CD-ROM やフラッシュドライブから起動するように設定できます。このようにすると、侵入者がレスキューモードやシングルユーザーモードに入ることが可能になり、システム上で任意のプロセスを開始したり、機密性の高いデータをコピーできるようになってしまいます。
- システムの起動を防ぐ — BIOS の中には起動プロセスをパスワードで保護できるものもあります。これを有効にすると、攻撃者は BIOS がブートローダーを開始する前にパスワード入力を求められます。
BIOS パスワードの設定方法はコンピューターメーカーで異なるため、具体的な方法についてはコンピューターのマニュアルを参照してください。
BIOS パスワードを忘れた場合は、マザーボード上のジャンパーでリセットするか、CMOS バッテリーを外します。このため、可能な場合はコンピューターのケースをロックすることがよい方法です。ただし、CMOS バッテリーを外す前にコンピューターもしくはマザーボードのマニュアルを参照してください。
2.1.2.1.1. x86 以外のプラットフォームのセキュリティ
他のアーキテクチャーでは、x86 システム上の BIOS とほぼ同等の低レベルのタスクを実行するために異なるプログラムを使用します。例えば、Intel® Itanium™ コンピューターは Extensible Firmware Interface (EFI) シェルを使用します。
他のアーキテクチャー上で BIOS と同様のプログラムをパスワード保護する方法については、メーカーの指示を参照してください。
2.1.2.2. ブートローダーのパスワード
Linux ブートローダーをパスワードで保護する主要な理由は以下のとおりです。
- シングルユーザーモードへのアクセスを防ぐ — 攻撃者がシステムを起動してシングルユーザーモードに入れるとすると、root パスワードの入力なしで自動的に root としてログインすることになってしまいます。
警告
/etc/sysconfig/initファイルでSINGLEパラメーターを編集してシングルユーザーモードへのアクセスを保護する方法は推奨されません。攻撃者は、GRUB のカーネルコマンドライン上で (init=を使って) カスタム初期コマンドを特定することでパスワードを迂回できます。「GRUB のパスワード保護」 にあるように、GRUB ブートローダーをパスワードで保護することが推奨されます。 - GRUB コンソールへのアクセスを防ぐ — マシンがブートローダーに GRUB を使用している場合、攻撃者は GRUB エディターインターフェイスを使って設定を変更したり、
catコマンドを使用して情報収集が可能になります。 - 安全でないオペレーティングシステムへのアクセスを防ぐ — デュアルブートシステムの場合、攻撃者はアクセス制御やファイルパーミッションを無視する (例えば、DOS などの) OS を起動時に選択できます。
Red Hat Enterprise Linux 6 は、出荷時に x86 プラットフォーム上で GRUB ブートローダーが組み込まれています。GRUB の詳細については、『Red Hat Enterprise Linux インストールガイド』 を参照してください。
2.1.2.2.1. GRUB のパスワード保護
「ブートローダーのパスワード」 にある初めの 2 つの問題は、GRUB の設定ファイルに パスワード指示文を追加することで対処できます。これを行うには、まず強固なパスワードを選択し、シェルを開いて root でログインした後、以下のコマンドを実行します。
/sbin/grub-md5-crypt
パスワードの入力を求められたら、GRUB パスワードを入力して Enter を押します。すると、パスワードの MD5 ハッシュが返されます。
次に GRUB 設定ファイル
/boot/grub/grub.conf を編集します。これを開いて、ドキュメンテーションの主要セクションにある timeout 行の下に以下の行を追加します。
password --md5 <password-hash>
<password-hash> の部分を
/sbin/grub-md5-crypt が返した値に置き換えます [4]。
次回のシステム起動時には、p を押して GRUB パスワードを押さないとエディターやコマンドインターフェイスにアクセスできないように、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>
2.1.2.2.2. インタラクティブスタートアップの無効化
起動順序の最初に I キーを押すと、インタラクティブな方法でシステムを起動できます。この方法では、システムがユーザーにサービスを 1 つずつ開始するように求めます。しかし、システムに物理的なアクセスがある攻撃者の場合は、この方法だとセキュリティ関連のサービスを無効にし、システムへのアクセスを許すことになってしまいます。
このようなインタラクティブなスタートアップを防止するには、root で
/etc/sysconfig/init ファイルの PROMPT パラメーターを以下のように無効にします。
PROMPT=no
2.1.3. パスワードのセキュリティ
パスワードは、Red Hat Enterprise Linux がユーザーの ID を確認する第一の手段です。ユーザーやワークステーション、ネットワークの保護にパスワードのセキュリティが重要であるのは、このためです。
セキュリティ目的で、インストールプログラムはシステムが セキュアハッシュアルゴリズム 512 (SHA512) とシャドウパスワードを使うように設定します。この設定を変更しないことが強く推奨されます。
インストール中にシャドウパスワードが検出されると、すべてのパスワードは全ユーザーが読み取り可能な
/etc/passwd ファイルに一方向のハッシュとして保存されます。この場合、システムはオフラインのパスワードクラッキング攻撃に脆弱なものとなってしまいます。侵入者が通常のユーザーとしてマシンにアクセスすると、/etc/passwd ファイルを侵入者自身のマシンにコピーして、パスワードクラッキングプログラムをいくつでも実行できるようになります。このファイルに安全でないパスワードがあれば、パスワードクラッカーがこれを見つけるのは時間の問題となります。
シャドウパスワードは、パスワードハッシュを
/etc/shadow ファイルに保存することで、このタイプの攻撃を排除します。このファイルは、root ユーザーのみが読み取り可能なためです。
この場合、攻撃者は SSH や FTP などのマシン上のネットワークサービスにログインしてリモートからパスワードクラッキングを試みることが強いられます。このようなブルートフォース攻撃は時間がかかり、何百回ものログイン失敗がシステムファイルに書き込まれるので、明らかな痕跡が残ります。もちろん、クラッカーが脆弱なパスワードがあるシステムに真夜中から攻撃を開始した場合、夜明け前にはアクセスに成功し、痕跡を隠すためにログファイルを編集してしまう、という可能性もあります。
フォーマットやストレージに加えて考慮すべき点は、コンテンツの問題です。パスワードクラッキングからアカウントを保護するためにユーザーがなし得る最重要事項は、強固なパスワードを作成することです。
2.1.3.1. 強固なパスワードの作成
安全なパスワードを作成するには、長いパスワードの方が短くかつ複雑なものよりも強固であることをユーザーは認識する必要があります。あるパスワードが数字や特殊文字、大文字のアルファベットを含んでいても、それが 8 文字の長さしかなければ、強固なパスワードとは言えません。「John The Ripper」のようなパスワード解析ツールは、人間が記憶するには困難なパスワードを分解するために最適なものです。
情報の理論上では、エントロピーはランダムな変数に関連付けられる不確実性のレベルで、ビット表示されます。エントロピーの値が高ければ高いほど、パスワードはより安全と言えます。NIST (米標準技術研究所) の SP 800-63-1 文書によると、一般的に選択される 5 万件のパスワードからなる辞書にないパスワードには、少なくとも 10 ビットのエントロピーがあります。このため、ランダムな 4 単語からなるパスワードには、およそ 40 ビットのエントロピーがあることになります。安全性を高めるために複数の単語で構成される長いパスワードは、パスフレーズ とも呼ばれます。例を示します。
randomword1 randomword2 randomword3 randomword4
大文字や数字、特殊文字の使用が強制されるシステムでは、上記の推奨事項に合致するパスフレーズは簡単に修正することができます。たとえば、最初の文字を大文字にして、"
1!" を追加します。このような修正は、パスフレーズの安全性を大幅に高めるもの ではない ことに注意してください。
安全なパスワードの作成にはいくつものアプローチがありますが、以下の悪い点は必ず避けてください。
- 辞書の 1 単語を使用する。外国語の 1 単語を使用する。反転した単語を使用する。数字のみを使用する。
- パスワードまたはパスフレーズを 10 文字未満にする。
- キーボードのレイアウトにおけるキーの配列を使用する。
- パスフレーズを書き留める。
- 誕生日や記念日、家族の名前、ペットの名前などの個人情報をパスフレーズに使用する。
- 複数のマシンで同じパスワードまたはパスフレーズを使用する。
セキュアなパスワードの作成は不可欠ですが、パスワードの適切な管理も特に大きな組織のシステム管理者にとっては重要です。次のセクションでは、組織内でのユーザーパスワードの作成および管理で推奨される方法を説明します。
2.1.4. 組織内でのユーザーパスワード作成
組織内に多くのユーザーがいる場合、システム管理者は 2 つの基本的な方法で強固なパスワードの使用を強制できます。つまり、管理者がパスワードを作成してユーザーに渡すか、パスワードが受容可能なレベルにあるかどうかを検証しながらユーザー自身がパスワードを作成する方法です。
前者の方法だとパスワードは強固なものになりますが、組織が拡大するにつれてタスクが重荷になります。また、ユーザーが自分のパスワードを書き留めるリスクも高まります。
これらの理由で、多くのシステム管理者は後者を選択します。ただし、パスワードが強固かどうかを積極的に検証し、場合によってはパスワードエージングで定期的にユーザーが強制的にパスワードを変更するようにします。
2.1.4.1. 強固なパスワードの強制
ネットワークを侵入から守るには、組織内で使われているパスワードが強固なものであることをシステム管理者が確認することが推奨されます。ユーザーはパスワードを作成・変更する際に、コマンドラインアプリケーション
passwd を使用できます。これは、Pluggable Authentication Modules (PAM) 対応なので、パスワードが短すぎないかまたは簡単にクラックされないかをチェックします。このチェックは、pam_cracklib.so PAM モジュールを使って実行されます。Red Hat Enterprise Linux では、pam_cracklib PAM モジュールを使って、パスワードの強度を規則セットに対してチェックすることができます。これは、他の PAM モジュールとともに /etc/pam.d/passwd ファイルの password コンポーネント内にスタックして、ユーザーログイン用のカスタムルールセットを設定することができます。pam_cracklib には、以下の 2 つのルーチンがあります。ひとつは、示されたパスワードが辞書内にあるかどうかをチェックすること。辞書にない場合は、さらなるチェックを行うことです。チェック項目の完全一覧については、pam_cracklib(8) の man ページを参照してください。
例2.1 pam_cracklib を使ったパスワード強度チェックの設定
パスワードを 8 文字以上にして、4 種類すべての文字を含めることを要件とするには、
/etc/pam.d/passwd ファイルの password セクションに以下の行を追加します。
password required pam_cracklib.so retry=3 minlen=8 minclass=4
パスワード強度チェックで連続文字または反復文字のチェックを行うには、
/etc/pam.d/passwd ファイルの password セクションに以下の行を追加します。
password required pam_cracklib.so retry=3 maxsequence=3 maxrepeat=3
この例では、「abcd」や「1234」など、4 つ以上連続する文字をパスワードに含めることはできません。また、同じ文字は、3 つまでしか繰り返すことはできません。
注記
root ユーザーに対してはこれらのチェックは実行されないので、警告メッセージが出ても root ユーザーは通常ユーザー用にどんなパスワードでも設定することができます。
PAM はカスタマイズ可能なので、
pam_passwdqc (http://www.openwall.com/passwdqc/ から入手可能) などのパスワード健全性チェッカーをさらに追加したり、新たなモジュールを書き込んだりすることができます。入手可能な PAM モジュールのリストについては、http://uw714doc.sco.com/en/SEC_pam/pam-6.html を参照してください。PAM の詳細情報については、『Managing Single Sign-On and Smart Cards』 ガイドを参照してください。
パスワード作成時に行われるパスワードチェックは、脆弱なパスワードの発見において、パスワードクラッキングプログラムが実行するチェックほど効果的ではありません。
Red Hat Enterprise Linux 下で実行可能な多くのパスワードクラッキングプログラムがありますが、これらはオペレーティングシステムに同梱されていません。以下に一般的なパスワードクラッキングプログラムの例を挙げます。
- John The Ripper — 高速かつ柔軟性のあるパスワードクラッキングプログラムです。複数の単語リストが使用可能で、ブルートフォースパスワードクラッキングも実行できます。オンラインで http://www.openwall.com/john/ から入手できます。
- Crack — おそらく最も知名度の高いパスワードクラッキングソフトウェアです。Crack は非常に高速ですが、扱いは John The Ripper ほど簡単ではありません。
- Slurpie — Slurpie は John The Ripper および Crack と類似したものですが、複数のコンピューター上で同時に実行するように設計されており、分散パスワードクラッキング攻撃を生成します。他の多くの分散攻撃セキュリティ評価ツールとともに、オンラインで http://www.ussrback.com/distributed.htm で入手可能です。
警告
組織内でパスワードのクラッキングを試みる場合は常に、最初に書面で許可を得てください。
2.1.4.2. パスフレーズ
パスフレーズとパスワードは、現在のほとんどのシステムおけるセキュリティの土台となっています。残念ながら、生体認証や 2 要素認証はまだ多くのシステムで主流になっていません。システムの安全確保にパスワードを使用するのであれば、パスフレーズの使用を検討することが推奨されます。パスフレーズはパスワードよりも長く、数字や記号などの非標準文字で実行してもパスワードよりもすぐれた保護を提供します。
2.1.4.3. パスワードエージング
パスワードエージングは、システム管理者が組織内での脆弱なパスワードに対する防御として用いるもうひとつのテクニックです。パスワードエージングとは、一定期間後 (通常 90 日) にユーザーが新たなパスワードを作成するように求められるシステムのことです。理論上は、ユーザーに定期的なパスワード変更を強制すれば、クラックされたパスワードは侵入者にとって一定期間しか有効でないことになります。しかし、パスワードエージングのマイナス面は、ユーザーがパスワードを書き留める可能性が高くなるという点です。
Red Hat Enterprise Linux では、パスワードエージングを指定する主要プログラムは次の 2 つになります。
chage コマンド、もしくはグラフィカルな User Manager (system-config-users) アプリケーションです。
重要
chage コマンドを使用するには、シャドウパスワードが有効となっている必要があります。詳細は 『Red Hat Enterprise Linux 6 導入ガイド』 を参照してください。
chage コマンドの -M オプションでは、パスワードが有効となる最長日数を指定します。例えば、ユーザーのパスワードが 90 日間で期限切れとなるように設定するには、以下のコマンドを実行します。
chage-M 90<username>
上記のコマンドでは、<username> をユーザー名で置き換えます。パスワードの期限切れを無効にするには、通常
-M オプションの後に 99999 の値を使います (これは 273 年余りに相当します)。
chage コマンドで使用可能なオプションの詳細情報については、以下の表を参照してください。
表2.1 chage のコマンドラインオプション
| オプション | 説明 |
|---|---|
-d days | 1970 年 1 月 1 日から最後にパスワードを変更した日までの日数を指定します。 |
-E date | アカウントがロックされる日付を YYYY-MM-DD の形式で指定します。日付の代わりに、 1970 年 1 月 1 日からの日数を指定することも可能です。 |
-I days | パスワードが失効してからアカウントがロックされるまでのアクティブでない日数を指定します。値を 0 とすると、パスワード失効後にアカウントはロックされません。 |
-l | 現在のアカウントエージングの設定を一覧表示します。 |
-m days | パスワード変更が必要となる間隔の最短日数を指定します。値を 0 とすると、パスワードは失効しません。 |
-M days | パスワードの有効最長日数を指定します。このオプションで指定した日数と -d オプションで指定した日数の合計が、1970 年 1 月 1 日から数えた現在までの日数より少ない場合は、ユーザーはアカウントを使用する前にパスワードを変更する必要があります。 |
-W days | パスワードが失効する前にユーザーに警告を発する日数を指定します。 |
インタラクティブモードで
chage を使用して、複数のパスワードエージングおよびアカウントの詳細を修正することもできます。以下のコマンドでインタラクティブモードに入ります。
chage <username>
以下は、このコマンドを使用したインタラクティブセッションの例です。
~]#chage juanChanging the aging information for juan Enter the new value, or press ENTER for the default Minimum Password Age [0]:10Maximum Password Age [99999]:90Last Password Change (YYYY-MM-DD) [2006-08-18]: Password Expiration Warning [7]: Password Inactive [-1]: Account Expiration Date (YYYY-MM-DD) [1969-12-31]:
ユーザーの初回ログイン時にパスワードが失効するように設定できます。これにより、ユーザーはパスワードを直ちに変更するよう強制されます。
- 初期パスワードを設定します。この手順には 2 つの一般的なアプローチがあります。デフォルトのパスワードを割り当てる、もしくは null パスワードを使用します。デフォルトのパスワードを割り当てるには、
rootとしてシェルプロンプトで以下を入力します。passwdusername代わりに null パスワードを割り当てるには、次のコマンドを使用します。passwd-dusername警告
null パスワードの使用は便利ですが、安全性は極めて低くなります。これは、いかなる第三者でも、セキュアでないユーザー名を使用して最初にシステムにログインし、アクセスできるためです。null パスワードでアカウントのロック解除を行う前に、ユーザーがログインできる状態にあることを常に確かめてください。 - パスワードを直ちに強制的に失効させるには、
rootとして以下のコマンドを実行します。chage-d0usernameこのコマンドは、パスワードが最後に変更された日付の値を 1970 年 1 月 1 日に設定します。パスワードエージングのポリシーが設定されていても、この値はパスワードを直ちに強制的に期限切れにします。
これで、ユーザーは初回ログイン時に新規パスワードを入力するよう要求されます。
グラフィカルの ユーザー管理 アプリケーションを使って、以下のようにパスワードエージングポリシーを作成することもできます。注: この手順を行うには、管理者権限が必要です。
- パネル上の メニューをクリックして から をクリックして ユーザー管理 を表示させます。別の方法では、シェルプロンプトで
system-config-usersのコマンドを入力します。 - ユーザー タブをクリックして、ユーザーリストの中から必要なユーザーを選択します。
- ツールバーの をクリックして、ユーザー設定のダイアログボックスを表示させます (または メニューで を選択します) 。
- パスワード情報 タブをクリックして、パスワード失効を有効にする のチェックボックスにチェックマークを付けます。
- 変更が要求されるまでの日数 フィールドに必要な値を入力し、 をクリックします。
図2.1 パスワードエージングオプションの指定
screenshot needs to be updated
2.1.5. 動きのないアカウントをロックする
pam_lastlog PAM モジュールを使うと、しばらくログインしていないユーザーをロックアウトしたり、最後のログイン試行についての情報を表示できます。このモジュールは root アカウントはチェックしないので、root アカウントがロックアウトされることはありません。
lastlog コマンドは、ユーザーの最後のログインを表示します。一方、last コマンドは、すべての現行および以前のログインセッションを表示します。これらのコマンドはそれぞれ、/var/log/lastlog と /var/log/wtmp ファイルからデータを読み込みます。データは、バイナリ形式で保存されています。
- ユーザーが最後にログインした前に試行されたログイン失敗数を表示するには、root で以下の行を
/etc/pam.d/loginファイルのsessionセクションに追加します。session optional pam_lastlog.so silent noupdate showfailed
アクティビティーがないことによるアカウントのロックは、コンソールもしくは GUI、またはこれら両方に適用するよう設定することができます。
- アクティビティーが 10 日間なかった場合にアカウントをロックするには、root で以下の行を
/etc/pam.d/loginファイルのauthセクションに追加します。auth required pam_lastlog.so inactive=10
- GNOME デスクトップ環境でアカウントをロックするには、root で以下の行を
/etc/pam.d/gdmファイルのauthセクションに追加します。auth required pam_lastlog.so inactive=10
注記
他のデスクトップ環境では、その環境における該当ファイルを編集してください。
2.1.6. アクセス制御のカスタマイズ
pam_access PAM モジュールを使用すると、管理者はログイン名、ホストもしくはドメイン名、または IP アドバイスに基づいてアクセス制御をカスタマイズできます。デフォルトでは、他の指定がない場合、モジュールがアクセスルールを /etc/security/access.conf ファイルから読み込みます。これらルールの形式についての完全な説明は、access.conf(5) の man ページを参照してください。Red Hat Enterprise Linux ではデフォルトで、pam_access が /etc/pam.d/crond および /etc/pam.d/atd の各ファイルに含まれています。
ユーザー john がコンソールおよびグラフィックデスクトップ環境からシステムにアクセスできないようにするには、以下の手順を実行します。
- 以下の行を
/etc/pam.d/loginおよび/etc/pam.d/gdm-*の各ファイルのaccountセクションに追加します。account required pam_access.so
/etc/security/access.confファイルで、以下のルールを指定します。- : john : ALL
このルールでは、ユーザー john がどの場所からログインしようとしても、拒否されます。
ユーザー john が IP アドレス 1.2.3.4 からログインしようとする場合を除いて、SSH 経由ですべてのユーザーによるログインを許可するには、以下の手順を実行します。
- 以下の行を
/etc/pam.d/sshdファイルのaccountセクションに追加します。account required pam_access.so
- /etc/security/access.conf ファイルで以下の ルールを指定します。
+ : ALL EXCEPT john : 1.2.3.4
他のサービスからのアクセスを制限するには、
/etc/pam.d ディレクトリー内の各ファイル内で pam_access モジュールが必要になります。
システム全体の PAM 設定ファイル (
/etc/pam.d ディレクトリー内の *-auth ファイル) を呼び出すすべてのサービス向けに pam_access モジュールを呼び出すには、以下のコマンドを使用します。
authconfig --enablepamaccess --update
別の方法では、認証設定ユーティリティーを使って
pam_access モジュールを有効にすることができます。このユーティリティーを起動するには、トップメニューから → → を選択します。 タブで、「ローカルアクセス制御を有効にする」にチェックを入れます。これで、pam_access モジュールがシステム全体の PAM 設定に追加されます。
2.1.7. 時間ベースのアクセス制限
pam_time PAM モジュールでは、一定の時間帯にアクセスを制限することができます。また、特定の曜日やユーザー名、システムサービスの使用などに基づいてアクセスを制限するように設定することも可能です。デフォルトでは、モジュールはアクセスルールを /etc/security/time.conf ファイルから読み取ります。これらルールの形式についての完全な説明は、time.conf(5) の man ページを参照してください。
root ユーザー以外の全ユーザーが月曜から金曜までの午後 5:30 から午前 8:00 までと土曜日および日曜日にログインできないようにするには、以下の手順を実行します。
- 以下の行を
/etc/pam.d/loginファイルの account セクションに追加します。account required pam_time.so
/etc/security/time.confファイルで、以下のルールを指定します。login ; ALL ; !root ; tty* ; !Wk1730-0800
ユーザー john が (月曜始まりの) 営業日の営業時間中のみに SSH サービスを使用できるようにするには、以下の手順を実行します。
- 以下の行を
/etc/pam.d/sshdファイルに追加します。account required pam_time.so
/etc/security/time.confファイルで、以下のルールを指定します。sshd ; john ; tty* ; Wk0800-1730
注記
これらの設定がデスクトップで適用されるには、
pam_time モジュールが /etc/pam.d ディレクトリー内の対応ファイルに含まれている必要があります。
2.1.8. アカウント制限の適用
pam_limits PAM モジュールを使うと、以下のことができます。
- ユーザーあたりの同時ログインセッションの最大数など、ユーザーログインセッションの制限を適用する。
- ulimit ユーティリティーで設定する制限を指定する。
- nice ユーティリティーで設定する優先順位を指定する。
デフォルトでは、ルールは
/etc/security/limits.conf ファイルから読み取られます。これらルールの形式についての完全な説明は、limits.conf(5) の man ページを参照してください。さらに、特定のアプリケーションやサービス向けに、/etc/security/limits.d ディレクトリー内に個別の設定ファイルを作成することもできます。デフォルトでは、pam_limits モジュールは、/etc/pam.d/ ディレクトリー内の多くのファイルに含まれています。ユーザープロセスのデフォルト制限は /etc/security/limits.d/90-nproc.conf ファイルで定義され、fork 爆弾のような悪意のあるサービス拒否攻撃を防ぎます。デフォルトのユーザープロセス制限を 50 に変更するには、/etc/security/limits.d/90-nproc.conf 内の値をファイル内の形式にしたがって変更します。
* soft nproc 50
例2.2 ユーザーあたりの最大ログイン数の指定
officeという名前のグループにおけるユーザーの同時ログイン最大数を設定するには、以下の ルールを/etc/security/limits.confファイル内で指定します。@office - maxlogins 4
- 以下の行は、デフォルトで
/etc/pam.d/system-auth内にあるはずです。ない場合は、手動で追加します。session required pam_limits.so
2.1.9. 管理者コントロール
ホームとなるマシンを管理する際には、ユーザーは root ユーザーとして、または
sudo や su などの setuid プログラムで有効な root 権限を取得してから実行する必要のあるタスクがあります。setuid プログラムは、プログラムを実行しているユーザーではなく、プログラムの所有者のユーザー ID (UID) で実行されるプログラムです。これらのプログラムは、以下の例のように、ロング形式の所有者セクションにある s で示されます。
~]$ ls -l /bin/su
-rwsr-xr-x. 1 root root 34904 Mar 10 2011 /bin/su注記
s は大文字または小文字の場合があります。大文字の場合は、基になるパーミッションビットが設定されていないことを示します。
しかし、組織のシステム管理者は、組織のユーザーが自身のマシンにどの程度の管理者アクセスを持つかを決定しなくてはなりません。
pam_console.so と呼ばれる PAM モジュールを使うと、再起動やリムーバブルメディアのマウントなど通常は root ユーザーのみとなっているアクティビティーを、物理コンソールに最初にログインしたユーザーが実行できるようになります (pam_console.so の詳細については、『Managing Single Sign-On and Smart Cards』 を参照してください)。しかし、ネットワーク設定の変更や新たなマウスの設定、ネットワークデバイスのマウントといったシステム管理者の他の重要なタスクは、管理者権限なしでは実行できません。その結果、システム管理者はネットワーク上のユーザーにどの程度のアクセスを許可するかを判断する必要があります。
2.1.9.1. Root アクセスの許可
組織内のユーザーが信頼できてコンピューターの知識を持っているユーザーであれば、root アクセスを許可することに問題はありません。ユーザーに root アクセスを許可すれば、デバイスの追加やネットワークインターフェイスの設定といった重要性の低いアクティビティを個別のユーザーが処理できるので、システム管理者はネットワークセキュリティや他の重要な問題に専念できます。
一方で、個別のユーザーに root アクセスを許可すると、以下のような問題も発生します。
- マシンの誤った設定 — root アクセスを持つユーザーは自身のマシンを間違って設定する可能性があり、この問題を解決するにはヘルプを必要とします。ひどい場合には、知らないうちにセキュリティに穴を開けてしまう可能性もあります。
- 安全でないサービスの実行 — root アクセスを持つユーザーは、FTP や Telnet といった安全でないサービスを自身のマシン上で実行して、ユーザー名やパスワードを危険にさらす可能性があります。これらのサービスは、ユーザー名やパスワードをプレーンテキストでネットワーク上で送信します。
- Email の添付ファイルを root として実行 — 滅多にないことですが、Linux に影響を及ぼす Email ウイルスも存在します。しかしこれが脅威となるのは、root ユーザーとして実行された場合のみです。
- 監査証跡がそのままになる — root アカウントは通常複数のユーザーが共有し、複数のシステム管理者がシステムのメインテナンスをできるようになっているため、ある時点でこのうちのどのユーザーが root だったかを見分けることは不可能です。別個のログインを使用すると、ユーザーがログインしたアカウントとセッション追跡目的の一意の番号がタスク構造に組み込まれ、これはユーザーが開始するプロセスすべてで継承されます。同時ログインを使用すると、一意の番号は特定ログインのアクションの追跡に使用できます。アクションが監査イベントを生成する際には、ログインアカウントとその一意の番号に関連付けられているセッションとともに記録されます。これらのログインとセッションを表にするには、
aulastコマンドを使用します。aulastの--proofオプションを使うと、特定のセッションで生成された監査可能なイベントを切り離す特定のausearchクエリの提示が可能になります。
2.1.9.2. Root アクセスの拒否
上記またはその他の理由でユーザーが root でログインすることに管理者が不安に感じる場合、root パスワードは公開せず、ランレベル 1 へのアクセスやシングルユーザーモードへのアクセスをブートローダーパスワード保護で拒否してください (このトピックについての詳細は 「ブートローダーのパスワード」 を参照してください)。
管理者は以下の 4 つの方法で、root ログインが拒否されるようにできます。
- Root シェルの変更
- ユーザーが直接 root としてログインしないように、システム管理者は
/etc/passwdファイルで root アカウントのシェルを/sbin/nologinに設定できます。表2.2 Root シェルの無効化
影響あり 影響なし Root シェルへのアクセスを防ぎ、アクセスの試みをすべてログに記録します。以下のプログラムは root アカウントへのアクセスが止められます。logingdmkdmxdmsusshscpsftp
FTP クライアントや メールクライアント、多くの setuid プログラムはシェルを必要としません。以下のプログラムは root アカウントへのアクセスが 止められません。sudo- FTP クライアント
- Email クライアント
- どのコンソールデバイス (tty) からの root アクセスも無効にする
- Root アカウントへのアクセスをさらに制限するために、管理者は
/etc/securettyファイルを編集してコンソールでの root ログインを無効にすることができます。このファイルは、root ユーザーがログイン可能なすべてのデバイスを一覧表示します。このファイル自体がない場合、コンソールからでも raw ネットワークインターフェイスからでも、システム上のいかなる通信デバイスからでも root ユーザーはログイン可能となってしまいます。ユーザーは Telnet 経由で root としてマシンにログイン可能で、こうするとプレーンテキストのパスワードがネットワーク上で送信されてしまうので、危険なことになります。デフォルトでは、Red Hat Enterprise Linux の/etc/securettyファイルは root ユーザーにのみ、マシンに物理的につながれたコンソールでのログインを許可します。root ユーザーによるログインを拒否するには、root でシェルプロンプトから以下のコマンドを入力して、このファイルのコンテンツ削除します。echo > /etc/securettyKDM、GDM、XDM のログインマネージャーでのsecurettyサポートを有効にするには、以下の行を追加します。auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so
追加対象のファイルは以下のとおりです。/etc/pam.d/gdm/etc/pam.d/gdm-autologin/etc/pam.d/gdm-fingerprint/etc/pam.d/gdm-password/etc/pam.d/gdm-smartcard/etc/pam.d/kdm/etc/pam.d/kdm-np/etc/pam.d/xdm
警告
/etc/securettyファイルを空白にしても、root ユーザーがリモートでツールの OpenSSH スイートを使用してログインすることは止められません。これは、コンソールは認証が終わるまで開かれないためです。表2.3 Root ログインの無効化
影響あり 影響なし コンソールまたはネットワーク経由での root アカウントへのアクセスを防ぎます。以下のプログラムは root アカウントへのアクセスが止められます。logingdmkdmxdm- tty を開くその他のネットワークサービス
Root としてはログインしませんが、setuid または別のメカニズムで管理タスクを実行するプログラムです。以下のプログラムは root アカウントへのアクセスが 止められません。susudosshscpsftp
- Root SSH ログインを無効にする
- SSH プロトコル経由での root ログインを防ぐには、SSH デーモンの設定ファイルである
/etc/ssh/sshd_configを編集し、#PermitRootLogin yes
の行を以下のように変更します。PermitRootLogin no
表2.4 Root SSH ログインの無効化
影響あり 影響なし ツールの OpenSSH スイート経由での root アクセスを防ぎます。以下のプログラムは root アカウントへのアクセスが止められます。sshscpsftp
ツールの OpenSSH スイートの一部ではないプログラム - PAM を使用してサービスへの root アクセスを制限する
- PAM は
/lib/security/pam_listfile.soを使って、特定アカウントの拒否に大幅な柔軟性を提供します。管理者はこのモジュールを使ってログインが許可されないユーザーリストを引用できます。システムサービスへの root アクセスを制限するには、/etc/pam.d/ディレクトリー内の対象サービスのファイルを編集して、pam_listfile.soモジュールが認証に必要となるようにします。以下の例では、/etc/pam.d/vsftpdPAM 設定ファイルのvsftpdFTP サーバーにこのモジュールを使用しています (一行目の末にある\の文字は、指示文が一行の場合は必要ありません)。auth required /lib/security/pam_listfile.so item=user \ sense=deny file=/etc/vsftpd.ftpusers onerr=succeed
これにより、PAM が/etc/vsftpd.ftpusersファイルを見て、リストに載っているユーザーにサービスへのアクセスを拒否するように指示します。管理者はこのファイル名を変更し、各サービスごとに別個のリストを維持したり、複数サービスへのアクセスを拒否する集中リストを使用したりすることができます。管理者が複数サービスへのアクセスを拒否したい場合、メールクライアントでは/etc/pam.d/popや/etc/pam.d/imapファイルに、SSH クライアントでは/etc/pam.d/sshファイルのような PAM 設定ファイルに同様の行を追加することができます。PAM についての詳細は、『Red Hat Enterprise Linux Managing Single Sign-On and Smart Cards』 ガイドの 『Using Pluggable Authentication Modules (PAM)』 の章を参照してください。表2.5 PAM を使った root の無効化
影響あり 影響なし PAM 対応のネットワークサービスへの root アクセスを防ぎます。以下のサービスは root アカウントへのアクセスが止められます。logingdmkdmxdmsshscpsftp- FTP クライアント
- Email クライアント
- すべての PAM 対応サービス
PAM 非対応のプログラムおよびサービス
2.1.9.3. 自動ログアウトの有効化
ユーザーが
root としてログインしている場合、このセッションを無人状態にしておくと、重大なセキュリティリスクをもたらす恐れがあります。このリスクを減らすために、一定期間が経過してからアイドル状態のユーザーを自動的にログアウトするようにシステムを設定することができます。
- screen パッケージがインストールされていることを確認して下さい。
rootとして以下のコマンドを実行します。~]#
yuminstallscreenRed Hat Enterprise Linux にパッケージをインストールする方法についての詳細情報は、『Red Hat Enterprise Linux 6 導入ガイド』 の パッケージのインストール のセクションを参照してください。 rootとして/etc/profileファイルの先頭に以下の行を追加して、このファイルの処理が中断されないようにします。trap "" 1 2 3 15
/etc/profileファイルの最後に以下の行を追加して、ユーザーが仮想コンソールまたはリモートからログインする度にscreenセッションが開始するようにします。SCREENEXEC="screen" if [ -w $(tty) ]; then trap "exec $SCREENEXEC" 1 2 3 15 echo -n 'Starting session in 10 seconds' sleep 10 exec $SCREENEXEC fi
新規セッションが開始される度にメッセージが表示されるため、ユーザーは 10 秒間待たなければならない点に注意して下さい。セッション開始までの待機時間を調節するには、sleepコマンドの後にある値を変更します。- アクティブでない状態が一定期間経過した後に、
screenセッションを閉じるようにするには、以下の行を/etc/screenrc設定ファイルに追加します。idle 120 quit autodetach off
上記は、制限時間を 120 秒に設定しています。この制限を調節するには、idle指示文の後にある値を変更します。別の方法として、以下の行を使用してセッションのロックだけが行われるようにシステムを設定することも可能です。idle 120 lockscreen autodetach off
この方法では、セッションのロックを解除するためにパスワードが必要になります。
これらの変更は、ユーザーが次回システムにログインする時に反映されます。
2.1.9.4. Root アクセスの制限
Root ユーザーへのアクセスを完全に拒否するのではなく、管理者が
su や sudo といった setuid プログラム経由のアクセスのみを許可したい場合もあるかもしれません。su および sudo についての詳細は 『Red Hat Enterprise Linux 6 導入ガイド』 および su(1) と sudo(8) の man ページを参照してください。
2.1.9.5. アカウントのロック
Red Hat Enterprise Linux 6 では、
pam_faillock PAM モジュールを使うとシステム管理者は特定回数のログイン失敗の後にユーザーアカウントをロックアウトすることができます。ユーザーログインの試行回数を制限する主な目的はセキュリティ措置であり、ユーザーアカウントのパスワード獲得を目的とする総当たり攻撃を防ぐためのものです。
pam_faillock モジュールを使うと、ログイン失敗はユーザーごとに /var/run/faillock ディレクトリー内の個別ファイルに保存されます。
注記
ログイン失敗のログファイルにおける行の順番は重要なものです。
even_deny_root オプションが使用されている場合、この順番が変更されると root アカウントを含むすべてのユーザーアカウントがロックされます。
アカウントのロックを設定するには、以下の手順を実行します。
- root 以外のユーザーがログインに 3 回失敗した後にロックアウトし、その 10 分後にこのユーザーのロックアウトを解除するようにするには、以下の行を
/etc/pam.d/system-authおよび/etc/pam.d/password-authの各ファイルのauthセクションに追加します。auth required pam_faillock.so preauth silent audit deny=3 unlock_time=600 auth sufficient pam_unix.so nullok try_first_pass auth [default=die] pam_faillock.so authfail audit deny=3 unlock_time=600
- 以下の行を上記の手順の両ファイルの
accountセクションに追加します。account required pam_faillock.so
- アカウントのロックアウトを root ユーザーにも適用するには、
/etc/pam.d/system-authおよび/etc/pam.d/password-authの各ファイルのpam_faillockエントリーにeven_deny_rootオプションを追加します。auth required pam_faillock.so preauth silent audit deny=3 even_deny_root unlock_time=600 auth sufficient pam_unix.so nullok try_first_pass auth [default=die] pam_faillock.so authfail audit deny=3 even_deny_root unlock_time=600 auth sufficient pam_faillock.so authsucc audit deny=3 even_deny_root unlock_time=600
ユーザー
john がログインに 3 回失敗した後に再度ログインしようとすると、このユーザーのアカウントはこの 4 回目のログイン試行でロックされます。
[user@localhost ~]$ su - john Account locked due to 3 failed logins su: incorrect password
複数回のログイン失敗の後でもユーザーがロックアウトされないようにするには、以下の行を
/etc/pam.d/system-auth および /etc/pam.d/password-auth の各ファイルで pam_faillock が最初に呼び出される行のすぐ上に追加します。また、user1、user2、user3 を実際のユーザー名で置き換えます。
auth [success=1 default=ignore] pam_succeed_if.so user in user1:user2:user3
ユーザー別のログイン失敗数を表示するには、root で以下のコマンドを実行します。
[root@localhost ~]# faillock
john:
When Type Source Valid
2013-03-05 11:44:14 TTY pts/0 V
ユーザーのアカウントのロックを解除するには、root で以下のコマンドを実行します。
faillock --user <username> --reset
authconfig ユーティリティーを使って認証設定を修正すると、
system-auth および password-auth の各ファイルは authconfig ユーティリティーからの設定で上書きされます。設定ファイルと authconfig を同時に使うには、以下の手順でアカウントロックを設定する必要があります。
- 以下のシンボリックリンクを作成します。
~]#
ln -s /etc/pam.d/system-auth /etc/pam.d/system-auth-local~]#ln -s /etc/pam.d/password-auth /etc/pam.d/password-auth-local /etc/pam.d/system-auth-localファイルに以下の行を記載します。auth required pam_faillock.so preauth silent audit deny=3 unlock_time=600 include system-auth-ac auth [default=die] pam_faillock.so authfail silent audit deny=3 unlock_time=600 account required pam_faillock.so account include system-auth-ac password include system-auth-ac session include system-auth-ac
/etc/pam.d/password-auth-localファイルに以下の行を記載します。auth required pam_faillock.so preauth silent audit deny=3 unlock_time=600 include password-auth-ac auth [default=die] pam_faillock.so authfail silent audit deny=3 unlock_time=600 account required pam_faillock.so account include password-auth-ac password include system-auth-ac session include system-auth-ac
pam_faillock の設定オプションについての詳細情報は、pam_faillock(8) の man ページを参照してください。
2.1.10. セッションのロック
日常の業務中にユーザーがワークステーションから離れなければならない時もあります。こういう場合は、特に十分な物理的セキュリティ対策がとられていない環境 (「物理的コントロール」 を参照) では、攻撃者にマシンに物理的にアクセスする機会を与えてしまいます。ノートパソコンの場合は特に、持ち運びが便利なので物理的な安全性が脅かされます。このリスクは、正しいパスワードが入力されないとシステムにアクセスできないようにするセッションロッキング機能を使うことで緩和できます。
注記
画面のロックがログアウトよりも優れている点は、ロックの場合は (ファイル転送といった) ユーザーのプロセスを続行できるという点です。ログアウトしてしまうと、このようなプロセスは中断してしまいます。
2.1.10.1. GNOME スクリーンセーバーコマンドを使用して GNOME をロックする
Red Hat Enterprise Linux 6 のデフォルトのデスクトップ環境である GNOME には、ユーザーがいつでも画面をロックできる機能が含まれています。このロックを実行するにはいくつかの方法があります。
- → → → → で指定されているキーの組み合わせを押します。デフォルトでは、Ctrl+Alt+L となっています。
- パネル上で → を選択します。
- コマンドラインインターフェイスで以下のコマンドを実行します。
gnome-screensaver-command-l
上記の方法はどれも、スクリーンセーバーが実行されて画面がロックされる、という同じ結果になります。ユーザーがいずれかのキーを押すとスクリーンセーバーが解除され、パスワードを入力して作業を続けられます。
この機能は
gnome-screensaver プロセスの稼働を必要とすることに注意してください。これが稼働中かどうかは、プロセスについての情報を提供するコマンドを使用してチェックします。例えば、以下のコマンドを端末から実行します。
pidof gnome-screensavergnome-screensaver が実行中であれば、識別番号 (PID) を示す番号がコマンド実行後に画面に表示されます。プロセスが実行中でなければ、出力がありません
詳細は
gnome-screensaver-command(1) man ページを参照してください。
重要
上記の画面をロックする方法は、手動でのアクティベーションに依存しています。そのため管理者はユーザーに、短時間でもマシンから離れる場合は必ずコンピューターをロックすることアドバイスする必要があります。
2.1.10.1.1. スクリーンセーバーロックの自動アクティベーション
gnome-screensaver-command の名前が示すように、ロック機能は GNOME のスクリーンセーバーと連動しています。ロック機能をスクリーンセーバーのアクティベーションと連動させて、ワークステーションが一定時間無人となったらロックするようにできます。この機能はデフォルトで、5 分間のタイムアウトでアクティベートするようになっています。
この自動ロック設定を変更するには、メインパネルから → → を選択します。これで、タイムアウトの時間設定をするウィンドウが開き (アイドル状態になるまでの時間 スライダー) 自動ロックの有効/無効化ができます (スクリーンセーバーを起動したら画面をロックする チェックボックス)。
図2.2 スクリーンセーバーの設定変更
注記
スクリーンセーバーの設定 ダイアログで アイドル状態になったらスクリーンセーバーを起動する のオプションを無効にすると、スクリーンセーバーが自動で起動しなくなります。このため、自動ロックも無効になりますが、「GNOME スクリーンセーバーコマンドを使用して GNOME をロックする」 にある手動作業でのワークステーションのロックはできます。
2.1.10.1.2. リモートでのセッションロック
ロック対象のワークステーションが
ssh プロトコルでの接続を受け入れれば、これを使用して GNOME セッションをリモートでロックすることもできます。アクセスしたマシンの画面をリモートでロックするには、以下のコマンドを実行します。
ssh -X <username>@<server> "export DISPLAY=:0; gnome-screensaver-command -l"
<username> を自分のユーザー名で、<server> をロックするワークステーションの IP アドレスで置き換えます。
ssh に関する詳細は、「SSH (Secure Shell)」 を参照してください。
2.1.10.2. vlock を使った仮想コンソールのロック
仮想コンソールをロックする必要がある場合は、
vlock というユーティリティーを使って実行できます。このユーティリティーをインストールするには、以下のコマンドを root で実行します。
~]# yum install vlock
インストール後は、新たなパラメーターなしで
vlock コマンドを使えば、コンソールセッションはすべてロックできます。このコマンドでは、アクティブな仮想コンソールをロックしますが、他のセッションへのアクセスは可能です。ワークステーション上のすべての仮想コンソールへのアクセスを防止するには、以下のコマンドを実行します。
vlock-a
この場合、
vlock がアクティブなコンソールをロックし、-a オプションが他の仮想コンソールへのスイッチを防ぎます。
詳細は
vlock(1) man ページを参照してください。
2.1.11. 利用可能なネットワーク
組織内のシステム管理者にとっては管理機能へのユーザーアクセスは重要な問題ですが、どのネットワークサービスがアクティブかを監視することは、Linux システムのすべての管理・運営担当者にとって最重要事項です。
Red Hat Enterprise Linux 6 における多くのサービスは、ネットワークサーバーとして動作します。マシン上でネットワークサービスが稼働中であれば、(デーモン と呼ばれる) サーバーアプリケーションが 1 つ以上のネットワークポート上での接続をリッスンします。これらの各サーバーは、潜在的な攻撃の接近手段として扱われる必要があります。
2.1.11.1. サービスへのリスク
ネットワークサービスは Linux システムに多くのリスクを与える可能性があります。主な問題を以下に挙げます。
- サービス拒否攻撃 (DoS) — サービス拒否攻撃は、サービスに対して要求を大量に送信することでシステムがすべての要求をログ記録・応答しようとし、使用不可能になります。
- 分散型サービス拒否攻撃 (DDoS) — これは DoS 攻撃の一種で、複数の脆弱なマシンを使用し (通常、数千以上)、サービスに対して一斉攻撃を仕掛けます。大量の要求が送信され、サービスを使用不可能にしてしまいます。
- スクリプトの脆弱性への攻撃 — Web サーバーが通常行うように、サーバー全体のアクションにサーバーがスクリプトを使用している場合、クラッカーは誤って書かれたスクリプトを攻撃することができます。このスクリプトの脆弱性に対する攻撃により、バッファがオーバーフロー状態になるか、攻撃者がシステム上のファイルを変更できる可能性があります。
- バッファオーバーフロー攻撃 — ポート番号 0 から 1023 までに接続するサービスは、管理ユーザーとして実行する必要があります。アプリケーションに利用可能なバッファオーバーフローがある場合、攻撃者はデーモンを実行中のユーザーとしてシステムにアクセスすることができます。利用可能なバッファオーバーフローが存在することから、クラッカーは自動ツールを使って脆弱性のあるシステムを特定でき、アクセスを確保した後に自動ルートキットを使ってシステムへのアクセスを維持します。
注記
Red Hat Enterprise Linux では、ExecShield と呼ばれる x86 互換のシングルおよびマルチプロセッサのカーネルがサポートする実行可能メモリのセグメント化および保護技術により、バッファオーバーフローの脆弱性における脅威は緩和されています。ExecShield は仮想メモリを実行可能なセグメントと非実行可能セグメントに分けることでバッファオーバーフローのリスクを下げます。(バッファオーバーフローエクスプロイトから注入された悪意のあるコードなど) 実行可能セグメント外で実行を試みるすべてのプログラムコードは、セグメント化の失敗を発生させ、終了します。
Execshield には AMD64 プラットフォーム上の No eXecute (NX) と Itanium 上の eXecute Disable (XD) テクノロジー、Intel® 64 システムのサポートが含まれます。これらのテクノロジーが ExecShield と組み合わさることで、4 KB の実行可能コードという粒度で仮想メモリの実行可能な部分での悪意のあるコードの実行を防ぎます。これで、バッファオーバーフローエクスプロイトからの攻撃リスクを減らします。
重要
ネットワーク上での攻撃への露出を限定するには、使用していないサービスをすべて無効にしてください。
2.1.11.2. サービスの特定および設定
セキュリティを強化するために、Red Hat Enterprise Linux でインストールされているネットワークサービスのほとんどはデフォルトでオフとなっています。ただし、以下のものは例外となります。
cupsd— Red Hat Enterprise Linux のデフォルトのプリントサーバーlpd— 代替プリントサーバーxinetd—gssftpやtelnetなどの下位サーバーへの接続を管理するスーパーサーバーsendmail— Sendmail メール転送エージェント (MTA) はデフォルトでは有効となっていますが、localhost からの接続のみをリッスンします。sshd— Telnet の安全な代替となる OpenSSH サーバー
これらサービスの稼働を継続しておくかどうかを判断する際は、常識にしたがってリスクを避けるのが最善策です。例えば、プリンターが利用できない場合は
cupsd を無効にします。同じことは portmap についても言えます。NFSv3 ボリュームをマウントしていなかったり、NIS (ypbind サービス) を使用しないのであれば、portmap を無効にすべきです。
図2.3 サービス設定ツール
特定サービスの目的が明確でない場合は、図2.3「サービス設定ツール」 にあるように、サービス設定ツール の説明フィールドで追加情報が提供されています。
起動時にどのネットワークサービスが開始されるかをチェックするだけでは十分ではありません。どのポートが開いていて、リッスンしているかをチェックすることも推奨されます。詳細は、「リッスンしているポートの確認」 を参照してください。
2.1.11.3. 安全でないサービス
潜在的にはどのネットワークサービスも安全ではありません。未使用のサービスをオフにすることが重要なのは、このためです。サービスのエクスプロイトは定期的に発見され修正プログラムが提供されているので、ネットワークサービスはどんなものでも関連するパッケージを定期的に更新することが非常に重要です。詳細は 「セキュリティの更新」 を参照してください。
ネットワークプロトコルの中にはもともと他のものよりも安全性が低いものがあります。以下の動作を実行するサービスがそれに当たります。
- 暗号化されていないネットワークでユーザー名やパスワードを送信する — Telnet や FTP など多くの古いプロトコルは認証セッションを暗号化しないので、できるだけ避けてください。
- 暗号化されていないネットワークで機密性の高いデータを送信する — Telnet や FTP、HTTP、SMTP など多くのプロトコルでは暗号化されていないネットワークでデータを送信します。また、NFS や SMB などの多くのネットワークファイルシステムでも暗号化されていないネットワークで情報を送信します。これらのプロトコルを使用する際に送信するデータの種類を制限することは、ユーザーの責任になります。
netdumpといったリモートのメモリダンプサービスは、暗号化されていないネットワークでメモリのコンテンツを送信します。メモリダンプにはパスワードや、さらに深刻な場合にはデータベースエントリや他の機密性の高い情報が含まれている場合もあります。fingerやrwhodといったサービスは、システムのユーザーについての情報を明らかにします。
もともと安全性が低いサービスには、
rlogin、rsh、telnet、vsftpd などがあります。
リモートログインおよびシェルプログラム (
rlogin、rsh、telnet) はすべて避けて、SSH を選択するべきです。sshd についての詳細情報は、「セキュリティ強化の通信ツール」を参照してください。
FTP はリモートシェルと比べるとシステムの安全性にそれほど危険ではありませんが、問題を回避するには FTP サーバーは慎重に設定、監視する必要があります。FTP サーバーを安全にする詳細情報については、「FTP のセキュア化」 を参照してください。
実装時に注意が必要で、ファイアウォールの背後に配置する必要があるサービスは以下のものです。
fingerauthd(以前の Red Hat Enterprise Linux リリースではidentdと呼ばれていました)netdumpnetdump-servernfsrwhodsendmailsmb(Samba)yppasswddypservypxfrd
ネットワークサービスの安全性を高めるための詳細情報は、「サーバーのセキュリティ」 を参照してください。
次のセクションでは、簡単なファイアウォールを設定するツールについて説明します。
2.1.12. 個人用ファイアウォール
必要な ネットワークサービスを設定した後は、ファイアウォールの設置が重要になります。
重要
インターネットや信頼できないネットワークに接続する前 に、必要なサービスを設定し、ファイアウォールを設置してください。
ファイアウォールは、ネットワークパケットがシステムのネットワークインターフェイスにアクセスすることを防ぎます。ファイアウォールがブロックしているポートに要求がなされた場合、この要求は無視されます。サービスがブロックされているポートの一つをリッスンしている場合、パケットは受信されず、実質的には無視されます。このため、ファイアウォールを設定する際は、設定済みサービスが使用しているポートへのアクセスをブロックしないようにする一方で、使用されていないポートへのアクセスを確実にブロックするようにしてください。
ほとんどのユーザーにとって、簡単なファイアウォールを設定する最善のツールは、Red Hat Enterprise Linux に同梱されているグラフィカルのファイアウォール設定ツールである Firewall Configuration Tool (
system-config-firewall) です。このツールは、コントロールパネルのインターフェイスを使って全般目的のファイアウォール用に幅広い iptables ルールを作成します。
このアプリケーションと利用可能なオプションについての詳細情報は、「基本的なファイアウォールの設定」 を参照してください。
上級ユーザーおよびサーバー管理者の場合は、
iptables を使って手動でファイアウォールを設定する方法が望まれます。詳細は 「ファイアウォール」 を参照してください。iptables コマンドに関する総合的なガイドについては、「IPTables」 を参照してください。
2.1.13. セキュリティ強化の通信ツール
インターネットの規模と人気が拡大するにつれて、通信傍受の脅威も増大しています。通信はネットワーク上で行われるため、長年にわたってこれを暗号化するツールが開発されてきました。
Red Hat Enterprise Linux 6 に同梱されている基本的ツールは 2 つあり、これらはネットワーク上を行き来する情報を保護するために高レベルの公開キー暗号作成法に基づいた暗号化アルゴリズムを使います。
- OpenSSH — ネットワーク通信暗号化のための SSH プロトコルの無料実装
- Gnu Privacy Guard (GPG) — データ暗号化用の PGP (Pretty Good Privacy) 暗号化アプリケーションの無料実装
OpenSSH はリモートマシンにアクセスする安全な方法で、
telnet や rsh などの旧式かつ暗号化されていないサービスに代わるものです。OpenSSH には sshd と呼ばれるネットワークサービスのほか、以下の 3 つのコマンドラインアプリケーションが含まれています。
ssh— 安全なコンソールアクセスクライアントscp— 安全なリモートコピーコマンドsftp— インタラクティブなファイル転送セッションを可能にする安全な擬似 ftp クライアント
OpenSSH に関する詳細は、「SSH (Secure Shell)」 を参照してください。
重要
GPG は Email 通信の秘密性を確保する方法の一つです。公開ネットワークで機密性の高いデータを Email で送るためと、ハードドライブ上の機密性の高いデータを保護するための両方に使用できます。
Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.