Red Hat Enterprise Linux 7 Security Guide Ja JP

Red Hat Enterprise Linux 7
セキュリティガイド
Red Hat Enterprise Linux 7 のセキュリティに関するガイド
Martin Prpič Tomáš Čapek Stephen Wadeley

Yoana Ruseva Miroslav Svoboda Robert Krátký
Red Hat Enterprise Linux 7 セキュリティガイド
Red Hat Enterprise Linux 7 のセキュリティに関するガイド
Martin Prpič
Red Hat Customer Content Services
mprpic@redhat.com
Tomáš Čapek
tcapek@redhat.com
Stephen Wadeley
swadeley@redhat.com
Yoana Ruseva
yruseva@redhat.com
Miroslav Svoboda
msvoboda@redhat.com
Robert Krátký
rkratky@redhat.com
法律上の通知
Copyright © 2015 Red Hat, Inc.
This document is licensed by Red Hat under the Creative Commons Attribution-
ShareAlike 3.0 Unported License. If you distribute this document, or a modified version
of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If
the document is modified, all Red Hat trademarks must be removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees
not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable
law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora,
the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United
States and other countries.
Linux ® is the registered trademark of Linus Torvalds in the United States and other
countries.
Java ® is a registered trademark of Oracle and/or its affiliates.
XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the

United States and/or other countries.
MySQL ® is a registered trademark of MySQL AB in the United States, the European

Union and other countries.
Node.js ® is an official trademark of Joyent. Red Hat Software Collections is not

formally related to or endorsed by the official Joyent Node.js open source or
commercial project.
The OpenStack ® Word Mark and OpenStack Logo are either registered
trademarks/service marks or trademarks/service marks of the OpenStack
Foundation, in the United States and other countries and are used with the
OpenStack Foundation's permission. We are not affiliated with, endorsed or
sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
概要
本書は、ユーザーおよび管理者が、ローカルまたはリモートからの侵入、悪用および悪意のある行
為に対してワークステーションとサーバーを保護するプロセスと方法を習得する際の手助けとなり
ます。本ガイドは Red Hat Enterprise Linux にフォーカスしたものですが、概念と手法はすべ
ての Linux システムに適用できるものです。データセンター、勤務先および個人宅での安全なコン
ピューター環境の構築に必要となるプランニングとツールについて詳細に説明しています。管理
上の適切な知識と警戒体制およびツールを備えることで、Linux を実行しているシステムの機能を
フルに活用し、かつこれらのシステムをほとんどの一般的な侵入や悪用の手法から保護することが
できます。
1
第1章セキュリティの概要
ビジネスの運営や個人情報の記録ではネットワーク化された強力なコンピューターへの依存度が高まってい
ることから、各種業界ではネットワークとコンピューターのセキュリティの実践に関心が向けられていま
す。企業は、システム監査の適正な実施やソリューションが組織の運営要件を満たすようにするために、セ
キュリティ専門家の知識と技能を求めてきました。ほとんどの組織はますます動的になってきていることか
ら、従業員は会社の重要な IT リソースにローカルまたはリモートでアクセスするようになっています。こ
のため、セキュアなコンピューティング環境に対するニーズはより顕著になっています。
しかし残念なことに、多くの組織 (個々のユーザーも含む) が、機能性や生産性、便利さ、使いやすさおよ

び予算面の懸念事項にばかり目を向けてセキュリティを付け足しと見なし、セキュリティのプロセスが見
過ごされています。さらに、セキュリティの適切な実施については、無許可の侵入が発生した後にはじめて
徹底されることも多くあります。多くの侵入の試みを阻止する効果的な方法は、インターネットなどの信頼
できないネットワークにサイトを接続する前に、適切な措置を講じることです。
注記
本書では、/lib ディレクトリーにあるファイルにも言及しています。64 ビットのシステムを使用

している場合は、それらのファイルの一部は /lib64 にある可能性があります。
1.1. コンピューターセキュリティとは
コンピューターセキュリティは、コンピューティングと情報処理の幅広い領域で使用される一般的な用語
です。日常業務や重要な情報へのアクセスにおいてコンピューターシステムとネットワークに依存する業界
は、企業データを総体的資産の重要な部分であると見なしています。総保有コスト (Total Cos t of
Owne rs hip: TCO) やサービスの品質 (Quality of Se rvice : QoS) などのいくつかの用語および評価指標
は日常的なビジネス用語として用いられるようになっていますが、これらの評価指標を用いて、各種の業界
はプランニングおよびプロセス管理コストの一環としてデータ保全性や可用性などを算出しています。電子
商取引などを行う業界では、データの可用性と信頼性がビジネスの成否を決める可能性があります。
1.1.1. セキュリティの標準化
すべての業界の企業は、米国医師会 (AMA: Ame rican Me dical As s ociation) や米国電気電子学会 (IEEE:

Ins titute of Ele ctrical and Ele ctronics Engine e rs ) などの標準化推進団体によって作成される規制や
ルールに従っています。情報セキュリティにも同じことが言えます。多くのセキュリティコンサルタント
やベンダーは機密性 (Confidentiality)、保全性 (Integrity)、可用性 (Availability) の頭文字をとった CIA
として知られる標準セキュリティモデルを採用しています。この 3 階層モデルは、機密情報のリスク評価
やセキュリティ方針の確立において一般的に採用されているモデルです。以下でこの CIA モデルについて
説明します。
機密性 — 機密情報は、事前に定義された個人に対してのみ利用可能とする必要があります。情報の許可
されていない送信や使用は、制限する必要があります。例えば、情報に機密性があれば、権限のない個
人が ID 盗難やクレジット詐欺などの悪意のある目的で顧客情報や財務情報を入手できません。
保全性 — 情報は、不完全または不正確になるように改ざんすべきではありません。承認されていない
ユーザーは、機密情報を変更したり破壊する機能を使用できないように制限される必要があります。
可用性 — 情報は、認証されたユーザーが必要な時にいつでもアクセスできる必要があります。可用性
は、情報が合意された頻度とタイミングで入手できることを保証します。これは、パーセンテージで測
定されることが多く、ネットワークサービスプロバイダーやその企業顧客が使用するサービスレベルア
グリーメント (SLA) で正式に合意されます。
1.2. セキュリティコントロール
2
⁠第1章セキュリティの概要
1.2. セキュリティコントロール
コンピューターセキュリティは多くの場合、以下の 3 つの異なるマスターカテゴリーに分類され、一般に
はコントロールと呼ばれています。
物理的
技術的
管理的
これら 3 つの大まかなカテゴリーは、セキュリティの適切な実施における主な目的を定義するものです。
これらのコントロールには、コントロールおよびそれらの実装方法を詳細化するサブカテゴリーがありま
す。
1.2.1. 物理的コントロール
物理的コントロールは、機密資料への認証されていないアクセスの抑止または防止のために、明確な構造で
セキュリティ対策を実施することです。物理的コントロールの例は以下の通りです。
有線監視カメラ
動作/温度感知アラームシステム
警備員
写真付き身分証明書
施錠された、デッドボルト付きのスチールドア
バイオメトリクス (指紋、声、顔、虹彩、筆跡、および本人確認を行うためのその他の自動認識方法が含
まれます)
1.2.2. 技術的コントロール
技術的コントロールでは、物理的な構造物やネットワークにおける機密データのアクセスや使用を制御する
ための基盤となる技術を使用します。技術的コントロールは広い範囲に及び、以下のような技術も含まれま
す。
暗号化
スマートカード
ネットワーク認証
アクセス制御リスト (ACL: Acce s s control lis ts )
ファイル完全性監査ソフトウェア
1.2.3. 管理者コントロール
管理的コントロールは、セキュリティの人的要素を定義します。これらは組織内のあらゆるレベルの人員に
関連するもので、次のような手段によって、誰がどのリソースや情報にアクセスするかを決定します。
トレーニングおよび認識の向上
災害準備および復旧計画
人員採用と分離の戦略
3
人員登録とアカウンティング
1.3. 脆弱性のアセスメント
時間、リソースおよびやる気のある攻撃者は、ほとんどすべてのシステムに侵入することができます。現在
利用できるすべてのセキュリティ手順と技術を駆使しても、すべてのシステムを侵入から完全に保護できる
訳ではありません。ルーターはインターネットへのセキュアなゲートウェイの提供に役立ちます。ファイ
アウォールはネットワークの境界を保護します。仮想プライベートネットワーク (VPN) は、暗号化された
ストリームにおいてデータを安全に通過させます。侵入検知システムは悪意のある活動について警告しま
す。しかし、これらの技術が成功するかどうかは、以下を含む数多くの要因によって決まります。
技術の設定、監視および保守を行うスタッフの専門知識
サービスとカーネルのパッチおよび更新を迅速かつ効率的に行う能力
ネットワーク上での警戒を常に怠らない担当者の能力
データシステムと各種技術が動的であることを考えると、企業リソースのセキュア化は極めて複雑なタスク
になり得ます。この複雑さゆえに、使用するすべてのシステムについての専門家リソースを見つけることは
多くの場合、困難になります。高レベルの情報セキュリティの多くの分野に精通している人材を確保するこ
とはできても、複数分野における専門家スタッフを保持することは容易ではありません。これは主に、情報
セキュリティの各専門分野では継続的な注意とフォーカスが必要とされるためです。情報セキュリティは
常に変化しています。
脆弱性アセスメントは、お使いのネットワークとシステムのセキュリティについての内部監査です。このア
セスメントの結果として、ネットワークの機密性、完全性および可用性の状態が明らかになります (「セ
キュリティの標準化」に詳述)。通常、脆弱性アセスメントは、対象システムとリソースに関する重要な
データを収集する調査フェーズから開始されます。この後にはシステム準備フェーズが続きます。基本的に
このフェーズでは、対象を絞り、それが持つすべての既知の脆弱性を検査します。準備フェーズの後には報
告フェーズが続きます。ここでは、調査結果が高中低のカテゴリに分類され、対象のセキュリティを向上さ
せる (または脆弱性のリスクを軽減する) 方法が話し合われます。
自宅の脆弱性アセスメントを実施することを想定してみましょう。まずは自宅のドアが閉じられており、か
つ施錠されていることを確認するために各ドアの点検を行うことでしょう。また、すべての窓が完全に閉じ
られていて掛け金が締められていることもチェックするでしょう。これと同じ概念がシステムやネットワー
ク、および電子データにも適用されます。悪意のあるユーザーはデータを盗み、これを破壊します。悪意の
あるユーザーが使用するツールや考え方および動機に注目すると、彼らの行動にすばやく反応することが可
能になります。
1.3.1. アセスメントとテストの定義
脆弱性アセスメントは、外部からの視点と内部からの視点の 2 種類に分類できます。
外部からの視点で脆弱性アセスメントを実施する場合、システムに外部から攻撃を試みます。会社の外部に
立つことで、クラッカーの視点を得ることができます。一般にルーティング可能な IP アドレスや DMZ に
あるシステムやファイアウォールの外部インターフェースなど、クラッカーが目を付けるものに着目しま
す。DMZ は「非武装地帯 (de militariz e d z one )」を表し、企業のプライベート LAN などの信頼できる
内部ネットワークと公的なインターネットなどの信頼できない外部ネットワークの間にあるコンピュー
ターまたは小さなサブネットワークに相当します。通常、DMZ には We b (HTTP) サーバー、FTP サー
バー、SMTP (e -mail) サーバーおよび DNS サーバーなど、インターネットのトラフィックにアクセスで
きるデバイスが含まれます。
内部からの視点で脆弱性アセスメントを実施する場合、実行者は内部関係者であり、信頼されるステータス
にあることから、有利な位置に立ちます。内部からの視点は、実行者やその同僚がシステムにログオンした
時点で得られるものです。プリントサーバーやファイルサーバー、データベースおよびその他のリソースを
見ることができます。
4
これら 2 種類の脆弱性アセスメントには大きな違いがあります。会社の内部にいる場合は、部外者にはな
い多くの特権が与えられます。多くの組織では、侵入者を締め出すようにセキュリティが構成されていま
す。しかし、組織内の各分野に対しては、ほとんどセキュリティ対策が取られていません (部門内ファイア
ウォール、ユーザーレベルのアクセス制御および内部リソースに対する認証手順など)。また、一般的にほ
とんどのシステムは社内にあるので、内部からの方がより多くのリソースを確認できます。いったん社外に
移動すると、ステータスは信頼されない状態になります。外部から利用できるシステムやリソースは、通常
は非常に限られたものになります。
脆弱性アセスメントと侵入テストの違いを考えてみましょう。脆弱性テストを侵入テストの第一歩と捉えて
ください。アセスメントで得られる情報は、その後のテストで使用されます。アセスメントは抜け穴や潜在
的な脆弱性を検査する目的で行われるのに対し、侵入テストでは調査結果を実際に使用する試みがなされま
す。
ネットワークインフラストラクチャーのアセスメントは動的なプロセスです。セキュリティ (情報セキュリ
ティと物理的なセキュリティ) は動的なものです。アセスメントを実施することで概要が明らかになり、誤
検出 (Fals e pos itive s ) と検出漏れ (Fals e ne gative s ) が示される場合があります。誤検出では、実際
には存在しない脆弱性をツールが検出します。検出漏れでは、実際の脆弱性が除外されてしまいます。
セキュリティ管理者の力量は、使用するツールとその管理者が有する知識で決まります。現在使用できるア
セスメントツールのいずれかを選び、それらをシステムに対して実行すると、ほぼ間違いなくいくつかの誤
検出が見つかります。プログラム障害かユーザーエラーかに関わらず、結果は同じです。ツールは誤検出す
ることもあれば、さらに悪い場合は、検出漏れをすることもあります。
脆弱性アセスメントと侵入テストの違いが定義されたところで、新たなベストプラクティスの一環として侵
入テストを実施する前に、アセスメントの結果を注意深く確認、検討してみましょう。
警告
実稼働システム上で脆弱性を悪用する試みを行わないでください。システムとネットワークの生産性
と効率に悪影響を与える可能性があります。
脆弱性アセスメントの実施には、以下のような利点があります。
情報セキュリティに事前にフォーカスできる
クラッカーが発見する前に潜在的な不正使用を発見できる
システムを最新の状態に維持し、パッチを適用できる
スタッフの成長と専門知識の開発を促す
経済的な損失とマイナスの評判を緩和する
1.3.2. 方法論の確立
脆弱性アセスメントの方法論を確立すると、脆弱性アセスメント用のツール選択に役立ちます。残念なが
ら、現時点では事前定義の方法論や業界で承認された方法論はありませんが、一般常識やベストプラクティ
スを適切なガイドとして活用することができます。
ターゲットは何か? 1 つのサーバーまたはネットワーク全体、およびネットワーク内のすべてが含まれる
のか? 会社の外部にいるのか、それとも内部にいるのか? これらの質問に対する答えは、ツールの選択のみ
ならず、ツールの使用方法を決定する際にも役立ちます。
方法論の確立についての詳細は、以下の We b サイトを参照してください。
https ://www.owas p.org/ — 『The Ope n We b Application Se curity Proje ct』
5
1.3.3. 脆弱性アセスメントのツール
アセスメントは、情報収集ツールを使用することから始まります。ネットワーク全体を評価する際は、最初
にレイアウトを描いて実行されているホストを把握します。ホストの場所を確認したら、それぞれのホスト
を個別に検査します。これらのホストにフォーカスするには別のツールセットが必要になります。どのツー
ルを使用すべきかを知っておくことは、脆弱性の発見において最も重要なステップである可能性がありま
す。
日常生活のあらゆる状況と同様に、同じジョブを実行できる異なるツールは数多くあります。この概念は脆
弱性アセスメントの実施にも当てはまります。ツールには、オペレーティングシステムやアプリケーション
に固有ものや、(使用されるプロトコルに基づいて) ネットワークに固有のツールもあります。ツールには無
料のものもあれば、そうでないものもあり、直感的で使いやすいツールもあれば、難解で適切に文書化され
てはいないものの、他のツールにはない機能を持つツールもあります。
適切なツールを見つけることは困難なタスクとなる場合もあり、最終的には経験が重要になります。可能で
あれば、実験ラボをセットアップし、各ツールの長所と短所を発見できるようできる限り多くのツールをテ
ストするようにします。ツールの README ファイルや man ページも確認してください。さらに、イン
ターネットからツールについての記事やステップバイステップのガイドまたはツール固有のメーリングリス
トなどの詳細情報を入手してください。
以下で説明するツールは、利用可能なツールのごくわずかなサンプルです。
1.3.3.1. Nmap を使用したホストのスキャン
Nmap はネットワークのレイアウトを決定するためによく使用されるツールです。
Nmap は長年にわ
たって利用されており、情報収集を行う際におそらく最もよく使われるツールです。各種のオプションと使
用法を詳述した優れたマニュアルページが含まれています。管理者は、ネットワーク上で Nmap を使用
し、ホストシステムやそれらのシステム上で開かれているポートを見つけることができます。
Nmap は、脆弱性アセスメントにおける最初の有効なステップです。ネットワーク内にあるすべてのホス
トのマッピングができるほか、Nmap が特定ホスト上で実行中のオペレーティングシステムを特定できる
ようにするオプションを渡すこともできます。Nmap はセキュアなサービスの使用と不必要なサービスの
停止についての方針を定める際の優れた土台を提供します。
Nmap をインストールするには、root で yum install nmap コマンドを実行します。
1.3.3.1.1. Nmap の使用
Nmap を実行するには、シェルプロンプトに nmap コマンドを入力し、その後にスキャン対象のマシンの

ホスト名または IP アドレスを入力します。
nmap <hostname>
例えば、ホスト名が foo.example.com のマシンをスキャンするには、シェルプロンプトに以下を入力

します。
~]$ nmap foo.example.com
基本的なスキャン (ホストの位置や他のネットワーク条件によって数分の時間がかかる場合があります) の
結果は以下のようになります。
Interesting ports on foo.example.com:

Not shown: 1710 filtered ports
PORT STATE SERVICE
22/tcp open ssh
6
53/tcp open domain

80/tcp open http
113/tcp closed auth
Nmap はリッスンしているまたはサービスを待機している最も一般的なネットワーク通信ポートをテスト
します。テストから得られる情報は、不必要または未使用のサービスの終了を希望している管理者にとって
役に立つものです。
Nmap の使用法に関する詳細情報は、以下の URL にある公式ホームページを参照してください。
http://www.ins e cure .org/
1.3.3.2. Nessus
Nessus は完全サービス型のセキュリティスキャナーです。Nessus のプラグインアーキテクチャーを

使うと、ユーザーは使用しているシステムやネットワーク用にスキャナーをカスタマイズすることができま
す。他のスキャナーと同様に、Nessus の性能はベースとなる署名データベースに左右されます。幸いな
ことに Nessus の更新は頻繁に行われており、完全なレポート作成機能やホストスキャンおよびリアルタ
イムの脆弱性検索機能があります。しかし、Nessus のように頻繁に更新される強力なツールであって
も、誤検出や検出漏れの可能性があることに注意してください。
注記
Nessus クライアントおよびサーバーソフトウェアを使用するには、サブスクリプションが必要で
す。本ガイドでは、このアプリケーションに関心のあるユーザー向けに参考情報として説明していま
す。
Nessus に関する詳細は、以下の URL にある公式 We b サイトを参照してください。
http://www.ne s s us .org/
1.3.3.3. OpenVAS
OpenVAS (Open Vulnerability Assessment System) は、脆弱性および包括的な脆弱性管理のスキャ

ンに使用可能なツールおよびサービスのセットです。OpenVAS フレームワークでは、ソリューションの
様々なコンポーネントを制御するウェブベース、デスクトップ、およびコマンドラインツールが多く提供さ
れます。OpenVAS の中心となる機能は、セキュリティスキャナーが提供します。これは、毎日更新され
る 3 万 3 千以上の Ne twork Vulne rability Te s ts (NVT) を活用します。Nessus (「Ne s s us 」を参
照) とは異なり、OpenVAS はサブスクリプションが必要ありません。
Ope nVAS に関する詳細は、以下の URL にある公式 We b サイトを参照してください。
http://www.ope nvas .org/
1.3.3.4. Nikt o
Nikt o は、優れた共通ゲートウェイインターフェース (CGI) のスクリプトスキャナーです。Nikt o は、

CGI の脆弱性をチェックするだけでなく、侵入検知システムを逃れるために回避的な方法でチェックを行
います。Nikto には詳細の資料が同梱されており、プログラムの実行前に注意して確認してくださ
い。Nikt o は、CGI スクリプトに対応する We b サーバーのセキュリティをチェックする優れたリソース
になります。
Nikt o の詳細については、以下の URL を参照してください。
http://cirt.ne t/nikto2
7
1.4. セキュリティへの脅威
1.4.1. ネットワークセキュリティへの脅威
ネットワークの以下の要素を設定する際に不適当なプラクティスが行われると、攻撃のリスクが増大しま
す。
セキュリティが十分ではないアーキテクチャー
間違った構成のネットワークは、未承認ユーザーの主要のエントリーポイントになります。信頼ベースの
オープンなローカルネットワークを安全性の非常に低いインターネットに対して無防備な状態にしておくこ
とは、犯罪の多発地区でドアを半開きにしておくようなものです。すぐに何かが起きることはないかもしれ
ませんが、いずれ誰かがこの機会を悪用するでしょう。
ブロードキャストネットワーク
システム管理者は、セキュリティ計画においてネットワーキングハードウェアの重要性を見落としがちで
す。ハブやルーターなどの単純なハードウェアは、ブロードキャストやノンスイッチの仕組みに基づいてい
ます。つまり、あるノードがネットワークを介して受信ノードにデータを送信するときは常に、受信ノード
が受信してデータを処理するまで、ハブやルーターはデータパケットのブロードキャストを送信します。こ
の方式は、外部侵入者やローカルホスト上の認証されていないユーザーが仕掛けるアドレス解決プロトコル
(ARP) およびメディアアクセスコントロール (MAC) アドレスの偽装に対して最も脆弱です。
集中化サーバー
ネットワーキングのもうひとつの落とし穴は、集中化されたコンピューティングの使用にあります。多くの
企業では、一般的なコスト削減手段として、すべてのサービスを 1 台の強力なマシンに統合しています。
集中化は、複数サーバーの設定よりも管理がより簡単な上、コストを大幅に削減できるので便利な手段と言
えます。しかし、集中化されたサーバーはネットワークにおける単一障害点となるため、集中化サーバーが
攻撃されると、ネットワークは完全に使えなくなるか、またはデータの不正操作や盗難が起きやすくなる可
能性があります。こうした状況では、1 つの集中化サーバーが侵入口となり、ネットワーク全体へのアクセ
スを許してしまうことになります。
1.4.2. サーバーセキュリティへの脅威
サーバーには組織の重要情報が数多く含まれることが多いため、サーバーのセキュリティはネットワークの
セキュリティと同様に重要です。サーバーが攻撃されると、クラッカーがすべてのコンテンツを意のままに
盗んだり、不正に操作したりできるようになることがあります。以下のセクションでは、主要な問題のいく
つかを詳述します。
未使用のサービスと開かれたポート
Re d Hat Ente rpris e Linux 7 を完全にインストールすると、1000 以上のアプリケーションとライブラ

リのパッケージが含まれます。しかし、ほとんどのサーバー管理者はディストリビューションに含まれる
すべての個別パッケージをインストールすることはありません。その代わりに、複数のサーバーアプリケー
ションを含むパッケージのベースインストールを行います。インストールするパッケージ数を制限する理由
および追加するリソースについての詳細は、「必要なパッケージの最小限のインストール」を参照してくだ
さい。
システム管理者は、どのアプリケーションがインストールに含まれるかを気にせずにオペレーティングシス
テムをインストールしてしまうことがよくあります。必要のないパッケージがインストールされ、デフォル
ト設定でオンにしてしまうと、これが問題になる場合があります。これにより、管理者の気付かないところ
で、Te lne t や DHCP、または DNS などの不要なサービスがサーバーやワークステーションで実行され、
8
その結果、サーバーへの不要なトラフィックが発生したり、クラッカーにシステムへのパスが提供される可
能性があります。ポートを閉じる方法や未使用のサービスを無効にする方法についての詳細は、「サービス
のセキュア化」を参照してください。
パッチが適用されないサービス
デフォルトのインストールに含まれるほとんどのサーバーアプリケーションは、ソフトウェアの細部まで徹
底的にテストされており、堅牢な作りになっています。何年も実稼働環境で使用される中で、それらのコー
ドは入念に改良され、数多くのバグの発見や修正が行われるものです。
しかし、完璧なソフトウェアというものはなく、常に改良の余地があるものです。さらに、比較的に新しい
ソフトウェアは実稼働環境に最近導入されたか、または他のサーバーソフトウェアほど普及していない場合
が多くあり、厳密なテストが期待通りに行われていない状況も多く見受けられます。
開発者やシステム管理者は、サーバーアプリケーションで悪用される可能性のあるバグを発見することが多
くあり、関連する情報を Bugtraq メーリングリスト (http://www.s e curityfocus .com) や Compute r
Eme rge ncy Re s pons e Te am (CERT) We b サイト (http://www.ce rt.org) などの、バグ追跡やセキュ
リティ関連の We b サイトに公開します。これらはセキュリティの脆弱性についてコミュニティに警告す
る効果的な方法ではありますが、システムに速やかにパッチを当てるかどうかは個々のシステム管理者次第
となります。クラッカーも同じ脆弱性トラッキングサービスにアクセスし、可能な場合にはいつでもパッチ
が適用されていないシステムをクラッキングするために関連情報を利用できることを考慮すると、速やかな
対応がとりわけ重要になります。優れたシステム管理には、よりセキュアなコンピューティング環境を確保
するために、警戒を怠らず、バグ追跡を絶えず行い、適切なシステム保守を実行することが求められます。
システムを最新状態に維持する方法についての詳細は、3章システムを最新の状態に保つを参照してくださ
い。
管理における不注意
システムにパッチを当てようとしない管理者は、サーバーセキュリティへの最大の脅威の 1 つとなりま
す。SysAdmin, Audit, Network, Security Institute (SANS) によると、コンピューターのセキュリティ
脆弱性の主な原因は、「訓練を受けていない人にセキュリティの保守を任せ、保守を行うために必要な訓練
や時間を与えないこと」にあります。これは、自信過剰な管理者やモチベーションの高い管理者だけではな
く、経験の少ない管理者にも起こり得ます。
サーバーやワークステーションにパッチを当てない管理者のほかに、システムのカーネルやネットワーク通
信からのログメッセージを見落とす管理者もいます。またよく起こるエラーとして、サービスのデフォルト
パスワードやキーを変更しないまま放置しておくことがあります。例えば、データベースにはデフォルトの
管理パスワードが設定されているものがありますが、この設定では、システム管理者がインストール後すぐ
にデフォルトパスワードを変更することをデータベース開発者が想定しています。しかし、データベース管
理者がこのパスワードの変更を忘れると、経験の浅いクラッカーでさえ、周知のデフォルトパスワードを
使ってデータベースの管理者権限を得ることができます。これらは、管理者の不注意がサーバーを危険にさ
らすことになる数例に過ぎません。
本質的に安全ではないサービス
どんなに注意深い組織であっても、選択するネットワークサービスが本質的に安全でない限り、攻撃を受け
やすくなります。例えば、多くのサービスは、信頼できるネットワークで使用されるとの仮定に基づいて開
発されますが、これらのサービスが (本質的に信頼できない) インターネット上で利用可能になる時点で、
この仮定は成立しなくなります。
安全ではないネットワークサービスのカテゴリの 1 つに、暗号化されていないユーザー名とパスワードを
認証時に要求するサービスがあります。Te lne t や FTP がこの種のサービスです。パケット盗聴ソフト
ウェアがリモートユーザーとこのようなサービス間のトラフィックをモニタリングしていれば、ユーザー名
とパスワードは簡単に傍受される可能性があります。
また、基本的にこのようなサービスはセキュリティ業界で中間者攻撃と呼ばれる攻撃の餌食になりやすくな
9
ります。この種の攻撃では、クラッカーは、ネットワーク上のクラッキングされたネームサーバーをだま
し、目標のサービスではなくクラッカーのマシンにポイントすることで、ネットワークトラフィックをリダ
イレクトします。誰かがサーバーへリモートセッションを開くと、攻撃者のマシンがリモートサービスと無
防備なユーザー間に静かに存在する目に見えないパイプとして機能し、この間を流れる情報を取り込みま
す。このようにして、クラッカーはサーバーやユーザーに気付かれることなく、管理パスワードや生データ
を収集できるようになってしまいます。
安全ではないサービスの別のカテゴリは、NFS または NIS などのネットワークファイルシステムと情報

サービスです。これらは、LAN 利用を目的として開発されましたが、残念なことに (リモートユーザー用
の) WAN も対象に含まれるように拡張されました。NFS では、クラッカーによる NFS 共有のマウントや
そこに格納されているものへのアクセスを防ぐ認証やセキュリティの仕組みがデフォルトで設定されていま
せん。NIS も、プレーンテキスト ASCII または DBM (ASCII から派生) データベースの中に、パスワード
やファイルパーミッションなどの、ネットワーク上のすべてのコンピューターに知らせる必要のある重要
な情報を保持しています。クラッカーがこのデータベースのアクセス権を取得すると、管理者のアカウント
を含む、ネットワーク上のすべてのユーザーアカウントにアクセスできるようになってしまいます。
Re d Hat Ente rpris e Linux 7 は、上記のサービスをデフォルト時にすべて無効にしてリリースされま

す。しかし、管理者はこれらのサービスの使用を迫られる場合も多くあるため、注意して設定することが重
要になります。安全な方法でサービスをセットアップする詳細情報は、「サービスのセキュア化」を参照し
てください。
1.4.3. ワークステーションおよび家庭用 PC のセキュリティに対する脅威
ワークステーションや家庭用 PC はネットワークやサーバーほど攻撃にさらされることはないかもしれませ
んが、クレジットカード情報のような機密データが含まれるのでシステムクラッカーの標的になります。
ワークステーションは知らぬ間に攻撃者によって「スレーブ」マシンとして引き入れられ、一連の攻撃で攻
撃者に使用される可能性もあります。このため、ユーザーはワークステーションの脆弱性を理解しておく
と、オペレーティングシステムの再インストールや、深刻な場合はデータ盗難からの回復といった問題から
免れることができます。
不適切なパスワード
不適切なパスワードを設定すると、システムにアクセスする最も簡単な方法を攻撃者に提供してしまいま
す。パスワードを作成する際のよくある落とし穴を避ける方法については、「パスワードのセキュリ
ティ」を参照してください。
脆弱なクライアントアプリケーション
管理者がサーバーに十分な安全対策を施し、パッチを当てている場合でも、リモートユーザーによるアクセ
スが安全であるわけではありません。例えば、サーバーが公開ネットワーク上で Te lne t や FTP サービス
を提供している場合、攻撃者はネットワークを通過するプレーンテキストのユーザー名とパスワードを取り
込み、アカウント情報を使用してリモートユーザーのワークステーションにアクセスすることが可能です。
SSH などのセキュアなプロトコルを使用している場合であっても、クライアントアプリケーションを定期
的に更新していないと、リモートユーザーは特定の攻撃を受けやすくなる可能性があります。例えば、v.1
SSH クライアントは、悪意のある SSH サーバーからの X 転送攻撃に対して脆弱です。クライアントが
サーバーに接続すると、攻撃者はネットワーク上でクライアントによるキー入力やマウス操作をひそかに収
集できます。この問題は v.2 SSH プロトコルで修正されましたが、ユーザーはどのアプリケーションにこ
のような脆弱性があるかを追跡し、必要に応じてアプリケーションを更新する必要があります。
「デスクトップのセキュリティ」では、管理者とホームユーザーがコンピューターのワークステーション
の脆弱性を限定するために取るべき手順をより詳細に説明しています。
1.5. 一般的な不正使用と攻撃
10
表1.1「一般的な不正使用」では、侵入者が組織のネットワークリソースにアクセスするために使用する最
も一般的な不正使用とエントリーポイントのいくつかについて詳しく説明しています。これらの一般的な不
正使用については、それらがどのように実行され、管理者がそれらの攻撃からネットワークをどのように適
切に保護できるかを理解していることが重要になります。
表1.1 一般的な不正使用
不正使用説明注意事項
空またはデフォル管理パスワードを空白のままにしたり、ルーター、ファイアウォール、VPN お
トのパスワード製品ベンダーが設定したデフォルトパスよび Ne twork Attache d Storage
ワードをそのまま使用します。ルーター (NAS) アプライアンスなどのネットワー
やファイアウォールなどのハードウェアクハードウェアに一般的に関連するもの
で最もよく見られますが、Linux で実行です。
するサービスにはデフォルトの管理者パ
スワードが入っているものがあります数多くのレガシーオペレーティングシス
（ただし Re d Hat テム、特にサービスをバンドルしたオペ
Ente rpris e Linux 7 はパスワードなしレーティングシステム (UNIX や
で出荷されます)。 Windows など) によくあります。
管理者が急いで特権ユーザーアカウント
を作成したためにパスワードが空白のま
まになっていることがありますが、これ
は、このアカウントを発見した悪意のあ
るユーザーにとっては、絶好のエント
リーポイントとなります。
デフォルトの共有セキュアなサービスでは、開発や評価テ無線アクセスポイントや事前設定済みの

鍵スト用にデフォルトのセキュリティ鍵がセキュアなサーバー機器に最も多く見ら
パッケージ化されていることがありまれます。
す。これらの鍵を変更せずにインター
ネット上の実稼働環境に置いた場合、同
じデフォルトの鍵を持つすべてのユー
ザーがその共有鍵のリソースや、そこに
あるすべての機密情報にアクセスできる
ようになります。
IP スプーフィングリモートマシンがローカルネットワークスプーフィングは、攻撃者が標的となる
上でノードとして動作し、サーバーに脆システムへの接続を調整するのに
弱性を見つけるとバックドアプログラム TCP/IP シーケンス番号を予測しなけれ
またはトロイの木馬をインストールしばならないのでかなり難しいことです
て、ネットワークリソース全体へのコンが、クラッカーの脆弱性の攻撃を支援す
トロールを得ようとします。る利用可能なツールがいくつかありま
す。
標的となるシステムで実行される、ソー
スベース認証技術を使用するサービス
(rsh、 telnet、FTP その他) によっ
て異なりますが、このようなサービス
は、ssh または SSL/TLS で使用される
PKI やその他の形式の暗証化認証と比較
すると推奨できるものではありません。
11
盗聴 2 つのノード間の接続を盗聴することにこの種類の攻撃には大抵、Te lne t、
より、ネットワーク上のアクティブな FTP、および HTTP 転送などのプレーン
ノード間を行き交うデータを収集しまテキストの転送プロトコルが使われま
す。す。
このような攻撃を仕掛けるには、リモー
トの攻撃者は LAN 上で攻撃するシステ
ムへのアクセス権を持っていなければな
りません。通常、クラッカーは LAN 上
にあるシステムを危険にさらすために活
発な攻撃（IP スプーフィングや中間者攻
撃など) を仕掛けます。
パスワードのなりすましを防ぐ予防策と
しては、暗号化鍵交換、ワンタイムパス
ワードまたは暗号化された認証による
サービス使用が挙げられます。通信中は
強力な暗号化を実施することをお勧めし
ます。
サービスの脆弱性攻撃者はインターネット上で実行されて CGI などの HTTP ベースのサービス

いるサービスの欠陥や抜け穴を見つけまは、リモートのコマンド実行やインタラ
す。この脆弱性を利用する攻撃者は、シクティブなシェルアクセスに対しても脆
ステム全体と格納されているデータを攻弱です。HTTP サービスが「nobody」
撃するだけでなく、ネットワーク上の他などの権限のないユーザーとして実行さ
のシステムも攻撃する可能性がありまれる場合でも、設定ファイルやネット
す。ワークマップなどの情報が読み取られる
可能性があります。または、攻撃者が
サービス拒否攻撃を開始して、システム
のリソースを流出させたり、他のユー
ザーが利用できないようにする可能性も
あります。
開発時およびテスト時には気付かない脆
弱性がサービスに含まれることがありま
す。このような脆弱性 (攻撃者が任意の
値を使用してアプリケーションのメモ
リーバッファー領域をあふれさせ、攻撃
者が任意のコマンドを実行できるような
インタラクティブなコマンドプロンプト
を与えて、サービスをクラッシュさせ
るバッファーオーバーフローなど）は完
全な管理コントロールを攻撃者に与える
ものとなる可能性があります。
管理者は、サービスが root ユーザーと

して実行されないようにし、ベンダーま
たは CERT や CVE などのセキュリティ
組織からのアプリケーション用のパッチ
やエラータ更新がないか常に注意する必
要があります。
12
アプリケーション攻撃者はデスクトップやワークステーワークステーションとデスクトップは、
の脆弱性ションのアプリケーション（電子メールユーザーが侵害を防いだり検知するため
クライアントなど）に欠陥を見つけ出の専門知識や経験を持たないため、不正
し、任意のコードを実行したり、将来の使用の対象になりやすくなります。認証
システム侵害のためにトロイの木馬を移されていないソフトウェアをインストー
植したり、システムを破壊したりしまルしたり、要求していないメールの添付
す。攻撃を受けたワークステーションがファイルを開く際には、それに伴うリス
ネットワークの残りの部分に対して管理クについて個々に通知することが必須で
特権を持っている場合は、さらなる不正す。
使用が起こる可能性があります。
電子メールクライアントソフトウェアが
添付ファイルを自動的に開いたり、実行
したりしないようにするといった、予防
手段を取ることが可能です。さらに、
Re d Hat Ne twork や他のシステム管理
サービスなどからワークステーションの
ソフトウェアを自動更新することによ
り、マルチシートのセキュリティデプロ
イメントの負担を軽減することができま
す。
サービス拒否攻撃単独の攻撃者または攻撃者のグループ 2000 年に発生した米国内での DoS で

(DoS: De nial of は、目標のホスト（サーバー、ルー最も多く報告されたケースとして、通信
Se rvice ) ター、ワークステーションのいずれか）量の非常に多い民間および政府サイトの
に認証されていないパケットを送ることいくつかが利用不可能になりました。ゾ
により、組織のネットワークまたはサーンビ (zombie) やリダイレクトされたブ
バーのリソースに対して攻撃を仕掛けまロードキャストノードとして動作する、
す。これにより、正当なユーザーはリ高帯域幅接続を有する複数の攻撃対象の
ソースを使用できなくなります。システムを使って、調整された ping フ
ラッド攻撃が行われたためです。
通常ソースパケットは、攻撃の本当のも
とを調査するのが難しくなるよう、偽装
(または再ブロードキャスト）されてい
ます。
iptables を使用したイングレスフィ
ルタリング (IETF rfc2267) や snort
などのネットワーク侵入検知システムに
おける進歩は、管理者が分散型サービス
拒否攻撃を追跡し、これを防止するのに
役立っています。
13
第2章インストール時におけるセキュリティのヒント
セキュリティは、Re d Hat Ente rpris e Linux 7 をインストールするために CD や DVD をディスクドラ
イブに入れた時から始まります。最初からシステムを安全に設定することで、追加のセキュリティ設定を後
で実装することがより簡単になります。
2.1. BIOS のセキュア化
BIOS (もしくは BIOS に相当するもの) およびブートローダーのパスワード保護により、システムに物理的

にアクセス可能な未承認ユーザーがリムーバブルメディアを使って起動したり、シングルユーザーモードで
root 権限を取得したりすることを防ぐことができます。このような攻撃に対するセキュリティ対策は、
ワークステーション上の情報の機密性とマシンの場所によって異なります。
例えば、マシンが見本市で使われていて機密情報を含んでいない場合、このような攻撃を防ぐことは重要で
はないかもしれません。しかし、同じ見本市で企業ネットワーク用のプライベートの暗号化されていない
SSH 鍵のあるノートパソコンが誰の監視下にもなく置かれていた場合、重大なセキュリティ侵害につなが
り、その影響は企業全体に及ぶ可能性があります。
ただし、ワークステーションが権限のあるユーザーもしくは信頼できるユーザーのみがアクセスできる場所
に置かれてるのであれば、BIOS もしくはブートローダーの安全確保は必要ない可能性もあります。
2.1.1. BIOS パスワード
コンピューターの BIOS をパスワードで保護する主な理由は、以下の 2 つです ⁠ [1] 。
1. BIOS 設定の変更を防止する — 侵入者が BIOS にアクセスした場合、CD-ROM やフラッシュド

ライブから起動するように設定できます。このようにすると、侵入者がレスキューモードやシング
ルユーザーモードに入ることが可能になり、システム上で任意のプロセスを開始したり、機密性の
高いデータをコピーできるようになってしまいます。
2. システムの起動を防ぐ — BIOS の中には起動プロセスをパスワードで保護できるものもあります。

これを有効にすると、攻撃者は BIOS がブートローダーを開始する前にパスワード入力を求められ
ます。
BIOS パスワードの設定方法はコンピューターメーカーで異なるため、具体的な方法についてはコンピュー
ターのマニュアルを参照してください。
BIOS パスワードを忘れた場合は、マザーボード上のジャンパーでリセットするか、CMOS バッテリーを

外します。このため、可能な場合はコンピューターのケースをロックすることがよい方法です。ただし、
CMOS バッテリーを外す前にコンピューターもしくはマザーボードのマニュアルを参照してください。
2.1.1.1. 非 BIOS ベースのシステム
他のシステムやアーキテクチャーでは、異なるプログラムを使用して x86 システム上の BIOS とほぼ同等

の低レベルのタスクを実行します。Unified Extensible Firmware Interface (UEFI) シェルなどがこの例
になります。
BIOS と同様のプログラムをパスワード保護する方法については、メーカーの指示を参照してください。
2.2. ディスクのパーティション設定
Re d Hat では、/boot、/、/tmp および /var/tmp のそれぞれに個別のパーティションを作成すること

を推奨しています。各パーティションの目的はそれぞれに異なり、これについて説明していきます。
14
⁠第2章インストール時におけるセキュリティのヒント
/boot
このパーティションは、ブート時にシステムが最初に読み込むパーティションです。システムを
Re d Hat Ente rpris e Linux 7 にブートするために使われるブートローダーとカーネルイメージ
はこのパーティションに保存されます。このパーティションは暗号化すべきではありません。こ
のパーティションが / に含まれていて、そのパーティションが暗号化されているかまたは他の理
由で利用できなくなると、システムをブートすることができなくなります。
/home
ユーザーデータ (/home) が別個のパーティションではなく / に保存されていると、このパー

ティションが一杯になり、オペレーティングシステムが不安定になる可能性があります。また、
システムを次のバージョンの Re d Hat Ente rpris e Linux 7 にアップグレードする際に
は、/home パーティションでデータを保存できると、このデータはインストール時に上書きされ
ないので、アップグレードが非常に簡単になります。root パーティション (/) が破損すると、
ユーザーのデータは完全に失われてしまいます。個別のパーティションを使うことで、データ損
失に対する保護が少しは高まります。また、このパーティションを頻繁にバックアップする対象
とすることも可能です。
/tmp および /var/tmp
/tmp と /var/tmp ディレクトリーは、どちらも長期保存の必要がないデータを保存するため

に使われます。しかし、これらのディレクトリーのいずれかが多くのデータであふれると、スト
レージスペースがすべて消費されてしまう可能性があります。こうした状態が発生して、かつこ
れらのディレクトリーが / に保管されていると、システムが不安定になり、クラッシュする可能
性があります。そのため、これらのディレクトリーを個別のパーティションに移動するとよいで
しょう。
注記
インストールのプロセス中には、パーティションを暗号化するオプションがユーザーに示されま
す。ユーザーは、パスフレーズを提供する必要があります。これは、パーティションのデータを保
護するために使われるバルク暗号鍵を解除する鍵として使用されます。LUKS についての詳細情報
は、「LUKS のディスク暗号化の使用」を参照してください。
2.3. 必要なパッケージの最小限のインストール
コンピューター上の各ソフトウェアには脆弱性が潜んでいる可能性があるので、実際に使用するパッケージ
のみをインストールすることがベストプラクティスになります。インストールを DVD から行う場合は、イ
ンストールしたいパッケージのみを選択するようにします。他のパッケージが必要になる場合は、いつでも
後でシステムに追加することができます。
最小限のインストール環境に関する詳細情報は、Re d Hat Ente rpris e Linux 7 インストールガイドの

ソフトウェアの選択の章を参照してください。最小限のインストールは、Kicks tart ファイルで--
nobase オプションを使用して実行することもできます。Kicks tart インストールについての詳細情報は、
Re d Hat Ente rpris e Linux 7 インストールガイドのパッケージの選択のセクションを参照してくださ
い。
2.4. インストール後の手順
以下のステップは、Re d Hat Ente rpris e Linux のインストール直後に実行する必要のあるセキュリティ

関連の手順です。
15
1. システムを更新します。root で以下のコマンドを実行します。
~]# yum update
2. ファイアウォールサービスの firewalld は Re d Hat Ente rpris e Linux のインストールで自動

的に有効になっていますが、kicks tart 設定などで明示的に無効となっている場合もあります。こ
のような場合は、ファイアウォールを再度有効にすることが推奨されます。
firewalld を開始するには、root で以下のコマンドを実行します。
~]# systemctl start firewalld

~]# systemctl enable firewalld
3. セキュリティを強化するために、不要なサービスは無効にしてください。たとえば、使用中のコン
ピューターにプリンターがインストールされていなければ、以下のコマンドを使って cups サービ
スを無効にします。
~]# systemctl disable cups
アクティブなサービスを見直すには、以下のコマンドを実行します。
~]$ systemctl list-units | grep service
2.5. その他のリソース
インストールに関する全般的な情報は、Re d Hat Ente rpris e Linux 7 インストールガイドを参照してく

ださい。
[1] 。システム BIO S はメーカーによって異なるため、パスワード保護をサポートしないものもあれば、あるタイプ

のパスワード保護のみをサポートするものもあります。
16
⁠第3章システムを最新の状態に保つ
第3章システムを最新の状態に保つ
本章では、システムを最新の状態に保つプロセスについて説明します。セキュリティ更新のインストール方
法の立案や設定、新たに更新されたパッケージが導入する変更の適用、Re d Hat カスタマーポータルを利
用したセキュリティアドバイザリーの追跡などが関連してきます。
3.1. インストール済みソフトウェアのメンテナンス
セキュリティの脆弱性が発見された場合、セキュリティ上のリスクを最小限に抑えるために、影響を受け
るソフトウェアを更新する必要があります。そのソフトウェアが現在サポートされている Re d Hat
Ente rpris e Linux ディストリビューション内のパッケージの一部である場合、Re d Hat は脆弱性を修正
する更新パッケージをできるだけ迅速にリリースするように全力を尽くします。
多くの場合、セキュリティ上の特定の不正使用に関する発表にはパッチ (または問題を解決するソースコー
ド) が伴われています。このパッチは Re d Hat Ente rpris e Linux パッケージに適用されます。パッチは
テストされ、エラータ更新としてリリースされるものです。しかし、発表にパッチが含まれていない場合に
は、Re d Hat の開発者はまず、問題の解決に向けてそのソフトウェアの保守担当者と協力します。問題が
解決されると、パッケージがテストされ、エラータ更新としてリリースされます。
システムで使用しているソフトウェアのエラータ更新がリリースされている場合、システムが攻撃される可
能性のある期間を最短にするため、影響を受けるパッケージをできる限り早く更新することが強く推奨され
ます。
3.1.1. セキュリティの更新の立案と設定
すべてのソフトウェアにはバグが含まれます。これらのバグは、悪意のあるユーザーにシステムをさらして
しまう可能性のある脆弱性につながりかねません。更新されていないパッケージは、コンピューターへの侵
入を招く一般的な原因となります。脆弱性の悪用を防ぐには、セキュリティパッチをタイミングよくインス
トールする計画を実行して、発見された脆弱性をすばやく排除してください。
セキュリティ更新が利用可能になったらそれらをテストして、インストールするスケジュールを立てま
す。更新のリリースからシステムにインストールするまでの間、システムを保護するための新たな制御が必
要になります。これらの制御は脆弱性の内容によって異なりますが、ファイアウォールの追加ルールや、外
部ファイアウォールの使用、またはソフトウェア設定の変更などがこれらに含まれることがあります。
サポート対象のパッケージ内のバグは、エラーのメカニズムを使用して修正されます。エラータは、1 つ以
上の RPMパッケージとそのエラータが対処する問題の簡単な説明で構成されています。エラータはすべ
て、アクティブなサブスクリプションを持つお客様に Red Hat サブスクリプション管理サービスで配布
されます。セキュリティ問題に対処するエラータは、Red Hat セキュリティアドバイザリーと呼ばれま
す。
セキュリティエラータを使った作業についての詳細情報は、「カスタマーポータルでセキュリティ更新を
見る」を参照してください。RHN Classic からの移行を含む Red Hat サブスクリプション管理サー
ビスについての詳細情報は、Re d Hat サブスクリプション管理にある関連ドキュメントを参照してくださ
い。
3.1.1.1. Yum のセキュリティ機能の使用
Yum パッケージマネジャーには、セキュリティエラータの検索、一覧、表示、インストールに使用可能な
セキュリティ関連の機能がいくつか含まれています。これらの機能を使うと、Yum を使ってセキュリティ
更新のみをインストールすることもできます。
使用中のシステムで利用可能なセキュリティ関連の更新を確認するには、root で以下のコマンドを実行し
ます。
17
~]# yum check-update --security

Loaded plugins: langpacks, product-id, subscription-manager
rhel-7-workstation-rpms/x86_64 | 3.4 kB 00:00:00
No packages needed for security; 0 packages available
上記のコマンドは非対話モードで実行されるので、更新が利用可能かどうかの自動確認のスクリプトに使用
することができます。このコマンドは、利用可能なセキュリティ更新がある場合には 100 を返し、更新が
ない場合には 0 を返します。エラーが発生すると、1 が返されます。
同様に、以下のコマンドを使用するとセキュリティ関連の更新のみがインストールされます。
~]# yum update --security
updateinfo サブコマンドを使うと、リポジトリーが提供する利用可能な更新についての情報を表示した
り、それについてアクションを取ることができます。この updateinfo サブコマンド自体は、多くのコマ
ンドを受け付け、この中にはセキュリティ関連の使用も含まれます。これらのコマンドの概要について
は、表3.1「yum update info で使用可能なセキュリティ関連のコマンド」を参照してください。
表3.1 yum updat einf o で使用可能なセキュリティ関連のコマンド
コマンド説明
advisory [advisories] 1 つ以上のアドバイザリーについての情報を表示します。advisory を
アドバイザリー番号で置き換えます。
cves CVE (Common Vulnerabilities and Exposures) に関連する情報の
サブセットを表示します。
security または sec セキュリティ関連の情報をすべて表示します。
severity または sev 提供された severity_level のセキュリティ関連パッケージについての
severity_level 情報を表示します。
3.1.2. パッケージの更新とインストール
システムのソフトウェアを更新する際には、信頼できるソースから更新をダウンロードすることが重要で
す。攻撃者は、問題を解決するはずのバージョンと同じバージョン番号のパッケージを簡単に再構築し、そ
のパッケージからセキュリティ上の別の不正使用を可能にした上で、それをインターネット上にリリース
する場合があります。こうした事態が発生すると、元の RPM に対するファイル検証などのセキュリティ対
策を講じても、不正アクセスを検知することができません。このため、RPM は Re d Hat などの信頼できる
ソールからのみダウンロードし、その保全性を検証するためにパッケージの署名を確認することが極めて重
要になります。
Yum パッケージマネジャーの使用方法に関する詳細情報は、Re d Hat Ente rpris e Linux 7 システム管

理者のガイドの Yum の章を参照してください。
3.1.2.1. 署名パッケージの検証
Re d Hat Ente rpris e Linux のパッケージはすべて、Re d Hat GPG 鍵を使って署名されていま

す。GPG は GNU Privacy Guard または GnuPG の略で、配信ファイルの信頼性を保証するために
使用されるフリーソフトウェアのパッケージです。パッケージ署名の検証が失敗すると、パッケージは改
ざんされている可能性があるので信頼できません。
Yum パッケージマネジャーを使うと、インストールまたはアップグレード対象の全パッケージの自動検証
ができます。この機能は、デフォルトで有効になっています。使用中のシステムでこのオプションを設定す
る場合は、/etc/yum.conf 設定ファイル内で gpgcheck 設定ディレクティブが 1 に設定されているこ
とを確認してください。
18
以下のコマンドを使用すると、ファイルシステム上のパッケージファイルを手動で検証できます。
rpmkeys --checksig package_file.rpm
Re d Hat パッケージの署名のプラクティスについての追加情報は、Re d Hat カスタマーポータルの Re d

Hat GPG キーの記事を参照してください。
3.1.2.2. 署名パッケージのインストール
ファイルシステムから検証済みのパッケージ (パッケージの検証方法については、「署名パッケージの検
証」を参照) をインストールするには、以下のように root で yum install コマンドを実行します。
yum install package_file.rpm
複数のパッケージを一度にインストールするには、シェル glob を使用します。たとえば、以下のコマンド

を実行すると、現行ディレクトリーにすべての .rpm パッケージがインストールされます。
yum install *.rpm
重要
セキュリティに関するエラータをインストールする前に、エラータレポートに記載されているすべ
ての特別な指示をよく読み、指示に従ってインストールしてください。エラータ更新に基づく変更の
適用についての全般的な指示は、「インストールされた更新による変更の適用」を参照してくださ
い。
3.1.3. インストールされた更新による変更の適用
セキュリティに関するエラータと更新をダウンロードしてインストールした後は、古いソフトウェアの使用
を中止して新しいソフトウェアの使用を開始することが重要です。これを実際に行う方法は、更新済みのソ
フトウェアの種類によって異なります。以下では、ソフトウェアの一般的なカテゴリを示し、パッケージ
のアップグレード後に更新バージョンを使用する方法について説明します。
注記
一般的に、システムの再起動は、ソフトウェアパッケージの最新バージョンが使用されていること
を確認する最も確実な方法です。ただし、このオプションは常に必要というわけではなく、システム
管理者が常に利用できるわけでもありません。
アプリケーション
ユーザースペースのアプリケーションとは、ユーザーが開始できるすべてのプログラムのことで
す。通常このようなアプリケーションは、ユーザー、スクリプトまたは自動化されたタスクユー
ティリティがそれらを起動する場合にのみ使用されるものです。
ユーザースペースのアプリケーションが更新されると、システムにあるアプリケーションのすべ
てのインスタンスが停止し、更新バージョンを使用するためにプログラムが再起動されます。
カーネル
19
カーネルは、Re d Hat Ente rpris e Linux 7 オペレーティングシステムの中心的なソフトウェア

コンポーネントです。カーネルはメモリー、プロセッサーおよび周辺機器へのアクセスを管理
し、すべてのタスクをスケジュールします。
カーネルは中心的な役割を担うので、カーネルの再起動にはコンピューターの再起動が伴いま
す。つまりカーネルの更新バージョンは、システムの再起動後に初めて使用できるようになりま
す。
KVM
qemu-kvm および libvirt のパッケージが更新されると、すべてのゲスト仮想マシンを停止し

て、関連の仮想化モジュールをリロードし (またはホストシステムを再起動し)、仮想マシンを再
起動する必要があります。
kvm、kvm-intel、または kvm-amd のどのモジュールが読み込まれているかを確認するに

は、lsmod コマンドを使用します。その後に modprove -r コマンドを使用して読み込まれて
いるモジュールを削除し、modprobe -a コマンドで影響を受けたモジュールをリロードしま
す。例を示します。
~]# lsmod | grep kvm

kvm_intel 143031 0
kvm 460181 1 kvm_intel
~]# modprobe -r kvm-intel
~]# modprobe -r kvm
~]# modprobe -a kvm kvm-intel
共有ライブラリ
共有ライブラリは、glibc のように、多くのアプリケーションやサービスにより使用されるコー
ドの集合です。通常、共有ライブラリを使用しているアプリケーションは、アプリケーションが
初期化される際に共有コードを読み込みます。そのため、更新されたライブラリを使用している
すべてのアプリケーションは、まず停止してから再起動する必要があります。
特定ライブラリにリンクしている実行中のアプリケーションを判別するには、以下の例のように
lsof コマンドを使用します。
lsof library
たとえば、libwrap.so ライブラリにリンクしている実行中のアプリケーションを判別するに
は、以下を入力します。
~]# lsof /lib64/libwrap.so.0

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
pulseaudi 12363 test mem REG 253,0 42520 34121785
/usr/lib64/libwrap.so.0.7.6
gnome-set 12365 test mem REG 253,0 42520 34121785
gnome-she 12454 test mem REG 253,0 42520 34121785
このコマンドは、ホストのアクセス制御に TCP Wrappe r を使用する実行中のプログラムの一覧

を返します。そのため tcp_wrappers パッケージが更新されると、リストにあるすべてのプログ
ラムは停止してから再起動する必要があります。
syst emd サービス
20
s ys te md サービスは、通常ブートプロセス中に開始される永続的なサーバープログラムです。
s ys te md サービスの例としては、sshd や vsftpd などがあります。
通常、これらのプログラムはマシンが起動している限りはメモリ内に残るので、パッケージの
アップグレード後には、更新された s ys te md サービスは停止してから再起動する必要がありま
す。これは、root で systemctl コマンドを使用すると実行できます。
systemctl restart service_name
service_name を sshd などの再起動するサービス名で置き換えます。
他のソフトウェア
以下のアプリケーションの更新は、リンク先のリソースで示された指示にしたがってください。
Red Hat Direct o ry Server —

https ://acce s s .re dhat.com/s ite /docume ntation/e n-
US/Re d_Hat_Dire ctory_Se rve r/ で該当する Re d Hat Dire ctory Se rve r バージョンの
『Re le as e Note s 』を参照してください。
Red Hat Ent erprise Virt ualizat io n Manager —

https ://acce s s .re dhat.com/s ite /docume ntation/e n-
US/Re d_Hat_Ente rpris e _Virtualiz ation/ で該当する Re d Hat
Ente rpris e Virtualiz ation のバージョンの『インストールガイド』を参照してください。
3.2. Red Hat カスタマーポータルの使用
Re d Hat カスタマーポータルは https ://acce s s .re dhat.com/ にあり、これは Re d Hat 製品に関する公

式情報のお客様向け主要リソースになります。ドキュメンテーションの検索やサブスクリプションの管理、
製品および更新のダウンロード、サポートケースの開始、セキュリティ更新についての情報収集などができ
ます。
3.2.1. カスタマーポータルでセキュリティ更新を見る
アクティブなサブスクリプションに関連するセキュリティアドバイザリー (エラータ) を見るに

は、https ://acce s s .re dhat.com/ でカスタマーポータルにログインして、メインページのDownload
Products & Updates ボタンをクリックします。Software & Download Center ページに入
り、Errata ボタンをクリックすると、登録済みシステムに関連するアドバイザリーが一覧表示されます。
アクティブな Re d Hat 全製品のセキュリティ更新をすべて表示するには、ページのトップにあるナビゲー

ションメニューを使ってセキュリティ → セキュリティアップデート → アクティブな製品に移動しま
す。
テーブルの左側にあるエラータコードをクリックすると、個別のアドバイザリーについての詳細情報が表示
されます。次のページには、特定のエラータの原因や結果、必要となる修正だけでなく、その特定のエラー
タが更新するパッケージ全一覧と更新の適用方法が示されています。このページには、関連する CVE など
の関連参照情報のリンクも含まれています。
3.2.2. カスタマーポータルページでの CVE への移動
CVE (Common Vulnerabilities and Exposures) プロジェクトは MITRE Corporation がメンテナンス

を行なっているもので、脆弱性とセキュリティエクスポージャーの標準名を一覧提供しています。
Re d Hat 製品に関連する CVE の一覧をカスタマーポータルで確認するに
は、https ://acce s s .re dhat.com/ でアカウントにログインして、ページトップにあるナビゲーションメ
ニューを利用してセキュリティ → リソース → CVE データベースに移動します。
21
テーブルの左側にある CVE コードをクリックすると、個別の脆弱性についての詳細情報が表示されます。

次のページには、特定の CVE 説明だけでなく、影響を受けている Re d Hat 製品の一覧と関連する
Re d Hat エラータのリンクが含まれています。
3.2.3. 問題の影響度の分類について
Re d Hat 製品で発見されたセキュリティ問題はすべて、Red Hat セキュリティレスポンスチームがその

問題の重大度に応じて影響度を割り当てます。これは、低、中、重要、重大の 4 段階評価で判断されま
す。これに加えて、セキュリティ問題はすべて Common Vulnerability Scoring System (CVSS) ベー
ススコアを使って評価されます。
これらを合わせると、セキュリティ問題の影響度が理解できます。そうすることで、使用中のシステムの
アップグレード戦略のスケジュールを立てたり、優先順位を決めたりすることができます。これらの評価は
特定の脆弱性の潜在的なリスクを反映するもので、現行の脅威レベルではなく、バグの技術的分析に基づい
ています。つまり、セキュリティの影響度評価は、特定の弱点に対してエクスプロイトがリリースされても
変更されません。
カスタマーポータルで影響度評価の個別レベルの詳細情報を確認するには、https ://acce s s .re dhat.com/

でアカウントにログインし、ページトップにあるナビゲーションメニューを利用してセキュリティ → ポ
リシー → 重大度のレベルに移動します。
セキュリティ更新やその適用方法、Re d Hat カスタマーポータル、および関連するトピックについての詳

細情報は、以下のリソースを参照してください。
インストールされているドキュメント
yum(8) — Yum パッケージマネジャーの man ページでは、Yum を使ってシステムにパッケージを

インストール、更新、削除する方法について説明しています。
rpmke ys (8) — rpmkeys ユーティリティーの man ページでは、このプログラムを使ってダウンロー

ドされたパッケージの信頼性を検証する方法について説明しています。
オンラインのドキュメント
Re d Hat Ente rpris e Linux 7 システム管理者のガイド — Re d Hat Ente rpris e Linux 7 の『シス
テム管理者のガイド』では、Yum および rpm プログラムを使って Re d Hat Ente rpris e Linux 7
システム上でパッケージをインストール、更新、削除する方法を説明しています。
Re d Hat Ente rpris e Linux 7 SELinux Us e r's and Adminis trator's Guide — Re d Hat
Ente rpris e Linux 7 の『SELinux Us e r's and Adminis trator's Guide 』では、SELinux
mandatory access control メカニズムの設定について説明しています。
Red Hat カスタマーポータル
Re d Hat カスタマーポータル — カスタマーポータルのメインページには、ポータルから入手可能な新

規コンテンツについての更新や最重要リソースへのリンクが含まれています。
セキュリティに関する連絡先および連絡方法 — Re d Hat セキュリティレスポンスチームについての情

報と、このチームに連絡すべき状況についての説明があります。
Re d Hat セキュリティブログ — Re d Hat セキュリティ専門家による最新のセキュリティ関連問題に

ついての記事です。
22
関連項目
2章インストール時におけるセキュリティのヒントでは、最初からシステムを安全に設定することで、
追加のセキュリティ設定を後で実装することがより簡単になることについて説明しています。
「GPG 鍵の作成」では、個人の GPG 鍵セットを作成し、通信を認証する方法について説明していま

す。
23
第4章ツールとサービスを使用したシステム強化
4.1. デスクトップのセキュリティ
パスワードは、Re d Hat Ente rpris e Linux 7 がユーザーの ID を確認する第一の手段です。ユーザーや

ワークステーション、ネットワークの保護にパスワードのセキュリティが重要であるのは、このためで
す。
インストールプログラムではセキュリティ目的で、システムがセキュアハッシュアルゴリズム 512

(SHA512) とシャドウパスワードを使うように設定します。この設定は、変更しないことが強く推奨され
ます。
インストール中にシャドウパスワードが検出されると、すべてのパスワードは全ユーザーが読み取り可能な
/etc/passwd ファイルに一方向のハッシュとして保存されます。この場合、システムはオフラインのパ
スワードクラッキング攻撃に脆弱なものとなってしまいます。侵入者が通常のユーザーとしてマシンにアク
セスすると、/etc/passwd ファイルを侵入者自身のマシンにコピーして、パスワードクラッキングプロ
グラムをいくつでも実行できるようになります。このファイルに安全でないパスワードがあれば、パスワー
ドクラッカーがこれを見つけるのは時間の問題となります。
シャドウパスワードは、パスワードハッシュを /etc/shadow ファイルに保存することで、このタイプの

攻撃を排除します。このファイルは、root ユーザーのみが読み取り可能なためです。
この場合、攻撃者は SSH や FTP などのマシン上のネットワークサービスにログインしてリモートからパ

スワードクラッキングを試みることが強いられます。このようなブルートフォース攻撃は時間がかかり、何
百回ものログイン失敗がシステムファイルに書き込まれるので、明らかな痕跡が残ります。もちろん、ク
ラッカーが脆弱なパスワードがあるシステムに真夜中から攻撃を開始した場合、夜明け前にはアクセスに成
功し、痕跡を隠すためにログファイルを編集してしまう、という可能性もあります。
フォーマットやストレージに加えて考慮すべき点は、コンテンツの問題です。パスワードクラッキングから
アカウントを保護するためにユーザーがなし得る最重要事項は、強固なパスワードを作成することです。
4.1.1. パスワードのセキュリティ
4.1.1.1. 強固なパスワードの作成
安全なパスワードを作成するには、長いパスワードの方が短くかつ複雑なものよりも強固であることをユー
ザーは認識する必要があります。あるパスワードが数字や特殊文字、大文字のアルファベットを含んでいて
も、それが 8 文字の長さしかなければ、強固なパスワードとは言えません。「John The Rippe r」のよう
なパスワード解析ツールは、人間が記憶するには困難なパスワードを分解するために最適なものです。
情報の理論上では、エントロピーはランダムな変数に関連付けられる不確実性のレベルで、ビット表示され
ます。エントロピーの値が高ければ高いほど、パスワードはより安全と言えます。NIST (米標準技術研究
所) の SP 800-63-1 文書によると、一般的に選択される 5 万件のパスワードからなる辞書にないパス
ワードには、少なくとも 10 ビットのエントロピーがあります。このため、ランダムな 4 単語からなるパ
スワードには、およそ 40 ビットのエントロピーがあることになります。安全性を高めるために複数の単語
で構成される長いパスワードは、パスフレーズとも呼ばれます。例を示します。
randomword1 randomword2 randomword3 randomword4
大文字や数字、特殊文字の使用が強制されるシステムでは、上記の推奨事項に合致するパスフレーズは簡単
に修正することができます。たとえば、最初の文字を大文字にして、"1!" を追加します。このような修正
は、パスフレーズの安全性を大幅に高めるものではないことに注意してください。
パスワードを自分で作成するもうひとつの方法は、パスワードジェネレーターを使用することで
す。pwmake は、大文字、小文字、数字、特殊文字の 4 種類の文字からなるランダムなパッケージを生
24
⁠第4 章ツールとサービスを使用したシステム強化
成するコマンドラインツールです。このユーティリティーを使うと、パスワード生成に使用されるエントロ
ピービットの数を指定することができます。エントロピーは、/dev/urandom から引き出されます。指定
可能な最小ビット数は 56 で、これはブルートフォース攻撃が滅多に仕掛けられないシステムやサービスの
パスワードには十分なものです。攻撃者がパスワードハッシュファイルに直接アクセスできないアプリケー
ションであれば、64 ビットで十分です。攻撃者がパスワードハッシュへの直接アクセスを取得する可能性
がある場合やパスワードが暗号化鍵として使用される場合は、80 ビットや 128 ビットを使うべきです。
無効なエントロピービット数を指定すると、pwmake はデフォルトのビット数を使用します。128 ビッ
トのパッケージを作成するには、以下のコマンドを実行します。
pwmake 128
安全なパスワードの作成にはいくつものアプローチがありますが、以下の悪い点は必ず避けてください。
辞書の 1 単語を使用する。外国語の 1 単語を使用する。反転した単語を使用する。数字のみを使用す

る。
パスワードまたはパスフレーズを 10 文字未満にする。
キーボードのレイアウトにおけるキーの配列を使用する。
パスフレーズを書き留める。
誕生日や記念日、家族の名前、ペットの名前などの個人情報をパスフレーズに使用する。
複数のマシンで同じパスワードまたはパスフレーズを使用する。
セキュアなパスワードの作成は不可欠ですが、パスワードの適切な管理も特に大きな組織のシステム管理者
にとっては重要です。次のセクションでは、組織内でのユーザーパスワードの作成および管理で推奨される
方法を説明します。
4.1.1.2. 強固なパスワードの強制
組織内に多くのユーザーがいる場合、システム管理者は 2 つの基本的な方法で強固なパスワードの使用を
強制できます。つまり、管理者がパスワードを作成してユーザーに渡すか、パスワードに十分な強度がある
かを検証しながらユーザー自身がパスワードを作成する方法です。
前者の方法だとパスワードは強固なものになりますが、組織が拡大するにつれてタスクが重荷になります。
また、ユーザーが自分のパスワードを書き留め、それをさらしてしまうリスクも高まります。
これらの理由で、多くのシステム管理者は後者を選択しますが、パスワードが強固かどうかを積極的に検証
します。場合によっては、管理者はパスワードエージングで定期的にユーザーがパスワードを変更するよう
に強制することもできます。
ユーザーは、パスワードの作成や変更を求められると、passwd コマンドラインユーティリティーを使用
することができます。これは PAM (Pluggable Authentication Modules) を認識し、パスワードが短すぎ
ないか、短くない場合は簡単にクラックされないかを確認します。この確認は、pam_pwquality.so
PAM モジュールが実行します。
注記
Re d Hat Ente rpris e Linux 7 では、pam_pwquality PAM モジュールが pam_cracklib の代

わりとなっています。後者は、Re d Hat Ente rpris e Linux 6 でパスワードの品質確認にデフォル
トのモジュールとして使われていました。新たなモジュールは、pam_cracklib と同じバックエ
ンドを使用します。
pam_pwquality モジュールは、ルールセットに対してパスワードの強度を確認するために使用されま
25
す。確認の手順は 2 段階になります。まず、該当パスワードが辞書にあるかどうかをチェックします。辞
書にない場合は、さらにいくつかのチェックを行います。pam_pwquality は /etc/pam.d/passwd
ファイルの password コンポーネント内に他の PAM モジュールと並んでいます。ルールのカスタムセッ
トは、/etc/security/pwquality.conf 設定ファイル内で指定されます。これらのチェック項目の
完全一覧については、pwquality.conf (8) man ページを参照してください。
例4.1 pwquality.conf 内でのパスワード強度チェックの設定
pam_quality の使用を有効にするには、以下の行を /etc/pam.d/passwd ファイルのpassword

スタックに追加します。
password required pam_pwquality.so retry=3
チェック項目のオプションは、1 行に 1 つずつ指定します。たとえば、パスワードを 8 文字以上にし

て、4 種類すべての文字を含めることを要件とするには、以下の行を
/etc/security/pwquality.conf ファイルに追加します。
minlen=8
minclass=4
パスワード強度チェックで連続文字または反復文字のチェックを行うには、以下の行を
/etc/security/pwquality.conf に追加します。
maxsequence=3
maxrepeat=3
この例では、「abcd」や「1234」など、4 つ以上連続する文字をパスワードに含めることはできませ
ん。また、同じ文字は、3 つまでしか繰り返すことはできません。
注記
root ユーザーはパスワード作成ルールを強制している本人なので、警告メッセージが出ても root

ユーザーは通常ユーザーおよび自身用にどんなパスワードでも設定することができます。
4.1.1.3. パスワードエージングの設定
パスワードエージングは、システム管理者が組織内での脆弱なパスワードに対する防御として用いるもうひ
とつのテクニックです。パスワードエージングとは、一定期間後 (通常 90 日) にユーザーが新たなパス
ワードを作成するように求められるシステムのことです。理論上は、ユーザーに定期的なパスワード変更を
強制すれば、クラックされたパスワードは侵入者にとって一定期間しか有効でないことになります。しか
し、パスワードエージングのマイナス面は、ユーザーがパスワードを書き留める可能性が高くなるという点
です。
Re d Hat Ente rpris e Linux 7 でパスワードエージングを指定するには、chage コマンドを使用します。
重要
Re d Hat Ente rpris e Linux 7 では、デフォルトでシャドウパスワードが有効になっています。詳

細は、Re d Hat Ente rpris e Linux 7 システム管理者のガイドを参照してください。
26
chage コマンドの -M オプションでは、パスワードが有効となる最長日数を指定します。例えば、ユー

ザーのパスワードが 90 日間で期限切れとなるように設定するには、以下のコマンドを実行します。
chage -M 90 <username>
上記のコマンドでは、<username> をユーザー名で置き換えます。パスワードの期限切れを無効にするに
は、通常 -M オプションの後に 99999 の値を使います (これは 273 年余りに相当します)。
chage コマンドで使用可能なオプションの詳細情報については、以下の表を参照してください。
表4.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 juan

Changing the aging information for juan
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]:
ユーザーの初回ログイン時にパスワードが失効するように設定できます。これにより、ユーザーはパスワー
ドを直ちに変更するよう強制されます。
1. 初期パスワードを設定します。この手順には 2 つの一般的なアプローチがあります。デフォルトの
パスワードを割り当てる、もしくは null パスワードを使用します。
デフォルトのパスワードを割り当てるには、root としてシェルプロンプトで以下を入力します。
27
passwd username
代わりに null パスワードを割り当てるには、次のコマンドを使用します。
passwd -d username
警告
null パスワードの使用は便利ですが、安全性は極めて低くなります。これは、いかなる第三
者でも、セキュアでないユーザー名を使用して最初にシステムにログインし、アクセスでき
るためです。可能な場合は、null パスワードの使用は避けてください。どうしても避けられ
ない場合は、null パスワードでアカウントのロック解除を行う前に、ユーザーがログインで
きる状態にあることを常に確かめてください。
2. パスワードを直ちに強制的に失効させるには、root として以下のコマンドを実行します。
chage -d 0 username
このコマンドは、パスワードが最後に変更された日付の値を 1970 年 1 月 1 日に設定します。パ

スワードエージングのポリシーが設定されていても、この値はパスワードを直ちに強制的に期限切
れにします。
これで、ユーザーは初回ログイン時に新規パスワードを入力するよう要求されます。
4.1.2. アカウントのロック
Re d Hat Ente rpris e Linux 7 では、pam_faillock PAM モジュールを使うとシステム管理者は特定回

数のログイン失敗の後にユーザーアカウントをロックアウトすることができます。ユーザーログインの試行
回数を制限する主な目的はセキュリティ措置であり、ユーザーアカウントのパスワード獲得を目的とする総
当たり攻撃を防ぐためのものです。
pam_faillock モジュールを使うと、ログイン失敗はユーザーごとに /var/run/faillock ディレク

トリー内の個別ファイルに保存されます。
注記
ログイン失敗のログファイルにおける行の順番は重要なものです。even_deny_root オプション
が使用されている場合、この順番が変更されると root アカウントを含むすべてのユーザーアカウ
ントがロックされます。
アカウントのロックを設定するには、以下の手順を実行します。
1. 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
28
unlock_time=600
2. 以下の行を上記の手順の両ファイルの account セクションに追加します。
account required pam_faillock.so
3. アカウントのロックアウトを root ユーザーにも適用するには、/etc/pam.d/system-auth お

よび /etc/pam.d/password-auth の各ファイルの pam_faillock エントリーに
even_deny_root オプションを追加します。

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
ユーザー john がログインに 3 回失敗した後に再度ログインしようとすると、このユーザーのアカウント

はこの 4 回目のログイン試行でロックされます。
[yruseva@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
aut hco nf ig ユーティリティーを使って認証設定を修正すると、system-auth および password-

auth の各ファイルは aut hco nf ig ユーティリティーからの設定で上書きされます。これを避けるに
は、設定ファイルの代わりにシンボリックリンクを作成します。このリンクを aut hco nf ig が認識し、
上書きが避けられます。設定ファイル内のカスタム設定と aut hco nf ig を同時に使うには、以下の手順
でアカウントロックを設定します。
1. 設定ファイルの名前を変更します。
29
~]# mv /etc/pam.d/system-auth /etc/pam.d/system-auth-local

~]# mv /etc/pam.d/password-auth /etc/pam.d/password-auth-local
2. 以下のシンボリックリンクを作成します。
~]# ln -s /etc/pam.d/system-auth-local /etc/pam.d/system-auth

~]# ln -s /etc/pam.d/password-auth-local /etc/pam.d/password-auth
3. /etc/pam.d/system-auth-local ファイルに以下の行を記載します。

auth include system-auth-ac
auth [default=die] pam_faillock.so authfail silent audit

account include system-auth-ac
password include system-auth-ac
session include system-auth-ac
4. /etc/pam.d/password-auth-local ファイルに以下の行を記載します。

auth include password-auth-ac
auth [default=die] pam_faillock.so authfail silent audit

account include password-auth-ac
password include system-auth-ac
session include system-auth-ac
pam_faillock の設定オプションについての詳細情報は、pam_faillock(8) の man ページを参照してく

ださい。
4.1.3. セッションのロック
日常の業務中にユーザーがワークステーションから離れなければならない時もあります。こういう場合は、
特に十分な物理的セキュリティ対策がとられていない環境 (「物理的コントロール」を参照) では、攻撃者
にマシンに物理的にアクセスする機会を与えてしまいます。ノートパソコンの場合は特に、持ち運びが便利
なので物理的な安全性が脅かされます。このリスクは、正しいパスワードが入力されないとシステムにアク
セスできないようにするセッションロッキング機能を使うことで緩和できます。
30
注記
画面のロックがログアウトよりも優れている点は、ロックの場合は (ファイル転送といった) ユー
ザーのプロセスを続行できるという点です。ログアウトしてしまうと、このようなプロセスは中断し
てしまいます。
4.1.3.1. vlock を使った仮想コンソールのロック
仮想コンソールをロックする必要がある場合は、vlock というユーティリティーを使って実行できます。
このユーティリティーをインストールするには、以下のコマンドを root で実行します。
~]# yum install vlock
インストール後は、新たなパラメーターなしで vlock コマンドを使えば、コンソールセッションはすべて

ロックできます。このコマンドでは、アクティブな仮想コンソールをロックしますが、他のセッションへ
のアクセスは可能です。ワークステーション上のすべての仮想コンソールへのアクセスを防止するには、以
下のコマンドを実行します。
vlock -a
この場合、vlock がアクティブなコンソールをロックし、-a オプションが他の仮想コンソールへのス

イッチを防ぎます。
詳細は vlock(1) man ページを参照してください。
重要
Re d Hat Ente rpris e Linux 7 で現在利用可能な vlock のバージョンに関する既知の問題がいく

つかあります。
このプログラムでは現在、root パスワードを使ったコンソールのロック解除ができません。詳細
は BZ#895066 を参照してください。
コンソールをロックしても、画面およびスクロールバックバッファを削除しないので、それまで
のコマンドやコンソールで表示された出力が、ワークステーションに物理的アクセスできれば誰
でも見れることになります。詳細については、BZ#807369 を参照してください。
4.2. Root アクセスの制御
ホームとなるマシンを管理する際には、ユーザーは root ユーザーとして、または sudo や su などの

setuid プログラムで有効な root 権限を取得してから実行する必要のあるタスクがあります。s e tuid プロ
グラムは、プログラムを実行しているユーザーではなく、プログラムの所有者のユーザー ID (UID) で実行
されるプログラムです。これらのプログラムは、以下の例のように、ロング形式の所有者セクションにある
s で示されます。
~]$ ls -l /bin/su
-rwsr-xr-x. 1 root root 34904 Mar 10 2011 /bin/su
31
注記
s は大文字または小文字の場合があります。大文字の場合は、基になるパーミッションビットが設
定されていないことを示します。
しかし、組織のシステム管理者は、組織のユーザーが自身のマシンにどの程度の管理者アクセスを持つかを
決定しなくてはなりません。pam_console.so と呼ばれる PAM モジュールを使うと、再起動やリムーバ
ブルメディアのマウントなど通常は root ユーザーのみとなっているアクティビティーを、物理コンソール
に最初にログインしたユーザーが実行できるようになります。しかし、ネットワーク設定の変更や新たなマ
ウスの設定、ネットワークデバイスのマウントといったシステム管理者の他の重要なタスクは、管理者権限
なしでは実行できません。その結果、システム管理者はネットワーク上のユーザーにどの程度のアクセスを
許可するかを判断する必要があります。
4.2.1. Root アクセスの拒否
上記またはその他の理由でユーザーが root でログインすることに管理者が不安に感じる場合、root パス

ワードは公開せず、ランレベル 1 へのアクセスやシングルユーザーモードへのアクセスをブートローダー
パスワード保護で拒否してください (このトピックについての詳細は「ブートローダーのセキュア化」を
参照してください)。
管理者は以下の 4 つの方法で、root ログインが拒否されるようにできます。
Ro o t シェルの変更
ユーザーが直接 root としてログインしないように、システム管理者は /etc/passwd ファイル

で root アカウントのシェルを /sbin/nologin に設定できます。
表4.2 Ro o t シェルの無効化
影響あり影響なし
Root シェルへのアクセスを防ぎ、アクセスの FTP クライアントやメールクライアント、多
試みをすべてログに記録します。以下のプロくの s e tuid プログラムはシェルを必要とし
グラムは root アカウントへのアクセスが止めません。以下のプログラムは root アカウント
られます。へのアクセスが止められません。
login sudo
gdm FTP クライアント
kdm Email クライアント
xdm
su
ssh
scp
sftp
どのコンソールデバイス (t t y) からの ro o t アクセスも無効にする
Root アカウントへのアクセスをさらに制限するために、管理者は /etc/securetty ファイル

を編集してコンソールでの root ログインを無効にすることができます。このファイルは、root
ユーザーがログイン可能なすべてのデバイスを一覧表示します。このファイル自体がない場合、
コンソールからでも raw ネットワークインターフェイスからでも、システム上のいかなる通信
デバイスからでも root ユーザーはログイン可能となってしまいます。ユーザーは Te lne t 経由
で root としてマシンにログイン可能で、こうするとプレーンテキストのパスワードがネット
ワーク上で送信されてしまうので、危険なことになります。
32
デフォルトでは、Re d Hat Ente rpris e Linux 7 の /etc/securetty ファイルは root ユー

ザーにのみ、マシンに物理的につながれたコンソールでのログインを許可します。root ユーザー
によるログインを拒否するには、root でシェルプロンプトから以下のコマンドを入力して、この
ファイルのコンテンツ削除します。
echo > /etc/securetty
KDM、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 ユーザーがリモートでツールの

Ope nSSH スイートを使用してログインすることは止められません。これは、コンソール
は認証が終わるまで開かれないためです。
表4.3 Ro o t ログインの無効化
コンソールまたはネットワーク経由での root Root としてはログインしませんが、s e tuid
アカウントへのアクセスを防ぎます。以下のまたは別のメカニズムで管理タスクを実行す
プログラムは root アカウントへのアクセスがるプログラムです。以下のプログラムは root
止められます。アカウントへのアクセスが止められません。
login su
gdm sudo
kdm ssh
xdm scp
tty を開くその他のネットワークサービス sftp
Ro o t SSH ログインを無効にする
SSH プロトコル経由での root ログインを防ぐには、SSH デーモンの設定ファイルである

/etc/ssh/sshd_config を編集し、
33
#PermitRootLogin yes
の行を以下のように変更します。
PermitRootLogin no
表4.4 Ro o t SSH ログインの無効化
ツールの Ope nSSH スイート経由での root ツールの Ope nSSH スイートの一部ではない
アクセスを防ぎます。以下のプログラムはプログラム
root アカウントへのアクセスが止められま
す。
ssh
scp
sftp
PAM を使用してサービスへの ro o t アクセスを制限する
PAM は /lib/security/pam_listfile.so を使って、特定アカウントの拒否に大幅な柔軟

性を提供します。管理者はこのモジュールを使ってログインが許可されないユーザーリストを参
照できます。システムサービスへの root アクセスを制限するには、/etc/pam.d/ ディレクト
リー内の対象サービスのファイルを編集して、pam_listfile.so モジュールが認証に必要と
なるようにします。
以下の例では、/etc/pam.d/vsftpd PAM 設定ファイルの vsftpd FTP サーバーにこのモ

ジュールを使用しています (一行目の末にある \ の文字は、ディレクティブが一行の場合は必
要ありません)。
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 についての詳細情報は、『The Linux-PAM Sys te m Adminis trator's Guide 』を参照

してください。/usr/share/doc/pam-<version>/html/ ディレクトリーにあります。
表4.5 PAM を使った ro o t の無効化
34
PAM 対応のネットワークサービスへの root PAM 非対応のプログラムおよびサービス
アクセスを防ぎます。以下のサービスは root
アカウントへのアクセスが止められます。
login
gdm
kdm
xdm
ssh
scp
sftp
FTP クライアント
Email クライアント
すべての PAM 対応サービス
4.2.2. Root アクセスの許可
組織内のユーザーが信頼できてコンピューターの知識を持っているユーザーであれば、root アクセスを許
可することに問題はありません。ユーザーに root アクセスを許可すれば、デバイスの追加やネットワーク
インターフェイスの設定といった重要性の低いアクティビティを個別のユーザーが処理できるので、シス
テム管理者はネットワークセキュリティや他の重要な問題に専念できます。
一方で、個別のユーザーに root アクセスを許可すると、以下のような問題も発生します。
マシンの誤った設定 — root アクセスを持つユーザーは自身のマシンを間違って設定する可能性があ

り、この問題を解決するにはヘルプを必要とします。ひどい場合には、知らないうちにセキュリティに
穴を開けてしまう可能性もあります。
安全でないサービスの実行 — root アクセスを持つユーザーは、FTP や Te lne t といった安全でない

サービスを自身のマシン上で実行して、ユーザー名やパスワードを危険にさらす可能性があります。こ
れらのサービスは、ユーザー名やパスワードをプレーンテキストでネットワーク上で送信します。
Email の添付ファイルを ro o t として実行 — 滅多にないことですが、Linux に影響を及ぼす Email

ウイルスも存在します。しかしこれが脅威となるのは、root ユーザーとして実行された場合のみです。
監査証跡がそのままになる — root アカウントは通常複数のユーザーが共有し、複数のシステム管理者

がシステムのメインテナンスをできるようになっているため、ある時点でこのうちのどのユーザーが
root だったかを見分けることは不可能です。別個のログインを使用すると、ユーザーがログインしたア
カウントとセッション追跡目的の一意の番号がタスク構造に組み込まれ、これはユーザーが開始するプ
ロセスすべてで継承されます。同時ログインを使用すると、一意の番号は特定ログインのアクションの
追跡に使用できます。アクションが監査イベントを生成する際には、ログインアカウントとその一意の
番号に関連付けられているセッションとともに記録されます。これらのログインとセッションを表にす
るには、aulast コマンドを使用します。aulast の --proof オプションを使うと、特定のセッ
ションで生成された監査可能なイベントを切り離す特定の ausearch クエリの提示が可能になりま
す。監査システムについての詳細情報は、5章システム監査を参照してください。
4.2.3. Root アクセスの制限
Root ユーザーへのアクセスを完全に拒否するのではなく、管理者が su や sudo といった s e tuid プログ

ラム経由のアクセスのみを許可したい場合もあるかもしれません。su および sudo についての詳細は、
Re d Hat Ente rpris e Linux 7 システム管理者のガイドの権限の取得の章と、su(1) と sudo(8) の
man ページを参照してください。
4.2.4. 自動ログアウトの有効化
35
4.2.4. 自動ログアウトの有効化
ユーザーが root としてログインしている場合、このセッションを無人状態にしておくと、重大なセキュ

リティリスクをもたらす恐れがあります。このリスクを減らすために、一定期間が経過してからアイドル状
態のユーザーを自動的にログアウトするようにシステムを設定することができます。
1. screen パッケージがインストールされていることを確認して下さい。root として以下のコマン

ドを実行します。
yum install screen
Re d Hat Ente rpris e Linux 7 でのパッケージインストール方法についての情報は、Re d Hat

Ente rpris e Linux 7 システム管理者のガイドのパッケージでの作業の章を参照してください。
2. root として /etc/profile ファイルの先頭に以下の行を追加して、このファイルの処理が中断

されないようにします。
trap "" 1 2 3 15
3. /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 コマンド
の後にある値を変更します。
4. アクティブでない状態が一定期間経過した後に、screen セッションを閉じるようにするには、以
下の行を /etc/screenrc 設定ファイルに追加します。
idle 120 quit autodetach off
上記は、制限時間を 120 秒に設定しています。この制限を調節するには、idle ディレクティブ

の後にある値を変更します。
別の方法として、以下の行を使用してセッションのロックだけが行われるようにシステムを設定す
ることも可能です。
idle 120 lockscreen autodetach off
この方法では、セッションのロックを解除するためにパスワードが必要です。
これらの変更は、ユーザーが次回システムにログインする時に反映されます。
4.2.5. ブートローダーのセキュア化
Linux ブートローダーをパスワードで保護する主要な理由は以下のとおりです。
36
1. シングルユーザーモードへのアクセスを防ぐ— 攻撃者がシステムを起動してシングルユーザー
モードに入れるとすると、root パスワードの入力なしで自動的に root としてログインすることに
なってしまいます。
警告
/etc/sysconfig/init ファイルで SINGLE パラメーターを編集してシングルユーザー

モードへのアクセスを保護する方法は推奨されません。攻撃者は、GRUB 2 のカーネルコマ
ンドライン上で (init= を使って) カスタム初期コマンドを特定することでパスワードを迂
回できます。Re d Hat Ente rpris e Linux 7 システム管理者のガイドの GRUB 2 パスワー
ドの保護の章にあるように、GRUB 2 ブートローダーをパスワードで保護することが推奨
されます。
2. GRUB 2 コンソールへのアクセスを防ぐ — マシンがブートローダーに GRUB 2 を使用している

場合、攻撃者は GRUB 2 エディターインターフェイスを使って設定を変更したり、cat コマンド
を使用して情報収集ができるようになります。
3. 安全でないオペレーティングシステムへのアクセスを防ぐ— デュアルブートシステムの場合、攻
撃者はアクセス制御やファイルパーミッションを無視する (例えば、DOS などの) OS を起動時に
選択できます。
Inte l 64 および AMD64 プラットホームの Re d Hat Ente rpris e Linux 7 では、GRUB 2 ブートロー
ダーが同梱されています。GRUB 2 の詳細については、Re d Hat Ente rpris e Linux 7 システム管理者の
ガイドの GRUB 2 ブートローダーの操作の章を参照してください。
4.2.5.1. インタラクティブスタートアップの無効化
起動順序の最初に I キーを押すと、インタラクティブな方法でシステムを起動できます。この方法では、
システムがユーザーにサービスを 1 つずつ開始するように求めます。しかし、システムに物理的なアクセ
スがある攻撃者の場合は、この方法だとセキュリティ関連のサービスを無効にし、システムへのアクセスを
許すことになってしまいます。
このようなインタラクティブなスタートアップを防止するには、root で /etc/sysconfig/init ファ
イルの PROMPT パラメーターを以下のように無効にします。
PROMPT=no
4.3. サービスのセキュア化
組織内のシステム管理者にとっては管理機能へのユーザーアクセスは重要な問題ですが、どのネットワーク
サービスがアクティブかを監視することは、Linux システムのすべての管理・運営担当者にとっての最重要
事項です。
Re d Hat Ente rpris e Linux 7 における多くのサービスは、ネットワークサーバーとして動作します。マ

シン上でネットワークサービスが稼働中であれば、(デーモンと呼ばれる) サーバーアプリケーションが 1
つ以上のネットワークポート上での接続をリッスンします。これらの各サーバーは、潜在的な攻撃の接近手
段として扱われる必要があります。
4.3.1. サービスへのリスク
ネットワークサービスは Linux システムに多くのリスクを与える可能性があります。主な問題を以下に挙

げます。
37
サービス拒否攻撃 (Do S) — サービス拒否攻撃は、サービスに対して要求を大量に送信することでシス

テムがすべての要求をログ記録・応答しようとし、使用不可能になります。
分散型サービス拒否攻撃 (DDo S) — これは DoS 攻撃の一種で、複数の脆弱なマシンを使用し (通

常、数千以上)、サービスに対して一斉攻撃を仕掛けます。大量の要求が送信され、サービスを使用不可
能にしてしまいます。
スクリプトの脆弱性への攻撃 — We b サーバーが通常行うように、サーバー全体のアクションにサー
バーがスクリプトを使用している場合、攻撃者は誤って書かれたスクリプトを狙うことができます。こ
のスクリプトの脆弱性に対する攻撃により、バッファがオーバーフロー状態になるか、攻撃者がシステ
ム上のファイルを変更できる可能性があります。
バッファオーバーフロー攻撃 — ポート番号 0 から 1023 までに接続するサービスは、管理ユーザーと

して実行する必要があります。アプリケーションに利用可能なバッファオーバーフローがある場合、攻
撃者はデーモンを実行中のユーザーとしてシステムにアクセスすることができます。利用可能なバッ
ファオーバーフローが存在することから、クラッカーは自動ツールを使って脆弱性のあるシステムを特
定でき、アクセスを確保した後に自動ルートキットを使ってシステムへのアクセスを維持します。
注記
Re d Hat Ente rpris e Linux 7 では、ExecShield と呼ばれる x86 互換のシングルおよびマルチプ

ロセッサーのカーネルがサポートする実行可能メモリのセグメント化および保護技術により、バッ
ファオーバーフローの脆弱性における脅威は緩和されています。Exe cShie ld は仮想メモリを実行
可能なセグメントと非実行可能セグメントに分けることでバッファオーバーフローのリスクを下げ
ます。(バッファオーバーフローエクスプロイトから注入された悪意のあるコードなど) 実行可能セ
グメント外で実行を試みるすべてのプログラムコードは、セグメント化の失敗を発生させ、終了しま
す。
Exe cs hie ld には AMD64 プラットフォーム上の No eXecute (NX) と Inte l® 64 システムのサ

ポートが含まれます。これらのテクノロジーが Exe cShie ld と組み合わさることで、4 KB の実行
可能コードという粒度で仮想メモリの実行可能な部分での悪意のあるコードの実行を防ぎます。これ
で、バッファオーバーフローエクスプロイトからの攻撃リスクを減らします。
重要
ネットワーク上での攻撃への露出を限定するために、使用していないサービスはすべてオフにするこ
とが推奨されます。
4.3.2. サービスの特定および設定
セキュリティを強化するために、Re d Hat Ente rpris e Linux 7 でインストールされているネットワーク

サービスのほとんどはデフォルトでオフとなっています。ただし、以下のものは例外となります。
cups — Re d Hat Ente rpris e Linux 7 のデフォルトのプリントサーバー
cups-lpd — 代替プリントサーバー
xinetd — gssftp や telnet などの下位サーバーへの接続を管理するスーパーサーバー
sshd — Te lne t の安全な代替となる Ope nSSH サーバー
これらサービスの稼働を継続しておくかどうかを判断する際は、常識にしたがってリスクを避けるのが最善
38
策です。例えば、プリンターが利用できない場合は cups を無効にします。同じことは portreserve に

ついても言えます。NFSv3 ボリュームをマウントしていなかったり、NIS (ypbind サービス) を使用しな
いのであれば、rpcbind を無効にすべきです。ブート時にどのネットワークサービスが開始可能になって
いるかを確認するだけでは、十分ではありません。どのポートがオープンでリッスンしているかを確認する
ことが推奨されます。詳細情報は、「リッスンしているポートの確認」を参照してください。
4.3.3. 安全でないサービス
潜在的にはどのネットワークサービスも安全ではありません。未使用のサービスをオフにすることが重要な
のは、このためです。サービスのエクスプロイトは定期的に発見され修正プログラムが提供されているの
で、ネットワークサービスはどんなものでも関連するパッケージを定期的に更新することが非常に重要で
す。詳細は 3章システムを最新の状態に保つを参照してください。
ネットワークプロトコルの中には、もともと他のものよりも安全性が低いものがあります。以下の動作を実
行するサービスがそれに当たります。
暗号化されていないネットワークでユーザー名やパスワードを送信する— Te lne t や FTP など多くの

古いプロトコルは認証セッションを暗号化しないので、できるだけ避けてください。
暗号化されていないネットワークで機密性の高いデータを送信する — Te lne t や FTP、HTTP、SMTP

など多くのプロトコルでは暗号化されていないネットワークでデータを送信します。また、NFS や
SMB などの多くのネットワークファイルシステムでも暗号化されていないネットワークで情報を送信
します。これらのプロトコルを使用する際に送信するデータの種類を制限することは、ユーザーの責任
になります。
もともと安全性が低いサービスには、rlogin、rsh、telnet、vsftpd などがあります。
リモートログインおよびシェルプログラム (rlogin、rsh、telnet) はすべて避けて、SSH を選択する

ようにしてください。sshd についての詳細情報は、「SSH のセキュア化」を参照してください。
FTP はリモートシェルと比べるとシステムの安全性にそれほど危険ではありませんが、問題を回避するには
FTP サーバーは慎重に設定、監視する必要があります。FTP サーバーを安全にする詳細情報について
は、「FTP のセキュア化」を参照してください。
実装時に注意が必要で、ファイアウォールの背後に配置する必要があるサービスは以下のものです。
auth
nfs-server
smb および nbm (Samba)
yppasswdd
ypserv
ypxfrd
ネットワークサービスの安全性を高めるための詳細情報は、「ネットワークアクセスのセキュア化」を参
照してください。
4.3.4. rpcbind のセキュア化
rpcbind サービスは、NIS やNFS などの RPC サービス用の動的なポート割り当てデーモンです。この認

証メカニズムは脆弱なもので、制御対象のサービスに幅広いポートを割り当てる機能があります。このた
め、セキュア化は困難になります。
39
注記
NFSv4 は rpcbind を必要としなくなったので、portmap のセキュア化が影響するのは NFSv2

と NFSv3 のみです。NFSv2 もしくは NFSv3 サーバーの導入を計画する場合は、rpcbind が必
要となり、以下のセクションが適用されます。
RPC サービスを実行している場合は、以下の基本的なルールにしたがってください。
4.3.4.1. T CP Wrapper による rpcbind の保護
rpcbind にはビルトインの認証がないので、TCP Wrappe r を使用して rpcbind サービスにアクセスす

るネットワークやホストを制限することが重要です。
さらに、サービスへのアクセスを制限する際には、IP アドレスのみを使用してください。ホスト名は

DNS ポイズニングやその他の方法で偽造される恐れがあるので、使用しないでください。
4.3.4.2. f irewalld による rpcbind の保護
rpcbind サービスへのアクセスをさらに制限するには、サーバーにfirewalld ルールを追加し、特定

ネットワークへのアクセスを制限するとよいでしょう。
以下は、 firewalld リッチ言語コマンドの 2 つの例です。最初のコマンドは 192.168.0.0/24 ネット

ワークからポート 111 (rpcbind サービスが使用) への TCP 接続を許可します。2 つ目のコマンドは、
ローカルホストからの同一ポートへの接続を許可します。他のパケットはすべて遮断されます。
~]# firewall-cmd --add-rich-rule='rule family="ipv4" port port="111"

protocol="tcp" source address="192.168.0.0/24" invert="True" drop'
protocol="tcp" source address="127.0.0.1" accept'
UDP トラフィックを同様に制限するには、以下のコマンドを使用します。

protocol="udp" source address="192.168.0.0/24" invert="True" drop'
注記
設定を永続的にするには、--permanent を firewalld リッチ言語コマンドに追加します。ファ

イアウォールの実装に関する詳細情報は、「ファイアウォールの使用」を参照してください。
4.3.5. NIS のセキュア化
ネットワーク情報サービス (NIS) は ypserv と呼ばれる RPC サービスの一つで、rpcbind および他の

関連サービスと一緒に使用することで、ドメイン内にあると主張するすべてのコンピューターに、ユーザー
名やパスワード、他の機密性のある情報のマップを配布します。
NIS サーバーは、以下のものを含むいくつかのアプリケーションで構成されています。
/usr/sbin/rpc.yppasswdd — yppasswdd サービスとも呼ばれます。このデーモンを使用するこ

とで、ユーザーは NIS パスワードを変更できます。
40
/usr/sbin/rpc.ypxfrd — ypxfrd サービスとも呼ばれます。このデーモンは、ネットワーク上で

の NIS マップ転送を担当します。
/usr/sbin/ypserv — これは NIS サーバーデーモンです。
NIS は今日の基準ではあまり安全なものではありません。ホスト認証メカニズムがなく、パスワードハッ
シュを含むすべての情報をネットワーク上で暗号化せずに送信します。このため、NIS を使用するネット
ワークの設定時には、非常に注意深い作業が必要になります。さらに、NIS のデフォルト設定がもともと安
全でないことで複雑性が増してしまいます。
NIS サーバーの実装を予定している場合は、「rpcbind のセキュア化」に概説があるようにまず

rpcbind サービスのセキュア化を図ることが推奨されます。その後に、以下のようなネットワークプラニ
ングの問題などに対処してください。
4.3.5.1. ネットワークの注意深いプラニング
NIS は機密性の高い情報を暗号化せずにネットワーク上で送信するので、ファイアウォールの背後で、ま
たセグメント化された安全なネットワーク上で実行することが重要です。NIS 情報が安全でないネットワー
ク上で送信される際は、常に傍受される危険があります。ネットワークを注意深く設計することで、重大な
セキュリティ侵害の防止に役立ちます。
4.3.5.2. パスワードのような NIS ドメイン名およびホスト名を使用する
ユーザーが NIS サーバーの DNS ホスト名と NIS ドメイン名を知っていれば、NIS ドメイン内のマシンは

どれもコマンドを使用して認証なしにサーバーから情報を引き出すことができます。
例えば、だれかがノートパソコンをネットワークに接続するか、外部からネットワークに侵入すると (そし
て内部 IP アドレスにスプーフィングできたとすると)、以下のコマンドが /etc/passwd マップを公開し
ます。
ypcat -d <NIS_domain> -h <DNS_hostname> passwd
この攻撃者が root ユーザーであった場合、以下のコマンドを入力して /etc/shadow ファイルを入手す

ることが可能です。
ypcat -d <NIS_domain> -h <DNS_hostname> shadow
注記
Ke rbe ros を使用していれば、/etc/shadow ファイルは NIS マップ内に保存されません。
攻撃者による NIS マップへのアクセスをより困難にするには、o7hfawtgmhwg.domain.com のような

ランダムの文字列を DNS ホスト名にします。同様に、異なるランダムな NIS ドメイン名を作成します。
これにより、攻撃者は NIS サーバーへのアクセスが非常に困難になります。
4.3.5.3. /var/yp/securenets ファイルを編集する
/var/yp/securenets ファイルが空白もしくは存在しない場合 (デフォルトインストールの後の場合の

ように)、NIS はすべてのネットワークをリッスンします。最初にすることのひとつは、ネットマスクと
ネットワークのペアをファイルに置くことで、これにより ypserv は適正なネットワークからの要求のみ
に応答するようになります。
以下は /var/yp/securenets ファイルからのエントリのサンプルです。
41
255.255.255.0 192.168.0.0
警告
/var/yp/securenets ファイルを作成せずに NIS サーバーを初回起動することは、絶対にしな

いでください。
このテクニックは IP スプーフィングからの保護は提供しませんが、少なくとも NIS サーバーが対応する

ネットワークに対して制限をかけます。
4.3.5.4. 静的ポートの割り当てとリッチ言語ルールの使用
NIS に関連付けられているサーバーは、rpc.yppasswdd を除いて特定のポートの割り当てが可能です。

このデーモンを使うと、ユーザーは自身のログインパスワードを変更できるようになりま
す。rpc.ypxfrd と ypserv の 2 つの NIS サーバーデーモンにポートを割り当てると、NIS サーバー
デーモンをさらに侵入者から保護するためのファイアウォールルールが作成できます。
これを実行するには、以下の行を /etc/sysconfig/network に追加します。
YPSERV_ARGS="-p 834"
YPXFRD_ARGS="-p 835"
以下のリッチ言語の firewalld ルールを使って、これらのポートでサーバーがリッスンするネットワー

クを強制できます。
~]# firewall-cmd --add-rich-rule='rule family="ipv4" source

address="192.168.0.0/24" invert="True" port port="834-835"
protocol="tcp" drop'
~]# firewall-cmd --add-rich-rule='rule family="ipv4" source
address="192.168.0.0/24" invert="True" port port="834-835"
protocol="udp" drop'
つまり、192.168.0.0/24 ネットワークからの要求であれば、サーバーはポート 834 および 835 への

接続のみを許可することになります。最初のルールは TCP のもので、2 つ目は UDP になります。
注記
iptable s コマンドによるファイアウォール実装についての詳細情報は、「ファイアウォールの使
用」を参照してください。
4.3.5.5. Kerberos 認証を使用する
認証に NIS を使用する際に考慮すべきことの一つは、ユーザーがマシンにログインする際は常

に、/etc/shadow マップからのパスワードハッシュがネットワーク上で送信されるということです。侵
入者が NIS ドメインへアクセスしてネットワークトラフィックを傍受した場合、ユーザー名とパスワード
ハッシュを取得できることになります。さらに時間があれば、攻撃者はパスワードクラッキングプログラム
で脆弱なパスワードを推測し、ネットワーク上の有効なアカウントへのアクセスを取得できるようになりま
す。
42
Ke rbe ros は秘密鍵の暗号作成方法を使用するので、パスワードハッシュがネットワーク上で送信される

ことはなく、システムを大幅に安全なものとします。Ke rbe ros についての詳細は、Linux Domain
Ide ntity, Authe ntication, and Policy Guide の Authe ntication: Ke rbe ros KDC のセクションを参照
してください。
4.3.6. NFS のセキュア化
重要
NFS トラフィックは全バージョンで TCP を使用して送信することが可能で、UDP ではなく

NFSv3 を使って送信してください。NFS のバージョンはすべて、RPCSEC_GSS カーネルモジュー
ルの一部として Ke rbe ros ユーザーおよびグループ認証をサポートしています。Re d Hat
Ente rpris e Linux 7 では rpcbind を使用する NFSv3 がサポートされているので、rpcbind に
関する情報も引き続き含まれています。
4.3.6.1. ネットワークの注意深いプラニング
NFSv2 と NFSv3 ではこれまで、データの受け渡しは安全に行われていませんでした。今では NFS の全

バージョンで Ke rbe ros を使った通常のファイルシステム操作の認証 (およびオプションで暗号化) がで
きます。NFSv4 では、すべての操作で Ke rbe ros の使用が可能です。v2 または v3 では、ファイルロッ
クとマウントにまだ Ke rbe ros が使用されていません。NFSv4 使用時は、クライアントが NAT もしくは
ファイアウォールの背後にあるのであれば、委任はオフにすることができます。NFSv4.1 を使って NAT
およびファイアウォールを通じた委任による操作を可能にする方法については、Re d Hat
Ente rpris e Linux 7 ストレージ管理ガイドの pNFS のセクションを参照してください。
4.3.6.2. NFS マウントオプションのセキュア化
/etc/fstab ファイル内での mount コマンド使用については、Re d Hat Ente rpris e Linux 7 ストレー

ジ管理ガイドの mount コマンドの使い方の章で説明されています。セクション管理の観点からは、NFS
マウントオプションは /etc/nfsmount.conf でも指定可能であることは注目に値します。これを使う
と、カスタムのデフォルトオプションを設定することが可能です。
4.3.6.2.1. NFS サーバーのレビュー
警告
ファイルシステムをエクスポートする際は、全体のエクスポートのみを行なってください。ファイ
ルシステムのサブディレクトリーをエクスポートすると、セキュリティ問題につながる可能性があ
ります。場合によってはクライアントがファイルシステムのエクスポートされた部分から抜け出
し、エクスポートされていない部分に至ることもあります (exports(5) man ページのサブツリー
チェックのセクションを参照)。
マウント済みファイルシステムへの書き込み可能なユーザー数を減らすためには、可能な場合は常に ro オ
プションを使用してファイルシステムを読み取り専用としてエクスポートしてください。rw オプションの
使用は、明確に必要な場合のみとしてください。詳細は exports(5) man ページを参照してください。
書き込みアクセスを許可すると、シンボリックリンク攻撃などのリスクが高まります。これには、/tmp や
/usr/tmp などの一時ディレクトリーが含まれます。
ディレクトリーを rw オプションでマウントする必要がある場合は、リスク低減のためにできる限り全ユー
ザー書き込み可能としないようにします。アプリケーションのなかにはパスワードをクリアテキストで保存
したり暗号化が弱いものもあるので、ホームディレクトリーのエクスポートもリスクとみなされます。この
43
リスクは、アプリケーションコードがレビューされ、改善されることで軽減されてきています。SSH キー
にパスワードを設定しないユーザーもいるので、ホームディレクトリーがリスクをもたらすことになりま
す。パスワードや Ke rbe ros の使用を強制することで、このリスクは緩和されます。
エクスポートはアクセスを必要とするクライアントのみとしてください。NFS サーバーで showmount -

e コマンドを使用して、サーバーが何をエクスポートしているかを確認します。特に必要でないものはエク
スポートしないでください。
no_root_squash オプションは使用しないでください。また、既存のインストールのレビューを行い、
これが使用されていないことを確認してください。詳細は「no_root_s quas h オプションは使用しないで
ください」を参照してください。
secure オプションはサーバー側のエクスポートオプションで、「予約済み」ポートへのエクスポートを

制限する際に使用します。デフォルトでは、サーバーは「予約済み」ポート (ポート番号 1024 未満のも
の) からのクライアント通信のみを許可します。これは、クライアントが通常これらのポートの使用を許可
するのは「信頼できる」コード (カーネル内の NFS クライアントなど) のみだったためです。しかし、多
くのネットワークではクライアント上で root になるのは難しいことではないので、予約済みポートからの
通信が権限を伴うものであると仮定するのは安全ではありません。このため、予約済みポートへの制限は限
定的な価値しかありません。Ke rbe ros やファイアウォール、エクスポートを特定のクライアントに制限
するという方法を信頼する方がより安全です。
ほとんどのクライアントでは、可能な場合はまだ予約済みポートを使用しています。しかし、予約済みポー
トは限定的なリソースなので、クライアント (特に NFS マウント数が多いもの) はより高い番号のポートを
使う選択をする場合もあります。Linux クライアントは、「nore s vport」マウントオプションを使用し
てこれを行うことができます。エクスポートでこれを許可したい場合は、「ins e cure 」エクスポートオプ
ションで行うことができます。
ユーザーがサーバーにログインできないようにしておくのは、よい方法です。上記の NFS サーバー設定を

確認する間に、誰および何がサーバーにアクセス可能かを確認してください。
4.3.6.2.2. NFS クライアントのレビュー
set uid プログラムを使用できないようにするには、nosuid オプションを使用します。nosuid オプ

ションは set-user-identifier または set-group-identifier ビットを無効にします。これに
より、リモートユーザーが s e tuid プログラムを実行してより高い権限を取得することを防ぎます。このオ
プションは、クライアントおよびサーバー側で使用してください。
noexec オプションはクライアント上のすべての実行可能ファイルを無効にします。共有しているファイ
ルシステムにあるファイルをユーザーが不注意で実行しないようにこのオプションを使用します。nosuid
および noexec オプションは、ほとんどのファイルシステムの標準オプションです。
nodev オプションを使うと、クライアントが「de vice -file s 」をハードウェアデバイスとして処理する

ことを防ぎます。
resvport オプションはクライアント側のマウントオプションで、secure はこれに対応するサーバー側

のエクスポートオプションです (上記の説明を参照)。これは「予約済みポート」への通信を制限します。予
約済みまたは「よく知られた」ポートは、root ユーザーなどの権限のあるユーザーやプロセス用に確保さ
れています。このオプションを設定すると、クライアントが予約済みソースのポートを使ってサーバーと通
信するようになります。
NFS の全バージョンですでに Ke rbe ros 認証に対応しています。これを有効にするマウントオプション

は、次の通りです。sec=krb5
NFSv4 は、整合性には krb5i を、プライバシー保護には krb5p を使用して Ke rbe ros によるマウント

をサポートします。これらは sec=krb5 でのマウント時に使用されますが、NFS サーバー上での設定が必
要です。詳細はエクスポートに関する man ページ (man 5 exports) を参照してください。
NFS man ページ (man 5 nfs) には「SECURITY CONSIDERATIONS」セクションがあり、ここでは

NFSv4 のセキュリティ強化の説明と NFS の特定のマウントオプションすべてが含まれています。
44
4.3.6.3. 構文エラーに注意
NFS サーバーは /etc/exports ファイルを参照して、エクスポートするファイルシステムとこれらの

ディレクトリーをエクスポートするホストを決定します。このファイルを編集する際は、無関係な領域を追
加しないように注意してください。
例えば、/etc/exports ファイル内の以下の行は読み取り/書き込みパーミッションでディレクトリー
/tmp/nfs/ をホスト bob.example.com と共有します。
/tmp/nfs/ bob.example.com(rw)
一方、/etc/exports ファイルは同じディレクトリーを読み取り専用パーミッションでホスト
bob.example.com と共有し、ホスト名の後ろに一文字分の空白があるので読み取り/書き込みパーミッ
ションで wo rld と共有します。
/tmp/nfs/ bob.example.com (rw)
showmount コマンドを使って何が共有されているかを検証するのは、設定済み NFS 共有をチェックする

よい方法です。
showmount -e <hostname>
4.3.6.4. no_root _squash オプションは使用しないでください
デフォルトで NFS 共有は、root ユーザーを権限のないユーザーアカウントである nfsnobody ユーザー

に変更します。これにより、root で作成された全ファイルの所有者は nfsnobody に変更されます。この
変更で s e tuid ビットが設定されたプログラムのアップロードが防止されます。
no_root_squash を使用すると、リモートの root ユーザーは共有ファイルシステム上のどのファイルも

変更できるようになり、トロイの木馬に感染したアプリケーションを他のユーザーが間違って実行できる状
態にしてしまいます。
4.3.6.5. NFS ファイアウォールの設定
Re d Hat Ente rpris e Linux 7 のデフォルトの NFS は NFSv4 で、この場合は TCP でポート 2049 が
開いていれば問題ありません。NFSv3 を使用していると、以下の説明にあるように、さらに 4 つのポート
が必要になります。
NFSv3 用のポート設定
NFS に使用されるポートは rpcbind が動的に割り当てますが、ファイアウォールルールの作成時に問題を

起こす恐れがあります。このプロセスを簡素化するには、/et c/sysco nf ig/nf s ファイルを使って使用
するポートを特定します。
MOUNTD_PORT — mountd (rpc.mountd) 用の TCP および UDP ポート
STATD_PORT — s tatus (rpc.s tatd) 用の TCP および UDP ポート
LOCKD_TCPPORT — nlockmgr (rpc.lockd) 用 TCP ポート
LOCKD_UDPPORT — nlockmgr (rpc.lockd) 用 UDP ポート
指定されたポート番号は、他のサービスが使用してはいけません。ポート番号の指定と TCP および UDP

ポート 2049 (NFS) を許可するようにファイアウォールを設定してください。
45
NFS サーバーで rpcinfo -p コマンドを実行し、どのポートと RPC プログラムが使用されているかを確

認します。
4.3.7. Apache HT T P サーバーのセキュア化
Apache HTTP サーバーは Re d Hat Ente rpris e Linux 7 に同梱されているサービスのなかで最も安定性

があり安全なものの一つです。Apache HTTP サーバーを安全にするには多くのオプションとテクニック
があり、ここで詳述するには多すぎるほどです。以下のセクションでは、Apache HTTP サーバー稼働時
に実行できる優れた方法を簡単に説明します。
スクリプトを実稼働環境で実行する前に、常にそのシステムがシステム上で意図したとおりに稼働してい
ることを確認してください。また、スクリプトもしくは CGI を含むディレクトリーに書き込みパーミッ
ションを持っているのは root ユーザーのみであることを確認してください。これを行うには、root ユー
ザーで以下のコマンドを実行します。
chown root <directory_name>
chmod 755 <directory_name>
以下の設定オプションを (/etc/httpd/conf/httpd.conf 内の設定で) 使用する際は、システム管理

者は注意してください。
FollowSymLinks
このディレクティブはデフォルトで有効となっているので、We b サーバーのドキュメントルー
トへのシンボリックリンク作成時には注意してください。例えば、/ へのシンボリックリンクを
提供することはよい方法ではありません。
Indexes
このディレクティブはデフォルトで有効となっていますが、これが最適ではない可能性がありま
す。ビジターがサーバー上のファイル閲覧をできないようにするには、このディレクティブを削
除します。
UserDir
UserDir はシステム上でのユーザーアカウントの有無を確認できるので、デフォルトでは無効
となっています。サーバー上のユーザーディレクトリーのブラウジングを有効にするには、以下
のディレクティブを使用します。
UserDir enabled
UserDir disabled root
これらのディレクティブは、/root/ 以外のすべてのユーザーディレクトリーのブラウジングを
有効にします。無効アカウントリストにユーザーを追加するには、UserDir disabled 行に空
白で区切ったユーザーのリストを追加します。
サーバートークン
サーバートークンディレクティブは、クライアントに返信されるサーバー応答ヘッダーフィー
ルドを制御します。これには、以下のパラメーターを使用してカスタマイズできる種々の情報が
含まれます。
ServerTokens Full (デフォルトのオプション) — (OS の種類や使用されるモジュールな

ど) 利用可能なすべての情報を提供します。例えば、
46
Apache/2.0.41 (Unix) PHP/4.2.2 MyMod/1.2
ServerTokens Prod または ServerTokens ProductOnly — 以下の情報を提供しま

す。
Apache
ServerTokens Major — 以下の情報を提供します。
Apache/2
ServerTokens Minor — 以下の情報を提供します。
Apache/2.0
ServerTokens Min または ServerTokens Minimal — 以下の情報を提供します。
Apache/2.0.41
ServerTokens OS — 以下の情報を提供します。
Apache/2.0.41 (Unix)
潜在的な攻撃者がユーザーのシステムについて価値ある情報を取得できないないようにするに
は、ServerTokens Prod の使用が推奨されます。
重要
IncludesNoExec ディレクティブは削除しないでください。デフォルトでは、Server-Side
Includes (SSI) モジュールはコマンドの実行ができません。絶対に必要な場合以外は、この設定を
変更しないことが推奨されます。変更すると、攻撃者がシステム上でコマンドを実行できるようにな
る可能性があります。
ht t pd モジュールの削除
特定のシナリオでは、特定の httpd モジュールを削除して HTTP サーバーの機能を制限した方がよい場

合もあります。これを行うには、/etc/httpd/conf/httpd.conf ファイルで削除したいモジュールを
読み込み行全体をコメントアウトするだけです。例えば、プロキシモジュールを削除するには、以下の行の
先頭にハッシュ記号を加えてコメントアウトします。
#LoadModule proxy_module modules/mod_proxy.so
/etc/httpd/conf.d/ ディレクトリーにもモジュールの読み込みに使われる設定ファイルが含まれてい
ることに注意してください。
ht t pd および SELinux
詳細情報は、Re d Hat Ente rpris e Linux 7 SELinux Us e r's and Adminis trator's Guide の The
Apache HTTP Se rve r and SELinux の章を参照してください。
47
4.3.8. FT P のセキュア化
File Transfer Protocol (FTP) は旧式の TCP プロトコルで、ネットワーク上でファイル転送するために設

計されています。ユーザー認証を含むサーバーとのトランザクションがすべて暗号化されないので、安全で
ないプロトコルとみなされ、慎重に設定する必要があります。
Re d Hat Ente rpris e Linux 7 は以下の 2 つの FTP サーバーを提供します。
Red Hat Co nt ent Accelerat o r (tux) — FTP 機能のあるカーネル空間の We b サーバーです。
vsftpd — スタンドアロンでセキュリティ重視の FTP サービス実装です。
以下のセキュリティガイドラインは vsftpd FTP サービス設定のためのものです。
4.3.8.1. FT P グリーティングバナー
ユーザー名とパスワードの送信前に、すべてのユーザーにグリーティングバナーが示されます。デフォルト
では、このバナーにはシステムの脆弱性を特定しようとしているクラッカーに有益なバージョン情報が含ま
れています。
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. #########
注記
「TCP Wrappe rおよび xine td によるサービスのセキュア化」にあるように、各行を 220 で始め

る必要はありません。
vsftpd でこのバナーを参照するようにするには、以下のディレクティブを
/etc/vsftpd/vsftpd.conf ファイルに追加します。
banner_file=/etc/banners/ftp.msg
「TCP Wrappe r と接続バナー」にあるように、 TCP Wrappe r を使って着信接続に新たなバナーを送信

することも可能です。
4.3.8.2. 匿名のアクセス
/var/ftp/ ディレクトリーが存在すると、匿名アカウントがアクティベートされます。
48
このディレクトリーを作成する最も簡単な方法は、vsftpd パッケージをインストールすることです。こ
のパッケージは、匿名ユーザー向けのディレクトリーツリーを確立し、匿名ユーザーによる読み取り専用の
パーミッションをディレクトリーに設定します。
デフォルトでは、匿名ユーザーはどのディレクトリーにも書き込みできません。
警告
FTP サーバーへの匿名アクセスを有効にする場合は、機密性の高いデータの保存場所に注意してく
ださい。
4.3.8.2.1. 匿名のアップロード
匿名ユーザーによるファイルのアップロードを許可する場合は、/var/ftp/pub/ 内に書き込み専用の
ディレクトリーを作成することが推奨されます。これを行うには、以下のコマンドを root で実行します。
~]# mkdir /var/ftp/pub/upload
次に、パーミッションを変更して、匿名ユーザーがディレクトリーのコンテンツを閲覧できないようにしま
す。
~]# chmod 730 /var/ftp/pub/upload
ディレクトリーのロング形式での一覧は以下のようなります。
~]# ls -ld /var/ftp/pub/upload

drwx-wx---. 2 root ftp 4096 Nov 14 22:57 /var/ftp/pub/upload
管理者が匿名ユーザーによるディレクトリー内での書き込みや読み取りを許可すると、そのサーバーが盗難
ソフトウェアのレポジトリになってしまう場合が多くあります。
vsftpd で、以下の行を /etc/vsftpd/vsftpd.conf ファイルに追加します。
anon_upload_enable=YES
4.3.8.3. ユーザーアカウント
FTP は安全でないネットワーク上で認証用のユーザー名とパスワードを暗号化せずに送信するので、ユー
ザーアカウントからサーバーへのシステムユーザーアクセスを拒否することはよい方法です。
vsftpd のすべてのユーザーアカウントを無効にするには、以下のディレクティブを
/etc/vsftpd/vsftpd.conf に追加します。
local_enable=NO
4.3.8.3.1. ユーザーアカウントの制限
root ユーザーや sudo 権限を持つユーザーなど、特定のアカウントや特定のアカウントグループの FTP ア

クセスを無効にする最も簡単な方法は、「Root アクセスの拒否」にあるように PAM リストファイルを使
用することです。vsftpd の PAM 設定ファイルは、/etc/pam.d/vsftpd です。
また、各サービス内で直接ユーザーアカウントを無効にすることもできます。
49
vsftpd で特定のユーザーアカウントを無効にするには、ユーザー名を/etc/vsftpd/ftpusers に追
加します。
4.3.8.4. T CP Wrapper を使用してアクセスを制御する
FTP デーモンへのアクセスを制御するには、「TCP Wrappe rおよび xine td によるサービスのセキュア

化」にあるように TCP Wrappe r を使用します。
4.3.9. Post f ix のセキュア化
Pos tfix はメール転送エージェント (MTA) で、他の MTA や Email クライアント、配信エージェント間

で電子メッセージを配信するために Simple Mail Trans fe r Protocol (SMTP) を使用します。多くの
MTA には MTA 間のトラフィックを暗号化する機能がありますが、ほとんど使用されていないので、公開
ネットワーク上での Email 送信はもともと安全でない通信方法とみなされています。Pos tfix は Re d Hat
Ente rpris e Linux 7 のデフォルトの MTA として Se ndmail に代わるものです。
Pos tfix サーバーの実装を計画している場合は、以下の問題に対処することが推奨されます。
4.3.9.1. サービス拒否攻撃を制限する
Email の性質上、攻撃者が本気になるとサーバーに大量のメールを送信し、サービス拒否を発生させること
が簡単にできます。/etc/postfix/main.cf ファイル内のディレクティブに制限を設定すると、この
ような攻撃の有効性が制限されます。既存のディレクティブの値を変更するか、以下の形式で希望する値の
必要なディレクティブを追加することもできます。
<directive> = <value>
サービス拒否攻撃の制限に使用できるディレクティブを以下に示します。
smtpd_client_connection_rate_limit — 一定の時間単位内 (下記を参照) にクライアントが

当該サーバーに接続を試みることができる最大回数。デフォルト値は 0 で、この場合クライアントは
Pos tfix が受付可能な回数内で時間単位当たり何回でも接続を試みることができます。デフォルトで
は、信頼できるネットワーク内のクライアントは除外されます。
anvil_rate_time_unit — この時間単位は割合制限の計算に使用されます。デフォルト値は 60 秒
です。
smtpd_client_event_limit_exceptions — 接続および割合制限のコマンドから除外されるク
ライアントです。デフォルトでは、信頼できるネットワーク内のクライアントは除外されます。
smtpd_client_message_rate_limit — 時間単位内でクライアントが要求可能な最大メッセージ
配信数です (Pos tfix が実際にこの数のメッセージを受け付けるかどうかは別問題です)。
default_process_limit — あるサービスを提供する Pos tfix の子プロセスの最大デフォルト数で

す。この制限は、master.cf ファイル内の特定サービスによって無効にされる場合があります。デ
フォルト値は 100 です。
queue_minfree — メール受信に必要なキューファイルシステム内での空き領域の最低バイト数で
す。これは現在、Pos tfix SMTP サーバーがメールを受信するかどうかを判断するために使用していま
す。デフォルトでは、Pos tfix SMTP サーバーは、空き領域が me s s age _s iz e _limit の 1.5 倍未満で
あれば MAIL FROM コマンドを拒否します。空き領域の最低限度をより大きくするように指定するに
は、que ue _minfre e の値が少なくとも me s s age _s iz e _limit の 1.5 倍になるように指定します。
デフォルトの que ue _minfre e 値は 0 です。
header_size_limit — メッセージヘッダー保存に使用するメモリの最大バイト数です。ヘッダー
サイズがこの制限を超える場合は、超過分が廃棄されます。デフォルト値は 102400 です。
50
message_size_limit — メッセージの最大バイト数で、これにはエンベロープ情報も含まれます。
デフォルト値は 10240000 です。
4.3.9.2. NFS と Post f ix
メールスプールディレクトリー /var/spool/postfix/ を NFS 共有ボリュームに配置しないでくださ

い。NFSv2 と NFSv3 ではユーザー ID とグループ ID の制御を維持しないので、2 人以上のユーザーが同
一 UID を持つ可能性があり、それぞれがお互いのメールを受信、閲覧してしまう可能性があります。
注記
Ke rbe ros を使用する NFSv4 ではこういうことはありません。これは SECRPC_GSS カーネルモ

ジュールが UID ベースの認証を使用しないためです。ただし、それでも NFS 共有ボリュームに
メールスプールディレクトリーを置かない方がよいと考えられます。
4.3.9.3. メール専用ユーザー
ローカルユーザーによる Pos tfix サーバーの悪用を避けるには、メールユーザーが Email プログラムを使

用して Pos tfix サーバーにアクセスするだけにするのが最善の方法です。メールサーバー上のシェルアカ
ウントを許可せず、/etc/passwd ファイル内のすべてのユーザーシェルを /sbin/nologin に設定し
ます (root ユーザーは例外とする場合もある)。
4.3.9.4. Post f ix ネットワークリスニングの無効化
デフォルトでは、Pos tfix はローカルのループバックアドレスのみをリッスンするように設定されていま

す。これは、/etc/postfix/main.cf ファイルを表示すると確認できます。
/etc/postfix/main.cf ファイルを閲覧して、以下の inet_interfaces 行のみが表示されること

を確認してください。
inet_interfaces = localhost
これにより、Pos tfix はネットワークからではなく、(cron ジョブレポートなどの) ローカルシステムから

のメールメッセージのみを受信することが確認できます。これがデフォルト設定で、Pos tfix をネットワー
ク攻撃から守ります。
ローカルホストの制限を取り除き、Pos tfix がすべてのインターフェイスをリッスンできるようにするに

は、inet_interfaces = all と設定します。
4.3.9.5. Post f ix が SASL を使用する設定
Po st f ix の Re d Hat Ente rpris e Linux 7 バージョンは、SMTP 認証 (または SMTP AUTH) に

Do veco t もしくは Cyrus SASL 実装を使用できます。SMTP 認証は、Simple Mail Transfer
Protocol の拡張機能です。これを有効にすると、SMTP クライアントはサーバーとクライアントとの両
方でサポートされ、受け入れられている認証方法を使って SMTP サーバーを認証しなくてはなりません。本
セクションでは、Do veco t SASL 実装を利用するように Po st f ix を設定する方法を説明します。
Do veco t POP/IMAP サーバーをインストールして、Do veco t SASL 実装を使用するシステム上で利用

可能とするには、root で以下のコマンドを実行します。
~]# yum install dovecot
51
Po st f ix SMTP サーバーは、UNIX ドメインソケットか TCP ソケットのいずれかを使って Do veco t

SASL 実装と通信します。後者の方法は、Po st f ix と Do veco t アプリケーションが別個のマシンで実
行中の場合にのみ、必要となります。UNIX ドメインソケットの方がよりすぐれたプライバシーを提供する
ので、本ガイドではこちらを推奨しています。
Po st f ix が Do veco t SASL 実装を使用するように指示するには、両方のアプリケーションで多くの設

定変更が必要になります。以下の手順にしたがってください。
Do veco t のセットアップ
1. Do veco t のメインの設定ファイルである /etc/dovecot/conf.d/10-master.conf に以

下の行を含めます (デフォルトの設定ファイルには、ほとんどの関連セクションがすでに記載され
ており、これらの行はコメント解除するだけです)。
service auth {
unix_listener /var/spool/postfix/private/auth {
mode = 0660
user = postfix
group = postfix
}
}
上記の例では、Po st f ix と Do veco t の通信に UNIX ドメインソケットを使用することを仮定

しています。また、Po st f ix SMTP サーバーの設定はデフォルトとしています。この設定では、
メールキューが /var/spool/postfix/ ディレクトリーに配置され、アプリケーションは
postfix のユーザーおよびグループで実行されることになります。この方法では、読み取りおよ
び書き込み許可は、postfix ユーザーおよびグループに限定されます。
別の方法では、以下の設定を使うと Do veco t は TCP 経由で Po st f ix 認証リクエストをリッ

スンするようになります。
service auth {
inet_listener {
port = 12345
}
}
上記の例では、12345 を実際に使用するポート番号に置き換えます。
2. /etc/dovecot/conf.d/10-auth.conf 設定ファイルを編集して、Do veco t が Po st f ix

SMTP サーバーに plain および login の認証メカニズムを提供するようにします。
auth_mechanisms = plain login
Po st f ix のセットアップ
Po st f ix の場合、メインの設定ファイルである /etc/postfix/main.cf を修正するだけです。以下

の設定ディレクティブを追加もしくは編集します。
1. Po st f ix SMTP サーバーの SMTP 認証を有効にします。
smtpd_sasl_auth_enable = yes
2. Po st f ix が SMTP 認証に Do veco t SASL 実装を使用するように指示します。
52
smtpd_sasl_type = dovecot
3. Po st f ix キューディレクトリーの認証相対パスを提供します (相対パスを使用すること
で、Po st f ix サーバーが chro o t で稼働しているかどうかにかかわらず、この設定が確実に機
能するようになります)。
smtpd_sasl_path = private/auth
この手順では、Po st f ix と Do veco t の通信に UNIX ドメインソケットを使用することを仮定

しています。通信に TCP ソケットを使用する場合で、Po st f ix が別のマシンにある Do veco t
を探すように設定するには、以下のような設定値を使用します。
smtpd_sasl_path = inet:127.0.0.1:12345
上記の例では、127.0.0.1 を Do veco t マシンの IP アドレスに、12345 を Do veco t の

/etc/dovecot/conf.d/10-master.conf 設定ファイルで指定されているポート番号に置き
換えます。
4. Po st f ix SMTP サーバーがクライアントに対して利用可能とする SASL メカニズムを指定しま

す。暗号化セッションと非暗号化セッションでは、異なるメカニズムを設定できることに注意して
ください。
smtpd_sasl_security_options = noanonymous, noplaintext

smtpd_sasl_tls_security_options = noanonymous
上記の例では、非暗号化セッション中は匿名認証が許可されず、また暗号化されていないユーザー
名やパスワードを送信するメカニズムも許可されません。(TLS を使った) 暗号化セッションでは、
匿名でない認証メカニズムのみが許可されます。
許可される SASL メカニズムを制限する対応ポリシー全一覧

は、http://www.pos tfix.org/SASL_README.html#s mtpd_s as l_s e curity_options を参照し
てください。
その他のリソース
以下のオンラインのリソースでは、SASL による Po st f ix SMTP 認証の設定に便利な追加情報が提供さ

れています。
http://wiki2.dove cot.org/HowTo/Pos tfixAndDove cotSASL — SMTP 認証に Do veco t SASL 実

装を使用するための Po st f ix の設定方法が説明されています。
http://www.pos tfix.org/SASL_README.html#s e rve r_s as l — SMTP 認証に Do veco t または

Cyrus SASL 実装を使用するための Po st f ix の設定方法が説明されています。
4.3.10. SSH のセキュア化
Secure Shell (SSH) は、セキュアなチャネル上で別のシステムと通信するために使用される強力なネット

ワークプロトコルです。SSH 上の送信は暗号化され、傍受から保護されます。暗号化ログインを使用して、
従来のユーザー名とパスワードよりも優れた認証方法を提供することもできます。SSH プロトコルと
Re d Hat Ente rpris e Linux 7 における SSH サービスの使用方法についての一般的な情報は、Re d Hat
Ente rpris e Linux 7 システム管理者のガイドの Ope nSSH の章を参照してください。
53
重要
本セクションでは、SSH 設定のセキュア化における最も一般的な方法にフォーカスしてきました。
ただし、ここで提案された方法が網羅的または決定的であるというわけではありません。sshd デー
モンの動作修正に利用可能な設定ディレクティブすべてについての説明は sshd_config(5) の
man ページを、基本的な SSH の概念については ssh(1) の man ページを参照してください。
4.3.10.1. 暗号化ログイン
SSH は、コンピューターにログインするための暗号化鍵の使用をサポートしています。これはパスワード
のみの使用よりもはるかに安全です。この方法を他の認証方法と組み合わせると、マルチファクター認証
(multifactor authe ntication) と見なすことができます。マルチ認証方法についての詳細は、「複数の認
証方法」を参照してください。
認証における暗号鍵の使用を有効にするには、/etc/ssh/sshd_config ファイルの
PubkeyAuthentication 設定ディレクティブを yes に設定する必要があります。これがデフォルト設
定であることに注意してください。PasswordAuthentication ディレクティブを no に設定すると、
ログインでのパスワード使用が無効になります。
SSH 鍵は ssh-keygen コマンドを使って生成できます。引数なしでこれを実行すると、2048 ビットの

RSA 鍵のセットが作成されます。デフォルトでは、この鍵は ~/.ssh ディレクトリーに保存されます。-
b スイッチを使うと、鍵のビット強度を修正することができます。通常は、2048 ビット鍵で十分な強度が
提供されます。鍵のペアの生成に関する詳細情報は、Re d Hat Ente rpris e Linux 7 システム管理者のガ
イドの Ope nSSH の設定の章を参照してください。
~/.ssh ディレクトリーに、2 つの鍵が見つかるはずです。ssh-keygen コマンドの実行時にデフォルト

を受け入れると、生成されるファイル名は id_rsa と id_rsa.pub になり、それぞれに秘密鍵と公開鍵
が含まれます。秘密鍵はファイルの所有者のみが読み取り可能として、公開されないように常に保護してく
ださい。ただし公開鍵は、ログインするシステムに送信する必要があります。ssh-copy-id コマンドを
使用すると、サーバーにこの鍵を移動することができます。
~]$ ssh-copy-id -i [user@]server
このコマンドは、server 上の ~/.ssh/authorized_key ファイルに自動で公開鍵を追加します。ユー

ザーがサーバーへのログインを試みる際には、sshd デーモンがこのファイルをチェックします。
パスワードやその他の認証メカニズムと同様に、SSH 鍵は定期的に変更する必要があります。この
際、authorized_key ファイルから使用されていない鍵を必ず消去してください。
4.3.10.2. 複数の認証方法
マルチファクター認証とも呼ばれる複数の認証方式を使用すると、権限のないアクセスに対する保護のレベ
ルが高まります。このため、システムのセキュリティを強化する際には、マルチファクター認証を検討して
ください。マルチファクター認証を使用するシステムにログインしようとすると、ユーザーは指定されたす
べての認証方式で成功しないと、アクセスが認められません。
使用する認証方式を指定するには、/etc/ssh/sshd_config ファイル内の
AuthenticationMethods 設定ディレクティブを使用します。このディレクティブでは、必要となる認
証方式の複数のリストを定義できることに注意してください。複数を定義する場合は、各方式を少なくとも
1 つのリストで定義する必要があります。各リストは空白で区切ります。リスト内の各認証方式の名前はコ
ンマ区切りとします。例を示します。
AuthenticationMethods publickey,gssapi-with-mic publickey,keyboard-

interactive
54
上記の AuthenticationMethods ディレクティブを使って設定された sshd デーモンは、ユーザーが

publickey 認証の後に gssapi-with-mic または keyboard-interactive 認証でログインを完了
した場合にのみ、アクセスを許可します。必要とされる認証方式はそれぞれ、/etc/ssh/sshd_config
ファイル内の対応する設定ディレクティブ (PubkeyAuthentication など) で明示的に有効となってい
る必要があることに注意してください。利用可能な認証方式の全般的なリストは、ssh(1) man ページの
『AUTHENTICATION』セクションを参照してください。
4.3.10.3. SSH の他のセキュア化
プロトコルのバージョン
Re d Hat Ente rpris e Linux 7 で提供される SSH プロトコルは SSH-1 と SSH-2 の両バージョンをサ
ポートしますが、可能な場合は常に後者のみを使用してください。SSH-2 バージョンには、旧式の SSH-1
の多くの改善点が含まれており、高度な設定オプションの多くは SSH-2 でのみ使用可能となっています。
SSH プロトコルによる認証と対象となる通信の保護を最大限まで活用するために、ユーザーは SSH-2 を使

用することが推奨されます。sshd デーモンがサポートするプロトコルのバージョン
は、/etc/ssh/sshd_config ファイル内で Protocol 設定ディレクティブを使って指定できます。デ
フォルト設定は 2 になります。
鍵のタイプ
ssh-keygen コマンドはデフォルトで SSH-2 RSA 鍵のペアを生成しますが、-t オプションを使う

と、DSA または ECDSA 鍵を生成するように指示することもできます。ECDSA (Elliptic Curve Digital
Signature Algorithm) は、同じ対称鍵の長さでより優れたパフォーマンスを提供します。また、より短い
鍵も生成します。
デフォルト以外のポート
デフォルトでは、sshd デーモンは 22 ネットワークポートをリッスンします。ポートを変更すると、自動

ネットワークスキャンをベースとする攻撃に対するシステムの露出を減らすことになるので、曖昧さによっ
てセキュリティが増します。ポートは、/etc/ssh/sshd_config ファイルの Port ディレクティブで
指定できます。デフォルト以外のポート使用を可能にするには、デフォルトの SELinux ポリシーの変更も
必要になることに注意してください。これは、root で以下のコマンドを実行して ssh_port_t SELinux
タイプを修正することで可能になります。
~]# semanage -a -t ssh_port_t -p tcp port_number
上記のコマンドでは、port_number を Port ディレクティブで指定する新たなポート番号に置き換えま

す。
Ro o t 以外のログイン
特定のユースケースで root ユーザーとしてのログインが必要ない場合は、/etc/ssh/sshd_config

ファイルで PermitRootLogin 設定ディレクティブを no に設定することを検討してください。root
ユーザーとしてのログインの可能性をなくすことで、どのユーザーが通常のユーザーとしてログインした後
に root 権限を獲得し、権限のあるコマンドを実行したかを管理者が監査できるようになります。
4.4. ネットワークアクセスのセキュア化
4.4.1. T CP Wrapperおよび xinet d によるサービスのセキュア化
TCP Wrappe r では、単にサービスへのアクセスを拒否する以上のことができます。このセクションで

は、TCP Wrappe rを使って接続バナーを送信し、特定ホストからの攻撃に対して警告し、ロギング機能を
強化する方法を説明します。TCP Wrappe r の機能と制御言語についての情報は、hosts_options(5)
55
man ページを参照してください。サービスに適用可能なオプションとして機能する利用可能なフラグにつ
いては、xinetd.conf(5) man ページを参照してください。
4.4.1.1. T CP Wrapper と接続バナー
システム管理者が警戒していることを潜在的な攻撃者に知らせるには、ユーザーがサービスに接続する際に
適切なバナーを表示させるのがよい方法です。また、ユーザーに対してシステムのどの情報を表示させるか
を制御することもできます。サービスに TCP Wrappe r のバナーを実装するには、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/
4.4.1.2. T CP Wrapper と攻撃警告
特定のホストまたはネットワークによるサーバーへの攻撃が検出された場合、TCP Wrappe r は spawn

ディレクティブを使ってそのホストまたはネットワークからのその後の攻撃について管理者に警告すること
ができます。
以下の例では、206.182.68.0/24 ネットワークからのクラッカーがサーバーに攻撃を仕掛けようとしてい
ることが検出されたとします。/etc/hosts.deny ファイルに以下の行を挿入すると、そのネットワーク
からの接続の試みが拒否され、特別ファイルにログ記録されます。
ALL : 206.182.68.0 : spawn /bin/echo `date` %c %d >>

/var/log/intruder_alert
%d トークンは、攻撃者がアクセスを試みるサービス名を提供します。
接続とログインを許可するには、 spawn ディレクティブを /etc/hosts.allow ファイル内に置きま

す。
注記
spawn ディレクティブはどんなシェルコマンドも実行するので、特定のクライアントがサーバーに
接続しようとする際に、管理者に通知したり一連のコマンドを実行したりする特別スクリプトを作成
するとよいでしょう。
4.4.1.3. T CP Wrapper とロギングの強化
56
特定の種類の接続が他のものよりも懸念される場合は、severity オプションを使うと該当サービスに対
するログレベルを高めることができます。
以下の例では、FTP サーバーのポート 23 (Te lne t ポート) への接続はクラッカーによるものとします。こ

れを示すために、デフォルトのフラグである info の代わりに emerg フラグをログファイルに置いて接
続を拒否します。
これを実行するには、以下の行を /etc/hosts.deny に挿入します。
in.telnetd : ALL : severity emerg
これはデフォルトの authpriv ロギング機能を使用しますが、優先順位をデフォルト値の info から

emerg に引き上げ、ログメッセージを直接コンソールに投稿します。
4.4.2. リッスンしているポートの確認
ポートを必要以上に開くとシステムの攻撃対象領域を増やすことになるので、避けるべきです。システムが
サービスを開始した後で予期しないポートがリスニング状態になっている場合は、侵入の形跡である可能性
があり、調査が必要になります。
root でコンソールから以下のコマンドを実行して、ネットワークからの接続をリッスンしているポートを
判断します。
~]# netstat -pan -A inet,inet6 | grep -v ESTABLISHED

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
PID/Program name
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
1608/rpcbind
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN
2581/unbound
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
2048/sshd
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN
3202/cupsd
tcp 0 0 0.0.0.0:54136 0.0.0.0:* LISTEN
2279/rpc.statd
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN
2708/master
tcp 0 0 127.0.0.1:8953 0.0.0.0:* LISTEN
2581/unbound
tcp 0 0 127.0.0.1:8955 0.0.0.0:* LISTEN
2634/dnssec-trigger
tcp6 0 0 :::111 :::* LISTEN
1608/rpcbind
tcp6 0 0 :::60881 :::* LISTEN
2279/rpc.statd
tcp6 0 0 ::1:53 :::* LISTEN
2581/unbound
tcp6 0 0 :::22 :::* LISTEN
2048/sshd
tcp6 0 0 ::1:631 :::* LISTEN
3202/cupsd
tcp6 0 0 ::1:25 :::* LISTEN
2708/master
tcp6 0 0 ::1:8953 :::* LISTEN
57
2581/unbound
udp 0 0 127.0.0.1:766 0.0.0.0:*
2279/rpc.statd
udp 0 0 0.0.0.0:59186 0.0.0.0:*
674/avahi-daemon: r
udp 0 0 0.0.0.0:33639 0.0.0.0:*
2279/rpc.statd
udp 0 0 0.0.0.0:889 0.0.0.0:*
1608/rpcbind
udp 0 0 127.0.0.1:53 0.0.0.0:*
2581/unbound
udp 0 0 0.0.0.0:68 0.0.0.0:*
2642/dhclient
udp 0 0 0.0.0.0:111 0.0.0.0:*
1608/rpcbind
udp 0 0 0.0.0.0:46198 0.0.0.0:*
2642/dhclient
udp 0 0 0.0.0.0:123 0.0.0.0:*
697/chronyd
udp 0 0 0.0.0.0:5353 0.0.0.0:*
674/avahi-daemon: r
udp 0 0 127.0.0.1:323 0.0.0.0:*
697/chronyd
udp6 0 0 :::3885 :::*
2642/dhclient
udp6 0 0 :::889 :::*
1608/rpcbind
udp6 0 0 ::1:53 :::*
2581/unbound
udp6 0 0 :::111 :::*
1608/rpcbind
udp6 0 0 :::123 :::*
697/chronyd
udp6 0 0 ::1:323 :::*
697/chronyd
udp6 0 0 :::33235 :::*
2279/rpc.statd
raw6 0 0 :::58 :::* 7
2612/NetworkManager
本ガイドの作成時点では、-l オプションは SCTP サーバーを一覧表示していないことに注意してくださ

い。
システムで必要なサービスをコマンドの出力で確認して、特に必要でないものや権限が与えられていないも
のをオフにしてから、再度チェックを実行します。次に、ネットワーク経由で最初のシステムに接続してい
る別のシステムから nmap を使用して、外部チェックを行います。これは、ipt ables のルールの確認
に使用できます。外部システムから ss 出力で表示されているすべての IP アドレス (localhos t 127.0.0.0
または ::1 レンジを除く) をスキャンします。IPv6 のスキャンには -6 オプションを使用します。詳細は
man nmap(1) を参照してください。
以下は、ネットワークからの TCP 接続をリッスンしているポートを判断するために、別のシステムのコン

ソールから発行するコマンドの例です。
~]# nmap -sT -O 192.168.122.1
詳細は ss、nmap、services の man ページを参照してください。
58
4.4.3. ソースルーティングの無効化
ソースルーティングはインターネットプロトコルメカニズムで、IP パケットがアドレス一覧の情報を持ち
運べるようにします。このアドレスは、パケットが通過する必要のあるパスをルーターに知らせるもので
す。ルートを移動する際にホップを記録するオプションもあります。「ルート記録」と呼ばれるホップの記
録は、宛先にソースまでの帰りのパスを提供します。これによりソースは (つまり送信ホスト)、すべてもし
くは一部のルーターのルーティングテーブルを無視して、ルートを厳密もしくは緩やかに特定することがで
きます。これによりユーザーは、不正目的でネットワークトラフィックをリダイレクトすることが可能にな
ります。このため、ソースベースのルーティングは無効にする必要があります。
accept_source_route オプションを使用すると、ネットワークインターフェイスが厳密なソースルー

ト (SSR) もしくは緩やかなソースルーティング (LSR) オプションセットのあるパケットを受け付けるよ
うになります。ソースルーティングパケットの受け付けは s ys ctl 設定で制御します。以下のコマンドを
root で実行し、SSR または LSR オプションセットのあるパケットを遮断します。
~]# /sbin/sysctl -w net.ipv4.conf.all.accept_source_route=0
パケット転送の無効化は、可能な場合は上記のコマンドと合わせて行うべきです (転送の無効化は仮想化に
影響する場合があります)。以下のコマンドを root で発行します。
以下のコマンドはすべてのインターフェイスで IPv4 および IPv6 パケットの転送を無効にします。
~]# /sbin/sysctl -w net.ipv4.conf.all.forwarding=0
~]# /sbin/sysctl -w net.ipv6.conf.all.forwarding=0
以下のコマンドはすべてのインターフェイスですべてのマルチキャストパケットの転送を無効にします。
~]# /sbin/sysctl -w net.ipv4.conf.all.mc_forwarding=0
~]# /sbin/sysctl -w net.ipv6.conf.all.mc_forwarding=0
ICMP リダイレクトの受信が正当に使用される場合はほとんどありません。ICMP リダイレクトパケットは

特に必要でなければ、その受信と送信を無効にしてください。
以下のコマンドはすべてのインターフェイスですべての ICMP リダイレクトパケットの受信を無効にしま

す。
~]# /sbin/sysctl -w net.ipv4.conf.all.accept_redirects=0
~]# /sbin/sysctl -w net.ipv6.conf.all.accept_redirects=0
以下のコマンドはすべてのインターフェイスでセキュアな ICMP リダイレクトパケットの受信を無効にし

ます。
~]# /sbin/sysctl -w net.ipv4.conf.all.secure_redirects=0
以下のコマンドはすべてのインターフェイスですべての IPv4 ICMP リダイレクトパケットの受信を無効に

します。
~]# /sbin/sysctl -w net.ipv4.conf.all.send_redirects=0
59
IPv4 リダイレクトパケットの送信を無効にできるのはディレクティブのみです。IPv4 と IPv6 の差異を

生み出している「IPv6 Node Re quire me nts 」の説明については、RFC4294 を参照してください。
設定を永続的なものにするには、その設定を /etc/sysctl.conf に追加する必要があります。
詳細は s ys ctl の man ページ sysctl(8) を参照してください。ソースベースのルーティングおよびそ

のバリエーションに関連するインターネットオプションの説明については、RFC791 を参照してくださ
い。
警告
イーサネットネットワークは、ARP や MAC アドレススプーフィング、権限のない DHCP サー

バー、IPv6 ルーターまたは近隣アドバタイズメントといったトラフィックをリダイレクトする新た
な方法を提供します。さらに、ユニキャストトラフィックはブロードキャストの場合もたまにあ
り、情報の漏洩を引き起こします。これらの脆弱性は、ネットワークオペレーター導入する特定の対
策によってのみ、対処可能になります。ホストベースの対応策の有効性は、完全なものではありませ
ん。
4.4.4. 逆方向パス転送
逆方向パス転送は、あるインターフェイスから着信したパケットが異なるインターフェイス経由で去ってし
まうことを防ぐために使用されます。送信ルートと着信ルートが異なる場合は、非対称ルーティングと呼
ばれる場合もあります。ルーターがパケットをこの方法でルート設定することはよくありますが、ほとんど
のホストはこのようなことをする必要はないはずです。例外として挙げられるのは、トラフィックをあるリ
ンクで送信し、異なるサービスプロバイダーから別のリンクでトラフィックを受け取るアプリケーションで
す。例えば、xDSL との組み合わせで専用回線を使っている場合や、3G モデムを使ったサテライトリンク
などの場合です。このようなシナリオが該当する場合は、着信インターフェイスで逆方向パス転送をオフに
することが必要になります。つまり、これが必要だと分かっている場合を除いて、有効にしておくのが最善
の方法です。これは、ローカルサブネットからユーザーが IP アドレスをスプーフィングすることを防
ぎ、DDoS 攻撃の機会を減らすためです。
注記
Re d Hat Ente rpris e Linux 7 はデフォルトで厳密な逆方向パス転送を使用します。これは、RFC

3704 の Ingre s s Filte ring for Multihome d Ne tworks からの厳密な逆方向パスに関する推奨事
項に準拠したものです。現在これが適用されるのは、IPv4 のみです。
警告
転送が有効になっていれば、(ipt ables ルールなど) ソースアドレス確認に他の方法がある場合に

のみ、逆方向パス転送を無効にしてください。
rp_filter
逆方向パス転送は rp_filter ディレクティブで有効にします。rp_filter オプションは、3

つのモードから 1 つを選択するようにカーネルに指示します。
デフォルト動作の設定時には以下の形式になります。
~]# /sbin/sysctl -w net.ipv4.conf.default.rp_filter=INTEGER
60
ここでの INTEGER は、以下のいずれかになります。
0 — ソース確認なし
1 — RFC3704 で定義された厳密モード
2 — RFC3704 で定義された緩やかなモード
この設定はネットワークインターフェイスごとに net.ipv4.interface.rp_filter を使っ

て無効にすることが可能です。これらの設定を再起動後も維持するには、/etc/sysctl.conf
ファイルを修正します。
4.4.4.1. その他のリソース
以下のリソースでは、逆方向パス転送について詳細な説明が提供されています。
便利なウェブサイト
Ingre s s Filte ring for Multihome d Ne tworks の説明については、RFC3704 を参照してください。
/proc/sys/net/ipv4/ ディレクトリーで使用可能なファイルおよびオプションの一覧について
は、https ://www.ke rne l.org/doc/Docume ntation/ne tworking/ip-s ys ctl.txt を参照してくださ
い。
4.5. ファイアウォールの使用
4.5.1. f irewalld の概要
動的ファイアウォールデーモンである firewalld は、動的に管理されるファイアウォールを提供し、信

頼レベルをネットワークと関連する接続およびインターフェイスに割り当てるネットワーク「ゾーン」をサ
ポートします。これは、IPv4 および IPv6 のファイアウォール設定をサポートします。また、イーサ
ネットブリッジをサポートし、実行時と永続的な設定オプションを別々にすることできます。ファイア
ウォールルールを直接追加するためのサービスやアプリケーション向けのインターフェースもあります。
4.5.2. f irewalld について
firewalld は、グラフィカルな設定ツールである f irewall-co nf ig で設定します。fire walld は、

カーネルにある Net f ilt er と ipt ables t o o l を使用して通信します。パケットフィルタリングの実装
は、Ne tfilte r が行います。
グラフィカルの f irewall-co nf ig ツールを使用するには、Super キーを押してアクティビティを開

き、firewall と入力してから Enter を押します。f irewall-co nf ig ツールが表示され、管理者パス
ワードの入力が求められます。
f irewall-co nf ig ツールには、設定のラベルが付いたドロップダウンメニューがあります。ここで、実

行時と永続のモードが選べます。永続を選ぶと、左下に新たなアイコンの列が表示されます。サービス
のパラメーターは実行時モードでは変更できないため、これらのアイコンは永続モードでのみ表示されま
す。
firewalld が提供するファイアウォールのサービスは、設定の変更はいつでも可能で即座に実行されるの
で、静的ではなく動的なものです。変更は保存したり適用したりする必要がありません。ファイアウォール
はリロードの必要がないので、既存のネットワーク接続が意図せずに中断されることがありません。
コマンドラインクライアントである f irewall-cmd が提供され、これを使うと man firewall-

cmd(1) で説明されている永続および非永続の実行時の変更を行うことができます。永続的な変更
は、firewalld(1) man ページの説明にしたがってください。firewall-cmd コマンドは、root
61
ユーザーと管理者ユーザーといういわゆる wheel グループのメンバーのみが実行できることに注意してく

ださい。管理者ユーザーの場合は、po lkit メカニズム経由でコマンドが承認されます。
firewalld の設定は、様々な XML ファイルで /usr/lib/firewalld/ と /etc/firewalld/ に保

存されます。これらのファイルは修正、書き込み、バックアップ、他のインストールへのテンプレートとし
ての使用などができるので、柔軟性が高まります。
他のアプリケーションは、D-bus を使って firewalld と通信できます。
4.5.3. f irewalld と syst em-conf ig-f irewall および ipt ables との比較
firewalld と ipt ables service の本質的な違いは、以下の通りです。
ipt ables service は設定を /etc/sysconfig/iptables に保存しますが、firewalld は様々

な XML ファイルで /usr/lib/firewalld/ および /etc/firewalld/ に保存します。Re d Hat
Ente rpris e Linux では firewalld がデフォルトでインストールされるの
で、/etc/sysconfig/iptables ファイルがないことに注意してください。
ipt ables service では変更のひとつひとつで古いルールがフラッシュされ新しいルールが

/etc/sysconfig/iptables から読み込まれますが、firewalld ではそのようなすべてのルール
の再生はなく、差異のみが適用されます。このため、firewalld では既存の接続が中断されることな
く実行時に設定変更ができます。
これら両方が ipt ables t o o l を使用してカーネルパケットフィルターと通信します。
62
図4.1 ファイアウォールスタック
4.5.4. ネットワークゾーンについて
ファイアウォールを使うと、ユーザーがネットワーク内のデバイスとトラフィックに配置する信頼レベル
に基づいて、ネットワークを異なるゾーンに分けることができます。Net wo rkManager が
firewalld にインターフェイスが所属するゾーンを通知します。インターフェイスに割り当てられたゾー
ンは Net wo rkManager で、または関連する Net wo rkManager ウィンドウを開く f irewall-
co nf ig ツール経由で変更できます。
/etc/firewalld/ におけるゾーン設定は、ネットワークインターフェイスにすぐに適用可能な事前設定
の範囲です。以下でこれらを簡単に説明します。
drop
着信ネットワークパケットはすべて遮断され、返信されません。送信ネットワーク接続のみが可
能です。
block
63
IPv4 では icmp-hos t-prohibite d メッセージで、IPv6 では icmp6-adm-prohibite d メッ

セージですべての着信ネットワーク接続が拒否されます。システム内で開始されたネットワーク
接続のみが可能です。
public
公開エリア用です。自分のコンピューターを保護するため、ネットワーク上の他のコンピュー
ターを信頼しません。選択された着信接続のみが許可されます。
external
マスカレードを特別にルーター用に有効にした外部ネットワーク上での使用向けです。自分のコ
ンピューターを保護するため、ネットワーク上の他のコンピューターを信頼しません。選択され
た着信接続のみが許可されます。
dmz
公開アクセスが可能ではあるものの、内部ネットワークへのアクセスには制限がある非武装地帯
にあるコンピューター用。選択された着信接続のみが許可されます。
work
作業エリア用です。自分のコンピューターを保護するため、ネットワーク上の他のコンピュー
ターをほぼ信頼します。選択された着信接続のみが許可されます。
home
ホームエリア用です。自分のコンピューターを保護するため、ネットワーク上の他のコンピュー
ターをほぼ信頼します。選択された着信接続のみが許可されます。
internal
内部ネットワーク用です。自分のコンピューターを保護するため、ネットワーク上の他のコン
ピューターをほぼ信頼します。選択された着信接続のみが許可されます。
trusted
すべてのネットワーク接続が許可されます。
これらのゾーンのいずれかをデフォルトに指定することができます。インターフェイス接続が
Net wo rkManager に追加されると、デフォルトのゾーンに割り当てられます。インストール時に
は、firewalld のデフォルトは public ゾーンに設定されます。
4.5.5. ネットワークゾーンの選択
ネットワークゾーンの名前は、すぐに分かりユーザーが妥当な決定をすばやく下せるように付けられていま
す。ただし、ユーザーのニーズおよびリスク評価に合わせて、デフォルト設定の見直しを行ったり、不要な
サービスを無効にしてください。
4.5.6. 事前定義のサービスについて
サービスは、ローカルポートと宛先のリストとするか、サービスが有効な場合に自動的に読み込まれるファ
イアウォールヘルパーのモジュールのリストとすることができます。事前定義サービスを使用すると、ユー
ザーによるサービスへのアクセスの有効、無効の切り替えが容易になります。ポートやポート範囲を開くの
ではなく、事前定義のサービスまたはカスタム定義のサービスを使用すると、管理が容易になる場合があり
ます。サービスの設定オプションと一般的なファイル情報は、firewalld.service(5) man ページで
説明されています。サービスは個別の XML 設定ファイルで指定されており、これらのファイル名の形式
は、service-name.xml となります。
64
グラフィカルの f irewall-co nf ig ツールを使用してサービス一覧を表示するには、Super キーを押し

てアクティビティを開き、firewall と入力してから Enter を押します。f irewall-co nf ig ツールが
表示され、管理者パスワードの入力が求められます。サービスタブでサービスの一覧を確認できます。
コマンドラインを使用してデフォルトの利用可能な事前定義サービスを一覧表示するには、root で以下の
コマンドを実行します。
~]# ls /usr/lib/firewalld/services/
/usr/lib/firewalld/services/ にあるファイルは編集しないでくださ
い。/etc/firewalld/services/ にあるファイルのみを編集してください。
システムもしくはユーザーが作成したサービスを一覧表示するには、root で以下のコマンドを実行しま
す。
~]# ls /etc/firewalld/services/
サービスの追加もしくは削除は、グラフィカルの f irewall-co nf ig ツールを使用する

か、/etc/firewalld/services/ にある XML ファイルを編集することで実行できます。ユーザーが
サービスを追加もしくは変更していない場合、そのサービスに対応する XML ファイルは
/etc/firewalld/services/ にありません。サービスの追加または変更に
は、/usr/lib/firewalld/services/ のファイルをテンプレートとして使うことが可能です。root
で以下の形式でコマンドを実行します。
~]# cp /usr/lib/firewalld/services/[service].xml
/etc/firewalld/services/[service].xml
この後に、新規作成されたファイルを編集することができます。firewalld はファイルが
/etc/firewalld/services/ にあることを好みますが、もしファイルが削除されてしまった場合で
も、/usr/lib/firewalld/services/ にフォールバックします。ただし、これはリロードの後にな
ります。
4.5.7. ダイレクトインターフェイスについて
firewalld には、ルールを直接 ipt ables、ip6t ables、および ebt ables に渡すことを可能にす

る「ダイレクトインターフェイス」と呼ばれるものがあります。これはユーザーではなく、アプリケー
ションが使用するものです。ipt ables に精通していないと意図せずにファイアウォール侵害を引き起こ
す可能性があるので、ダイレクトインターフェイスを使用することは危険です。firewalld は追加された
ものを追跡するので、firewalld にクエリを行い、ダイレクトインターフェイスモードを使用してアプリ
ケーションが行った変更を確認することができます。ダイレクトインターフェイスは、--direct オプ
ションを firewall-cmd コマンドに追加すると使用できます。
ダイレクトインターフェイスモードは、サービスもしくはアプリケーションが実行時に特定のファイア
ウォールルールを追加するためのものです。--permanent オプションを追加して firewall-cmd --
permanent --direct コマンドを使用するか、/etc/firewalld/direct.xml を修正することで、
ルールを永続的なものにできます。ルールが永続的になっていないと、D-BUS を使用して firewalld か
ら開始、再開、リロードのメッセージを受け取るたびに毎回適用する必要があります。
4.5.8. f irewalld のインストール確認
Re d Hat Ente rpris e Linux 7 では、デフォルトで firewalld とグラフィカルのユーザーインターフェ

イス設定ツールである f irewall-co nf ig がインストールされます。root で以下のコマンドを実行する
と、これが確認できます。
~]# yum install firewalld firewall-config
65
4.5.9. f irewalld の無効化
firewalld を無効にするには、root で以下のコマンドを実行します。
~]# systemctl disable firewalld

# systemctl stop firewalld
4.5.10. ipt ables サービスの使用
firewalld の代わりにiptables および ip6tables の各サービスを使用するには、まず root で以下

のコマンドを実行して firewalld を無効にします。
~]# systemctl disable firewalld

# systemctl stop firewalld
そして root で以下のコマンドを実行して、iptables-services パッケージをインストールします。
~]# yum install iptables-services
iptables-services パッケージには、iptables と ip6tables のサービスが含まれています。
インストール後に root で以下のコマンドを実行して、iptables および ip6tables のサービスを開始

します。
# systemctl start iptables

# systemctl start ip6tables
# systemctl enable iptables
# systemctl enable ip6tables
4.5.11. f irewalld の開始
firewalld を起動するには、root で以下のコマンドを実行します。
~]# systemctl start firewalld
4.5.12. f irewalld の稼働確認
firewalld が稼働しているかどうかを確認するには、以下のコマンドを実行します。
~]$ systemctl status firewalld

firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled)
Active: active (running) since Sat 2013-04-06 22:56:59 CEST; 2 days
ago
Main PID: 688 (firewalld)
CGroup: name=systemd:/system/firewalld.service
さらに、f irewall-cmd がデーモンに接続可能かどうかを確認するには、以下のコマンドを実行します。
66
~]$ firewall-cmd --state

running
4.5.13. f irewalld のインストール
firewalld をインストールするには、root で以下のコマンドを実行します。
~]# yum install firewalld
グラフィカルユーザーインターフェイスツールの firewall-config をインストールするには、root で以下

のコマンドを実行します。
~]# yum install firewall-config
4.5.14. ファイアウォールの設定
ファイアウォールの設定は、グラフィカルユーザーインターフェイスツール f irewall-co nf ig の使用、

コマンドラインインターフェイスツール f irewall-cmd の使用、XML 設定ファイルの編集のいずれかで
実行できます。これらの方法を順番に説明します。
4.5.14.1. グラフィカルユーザーインターフェイスを使ったファイアウォールの設定
4.5.14.1.1. グラフィカルファイアウォール設定ツールの起動
グラフィカルの f irewall-co nf ig ツールを起動するには、Super キーを押してアクティビティを開

き、firewall と入力してから Enter を押します。f irewall-co nf ig ツールが表示され、管理者パス
ワードの入力が求められます。
コマンドラインを使ってグラフィカルなファイアウォール設定ツールを起動するには、root で以下のコマ
ンドを入力します。
~]# firewall-config
ファイアウォールの設定ウィンドウが開きます。このコマンドは一般ユーザーとしても実行できます
が、その場合は時折、管理者パスワードの入力を求められることに注意してください。
67
図4.2 ファイアウォール設定ツール
ウィンドウ左下の「接続しました」の表示を確認してください。これは、f irewall-co nf ig ツールが

ユーザースペースデーモン firewalld に接続されていることを示します。ICMP タイプ、ダイレクト
設定、およびロックダウン・ホワイトリストのタブは、表示のドロップダウンメニューから選択した
後にのみ、表示されることに注意してください。
4.5.14.1.2. ファイアウォールの設定変更
現行のファイアウォール設定を直ちに変更するには、現在の表示が実行時に設定されていることを確認し

てください。次回のシステム起動時またはファイアウォールの再読み込み時に設定が適用されるようにする
には、ドロップダウンリストから永続を選択します。
注記
実行時モードでファイアウォール設定を変更する際には、サービスに関連するチェックボックスに
チェックを入れたり消したりすると、その選択が直ちに反映されます。他のユーザーが使用している
可能性のあるシステムでこの作業を行う場合は、この点を考慮してください。
永続モードでファイアウォール設定を変更すると、ファイアウォールを再読み込みした場合かシス
テムの再起動時にのみ変更が反映されます。ファイルメニューの下にある再読み込みアイコンを使
用するか、オプションメニューをクリックして Firewalld の再読み込みを選択します。
ゾーンは左側のコラムで選択できます。ゾーンには有効になっているサービスがいくつかあり、すべてを閲
覧するにはウィンドウのサイズを変更するか、スクロールする必要がある場合があります。サービスを選択
および選択解除することで、設定をカスタマイズできます。
68
4.5.14.1.3. インターフェースをゾーンに追加する
接続インターフェイスをゾーンに追加したり再度割り当てるには、f irewall-co nf ig を開始して、メ

ニューバーからオプションを選び、ドロップダウンメニューから接続のゾーンの変更を選択する
と、ネットワーク接続のリストが表示されます。ここで、再度割り当てる接続を選択します。接続の
ゾーンを選択するのウィンドウが表示されます。ドロップダウンメニューから新規のファイアウォール
ゾーンを選択して OK をクリックします。
4.5.14.1.4. デフォルトゾーンの設定
新たなインターフェイスに割り当てるデフォルトのゾーンを設定するには、f irewall-co nf ig を開始し

て、メニューバーからオプションを選び、ドロップダウンメニューから標準のゾーンの変更を選択し
ます。標準ゾーンのウィンドウが表示されるので、デフォルトのゾーンとして使用するゾーンをリストか
ら選択して OK をクリックします。
4.5.14.1.5. サービスの設定
事前定義またはカスタマイズサービスを有効、無効にするには、f irewall-co nf ig ツールを起動して、

設定するサービスのネットワークゾーンを選択します。サービスタブを選択し、信頼するサービスの各タ
イプのチェックボックスを選択します。サービスをブロックするには、チェックボックスを外します。
サービスを編集するには、f irewall-co nf ig ツールを起動してから設定ラベルのあるドロップダウン

メニューで永続モードを選びます。サービスウィンドウの下部に新たなアイコンとメニューボタンが表
示されます。設定するサービスを選びます。
ポートとプロトコルのタブでは、選択されたサービスのポートとプロトコルの追加、変更、削除ができ

ます。モジュールタブでは、Net f ilt er ヘルパーモジュールの設定を行います。送信先タブでは、特定
の送信先アドレスとインターネットプロトコル (IPv4 または IPv6) へのトラフィックが制限できます。
4.5.14.1.6. ファイアウォールでポートを開く
特定のポートへのトラフィックがファイアウォールを通過できるようにするには、f irewall-co nf ig
ツールを起動して、設定を変更するネットワークゾーンを選択します。ポートタブを選んで追加ボタン
をクリックします。ポートとプロトコルウィンドウが開きます。
許可するポート番号またはポートの範囲を入力します。ドロップダウンリストから tcp または udp を選

択します。
4.5.14.1.7. IP アドレスのマスカレードの有効化
IPv4 アドレスを単一の外部アドレスに変換するには、f irewall-co nf ig ツールを起動して、変換するア

ドレスのネットワークゾーンを選択します。マスカレーディングタブを選択し、チェックボックスを選
択して IPv4 アドレスの単一アドレスへの変換を有効にします。
4.5.14.1.8. ポート転送の設定
特定のポートに向けられた受信ネットワークトラフィックまたは「パケット」を、内部アドレスまたは

別のポートに転送するには、まず IP アドレスのマスカレーディングを有効にしてから、ポート転送タブ
を選択します。
受信トラフィックのプロトコルとポートもしくはポート範囲をウィンドウの上部で選択します。
ローカルポートにトラフィックを転送する、つまり同一システム上のポートに転送するには、ローカル転
送のチェックボックスを選択します。トラフィックの送信先となるローカルポートまたはポート範囲を入
力します。
69
トラフィックを別の IPv4 アドレスに転送するには、他のポートへの転送チェックボックスを選択しま

す。送信先の IP アドレスとポートまたはポート範囲を入力します。ポートのフィールドに入力がないと、
デフォルトで同一ポートに送信されます。OK をクリックして変更を適用します。
4.5.14.1.9. ICMP フィルターの設定
ICMP フィルターを有効、無効にするには、f irewall-co nf ig ツールを起動して、フィルターにかける

メッセージのネットワークゾーンを選択します。ICMP フィルタータブを選択し、フィルターにかける
ICMP メッセージの各タイプのチェックボックスを選択します。フィルターを無効にするには、チェック
ボックスの選択を外します。これは方向ごとに設定され、デフォルトではすべてが許可されます。
ICMP タイプを編集するには、f irewall-co nf ig ツールを起動してから設定ラベルのあるドロップダウ

ンメニューで永続モードを選びます。サービスウィンドウの下部に新たなアイコンが表示されます。
4.5.14.2. コマンドラインツール f irewall-cmd を使ったファイアウォールの設定
コマンドラインツール f irewall-cmd は、デフォルトでインストールされる firewalld アプリケー

ションの一部です。これがインストールされているかどうかを確認するには、バージョンを確認するか、ヘ
ルプの出力を表示させます。バージョンのチェックは以下のコマンドで実行します。
~]$ firewall-cmd --version
ヘルプの出力を表示するには、以下のコマンドを実行します。
~]$ firewall-cmd --help
以下でコマンドをいくつか表示しています。完全一覧については、man firewall-cmd(1) man ページ

を参照してください。
注記
コマンドを永続的にするには、--direct コマンド (これらは元々一時的なもの) を除いてすべて

のコマンドに --permanent オプションを追加します。こうすると変更が永続的になるだけではな
く、変更はファイアウォールのリロード、サービスの再起動、もしくはシステムの再起動後にのみ
適用されることに注意してください。--permanent オプションなしで f irewall-cmd を使って
設定すると、変更は即座に適用されますが、これが有効なのはファイアウォールがリロードされ
る、システム再起動、または firewalld サービスが再起動されるまでになります。ファイア
ウォールのリロード自体は接続を切断しませんが、一時的な変更が破棄されることに注意してくださ
い。
4.5.14.3. コマンドラインインターフェイス (CLI) を使ったファイアウォール設定の表示
firewalld の状態をテキスト表示するには、以下のコマンドを実行します。
~]$ firewall-cmd --state
アクティブなゾーンと、それらに割り当てられているインターフェイスの一覧を表示するには、以下のコマ
ンドを実行します。
~]$ firewall-cmd --get-active-zones

public
interfaces: em1
70
たとえば、インターフェイス e m1 が現在割り当てられているゾーンを確認するには、以下のコマンドを実
行します。
~]$ firewall-cmd --get-zone-of-interface=em1

public
あるゾーン、たとえば public ゾーンに割り当てられているすべてのインターフェイスを確認するに

は、root で以下のコマンドを実行します。
~]# firewall-cmd --zone=public --list-interfaces

em1 wlan0
この情報は Net wo rkManager から得られるもので、接続ではなくインターフェイスのみを表示しま

す。
あるゾーン、たとえば public ゾーンの設定すべてを確認するには、root で以下のコマンドを実行しま

す。
~]# firewall-cmd --zone=public --list-all

public
interfaces:
services: mdns dhcpv6-client ssh
ports:
forward-ports:
icmp-blocks: source-quench
現在読み込まれているサービスを一覧表示するには、root で以下のコマンドを実行します。
~]# firewall-cmd --get-services

cluster-suite pop3s bacula-client smtp ipp radius bacula ftp mdns samba
dhcpv6-client dns openvpn imaps samba-client http https ntp vnc-server
telnet libvirt ssh ipsec ipp-client amanda-client tftp-client nfs tftp
libvirt-tls
ここで表示されるのは、/usr/lib/firewalld/services/ から読み込まれた事前定義サービスの名前
と、現在読み込まれているカスタムサービスになります。設定ファイル自体は service-name.xml. と命
名されることに注意してください。
カスタムが作成されていても読み込まれていない場合は、以下のコマンドで確認できます。
~]# firewall-cmd --permanent --get-services
ここでは、サービスが読み込まれていなくても、/etc/firewalld/services/ で設定されたカスタム
サービスを含めたすべてのサービスが一覧表示されます。
4.5.14.4. コマンドラインインターフェイス (CLI) を使ったファイアウォール設定の変更
4.5.14.4.1. 全パケットの遮断 (パニックモード)
すべての送受信パケットの遮断を開始するには、root で以下のコマンドを実行します。
~]# firewall-cmd --panic-on
71
これですべての送受信パケットが遮断されます。アクティブな接続は、一定期間アクションがないと切断さ
れます。この期間は、個別のセッションタイムアウト値によって異なります。
すべての送受信パケットの受け渡しを再開するには、root で以下のコマンドを実行します。
~]# firewall-cmd --panic-off
パニックモードの有効期間が短かった場合、パニックモードを無効にすると、確立されていた接続が再度機
能する可能性があります。
パニックモードの有効、無効を確認するには、以下のコマンドを実行します。
~]$ firewall-cmd --query-panic
有効な場合は終了状態が 0 で yes がプリントされ、無効だと終了状態が 1 で no がプリントされます。
4.5.14.4.2. コマンドラインインターフェイス (CLI) を使ったファイアウォールのリロード
ファイアウォールをユーザー接続を切断せずに、つまり状態情報を失わずにリロードするには、root で以
~]# firewall-cmd --reload
ファイアウォールをユーザー接続を切断して、つまり状態情報を破棄してリロードするには、root で以下
のコマンドを実行します。
~]# firewall-cmd --complete-reload
このコマンドは通常、重大なファイアウォール問題の場合にのみ使用されます。たとえば、状態情報に問題
があって接続が確立されないものの、ファイアウォールルール自体は適正な場合などです。
4.5.14.4.3. コマンドラインインターフェイス (CLI) を使ってインターフェイスをゾーンに追加する
インターフェイスをゾーンに追加するには、たとえば e m1 を public ゾーンに追加するには、root で以

~]# firewall-cmd --zone=public --add-interface=em1
この設定を永続的にするには、--permanent を追加してファイアウォールをリロードします。
4.5.14.4.4. インターフェイス設定ファイルを編集してインターフェースをゾーンに追加する
ifcfg-em1 設定ファイルを編集してインターフェイス、たとえば e m1 を work ゾーンに追加するに

は、root でエディターを使用して以下の行を ifcfg-em1 に追加します。
ZONE=work
ZONE オプションを省略するか、ZONE= または ZONE='' を使用すると、デフォルトのゾーンが使用され

ます。
Net wo rkManager が自動的に再接続を行い、ゾーンがそれに応じて設定されます。
4.5.14.4.5. ファイアウォール設定ファイルを編集してデフォルトゾーンを設定する
root で /etc/firewalld/firewalld.conf ファイルを開き、以下のように編集します。
72
# default zone
# The default zone used if an empty zone string is used.
# Default: public
DefaultZone=home
root で以下のコマンドを実行して、ファイアウォールをリロードします。
こうすると、状態情報を失わずにファイアウォールがリロードされます (TCP セッションが中断されませ

ん)。
4.5.14.4.6. コマンドラインインターフェイス (CLI) を使ってデフォルトゾーンを設定する
デフォルトのゾーンをたとえば public に設定するには、root で以下のコマンドを実行します。
~]# firewall-cmd --set-default-zone=public
この変更は即座に有効になり、このケースではファイアウォールのリロードは不要です。
4.5.14.4.7. コマンドラインインターフェイス (CLI) を使ったファイアウォールでのポート確認
あるゾーン、たとえば dmz で開いているすべてのポートを一覧表示するには、root で以下のコマンドを

実行します。
~]# firewall-cmd --zone=dmz --list-ports
--add-services コマンドで開いたポートはここで表示されないことに注意してください。
ゾーンにポートを追加するには、たとえば TCP トラフィックを dmz ゾーンでポート 8080 で許可するに

~]# firewall-cmd --zone=dmz --add-port=8080/tcp
ポート範囲をゾーンに追加するには、たとえばポート 5060 から 5061 を public ゾーンで許可するに

~]# firewall-cmd --zone=public --add-port=5060-5061/udp
4.5.14.4.8. コマンドラインインターフェイス (CLI) を使ってサービスをゾーンに追加する
サービスをゾーンに追加するには、たとえば SMTP を work ゾーンに許可するには、root で以下のコマ

~]# firewall-cmd --zone=work --add-service=smtp
4.5.14.4.9. コマンドラインインターフェイス (CLI) を使ってサービスをゾーンから削除する
73
サービスをゾーンから削除するには、たとえば SMTP を work ゾーンから削除するには、root で以下の

~]# firewall-cmd --zone=work --remove-service=smtp
変更をシステムブート後にも維持するには、--permanent オプションを追加します。このオプションを
使用して、かつ変更を即座に有効にしたい場合は、root で以下のコマンドを実行して、ファイアウォール
をリロードします。
このコマンドでは、確立されている接続は切断されません。切断したい場合は --complete-reload オ
プションが使えますが、この場合切断されるのは削除したサービスだけでなく、すべての確立されている接
続が切断されることに注意してください。
4.5.14.4.10 . XML ファイルを編集してサービスをゾーンに追加する
デフォルトゾーンのファイルを表示するには、root で以下のコマンドを実行します。
~]# ls /usr/lib/firewalld/zones/
block.xml drop.xml home.xml public.xml work.xml
dmz.xml external.xml internal.xml trusted.xml
これらのファイルは、編集しないでください。これらのファイルは、/etc/firewalld/zones/ ディレ
クトリーに同等のファイルがない場合に、デフォルトで使用されます。
デフォルトから変更されたゾーンファイルを表示するには、root で以下のコマンドを実行します。
~]# ls /etc/firewalld/zones/
external.xml public.xml public.xml.old
上記の例では、work ゾーンのファイルは存在しません。work ゾーンのファイルを追加するには、root

で以下のコマンドを実行します。
~]# cp /usr/lib/firewalld/zones/work.xml /etc/firewalld/zones/
これで /etc/firewalld/zones/ ディレクトリー内のファイルを編集できます。ファイルを削除して

しまった場合は、firewalld は /usr/lib/firewalld/zones/ にあるデフォルトファイルを使用し
てフォールバックします。
サービスをゾーンに追加するには、たとえば SMTP を work ゾーンに許可するには、root でエディター

を使用し、/etc/firewalld/zones/work.xml ファイルに以下の行を含めます。
<service name="smtp"/>
4.5.14.4.11. XML ファイルを編集してサービスをゾーンから削除する
XML ゾーンファイルを編集するには、root 権限でエディターを実行する必要があります。以前に設定さ

れたゾーンのファイルを表示するには、root で以下のコマンドを実行します。
~]# ls /etc/firewalld/zones/
external.xml public.xml work.xml
74
サービスをゾーンから削除するには、たとえば SMTP を work ゾーンから削除するには、root でエディ

ターを使用し、/etc/firewalld/zones/work.xml ファイルを編集して、以下の行を削除します。
<service name="smtp"/>
work.xmlファイルにそれ以外の変更がなされない場合、これでこの行は削除され、firewalld は次回リ
ロード時またはシステム起動時にデフォルトの /usr/lib/firewalld/zones/work.xml 設定ファイ
ルを使用します。
4.5.14.4.12. IP アドレスのマスカレーディングの設定
IP マスカレーディングがたとえば e xte rnal で有効かどうかを確認するには、root で以下のコマンドを

実行します。
~]# firewall-cmd --zone=external --query-masquerade
有効な場合は終了状態が 0 で yes がプリントされ、無効だと終了状態が 1 で no がプリントされま

す。zone が省略されると、デフォルトのゾーンが使用されます。
IP マスカレーディングを有効にするには、root で以下のコマンドを発行します。
~]# firewall-cmd --zone=external --add-masquerade
IP マスカレーディングを無効にするには、root で以下のコマンドを発行します。
~]# firewall-cmd --zone=external --remove-masquerade
4.5.14.4.13. コマンドラインインターフェイス (CLI) を使ったポート転送の設定
受信ネットワークパケットをあるポートから別のポートまたはアドレスに転送するには、まず root で以
下のコマンドを実行して、ゾーン (たとえば e xte rnal) の IP アドレスマスカレーディングを有効にしま
す。
~]# firewall-cmd --zone=external --add-masquerade
パケットをローカルポート (つまり同一システム上の別のポート) に転送するには、root で以下のコマン

~]# firewall-cmd --zone=external --add-forward-

port=port=22:proto=tcp:toport=3753
この例では、ポート 22 に向けられていたパケットがポート 3753 に転送されます。元の宛先のポート

は、port オプションで指定します。このオプションは、プロトコルを伴ってポートもしくはポート範囲と
することができます。プロトコルが指定された場合は、tcp または udp のいずれかにします。トラフィッ
クの転送先となるポートもしくはポート範囲である新たなローカルポートは、toport オプションで指定し
ます。この設定を永続的にするには、--permanent オプションを追加してファイアウォールをリロード
します。
宛先ポートを変更せずに、パケットを別の IPv4 アドレス (通常は内部アドレス) に転送するには、root

で以下のコマンドを実行します。
75
~]# firewall-cmd --zone=external --add-forward-

port=port=22:proto=tcp:toaddr=192.0.2.55
この例では、ポート 22 に向けられていたパケットがtoaddr で与えられたアドレスの同一ポートに転送さ

れます。元の宛先のポートは、port オプションで指定します。このオプションは、プロトコルを伴って
ポートもしくはポート範囲とすることができます。プロトコルが指定された場合は、tcp または udp のい
ずれかにします。トラフィックの転送先となるポートもしくはポート範囲である新たな宛先ポート
は、toport オプションで指定します。この設定を永続的にするには、--permanent オプションを追加
してファイアウォールをリロードします。
パケットを別の IPv4 アドレス (通常は内部アドレス) の別のポートに転送するには、root で以下のコマ

~]# firewall-cmd --zone=external /

--add-forward-port=port=22:proto=tcp:toport=2055:toaddr=192.0.2.55
この例では、ポート 22 に向けられていたパケットがtoaddr で与えられたアドレスのポート 2055 に転

送されます。元の宛先のポートは、port オプションで指定します。このオプションは、プロトコルを伴っ
てポートもしくはポート範囲とすることができます。プロトコルが指定された場合は、tcp または udp の
いずれかにします。トラフィックの転送先となるポートもしくはポート範囲である新たな宛先ポート
は、toport オプションで指定します。この設定を永続的にするには、--permanent オプションを追加
してファイアウォールをリロードします。
4.5.14.5. XML ファイルを使ったファイアウォールの設定
f irewalld の設定は、XML ファイルで /etc/firewalld/ ディレクトリーに保存されていま

す。/usr/lib/firewalld/ ディレクトリー内のファイルはデフォルト設定なので、変更しないでくだ
さい。XML ファイルの閲覧と変更には、root ユーザー権限が必要になります。XML ファイルは、以下の
3 つの man ページで説明されています。
firewalld.icmptype(5) man ページ — ICMP フィルタリングの XML 設定ファイルについて説

明しています。
firewalld.service(5) man ページ — f irewalld service の XML 設定ファイルについて説明

しています。
firewalld.zone(5) man ページ — firewalld ゾーン設定の XML 設定ファイルについて説明し

ています。
XML ファイルは直接作成、編集するか、グラフィカルおよびコマンドラインツールを使って間接的に作成
することができます。組織内では RPM ファイルでこれらを配布することで、管理とバージョンコントロー
ルが容易になります。Puppet のようなツールを使うと、このような設定ファイルの配布が可能になりま
す。
4.5.14.6. ダイレクトインターフェイスの使用
f irewall-cmd ツールで --direct オプションを使うと、ランタイム時にチェーンの追加、削除が可能

になります。ここではいくつかの例を紹介していますが、詳細は firewall-cmd(1) man ページを参照
ダイレクトインターフェイスの使用は意図せずにファイアウォール侵害を引き起こす可能性があるの
で、ipt ables に精通していない場合には危険です。
ダイレクトインターフェイスモードは、サービスもしくはアプリケーションが実行時に特定のファイア
ウォールルールを追加するためのものです。--permanent オプションを追加して firewall-cmd --
permanent --direct コマンドを使用するか、/etc/firewalld/direct.xml を修正することで、
76
ルールを永続的なものにできます。/etc/firewalld/direct.xml ファイルの詳細
は、firewalld.direct(5) の man ページを参照してください。
4.5.14.6.1. ダイレクトインターフェイスを使用したカスタムルールの追加
チェーン「IN_public_allow」にカスタムルールを追加するには、root で以下の形式のコマンドを実行

します。
~]# firewall-cmd --direct --add-rule ipv4 filter IN_public_allow \

0 -m tcp -p tcp --dport 666 -j ACCEPT
この設定を永続的にするには、--permanent オプションを追加します。
4.5.14.6.2. ダイレクトインターフェイスを使用したカスタムルールの削除
チェーン「IN_public_allow」からカスタムルールを削除するには、root で以下の形式のコマンドを実

行します。
~]# firewall-cmd --direct --remove-rule ipv4 filter IN_public_allow \

0 -m tcp -p tcp --dport 666 -j ACCEPT
4.5.14.6.3. ダイレクトインターフェイスを使用したカスタムルールの一覧表示
チェーン「IN_public_allow」内のカスタムルールを一覧表示するには、root で以下の形式のコマンド

を実行します。
~]# firewall-cmd --direct --get-rules ipv4 filter IN_public_allow
4.5.15. "リッチ言語" 構文を使った複雑なファイアウォールルールの設定
「リッチ言語」構文を使用すると、ダイレクトインターフェイスよりも理解しやすい方法で複雑なファイ
アウォールルールが作成できます。さらに、設定を永続的にすることができます。この言語は値の付いた
キーワードを使用するもので、ipt ables ルールの抽象表現です。ゾーンはこの言語を使って設定すること
ができ、現行の設定方式もそのままサポートされます。
4.5.15.1. リッチ言語コマンドの形式
本セクションのコマンドはすべて、root で実行する必要があります。ルールを追加するコマンド形式は以
下のようになります。
firewall-cmd [--zone=zone] --add-rich-rule='rule' [--timeout=seconds]
これでリッチ言語ルールの rule がゾーン zone に追加されます。このオプションは複数回指定することが

できます。ゾーンが省略されると、デフォルトのゾーンが使用されます。タイムアウトが指定されていれ
ば、ルールは指定の秒数の間、アクティブになり、その後に自動的に削除されます。
ルールを削除するコマンド形式は以下のようになります。
firewall-cmd [--zone=zone] --remove-rich-rule='rule'
これでゾーン zone のルール rule が削除されます。このオプションは複数回指定することができます。

ゾーンが省略されると、デフォルトのゾーンが使用されます。
77
ルールが存在するかどうかを確認するには、以下のコマンドを実行します。
firewall-cmd [--zone=zone] --query-rich-rule='rule'
このコマンドは、リッチ言語ルールの rule がゾーン zone に追加されたかどうかを返します。有効な場合

は終了状態が 0 で yes がプリントされ、無効だと終了状態が 1 で no がプリントされます。ゾーンが省
略されると、デフォルトのゾーンが使用されます。
ゾーン設定ファイルで使用されるリッチ言語表現についての詳細情報は、firewalld.zone(5) man
ページを参照してください。
4.5.15.2. リッチルールの構造について
リッチルールコマンドの形式または構造は、以下のようになります。
rule [family="rule family"]

[ source address="address" [invert="True"] ]
[ destination address="address" [invert="True"] ]
[ element ]
[ log [prefix="prefix text"] [level="log level"] [limit
value="rate/duration"] ]
[ audit ]
[ action ]
ルールは特定のゾーンに関連付けられます。ゾーンには複数のルールを関連付けることができます。いくつ
かのルールが相互に作用する、または矛盾する場合は、パケットに適合する最初のルールが適用されます。
4.5.15.3. リッチルールのコマンドオプションについて
family
ルール family が提供されている場合は、ipv4 か ipv6 になり、ルールを IPv4 または IPv6

に制限します。ルール family が提供されていない場合は、このルールは IPv4 と IPv6 の両方
に追加されます。ルール内でソースまたは宛先のアドレスが使用されていると、ルール family
を提供する必要があります。これは、ポート転送の場合でも同じです。
ソースおよび宛先のアドレス
source
ソースのアドレスを指定すると、接続試行の元を指定したソースアドレスに限定することができ
ます。ソースアドレスまたはアドレスの範囲は、IPv4 または IPv6 のマスクを伴う IP アドレ
スかネットワーク IP アドレスになります。ネットワーク family (IPv4 または IPv6) が自動的
に見つけられます。IPv4 のマスクは、ネットワークマスクか単純な番号になります。IPv6 の
マスクは、単純な番号になります。ホスト名の使用はサポートされていません。invert="true
または invert="yes" を追加すると、ソースアドレスコマンドの意味が逆になり、提供された
アドレス以外のものがマッチすることになります。
destination
宛先のアドレスを指定すると、ターゲットを指定した宛先アドレスに限定することができます。
宛先アドレスでは、ソースアドレスと同様の構文を使用します。ソースおよび宛先アドレスの使
用はオプションで、宛先アドレスの使用はすべての要素と使用できるわけではありません。これ
は、たとえばサービスエントリーにおける宛先アドレスの使用などによります。
要素
78
要素は、以下のいずれかひとつのみのタイプになりま

す。service、port、protocol、masquerade、icmp-block または forward-port です。
service
s e rvice 要素は、f irewalld が提供するサービスのひとつです。事前定義のサービス一覧を入

手するには、以下のコマンドを実行します。
~]$ firewall-cmd --get-services
サービスが宛先アドレスを提供する場合、ルール内の宛先アドレスと競合し、エラーが発生しま
す。内部で宛先アドレスを使用するサービスのほとんどは、マルチキャストを使用するサービス
です。コマンドは以下の形式になります。
service name=service_name
port
port 要素は、単一のポート番号か 5060-5062 のようなポート範囲のどちらかで、その後に

tcp か udp のプロトコルが続きます。コマンドは以下の形式になります。
port port=number_or_range protocol=protocol
protocol
プロトコルの値は、プロトコル ID 番号かプロトコル名になります。利用可能なプロトコルエン
トリーについては、/etc/protocols を参照してください。コマンドは以下の形式になりま
す。
protocol value=protocol_name_or_ID
icmp-block
ひとつ以上の ICMP タイプをブロックするには、このコマンドを使用します。ICMP タイプ

は、f irewalld がサポートする ICMP タイプのひとつになります。サポートされるICMP タイ
プの一覧を入手するには、以下のコマンドを実行します。
~]$ firewall-cmd --get-icmptypes
ここではアクションの特定はできません。icmp-block は reject のアクションを内部で使用

します。コマンドは以下の形式になります。
icmp-block name=icmptype_name
masquerade
ルール内の IP マスカレードを有効にします。ソースアドレスを提供するとこの分野へのマスカ
レードを制限できますが、宛先アドレスは制限できません。ここではアクションの特定はできま
せん。
forward-port
tcp または udp として指定されたプロトコルのローカルポートから別のローカルポート、別の

マシン、または別のマシン上の別のポートにパケットを転送します。port および to-port
は、単一のポート番号もしくはポート範囲のどちらでも構いません。宛先アドレスは、単純な IP
79
アドレスになります。ここではアクションの特定はできません。forward-port コマンドは
accept のアクションを内部で使用します。コマンドは以下の形式になります。
forward-port port=number_or_range protocol=protocol /

to-port=number_or_range to-addr=address
ロギング
log
s ys log などのカーネルロギングでルールへの新たな接続試行を記録します。ログメッセージに
接頭辞として追加される接頭辞テキストを定義することができます。ログレベル
は、emerg、alert、crit、error、warning、notice、info または debug のいずれか
になります。ログの使用はオプションです。ログの使用は以下のように制限できます。
log [prefix=prefix text] [level=log level] limit

value=rate/duration
rate は正の自然数 [1, ..] で、s、m、h、d は時間の長さになります。s は秒数、m は分数、h は

時間数、d は日数を表します。制限の最大値は 1/d で、これは 1 日あたり最大 1 ログエント
リーになります。
audit
Audit は、サービス auditd に送信された監査記録を使ってロギングの別の方法を提供します。

audit タイプは ACCEPT、REJECT または DROP のいずれかになりますが、これはルールのアク
ションから自動的に獲得されるので、audit コマンドの後では指定されません。Audit にはそれ
自体のパラメーターはありませんが、オプションで制限を加えることができます。Audit の使用
はオプションになります。
アクション
accept|reject|drop
アクションは accept、reject または drop のいずれかになります。ルールに含めることがで

きるのは、単一の要素またはソースのみになります。ルールに要素が含まれている場合、その要
素のマッチする新たな接続はそのアクションで処理されます。ルールにソースが含まれている場
合、そのソースアドレスからのものがすべて指定されたアクションで処理されます。
accept | reject [type=reject type] | drop
accept を使うと、新たな接続試行がすべて許可されます。reject を使うとそれらは拒否さ

れ、そのソースは拒否メッセージを受け取ります。拒否のタイプは、別の値を使用するように設
定できます。drop を使うと、すべてのパケットが即座に切断され、ソースにはなにも情報が送
られません。
4.5.15.4. リッチルールログコマンドの使用
ロギングは Net f ilt er ログターゲットおよび audit ターゲットを使用して実行できます。「zone_log」

という形式の名前で新たなチェーンがすべてのゾーンに追加されます。ここでの zone はゾーン名になりま
す。適切な順序にするために、これは deny チェーンの前に処理されます。ルールまたはルールの部分は
以下のようにルールのアクションにしたがって、別個のチェーンに置かれます。
80
zone_log
zone_deny
zone_allow
ロギングのルールはすべて「zone_log」チェーンに置かれ、これが最初に解析されます。reject およ

び drop ルールはすべて「zone_de ny」チェーンに置かれ、これは log チェーンの後に解析されま
す。accept ルールはすべて「zone_allow」チェーンに置かれ、これは deny チェーンの後に解析され
ます。ルールに log と deny または allow アクションが含まれる場合は、これらのアクションを指定し
ているルールのパーツはマッチするチェーンに置かれます。
4.5.15.4.1. リッチルールログコマンドの使用例 1
認証ヘッダープロトコル AH 用に新たな IPv4 および IPv6 接続を有効にします :
rule protocol value="ah" accept
プロトコル FTP および audit を使用した 1 分あたり 1 件のログ用に新たな IPv4 および IPv6 接続を許
可します :
rule service name="ftp" log limit value="1/m" audit accept
プロトコル TFTP と s ys log を使用した毎分 1 件のログ用にアドレス 192.168.0.0/24 からの新たな

IPv4 接続を許可します。
rule family="ipv4" source address="192.168.0.0/24" service name="tftp"

log prefix="tftp" level="info" limit value="1/m" accept
プロトコル RADIUS 用の 1:2:3:4:6:: からの新たな IPv6 接続はすべて拒否されます。他のソースか

らの新たな IPv6 接続は許可されます:
rule family="ipv6" source address="1:2:3:4:6::" service name="radius"

log prefix="dns" level="info" limit value="3/m" reject
rule family="ipv6" service name="radius" accept
プロトコル TCP を使ってポート 4011 で 1:2:3:4:6:: から受信した IPv6 パケットを、ポート 4012

上の 1::2:3:4:7 に転送します。
rule family="ipv6" source address="1:2:3:4:6::" forward-port to-

addr="1::2:3:4:7" to-port="4012" protocol="tcp" port="4011"
ソースアドレスをホワイトリスト化してそのソースからの接続すべてを許可します。
rule family="ipv4" source address="192.168.2.2" accept
81
他の例については、firewalld.richlanguage(5) man ページを参照してください。
4.5.16. ファイアウォールのロックダウン
ローカルのアプリケーションやサービスは、root で実行していれば (たとえば libvirt ) ファイアウォー

ル設定を変更することができます。この機能を使うと、管理者はファイアウォール設定をロックして、どの
アプリケーションもファイアウォール変更を要求できなくするか、ロックダウンのホワイトリストに追加
されたアプリケーションのみがファイアウォール変更を要求できるようにすることが可能になります。
ロックダウン設定はデフォルトで無効になっています。これを有効にすると、ローカルのアプリケーショ
ンやサービスによるファイアウォールの望ましくない変更を確実に防止することができます。
4.5.16.1. ファイアウォールロックダウンの設定
root でエディターを使用し、以下の行を /etc/firewalld/firewalld.conf ファイルに追加しま

す。
Lockdown=yes
root で以下のコマンドを実行して、ファイアウォールをリロードします。
管理ユーザーとして、つまり wheel グループのユーザーとして (通常、システムの最初のユーザー) 以下

のコマンドを実行し、デフォルトゾーンで imaps サービスの有効化を図ります。ユーザーパスワードが求
められます。
~]$ firewall-cmd --add-service=imaps

Error: ACCESS_DENIED: lockdown is enabled
f irewall-cmd の使用を有効にするには、root で以下のコマンドを実行します。
~]# firewall-cmd --add-lockdown-whitelist-command='/usr/bin/python -Es

/usr/bin/firewall-cmd*'
root でファイアウォールをリロードします。
管理ユーザーとして以下のコマンドを実行し、再度、デフォルトゾーンで imaps サービスの有効化を図り

ます。ユーザーパスワードが求められます。
~]$ firewall-cmd --add-service=imaps
これでコマンド実行が成功します。
4.5.16.2. コマンドラインクライアントを使用したロックダウンの設定
ロックダウンが有効になっているかどうかを確認するには、root で以下のコマンドを実行します。
~]# firewall-cmd --query-lockdown
82
有効になっている場合は終了状態が 0 で yes がプリントされ、無効だと終了状態が 1 で no がプリント

されます。
ロックダウンを有効にするには、root で以下のコマンドを実行します。
~]# firewall-cmd --lockdown-on
ロックダウンを無効にするには、root で以下のコマンドを実行します。
~]# firewall-cmd --lockdown-off
4.5.16.3. コマンドラインを使用したロックダウンホワイトリストオプションの設定
ロックダウンのホワイトリストには、コマンドやセキュリティのコンテキスト、ユーザー、およびユーザー
ID を含めることができます。ホワイトリストのコマンドエントリーがアスタリスク「*」で終わっている
場合、そのコマンドで始まるすべてのコマンドラインがマッチすることになります。「*」がなければ、引
数を含めたコマンドが完全に一致する必要があります。
ここでのコンテキストは、実行中のアプリケーションやサービスのセキュリティ (SELinux) コンテキスト

です。実行中のアプリケーションのコンテキストを確認するには、以下のコマンドを実行します。
~]$ ps -e --context
このコマンドで、実行中のアプリケーションすべてが返されます。grep ツールを使用して、出力から目的
のアプリケーションを以下のようにパイプ処理します。
~]$ ps -e --context | grep example_program
ホワイトリストにあるコマンドラインすべてを一覧表示するには、root で以下のコマンドを実行します。
~]# firewall-cmd --list-lockdown-whitelist-commands
ホワイトリストにコマンド command を追加するには、root で以下のコマンドを実行します。
~]# firewall-cmd --add-lockdown-whitelist-command='/usr/bin/python -Es

/usr/bin/command'
ホワイトリストからコマンド command を削除するには、root で以下のコマンドを実行します。
~]# firewall-cmd --remove-lockdown-whitelist-command='/usr/bin/python -

Es /usr/bin/command'
ホワイトリストにコマンド command があるかどうかを確認するには、root で以下のコマンドを実行し

ます。
~]# firewall-cmd --query-lockdown-whitelist-command='/usr/bin/python -Es

/usr/bin/command'
コマンドがある場合は終了状態が 0 で yes がプリントされ、ないと終了状態が 1 で no がプリントされ

ます。
83
ホワイトリストにあるセキュリティコンテキストすべてを一覧表示するには、root で以下のコマンドを実
行します。
~]# firewall-cmd --list-lockdown-whitelist-contexts
ホワイトリストにコンテキスト context を追加するには、root で以下のコマンドを実行します。
~]# firewall-cmd --add-lockdown-whitelist-context=context
ホワイトリストからコンテキスト context を削除するには、root で以下のコマンドを実行します。
~]# firewall-cmd --remove-lockdown-whitelist-context=context
ホワイトリストにコンテキスト context があるかどうかを確認するには、root で以下のコマンドを実行

します。
~]# firewall-cmd --query-lockdown-whitelist-context=context

ます。
ホワイトリストにあるユーザー ID すべてを一覧表示するには、root で以下のコマンドを実行します。
~]# firewall-cmd --list-lockdown-whitelist-uids
ホワイトリストにユーザー ID uid を追加するには、root で以下のコマンドを実行します。
~]# firewall-cmd --add-lockdown-whitelist-uid=uid
ホワイトリストからユーザー ID uid を削除するには、root で以下のコマンドを実行します。
~]# firewall-cmd --remove-lockdown-whitelist-uid=uid
ホワイトリストにユーザー ID uid があるかどうかを確認するには、以下のコマンドを実行します。
~]$ firewall-cmd --query-lockdown-whitelist-uid=uid

ます。
ホワイトリストにあるユーザー名すべてを一覧表示するには、root で以下のコマンドを実行します。
~]# firewall-cmd --list-lockdown-whitelist-users
ホワイトリストにユーザー名 user を追加するには、root で以下のコマンドを実行します。
84
~]# firewall-cmd --add-lockdown-whitelist-user=user
ホワイトリストからユーザー名 user を削除するには、root で以下のコマンドを実行します。
~]# firewall-cmd --remove-lockdown-whitelist-user=user
ホワイトリストにユーザー名 user があるかどうかを確認するには、以下のコマンドを実行します。
~]$ firewall-cmd --query-lockdown-whitelist-user=user

ます。
4.5.16.4. 設定ファイルを使用したロックダウンホワイトリストオプションの設定
デフォルトのホワイトリスト設定ファイルには、Net wo rkManager コンテキストと libvirt のデフォ

ルトのコンテキストが含まれています。また、ユーザー ID 0 がリストに含まれています。
<?xml version="1.0" encoding="utf-8"?>

<whitelist>
<selinux context="system_u:system_r:NetworkManager_t:s0"/>
<selinux context="system_u:system_r:virtd_t:s0-s0:c0.c1023"/>
<user id="0"/>
</whitelist>
以下のホワイトリスト設定ファイルの例では、firewall-cmd ユーティリティーのコマンドと、ユーザー
ID が 815 である user のコマンドすべてを有効にしています。

<whitelist>
<command name="/usr/bin/python -Es /bin/firewall-cmd*"/>
<selinux context="system_u:system_r:NetworkManager_t:s0"/>
<user id="815"/>
<user name="user"/>
</whitelist>
上記の例では user id と user name の両方が使われていますが、実際にはどちらか一方のみが必要に

なります。インタープリターは Python なので、コマンドラインに追加されています。または、以下のよう
な明確なコマンドを使用することもできます。
/usr/bin/python /bin/firewall-cmd --lockdown-on
この例では、--lockdown-on コマンドのみが許可されます。
85
注記
Re d Hat Ente rpris e Linux 7 では、すべてのユーティリティーが /usr/bin/ に格納さ

れ、/bin/ ディレクトリーは /usr/bin/ ディレクトリーにシンボリックリンクされています。
つまり、 root で firewall-cmd のパスを実行すると /bin/firewall-cmd に帰着します
が、/usr/bin/firewall-cmd が使用できるようになっています。新たなスクリプトはすべて新
しい格納場所を使うべきですが、root で実行するスクリプトが /bin/firewall-cmd のパスを
使用するようなっていれば、通常 root ユーザー以外のみに使用される /usr/bin/firewall-
cmd パスに加えてこのコマンドパスもホワイトリストに加える必要があります。
コマンドの名前属性の最後にある「*」は、それで始まるすべてのコマンドが一致することを意味

します。「*」がなければ、引数を含めたコマンドが完全に一致する必要があります。
4.5.17. その他のリソース
以下の情報ソースでは、firewalld に関する追加リソースが提供されています。
4.5.17.1. インストールされているドキュメント
firewalld(1) man ページ — firewalld のコマンドオプションについて説明しています。
firewalld.conf(5) man ページ — firewalld の設定に関する情報が含まれています。
firewall-cmd(1) man ページ — firewalld コマンドラインクライアントのコマンドオプション

について説明しています。
firewalld.icmptype(5) man ページ — ICMP フィルタリングの XML 設定ファイルについて説

明しています。
firewalld.service(5) man ページ — f irewalld service の XML 設定ファイルについて説明

しています。
firewalld.zone(5) man ページ — firewalld ゾーン設定の XML 設定ファイルについて説明し

ています。
firewalld.direct(5) man ページ — firewalld ダイレクトインターフェイス設定ファイルに

ついて説明しています。
firewalld.lockdown-whitelist(5) man ページ — firewalld ロックダウンホワイトリスト

の設定ファイルについて説明しています。
firewall.richlanguage(5) man ページ — firewalld リッチ言語ルールの構造について説明

しています。
firewalld.zones(5) man ページ — ゾーンについての全般的な説明とそれらの設定方法が説明さ

れています。
4.6. DNSSEC を使った DNS トラフィックのセキュア化
4.6.1. DNSSEC の概要
86
DNSSEC は、Domain Name System Security Extensions (DNSSEC : ドメイン名システムセキュリ

ティ拡張機能) のセットです。DNS クライアントが DNS ネームサーバーからの応答の整合性を認証、検査
して、応答元を検証し、転送中に不正に変更されなかったかどうかを判別できるようにします。
4.6.2. DNSSEC について
今日では、インターネット接続で多くのウェブサイトが HTTPS を使った安全な接続機能を提供していま

す。しかし、IP アドレスを直接入力していなければ、HTTPS ウェブサーバーに接続する前に DNS ルック
アップが実行される必要があります。この DNS ルックアップは安全に実行されず、認証がないことから中
間者攻撃の対象となります。つまり、ある DNS ネームサーバーから送信されたようにみえる応答が本物
で、不正に変更されていないことに DNS クライアントは確信を持てません。さらに重要なのは、再帰問い
合わせネームサーバーは、他のネームサーバーから得られる記録が本物かどうかを判断できません。DNS プ
ロトコルは、クライアントが中間者攻撃の対象とならないようなメカニズムを提供していませんでした。
DNSSEC は、DNS を使用したドメインネームを解決する際の認証および完全性のチェックの欠如に対処す
るために導入されました。DNSSEC は、機密性の問題には対処しません。
DNSSEC 情報の公開では、DNS リソース記録のデジタル署名と、DNS リゾルバーが信頼の階層チェーン

を構築できる方法での公開鍵の配布が行われます。すべての DNS リソースレコードのデジタル署名は、デ
ジタル署名のリソース記録 (RRSIG) として生成され、ゾーンに追加されます。ゾーンの公開鍵は、
DNSKEY リソースレコードとして追加されます。階層チェーンを構築するために、DNSKEY のハッシュ
が Delegation of Signing (DS) リソースレコードとして親ゾーンに公開されます。存在しない証拠を活用
するため、NextSECure (NSEC) および NSEC3 リソースレコードが使用されます。DNSSEC 署名ゾーン
では、各リソースレコードセット (RRs e t) に対応する RRSIG リソースレコードがあります。子ゾーンへ
の委任用に使用されるレコード (NS および glue レコード) には署名されないことに注意してください。そ
れらのレコードは子ゾーンに表示され、そこで署名されます。
DNSSEC 情報の処理は、root ゾーンの公開鍵で設定されたリゾルバーが行います。この鍵を使ってリゾル

バーは root ゾーンで使用された署名を検証することができます。たとえば、root ゾーンが .com の DS
レコードを署名しているとします。root ゾーンは .com ネームサーバーの NS および glue レコードも処
理します。リゾルバーはこの委任を追いかけ、これらの委任されたネームサーバーを使用して .com の
DNSKEY レコードを問い合わせます。獲得された DNSKEY レコードのハッシュは、root ゾーンの DS
レコードとマッチするはずです。マッチする場合、リゾルバーは獲得された .com の DNSKEY を信頼し
ます。.com ゾーンでは、RRSIG レコードは .com DNSKEY が作成します。このプロセス
は、redhat.com などの .com 内の委任で同様に繰り返されます。この方法を使用することで、検証を行
う DNS リゾルバーは 1 つの root 鍵での設定のみが必要で、多くの DNSKEY を通常の操作中に世界中か
ら収集します。暗号検査が失敗すると、リゾルバーはアプリケーションに SERVFAIL を返します。
DNSSEC は、DNSSEC をサポートしていないアプリケーションには全く見えないように設計されていま

す。DNSSEC 非対応のアプリケーションが DNSSEC 対応リゾルバーにクエリを行うと、RRSIG のよう
な新たなリソースレコードタイプのない応答を受け取ります。しかし、それでも DNSSEC 対応リゾルバー
はすべての暗号検査を実行し、悪意のある DNS 応答を検出するとアプリケーションに SERVFAIL エラーを
返します。DNSSEC は、DNS サーバー間 (権威と再帰) でデータの整合性を保護しますが、アプリケー
ションとリゾルバー間のセキュリティは提供しません。このため、アプリケーションにリゾルバーへの安
全なトランスポートが提供されることが重要になります。一番簡単な方法は、DNSSEC 対応リゾルバーを
localhost 上で稼働して /etc/resolv.conf 内の 127.0.0.1 を使用することです。リモートの
DNS サーバーに VPN 接続する方法もあります。
ホットスポットの問題について
Wi-Fi ホットスポットや VPN を使用する場合は、「DNS lie s 」に依存しています。キャプティブポータ

ルは、ユーザーを Wi-Fi サービス認証 (または支払い) する必要のあるページにリダイレクトするため
に、DNS を乗っ取る傾向があります。VPN に接続するユーザーは、企業ネットワークの外に存在しないリ
ソースを見つけるために、「内部のみ」の DNS サーバーを使用することがよくあります。これには、ソフ
トウェアによる追加処理が必要になります。たとえば、dnssec-t rigger を使って、ホットスポットが
DNS クエリを乗っ取っているかを検出し、unbound はプロキシネームサーバーとして DNSSEC クエリ
を処理するように動作することが可能です。
87
DNSSEC 対応のリカーシブリゾルバー
DNSSEC 対応のリカーシブリゾルバーを実装するには、BIND または unbound を使用することができま

す。両方ともデフォルトで DNSSEC を有効にし、DNSSEC root キーで設定されています。サーバー上
で DNSSEC を有効にするにはどちらでも可能ですが、ノートパソコンなどのモバイルデバイスで
は、unbound が推奨されます。これは、dnssec-t rigger 使用時にはホットスポット、Libreswan
使用時には VPN に必要となる DNSSEC 上書きの再構成をローカルユーザーが動的に行えるようになるた
めです。unbound デーモンはさらに、etc/unbound/*.d/ ディレクトリーにリスト化されている
DNSSEC 例外の実装もサポートします。これは、サーバーとモバイルデバイスの両方で役立ちます。
4.6.3. Dnssec-t rigger について
unbound が/etc/resolv.conf にインストールされ設定ができたら、アプリケーションからのすべて

の DNS クエリは unbound によって処理されます。dnssec-t rigger が unbound リゾルバーを再構成
するのは、そうするようにトリガーされた場合のみです。これは主に、異なる Wi-Fi ネットワークに接続す
るノートパソコンのような、ローミングを行うクライアントマシンに当てはまります。プロセスは以下のよ
うになります。
新規 DNS サーバーが DHCP 経由で獲得されると、Net wo rkManager が dnssec-t rigger

を「トリガー (開始) 」します。
Dnssec-t rigger がサーバーに対して多くのテストを実行し、サーバーが DNSSEC を適切にサポー

トしているかどうかを判断します。
サポートしている場合は、dnssec-t rigger が unbound を再構成して、その DNS サーバーをすべ

てのクエリに対するフォワーダーとして使用します。
テストが失敗した場合は、dnssec-t rigger は新規 DNS サーバーを無視して利用可能なフォール

バックの方法をいくつか試行します。
無制限ポート 53 (UDP および TCP) が利用可能だと判断されたら、フォワーダーを使用せずに

unbound が完全なリカーシブ DNS サーバーになるように指示します。
たとえば、ポート 53 がネットワークの DNS サーバー自体以外にはファイアウォールでブロックされ

ているなどしてこれが可能でない場合は、ポート 80 へは DNS を、ポート 443 へは TLS カプセル化
された DNS の使用を試みます。ポート 80 および 443 で DNS を稼働しているサーバー
は、/etc/dnssec-trigger/dnssec-trigger.conf で設定できます。デフォルトの設定ファイ
ルでは、コメントアウトされた例が利用可能になっています。
これらのフォールバックの方法も失敗する場合は、dnssec-t rigger は DNSSEC を完全に迂回して

セキュアでない状態で機能するか、「cache only」モードで実行します。後者の場合、新規の DNS ク
エリは試行されませんが、キャッシュにすでにあるものについてはすべて応答します。
Wi-Fi ホットスポットでは、ユーザーはインターネットへのアクセスを許可される前にサインオンページに
リダイレクトされる傾向が強まっています。上記で示された調査手順の間にリダイレクトが検出されると、
ユーザーはインターネットアクセスにログインが必要かどうかを尋ねるようにプロンプトが示されま
す。dnssec-trigger デーモンは 10 分ごとに DNSSEC リゾルバーをプローブし続けます。dnssec-
t rigger グラフィカルユーティリティーの使用に関する情報は、「Dns s e c-trigge r の使用」を参照し
てください。
4.6.4. VPN が提供されるドメインサーバーおよびネームサーバー
VPN 接続の中には、ドメインとネームサーバー一覧を伝達して、そのドメインを VPN トンネル設定の一部

として使用できるタイプもあります。Red Hat Ent erprise Linux では、Net wo rkManager がこ
れをサポートしています。つまり、unbound、dnssec-t rigger、および Net wo rkManager の組み
合わせは、VPN ソフトウェアが提供するドメインとネームサーバーを適切にサポートできるということで
す。VPN トンネルができれば、ローカルの unbound キャッシュは、受け取られたドメインネームのエン
88
トリーすべてについてフラッシュされるので、そのドメインネーム内のネームに関するクエリは VPN 経由
で届いた内部ネームサーバーから新たにフェッチされます。VPN トンネルが終了すると、unbound
キャッシュが再度フラッシュされ、ドメインへのクエリが以前に獲得されたプライベート IP アドレスでは
なく、公開 IP アドレスを返すようにします。詳細は、「接続によって提供されるドメイン用の DNSSEC
検証の設定」を参照してください。
4.6.5. 推奨される命名プラクティス
Re d Hat では、静的および一時的なネームの両方が host.example.com のように DNS 内のマシンに使

用されている完全修飾ドメインネーム (FQDN) に合致することを推奨しています。
ICANN (The Inte rne t Corporation for As s igne d Name s and Numbe rs ) は、(.yourcompany な
どの) トップレベルの未登録ドメインを公開登録簿に追加することがあります。このため、Re d Hat では、
プライベートネットワーク上であっても委任されていないドメイン名を使用しないことを強く推奨していま
す。これは、ネットワーク設定によっては異なる解決をしてしまうドメインネームになってしまう可能性が
あるからです。その結果、ネットワークリソースは利用不可能になってしまいます。また、委任されていな
いドメイン名を使うと、DNSSEC の実装および維持がより困難になります。これは、ドメインネームが競
合すると DNSSEC 検証に手動の設定が必要となるからです。この問題に関する詳細情報は、ICANN FAQ
on domain name collis ion を参照してください。
4.6.6. トラストアンカーについて
トラストアンカーは、DNS ネームとそのネームに関連づけられた公開鍵 (または公開鍵のキャッシュ) で構

成されます。ベース 64 のエンコード化された鍵として表示されます。これは、DNS レコードの検証と認
証に使用可能な公開鍵を含む情報の交換方法という意味で、証明書と同様のものになります。トラストアン
カーの完全な定義については、RFC 4033 を参照してください。
4.6.7. DNSSEC のインストール
4.6.7.1. unbound のインストール
マシン上でローカルに DNSSEC を使用する DNS を検証するためには、DNS リゾルバー unbound (また

は bind ) をインストールする必要があります。モバイルデバイスでは、 dnssec-t rigger のインストー
ルのみが必要です。サーバーには unbound で十分ですが、サーバーの場所 (LAN もしくはインターネッ
ト) によってはローカルドメイン用の転送設定が必要となる場合もあります。dnssec-t rigger は現在、
グローバルの公開 DNS ゾーンのみで機能します。Net wo rkManager、dhclient 、および VPN アプ
リケーションは自動でドメイン一覧 (およびネームサーバー一覧も) を収集することが多くあります
が、dnssec-t rigger や unbo und ではこれは行われません。
unbound をインストールするには、root ユーザーで以下のコマンドを実行します。
~]# yum install unbound
4.6.7.2. unbound の稼働確認
unbound デーモンが稼働しているかどうかを確認するには、以下のコマンドを実行します。
~]$ systemctl status unbound

unbound.service - Unbound recursive Domain Name Server
Loaded: loaded (/usr/lib/systemd/system/unbound.service; disabled)
Active: active (running) since Wed 2013-03-13 01:19:30 CET; 6h ago
unbound サービスが稼働していないと systemctl status コマンドは unbound を Active:

inactive (dead) とレポートします。
89
4.6.7.3. unbound の起動
現行セッション用に unbound を起動するには、root ユーザーで以下のコマンドを実行します。
~]# systemctl start unbound
systemctl enable コマンドを実行すると unbound がシステム起動時に毎回起動します。
~]# systemctl enable unbound
unbound デーモンは、以下のディレクトリーを使用してローカルデータの設定または上書きを可能にしま
す。
/etc/unbound/conf.d ディレクトリーは、特定のドメインネーム用の設定追加に使用されます。ド
メインネームのクエリを特定の DNS サーバーにリダイレクトするために使用されます。企業 WAN 内
にのみ存在するサブドメインに多く使用されます。
/etc/unbound/keys.d ディレクトリーは、特定のドメインネーム用のトラストアンカーの追加に使
用されます。これは、内部のみのネームが DNSSEC 署名されているものの、トラストのパスを構築す
るための DS レコードが公開で存在しない場合に必要になります。別のユースケースは、企業 WAN 外
で公開で入手可能なネームではない別の DNSKEY を使って署名された、内部バージョンのドメインの
場合になります。
/etc/unbound/local.d ディレクトリーは、特定の DNS データをローカルの上書きとして追加す

るために使用されます。これは、ブラックリストの構築もしくは手動の上書き作成に使用できます。こ
のデータは unbound がクライアントに返しますが、DNSSEC 署名とはマークされません。
VPN ソフトウェアと同様に Net wo rkManager は設定を劇的に変更することが可能です。これらの設

定ディレクトリーには、コメントアウトしたエントリー例が含まれています。詳細情報は
unbound.conf(5) man ページを参照してください。
4.6.7.4. Dnssec-t rigger のインストール
dnssec-t rigger アプリケーションは dnssec-triggerd デーモンとして稼働します。dnssec-

t rigger をインストールするには、root ユーザーで以下のコマンドを実行します。
~]# yum install dnssec-trigger
4.6.7.5. Dnssec-t rigger デーモンの稼働確認
dnssec-triggerd が稼働しているかどうかを確認するには、以下のコマンドを実行します。
~]$ systemctl status dnssec-triggerd

systemctl status dnssec-triggerd.service
dnssec-triggerd.service - Reconfigure local DNS(SEC) resolver on network
change
Loaded: loaded (/usr/lib/systemd/system/dnssec-triggerd.service;
enabled)
Active: active (running) since Wed 2013-03-13 06:10:44 CET; 1h 41min
ago
systemctl status コマンドは、 dnssec-triggerd デーモンが稼働していなければ Active:

inactive (dead) とレポートします。dnssec-triggerd を現行セッションで起動するには、root
ユーザーで以下のコマンドを実行します。
90
~]# systemctl start dnssec-triggerd
systemctl enable コマンドを実行すると dnssec-triggerd がシステム起動時に毎回起動します。
~]# systemctl enable dnssec-triggerd
4.6.8. Dnssec-t rigger の使用
dnssec-t rigger アプリケーションには、DNSSEC プローブの結果を表示し、DNSSEC プローブ要求

をオンデマンドで実行するための GNOME パネルユーティリティーがあります。このユーティリティーを
起動するには、Super キーを押してアクティビティ画面に入り、DNSSEC と入力して Enter を押しま
す。船の錨に似たアイコンが画面下部のメッセージトレイに追加されます。画面右下の青く丸い通知アイコ
ンを押してこれを表示させます。錨アイコンを右クリックすると、ポップアップメニューが表示されま
す。
通常の操作では、unbo und はローカルでネームサーバーとして使用され、resolv.conf は

127.0.0.1 をポイントします。Hotspot Sign-On パネルの OK をクリックすると、これが変更されま
す。DNS サーバーが Net wo rkManager からクエリを受け、resolv.conf に置かれます。これで
Hots pot のサインオンページで認証が可能になります。錨アイコンは赤い大きな感嘆符を表示して、DNS
クエリが安全でない状態で行われていることを警告します。認証が行われると、dnssec-t rigger は自動
的にこれを検出し、セキュアモードに戻します。ただし、場合によってはこれができず、ユーザーが手動で
Reprobe を選択する必要があることもあります。
Dnssec-t rigger は通常、ユーザーとのやりとりを必要としません。一旦開始するとバックグラウンド

で稼働し、問題が発生したらポップアップのテキストボックスでユーザーに通知します。ま
た、resolv.conf ファイルへの変更を unbound に知らせます。
4.6.9. DNSSEC における dig の使用
DNSSEC が稼働しているかどうかを確認するには、様々なコマンドラインツールの使用が可能です。最適
なのは、bind-utils パッケージからの dig コマンドです。ldns パッケージからの drill とunbound パッ
ケージからの unbo und-ho st も有用です。nslo o kup および ho st という古い DNS ユーティリ
ティーは旧式なので使用しないでください。
dig を使用して DNSSEC データを要求するクエリを送信するには、以下のように+dnssec オプション

をコマンドに追加します。
~]$ dig +dnssec whitehouse.gov

; <<>> DiG 9.9.3-rl.13207.22-P2-RedHat-9.9.3-4.P2.el7 <<>> +dnssec
whitehouse.gov
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21388
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;whitehouse.gov. IN A
;; ANSWER SECTION:
whitehouse.gov. 20 IN A 72.246.36.110
whitehouse.gov. 20 IN RRSIG A 7 2 20 20130825124016 20130822114016 8399
whitehouse.gov. BB8VHWEkIaKpaLprt3hq1GkjDROvkmjYTBxiGhuki/BJn3PoIGyrftxR
HH0377I0Lsybj/uZv5hL4UwWd/lw6Gn8GPikqhztAkgMxddMQ2IARP6p
91
wbMOKbSUuV6NGUT1WWwpbi+LelFMqQcAq3Se66iyH0Jem7HtgPEUE1Zc 3oI=
;; Query time: 227 msec

;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Aug 22 22:01:52 EDT 2013
;; MSG SIZE rcvd: 233
A レコードに加えて RRSIG レコードが返されます。これには DNSSEC 署名と署名の取得および失効時間

が含まれています。unbound サーバーは、上部の flags: セクションで ad を返して、データが
DNSSEC 認証されていることを示しています。
DNSSEC 検証が失敗すると、dig は SERVFAIL エラーを返します。
~]$ dig badsign-a.test.dnssec-tools.org

; <<>> DiG 9.9.3-rl.156.01-P1-RedHat-9.9.3-3.P1.el7 <<>> badsign-
a.test.dnssec-tools.org
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 1010
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
; EDNS: version: 0, flags:; udp: 4096
;badsign-a.test.dnssec-tools.org. IN A

;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Aug 22 22:04:52 EDT 2013
;; MSG SIZE rcvd: 60]
失敗に関する詳細情報を要求するには、dig コマンドに +cd オプションを指定して DNSSEC 検査を無効

にすることができます。
~]$ dig +cd +dnssec badsign-a.test.dnssec-tools.org

; <<>> DiG 9.9.3-rl.156.01-P1-RedHat-9.9.3-3.P1.el7 <<>> +cd +dnssec
badsign-a.test.dnssec-tools.org
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26065
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
; EDNS: version: 0, flags: do; udp: 4096
;badsign-a.test.dnssec-tools.org. IN A
;; ANSWER SECTION:
badsign-a.test.dnssec-tools.org. 49 IN A 75.119.216.33
badsign-a.test.dnssec-tools.org. 49 IN RRSIG A 5 4 86400 20130919183720
20130820173720 19442 test.dnssec-tools.org.
E572dLKMvYB4cgTRyAHIKKEvdOP7tockQb7hXFNZKVbfXbZJOIDREJrr
zCgAfJ2hykfY0yJHAlnuQvM0s6xOnNBSvc2xLIybJdfTaN6kSR0YFdYZ
n2NpPctn2kUBn5UR1BJRin3Gqy20LZlZx2KD7cZBtieMsU/IunyhCSc0 kYw=
92

;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Aug 22 22:06:31 EDT 2013
;; MSG SIZE rcvd: 257
DNSSEC は、間違った取得または失効時間によってマニフェスト自体を誤解することが多くあります。た
だし上記の例では、www.dns s e c-tools .org のユーザーはわざとこの RRSIG 署名を分割しており、この
出力を見るだけでは検出できません。このエラーは systemctl status unbound の出力で表示さ
れ、unbound デーモンがこれらのエラーを syslo g に以下のように記録します。
Aug 22 22:04:52 laptop unbound: [3065:0] info: validation failure

badsign-a.test.dnssec-tools.org. A IN
以下は、unbound-host を使用した例です。
~]$ unbound-host -C /etc/unbound/unbound.conf -v whitehouse.gov

whitehouse.gov has address 184.25.196.110 (secure)
whitehouse.gov has IPv6 address 2600:1417:11:2:8800::fc4 (secure)
whitehouse.gov has IPv6 address 2600:1417:11:2:8000::fc4 (secure)
whitehouse.gov mail is handled by 105 mail1.eop.gov. (secure)
4.6.10. Dnssec-t rigger 用のホットスポット検出インフラストラクチャーの設定
ネットワークに接続する際に、dnssec-t rigger はホットスポットの検出を試みます。ホットスポット

は通常、ユーザーがネットワークリソースを利用できる前にウェブページとのやりとりを強制するデバイス
です。この検出は既知のコンテンツがある特定の固定ウェブページのダウンロード試行で行われます。ホッ
トスポットがある場合は、既知のコンテンツ以外のものがダウンロードされます。
dnssec-t rigger によるホットスポット検出に使用可能な、既知のコンテンツがある固定ウェブページ

を設定するには、以下の手順にしたがいます。
1. インターネット上で公開されているマシン上にウェブサーバーを設定します。Re d Hat
Ente rpris e Linux 7 システム管理者のガイドの We b サーバーの章を参照してください。
2. サーバーが稼働したら、既知のコンテンツがある静的ページを公開します。このページは、有効な
HTML ページである必要はありません。たとえば、hotspot.txt という名前のプレーンテキスト
ファイルで OK という文字列の内容だけでも構いません。サーバーが example.com にあり、そ
のサーバーのサブディレクトリー document_root/static/ に hotspot.txt ファイルを公
開したとすると、この静的ページのアドレスは、example.com/static/hotspot.txt になり
ます。Re d Hat Ente rpris e Linux 7 システム管理者のガイドの We b サーバーの章にある
DocumentRoot ディレクティブを参照してください。
3. 以下の行を /etc/dnssec-trigger/dnssec-trigger.conf ファイルに追加します。
url: "http://example.com/static/hotspot.txt OK"
このコマンドは、HTTP (ポート 80) 経由でプローブされる URL を追加します。最初の部分は解決

される URL とダウンロードされるページで、後の部分はダウンロードしたウェブページに含まれ
ることになる文字列です。
93
設定オプションに関する詳細情報は、man ページ dnssec-trigger.conf(8) を参照してください。
4.6.11. 接続によって提供されるドメイン用の DNSSEC 検証の設定
デフォルトでは、適切なネームサーバーのある転送ゾーンは、Wi-Fi 以外の接続が提供するドメインすべて
について dnssec-t rigger が自動的に Net wo rkManager で unbound に追加します。デフォルト
では、unbound に追加されるすべての転送ゾーンは DNSSEC 検証されています。
転送ゾーンの検証におけるデフォルト動作は変更可能なので、すべての転送ゾーンがデフォルトで
DNSSEC 検証されるわけれはありません。すべてを検証するようにするには、 dnssec-t rigger 設定
ファイルである /etc/dnssec.conf にある validate_connection_provided_zones 変数を変
更します。root ユーザーでファイルを開き、以下のように行を編集します。
validate_connection_provided_zones=no
この変更は既存の転送ゾーンではなく、将来の転送ゾーンにのみ有効になります。このため、現在提供され
ているドメインについて DNSSEC を無効にするには、再接続が必要になります。
4.6.11.1. Wi-Fi が提供するドメイン用の DNSSEC 検証の設定
Wi-Fi が提供するゾーンへの転送ゾーンの追加を有効にすることができます。これを行うには、dnssec-
t rigger の設定ファイル /etc/dnssec.conf にある add_wifi_provided_zones 変数を変更しま
す。 root ユーザーでファイルを開き、以下のように行を編集します。
add_wifi_provided_zones=yes
この変更は既存の転送ゾーンではなく、将来の転送ゾーンにのみ有効になります。このため、現在 Wi-Fi が
提供するドメインについて DNSSEC を有効にするには、Wi-Fi 再接続 (再起動) が必要になります。
警告
Wi-Fi 提供ドメインを転送ゾーンとして unbound に追加することをオンにすると、セキュリティ

面で以下のような影響があります。
1. Wi-Fi アクセスポイントは意図的に、DHCP 経由でドメインを提供することが可能です。こ

のドメインは認証されていないもので、ユーザーの DNS クエリすべてをこのアクセスポイ
ントの DNS サーバーにルーティングしてしまいます。
2. 転送ゾーンの DNSSEC 検証をオフにすると、Wi-Fi 提供の DNSサーバーは、ユーザーが
知らない間に提供されたドメインからドメインネームの IP アドレスのなりすましができる
ようになります。
以下のリソースでは、DNSSEC について詳細な説明が提供されています。
dnssec-trigger(8) man ページ — dnssec-triggerd、dnssec-t rigger-co nt ro l および

dnssec-t rigger-panel のコマンドオプションについて説明しています。
dnssec-trigger.conf(8) man ページ — dnssec-triggerd の設定オプションについて説明し

ています。
94
unbound(8) man ページ — unbound、DNS 検証リゾルバーのコマンドオプションについて説明し

ています。
unbound.conf(5) man ページ — unbound の設定方法についての情報が含まれています。
resolv.conf(5) man ページ — リゾルバールーチンが読み取る情報が含まれています。
4.6.12.2. オンラインのドキュメント
ht t p://t o o ls.iet f .o rg/ht ml/rf c40 33
RFC 4033 DNS Se curity Introduction and Re quire me nts .
ht t p://www.dnssec.net /
DNSSEC リソースに関する多くのリンクがあるウェブサイトです。
ht t p://www.dnssec-deplo yment .o rg/
米国土安全保障省が後援する DNSSEC De ployme nt Initiative です。DNSSEC に関する多く

の情報と DNSSEC 導入に関する問題を話し合うメーリングリストが含まれています。
ht t p://www.int ernet so ciet y.o rg/deplo y360 /dnssec/co mmunit y/
Inte rne t Socie ty の「De ploy 360」イニシアチブで、DNSSEC 導入の活性化と調整を図り

ます。世界中のコミュニティーと DNSSEC アクティビティーを探す便利なリソースになりま
す。
ht t p://www.unbo und.net /
unbound DNS サービスに関する全般的な情報が含まれています。
ht t p://www.nlnet labs.nl/pro ject s/dnssec-t rigger/
dnssec-t rigger に関する全般的な情報が含まれています。
4.7. 仮想プライベートネットワーク (VPN) のセキュア化
Re d Hat Ente rpris e Linux 7 では、仮想プライベートネットワーク (VPN) は、Libreswan アプリ

ケーションがサポートしている IPsec トンネリングプロトコルを使って設定できます。Libreswan は
Openswan アプリケーションの分岐で、ドキュメント内の例は交換可能なもので
す。Net wo rkManager IPsec プラグインは、NetworkManager-libreswan と呼ばれます。GNOME
She ll のユーザーは、NetworkManager-libreswan-gnome パッケージをインストールしてください。こ
れには、依存関係として NetworkManager-libreswan が含まれています。NetworkManager-
libreswan-gnome は、Optional チャンネルからのみ入手可能です。Enabling Supple me ntary and
Optional Re pos itorie s を参照してください。
Libreswan は、Re d Hat Ente rpris e Linux 7 で利用可能なオープンソースのユーザースペース

IPsec 実装です。インターネット鍵交換 (IKE) プロトコルを使用します。IKE バージョン 1 および 2
は、ユーザーレベルのデーモンとして実装されます。ip xfrm コマンドを使って、手動で鍵を確立するこ
とも可能ですが、これは推奨されません。Libreswan は、ne tlink を使って Linux カーネルとインター
フェイス接続し、暗号化鍵を送信します。パケットの暗号化と暗号解読は、Linux カーネルで行われます。
Libreswan はネットワークセキュリティサービス (NSS) 暗号化ライブラリーを使用します。これ

は、Federal Information Processing Standard: 米連邦情報処理規格 (FIPS) のセキュリティ準拠に必
要なものです。
95
重要
Libreswan が実施する IPsec は、Re d Hat Ente rpris e Linux 7 での使用が推奨される唯一の

VPN 技術です。他の VPN は、そのリスクを理解することなく使用しないでください。
4.7.1. Libreswan を使った IPsec VPN
Libreswan をインストールするには、以下のコマンドをroot で実行します。
~]# yum install libreswan
Libreswan がインストールされているかどうかを確認するには、以下のコマンドを実行します。
~]$ yum info libreswan
Libreswan を新規インストールすると、NSS データベースがインストールプロセスの一部として初期化

されます。ただし、新規データベースを起動する必要がある場合は、以下のようにまず、古いデータベース
を削除してください。
~]# rm /etc/ipsec.d/*db
その後に以下のコマンドを root で実行して、新規 NSS データベースを初期化します。
~]# ipsec initnss

Enter a password which will be used to encrypt your keys.
The password should be at least 8 characters long,
and should contain at least one non-alphabetic character.
Enter new password:

Re-enter password:
NSS にパスワードを使用しない場合は、パスワードのプロンプトで Enter を 2 回押します。パスワード

を入力した場合は、システム起動時など、Libreswan の起動ごとに毎回パスワードの入力が必要になり
ます。
Libreswan が提供する ipsec デーモンの稼働を確認するには、以下のコマンドを実行します。
~]$ systemctl status ipsec

ipsec.service - Internet Key Exchange (IKE) Protocol Daemon for IPsec
Loaded: loaded (/usr/lib/systemd/system/ipsec.service; disabled)
Active: inactive (dead)
Libreswan が提供する ipsec デーモンを起動するには、root で以下のコマンドを実行します。
~]# systemctl start ipsec
デーモンが稼働していることを確認します。
96
~]$ systemctl status ipsec

ipsec.service - Internet Key Exchange (IKE) Protocol Daemon for IPsec
Loaded: loaded (/usr/lib/systemd/system/ipsec.service; disabled)
Active: active (running) since Wed 2013-08-21 12:14:12 CEST; 18s ago
システム起動時に Libreswan が起動するようにするには、root で以下のコマンドを実行します。
~]# systemctl enable ipsec
中間およびホストベースのファイアウォールが ipsec サービスを許可するように設定します。ファイア

ウォールおよび特定サービスの通過を許可することについての詳細情報は、「ファイアウォールの使用」
を参照してください。Libreswan の使用には、以下のパケットがファイアウォールを通過できるように
しておく必要があります。
Internet Key Exchange (IKE) プロトコル用に UDP ポート 500
IKE NAT-Traversal 用に UDP ポート 4500
Encapsulated Security Payload (ESP) IPsec パケット用にプロトコル 50
Authenticated Header (AH) IPsec パケット用にプロトコル 51 (一般的でない)
Libreswan を使って IPsec VPN を設定する例を 3 つ紹介します。ひとつ目は、2 つのホストを接続し

てセキュアな通信ができるようにします。2 つ目は、2 つのサイトを接続して 1 つのネットワークを形成
します。3 つ目は、このコンテキストではロードウォリアーと呼ばれるローミングユーザーをサポートし
ます。
4.7.2. Libreswan を使った VPN 設定
Libreswan では、「ソース」や「宛先」といった用語を使用しません。代わりに、エンドポイント (ホ

スト) に向かって「左」および「右」という用語を使用します。これにより、ほとんどのケースで両方の
エンドポイントで同じ設定が使えるようになります。ただし、ほとんどの管理者はローカルホスト
に「左」を、リモートホストに「右」を使用します。
エンドポイントの認証には、3 つの一般的な方法が使用されます。
事前共有鍵 (PSK) は、最もシンプルな認証方法です。PSK は任意の 20 以上の文字で構成されます。

PSK が任意でなくかつ短いものになる危険があることから、システムが FIPS モードで稼働している際
は、この方法は利用できません。
生 RSA 鍵は、静的なホスト間またはサブネット間で一般的に使用される IPsec 設定です。ホスト

は、それぞれの公開 RSA 鍵で手動で設定されます。この方法は、12 以上のホストで相互に IPsec ト
ンネルを設定する必要がある場合には、うまく拡張できません。
X.509 証明書は、共通の IPsec ゲートウェイに接続する必要のあるホストが多くある、大型の導入案

件でよく使用されます。ホストまたはユーザーの RSA 証明書の署名には、中央認証機関 (CA) が使用
されます。この中央 CA は、個別ホストまたはユーザーの取り消しを含む信頼の中継を担当します。
4.7.3. Libreswan を使用したホスト間の VPN
Libreswan が「左」および「右」と呼ばれる 2 つのホスト間で IPsec VPN を作成するよう設定す

るには、「左」のホスト上で root で以下のコマンドを実行し、新たな生 RSA 鍵のペアを作成します。
~]# ipsec newhostkey --configdir /etc/ipsec.d \

--output /etc/ipsec.d/www.example.com.secrets
Generated RSA key pair using the NSS database
97
これでホストの RSA 鍵のペアが生成されます。エントロピーが低い仮想マシンでは特に、RSA 鍵の生成

プロセスは時間が長くかかる場合があります。
公開鍵を表示するには、「左」と呼ばれるホスト上で root で以下のコマンドを実行します。
~]# ipsec showhostkey --left

# rsakey AQOrlo+hO
leftrsasigkey=0sAQOrlo+hOafUZDlCQmXFrje/oZm [...] W2n417C/4urYHQkCvuIQ==
以下で説明するように、この鍵を設定ファイルに追加する必要があります。
「右」と呼ばれるホスト上で root で以下のコマンドを実行します。
~]# ipsec newhostkey --configdir /etc/ipsec.d \

--output /etc/ipsec.d/www.example.com.secrets
Generated RSA key pair using the NSS database
公開鍵を表示するには、「右」と呼ばれるホスト上で root で以下のコマンドを実行します。
~]# ipsec showhostkey --right

# rsakey AQO3fwC6n
rightrsasigkey=0sAQO3fwC6nSSGgt64DWiYZzuHbc4 [...] D/v8t5YTQ==
この鍵を設定ファイルに追加する必要があります。
秘密の部分は、「NSS データベース」とも呼ばれる /etc/ipsec.d/*.db ファイルに保存されます。
このホスト間のトンネル用に設定ファイルを作成するには、上記の leftrsasigkey= と
rightrsasigkey= の各行を /etc/ipsec.d/ ディレクトリー内のカスタム設定ファイルに記載しま
す。Libreswan がカスタム設定ファイルを読み取れるようにするには、root でエディターを実行し、
メイン設定ファイルである /etc/ipsec.conf で以下の行の # 文字を削除します。これで、以下の行が
有効になります。
include /etc/ipsec.d/*.conf
root でエディターを使用して以下の形式で適切な名前のファイルを作成します。
/etc/ipsec.d/my_host-to-host.conf
以下のようにファイルを編集します。
conn mytunnel
leftid=@west.example.com
left=192.1.2.23
leftrsasigkey=0sAQOrlo+hOafUZDlCQmXFrje/oZm [...]
W2n417C/4urYHQkCvuIQ==
rightid=@east.example.com
right=192.1.2.45
authby=rsasig
# load and initiate automatically
auto=start
左右両方のホストに同一の設定ファイルを使用することができます。ホストは「左」か「右」かを自動検出
します。ホストのいずれかがモバイルホストであり、IP アドレスが事前に分からない場合は、モバイルホ
98
ストの IP アドレスに %defaultroute を使用します。これで動的 IP アドレスが自動的に拾われます。

モバイルホストからの接続を受け付ける静的ホストでは、IP アドレスに %any を指定します。
leftrsasigkey の値が「左」のホストから、rightrsasigkey の値が「右」のホストからであること

を確認してください。
ipsec を再起動して、変更された設定を読み込みます。
~]# systemctl restart ipsec
root で以下のコマンドを実行して、IPsec トンネルを読み込みます。
~]# ipsec auto --add mytunnel
左右いずれかでトンネルを表示するには、root で以下のコマンドを実行します。
~]# ipsec auto --up mytunnel
4.7.3.1. Libreswan を使ったホスト間 VPN の検証
IKE 交渉は、UDP ポート 500 で行われます。IPsec パケットは、Encapsulated Security

Payload (ESP) パケットとして現れます。VPN 接続が NAT ルーターを通過する必要がある場合は、ESP
パケットはポート 4500 上の UDP パケットにカプセル化されます。
パケットが VPN トンネル経由で送信されていることを確認するには、root で以下の形式のコマンドを実

行します。
~]# tcpdump -n -i interface esp and udp port 500 and udp port 4500
00:32:32.632165 IP 192.1.2.45 > 192.1.2.23:
ESP(spi=0x63ad7e17,seq=0x1a), length 132
00:32:32.632592 IP 192.1.2.23 > 192.1.2.45:
ESP(spi=0x4841b647,seq=0x1a), length 132
00:32:32.632592 IP 192.0.2.254 > 192.0.1.254: ICMP echo reply, id 2489,
seq 7, length 64
00:32:33.632221 IP 192.1.2.45 > 192.1.2.23:
ESP(spi=0x63ad7e17,seq=0x1b), length 132
00:32:33.632731 IP 192.1.2.23 > 192.1.2.45:
ESP(spi=0x4841b647,seq=0x1b), length 132
seq 8, length 64
00:32:34.632183 IP 192.1.2.45 > 192.1.2.23:
ESP(spi=0x63ad7e17,seq=0x1c), length 132
00:32:34.632607 IP 192.1.2.23 > 192.1.2.45:
ESP(spi=0x4841b647,seq=0x1c), length 132
seq 9, length 64
00:32:35.632233 IP 192.1.2.45 > 192.1.2.23:
ESP(spi=0x63ad7e17,seq=0x1d), length 132
00:32:35.632685 IP 192.1.2.23 > 192.1.2.45:
ESP(spi=0x4841b647,seq=0x1d), length 132
seq 10, length 64
ここでの interface は、監視するインターフェイスになります。t cpdump での表示を終了するに

は、Ctrl+C を押します。
99
注記
t cpdump コマンドと IPsec のインタラクションはやや予想外のものになります。見えるのは暗

号化された送信パケットのみで、プレーンテキストの送信パケットは見えません。受信パケット
は、暗号化および暗号解読された両方を表示します。可能であれば、t cpdump コマンドはどちら
かのエンドポイント上ではなく、2 つのマシン間にあるルーター上で実行してください。
4.7.4. Libreswan を使ったサイト間の VPN
Libreswan が 2 つのネットワークを結合させるサイト間の IPsec VPN を作成するようにするには、エ

ンドポイントとなる 2 つのホスト間に IPsec トンネルを作成します。これらのホストは、1 つ以上のサブ
ネットからのトラフィック通過を許可するよう設定します。このため、これらはネットワークのリモート部
分にはゲートウェイのように見えます。サイト間 VPN とホスト間 VPN の唯一の違いは、前者では 1 つ以
上のネットワークまたはサブネットを設定ファイルで指定する必要があるという点です。
サイト間 IPsec VPN を作成するように Libreswan を設定するには、まず「Libre s wan を使用したホ

スト間の VPN」にあるようにホスト間の IPsec VPN を設定し、その設定ファイルを
/etc/ipsec.d/my_site-to-site.conf などの適切なファイル名にコピーまたは移動します。root
としてエディターを使用して、カスタム設定ファイルである /etc/ipsec.d/my_site-to-
site.conf を以下のように編集します。
conn mysubnet
also=mytunnel
leftsubnet=192.0.1.0/24
rightsubnet=192.0.2.0/24
conn mysubnet6
also=mytunnel
connaddrfamily=ipv6
leftsubnet=2001:db8:0:1::/64
rightsubnet=2001:db8:0:2::/64
conn mytunnel
auto=start
left=192.1.2.23
right=192.1.2.45
authby=rsasig
トンネルを表示するには、Libreswan を再起動するか、root で以下のコマンドを実行して手動ですべて

の接続を読み込み、開始します。
~]# ipsec auto --add mysubnet
~]# ipsec auto --add mysubnet6
~]# ipsec auto --add mytunnel
100
~]# ipsec auto --up mysubnet

104 "mysubnet" #1: STATE_MAIN_I1: initiate
003 "mysubnet" #1: received Vendor ID payload [Dead Peer Detection]
003 "mytunnel" #1: received Vendor ID payload [FRAGMENTATION]
106 "mysubnet" #1: STATE_MAIN_I2: sent MI2, expecting MR2
108 "mysubnet" #1: STATE_MAIN_I3: sent MI3, expecting MR3
003 "mysubnet" #1: received Vendor ID payload [CAN-IKEv2]
004 "mysubnet" #1: STATE_MAIN_I4: ISAKMP SA established
{auth=OAKLEY_RSA_SIG cipher=aes_128 prf=oakley_sha group=modp2048}
117 "mysubnet" #2: STATE_QUICK_I1: initiate
004 "mysubnet" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel
mode {ESP=>0x9414a615 <0x1a8eb4ef xfrm=AES_128-HMAC_SHA1 NATOA=none
NATD=none DPD=none}
~]# ipsec auto --up mysubnet6

117 "mysubnet" #2: STATE_QUICK_I1: initiate
004 "mysubnet" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel
mode {ESP=>0x06fe2099 <0x75eaa862 xfrm=AES_128-HMAC_SHA1 NATOA=none
NATD=none DPD=none}
~]# ipsec auto --up mytunnel

104 "mytunnel" #1: STATE_MAIN_I1: initiate
003 "mytunnel" #1: received Vendor ID payload [Dead Peer Detection]
106 "mytunnel" #1: STATE_MAIN_I2: sent MI2, expecting MR2
108 "mytunnel" #1: STATE_MAIN_I3: sent MI3, expecting MR3
003 "mytunnel" #1: received Vendor ID payload [CAN-IKEv2]
004 "mytunnel" #1: STATE_MAIN_I4: ISAKMP SA established
{auth=OAKLEY_RSA_SIG cipher=aes_128 prf=oakley_sha group=modp2048}
117 "mytunnel" #2: STATE_QUICK_I1: initiate
004 "mytunnel" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel
mode {ESP=>0x9414a615 >0x1a8eb4ef xfrm=AES_128-HMAC_SHA1 NATOA=none
NATD=none DPD=none}
4.7.4.1. Libreswan を使ったサイト間 VPN の検証
パケットが VPN トンネル経由で送信されていることを確認する方法は、「Libre s wan を使ったホスト間

VPN の検証」で説明されている手順と同じになります。
4.7.5. Libreswan を使ったサイト間の単一トンネル VPN
サイト間のトンネルを構築する際には、ゲートウェイは公開 IP アドレスではなく、内部の IP アドレスを

使って相互に通信する必要が多くあります。これは、単一トンネルを使用することで実行できます。ホスト
名が west の左のホストの内部 IP アドレスが 192.0.1.254 で、ホスト名が east の右のホストの IP
アドレスが 192.0.2.254 の場合、単一トンネルを使った以下の設定が使用できます。
conn mysubnet
left=192.1.2.23
leftsourceip=192.0.1.254
101
right=192.1.2.45
rightsourceip=192.0.2.254
auto=start
authby=rsasig
4.7.6. Libreswan を使ったサブネット押し出し
IPsec は、ハブおよびスポークのアーキテクチャーで導入されることがよくあります。各リーフノードに
は、広い範囲の一部である IP 範囲があります。各リーフはハブ経由で相互に通信します。これは、サブ
ネット押し出しと呼ばれます。下記の例では、ヘッドオフィスを 10.0.0.0/8 で設定し、2 つのブラン
チでは小型の /24 サブネットを使用します。
ヘッドオフィスでは以下のようになります。
conn branch1
left=1.2.3.4
leftid=@headoffice
leftrsasigkey=0sA[...]
#
right=5.6.7.8
rightid=@branch1
righsubnet=10.0.1.0/24
rightrsasigkey=0sAXXXX[...]
#
auto=start
authby=rsasigkey
conn branch2
left=1.2.3.4
leftid=@headoffice
#
right=10.11.12.13
rightid=@branch2
rightrsasigkey=0sAYYYY[...]
#
auto=start
authby=rsasigkey
「branch1」オフィスでは、同一の接続を使用します。さらに、パススルー (pas s -through) 接続を使用

して、ローカル LAN トラフィックをトンネル経由の送信から除外します。
conn branch1
left=1.2.3.4
leftid=@headoffice
#
102
right=10.11.12.13
rightid=@branch2
rightrsasigkey=0sAYYYY[...]
#
auto=start
authby=rsasigkey
conn passthrough
left=1.2.3.4
right=0.0.0.0
authby=never
type=passthrough
auto=route
4.7.7. Libreswan を使ったロードウォリアーアプリケーション
ロードウォリアーとは、ノート PC などのモバイルクライアントを使用する移動ユーザーのことで、これら
のクライアントには動的に IP アドレスが割り当てられます。これは、証明書を使って認証します。
サーバー上では以下の設定になります。
conn roadwarriors
left=1.2.3.4
# if access to the LAN is given, enable this
#leftsubnet=10.10.0.0/16
leftcert=gw.example.com
leftid=%fromcert
right=%any
# trust our own Certificate Agency
rightca=%same
# allow clients to be behind a NAT router
rightsubnet=vhost:%priv,%no
authby=rsasigkey
# load connection, don't initiate
auto=add
# kill vanished roadwarriors
dpddelay=30
dpdtimeout=120
dpdaction=%clear
ロードウォリアーのデバイスであるモバイルクライアント上では、上記の設定に多少変更を加えて使用しま
す。
conn roadwarriors
# pick up our dynamic IP
left=%defaultroute
leftcert=myname.example.com
leftid=%fromcert
# right can also be a DNS hostname
right=1.2.3.4
# if access to the remote LAN is required, enable this
#rightsubnet=10.10.0.0/16
103
# trust our own Certificate Agency

rightca=%same
authby=rsasigkey
# Initiate connection
auto=start
4.7.8. Libreswan および X.509 証明書による XAUT H を使ったロードウォリアーア

プリケーション
Libreswan は、接続確立の際に XAUTH IPsec 拡張機能を使って、ローミング VPN クライアントに対

してネイティブに IP アドレスと DNS 情報を割り当てる方法を提供します。XAUTH は、PSK または
X.509 証明書を使って導入することができます。X.509 を使った導入の方がより安全です。クライアント
の証明書は、証明書失効リストまたは Online Certificate Status Protocol (OCSP) で失効させることが
できます。X.509 証明書を使うと、個別のクライアントはサーバーを偽装することができません。グルー
プパスワードとも呼ばれる PSK を使うと、これは理論上は可能になります。
XAUTH は、それ自体とユーザー名およびパスワードを新たに確認するために、VPN クライアントを必要

とします。Google 認証システムや RSA Se cure ID トークンなどのワンタイムパスワード (OTP) では、
ユーザーパスワードにワンタイムトークンが付けられます。
XAUTH では、以下の 3 つのバックエンドが考えられます。

xauthby=pam
これは、/etc/pam.d/pluto にある設定を使用してユーザーを認証します。Pam は、それ自

体で様々なバックエンドを使用するように設定できます。システムアカウントのユーザーパス
ワードスキームや LDAP ディレクトリー、RADIUS サーバー、カスタムパスワード認証モ
ジュールなどが使用可能です。
xauthby=file
これは、設定ファイル /etc/ipsec.d/passwd (/etc/ipsec.d/nsspassword と混同し

ないこと) を使用します。このファイルの形式は Apache .htpasswd ファイルと同様のもの
で、Apache htpasswd コマンドはこのファイルのエントリー作成に使用できます。ただし、
ユーザー名とパスワードの後に、使用する IPsec 接続の接続名が 3 番目のコラムに必要になり
ます。たとえば、"conn re mote us e rs " を使用してリモートユーザーに VPN を提供する場
合、パスワードファイルのエントリーは以下のようになります。
user1:$apr1$MIwQ3DHb$1I69LzTnZhnCT2DPQmAOK.:remoteusers
htpasswd コマンドを使用する際は、各行の user:password の後に接続名を手動で追加する必

要があることに注意してください。
xauthby=alwaysok
サーバーは常に、XAUTH ユーザーとパスワードの組み合わせが適切であるように装います。
サーバーはユーザー名とパスワードを無視しますが、クライアントはこれらを指定する必要があ
ります。これはユーザーが X.509 証明書で既に特定されている場合、もしくは XAUTH バック
エンドが不要な VPN をテストしている場合にのみ使用します。
X.509 証明書を使った設定例を以下に示します。
conn xauth-rsa
auto=add
authby=rsasig
pfs=no
rekey=no
104
left=ServerIP
leftcert=vpn.example.com
#leftid=%fromcert
leftid=vpn.example.com
leftsendcert=always
rightaddresspool=10.234.123.2-10.234.123.254
right=%any
rightrsasigkey=%cert
modecfgdns1=1.2.3.4
modecfgdns2=8.8.8.8
modecfgdomain=example.com
modecfgbanner="Authorized Access is allowed"
leftxauthserver=yes
rightxauthclient=yes
leftmodecfgserver=yes
rightmodecfgclient=yes
modecfgpull=yes
xauthby=pam
dpddelay=30
dpdtimeout=120
dpdaction=clear
ike_frag=yes
# for walled-garden on xauth failure
# xauthfail=soft
#leftupdown=/custom/_updown
xauthfail を hard ではなく s oft に設定すると認証失敗は無視され、VPN はユーザーが適切に認証し

たかのように設定されます。カスタムのアップダウンスクリプトを使用すると、環境変数 XAUTH_FAILED
をチェックできます。このようなユーザーは、たとえば iptable s DNAT を使って「walle d garde n」
にリダイレクトすることが可能です。リダイレクト先では管理者に連絡を取ったりサービスの有料サブスク
リプションの更新などができます。
VPN クライアントは、modecfgdomain の値と DNS エントリーを使って特定ドメインに対するクエリを

指定されたネームサーバーにリダイレクトします。これにより、ローミングユーザーは内部 DNS ネームを
使って内部のみのリソースにアクセスできるようになります。
leftsubnet が 0.0.0.0/0 でない場合は、分割トンネリング設定要求が自動的にクライアントに送信さ

れます。たとえば、leftsubnet=10.0.0.0/8 を使用すると、VPN クライアントは 10.0.0.0/8 のト
ラフィックのみを VPN 経由で送信します。
以下のソースでは、Libreswan および ipsec デーモンに関する追加リソースが提供されています。
ipsec(8) man ページ — ipsec のコマンドオプションを説明しています。
ipsec.conf(5) man ページ — ipsec の設定情報が含まれています。
ipsec.secrets(5) man ページ — ipsec.secrets ファイルの形式を説明しています。
ipsec_auto(8) man ページ — 鍵の自動交換を使用して確立された Libreswan IPsec 接続を操

作する aut o コマンドラインクライアントの使用方法を説明しています。
ipsec_rsasigkey(8) man ページ — RSA 署名鍵の生成に使用するツールを説明しています。
105
/usr/share/doc/libreswan-version/README.nss — Libreswan pluto デーモンの NSS

暗号化ライブラリーで使用する生 RSA 鍵と証明書の使用に関するコマンドを説明しています。
4.7.9.2. オンラインのドキュメント
ht t ps://libreswan.o rg
アップストリームプロジェクトの We b サイトです。
ht t p://www.mo zilla.o rg/pro ject s/securit y/pki/nss/
Ne twork Se curity Se rvice s (NSS) プロジェクトです。
4.8. OpenSSL の使用
OpenSSL は、アプリケーションに暗号化プロトコルを提供するライブラリーです。o penssl コマンド

ラインユーティリティーを使うと、シェルから暗号化機能が使えるようになります。これには、インタラク
ティブモードが含まれています。
o penssl コマンドラインユーティリティーには多くの擬似コマンドがあり、システムにインストールされ
た o penssl のバージョンが対応しているコマンドに関する情報を提供します。擬似コマンドlist-
standard-commands、list-message-digest-commands、および list-cipher-commands は
それぞれ、すべての標準コマンド一覧、メッセージダイジェストコマンド一覧、暗号コマンド一覧を出力し
ます。これは、現行の o penssl ユーティリティーで利用可能なものです。
擬似コマンド list-cipher-algorithms および list-message-digest-algorithms は、すべ

ての暗号およびメッセージダイジェストネームを一覧表示します。擬似コマンド list-public-key-
algorithms は、対応するすべての公開鍵アルゴリズムを一覧表示します。たとえば、対応するすべての
公開鍵アルゴリズムを一覧表示するには、以下のコマンドを実行します。
~]$ openssl list-public-key-algorithms
擬似コマンド no-command-name は、指定されたネームの command-name が利用可能かどうかをテ

ストします。詳細情報は、openssl(1) の man ページを参照してください。
4.8.1. 暗号鍵の作成と管理
OpenSSL では、公開鍵は対応する秘密鍵から生成されます。このため、アルゴリズムを決定した後に最
初に行うことは、秘密鍵の生成になります。以下の例では、秘密鍵を privkey.pem とします。たとえば、
デフォルトのパラメーターを使用して RSA 秘密鍵を作成するには、以下のコマンドを実行します。
~]$ openssl genpkey -algorithm RSA -out privkey.pem
RSA アルゴリズムは以下のオプションに対応しています。
rsa_keygen_bits:numbits — 生成される鍵のビット数です。指定されない場合は、1024 が使わ

れます。
rsa_keygen_pubexp:value — RSA 公開指数の値です。これは大きな十進数か、0x で始まる場合

は十六進数にすることができます。デフォルト値は 65537 です。
たとえば、公開指数に 3 を使用して 2048 ビットの RSA 秘密鍵を作成するには、以下のコマンドを実行

します。
106
~]$ openssl genpkey -algorithm RSA -out privkey.pem -pkeyopt

rsa_keygen_bits:2048 \ -pkeyopt rsa_keygen_pubexp:3
128 ビットの AES とパスフレーズ「he llo」を使用してこの秘密鍵を出力する際に暗号化するには、以

~]$ openssl genpkey -algorithm RSA -out privkey.pem -aes-128-cbc -pass

pass:hello
秘密鍵の生成に関する詳細情報は、genpkey(1) の man ページを参照してください。
4.8.2. 証明書の生成
OpenSSL を使って証明書を生成するには、秘密鍵が利用可能である必要があります。以下の例では、秘
密鍵を privkey.pem とします。秘密鍵をまだ生成していない場合は、「暗号鍵の作成と管理」を参照し
てください。
証明書に認証局 (CA) による署名を受けるには、証明書を生成して認証局に送信する必要があります。これ

は、証明書署名要求と呼ばれます。詳細情報は、「証明書署名要求の作成」を参照してください。別の方
法では、自己署名の証明書を作成します。詳細情報は、「自己署名証明書の作成」を参照してください。
4.8.2.1. 証明書署名要求の作成
CA に提出する証明書を作成するには、コマンドを以下の形式で実行します。
~]$ openssl req -new -key privkey.pem -out cert.csr
これで、デフォルトの privacy-enhanced electronic mail (PEM) 形式でエンコードされた cert.csr

と呼ばれる X.509 証明書が作成されます。PEM という名前は、「Privacy Enhance me nt for Inte rne t
Ele ctronic Mail」に由来し、RFC 1424 で説明されています。別の DER 形式で証明書ファイルを生成す
るには、-outform DER コマンドオプションを使用します。
上記のコマンドを発行すると、証明書の識別名 (DN) を作成するために、ユーザー自身の情報と組織の情報

が求められます。以下の情報が必要になります。
2 文字の国コード
州または県の名前
市または自治体
組織の名前
組織内の部署名
ユーザー名もしくはシステムのホスト名
Email アドレス
req(1) man ページでは、 PKCS# 10 証明書要求とユーティリティーの生成について説明されていま

す。証明書作成プロセスで使用されるデフォルト設定は、/etc/pki/tls/openssl.cnf ファイル内に
あります。詳細は、openssl.cnf(5) man ページを参照してください。
4.8.2.2. 自己署名証明書の作成
366 日間有効の自己署名証明書を生成するには、以下の形式でコマンドを実行します。
107
~]$ openssl req -new -x509 -key privkey.pem -out selfcert.pem -days 366
4.8.2.3. Makef ile を使った証明書の作成
/etc/pki/tls/certs ディレクトリーには Makefile が格納されており、これに make コマンドを使

用すると証明書が作成できます。使用方法を確認するには、以下のコマンドを実行します。
~]$ make -f /etc/pki/tls/certs/Makefile
または、ディレクトリーに移動して以下のように make コマンドを実行することもできます。
~]$ cd /etc/pki/tls/certs/
~]$ make
詳細情報は、make(1) man ページを参照してください。
4.8.3. 証明書の検証
CA 署名がされている証明書は、信頼できる証明書と呼ばれます。このため、自己署名証明書は、信頼され
ない証明書になります。検証ユーティリティーは、OpenSSL が通常の工程で使用するものと同じ SSL
および S/MIME 機能を使用します。エラーが見つかると報告され、他のエラーを見つけるためにテストを
継続する試みがなされます。
PEM 形式の複数の X.509 証明書を検証するには、以下の形式のコマンドを実行します。
~]$ openssl verify cert1.pem cert2.pem
証明書チェーンを検証するには、リーフ証明書が cert.pem にあり、信頼していない中間証明書が

untrusted.pem 内で直接連結している必要があります。信頼できる root CA 証明書
は、/etc/pki/tls/certs/ca-bundle.crt または cacert.pem でリスト表示されているデフォル
トの CA 内にある必要があります。この状態でチェーンを検証するには、以下の形式のコマンドを実行しま
す。
~]$ openssl verify -untrusted untrusted.pem -CAfile cacert.pem cert.pem
詳細情報は、verify(1) man ページを参照してください。
4.8.4. ファイルの暗号化および暗号化解除
ファイル plaintext を暗号化するには、以下のコマンドを実行します。
~]$ openssl pkeyutl -in plaintext -out cyphertext -inkey privkey.pem
鍵および証明書のデフォルトの形式は PEM です。必要に応じて -keyform DER コマンドを使用し、

DER 鍵形式を指定します。
暗号化エンジンを指定するには、-engine コマンドを以下のように使用します。
~]$ openssl pkeyutl -in plaintext -out cyphertext -inkey privkey.pem -

engine id
108
ここでの id は、暗号化グラフィックエンジンの ID です。エンジンが利用可能かどうかを確認するには、

以下のコマンドを実行します。
~]$ openssl engine -t
データファイル plaintext に署名するには、以下のコマンドを実行します。
~]$ openssl pkeyutl -sign -in plaintext -out sigtext -inkey privkey.pem
署名されたデータファイルを検証し、データを抽出するには、以下のコマンドを実行します。
~]$ openssl pkeyutl -verifyrecover -in sig -inkey key.pem
DSA 鍵などを使用した署名を検証するには、以下のコマンドを実行します。
~]$ openssl pkeyutl -verify -in file -sigfile sig -inkey key.pem
pkeyutl(1) man ページでは、公開鍵アルゴリズムのユーティリティーについての説明があります。
4.8.5. メッセージダイジェストの生成
dgst コマンドは、十六進数形式で提供されたファイルのメッセージダイジェストを作成します。このコマ
ンドは、デジタル署名および検証にも使用できます。メッセージダイジェストコマンドは、以下の形式をと
ります。
openssl dgst algorithm -out filename -sign private-key
ここでの algorithm は、md5|md4|md2|sha1|sha|mdc2|ripemd160|dss1 のいずれかになりま

す。本ガイド作成時点では、SHA1 アルゴリズムが推奨されます。DSA を使用した署名もしくは検証が必
要な場合は、-rand オプションで指定したランダムなデータを含むファイルを一緒に dss1 オプションを
使用する必要があります。
s ha1 アルゴリズムを使用してデフォルトの He x 形式でメッセージダイジェストを作成するには、以下の

~]$ openssl dgst sha1 -out digest-file
秘密鍵 privekey.pem を使用してダイジェストにデジタル署名するには、以下のコマンドを実行します。
~]$ openssl dgst sha1 -out digest-file -sign privkey.pem
詳細情報は、dgst(1) man ページを参照してください。
4.8.6. パスワードハッシュの生成
passwd コマンドは、パスワードのハッシュを計算します。コマンドラインでパスワードのハッシュを計
算するには、以下のコマンドを実行します。
~]$ openssl passwd password
デフォルトでは、-crypt アルゴリズムが使用されます。
109
BSD アルゴリズム 1 に基づく MD5 を使用して、標準入力からパスワードのハッシュを計算するには、以

~]$ openssl passwd -1 password
-apr1 オプションが BSD アルゴリズムの Apache バリアントを指定します。
s alt xx を使用してファイルに保存されているパスワードのハッシュを計算するには、以下のコマンドを実
行します。
~]$ openssl passwd -salt xx -in password-file
パスワードは標準出力に送信され、出力ファイルを指定する -out オプションはありません。-table

は、パスワードハッシュの表とそれに対応するクリアテキストのパスワードを生成します。
詳細およびその他の例については、sslpasswd(1) の man ページを参照してください。
4.8.7. ランダムデータの生成
シードファイルを使用してランダムなデータを含むファイルを生成するには、以下のコマンドを実行しま
す。
~]$ openssl rand -out rand-file -rand seed-file
ランダムデータプロセスをシードするための複数ファイルは、コロン : 区切りのリストを使用して指定で
きます。
詳細情報は、rand(1) man ページを参照してください。
4.8.8. システムのベンチマーキング
あるアルゴリズムにおけるシステムの演算速度をテストするには、以下のコマンドを実行します。
~]$ openssl speed algorithm
ここでの algorithm は、使用する予定の対応アルゴリズムのいずれかになります。利用可能なアルゴリズ

ムを一覧表示するには、openssl speed と入力してタブを押します。
4.8.9. OpenSSL の設定
Ope nSSL にはマスター設定ファイルと呼ばれる設定ファイル /etc/pki/tls/openssl.cnf があ

り、Ope nSSL ライブラリーがこれを読み込みます。各アプリケーション用の個別の設定ファイルを用い
ることもできます。設定ファイルには、[ section_name ] のようにセクション名が付いた多くのセク
ションが含まれています。最初の [ section_name ] までの部分は、デフォルトセクションと呼ばれる
ことに注意してください。Ope nSSL が設定ファイル内で名前を検索する際には、最初に名前の付いたセク
ションが検索されます。別の設定ファイルがコマンド内のオプションで指定されていなければ、Ope nSSL
コマンドはすべて、マスター Ope nSSL 設定ファイルを使用します。設定ファイルの詳細
は、config(5) man ページで説明されています。
以下の 2 つの RFC は、証明書ファイルのコンテンツについて説明しています。
『Inte rne t X.509 Public Ke y Infras tructure Ce rtificate and Ce rtificate Re vocation Lis t
(CRL) Profile 』
110
『Update s to the Inte rne t X.509 Public Ke y Infras tructure Ce rtificate and Ce rtificate
Re vocation Lis t (CRL) Profile 』
4.9. st unnel の使用
st unnel プログラムは、クライアントとサーバー間の暗号化ラッパーです。設定ファイルで指定された
ポートをリッスンし、クライアントとの通信を暗号化し、通常のポートでリッスンしているオリジナルの
デーモンにデータを転送します。こうすることで、それ自体で暗号化をサポートしていないサービスをセ
キュアにすることができます。また、SSL バージョン 2 や 3 など、POODLE SSL 脆弱性 (CVE-2014-
3566) の影響を受け、安全上の理由から使用を避けたい暗号化サービスのセキュリティを改善することも
できます。詳細は、https ://acce s s .re dhat.com/s olutions /1234773 を参照してください。CUPS
は、自身の設定で SSL を無効にする方法がないコンポーネントの例です。
4.9.1. st unnel のインストール
stunnel パッケージをインストールするには、root で以下のコマンドを実行します。
~]# yum install stunnel
4.9.2. st unnel を T LS ラッパーとして設定する
st unnel の設定は、以下の手順にしたがいます。
1. st unnel とどのサービスを使うにしても、有効な証明書が必要になります。適切な証明書がない
場合は、認証機関に申し込むか、自己署名の証明書を自身で作成することもできます。
警告
実稼働環境で稼働しているサーバーには、常に認証機関で署名された証明書を使用してくだ
さい。自己署名証明書は、テスト目的またはプライベートネットワークのみで使用すること
をお勧めします
認証局が提供する証明書についての詳細情報は、「証明書署名要求の作成」を参照してくださ
い。st unnel 用に自己署名証明書を作成するには、root で /etc/pki/tls/certs/ ディレ
クトリーに移動し、以下のコマンドを実行します。
certs]# make stunnel.pem
すべての質問に回答して、プロセスを完了します。
2. 証明書ができたら、st unnel 用の設定ファイルを作成します。これはテキストファイルで、各行

でオプションまたはサービス定義の開始を指定します。また、コメントや空の行使って、読みやす
くすることもできます。コメントはセミコロンで開始します。
stunnel RPM パッケージには /etc/stunnel/ ディレクトリーが含まれ、設定ファイルはここ

で保存します。st unnel ではファイル名で特定の形式や拡張子は必要ありません
が、/etc/stunnel/stunnel.conf としてください。以下のコンテンツでは、st unnel を
TLS ラッパーとして設定します。
cert = /etc/pki/tls/certs/stunnel.pem
; Allow only TLS, thus avoiding SSL
sslVersion = TLSv1
111
chroot = /var/run/stunnel
setuid = nobody
setgid = nobody
pid = /stunnel.pid
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
[service_name]
accept = port
connect = port
TIMEOUTclose = 0
別の方法では、sslVersion = TLSv1 の行を以下の行で置き換えると SSL を避けられます。
options = NO_SSLv2
options = NO_SSLv3
オプションの目的は、以下のとおりです。
cert — 証明書へのパスです。
sslVersion — SSL のバージョンです。SSL と TLS は別個の暗号化プロトコルですが、こ

こでは TLS が使えることに注意してください。
chroot — 変更後の root ディレクトリーです。ここでは、s tunne l プロセスがより安全に実

行できます。
setuid, setgid — st unnel プロセスを実行するユーザーおよびグループ。nobody は制限

されたシステムアカウントになります。
pid — st unnel がプロセス ID を保存するファイルで、chroot に相対的になります。
socket — ローカルおよびリモートのソケットオプション。このケースでは、ネーグルのアル
ゴリズムを無効にして、ネットワーク遅延を改善します。
[service_name] — サービ定義の開始点。この下に続く行で使用されるオプションは、該当
サービスのみに適用されます。この上にあるオプションは、 st unnel でグローバルに適用さ
れます。
accept — リッスンするポートです。
connect — 接続先のポートです。このポートは、セキュアにしているサービスが使用するも
のである必要があります。
TIMEOUTclose — クライアントから close_notify 警告が出されるまでの待ち時間です。こ

れが 0 の場合は、st unnel はまったく待機しません。
options — Ope nSSL ライブラリーのオプション。
例4.2 CUPS のセキュア化
CUPS 用に s tunne l を TLS ラッパーとして設定するには、以下の値を使用します。
[cups]
accept = 632
connect = 631
112
632 の代わりに使用されていないポートを使うこともできます。631 は CUPS が通常使用す

るポートです。
3. chroot ディレクトリーを作成し、setuid オプションで指定されているユーザーにこのディレク

トリーへの書き込みアクセスを与えます。これを行うには、root で以下のコマンドを実行しま
す。
~]# mkdir /var/run/stunnel

~]# chown nobody:nobody /var/run/stunnel
これで、st unnel が PID ファイルを作成できるようになります。
4. 使用中のシステムでファイアウォールが新たなポートへのアクセスを許可しない設定となっている
場合は、この設定を許可するように変更します。詳細は、「ファイアウォールでポートを開く」を
参照してください。
5. 設定ファイルと chroot ディレクトリーを作成し、指定されたポートがアクセス可能なことを確

認したら、st unnel を開始することができます。
4.9.3. st unnel の起動、停止、再起動
st unnel を起動するには、root で以下のコマンドを実行します。
~]# stunnel /etc/stunnel/stunnel.conf
デフォルトでは、st unnel は出力のログに /var/log/secure を使用します。
st unnel を停止するには、root で以下のコマンドを実行してプロセスを強制終了させます。
~]# kill `cat /var/run/stunnel/stunnel.pid`
st unnel の実行中に設定ファイルを編集した場合は、st unnel を停止して再起動すると、変更が反映さ

れます。
4.10. 暗号化
4.10.1. LUKS のディスク暗号化の使用
Linux Unifie d Ke y Se tup-on-dis k-format (または LUKS) を使うと、Linux コンピューター上のパー

ティションを暗号化できます。これは特に、モバイルコンピューターやリムーバブルメディアを使う際に
重要です。LUKS を使うと、複数のユーザーキーを使って、パーティションのバルク暗号化に使用されるマ
スターキーの暗号化解除ができるようになります。
LUKS の概要
LUKS の機能
LUKS はブロックデバイス全体を暗号化するため、脱着可能なストレージメディアやノート
PC のディスクドライブといった、モバイルデバイスのコンテンツ保護に適しています。
暗号化されたブロックデバイスにあるのは任意のコンテンツです。これは、スワップデバイ
スの暗号化に役立ちます。また、とりわけデータストレージ用にフォーマットしたブロック
デバイスを使用する特定のデータベースに関しても有用です。
113
LUKS は既存のデバイスマッパーカーネルサブシステムを使用します。
LUKS はパラフレーズの強化を提供し、辞書攻撃から保護します。
LUKS デバイスには複数のキースロットが含まれ、ユーザーはこれを使ってバックアップ
キーやパスフレーズを追加できます。
LUKS でできないこと:
LUKS は、多くのユーザー (9 人以上) が同一デバイスに対して別々のアクセスを持つことが

必要となるアプリケーションには適していません。
LUKS は、ファイルレベルの暗号化を必要とするアプリケーションには適していません。
4.10.1.1. Red Hat Ent erprise Linux における LUKS の実装
Re d Hat Ente rpris e Linux 7 は、LUKS を使ってファイルシステムを暗号化します。デフォルトではイ

ンストール時に、ファイルシステムを暗号化するオプションのチェックが外されています。ハードディス
クを暗号化するオプションを選択すると、コンピューターを起動するたびにパスフレーズを尋ねられます。
このパスフレーズは、パーティションの暗号化解読に用いられるバルク暗号化鍵を「ロック解除」します。
デフォルトのパーティションテーブルの変更を選択すると、暗号化するパーティションを選択できます。
この設定は、パーティションテーブル設定で行われます。
LUKS に使用されるデフォルトの暗号 (cryptsetup --help を参照) は ae s -cbc-e s s iv:s ha256

(ESSIV - Encrypte d Salt-Se ctor Initializ ation Ve ctor) です。インストールプログラムの
Anaco nda は、デフォルトでは XTS モード (ae s -xts -plain64) を使用することに注意してください。
LUKS のデフォルトの鍵のサイズは 256 ビットです。Anaco nda (XTS モード) と併用する場合の
LUKS のデフォルトの鍵のサイズは 512 ビットです。利用可能な暗号は以下の通りです。
AES - Advance d Encryption Standard (高度暗号化標準) - FIPS PUB 197
Twofis h (128 ビットブロック暗号)
Se rpe nt
cas t5 - RFC 2144
cas t6 - RFC 2612
4.10.1.2. 手動でのディレクトリーの暗号化
警告
以下の手順を実行すると、暗号化しているパーティションの既存データがすべて削除されます。す
べての情報が失われてしまうので、この手順を開始する前に、外部ソースへのデータのバックアッ
プを必ず行なってください。
1. root としてシェルプロンプトに以下を入力し、ランレベル 1 に入ります。
telinit 1
2. 既存の /home のマウントを解除します。
umount /home
114
3. 直前の手順のコマンドが失敗した場合は、fuser を使用し、/home を独占しているプロセスを見

つけてこれらを止めます。
fuser -mvk /home
4. /home がもはやマウントされていないことを確認します。
grep home /proc/mounts
5. パーティションをランダムなデータで埋めます。
shred -v --iterations=1 /dev/VG00/LV_home
このコマンドは、デバイスの連続書き込み速度で実行され、完了までに時間がかかる場合がありま
す。使用デバイスに暗号化されていないデータが残っていないことを確認した上で、デバイスの暗
号化されたデータを含む部分を難読化するのは重要なステップです。
6. パーティションを初期化します。
cryptsetup --verbose --verify-passphrase luksFormat

/dev/VG00/LV_home
7. 新たに暗号化したデバイスを開きます。
cryptsetup luksOpen /dev/VG00/LV_home home
8. デバイスがあることを確認します。
ls -l /dev/mapper | grep home
9. ファイルシステムを作成します。
mkfs.ext3 /dev/mapper/home
10. ファイルシステムをマウントします。
mount /dev/mapper/home /home
11. ファイルシステムが表示されていることを確認します。
df -h | grep home
12. 以下を /etc/crypttab ファイルに追加します。
home /dev/VG00/LV_home none
13. /etc/fstab ファイルを編集して、/home の古いエントリを削除し、以下の行を追加します。
/dev/mapper/home /home ext3 defaults 1 2
14. デフォルトの SELinux セキュリティコンテンツを復元します。
115
/sbin/restorecon -v -R /home
15. マシンを再起動します。
shutdown -r now
16. /etc/crypttab にあるエントリにより、コンピューターのブート時に luks パスフレーズが尋

ねられます。
17. root としてログインし、バックアップを復元します。
これですべてのデータ用に暗号化されたパーティションを設定できたので、コンピューターをオフにしてい
る間もデータを安全に保管できます。
4.10.1.3. 既存デバイスへの新規パスフレーズの追加
既存デバイスに新規パスフレーズを追加するには、以下のコマンドを使用します。
cryptsetup luksAddKey device
認証のために既存のパスフレーズが尋ねられた後に、新規パスフレーズの入力を求めるプロンプトが出され
ます。
4.10.1.4. 既存のデバイスからのパスフレーズ削除
既存のデバイスからパスフレーズを削除するには、以下のコマンドを使用します。
cryptsetup luksRemoveKey device
削除したいパスフレーズを求めるプロンプトの後に、認証に必要な残りのパスフレーズを求めるプロンプト
が出されます。
4.10.1.5. Anaconda での暗号化したブロックデバイスの作成
システムのインストール時に、暗号化されたデバイスを作成することができます。これにより、暗号化
パーティションを含むシステムを簡単に設定することができます。
ブロックデバイスの暗号化を有効にするには、自動パーティション設定を選択している場合はシステムの
暗号化チェックボックスに、個別パーティション、ソフトウェア RAID アレイまたは論理ボリュームを
作成している場合は暗号化チェックボックスにチェックを入れます。パーティション設定が終了した
ら、暗号化のパスフレーズが尋ねられます。このパスフレーズは暗号化したデバイスへのアクセスに必要と
なります。LUKS デバイスが事前に存在しており、インストールプロセスの当初にそれらの正しいパスフ
レーズを指定している場合には、チェックボックスのあるパスフレーズ入力ダイアログが表示されます。こ
のチェックボックスにチェックを入れると、既存の暗号化ブロックデバイスの利用可能なスロットに新規
パスフレーズを追加することになります。
注記
自動パーティション設定画面のシステムの暗号化チェックボックスにチェックを入れた後に

カスタムレイアウトの作成を選択しても、ブロックデバイスは自動的に暗号化されません。
116
注記
kickstart を使用すると、新たに暗号化されたブロックデバイスのパスフレーズを個別に設定す
ることができます。
Re d Hat Ente rpris e Linux 7 における LUKS や暗号化ハードディスクについての詳細は、以下のリンク

にアクセスしてください。
LUKS home page
LUKS/crypts e tup FAQ
LUKS - Linux Unifie d Ke y Se tup Wikipe dia article
HOWTO: Cre ating an e ncrypte d Phys ical Volume (PV) us ing a s e cond hard drive and
pvmove
4.10.2. GPG 鍵の作成
GnuPG (GPG) は、ユーザーを識別し、通信 (確認できない人々との通信も含む) を認証するために使われ

ます。GPG は、GPG 署名のある電子メールを読む人がその真正性を検証できるようにします。つまり、
GPG は、あなたが署名した通信が実際にあなたからのものであることをかなりの精度で確認できるように
します。GPG は、第三者がコードを変更したり、会話を傍受したり、メッセージを改ざんしたりすること
を防ぐ点で役に立ちます。
4.10.2.1. GNOME での GPG 鍵の生成
GNOME で GPG 鍵を作成するには、以下の手順にしたがいます。
1. Seaho rse ユーティリティーをインストールします。これにより GPG 鍵の管理が容易になりま

す。
~]# yum install seahorse
2. 鍵を作成するには、アプリケーション → アクセサリメニューから、パスワードと暗号鍵を選択し
ます。これでアプリケーション Seaho rse が起動します。
3. ファイルメニューから新規を選択し、PGP 鍵を選択した後に続行をクリックします。
4. 氏名、電子メールアドレスおよび自身についての説明のオプションのコメント (例: John C. Smith,

jsmith@example.com, Software Engine e r) を入力します。生成をクリックします。鍵のパ
スフレーズを問い合わせるダイアログが表示されます。パスフレーズは強固なだけでなく覚えやす
いものを選択してください。OK をクリックすると鍵が作成されます。
警告
パスフレーズを忘れると、データの暗号解除ができなくなります。
117
GPG 鍵の ID を見つけるには、新規に作成された鍵の横にある鍵の ID コラムを確認します。多くの場

合、鍵の ID を求められたら、0x6789ABCD などのように鍵の ID の前に 0x を付けます。秘密鍵のバッ
クアップを取り、安全な場所に保管してください。
4.10.2.2. KDE での GPG 鍵の作成
KDE で GPG 鍵を作成するには、以下の手順にしたがいます。
1. メインメニューからアプリケーション → ユーティリティ → 暗号ツールを選択して KGpg プログ

ラムを起動します。これまで KGpg を使用したことがなければ、プログラムが独自の GPG 鍵ペ
アを生成するプロセスを詳しく説明します。
2. ダイアログボックスで、新しい鍵ペアを生成するよう求められます。名前、電子メールアドレス、
およびオプションのコメントを入力します。鍵の長さ (ビット数) とアルゴリズムに加え、鍵の有効
期限も選択できます。
3. 次のダイアログでパスフレーズを入力します。この時点で、鍵が KGpg のメインウィンドウに表

示されます。
警告
パスフレーズを忘れると、データの暗号解除ができなくなります。
GPG 鍵の ID を見つけるには、新規に作成された鍵の横にある鍵の ID コラムを確認します。多くの場

合、鍵の ID を求められたら、0x6789ABCD などのように鍵の ID の前に 0x を付けます。秘密鍵のバッ
クアップを取り、安全な場所に保管してください。
4.10.2.3. コマンドラインを用いた GPG 鍵の生成
1. 次のシェルコマンドを使用します。
~]$ gpg2 --gen-key
このコマンドは、公開鍵と秘密鍵で構成される鍵ペアを生成します。受信側では、ユーザーからの
通信の認証や暗号化解除を行うためにこのユーザーの公開鍵を使用します。そのため、とりわけ
メーリングリストのように、送信者からの認証済みの通信を受け取ることを希望すると思われる
人々に向けて、できる限り幅広く公開鍵を配布してください。
2. 一連のプロンプトにしたがってプロセスを進めます。デフォルト値を割り当てる場合は Enter
キーを押します。最初のプロンプトは、使用を希望する鍵の種類を選択するよう尋ねます。
Please select what kind of key you want:

(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection?
ほとんど多くの場合、デフォルトが適切な選択になります。RSA/RSA 鍵を選択すると、通信に署
名するだけでなく、ファイルを暗号化することができます。
3. 鍵のサイズを選択します。
118
RSA keys may be between 1024 and 4096 bits long.

What keysize do you want? (2048)
ここでも、デフォルトの 2048 はほとんどすべてのユーザーに適しており、これは極めて強いレベ

ルのセキュリティになります。
4. 鍵の有効期限を選択します。デフォルトの none を使用するのではなく、失効日を選択する方がよ

いでしょう。例えば、鍵にある電子メールアドレスが無効になると、失効日が設定されているため
に、他の人々はその公開鍵を使用するのを止めるように通知されます。
Please specify how long the key should be valid.

0 = key does not expire
d = key expires in n days
w = key expires in n weeks
m = key expires in n months
y = key expires in n years
key is valid for? (0)
例えば、1y の値を入力すると、鍵の有効期間は 1 年間になります (鍵の生成後にこの失効日を変

更することができます)。
5. gpg2 プログラムが署名情報を尋ねる前に、以下のプロンプトが表示されます。
Is this correct (y/N)?
y を入力してプロセスを終了します。
6. GPG 鍵用に氏名と電子メールアドレスを入力します。このプロセスは、ユーザーを個人として認証
するためのものです。このため、本当の名前を入力してください。偽の電子メールアドレスを選択
すると、他の人があなたの公開鍵を見つけにくくなります。これにより、通信の認証が困難になり
ます。例えば、メーリングリストの自己紹介にこの GPG 鍵を使用する場合、そのリストで使用し
ている電子メールアドレスを入力します。
コメントフィールドには、エイリアスやその他の情報を記載します。(一部の人は、目的別に複数の
鍵を使用しており、「オフィス」または「オープンソースプロジェクト」などのコメントを付けて
それぞれの鍵を識別しています。）
7. すべてのエントリーが正しければ、確認プロンプトで O と入力して続行するか、または問題がある
場合はそれを修正するために他のオプションを使用します。最後に、秘密鍵のパスフレーズを入力
します。gpg2 プログラムは、入力エラーがないことを確認するためにパスフレーズを 2 回入力す
るように指示します。
8. 最後に、gpg2 はランダムなデータを生成して鍵を可能な限り一意なものにします。このプロセス
をスピードアップするには、この手順の実行中にマウスを動かし、ランダムなキーを入力するか、
またはシステム上で他のタスクを実行します。この手順が完了すると、鍵が完成して使用可能な状
態になります。
pub 1024D/1B2AFA1C 2005-03-31 John Q. Doe <jqdoe@example.com>

Key fingerprint = 117C FE83 22EA B843 3E86 6486 4320 545E 1B2A
FA1C
sub 1024g/CEA4B22E 2005-03-31 [expires: 2006-03-31]
9. 鍵のフィンガープリントは、あなたの鍵の「署名」の短縮版です。これを使って、他の人々があな
たの実際の公開鍵を (改ざんされない状態で) 受け取ったことを確認することができます。このフィ
ンガープリントを書き留めておく必要はありません。フィンガープリントを表示するには、以下の
コマンドをあなたの電子メールアドレスに置き換えて使用します。
119
~]$ gpg2 --fingerprint jqdoe@example.com
「GPG 鍵の ID」は、公開鍵を識別する 16 進法の 8 文字で構成されます。上記の例では、GPG

鍵 ID は 1B2AFA1C です。多くの場合、鍵 ID を求められる際には、0x6789ABCD などのよう
に、鍵 ID の前に 0x を付けます。
警告
パスフレーズを忘れると、鍵を使うことができなくなり、その鍵で暗号化されたすべてのデータが失
われます。
4.10.2.4. 公開鍵の暗号化について
1. Wikipe dia - Public Ke y Cryptography
2. HowStuffWorks - Encryption
4.10.3. 公開鍵暗号化における openCrypt oki の使用
o penCrypt o ki は PKCS#11 の Linux 実装で、トークンと呼ばれる暗号化デバイスへのアプリケー

ションプログラミングインターフェイス (API) を定義する公開鍵暗号標準です。トークンは、ハードウェ
アまたはソフトウェアに実装することが可能です。本章では、Re d Hat Ente rpris e Linux 7 での
o penCrypt o ki システムのインストール、設定および使用についての概要を説明します。
4.10.3.1. openCrypt oki のインストールとサービスの起動
テスト目的のトークンのソフトウェア実装を含む、基本の o penCrypt o ki パッケージをシステムにイン

ストールするには、root で以下のコマンドを実行します。
~]# yum install opencryptoki
使用するハードウェアトークンのタイプによっては、特別なユースケース用のサポートを提供する追加パッ
ケージのインストールが必要になる場合もあります。たとえば、Trusted Platform Module (TPM) デバイ
ス用のサポートを入手するには、opencryptoki-tpmtok パッケージをインストールする必要があります。
Yum パッケージマネジャーを使用してパッケージをインストールする情報全般に関しては、Re d Hat

Ente rpris e Linux 7 システム管理者のガイドのパッケージのインストールセクションを参照してくださ
い。
o penCrypt o ki サービスを有効にするには、pkcsslotd デーモンを実行する必要があります。root

で以下のコマンドを実行すると、現行セッションでこのデーモンが起動します。
~]# systemctl start pkcsslotd
ブート時にサービスが自動的に起動するには、以下のコマンドを実行します。
~]# systemctl enable pkcsslotd
s ys te md ターゲットを使用したサービスの管理方法に関する詳細情報は、Re d Hat Ente rpris e Linux 7

システム管理者のガイドの s ys te md によるサービス管理の章を参照してください。
120
4.10.3.2. openCrypt oki の設定と使用
pkcsslotd デーモンは起動後に /etc/opencryptoki/opencryptoki.conf 設定ファイルを読み込

みます。このファイルは、システムと機能するように設定されたトークンとそのスロットについての情報を
収集するために使用されます。
このファイルは、鍵と値のペアを使用して個別スロットを定義します。各スロットの定義には、説明、使用
するトークンライブラリーの仕様、およびスロットの製造者の ID が含まれます。オプションでは、スロッ
トのハードウェアおよびファームウェアのバージョンを定義することもできます。ファイル形式の説明、
個別の鍵およびその鍵に割り当てられる値の詳細な説明は、ope ncryptoki.conf(5) man ページを参照し
てください。
ランタイム時の pkcsslotd デーモンの動作を修正するには、pkcsconf ユーティリティーを使用しま

す。このツールを使うと、デーモンの状態の表示と設定に加え、現在設定されているスロットとトークンの
一覧表示と修正がでいます。たとえば、トークンについての情報を表示するには、以下のコマンドを実行し
ます。(pkcsslotd デーモンと通信する必要のある root 以外のユーザーは、pkcs11 システムグループ
に属している必要があることに注意してください)
~]$ pkcsconf -t
pkcsconf で利用可能な引数の一覧については、pkcs conf(1) man ページを参照してください。
警告
pkcs11 グループには、完全に信頼できるユーザーのみを割り当ててください。このグループのメ
ンバーは、o penCrypt o ki サービスの他のユーザーが設定済み PKCS#11 トークンへアクセスで
きなくすることができます。またこのグループのメンバーは、o penCrypt o ki の他のユーザーの
権限で任意のコードを実行することができます。
4.10.4. 信頼できる鍵および暗号化された鍵
信頼できる鍵および暗号化された鍵は、カーネルキーリングサービスを使用するカーネルが生成する可変
長のシンメトリックキーです。この鍵はユーザースペースでは暗号解除された形式で表示されないので、そ
の整合性が検証可能になります。このため、たとえば拡張検証モジュール (EVM) がこの鍵を使用して稼働
中のシステムの整合性を検証かつ確認することができるようになります。ユーザーレベルのプログラムがア
クセス可能なのは、暗号化されたブロブの形式での鍵のみです。
信頼できる鍵は、Trusted Platform Module (TPM) チップというハードウェアが必要になります。これ

は、鍵の作成と暗号化 (保護) の両方に使用されます。TPM は、storage root key (SRK) と呼ばれる
2048 ビットの RSA 鍵を使ってこの鍵を保護します。
さらに、信頼できる鍵は TPM のプラットホーム構成レジスター (PCR) の特定の値のセットを使って保護

される場合があります。PCR には、BIOS を反映する整合性管理の値、ブートローダー、およびオペレー
ティングシステムのセットが含まれています。つまり、PCR で保護された鍵は、これが暗号化された全く
同一システム上の TPM でしか暗号解除できないことになります。ただし、PCR で保護された信頼できる鍵
が読み込まれると (キーリングに追加されると)、すなわちそれに関連付けられている PCR の値が確認され
ると、新たな (または将来の) PCR の値で更新可能となります。このため、たとえば、新規カーネルのブー
トが可能になります。また、ひとつの鍵は異なる PCR の値を持つ複数のブロブとして保存することもでき
ます。
暗号化された鍵は、カーネル AES 暗号化を使用するので、TPM を必要とせず、信頼できる鍵よりもスピー

ディーになります。暗号化された鍵は、カーネル生成の任意の数を使って作成され、ユーザースペースブロ
ブにエクスポートされる際にマスターキーで暗号化されます。このマスターキーは、信頼できる鍵かユー
ザーキーとすることができます。後者の場合、暗号化された鍵の安全性は、ユーザーキーによる暗号化と同
121
等のものでしかないという欠点があります。
4.10.4.1. 鍵を使った作業
鍵を使う操作の前には、関連するカーネルモジュールの読み込みが必要になります。信頼できる鍵の場合は
t rust ed モジュール、暗号化された鍵の場合は encrypt ed-keys モジュールです。root ユーザーで
以下のコマンドを実行して、これらモジュールの両方を同時に読み込みます。
~]# modprobe trusted encrypted-keys
keyct l ユーティリティーを使って信頼できる鍵と暗号化された鍵の作成、読み込み、エクスポート、更新
ができます。keyct l の使用に関する詳細情報は、ke yctl(1) を参照してください。
注記
TPM を使用するには (信頼できる鍵の作成および保護目的など)、これを有効かつアクティブにする

必要があります。これは通常、マシンの BIOS で設定するか、ユーティリティーの tpm-tools パッ
ケージから tpm_setactive コマンドを使用するとできます。また、T ro uSers アプリケーショ
ン (trousers パッケージ) のインストールと、T ro uSers スイートの一部である tcsd デーモン
が稼働して TPM と通信している必要もあります。
TPM を使用して信頼できる鍵を作成するには、以下の構文で keyctl コマンドを実行します。
keyctl add trusted name "new keylength [options]" keyring
上記の構文を使用したコマンド例は以下のようになります。
~]$ keyctl add trusted kmk "new 32" @u

642500861
上記の例では、kmk と呼ばれる 32 バイト (256 ビット) の長さの信頼できる鍵が作成され、ユーザーキー

リング (@u) に置かれます。この鍵は、32 から 128 バイト (256 から 1024 ビット) の長さになりま
す。show サブコマンドを使ってカーネルキーリングの現在の構成を一覧表示します。
~]$ keyctl show

Session Keyring
-3 --alswrv 500 500 keyring: _ses
97833714 --alswrv 500 -1 \_ keyring: _uid.1000
642500861 --alswrv 500 500 \_ trusted: kmk
print サブコマンドは、暗号化された鍵を標準出力に出します。この鍵をユーザースペースのブロブにエ
クスポートするには、以下のように pipe サブコマンドを使用します。
~]$ keyctl pipe 642500861 > kmk.blob
信頼できる鍵をユーザースペースのブロブから読み込むには、add コマンドでブロブを引数として使用しま
す。
~]$ keyctl add trusted kmk "load `cat kmk.blob`" @u

268728824
122
これで TPM で保護された信頼できる鍵を用いて安全な暗号化された鍵を作成することができます。暗号化

された鍵の生成には、以下のコマンド構文が使用されます。
~]$ keyctl add encrypted name "new [format] key-type:master-key-name

keylength" keyring
上記の構文に基づき、既存の信頼できる鍵を使って暗号化された鍵を生成するコマンドは以下のようになり
ます。
~]$ keyctl add encrypted encr-key "new trusted:kmk 32" @u

159771175
TPM が利用できないシステムで暗号化された鍵を作成するには、任意の数の列を使ってユーザーキーを生
成し、それを使って実際の暗号化された鍵を保護します。
~]$ keyctl add user kmk-user "`dd if=/dev/urandom bs=1 count=32

2>/dev/null`" @u
427069434
その後に、任意の数のユーザーキーを使って暗号化された鍵を生成します。
~]$ keyctl add encrypted encr-key "new user:kmk-user 32" @u

1012412758
list サブコマンドを使うと、指定されたカーネルキーリング内のすべての鍵を一覧表示できます。
~]$ keyctl list @u

2 keys in keyring:
427069434: --alswrv 1000 1000 user: kmk-user
1012412758: --alswrv 1000 1000 encrypted: encr-key
重要
マスターの信頼できる鍵で保護されていない暗号化された鍵の安全性は、その鍵の暗号化に使用され
たユーザーマスターキー (任意の数の鍵) と同等にしかならないことに注意してください。このた
め、マスターユーザーキーはできるだけ安全に、可能であればブートプロセスの初期に、読み込むよ
うにしてください。
以下のオフラインおよびオンラインのリソースでは、信頼できる鍵および暗号化された鍵に関する追加情報
が提供されています。
ke yctl(1) — keyct l ユーティリティーおよびそのサブコマンドについての使用方法を説明していま

す。
123
Ente rpris e Linux 7 の『SELinux Us e r's and Adminis trator's Guide 』では、SELinux の原則
と、SELinux を設定して Apache HT T P Server などのさまざまなサービスで使用する方法が詳
細に説明されています。
https ://www.ke rne l.org/doc/Docume ntation/s e curity/ke ys -trus te d-e ncrypte d.txt — Linux
カーネルの信頼できる鍵および暗号化された鍵に関する機能についての公式ドキュメントです。
関連項目
「高度暗号化標準 — AES」では、Advanced Encryption Standard (高度暗号化標準) について

簡単に説明しています。
「公開鍵暗号」では、公開鍵の暗号化のアプローチとそこで使用される様々な暗号化プロトコルについ
て説明しています。
4.11. T LS 設定の強化
TLS (トランスポート層セキュリティ ) は、ネットワーク通信をセキュアにするために使用する暗号化プ

ロトコルです。優先する鍵交換プロトコル、認証方法、および暗号化アルゴリズムを設定することでシステ
ムのセキュリティ設定を強化する際には、サポートするクライアントの範囲が広ければ広いほど、セキュリ
ティのレベルが低くなることを認識しておく必要があります。反対に、セキュリティ設定を厳密にすると、
クライアントとの互換性が制限され、システムからロックアウトされるユーザーが出てくる可能性もありま
す。可能な限り厳密な設定を目指し、互換性のために必要な場合にのみ、これを緩めるようにしてくださ
い。
Re d Hat Ente rpris e Linux 7 に含まれるライブラリーが提供するデフォルト設定は、ほとんどの導入に

おいて十分に安全なものです。TLS 実装は、可能な場合はセキュアなアルゴリズムを使用する一方で、レ
ガシークライアントまたはサーバーとの接続を妨げません。セキュアなアルゴリズムやプロトコルをサポー
トしていないレガシーのクライアントやサーバーの接続が期待できない場合やそれらの接続が許可されない
場合に、厳密なセキュリティ要件の環境で本セクションで説明されている強化設定を適用してください。
4.11.1. 有効にするアルゴリズムの選択
選択して設定する必要があるコンポーネントがいくつかあります。以下で説明するものはすべて、その設定
結果 (つまり、クライアントにおけるサポートレベル) やシステム上でソリューションが持つコンピュー
ターのデマンドに直接影響します。
プロトコルのバージョン
最新バージョンの TLS は、すぐれたセキュリティメカニズムを提供します。古いバージョンの TLS (さら

に SSL) のサポートを含める切実な理由がなければ、最新バージョンの TLS のみを使ってシステムが接続
するようにしてください。
SSL のバージョン 2 または 3 を使った処理を許可しないでください。これらのバージョンには、セキュリ

ティに関する重大な脆弱性があります。TLS のバージョン 1.0 以上を使った処理のみを許可してくださ
い。現行の TLS バージョン 1.2 を常に優先するようにしてください。
124
注記
TLS の全バージョンのセキュリティは現在、TLS 拡張機能、特定の暗号 (下記参照)、および他の回

避策に依存していることに注意してください。TLS の接続ピアはすべてセキュアな再交渉記号
(RFC 5746) を実装する必要があり、圧縮をサポートしていない必要があります。また、CBC モー
ドの暗号 (Lucky Thirte e n 攻撃) に対するタイミング攻撃を緩和する方法を実装する必要がありま
す。TLS v1.0 クライアントはさらに、レコード分割 (BEAST 攻撃に対する回避策) を実装する必
要があります。TLS v1.2 は、AES-GCM、AES-CCM、または Camellia-GCM といった既知の問
題のない認証付き暗号 (Authe nticate d Encryption with As s ociate d Data : AEAD) モードの
暗号をサポートしています。ここに記載された緩和策はすべて、Re d Hat Ente rpris e Linux に含
まれる暗号ライブラリーに実装されています。
プロトコルのバージョンおよび推奨される使用方法についての概要は、表4.6「プロトコルのバージョン」
を参照してください。
表4.6 プロトコルのバージョン
プロトコルの推奨される使用方法
バージョン
SSL v2 使用しないでください。重大なセキュリティ上の脆弱性があります。
SSL v3 使用しないでください。重大なセキュリティ上の脆弱性があります。
TLS v1.0 必要な場合は、相互運用性目的で使用します。相互運用性を保証する方法では緩和でき
ない既知の問題があります。このため、緩和策はデフォルトでは有効になっていませ
ん。最新の暗号化スイートには対応していません。
TLS v1.1 必要な場合は、相互運用性目的で使用します。既知の問題はありませんが、Re d Hat
Ente rpris e Linux の TLS 実装すべてに含まれるプロトコル修正に依存します。最新
の暗号化スイートには対応していません。
TLS v1.2 推奨されるバージョンです。最新の AEAD 暗号化スイートに対応しています。
Re d Hat Ente rpris e Linux のコンポーネントのなかには、TLS v1.1 や v1.2 に対応しているのに

TLS v1.0 を使用する設定になっているものもあります。これは、最新バージョンのTLS に対応していな
い可能性のある外部サービスとの最高レベルの相互運用性を達成する目的でこのようになっています。相互
運用性の要件に対応して、利用可能な最高レベルの TLS バージョンを有効にしてください。
重要
SSL v3 の使用は推奨されません。これは安全ではなく一般の使用には適していませんが、 SSL v3

をどうしても有効にする必要がある場合は、「s tunne l の使用」を参照してください。暗号化に対
応していない、または旧式で安全でない暗号化モードの使用しかできないサービスを使用する場合で
も、st unnel を使用して安全に通信を暗号化する方法が説明されています。
暗号化スイート
旧式の安全でない暗号化スイートではなく、最近のより安全なものを使ってください。e NULL および

aNULL 暗号化スイートは暗号化や認証をまったく提供しないので、常に無効にしてください。RC4 や
HMAC-MD5 をベースとした暗号化スイートには重大な欠陥があるので、可能な場合はこれらも無効にして
ください。いわゆるエクスポート暗号化スイートも同様にしてください。これらは意図的に弱くなってい
るので、侵入が容易になっています。
128 ビット未満のセキュリティしか提供しない暗号化スイートは直ちに不安というわけではありません
が、これらは短期間の使用に考慮すべきではありません。128 ビット以上のセキュリティを使用するアル
125
ゴリズムは少なくとも数年間は解読不可能であることが期待されているので、強く推奨されます。3DES 暗
号は 168 ビットの使用といわれていますが、実際に提供されているのは 112 ビットのセキュリティであ
ることに注意してください。
(perfect) forward secrecy (PFS) をサポートしている暗号化スイートを常に優先させてください。PFS

は、サーバー鍵が漏れたとしても、暗号化されたデータの秘密性は確保されます。これにより、すばやい
RSA 鍵の交換がなくなる一方、ECDHE および DHE の使用が可能になります。これら 2 つのうちで
は、ECDHE の方がより速いため、優先される選択肢となります。
AES-GCM などの AEAD 暗号はパディングオラクル攻撃 (padding oracle attacks ) に対して脆弱ではな

いため、CBC モードの暗号よりも優先してください。さらに多くの場合、AES-GCM は特にハードウェアに
AES 用の暗号化アクセラレーターがある場合、CBC モードの AES よりも高速です。
また、ECDSA 証明書を使って ECDHE 鍵交換を使用する際は、純粋な RSA 鍵交換よりも速くなります。レ

ガシークライアント用のサポートを提供するには、サーバー上に証明書と鍵のペアを 2 つインストールし
ます。ひとつは ECDSA 鍵 (新規クライアント用) で、もうひとつは RSA 鍵 (レガシークライアント用) で
す。
公開鍵の長さ
RSA 鍵を使用する際は常に、少なくとも SHA-256 で署名された最低 3072 ビットの鍵の長さを優先さ

せます。これは、真の 128 ビットのセキュリティでは十分な大きさです。
警告
システムのセキュリティ強度は、チェーンの中の最も弱いリンクが示すものと同じであるというこ
とを念頭に置いてください。たとえば、強力な暗号化だけではすぐれたセキュリティは保証されま
せん。鍵と証明書も同様に重要で、認証機関 (CA) が鍵の署名に使用するハッシュ機能と鍵もまた重
要になります。
4.11.2. T LS 実装の使用
Re d Hat Ente rpris e Linux 7 には、完全機能の TLS 実装が同梱されています。本セクションで

は、OpenSSL および GnuT LS の設定を説明します。個別アプリケーションでの TLS サポートの設定
方法については、「特定アプリケーションの設定」を参照してください。
利用可能な TLS 実装は、各種の暗号化スイートをサポートします。これらのスイートは、TLS でセキュ

ア化された通信の確立および使用時に一緒に送られる全要素を定義します。
「有効にするアルゴリズムの選択」で示された推奨事項を検討するとともに、各種の実装で含まれている
ツールを使って、ご自分のユースケースにとって最善のセキュリティを提供する暗号化スイートを一覧表
示、指定してください。そこでできた暗号化スイートを使って、各アプリケーションが接続を処理してセ
キュア化することができます。
重要
使用する TLS 実装またはその実装を利用するアプリケーションが更新またはアップグレードされた

後は、必ず設定をチェックしてください。新しいバージョンは、ユーザーが有効化を希望せずかつ
使用中の設定では無効にされない、新たな暗号化スイートを導入する場合があります。
4.11.2.1. OpenSSL での暗号化スイートの使用
126
OpenSSL は、SSL および TLS プロトコルをサポートするツールキットおよび暗号化ライブラリーで

す。Re d Hat Ente rpris e Linux 7 では、設定ファイルは /etc/pki/tls/openssl.cnf にありま
す。その形式は、config(1) で確認できます。「Ope nSSL の設定」も参照してください。
インストール済みの OpenSSL でサポートされている暗号化スイートすべてを一覧表示するには、以下の

ように openssl コマンドで ciphers サブコマンドを実行します。
~]$ openssl ciphers -v 'ALL:COMPLEMENTOFALL'
(OpenSSL ドキュメンテーションでは cipher strings および keywords と呼ばれる) 他のパラメーター

を ciphers コマンドに渡して出力を絞ります。特別なキーワードを使うと、特定の条件を満たすスイート
のみを一覧表示することができます。たとえば、HIGH グループに属するスイートのみを一覧表示するに
は、以下のコマンドを実行します。
~]$ openssl ciphers -v 'HIGH'
利用可能なキーワードおよび暗号化文字列の一覧は、ciphe rs (1) の man ページを参照してください。
「有効にするアルゴリズムの選択」の推奨事項を満たす暗号化スイートを一覧表示するには、以下のよう
なコマンドを実行します。
~]$ openssl ciphers -v 'kEECDH+aECDSA+AES:kEECDH+AES+aRSA:kEDH+aRSA+AES'

| column -t
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA
Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256)
Mac=SHA384
ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256)
Mac=SHA1
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128)
Mac=SHA256
ECDHE-ECDSA-AES128-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128)
Mac=SHA1
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256)
Mac=SHA384
ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256)
Mac=SHA1
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128)
Mac=SHA256
ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128)
Mac=SHA1
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA
DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256)
Mac=SHA256
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256)
Mac=SHA1
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA
127
DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128)

Mac=SHA256
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128)
Mac=SHA1
上記のコマンドはセキュアでない暗号をすべて省略し、ephemeral elliptic curve Diffie-

Hellman 鍵交換と ECDSA 暗号を優先します。また、RSA 鍵交換も省略します (perfect forward
secrecy が保証されます)。
これはやや厳密な設定であることに注意してください。現実には条件を多少緩和して、より広い範囲のクラ
イアントとの互換性を可能にする必要があるかもしれません。
4.11.2.2. GnuT LS での暗号化スイートの使用
GnuT LS は、SSL および TLS の各プロトコルとそれに関連する技術を実装する通信ライブラリーです。
注記
Re d Hat Ente rpris e Linux 7 上の GnuT LS は、ほとんどのユースケースに十分なセキュリティ

をもたらす、最適なデフォルト設定値を提供します。特別なセキュリティ要件がない限り、提供さ
れたデフォルト値の使用が推奨されます。
gnutls-cli コマンドを -l (または --list) オプションと実行すると、サポート対象の暗号化スイート

すべてが一覧表示されます。
~]$ gnutls-cli -l
-l オプションで表示された暗号化スイート一覧を絞り込むには、ひとつ以上のパラメーター GnuT ( LS
ドキュメンテーションでは priority strings および keywords と呼ばれる) を --priority オプション
に渡します。利用可能な priority s trings の全一覧
は、http://www.gnutls .org/manual/gnutls .html#Priority-Strings にある GnuT LS ドキュメンテー
ションを参照してください。たとえば、少なくとも 128 ビットのセキュリティを提供する暗号化スイート
一覧を表示するには、以下のコマンドを実行します。
~]$ gnutls-cli --priority SECURE128 -l
「有効にするアルゴリズムの選択」の推奨事項を満たす暗号化スイートを一覧表示するには、以下のよう
なコマンドを実行します。
~]$ gnutls-cli --priority SECURE256:+SECURE128:-VERS-TLS-ALL:+VERS-

TLS1.2:-RSA:-DHE-DSS:-CAMELLIA-128-CBC:-CAMELLIA-256-CBC -l
Cipher suites for SECURE256:+SECURE128:-VERS-TLS-ALL:+VERS-TLS1.2:-RSA:-
DHE-DSS:-CAMELLIA-128-CBC:-CAMELLIA-256-CBC
TLS_ECDHE_ECDSA_AES_256_GCM_SHA384 0xc0, 0x2c
TLS1.2
TLS_ECDHE_ECDSA_AES_256_CBC_SHA384 0xc0, 0x24
TLS1.2
TLS_ECDHE_ECDSA_AES_256_CBC_SHA1 0xc0, 0x0a
SSL3.0
TLS_ECDHE_ECDSA_AES_128_GCM_SHA256 0xc0, 0x2b
TLS1.2
TLS1.2
128

SSL3.0
TLS_ECDHE_RSA_AES_256_GCM_SHA384 0xc0, 0x30
TLS1.2
TLS_ECDHE_RSA_AES_256_CBC_SHA1 0xc0, 0x14
SSL3.0
TLS_ECDHE_RSA_AES_128_GCM_SHA256 0xc0, 0x2f
TLS1.2
TLS1.2
SSL3.0
TLS_DHE_RSA_AES_256_CBC_SHA256 0x00, 0x6b
TLS1.2
TLS_DHE_RSA_AES_256_CBC_SHA1 0x00, 0x39
SSL3.0
TLS_DHE_RSA_AES_128_GCM_SHA256 0x00, 0x9e
TLS1.2
TLS1.2
SSL3.0
Certificate types: CTYPE-X.509

Protocols: VERS-TLS1.2
Compression: COMP-NULL
Elliptic curves: CURVE-SECP384R1, CURVE-SECP521R1, CURVE-SECP256R1
PK-signatures: SIGN-RSA-SHA384, SIGN-ECDSA-SHA384, SIGN-RSA-SHA512,
SIGN-ECDSA-SHA512, SIGN-RSA-SHA256, SIGN-DSA-SHA256, SIGN-ECDSA-SHA256
上記のコマンドは、出力を 128 ビット以上のセキュリティがある暗号に絞り込み、より強力なものを優先

しています。また、RSA 鍵交換と DSS 認証を禁止しています。
これはやや厳密な設定であることに注意してください。現実には条件を多少緩和して、より広い範囲のクラ
イアントとの互換性を可能にする必要があるかもしれません。
4.11.3. 特定アプリケーションの設定
アプリケーションはそれぞれ、TLS 用に個別の設定メカニズムを提供します。本セクションでは、最も一
般的に使用されているサーバーアプリケーションが使用する TLS 関連の設定ファイルについて説明し、よ
くある説明例を示します。
いずれの設定を選択しても、サーバーアプリケーションがサーバー側の暗号命令を強制し、使用される暗

号化スイートが必ずユーザー設定の命令で決定されるようにしてください。
4.11.3.1. Apache HT T P サーバーの設定
Apache HT T P Server は、TLS に OpenSSL と NSS の両方のライブラリーを使用できます。選択

した TLS ライブラリーによって、mo d_ssl か mo d_nss のモジュールをインストールする必要があり
ます (その名前の付いたパッケージが提供)。たとえば、OpenSSL mo d_ssl モジュールを提供するパッ
ケージをインストールするには、root で以下のコマンドを実行します。
~]# yum install mod_ssl
129
mod_ssl パッケージは /etc/httpd/conf.d/ssl.conf 設定ファイルをインストールし、これを使う

と Apache HT T P Server の TLS 関連の設定を修正できます。同様に、mod_nss パッケージは
/etc/httpd/conf.d/nss.conf 設定ファイルをインストールします。
httpd-manual パッケージをインストールして Apache HT T P Server の完全なドキュメンテーショ

ンを取得します。これには、TLS 設定が含まれます。/etc/httpd/conf.d/ssl.conf 設定ファイルで
利用可能なディレクティブの詳細は、/usr/share/httpd/manual/mod/mod_ssl.html で説明され
ています。各種設定の例は、/usr/share/httpd/manual/ssl/ssl_howto.html で確認できます。
/etc/httpd/conf.d/ssl.conf 設定ファイルの設定を修正する場合は、少なくとも下記の 3 つの
ディレクティブを確認してください。
SSLProtocol
許可する TLS (または SSL) のバージョンを指定するディレクティブです。
SSLCipherSuite
優先する暗号化スイートを指定する、もしくは許可しないスイートを無効にするディレクティブ
です。
SSLHonorCipherOrder
コメントを解除して、このディレクティブを on に設定すると、接続先のクライアントが指定さ
れた暗号化の命令に従います。
例を示します。
SSLProtocol all -SSLv2 -SSLv3

SSLCipherSuite HIGH:!aNULL:!MD5
SSLHonorCipherOrder on
上記の設定は最小限のものであり、「有効にするアルゴリズムの選択」にある推奨事項にしたがうことで
さらに強化できることに注意してください。
mo d_nss モジュールを設定、使用するには、/etc/httpd/conf.d/nss.conf 設定ファイルを修正

します。mo d_nss モジュールは mo d_ssl から派生しているため、後者と多くの機能を共有していま
す。設定ファイルの構成だけでなく、利用可能なディレクティブも同様です。mo d_nss ディレクティブ
には、SSL ではなく NSS の接頭辞が付くことに注意してください。mo d_nss に適用できない
mo d_ssl 設定ディレクティブの一覧を含む mo d_nss についての概要
は、https ://git.fe dorahos te d.org/cgit/mod_ns s .git/plain/docs /mod_ns s .html を参照してくださ
い。
4.11.3.2. Dovecot メールサーバーの設定
Do veco t メールサーバーが TLS を使用するように設定するには、/etc/dovecot/conf.d/10-

ssl.conf 設定ファイルを修正します。このファイルで利用可能な基本的な設定ディレクティブの一部
は、/usr/share/doc/dovecot-2.2.10/wiki/SSL.DovecotConfiguration.txt (このヘルプ
ファイルは標準 Do veco t インストールに含まれています) で説明しています。
/etc/dovecot/conf.d/10-ssl.conf 設定ファイルの設定を修正する場合は、少なくとも下記の 3
つのディレクティブを確認してください。
ssl_protocols
許可する TLS (または SSL) のバージョンを指定するディレクティブです。
ssl_cipher_list
130
優先する暗号化スイートを指定する、もしくは許可しないスイートを無効にするディレクティブ
です。
ssl_prefer_server_ciphers
コメントを解除して、このディレクティブを yes に設定すると、接続先のクライアントが指定

された暗号化の命令に従います。
例を示します。
ssl_protocols = !SSLv2 !SSLv3

ssl_cipher_list = HIGH:!aNULL:!MD5
ssl_prefer_server_ciphers = yes
上記の設定は最小限のものであり、「有効にするアルゴリズムの選択」にある推奨事項にしたがうことで
さらに強化できることに注意してください。
4.11.4. その他の情報
T LS の設定および関連トピックについての詳細情報は、以下に挙げるリソースを参照してください。
config(1) — /etc/ssl/openssl.conf 設定ファイルの形式を説明しています。
ciphe rs (1) — 利用可能な OpenSSL キーワードおよび暗号化文字列の一覧が含まれています。
/usr/share/httpd/manual/mod/mod_ssl.html — Apache HT T P Server 用に

mo d_ssl が使用する /etc/httpd/conf.d/ssl.conf 設定ファイルで利用可能なディレクティブ
を詳細に説明しています。
/usr/share/httpd/manual/ssl/ssl_howto.html — Apache HT T P Server 用に

mo d_ssl が使用する /etc/httpd/conf.d/ssl.conf 設定ファイルでの現実的な設定例が含まれ
ています。
/usr/share/doc/dovecot-2.2.10/wiki/SSL.DovecotConfiguration.txt —
Do veco t メールサーバーが使用する /etc/dovecot/conf.d/10-ssl.conf 設定ファイルで使
用可能な基本的設定ディレクティブについて説明しています。
Ente rpris e Linux 7 の『SELinux Us e r's and Adminis trator's Guide 』では、SELinux の原則
と、SELinux を設定して Apache HT T P Server などのさまざまなサービスで使用する方法が詳
細に説明されています。
http://tools .ie tf.org/html/draft-ie tf-uta-tls -bcp-00 — TLS および DTLS のセキュアな使用におけ

る推奨事項です。
関連項目
「SSL/TLS」では、SSL および TLS プロトコルを簡潔に説明しています。
「Ope nSSL の使用」では、OpenSSL を使用して鍵を作成、管理し、証明書を生成し、ファイルを

暗号化、暗号化解除する方法を説明しています。
131
第5章システム監査
Linux Audit システムは、システム上のセキュリティ関連情報を追跡する方法を提供します。事前設定ルー

ルに基づき、Audit はシステム上で発生しているイベントについての情報をできるだけ多く記録するための
ログエントリーを生成します。この情報は、セキュリティポリシーの違反者と違反者によるアクションを判
断する上でミッションクリティカルな環境で必須のものです。Audit は新たなセキュリティをシステムに
追加するわけではありません。システム上で使われているセキュリティポリシーの侵害を発見するために使
用されます。これらの侵害は、SELinux などの追加のセキュリティ対策でさらに防ぐことができます。
Audit がログファイルに記録できる情報のいくつかを、以下のリストで要約しています。
イベントの日付と時間、タイプ、結果。
サブジェクトとオブジェクトの機密性のラベル。
イベントを開始したユーザーの ID とイベントの関連性。
Audit 設定の全修正および Audit ログファイルへのアクセス試行。
SSH、Ke rbe ros 、およびその他の認証メカニズムのすべての使用。
/etc/passwd のような、信頼できるデータベースへの変更。
システムからの情報のインポートおよびシステムへの情報のエクスポートの試行。
ユーザー ID、サブジェクトおよびオブジェクトラベル、その他の属性に基づく include または

e xclude イベント。
Audit システムの使用は、多くのセキュリティ関連の証明書における要件でもあります。Audit は、以下の

証明書またはコンプライアンスガイドの要件に合致するかそれらを超えるように設計されています。
Controlle d Acce s s Prote ction Profile (CAPP)
Labe le d Se curity Prote ction Profile (LSPP)
Rule Se t Bas e Acce s s Control (RSBAC)
NISPOM (National Indus trial Se curity Program Ope rating Manual)
Fe de ral Information Se curity Manage me nt Act (FISMA)
Payme nt Card Indus try — Data Se curity Standard (PCI-DSS)
セキュリティ技術実装ガイド (STIG: Se curity Te chnical Imple me ntation Guide )
Audit は以下でも認定されています。
National Information As s urance Partne rs hip (NIAP) および Be s t Se curity Indus trie s (BSI)
による評価。
Re d Hat Ente rpris e Linux 5 上での LSPP/CAPP/RSBAC/EAL4+ の認定。
Re d Hat Ente rpris e Linux 6 上での Ope rating Sys te m Prote ction Profile / Evaluation
As s urance Le ve l 4+ (OSPP/EAL4+) の認定。
使用例
ファイルアクセスの監視
Audit は、ファイルやディレクトリーがアクセス、修正、実行されたか、またはファイル属性が
変更されたかを追跡することができます。これはたとえば、重要なファイルへのアクセスを検出
132
⁠第5章システム監査
変更されたかを追跡することができます。これはたとえば、重要なファイルへのアクセスを検出
し、これらのファイルが破損した場合に監査証跡を入手可能とする際に便利なものです。
システムコールの監視
Audit は、特定のシステムコールが使用されるたびにログエントリーを生成するように設定でき
ます。これを使用すると、settimeofday や clock_adjtime、その他の時間関連のシステム
コールを監視することで、システム時間への変更を追跡できます。
ユーザーが実行したコマンドの記録
Audit はファイルが実行されたかどうかを追跡できるので、特定のコマンドの実行を毎回記録す
るようにいくつものルールを定義することができます。たとえば、/bin ディレクトリー内の実
行可能ファイルすべてについてルールを定義することができます。その結果できるログエント
リーをユーザー ID で検索すると、ユーザーごとに実行されたコマンドの監査証跡を生成するこ
とができます。
セキュリティイベントの記録
pam_faillock 認証モジュールは、失敗したログイン試行を記録することができます。Audit
で失敗したログイン試行も記録するように設定すると、ログインを試みたユーザーについての追
加情報が提供されます。
イベントの検索
Audit は ausearch ユーティリティーを提供します。これを使うと、ログエントリーをフィル

ターにかけ、いくつもの条件に基づく完全な監査証跡を提供することができます。
サマリーレポートの実行
aurepo rt ユーティリティーを使うと、記録されたイベントのデイリーレポートを生成するこ
とができます。システム管理者は、このレポートを分析し、疑わしいアクティビティーをさらに
調べることができます。
ネットワークアクセスの監視
ipt ables と ebt ables ユーティリティーは Audit イベントを開始するように設定でき、こ

れでシステム管理者はネットワークアクセスを監視できるようになります。
注記
システムのパフォーマンスは、Audit が収集する情報量によって影響される可能性があります。
5.1. Audit システムのアーキテクチャー
Audit システムは、ユーザースペースアプリケーションおよびユーティリティーと、カーネル側のシステム
コール処理という 2 つの主要パートで構成されます。カーネルコンポーネントは、ユーザースペースアプ
リケーションからシステムコールを受け、これを user、t ask、または exit のいずれかのフィルターで
振り分けます。システムコールがフィルターのどれかを通過すると、exclude フィルターに掛けられま
す。このフィルターは Audit ルール設定に基づいて、システムコールを Audit デーモンに送信してさらに
処理します。図5.1「Audit システムのアーキテクチャー」では、このプロセスを示しています。
133
図5.1 Audit システムのアーキテクチャー
ユーザースペースの Audit デーモンはカーネルから情報を収集し、ログファイルにログファイルエント

リーを作成します。他のユーザースペースユーティリティーは、Audit デーモン、カーネル Audit コン
ポーネント、または Audit ログファイルと対話します。
audisp — Audit ディスパッチャーデーモンは Audit デーモンと対話し、イベントを他のアプリケー

ションに送信してさらに処理します。このデーモンの目的は、プラグインメカニズムを提供して、リア
ルタイムの分析プログラムが Audit イベントと対話できるようにすることです。
audit ct l — Audit 制御ユーティリティーはカーネル Audit コンポーネントと対話し、イベント生成

プロセスの多くの設定やパラメーターを制御します。
残りの Audit ユーティリティーは Audit ログファイルのコンテンツを入力として受け取り、ユーザー

の要件に基づいて出力を生成します。たとえば、aurepo rt ユーティリティーは記録された全イベン
トのレポートを生成します。
5.2. audit パッケージのインストール
Audit システムを使用するには、audit パッケージがシステムにインストールされている必要がありま

す。audit パッケージ (audit および audit-libs) は、デフォルトで Re d Hat Ente rpris e Linux 6 にイ
ンストールされています。これらのパッケージがインストールされていない場合は、root で以下のコマン
ド実行してインストールします。
~]# yum install audit
5.3. audit サービスの設定
Audit デーモンは、/etc/audit/auditd.conf 設定ファイルで設定できます。このファイルは、Audit

デーモンの動作を修正する設定パラメーターで構成されています。空の行やハッシュ記号 (#) の後に続くテ
キストは無視されます。設定パラメーターの全一覧とそれらの説明は、audit.conf(5) man ページで確認
できます。
134
5.3.1. CAPP 環境用の auditd 設定
デフォルトの auditd 設定は、ほとんどの環境で適切なものです。ただし、使用中の環境が、Common

Crite ria 認証の一部である Co nt ro lled Access Pro t ect io n Pro f ile (CAPP) で設定された基準
に適合する必要がある場合は、以下のように Audit デーモンを設定する必要があります。
Audit ログファイルを格納するディレクトリー (通常 /var/log/audit/) を、別個のパーティション

に置きます。これにより、他のプロセスがこのディレクトリーのスペースを使うことを防ぎます。ま
た、Audit デーモン用に残りのスペースがどれだけあるか、正確に分かるようになります。
単一 Audit ログファイルの最大サイズを指定する max_log_file パラメーターは、Audit ログファ

イルを格納するパーティション上で利用可能なスペースを最大活用するように設定する必要がありま
す。
max_log_file_action パラメーターは、max_log_file で設定された上限に達した際に取られる

アクションを決定します。これは、keep_logs に設定して、Audit ログファイルが上書きされないよ
うにすべきです。
space_left パラメーターは、ここで指定した値にディスク上の残りの空きスペースが達する
と、space_left_action パラメーターで定義したアクションが起動します。s pace _le ft で指定す
るディスクの残り空きスペースの値は大きなものに設定し、これがなくなる前に管理者が対応してス
ペースを利用可能にできるようにすべきです。space_left の値は、Audit ログファイルが生成され
るレートによって異なります。
space_left_action パラメーターは、email または exec に設定して適切な通知方法にすること

が推奨されます。
admin_space_left パラメーターは、ここで指定した値にディスク上の残りの空きスペースが達する
と、admin_space_left_action パラメーターで定義したアクションが起動します。
admin_s pace _le ft の値は大きなものに設定し、管理者が実行するアクションをログ記録できるように
する必要があります。
admin_space_left_action は single に設定して、システムをシングルユーザーモードにし、管

理者がディスクスペースを解放できるようにする必要があります。
disk_full_action パラメーターは、Audit ログファイルを格納するパーティションに空きスペー

スが無くなった場合に起動するアクションを指定します。このパラメーターは、halt または single
のどちらかに設定する必要があります。これにより、Audit がイベントをログ記録できなくなった際
に、システムがシャットダウンするか、シングルユーザーモードで稼働するようになります。
disk_error_action は、Audit ログファイルがあるパーティションでエラーが検出された場合に起

動するアクションを指定します。このパラメーターは、ハードウェアの機能不全処理に関するローカル
のセキュリティポリシーによって、syslog、single、halt のいずれかに設定する必要がありま
す。
flush 設定パラメーターは、sync または data に設定します。これにより、すべての Audit イベン

トデータがディスク上のログファイルと完全に同期されます。
残りの設定オプションは、ローカルのセキュリティポリシーにあわせて設定します。
5.4. audit サービスの起動
auditd を適切に設定したら、サービスを起動して Audit 情報を収集し、ログファイルに保存します。

root で以下のコマンドを実行して auditd を起動します。
~]# service auditd start
135
オプションでは、root で以下のコマンドを実行すると、auditd がブート時に起動するように設定できま

す。
~]# chkconfig auditd on
auditd では、service auditd action コマンドを使用して、他のアクションが実行できます。ここ

での action は、以下のいずれかになります。
stop — auditd を停止します。
restart — auditd を再起動します。
reload または force-reload — audit d の設定を /etc/audit/auditd.conf ファイルから

再読み込みします。
rotate — /var/log/audit/ ディレクトリー内のログファイルを交代させます。
resume — Audit イベントのログが一旦停止された後、再開します。たとえば、Audit ログファイルが

あるディスクパーティションの未使用スペースが十分でない場合などです。
condrestart または try-restart — audit d がすでに実行中の場合にのみ、これを再起動しま

す。
status — 実行中の audit d のステータスを表示します。
5.5. Audit ルールの定義
Audit システムは、ログファイルにキャプチャーされるものを定義するルールセットで作動します。指定
可能な Audit ルールには、以下の 3 つのタイプがあります。
制御ルール — Audit システムの動作と設定のいくつかの修正が可能になります。
ファイルシステムルール — ファイルウォッチとも呼ばれ、特定のファイルまたはディレクトリーへの
アクセスの監査が可能になります。
システムコールルール — 特定のプログラムが実行するシステムコールのログ記録が可能になります。
Audit ルールは、audit ct l ユーティリティーのコマンドラインで指定するか (このルールは再起動後は維

持されません)、/etc/audit/audit.rules ファイルに書き込んで指定することができます。以下の 2
つのセクションでは、Audit ルール定義における両方のアプローチをまとめています。
5.5.1. audit ct l ユーティリティーを使った Audit ルールの定義
注記
Audit サービスおよび Audit ログファイルと対話するすべてのコマンドは、root 権限が必要になり

ます。これらのコマンドは、必ず root ユーザーとして実行してください。
auditctl コマンドを使うと、Audit システムの基本的な機能を制御し、どの Audit イベントをログ記録

するかを決定するルールが定義できます。
制御ルールの定義
以下の制御ルールを使うと、Audit システムの動作が修正できます。
136
-b
カーネルにおける既存のAudit バッファの最大値を設定します。例を示します。
~]# auditctl -b 8192
-f
重大なエラーが検出された際に実行されるアクションを設定します。例を示します。
~]# auditctl -f 2
上記の設定では、重大なエラーが発生した際にカーネルパニックが起動されます。
-e
Audit システムを有効または無効にする、もしくは設定をロックします。例を示します。
~]# auditctl -e 2
上記のコマンドは、Audit 設定をロックします。
-r
1 秒あたりに生成されるメッセージ数を設定します。例を示します。
~]# auditctl -r 0
上記の設定では、生成されるメッセージ数は制限されません。
-s
Audit システムのステータスをレポートします。例を示します。
~]# auditctl -s
AUDIT_STATUS: enabled=1 flag=2 pid=0 rate_limit=0
backlog_limit=8192 lost=259 backlog=0
-l
読み込まれている Audit ルールすべてを一覧表示します。例を示します。
~]# auditctl -l
LIST_RULES: exit,always watch=/etc/localtime perm=wa key=time-
change
LIST_RULES: exit,always watch=/etc/group perm=wa key=identity
LIST_RULES: exit,always watch=/etc/passwd perm=wa key=identity
LIST_RULES: exit,always watch=/etc/gshadow perm=wa key=identity
⋮
-D
読み込まれている Audit ルールすべてを削除します。例を示します。
~]# auditctl -D
No rules
137
ファイルシステムルールの定義
ファイルシステムのルールを定義するには、以下の構文を使用します。
auditctl -w path_to_file -p permissions -k key_name
ここでは、
path_to_file は、監査対象のファイルもしくはディレクトリーになります。
permissions は、ログ記録されるパーミッションになります。
r — ファイルまたはディレクトリーの読み取りアクセスです。
w — ファイルまたはディレクトリーの書き込みアクセスです。
x — ファイルまたはディレクトリーの実行アクセスです。
a — ファイルまたはディレクトリーの属性を変更します。
key_name は、どのルールまたはルールセットが特定のログエントリーを生成したかを特定する際に役
立つオプションの文字列です。
例5.1 ファイルシステムルール
/etc/passwd ファイルへのすべての書き込みアクセスとこのファイルのすべての属性変更をログ記録
するルールを定義するには、以下のコマンドを実行します。
~]# auditctl -w /etc/passwd -p wa -k passwd_changes
-k オプションに続く文字列は任意のものであることに注意してください。
/etc/selinux/ ディレクトリー内の全ファイルへのすべての書き込みアクセスとこれらファイルのす
べての属性変更をログ記録するルールを定義するには、以下のコマンドを実行します。
~]# auditctl -w /etc/selinux/ -p wa -k selinux_changes
Linux カーネルにモジュールを挿入する /sbin/insmod コマンドの実行をログ記録するルールを定義

するには、以下のコマンドを実行します。
~]# auditctl -w /sbin/insmod -p x -k module_insertion
システムコールルールの定義
システムコールのルールを定義するには、以下の構文を使用します。
auditctl -a action,filter -S system_call -F field=value -k key_name
ここでは、
action および filter は、特定のイベントがいつログ記録されるかを指定します。action は、always

または never になります。filter は、イベントにどのカーネルルール適合のフィルターを適用するかを
138
指定します。ルール適合フィルターは、task、exit、user、exclude のいずれかになります。これ
らフィルターの詳細については、「Audit システムのアーキテクチャー」の最初の部分を参照してくだ
さい。
system_call は、名前でシステムコールを指定します。システムコールの全一覧
は、/usr/include/asm/unistd_64.h ファイルで確認できます。複数のシステムコールをひとつ
のグループにまとめて、-S オプションの後にそれらを指定することも可能です。
field=value では、指定されたアーキテクチャー、グループ ID、プロセス ID、その他に基づいて、

ルールがイベントに合致するようさらに修正する追加オプションを指定します。利用可能なフィールド
のタイプおよびそれらの値の全一覧は、auditctl(8) man ページで確認できます。
key_name は、どのルールまたはルールセットが特定のログエントリーを生成したかを特定する際に役
立つオプションの文字列です。
例5.2 システムコールのルール
システムが 64 ビットアーキテクチャーを使用していて、プログラムが adjtimex または

settimeofday システムコールを使用するたびにログエントリーを作成するルールを定義するには、以
~]# auditctl -a always,exit -F arch=b64 -S adjtimex -S settimeofday -k

time_change
ユーザー ID が 500 以上 (-F auid!=4294967295 オプションを使用すると、ログイン UID が設定

されていないユーザーが除外されます) のシステムユーザーがファイルを削除またはファイルの名前を変
更するたびにログエントリーを作成するルールを定義するには、以下のコマンドを実行します。
~]# auditctl -a always,exit -S unlink -S unlinkat -S rename -S

renameat -F auid>=500 -F auid!=4294967295 -k delete
システムコールルールの構文を使って、ファイルシステムのルールを定義することもできます。以下の
コマンドでは、-w /etc/shadow -p wa ファイルシステムルールに似たシステムコールのルールが
作成されます。
~]# auditctl -a always,exit -F path=/etc/shadow -F perm=wa
5.5.2. 永続的な Audit ルールの定義と /etc/audit/audit.rules ファイルでの制御
再起動後も維持される Audit ルールを定義するには、そのルールを /etc/audit/audit.rules ファイ

ルに含める必要があります。このファイルは、同じ auditctl コマンドライン構文を使ってルールを指定
します。空の行やハッシュ記号 (#) に続くテキストは無視されます。
auditctl コマンドで -R オプションを使うと、指定されたファイルからルールを読み取ることもできま

す。例を示します。
~]# auditctl -R /usr/share/doc/audit-version/stig.rules
制御ルールの定義
139
ファイルに含めることができるのは、-b、-D、-e、-f、および -r の制御ルールのみで、これらは Audit

の動作を修正します。これらのオプションに関する詳細は、5.5.1項「制御ルールの定義」を参照してくだ
さい。
例5.3 audit.rules での制御ルール
# Delete all previous rules

-D
# Set buffer size

-b 8192
# Make the configuration immutable -- reboot is required to change

audit rules
-e 2
# Panic when a failure occurs

-f 2
# Generate at most 100 audit messages per second

-r 100
ファイルシステムおよびシステムコールのルールの定義
ファイルシステムおよびシステムコールのルールは、auditctl 構文を使って定義します。「audit ct l
ユーティリティーを使った Audit ルールの定義」の例は、以下のルールファイルのようになります。
例5.4 audit.rules でのファイルシステムおよびシステムコールのルール
-w /etc/passwd -p wa -k passwd_changes
-w /etc/selinux/ -p wa -k selinux_changes
-w /sbin/insmod -p x -k module_insertion
-a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time_change

-a always,exit -S unlink -S unlinkat -S rename -S renameat -F
auid>=500 -F auid!=4294967295 -k delete
事前設定ルールのファイル
/usr/share/doc/audit-version/ ディレクトリーでは、audit パッケージが各種の証明書基準にし

たがって事前設定ルールのファイル一式を提供しています。
nispom.rules — NISPOM (National Indus trial Se curity Program Ope rating Manual) の第 8
章で指定されている要件に合致する、Audit ルール設定です。
capp.rules — Common Crite ria 認証の一部である Controlle d Acce s s Prote ction Profile
(CAPP) が設定している要件に合致する、Audit ルール設定です。
lspp.rules — Common Crite ria 認証の一部である Labe le d Se curity Prote ction Profile
(LSPP) が設定している要件に合致する、Audit ルール設定です。
140
stig.rules — セキュリティ技術実装ガイド (STIG: Se curity Te chnical Imple me ntation

Guide ) で設定している要件に合致する、Audit ルール設定です。
これらの設定ファイルを使用するには、オリジナルの /etc/audit/audit.rules ファイルのバック

アップを作成し、選択する設定ファイルをこの /etc/audit/audit.rules にコピーします。
~]# cp /etc/audit/audit.rules /etc/audit/audit.rules_backup

~]# cp /usr/share/doc/audit-version/stig.rules /etc/audit/audit.rules
5.6. Audit ログファイルについて
デフォルトでは、Audit システムはログエントリーを /var/log/audit/audit.log ファイルに保存し

ます。ログローテーションが有効になっていれば、ローテーションされた audit.log ファイルは同じ
ディレクトリーに保存されます。
下記の Audit ルールは、/etc/ssh/sshd_config ファイルの読み取りまたは修正の試行をすべてログ

記録します。
-w /etc/ssh/sshd_config -p warx -k sshd_config
auditd デーモンが実行中の場合、以下のコマンドが Audit ログファイルに新規イベントを作成します。
~]# cat /etc/ssh/sshd_config
このイベントは audit.log ファイル内で以下のように見えます。
type=SYSCALL msg=audit(1364481363.243:24287): arch=c000003e syscall=2

success=no exit=-13 a0=7fffd19c5592 a1=0 a2=7fffd19c4b50 a3=a items=1
ppid=2686 pid=3538 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500
egid=500 sgid=500 fsgid=500 tty=pts0 ses=1 comm="cat" exe="/bin/cat"
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
key="sshd_config"
type=CWD msg=audit(1364481363.243:24287): cwd="/home/shadowman"
type=PATH msg=audit(1364481363.243:24287): item=0
name="/etc/ssh/sshd_config" inode=409248 dev=fd:00 mode=0100600 ouid=0
ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0
上記のイベントは、3 つの記録 (それぞれ type= キーワードで開始) で構成されており、これらは同じタ

イムスタンプとシリアル番号を共有しています。各記録は、いくつかの name=value のペアで構成されて
おり、これらは空白またはコンマ区切りとなっています。以下で上記のイベントを詳しく分析します。
最初の記録
type=SYSCALL
type フィールドには、記録のタイプが記載されます。この例では、この記録がカーネルへのシ
ステムコールで開始されたことを SYSCALL の値が示しています。
タイプの値およびそれらの説明に関する全一覧は、「Audit 記録のタイプ」を参照してくださ

い。
msg=audit(1364481363.243:24287):
msg フィールドでは以下を記録しています。
141
audit(time_stamp:ID) の形式で、記録のタイムスタンプと一意の ID。複数の記録は、

それらが同一の Audit イベントの一部として生成されている場合は、同じタイムスタンプと
ID を共有できます。
各種のイベント固有の name=value ペア。これは、カーネルもしくはユーザースペースアプ

リケーションが提供します。
arch=c000003e
arch フィールドには、システムの CPU アーキテクチャーについての情報が含まれま

す。c000003e という値は、十六進法でエンコードされています。ausearch コマンドで
Audit 記録を検索する際は、-i または --interpret オプションを使うと自動的に十六進法の
値がヒューマンリーダブルなものに変換されます。c000003e の値は、x86_64 として解釈され
ます。
syscall=2
syscall フィールドは、カーネルに送信されたシステムコールのタイプを記録します。2 とい
う値は、/usr/include/asm/unistd_64.h ファイル内のヒューマンリーダブルに相当する
ものにマッチします。このケースでは、2 は open システムコールになります。ausyscall
ユーティリティーを使うと、システムコール番号をヒューマンリーダブルなものに変換できるこ
とに注意してください。ausyscall --dump コマンドを実行すると、システムコールすべてと
それらの番号一覧が表示されます。詳細情報は、aus ys call(8) man ページを参照してくださ
い。
success=no
success フィールドは、その特定のイベントで記録されたシステムコールが成功したかどうか
を記録します。このケースでは、コールは成功しませんでした。
exit=-13
exit フィールドには、システムコールが返した終了コードを指定する値が含まれています。こ
の値は、システムコールによって異なります。以下のコマンドを使うと、この値をヒューマン
リーダブルなものに変換できます。 ausearch --interpret --exit -13 (Audit ログに
終了コード -13 で失敗したイベントが含まれていることが前提)。
a0=7fffd19c5592, a1=0, a2=7fffd19c5592, a3=a
a0 から a3 までのフィールドは、このイベントにおけるシステムコールの最初の 4 つの引数を
十六進法で記録します。これらの引数は、使用されているシステムコールによって異なりま
す。ausearch ユーティリティーでこれらを変換できます。
items=1
items フィールドには、イベントのパス記録の数が含まれています。
ppid=2686
ppid フィールドは、親プロセス ID (PPID) を記録します。このケースでは、2686 は bash プ

ロセスの PPID でした。
pid=3538
pid フィールドは、プロセス ID (PID) を記録します。このケースでは、3538 は、cat プロセ

スの PID でした。
auid=500
142
auid は、loginuid である Audit ユーザー ID を記録します。この ID は、ログイン時にユー

ザーに割り当てられ、ユーザーの ID が変更された後でもすべてのプロセスに引き継がれます (た
とえば、su - john コマンドでユーザーアカウントを切り替えた場合)。
uid=500
uid フィールドは、分析されているプロセスを開始したユーザーのユーザー ID を記録します。

ユーザー ID は、以下のコマンドでユーザー名に変換できます。ausearch -i --uid UID。
このケースでは、500 は shadowman のユーザー ID です。
gid=500
gid フィールドは、分析されているプロセスを開始したユーザーのグループ ID を記録します。
euid=500
euid フィールドは、分析されているプロセスを開始したユーザーの実効ユーザー ID を記録し

ます。
suid=500
suid フィールドは、分析されているプロセスを開始したユーザーのセットユーザー ID を記録

します。
fsuid=500
fsuid フィールドは、分析されているプロセスを開始したユーザーのファイルシステムユーザー
ID を記録します。
egid=500
egid フィールドは、分析されているプロセスを開始したユーザーの実効グループ ID を記録し

ます。
sgid=500
sgid フィールドは、分析されているプロセスを開始したユーザーのセットグループ ID を記録

します。
fsgid=500
fsgid フィールドは、分析されているプロセスを開始したユーザーのファイルシステムグループ
tty=pts0
tty フィールドは、分析されているプロセスが開始されたターミナルを記録します。
ses=1
ses フィールドは、分析されているプロセスが開始されたセッションのセッション ID を記録し

ます。
comm="cat"
comm フィールドは、分析されているプロセスを開始するために使用されたコマンドのコマンド
ライン名を記録します。このケースでは、cat コマンドを使ってこの Audit イベントが開始され
ました。
exe="/bin/cat"
143
exe フィールドは、分析されているプロセスを開始するために使用された実行可能ファイルへの
パスを記録します。
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
subj フィールドは、分析されているプロセスの実行時にラベル付けされた SELinux コンテン

ツを記録します。
key="sshd_config"
key フィールドは、Audit ログでこのイベントを生成したルールに関連付けられている管理者に

よる定義の文字列を記録します。
2 番目の記録
type=CWD
2 番目の記録では、type フィールドの値は、現在の作業ディレクトリーである CWD になりま

す。このタイプは、最初の記録で指定されているシステムコールを開始したプロセスが実行され
ている作業ディレクトリーの記録に使われます。
この記録の目的は、相対パスが関連する PATH 記録に保存された場合に、現行プロセスの位置を

記録することにあります。この方法により、このプロセスの絶対パスが再構築可能になります。
msg=audit(1364481363.243:24287)
msg フィールドは、最初の記録と同じタイムスタンプと ID の値になります。
cwd="/home/shadowman"
cwd フィールドは、システムコールが開始されたディレクトリーへのパスになります。
3 番目の記録
type=PATH
3 番目の記録では、type フィールドの値は PATH になります。Audit イベントには、システム

コールに引数として渡されたすべてのパスに PATH タイプの記録が含まれます。この Audit イベ
ントでは、1 つのパス (/etc/ssh/sshd_config) のみが引数として使われています。
msg=audit(1364481363.243:24287):
msg フィールドは、最初と 2 番目の記録と同じタイムスタンプと ID の値になります。
item=0
item フィールドは、SYSCALL タイプの記録で参照されたアイテム総数のうち、どのアイテム

が現行の記録かを示します。この数字はゼロベースで、0 は最初のアイテムであることを示しま
す。
name="/etc/ssh/sshd_config"
name フィールドは、システムコールに引数として渡されたファイルまたはディレクトリーへの
完全パスを記録します。このケースでは、/etc/ssh/sshd_config ファイルとなります。
inode=409248
144
inode フィールドには、このイベントで記録されたファイルまたはディレクトリーに関連する
inode 番号が含まれます。以下のコマンドを実行すると、409248 inode 番号に関連するファ
イルまたはディレクトリーが表示されます。
~]# find / -inum 409248 -print

/etc/ssh/sshd_config
dev=fd:00
dev フィールドは、このイベントで記録されたファイルまたはディレクトリーを含むデバイスの
マイナーおよびメジャー ID を示します。このケースでは、値は /dev/fd/0 デバイスを示して
います。
mode=0100600
mode フィールドは、ファイルまたはディレクトリーパーミッションを数字表記でエンコードさ
れた形で記録します。このケースでは、0100600 は -rw------- に変換可能です。つまり、
root ユーザーにのみ、/etc/ssh/sshd_config ファイルへの読み取りおよび書き込みパー
ミッションがあることをなります。
ouid=0
ouid フィールドは、オブジェクトの所有者のユーザー ID を記録します。
ogid=0
ogid フィールドは、オブジェクトの所有者のグループ ID を記録します。
rdev=00:00
rdev フィールドには、特定なファイルにのみ使われる、記録されたデバイス識別子が含まれま
す。このケースでは、記録されたファイルは通常のファイルなので、使われていません。
obj=system_u:object_r:etc_t:s0
obj フィールドは、実行時に記録されたファイルまたはディレクトリーにラベル付けされる
SELinux コンテキストを記録します。
上記で分析された Audit イベントには、イベントに含まれる可能性のあるフィールドのサブセットのみが

含まれています。イベントフィールドおよびそれらの説明の全一覧は、「Audit イベントフィールド」を
参照してください。イベントのタイプおよびそれらの説明の全一覧は、「Audit 記録のタイプ」を参照し
てください。
例5.5 追加の audit.log イベント
以下の Audit イベントでは、auditd デーモンが正常にスタートしたことを記録しています。ver

フィールドでは、開始された Audit デーモンのバージョンを示しています。
type=DAEMON_START msg=audit(1363713609.192:5426): auditd start,

ver=2.2 format=raw kernel=2.6.32-358.2.1.el6.x86_64 auid=500 pid=4979
subj=unconfined_u:system_r:auditd_t:s0 res=success
以下の Audit イベントでは、UID が 500 のユーザーが root ユーザーとしてログインを試み、失敗し

たことを記録しています。
145
type=USER_AUTH msg=audit(1364475353.159:24270): user pid=3280 uid=500

auid=500 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-
s0:c0.c1023 msg='op=PAM:authentication acct="root" exe="/bin/su"
hostname=? addr=? terminal=pts/0 res=failed'
5.7. Audit ログファイルの検索
ausearch ユーティリティーを使うと、Audit ログファイル内で特定のイベントを検索できます。デフォ

ルトでは、ausearch は /var/log/audit/audit.log ファイルを検索します。ausearch
options -if file_name コマンドを使うと、別のファイルを指定できます。ausearch コマンドで複
数のオプションを渡すと、AND 演算子の使用に相当します。
例5.6 ausearch を使った Audit ログファイルの検索
失敗したログイン試行を /var/log/audit/audit.log ファイル内で検索するには、以下のコマン

~]# ausearch --message USER_LOGIN --success no --interpret
すべてのアカウント、グループ、役割変更を検索するには、以下のコマンドを実行します。
~]# ausearch -m ADD_USER -m DEL_USER -m ADD_GROUP -m USER_CHAUTHTOK -m

DEL_GROUP -m CHGRP_ID -m ROLE_ASSIGN -m ROLE_REMOVE -i
特定のユーザーがそのユーザーのログイン ID (auid) を使って実行したログインのアクションをすべて

検索するには、以下のコマンドを実行します。
~]# ausearch -ua 500 -i
昨日から現在までに失敗したすべてのシステムコールを検索するには、以下のコマンドを実行します。
~]# ausearch --start yesterday --end now -m SYSCALL -sv no -i
ausearch オプションの全一覧は、aus e arch(8) man ページを参照してください。
5.8. Audit レポートの作成
aurepo rt ユーティリティーを使うと、Audit ログファイルに記録されたイベントについてのサマリーと

レポートが生成できます。デフォルトでは、レポート作成のために /var/log/audit/ 内のすべての
audit.log ファイルがクエリされます。aureport options -if file_name コマンドを使うと、
レポート作成に別のファイルをクエリするよう指定できます。
例5.7 aureport を使った Audit レポートの生成
今日を除いた過去 3 日間にログ記録されたイベントのレポートを生成するには、以下のコマンドを実行
します。
~]# aureport --start 04/08/2013 00:00:00 --end 04/11/2013 00:00:00
146
実行可能ファイルのイベントすべてについてのレポートを生成するには、以下のコマンドを実行しま
す。
~]# aureport -x
上記の実行可能ファイルのレポートのサマリーを生成するには、以下のコマンドを実行します。
~]# aureport -x --summary
全ユーザーの失敗したイベントのレポートサマリーを生成するには、以下のコマンドを実行します。
~]# aureport -u --failed --summary -i
システムユーザーごとのすべてのログイン試行失敗のレポートサマリーを生成するには、以下のコマンド
~]# aureport --login --summary -i
ユーザー 500 のすべてのファイルアクセスイベントを検索するausearch クエリからレポートを生成

するには、以下のコマンドを実行します。
~]# ausearch --start today --loginuid 500 --raw | aureport -f --

summary
クエリされたすべての Audit ファイルおよびそれらに含まれるイベントの時間帯についてのレポートを

生成するには、以下のコマンドを実行します。
~]# aureport -t
aureport オプションの全一覧は、aure port(8) man ページを参照してください。
Audit システムについての詳細情報は、以下のリソースを参照してください。
オンラインのリソース
Linux Audit システムのプロジェクトページ: http://pe ople .re dhat.com/s grubb/audit/
Hack In the Box 誌の記事『Inve s tigating ke rne l Re turn Code s with the Linux Audit
Sys te m』 : http://magaz ine .hackinthe box.org/is s ue s /HITB-Ez ine -Is s ue -005.pdf
audit パッケージが提供するドキュメンテーションは、/usr/share/doc/audit-version/ ディレク

トリーにあります。
man ページ
audis pd.conf(5)
147
auditd.conf(5)
aus e arch-e xpre s s ion(5)
audit.rule s (7)
audis pd(8)
auditctl(8)
auditd(8)
aulas t(8)
aulas tlog(8)
aure port(8)
aus e arch(8)
aus ys call(8)
autrace (8)
auvirt(8)
148
⁠第6 章コンプライアンスおよび O pe nSCAP を使った脆弱性のスキャン
第6章コンプライアンスおよび OpenSCAP を使った脆弱性のス

キャン
6.1. Red Hat Ent erprise Linux におけるセキュリティコンプライアン

ス
コンプライアンス監査は、あるオブジェクトがコンプライアンスポリシーのすべてのルールにしたがって
いるかどうかを判断するプロセスです。コンプライアンスポリシーは、コンピューティング環境で使用さ
れる望ましい設定を指定するセキュリティ専門家が定義します。これは多くの場合、チェックリストの形式
を取ります。
コンプライアンスポリシーは組織によって大幅に異なることがよくあり、同一組織内でもシステムが異なる
と様々なものになります。システムの目的や組織におけるシステム重要性に基づいて、これらのポリシーは
異なってきます。カスタム化したソフトウェア設定や導入の特徴によっても、カスタム化したポリシーの
チェックリストが必要になってきます。
Re d Hat Ente rpris e Linux は、完全に自動化されたコンプライアンス監査を可能にするツールを提供し

ます。これらのツールは SCAP (Se curity Conte nt Automation Protocol) 標準に基づいており、コンプ
ライアンスポリシーの自動化に合わせるように設計されています。
Red Hat Ent erprise Linux 7 でサポートされているセキュリティコンプライアンスツール
SCAP Wo rkbench — scap-workbench グラフィカルユーティリティーは、単一のローカルまた

はリモートシステム上で構成スキャンと脆弱性スキャンを実行するように設計されています。これらの
スキャンと評価に基づくセキュリティレポートの生成にも使用できます。
OpenSCAP — o scap コマンドラインユーティリティーは、ローカルシステムの上で構成スキャン

と脆弱性スキャンを実行するように設計されています。これにより、セキュリティコンプライアンスの
コンテンツを検証し、スキャンと評価に基づいてレポートとガイドを生成します。
複数のリモートのシステムで自動コンプライアンス監査を実行する必要がある場合は、Re d Hat Sate llite

用の Ope nSCAP ソリューションを利用することができます。詳細は、「Re d Hat Sate llite での
Ope nSCAP の使用」および「その他のリソース」を参照してください。
注記
Re d Hat は、Re d Hat Ente rpris e Linux 7 ディストリビューションではデフォルトでコンプラ

イアンスポリシーを提供していないことに注意してください。この理由については、「コンプライア
ンスポリシーの定義」で説明されています。
6.2. コンプライアンスポリシーの定義
セキュリティまたはコンプライアンスポリシーがまったくのゼロから書かれることはめったにありませ
ん。ISO 270 0 0 標準シリーズやその派生物、他のソースなどがセキュリティポリシーのテンプレートや
実践上の推奨事項を提供するので、最初はこれらが便利です。しかし、情報セキュリティプログラムを構築
している組織では、個別のニーズに合わせるためにポリシーテンプレートを修正する必要があります。テン
プレートは、企業環境への関連性に基づいて選択すべきです。テンプレートには組織に適用できない埋め込
みの前提が含まれていたり、テンプレートで特定の判断が明らかに必要であることなどから、テンプレート
選択後にこれを調整する必要があります。
149
Re d Hat Ente rpris e Linux の監査機能は、Se curity Conte nt Automation Protocol (SCAP) 標準を
ベースとしています。SCAP は相互運用可能な使用を統合したもので、形式と命名を標準化します。これら
の形式と命名により、ソフトウェアの弱点およびセキュリティ設定の情報がマシンとユーザーの両方に通信
されます。SCAP は、自動設定、脆弱性とパッチのチェック、技術的制御コンプライアンスアクティビ
ティー、およびセキュリティ措置などをサポートする仕様の複数目的のフレームワークです。
言い換えると、SCAP は、ベンダーにとらわれないセキュリティポリシーの表示方法です。このため、現
代の企業では幅広く使われています。SCAP 仕様は、セキュリティコンテンツの形式が周知かつ標準化さ
れたエコシステムを作り出す一方で、スキャナーやポリシーエディターの導入は義務化されません。このよ
うな状態では、企業がいくつものセキュリティベンダーを用いていても、組織がセキュリティポリシー
(SCAP コンテンツ) を構築するのは一度で済みます。
SCAP の最新バージョンには、いくつかの基礎的標準が含まれています。これらのコンポーネントは、
SCAP 内での機能により、以下のようにグループ化されています。
SCAP コンポーネント
言語 — このグループは、コンプライアンスポリシーを表現する標準的な語彙および慣習を定義する
SCAP 言語で構成されます。
eXtensible Configuration Checklist Description Format (XCCDF) — セキュリティガイダンス

を表示、組織、および管理するための言語です。
Open Vulnerability and Assessment Language (OVAL) — スキャンされたシステムの状態に

ついて論理的アサーションを実行するための言語です。
Open Checklist Interactive Language (OCIL) — ユーザーにクエリを行い、その質問に対する

ユーザーの返答を解釈するための標準的な方法を提供する言語です。
Asset Identification (AI) — セキュリティアセットを特定するためのデータモデル、方法、および

ガイダンスを提供する言語です。
Asset Reporting Format (ARF) — 収集されたセキュリティアセットおよびアセットとセキュリ

ティレポートとの関係についての情報の送信形式を表示する言語です。
列挙 — このグループには、命名形式および興味のある特定のセキュリティ関連の分野からのアイテム
の公式一覧または辞書を定義する、SCAP 基準が含まれています。
Common Configuration Enumeration (CCE) — アプリケーションおよびオペレーティングシス

テム用のセキュリティ関連設定要素の列挙です。
Common Platform Enumeration (CPE) — 情報技術 (IT) システム、プラットホーム、およびソ

フトウェアパッケージの特定に使用される構造化命名スキームです。
Common Vulnerabilities and Exposures (CVE) — 周知のソフトウェア脆弱性および露出のコ

レクションへの参照方法です。
メトリクス — このグループは、セキュリティリスクを特定、評価するフレームワークで構成されてい
ます。
Common Configuration Scoring System (CCSS) — セキュリティ関連の設定要素を評価し、そ

れらをスコアに割り当ててユーザーが適切な応答ステップの優先度を決定できるようにする、メトリ
クスシステムです。
Common Vulnerability Scoring System (CVSS) — ソフトウェアの脆弱性を評価し、それらを

スコアに割り当ててユーザーがセキュリティリスクの優先度を決定できるようにするメトリクスシス
テムです。
150
整合性 — SCAP コンポーネントとスキャンの結果の整合性を維持するための SCAP 仕様です。
Trust Model for Security Automation Data (TMSAD) — セキュリティ自動化ドメイン内の

XML ファイルのコンテンツにおいて、署名、ハッシュ、鍵情報、および ID 情報を表示するための
既存の仕様の使い方を説明した推奨事項です。
各 SCAP コンポーネントには、XML ベースのドキュメント形式とその XML ネームスペースがあります。

SCAP で表示されているコンプライアンスポリシーは、単一の OVAL 定義 XML ファイル、データスト
リームファイル、単一 z ip アーカイブ、またはポリシーチェックリストを表示する XCCDF ファイルを含
む別個の XML ファイルセットのいずれかになります。
6.2.1. XCCDF ファイル形式
XCCDF 言語は、情報交換、ドキュメント生成、組織および状況に応じた調整、自動コンプライアンステス
ト、およびコンプライアンススコアリングをサポートするように設計されています。この言語は主に記述的
で、セキュリティスキャンを実行するコマンドは含まれていません。しかし XCCDF ドキュメントは他の
SCAP コンポーネントを参照できるため、関連する評価ドキュメント (OVAL, OCIL) を除くすべてのター
ゲットプラットホームのなかで移植可能なコンプライアンスポリシーの作成に使用することができます。
コンプライアンスポリシーを表示する一般的な方法は XML ファイルセットで、このうちのひとつが

XCCDF チェックリストになります。この XCCDF は通常、評価リソース、複数の OVAL、OCIL および
Script Che ck Engine (SCE) ファイルを参照しています。さらに、このファイルセットには、CPE 辞書
ファイルとこの辞書用のオブジェクトを定義する OVAL ファイルを含めることができます。
XCCDF は XML ベースの言語であることから、非常に多くの XML 要素と属性を定義、使用します。以下

では、主要な XCCDF 要素を簡単に説明しています。XCCDF の詳細については、NIST Inte rage ncy
Re port 7275 Re vis ion 4 を参照してください。
XCCDF ドキュメントの主要 XML 要素
<xccdf:Benchmark> — XCCDF ドキュメント全体を囲むルート要素です。これには、タイトル、説

明、作者一覧、最新の修正日、チェックリスト受け付けのステータスなどのチェックリストのメタデー
タが含まれる場合があります。
<xccdf:Rule> — チェックリスト要件を表示し、その説明を保持する重要な要素です。これには、特
定のルールのコンプライアンスを確認または強制したり、ルール自体を修正するアクションを定義す
る、子要素が含まれる場合があります。
<xccdf:Value> — ベンチマーク内の他の XCCDF 要素の属性を表示するために使用される重要な要

素です。
<xccdf:Group> — この要素は、XCCDF ドキュメントを組織化して、要件と同じコンテキストまた

はタイプのグループや構造体を含みます。これは、<xccdf:Rule>、<xccdf:Value>、および
<xccdf:Group> 要素を収集することでなされます。
<xccdf:Profile> — この要素は、XCCDF ベンチマークの名前付き調整に使われます。ベンチマー

クがいくつかの異なるテーラリングを持つことが可能になります。<xccdf:Profile>
は、<xccdf:select> や <xccdf:refine-rule> などのいくつかのセレクター要素を使って、ど
の要素が実行中に修正されたり処理されたりするかを決定します。
<xccdf:Tailoring> — この要素では、ベンチマーク外のベンチマークプロファイルの定義が可能に
なります。これは、コンプライアンスポリシーの手動のテーラリングでは、妥当なものになる場合があ
ります。
151
<xccdf:TestResult> — この要素は、ターゲットシステム上の特定のベンチマークのスキャン結果
を保持する役割を果たします。各 <xccdf:TestResult> は、特定のスキャンのコンプライアンスポ
リシーを定義する際に使用されたプロファイルを参照するようにしてください。また、スキャンに関連
するターゲットシステムについての重要情報も含めるようにしてください。
<xccdf:rule-result> — <xccdf:TestResult> の子要素で、ベンチマークからターゲットシス

テムに特定のルールを適用した結果を保持するために使用されます。
<xccdf:fix> — <xccdf:Rule> の子要素で、特定のルールに従っていないターゲットシステムの

改善に使われます。これにターゲットシステム上で実行するコマンドまたはスクリプトを含めると、シ
ステムをルールにしたがわせることができます。
<xccdf:check> — <xccdf:Rule> の子要素で、特定ルールの評価方法を定義する外部ソースを参

照します。
<xccdf:select> — ポリシーから特定のルールまたはルールのグループを除外もしくは含めるために
使われるセレクター要素です。
<xccdf:set-value> — <xccdf:Value> 要素の属性を変更せずに、この要素で指定された現在の

値の上書きに使われるセレクター要素です。
<xccdf:refine-value> — ポリシーテーラリング中に特定の <xccdf:Value> 要素の制限を指定

するために使われるセレクター要素です。
<xccdf:refine-rule> — このセレクター要素は、選択されたルールの属性の上書きを可能にしま
す。
例6.1 XCCDF ドキュメントの例
<?xml version="1.0" encoding="UTF-8"?>

<Benchmark xmlns="http://checklists.nist.gov/xccdf/1.2"
id="xccdf_com.example.www_benchmark_test">
<status>incomplete</status>
<version>0.1</version>
<Profile id="xccdf_com.example.www_profile_1">
<title>Profile title is compulsory</title>
<select idref="xccdf_com.example.www_group_1"
selected="true"/>
<select idref="xccdf_com.example.www_rule_1"
selected="true"/>
<refine-value idref="xccdf_com.example.www_value_1"
selector="telnet service"/>
</Profile>
<Group id="xccdf_com.example.www_group_1">
<Value id="xccdf_com.example.www_value_1">
<value selector="telnet_service">telnet-server</value>
<value selector="dhcp_servide">dhcpd</value>
<value selector="ftp_service">tftpd</value>
</Value>
<Rule id="xccdf_com.example.www_rule_1">
<title>The telnet-server Package Shall Not Be Installed </title>
<rationale>
Removing the telnet-server package decreases the risk
of the telnet service’s accidental (or intentional) activation
</rationale>
<fix platform="cpe:/o:redhat:enterprise_linux:6"
152
reboot="false"
disruption="low"
system="urn:xccdf:fix:script:sh">
yum -y remove
<sub idref="xccdf_com.example.www_value_1"/>
</fix>
<check system="http://oval.mitre.org/XMLSchema/oval-definitions-
5">
<check-export value-id="xccdf_com.example.www_value_1"
export-name="oval:com.example.www:var:1"/>
<check-content-ref href="examplary.oval.xml"
name="oval:com.example.www:def:1"/>
</check>
<check system="http://open-scap.org/page/SCE">
<check-import import-name="stdout"/>
<check-content-ref href="telnet_server.sh"/>
</check>
</Rule>
</Group>
</Benchmark>
6.2.2. OVAL ファイル形式
Ope n Vulne rability As s e s s me nt Language (OVAL) は、SCAP の必須かつ最も古いコンポーネント

です。OVAL 標準の主なゴールは、セキュリティ製品の間で相互運用性を確保することです。これは、以
下の 3 つのドメインの標準化でなされます。
1. ターゲットシステム設定の表示。
2. ターゲットシステムが特定のマシン状態にあるかを分析。
3. 指定されたマシン状態と観察されたマシン状態の比較結果のレポーティング。
他のツールやカスタム化されたスクリプトとは異なり、OVAL 言語は宣言型でリソースの望ましい状態を記
述します。OVAL 言語コードはスキャナーと呼ばれる OVAL インタープリターツールを用いて実行されま
すが、直接実行されることは決してありません。OVAL が宣言型であるために、評価されるシステムの状態
が偶然に修正されることはありません。セキュリティスキャナーは可能な限り高い権限で実行されることが
多いので、これは重要な点になります。
OVAL 仕様はコメントと貢献を公開で受け付けています。また、多くの IT 企業が米連邦政府の援助を受け

た NPO である MITRE Corporation と協力しています。OVAL 仕様は継続的に発展しており、バージョ
ン番号で改訂版を区別しています。最新バージョンは 2012 年にリリースされた 5.10.1 になります。
他のすべての SCAP コンポーネントと同様に、OVAL は XML に基づいています。OVAL 標準は、いくつ

かのドキュメント形式を定義します。これらはそれぞれ異なる種類の情報を含み、異なる目的に使われま
す。
OVAL ドキュメント形式
OVAL Definitions 形式は、最も一般的な OVAL ファイル形式で、システムスキャンに直接使用されま

す。OVAL De finitions のドキュメントは、ターゲットシステムの望ましい状態を記述します。
153
OVAL Variables 形式は、OVAL De finitions ドキュメントの修正に使用される変数を定義します。

OVAL Variable s ドキュメントは通常、OVAL De finitions ドキュメントと一緒に使われ、ランタイ
ム時にターゲットシステムのセキュリティコンテンツを調整します。
OVAL System Characteristics 形式は、評価対象のシステムについての情報を保持します。OVAL

Sys te m Characte ris tics ドキュメントは通常、実際のシステムの状態と、OVAL De finitions ド
キュメントが定義する期待された状態を比較するために使用されます。
OVAL Results は、最も包括的な OVAL 形式で、システム評価の結果を報告するために使われます。

OVAL Re s ults ドキュメントには通常、評価された OVAL 定義のコピー、バインドされた OVAL 変
数、OVAL システムの特徴、システムの特徴と定義の比較に基づいて計算されたテスト結果が含まれま
す。
OVAL Directives 形式は、特定の詳細を除外または含めることで、OVAL Re s ult ドキュメントの長さ

を調整するために使われます。
OVAL Common Model 形式には、いくつかの他の OVAL スキームに使用される構造体と列挙の定義

が含まれます。これは、OVAL 定義を再利用して、複数のドキュメントでの重複を防ぐために使われま
す。
OVAL De finitions ドキュメントは、設定要件一式で構成されます。各要件

は、definitions、tests、objects、states、および variables の 5 つの基本的なセクションで構成され
ます。de finitions セクション内における要素は、特定の定義を満たすためにどのテストが実行されるかを
記述します。te s t 要素は、obje cts と s tate s をリンクさせます。システム評価中に、ある obje ct 要素
が示す評価システムのリリースが特定の s tate 要素に対応すると、テストが成功したとみなされます。
variable s セクションでは、s tate s セクションからの要素の調整に使用される可能性のある外部の変数を
定義します。これらのセクションに加えて、OVAL De finitions ドキュメントには通常、generator およ
び signature の各セクションも含まれています。generator セクションには、ドキュメントの出所につい
ての情報とそのコンテンツに関連する様々な追加情報が含まれます。
OVAL ドキュメントの基本的セクションからの各要素は、以下の形式の識別子で明確に特定されます。
oval:namespace:type:ID
ここでの namespace は、識別子を定義するネームスペースです。type は、de finitions 要素の場合は

def、te s ts 要素の場合は tst、obje cts 要素の場合は obj、s tate s 要素の場合は ste、variable s 要素
の場合は var になります。ID は、識別子の整数値になります。
例6.2 OVAL Def init io ns ドキュメントの例

<oval_definitions
xmlns:lin-def="http://oval.mitre.org/XMLSchema/oval-definitions-
5#linux"
xmlns:oval="http://oval.mitre.org/XMLSchema/oval-common-5"
xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<generator>
<oval:product_name>vim</oval:product_name>
<oval:schema_version>5.10.1</oval:schema_version>
<oval:timestamp>2012-11-22T15:00:00+01:00</oval:timestamp>
</generator>
<definitions>
<definition class="inventory"
id="oval:org.open-scap.cpe.rhel:def:7"
154
version="1">
<metadata>
<title>Red Hat Enterprise Linux 7</title>
<affected family="unix">
<platform>Red Hat Enterprise Linux 7</platform>
</affected>
<reference ref_id="cpe:/o:redhat:enterprise_linux:7"
source="CPE"/>
<description>
The operating system installed on the system is Red Hat
Enterprise Linux 7
</description>
</metadata>
<criteria>
<criterion comment="Red Hat Enterprise Linux 7 is installed"
test_ref="oval:org.open-scap.cpe.rhel:tst:7"/>
</criteria>
</definition>
</definitions>
<tests>
<lin-def:rpminfo_test check_existence="at_least_one_exists"
id="oval:org.open-scap.cpe.rhel:tst:7"
version="1"
check="at least one"
comment="redhat-release is version 7">
<lin-def:object object_ref="oval:org.open-scap.cpe.redhat-
release:obj:1"/>
<lin-def:state state_ref="oval:org.open-scap.cpe.rhel:ste:7"/>
</lin-def:rpminfo_test>
</tests>
<objects>
<lin-def:rpmverifyfile_object id="oval:org.open-scap.cpe.redhat-
release:obj:1"
version="1">

<lin-def:behaviors nolinkto='true'
nomd5='true'
nosize='true'
nouser='true'
nogroup='true'
nomtime='true'
nomode='true'
nordev='true'
noconfigfiles='true'
noghostfiles='true' />
<lin-def:name operation="pattern match"/>
<lin-def:epoch operation="pattern match"/>
<lin-def:version operation="pattern match"/>
<lin-def:release operation="pattern match"/>
<lin-def:arch operation="pattern match"/>
<lin-def:filepath>/etc/redhat-release</lin-def:filepath>
</lin-def:rpmverifyfile_object>
</objects>
<states>
<lin-def:rpminfo_state id="oval:org.open-scap.cpe.rhel:ste:7"
155
version="1">
<lin-def:name operation="pattern match">^redhat-release</lin-
def:name>
<lin-def:version operation="pattern match">^7[^\d]</lin-
def:version>
</lin-def:rpminfo_state>
</states>
</oval_definitions>
6.2.3. データストリームの形式
SCAP データストリームは、SCAP バージョン 1.2 から使用されているファイル形式で、XCCDF や

OVAL、その他のコンポーネントファイルなど、XCCDF チェックリストで表示されているコンプライアン
スポリシーの定義に使用可能なもののバンドルを表します。また、特定のデータストリームを SCAP コン
ポーネントにしたがってファイルに分割することを可能にするインデックスとカタログも含まれています
データストリームは XML 形式を使用し、これはコンテンツのテーブルで形成されたヘッダーと

<ds:component> 要素の一覧で構成されています。これらの要素にはそれぞれ、XCCDF や OVAL、
CPE などの SCAP コンポーネントが含まれます。データストリームファイルには同じタイプの複数のコン
ポーネントが含まれている場合があり、組織で必要とされるセキュリティポリシーすべてがカバーされま
す。
例6.3 データストリームヘッダーの例
<ds:data-stream-collection
xmlns:ds="http://scap.nist.gov/schema/scap/source/1.2"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:cat="urn:oasis:names:tc:entity:xmlns:xml:catalog"
id="scap_org.open-scap_collection_from_xccdf_ssg-rhel7-xccdf-
1.2.xml"
schematron-version="1.0">
<ds:data-stream id="scap_org.open-scap_datastream_from_xccdf_ssg-
rhel7-xccdf-1.2.xml"
scap-version="1.2" use-case="OTHER">
<ds:dictionaries>
<ds:component-ref id="scap_org.open-scap_cref_output--ssg-rhel7-
cpe-dictionary.xml"
xlink:href="#scap_org.open-scap_comp_output--ssg-rhel7-cpe-
dictionary.xml">
<cat:catalog>
<cat:uri name="ssg-rhel7-cpe-oval.xml"
uri="#scap_org.open-scap_cref_output--ssg-rhel7-cpe-
oval.xml"/>
</cat:catalog>
</ds:component-ref>
</ds:dictionaries>
<ds:checklists>
<ds:component-ref id="scap_org.open-scap_cref_ssg-rhel7-xccdf-
1.2.xml"
xlink:href="#scap_org.open-scap_comp_ssg-rhel7-xccdf-1.2.xml">
<cat:catalog>
<cat:uri name="ssg-rhel7-oval.xml"
156
uri="#scap_org.open-scap_cref_ssg-rhel7-oval.xml"/>
</cat:catalog>
</ds:component-ref>
</ds:checklists>
<ds:checks>
<ds:component-ref id="scap_org.open-scap_cref_ssg-rhel7-oval.xml"
xlink:href="#scap_org.open-scap_comp_ssg-rhel7-oval.xml"/>
cpe-oval.xml"
xlink:href="#scap_org.open-scap_comp_output--ssg-rhel7-cpe-
oval.xml"/>
oval.xml"
xlink:href="#scap_org.open-scap_comp_output--ssg-rhel7-
oval.xml"/>
</ds:checks>
</ds:data-stream>
<ds:component id="scap_org.open-scap_comp_ssg-rhel7-oval.xml"
timestamp="2014-03-14T16:21:59">
<oval_definitions xmlns="http://oval.mitre.org/XMLSchema/oval-
definitions-5"
xmlns:oval="http://oval.mitre.org/XMLSchema/oval-common-5"
xmlns:ind="http://oval.mitre.org/XMLSchema/oval-definitions-
5#independent"
xmlns:unix="http://oval.mitre.org/XMLSchema/oval-definitions-
5#unix"
xmlns:linux="http://oval.mitre.org/XMLSchema/oval-definitions-
5#linux"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://oval.mitre.org/XMLSchema/oval-common-
5
oval-common-schema.xsd
http://oval.mitre.org/XMLSchema/oval-definitions-5
oval-definitions-schema.xsd
http://oval.mitre.org/XMLSchema/oval-definitions-
5#independent
independent-definitions-schema.xsd
http://oval.mitre.org/XMLSchema/oval-definitions-5#unix
unix-definitions-schema.xsd
http://oval.mitre.org/XMLSchema/oval-definitions-5#linux
linux-definitions-schema.xsd">
6.3. SCAP Workbench の使用
SCAP Wo rkbench (scap-workbench) はグラフィカルユーティリティーで、これを使うと単一のロー

カルまたはリモートシステム上で構成スキャンと脆弱性スキャンが実行できます。また、システム修復や、
スキャン評価に基づくレポート生成もできます。o scap コマンドラインユーティリティーと比べる
と、SCAP Wo rkbench には限定的な機能しかないことに注意してください。また、SCAP
Wo rkbench は XCCDF およびデータストリームファイルの形式でしかセキュリティコンテンツを処理
できません。
以下のセクションでは、SCAP Workbe nch をインストール、起動、利用して、システムスキャンや修

復、スキャンのカスタマイズを実行する方法と、これらタスクに関連する例を説明します。
157
6.3.1. SCAP Workbench のインストール
システムに SCAP Wo rkbench をインストールするには、root で以下のコマンドを実行します。
~]# yum install scap-workbench
このコマンドにより、SCAP Workbe nch の正常な機能に必要なすべてのパッケージがインストールされ

ます。これには、それ自体がユーティリティーを提供する scap-workbench パッケージも含まれていま
す。システムに qt および openssh パッケージなどの必要な依存関係がインストールされていれば、それ
らのパッケージは自動的に最新バージョンに更新されることに注意してください。
SCAP Workbe nch を効果的に使い始める前に、システムにいくつかのセキュリティコンテンツをインス

トールもしくはインポートする必要があります。SCAP コンテンツはそれぞれのウェブサイトからダウン
ロードするか、RPM ファイルもしくはパッケージとして指定されている場合は、Yum パッケージマネ
ジャーを使って指定された場所もしくは既知のリポジトリーからインストールすることができます。
たとえば、SCAP Se curity Guide (SSG) パッケージである scap-security-guide のインストールが可

能です。このパッケージには、Linux システム用の現時点で最新かつ精巧なセキュリティポリシーが含ま
れています。システムにこのパッケージを導入する正確な手順を学習するには、SSG proje ct ページを参
システムに scap-security-guide をインストールした後は、特に指定されていなければ、SSG セキュリ

ティコンテンツは /usr/share/xml/scap/ssg/rhel7/ ディレクトリーに格納され、他のセキュリ
ティコンプライアンス作業を進めることができます。
個別のニーズに合致する可能性のある既存の SCAP コンテンツの他のソースが必要な場合は、「その他の

リソース」を参照してください。
6.3.2. SCAP Workbench の稼働
SCAP Wo rkbench ユーティリティーと SCAP コンテンツを正常にインストールできたら、システム上

で SCAP Wo rkbench の使用が可能になります。SCAP Wo rkbench を GNOME Classic デスク
トップ環境から稼働するには、Super キーをおしてアクティビティに入り、scap-workbench と入
力してから Enter を押します。Super キーはキーボードと他のハードウェアによって外観が異なります
が、普通は Windows または Command キーで、通常スペースバーキーの左隣にあります。
ユーティリティーを起動すると、SCAP Workbench ウィンドウが表示されます。SCAP Workbench

ウィンドウはいくつかのインタラクティブ要素で構成されており、システムのスキャン実行前にこれらに慣
れておくとよいでしょう。
Input f ile
このフィールドには、選択されたセキュリティポリシーへの完全パスがあります。Browse ボタ
ンをクリックすると、システム上で当てはまる SCAP コンテンツを検索することができます。
Checklist
このコンボボックスは、選択されたセキュリティポリシーで適用されるチェックリスト名を表示
します。2 つ以上のチェックリストが利用可能な場合は、このボックスをクリックすると特定の
チェックリストが選択できます。
T ailo ring
このコンボボックスは、特定のセキュリティポリシーに使用されるカスタマイズを表示します。
このコンボボックスをクリックして、システム評価に適用されるカスタムルールを選択できま
す。デフォルト値は (no t ailo ring) で、これは使用されているセキュリティポリシーに変更
がないことを意味します。選択されているセキュリティプロファイルに変更を加えた場
合、Save Tailoring をクリックするとこれらの変更を XML ファイルで保存できます。
158
Pro f ile
このコンボボックスには、選択されたセキュリティプロファイル名が表示されます。コンボボッ
クスをクリックすると、XCCDF またはデータストリームファイルからセキュリティプロファイ
ルを選択できます。選択したセキュリティプロファイルのプロパティーを継承する新規プロファ
イルを作成するには、Customize ボタンをクリックします。
T arget
評価対象のシステムがローカルかリモートかを 2 つのラジオボタンから選択します。
Select ed Rules
このフィールドには、セキュリティポリシーの対象となるセキュリティルールが一覧表示されま
す。特定のセキュリティルール上にカーソルを持っていくとそのルールについての詳細情報が表
示されます。
Save co nt ent
このメニューを使うと、Input f ile および T ailo ring フィールドで選択された SCAP ファ

イルが選択されたディレクトリーに、または RPM パッケージとして保存できます。
ステータスバー
このグラフィカルバーは、実行中の操作のステータスを表示します。
Online remediat io n
このチェックボックスにチェックを入れると、システム評価中に修復機能が有効になります。
チェックが入っていると、SCAP Workbe nch はポリシーで定義された状態にマッチしないシス
テム設定の修正を試行します。
Scan
このボタンを押すと、指定されたシステムの評価が開始されます。
159
図6.1 SCAP Wo rkbench のウィンドウ
6.3.3. システムのスキャン
SCAP Wo rkbench の主な機能は、特定の XCCDF またはデータストリームファイルにしたがって、選

択されたシステム上でセキュリティスキャンを実行することです。選択されたセキュリティポリシーに対
してシステムを評価するには、以下のステップにしたがいます。
1. Browse ボタンをクリックしてセキュリティポリシーを選択し、その XCCDF またはデータスト

リームファイルを検索します。
警告
セキュリティポリシーを選択すると、保存されていない以前の tailoring 変更は失われま

す。失われたオプションを再度適用するには、利用可能なプロファイルと tailoring コンテ
ンツを再度選択する必要があります。新規のセキュリティポリシーでは、以前のカスタマイ
ズが適用できない場合があることに注意してください。
2. 選択した SCAP ファイルが 2 つ以上のチェックリストを提供するデータストリームファイルの場

合、Checklist コンボボックスをクリックすると特定のチェックリストが選択できます。
160
警告
チェックリストを変更すると、別のプロファイルが選択される場合があります。また、新規
チェックリストには、以前のカスタマイズが適用できない場合もあります。
3. 自分のニーズにカスタマイズされたセキュリティコンテンツのある事前に用意されたファイルを使
用するには、T ailo ring コンボボックスでそのファイルをクリックして読み込みます。また、利
用可能なセキュリティプロファイルを変更してカスタマイズした tailoring ファイルを作成するこ
ともできます。詳細は、「セキュリティプロファイルのカスタマイズ」を参照してください。
a. 現行のシステム評価にカスタマイズを使用しない場合は、(no tailoring) オプション

を選択します。以前にカスタマイズが選択されていなければ、これがデフォルトオプショ
ンになります。
b. 現行のシステム評価に使用する特定の tailoring ファイルを検索するには、(open

tailoring file...) オプションを選択します。
c. これまでに tailoring ファイルを使用したことがある場合は、SCAP Wo rkbench はこ

のファイルを保存していてリストに追加します。これにより、同一スキャンの反復適用が
簡素化されます。
4. Pro f ile コンボボックスをクリックして適切な選択セキュリティプロファイルを選択します。
a. 選択したプロファイルを修正するには、Customize ボタンをクリックします。プロファ
イルのカスタマイズに関する詳細は、「セキュリティプロファイルのカスタマイズ」を参
5. Target ラジオボタンのいずれかを選択して、スキャンするマシンをローカルかリモートから選択
します。
a. リモートシステムを選択した場合は、以下の例のようにユーザー名、ホスト名、ポート情報
を入力して指定します。
図6.2 リモートシステムの指定
6. Online remediation チェックボックスを選択すると、システム設定の自動修正が有効になり

ます。このオプションが有効になっていると、システムスキャン中に関連チェックが失敗した場
合、SCAP Wo rkbench はポリシーが適用するセキュリティルールにしたがってシステム設定
を変更するよう試みます。
警告
修正オプションが有効な状態でのシステム評価は、慎重に行わないとシステムが機能不全に
陥る場合があります。
7. Scan ボタンをクリックしてシステムスキャンを開始します。
6.3.4. セキュリティプロファイルのカスタマイズ
161
6.3.4. セキュリティプロファイルのカスタマイズ
ご使用のセキュリティポリシーに適応したセキュリティプロファイルを選択した後で Customize ボタン

をクリックすると、これをさらに調節することができます。Tailoring ウィンドウが開いて、現在選択され
ている XCCDF プロファイルをその XCCDF ファイルを実際に変更することなく修正できます。
図6.3 セキュリティプロファイルのカスタマイズ
Tailoring ウィンドウには、選択されたセキュリティプロファイルに関連する XCCDF 要素がすべて含

まれており、各要素の詳細情報と機能も表示されます。このウィンドウのメインフィールドで各要素の
チェックボックスにチェックを入れたり外したりすることで、これらの要素を有効または無効にすることが
できます。Tailoring は、元に戻すとやり直す機能もサポートしており、ウィンドウ左上の矢印アイコ
ンをクリックすることでこれらの機能を実行できます。
プロファイルのカスタマイズを終えたら、Finish Tailoring ボタンをクリックして変更を確認しま

す。これで変更がメモリーに記憶されますが、SCAP Wo rkbench を終了したり、新規 SCAP コンテン
ツの選択や別の tailoring オプションを選択するなどの特定の変更が行われると、変更は保持されません。
変更を保存するには、SCAP Workbench ウィンドウの Save Tailoring ボタンをクリックします。こ
うすることで、セキュリティプロファイルの変更が選択されたディレクトリーに XCCDF tailoring ファイ
ルとして保存できます。この tailoring ファイルは他のプロファイルでも選択可能であることに注意してく
ださい。
6.3.5. SCAP コンテンツの保存
SCAP Wo rkbench では、システム評価に使用された SCAP コンテンツの保存も可能になっています。

tailoring ファイルを別個に保存するか (「セキュリティプロファイルのカスタマイズ」を参照) または
Save content コンボボックスをクリックして、Save into a directory または Save as RPM
オプションを選択するとすべてのセキュリティコンテンツを一度に保存できます。
162
Save into a directory オプションを選択すると、SCAP Wo rkbench は XCCDF もしくはデー

タストリームファイルと tailoring ファイルの両方を指定された場所に保存します。これはバックアップと
して便利な方法です。
Save as RPM オプションを選択すると、SCAP Wo rkbench に XCCDF もしくはデータストリーム

ファイルと tailoring ファイルを含む RPM パッケージを作成するよう指示できます。これは、リモートで
スキャンができないシステムに希望するセキュリティコンテンツを配布する場合やコンテンツをさらに処理
するために配布する際に便利です。
図6.4 現行 SCAP コンテンツを RPM パッケージとして保存
6.3.6. スキャン結果の表示とスキャンレポートの生成
システムスキャンが終了すると、Scan ボタンの代わりに Clear および Report の 2 つのボタンが表示

されます。
警告
Clear ボタンをクリックすると、スキャン結果が恒久的に削除されます。
Report ボタンをクリックすると Evaluation Report ウィンドウが開かれ、スキャン結果を見たりさ

らに処理することができます。このウィンドウには Save コンボボックスと Open in Browser および
Close の 2 つのボタンがあります。
163
スキャン結果を XCCDF、ARF、または HTML ファイルの形式で保存するには、Save コンボボックスを

クリックします。ヒューマンリーダブルな形式でスキャン結果を生成するには、HTML Report オプショ
ンを選択します。さらに自動処理を施したい場合は、XCCDF および ARF (データストリーム) 形式が適し
ています。これら 3 つのオプションは、何度でも選択できます。
スキャン結果を保存せずにすぐに確認したい場合は、Open in Browser ボタンをクリックします。デ

フォルトのウェブブラウザーで HTML の一時ファイル形式でスキャン結果が表示されます。
6.4. oscap の使用
o scap コマンドラインユーティリティーを使うと、ローカルシステムのスキャン、セキュリティコンプ
ライアンスコンテンツの確認、これらのスキャンおよび評価を基にしたレポートとガイドの生成ができま
す。このユーティリティーは Ope nSCAP ライブラリーへのフロントエンドとしてのサービスを提供し、
その機能を処理する SCAP コンテンツのタイプに基づいてモジュール (サブコマンド) にグループ化しま
す。
以下のセクションでは o scap のインストール方法と最も一般的な操作の実行方法を説明します。これら

のタスクの説明に例を用いています。特定のサブコマンドの詳細を確認するには、o scap コマンドの --
help オプションを使用してください。
oscap [options] module module_operation

[module_operation_options_and_arguments] --help
ここでの module は、処理されている SCAP コンテンツのタイプになります。ま

た、module_operation は、SCAP コンテンツにおける特定の操作のサブコマンドになります。
例6.4 特定の o scap 操作に関するヘルプ
~]$ oscap ds sds-split --help

oscap -> ds -> sds-split
Split given SourceDataStream into separate files
Usage: oscap [options] ds sds-split [options] SDS TARGET_DIRECTORY
SDS - Source data stream that will be split into multiple files.
TARGET_DIRECTORY - Directory of the resulting files.
Options:
--datastream-id <id> - ID of the datastream in the
collection to use.
--xccdf-id <id> - ID of XCCDF in the datastream that
should be evaluated.
o scap の全機能を学習し、オプションの完全一覧を確認するには、oscap(8) man ページを参照してく

ださい。
6.4.1. oscap のインストール
システムに o scap をインストールするには、root で以下のコマンドを実行します。
~]# yum install openscap-utils
164
このコマンドで、o scap の正常な機能に必要なパッケージがすべてインストールできます。これには、そ

れ自体がユーティリティーを提供する openscap パッケージも含まれています。オリジナルのセキュリ
ティコンテンツを書き込むには、Script Che ck Engine (SCE) を提供する openscap-engine-sce パッ
ケージもインストールする必要があります。この SCE は SCAP プロトコルの拡張機能で、これを使うと
コンテンツ作者は Bas h、Python、Ruby などのスクリプト言語を使ってセキュリティコンテンツを書き
込むことができるようになります。openscap-engine-sce パッケージは Optional チャンネルからのみ
入手可能であることに注意してください。Enabling Supple me ntary and Optional Re pos itorie s を参
オプションとして o scap のインストール後に、o scap のバージョンの機能やこのバージョンがサポー

トする仕様、特定の o scap ファイルの保存場所、使用可能な SCAP オブジェクトの種類、他の役立つ情
報をチェックできます。これらの情報を表示するには、以下のコマンドを実行します。
~]$ oscap -V
OpenSCAP command line tool (oscap) 1.0.4
Copyright 2009--2014 Red Hat Inc., Durham, North Carolina.
==== Supported specifications ====

XCCDF Version: 1.2
OVAL Version: 5.10.1
CPE Version: 2.3
CVSS Version: 2.0
CVE Version: 2.0
Asset Identification Version: 1.1
Asset Reporting Format Version: 1.1
==== Capabilities added by auto-loaded plugins ====

SCE Version: 1.0 (from libopenscap_sce.so.8)
==== Paths ====

Schema files: /usr/share/openscap/schemas
Schematron files: /usr/share/openscap/xsl
Default CPE files: /usr/share/openscap/cpe
Probes: /usr/libexec/openscap
==== Inbuilt CPE names ====

Red Hat Enterprise Linux - cpe:/o:redhat:enterprise_linux
Red Hat Enterprise Linux 5 - cpe:/o:redhat:enterprise_linux:5
Fedora 16 - cpe:/o:fedoraproject:fedora:16
Red Hat Enterprise Linux Optional Productivity Applications -
cpe:/a:redhat:rhel_productivity
Red Hat Enterprise Linux Optional Productivity Applications 5 -
cpe:/a:redhat:rhel_productivity:5
==== Supported OVAL objects and associated OpenSCAP probes ====

system_info probe_system_info
family probe_family
filehash probe_filehash
environmentvariable probe_environmentvariable
165
textfilecontent54 probe_textfilecontent54
textfilecontent probe_textfilecontent
variable probe_variable
xmlfilecontent probe_xmlfilecontent
environmentvariable58 probe_environmentvariable58
filehash58 probe_filehash58
inetlisteningservers probe_inetlisteningservers
rpminfo probe_rpminfo
partition probe_partition
iflisteners probe_iflisteners
rpmverify probe_rpmverify
rpmverifyfile probe_rpmverifyfile
rpmverifypackage probe_rpmverifypackage
selinuxboolean probe_selinuxboolean
selinuxsecuritycontext probe_selinuxsecuritycontext
file probe_file
interface probe_interface
password probe_password
process probe_process
runlevel probe_runlevel
shadow probe_shadow
uname probe_uname
xinetd probe_xinetd
sysctl probe_sysctl
process58 probe_process58
fileextendedattribute probe_fileextendedattribute
routingtable probe_routingtable
o scap ユーティリティーを効果的に使い始める前に、システムにいくつかのセキュリティコンテンツをイ
ンストールもしくはインポートする必要があります。SCAP コンテンツはそれぞれのウェブサイトからダウ
ンロードするか、RPM ファイルもしくはパッケージとして指定されている場合は、Yum パッケージマネ
ジャーを使って指定された場所もしくは既知のリポジトリーからインストールすることができます。
たとえば、SCAP Se curity Guide (SSG) パッケージである scap-security-guide のインストールが可

能です。このパッケージには、Linux システム用の最新のセキュリティポリシーが含まれています。シス
テムにこのパッケージを導入する正確な手順を学習するには、SSG proje ct ページを参照してください。
システムに scap-security-guide をインストールした後は、特に指定されていなければ、SSG セキュリ

ティコンテンツは /usr/share/xml/scap/ssg/rhel7/ ディレクトリーに格納され、他のセキュリ
ティコンプライアンス作業を進めることができます。
個別のニーズに合致する可能性のある既存の SCAP コンテンツの他のソースが必要な場合は、「その他の

リソース」を参照してください。
システムに SCAP コンテンツをインストールした後に、コンテンツへのファイルパスを提供すると

o scap はコンテンツを処理できます。o scap ユーティリティーは SCAP バージョン 1.2 をサポートし
ており、SCAP バージョン 1.1 および 1.0 とも後方互換性があるので、特別な要件を必要とせずに以前の
バージョンの SCAP コンテンツを処理できます。
6.4.2. SCAP コンテンツの表示
SCAP 標準は、数多くのファイル形式を定義します。o scap ユーティリティーは、多くの形式に適合す

るファイルを処理したり、作成したりすることができます。SCAP コンテンツの特定ファイルをさらに処
理するには、そのファイルタイプでの o scap の使い方を理解する必要があります。特定のファイルの使
い方が分からない場合は、ファイルを開いて読んでみるか、o scap の info モジュールを使うことがで
きます。これはファイルを解析し、ヒューマンリーダブルな形式で関連情報を抽出します。
166
以下のコマンドを実行すると、SCAP ドキュメントの内部構造を調べることができます。また、ドキュメ
ントタイプ、仕様バージョン、ドキュメントのステータス、ドキュメントの公開日、ドキュメントがファ
イルシステムにコピーされた日付などの便利な情報が表示されます。
oscap info file
ここでの file は、調べているセキュリティコンテンツファイルへの完全パスになります。以下の例で

oscap info コマンドの使用方法を示します。
例6.5 SCAP コンテンツについて情報を表示する
~]$ oscap info /usr/share/xml/scap/ssg/rhel7/ssg-rhel7-ds.xmal

Document type: Source Data Stream
Imported: 2014-03-14T12:22:01
Stream: scap_org.open-scap_datastream_from_xccdf_ssg-rhel7-xccdf-
1.2.xml
Generated: (null)
Version: 1.2
Checklists:
Ref-Id: scap_org.open-scap_cref_ssg-rhel7-xccdf-1.2.xml
Profiles:
xccdf_org.ssgproject.content_profile_test
xccdf_org.ssgproject.content_profile_rht-ccp
xccdf_org.ssgproject.content_profile_common
xccdf_org.ssgproject.content_profile_stig-
rhel7-server-upstream
Referenced check files:
ssg-rhel7-oval.xml
system:
http://oval.mitre.org/XMLSchema/oval-definitions-5
Checks:
Ref-Id: scap_org.open-scap_cref_ssg-rhel7-oval.xml
Ref-Id: scap_org.open-scap_cref_output--ssg-rhel7-cpe-oval.xml
Ref-Id: scap_org.open-scap_cref_output--ssg-rhel7-oval.xml
Dictionaries:
Ref-Id: scap_org.open-scap_cref_output--ssg-rhel7-cpe-
dictionary.xml
6.4.3. システムのスキャン
o scap の最も重要な機能は、ローカルシステムの設定および脆弱性スキャンを実行することです。以下は
コマンドの一般的な構文になります。
oscap [options] module eval [module_operation_options_and_arguments]
o scap ユーティリティーでは、XCCDF (e Xte ns ible Configuration Che cklis t De s cription Format)

ベンチマークと OVAL (Ope n Vulne rability and As s e s s me nt Language ) 定義の両方で表示される
SCAP コンテンツに対してシステムのスキャンを行うことができます。セキュリティポリシーは単一の
OVAL または XCCDF ファイルの場合もあれば、複数の別個の XML ファイルの場合もあります。後者の
167
場合は、各ファイルが異なるコンポーネントを表します (XCCDF、OVAL、CPE、CVE、その他)。スキャ
ン結果は、標準出力と XML ファイルの両方にプリントすることができます。この結果のファイルは
o scap でさらに処理され、ヒューマンリーダブル形式のレポートを生成することができます。以下は、こ
のコマンドの最も一般的な使用例になります。
例6.6 SSG OVAL 定義を使用したシステムのスキャン
すべての定義を評価しながら SSG OVAL 定義ファイルに対してシステムのスキャンを実行するには、

以下のコマンドを実行します。
~]$ oscap oval eval --results scan-oval-results.xml

/usr/share/xml/scap/ssg/rhel7/ssg-rhel7-ds.xml
スキャン結果は、scan-oval-results.xml ファイルとして現在のディレクトリーに保存されます。
例6.7 SSG OVAL 定義を使用したシステムのスキャン
SSG データストリームファイルで表されるセキュリティポリシーから特定の OVAL 定義を評価するに

は、以下のコマンドを実行します。
~]$ oscap oval eval --id oval:ssg:def:100 --results scan-oval-

results.xml /usr/share/xml/scap/ssg/rhel7/ssg-rhel7-ds.xml
スキャン結果は、scan-oval-results.xml ファイルとして現在のディレクトリーに保存されます。
例6.8 SSG XCCDF ベンチマークを使用したシステムのスキャン
システム上の xccdf_org.ssgproject.content_profile_rht-ccp プロファイルの SSG

XCCDF ベンチマークを実行するには、以下のコマンドを実行します。
~]$ oscap xccdf eval --profile

xccdf_org.ssgproject.content_profile_rht-ccp --results scan-xccdf-
results.xml scan-xccdf-results.xml /usr/share/xml/scap/ssg/rhel7/ssg-
rhel7-ds.xml
スキャン結果は、scan-xccdf-results.xml ファイルとして現在のディレクトリーに保存されま
す。
注記
--profile コマンドラインの引数は、特定の XCCDF またはデータストリームファイルからセ

キュリティプロファイルを選択します。利用可能なプロファイルの一覧は、oscap info コマ
ンドを実行すると確認できます。--profile コマンドライン引数が省略されると、SCAP 標準
で必要とされるデフォルトの XCCDF プロファイルが使用されます。デフォルトの XCCDF プロ
ファイルは適切なセキュリティポリシーである場合もありますが、そうでない場合もあることに
注意してください。
6.4.4. レポートおよびガイドの生成
168
o scap のもうひとつの便利な機能は、ヒューマンリーダブルな形式で SCAP コンテンツを生成すること

です。o scap ユーティリティーを使うと、XML ファイルを HTML またはプレーンテキスト形式に変換で
きます。この機能は、セキュリティガイドやチェックリストの生成に使用できます。これらは、セキュア
なシステム設定のガイドになるとともに、情報ソースの役割も果たします。システムスキャンの結果も、読
みやすい結果レポートに変換することができます。一般的なコマンド構文は以下のようになります。
oscap module generate sub-module [specific_module/sub-

module_options_and_arguments] file
ここでの module は xccdf または oval に、sub-module は生成されたドキュメントのタイプに、file

は XCCDF または OVAL ファイルになります。
以下でこのコマンドの最も一般的な使用例を示します。
例6.9 チェックリスト付きガイドの生成
チェックリスト付きの SSG ガイドを xccdf_org.ssgproject.content_profile_rht-ccp プ

ロファイル用に作成するには、以下のコマンドを実行します。
~]$ oscap xccdf generate guide --profile

xccdf_org.ssgproject.content_profile_rht-ccp
/usr/share/xml/scap/ssg/rhel7/ssg-rhel7-ds.xml > ssg-guide-
checklist.html
ガイドは、ssg-guide-checklist.html ファイルとして現在のディレクトリーに保存されます。
例6.10 SSG OVAL スキャン結果をレポートに変換する
SSG OVAL スキャンの結果を HTML ファイルに変換するには、以下のコマンドを実行します。
~]$ oscap oval generate report scan-oval-results.xml > ssg-scan-oval-

report.html
結果のレポートは ssg-scan-oval-report.html ファイルとして現在のディレクトリーに保存され

ます。この例では、scan-oval-results.xml ファイルが保存されている場所からこのコマンドが実
行されることを想定しています。それ以外の場合は、スキャン結果を含んでいるファイルの完全修飾パ
スを指定する必要があります。
例6.11 SSG XCCDF スキャン結果をレポートに変換する
SSG XCCDF スキャンの結果を HTML ファイルに変換するには、以下のコマンドを実行します。
~]$ oscap xccdf generate report scan-xccdf-results.xml > scan-xccdf-

report.html
結果レポートは ssg-scan-xccdf-report.html ファイルとして現在のディレクトリーに保存され

ます。別の方法では、--report コマンドライン引数を使用すると、スキャン時にこのレポートが生成
できます。
169
~]$ oscap xccdf eval --profile

xccdf_org.ssgproject.content_profile_rht-ccp --results scan-xccdf-
results.xml --report scan-xccdf-report.html
6.4.5. SCAP コンテンツの検証
システム上でセキュリティポリシーを使い始める前に、ポリシーを検証してポリシー内の構文エラーやセマ
ンティックエラーを避けるようにしてください。o scap ユーティリティーを使うと、SCAP XML スキー
マに対してセキュリティコンテンツを検証することができます。検証結果は、標準エラーストリーム
(s tde rr) にプリントされます。このような検証コマンドの一般的な構文は以下のようになります。
oscap module validate [module_options_and_arguments] file
ここでの file は、検証されているファイルへの完全パスになります。唯一の例外はデータストリームモ

ジュール (ds ) で、これは validate ではなく sds-validate 演算を使用します。以下の例で示されて
いるように、特定のデータストリーム内の SCAP コンポーネントは自動的に検証され、各コンポーネント
は別個に指定されないことに注意してください。
~]$ oscap ds sds-validate /usr/share/xml/scap/ssg/rhel7/ssg-rhel7-ds.xml
OVAL 仕様のような特定の SCAP コンテンツの場合、スキマトロン検証も実行できます。スキマトロン検

証は標準の検証よりも遅いものの、より深い分析を提供するのでより多くのエラーを検出できます。以下の
SSG 例では、このコマンドの通常の使用方法を示しています。
~]$ oscap oval validate --schematron /usr/share/xml/scap/ssg/rhel7/ssg-

rhel7-ds.xml
6.5. Red Hat Sat ellit e での OpenSCAP の使用
複数の Re d Hat Ente rpris e Linux システムを稼働している際には、すべてのシステムがセキュリティポ

リシーにしたがっており、リモートの 1 カ所からスキャンと評価を実行することが重要になります。これ
は、Sate llite クライアントに spacewalk-oscap パッケージがインストールされている Re d Hat
Sate llite 5.5 以降を使用することで達成できます。このパッケージは、Red Hat Net wo rk T o o ls
チャンネルから入手できます。How to e nable /dis able a re pos itory us ing Re d Hat Subs cription-
Manage r? を参照してください。
このソリューションは、2 つの方法でのセキュリティコンプライアンススキャンの実行、表示、およびス
キャン結果のさらなる処理をサポートしています。OpenSCAP Satellite Web Interface を使うか
Satellite API からコマンドとスクリプトを実行することができます。このソリューションのセキュリ
ティコンプライアンス、要件、機能に関する詳細情報は、Re d Hat Sate llite 5.6 ユーザーガイドを参照
6.6. 実用的な使用例
本セクションでは、Re d Hat 製品用に提供されている特定のセキュリティコンテンツの実用的な使用例を

紹介します。
6.6.1. Red Hat 製品のセキュリティ脆弱性の監査
170
Re d Hat は自社製品用に継続的に OVAL 定義を提供しています。これらの定義により、インストール済み

ソフトウェアにおける脆弱性の完全自動化された監査が可能になります。このプロジェクトに関する詳細情
報は、http://www.re dhat.com/s e curity/data/me trics / を参照してください。これらの定義をダウン
ロードするには、以下のコマンドを実行します。
~]$ wget http://www.redhat.com/security/data/oval/com.redhat.rhsa-

all.xml
Re d Hat Sate llite 5 のユーザーには、パッチ定義の XCCDF の部分が便利かもしれません。これらの定

義をダウンロードするには、以下のコマンドを実行します。
~]$ wget http://www.redhat.com/security/data/metrics/com.redhat.rhsa-

all.xccdf.xml
システムにインストール済みのソフトウェアに関するセキュリティ脆弱性を監査するには、以下のコマンド
~]$ oscap oval eval --results rhsa-results-oval.xml --report oval-

report.html com.redhat.rhsa-all.xml
o scap ユーティリティーは、National Vulne rability Databas e にリンクしている CVE に

Re d Hat セキュリティアドバイザリーをマッピングします。そして、どのセキュリティアドバイザリーが
適用されていないかを報告します。
注記
これらの OVAL 定義は、Re d Hat がリリースしているソフトウェアや更新のみをカバーしているこ

とに注意してください。サードパーティーのソフトウェアのパッチステータスを検出するには、追
加の定義を提供する必要があります。
6.6.2. SCAP セキュリティガイドを使ったシステム設定の監査
SCAP Se curity Guide (SSG) プロジェクトのパッケージである scap-security-guide には、Linux シ

ステム用の最新のセキュリティポリシー一式が含まれています。ご使用のシステムにこのパッケージを導入
する方法については、SSG proje ct ページを参照してください。scap-security-guide の一部は、
Re d Hat Ente rpris e Linux 7 設定のガイドにもなっています。scap-security-guide で利用可能なセ
キュリティコンテンツを確認するには、oscap info モジュールを使用します。
~]$ oscap info /usr/share/xml/scap/ssg/rhel7/ssg-rhel7-ds.xml
このコマンドの出力は SSG ドキュメントの概要で、利用可能な設定プロファイルが含まれています。ご使

用のシステム設定を監査するには、適切なプロファイルを選択して適切な評価コマンドを実行します。たと
えば、以下のコマンドは、Re d Hat Ce rtifie d Cloud Provide rs 用のドラフト SCAP プロファイルに対
し特定のシステムを評価するために使われます。
~]$ oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_rht-

ccp --results ssg-rhel7-xccdf-result.xml --report ssg-rhel7-report.html
171
様々なセキュリティコンプライアンスの分野に関する詳細情報は、以下のリソースを参照してください。
oscap(8) — o scap コマンドラインユーティリティーの man ページでは、利用可能なオプション全

一覧とその使用方法が説明されています。
scap-workbench(8) — SCAP Workbench アプリケーションの man ページでは、このアプリケー

ションの基本的情報と SCAP コンテンツの潜在的ソースへのリンクを提供しています。
Guide to the Se cure Configuration of Re d Hat Ente rpris e Linux 7 —

/usr/share/doc/scap-security-guide-0.1.5/ ディレクトリーにある HTML ドキュメント
です。XCCDF チェックリストという形式でシステムのセキュリティ設定の詳細なガイドを提供してい
ます。
The Ope nSCAP proje ct page — Ope nSCAP プロジェクトのホームページでは、o scap ユー

ティリティーと SCAP に関連する他のコンポーネントおよびプロジェクトの詳細情報が提供されてい
ます。
The SCAP Workbe nch proje ct page — SCAP Workbe nch プロジェクトのホームページで
は、scap-wo rkbench アプリケーションの詳細情報が提供されています。
The SCAP Se curity Guide (SSG) proje ct page — SSG プロジェクトのホームページでは、Re d

Hat Ente rpris e Linux 向けの最新セキュリティコンテンツが提供されています。
National Ins titute of Standards and Te chnology (NIST) SCAP page — このページには SCAP
関連の大量の資料があります。SCAP の出版物や仕様、SCAP 検出プログラムもあります。
National Vulne rability Databas e (NVD) — このページは、SCAP コンテンツおよび他の SCAP 標

準ベースの脆弱性管理データの最大のリポジトリーです。
Re d Hat OVAL conte nt re pos itory — Re d Hat Ente rpris e Linux システム向けの OVAL 定義を
含むリポジトリーです。
MITRE CVE — これは、MITRE corporationが提供する既知のセキュリティ脆弱性に関するデータベー

スです。
MITRE OVAL — このページは、MITRE corporation が提供する OVAL 関連のプロジェクトを紹介し

ています。OVAL 関連の他の情報に加え、OVAL 言語の最新バージョンや 2 万 2 千を越える OVAL 定
義を数える巨大な OVAL コンテンツのリポジトリーがあります。
Re d Hat Sate llite 5.6 ユーザーガイド — このガイドでは、Ope nSCAP を使って複数のシステム上

でシステムセキュリティを維持する方法が説明されています。
172
⁠第7章米連邦政府の標準および規制
第7章米連邦政府の標準および規制
どの組織も、米連邦政府または業界のセキュリティ仕様、標準および規制の遵守に取り組むことで一定のセ
キュリティレベルを維持することができます。本章では、これらの標準および規制のいくつかについて説明
します。
7.1. 連邦情報処理標準 (FIPS: Federal Informat ion Processing

St andard)
連邦情報処理標準 (FIPS) のパブリケーションである 140-2 は、暗号モジュールの品質を検証するために

連邦政府と業界の作業部会によって開発されたコンピューターセキュリティ標準です。FIPS のパブリケー
ション (140-2 を含む) は以下の URL にあります。http://cs rc.nis t.gov/publications /Pubs FIPS.html。
本書の作成時点で 140-3 のパブリケーションは草稿なので、これが完成版の標準ではない可能性があるこ
とに注意してください。FIPS 標準は、さまざまな業界や暗号モジュールの各種の実装およびさまざな組織
規模や要件に対応すべく、4 つのセキュリティレベルを規定しています。これらのレベルについて以下で説
明します。
レベル 1 — セキュリティレベル 1 はセキュリティの最も低いレベルです。暗号モジュールについての

基本的なセキュリティ要件が規定されます (例: 1 つ以上の承認済みのアルゴリズムか、または承認済み
のセキュリティ機能を使用するものとする)。セキュリティレベル 1 の暗号モジュールでは、実稼働レ
ベルのコンポーネントの基本要件を超える具体的な物理セキュリティのメカニズムは必要とされませ
ん。セキュリティレベル 1 の暗号モジュールの例には、パソコン (PC) 用の暗号化ボードがあります。
レベル 2 — セキュリティレベル 2 は、セキュリティレベル 1 の暗号モジュールについての物理セ

キュリティのメカニズムを強化します。レベル 2 では、耐タンパー性のあるコーティングまたはシール
を使用することや、モジュールの除去可能なカバーやドアにこじあけ耐性のある錠をかけることを始め
とする物理的改ざんの痕跡を残すという要件が加わります。耐タンパー性のあるコーティングやシール
は暗号モジュールに付けられ、コーティングやシールを破らない限り、モジュール内のテキスト形式の
暗号鍵とクリティカルセキュリティパラメーター (CSP) に物理的にアクセスできないようにします。
許可されない物理的なアクセスからモジュールを保護するために、耐テンパー性のあるシールまたはこ
じあけ耐性のある錠をカバーまたはドアに取り付けます。
レベル 3 — セキュリティレベル 2 で要求されるテンパー証跡を残す物理セキュリティのメカニズムに

加えて、セキュリティレベル 3 は、暗号モジュール内で保持される CSP に侵入者がアクセスすること
を防ぐことを目的とします。セキュリティレベル 3 で要求される物理セキュリティのメカニズムは、物
理的なアクセスの試行や暗号モジュールの使用または変更を高い確率で検出し、これらに対応すること
を意図しています。この物理セキュリティのメカニズムには、頑丈な囲い (e nclos ure ) の使用、およ
び暗号モジュールの除去可能なカバー/ドアが開かれたときにテキスト形式の CSP をすべてゼロ化する
タンパー検出/タンパー応答を持つ回路の使用が含まれることがあります。
レベル 4 — セキュリティレベル 4 は、この標準で定義される最も高いセキュリティレベルです。この

セキュリティレベルでは、すべての許可されていない物理的なアクセスを検出し、これに応答すること
を目的として、物理セキュリティのメカニズムが暗号モジュール全体に保護用の遮蔽 (e nve lope ) を提
供します。あらゆる方向からの暗号モジュールの囲いへの侵入が非常に高い確率で検出され、その結
果、テキスト形式のすべての CSP が即座にゼロ化されます。セキュリティレベル 4 の暗号モジュール
は、物理的に保護されていない環境下での使用に役立ちます。
FIPS 標準の上記の各レベルや他の仕様についての詳細は、正規の FIPS 140-2 標準

(http://cs rc.nis t.gov/publications /fips /fips 140-2/fips 1402.pdf を参照してください。
7.1.1. FIPS モードの有効化
Re d Hat Ente rpris e Linux を連邦情報処理標準 (FIPS) パブリケーション 140-2 準拠とするには、いく

つかの変更を加えて認定済み暗号モジュールを使用することが必要です。お使いのシステム (カーネルおよ
びユーザースペース) を FIPS モードに切り替えるには、以下のステップを実行します。
173
1. モジュール内の整合性検証の適切な実行にあたり、pre link を無効にする必要がありま

す。/etc/sysconfig/prelink 設定ファイルで PRELINKING=no と設定してください。既存
の事前リンク (pre linking) がある場合は、 prelink -u -a コマンドを使用してすべてのシステ
ムファイル上でこれを元に戻す必要があります。
2. 次に、dracut-fips パッケージをインストールします。
~]# yum install dracut-fips
3. initramfs ファイルを再作成します。
~]# dracut -f
警告
この操作により、既存の initramfs ファイルが上書きされます。
4. /etc/default/grub ファイルの GRUB_CMDLINE_LINUX ke y に以下のオプションを追加し

てから grub.cfg ファイルを再構成して、grub.cfg 内の現行カーネルのカーネルコマンドライ
ンを修正します。
fips=1
/etc/default/grub への変更は、以下のように grub.cfg ファイルの再構築を必要としま

す。
BIOS ベースのマシンでは、root で以下のコマンド発行します。
~]# grub2-mkconfig -o /boot/grub2/grub.cfg
UEFI ベースのマシンでは、root で以下のコマンド発行します。
~]# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
174
⁠第7章米連邦政府の標準および規制
注記
/boot または /boot/efi が別のパーティションに格納されている場合、カーネルパラ

メーターの boot=</boot または /boot/efi のパーティション > をカーネルコマン
ドラインに追加する必要があります。df /boot または df /boot/efi のコマンドでそ
れぞれのパーティションを特定することができます。例を示します。
~]$ df /boot
Filesystem 1K-blocks Used Available Use%
Mounted on
/dev/sda1 495844 53780 416464 12% /boot
ブート間でデバイス名が変更されても boot= 設定オプションが機能するようにするには、

以下のコマンドを実行してパーティションの UUID (Unive rs ally Unique Ide ntifie r) を
特定します。
~]$ blkid /dev/sda1

/dev/sda1: UUID="05c000f1-f899-467b-a4d9-d5ca4424c797"
TYPE="ext4"
上記の例では、以下の文字列をカーネルコマンドラインに追加する必要があります。
boot=UUID=05c000f1-f899-467b-a4d9-d5ca4424c797
5. システムを再起動します。
FIPS へのより厳格なコンプライアンスが求められる場合は、システムのインストール時に fips=1 カーネ

ルオプションをカーネルコマンドラインに追加する必要があります。これにより、FIPS で承認されている
アルゴリズムを使って鍵を生成し、継続的なモニタリングテストを実施することができます。また、ユー
ザーは、インストールプロセス時にマウスを動かすか、またはマウスを使用できない場合は多数のキー入力
を行うことにより、システムに十分なエントロピーを確保する必要があります。推奨されるキー入力の回数
は 256 回以上です。255 回以下の場合は、一意でない鍵が生成される可能性があります。
7.2. NISPOM (Nat ional Indust rial Securit y Program Operat ing
Manual)
National Indus trial Se curity Program (NISP) の 1 つの構成要素である NISPOM (DoD 5220.22-M
とも呼ばれる) は、すべての政府指定業者向けに、秘密情報 (clas s ifie d information) に関する一連の手
順と要件を規定しています。現行の NISPOM は、2006 年 2 月 28 日付けのもので、2013 年 3 月 28
日からのメジャーな変更が組み込まれています。NISPOM 文書は以下の URL からダウンロードできま
す。http://www.nis pom.org/NISPOM-download.html
7.3. PCI DSS (Payment Card Indust ry Dat a Securit y

St andard)
(ソース: https ://www.pcis e curitys tandards .org/about/inde x.s html) PCI Securit y St andards
Co uncil は、20 0 6 年に発足したグローバル規模の開かれた協議会であり、データセキュリティスタン
ダード (DSS: Dat a Securit y St andard) を含む PCI セキュリティ基準の開発、管理、教育および
普及に関する討議の場を提供しています。
175
PCI DSS 標準は、https ://www.pcis e curitys tandards .org/s e curity_s tandards /pci_ds s .s html から
ダウンロードできます。
7.4. セキュリティ技術導入ガイド (Securit y T echnical

Implement at ion Guide)
セキュリティ技術導入ガイド (STIG: Se curity Te chnical Imple me ntation Guide ) は、ソフトウェア

とハードウェアの標準化された安全なインストールと保守についての方法論です。
STIG についての詳細は、以下の URL を参照してくださ

い。http://ias e .dis a.mil/s tigs /Page s /inde x.as px
176
⁠付録A 暗号の標準
付録A 暗号の標準
A.1. 同期式の暗号
A.1.1. 高度暗号化標準 — AES
高度暗号化標準 (AES: Advance d Encryption Standard) は米国政府によって採用された暗号化標準で

す。この標準は、元は Rijndae l として公開された大規模なコレクションの中から採用された、3 つのブ
ロック暗号 AES-128、AES-192 および AES-256 から構成されています。それぞれの AES 暗号は、
キーのサイズがそれぞれ 128、192 および 256 ビットの 128 ビットのブロックサイズを持ちます。AES
暗号の分析は詳細に行われており、現在ではその前進であるデータ暗号化標準 (DES: Data Encryption
Standard) と同様に世界中で使用されています。 ⁠ [2]
A.1.1.1. AES の歴史
AES は、標準化プロセス開始から 5 年後の 2001年11月26日に、U.S. FIPS PUB 197 (FIPS 197) とし

て National Ins titute of Standards and Te chnology (NIST) により発表されました。この 5 年間に
15 の競合するデザインが提出され、それぞれの評価が行われた結果、Rijndae l が最適な標準として選択さ
れました。これは多くの異なる暗号化パッケージで利用できます。AES は、最高機密情報に関して NSA
が初めて認定した、一般にアクセス可能でオープンな暗号です (Wikipe dia の Se curity of AES を参
照)。 ⁠ [3]
Rijndae l は 2 人のベルギー人の暗号学者 Joan Dae mon と Vince nt Rijme n により開発され、彼らによ

り AES の選定プロセスに提出されました。Rijndae l はこれら 2 人の発明家の名前の混成語です。 ⁠ [4]
A.1.2. データ暗号化標準 — DES
データ暗号化標準 (DES: Data Encryption Standard) は、1976 年に National Bure au of

Standards によって米国の公式な連邦情報処理標準 (FIPS: Fe de ral Information Proce s s ing
Standard) として選択されたブロック暗号 (共有秘密暗号の形式の１つ) であり、その後国際的に広く利用
されるようになりました。この暗号は 56 ビットキーを使用した対称鍵アルゴリズムに基づいています。こ
のアルゴリズムは当初、秘密の設計要素、比較的短い鍵の長さ、および National Se curity Age ncy
(NSA) のバックドアに関する疑惑とともに議論の的になりました。その後、DES は徹底的な学術的検証を
受け、現代のブロック暗号とその暗号解析の理解の進展に貢献しています。 ⁠ [5]
A.1.2.1. DES の歴史
現在、DES のセキュリティは多くのアプリケーションに対して不十分であると考えられています。この主
な原因は、56 ビットキーが小さすぎることにあります。1999年1月に、dis tribute d.ne t と Ele ctronic
Frontie r Foundation は共同で DES 鍵を 22 時間 15 分で解読しました。また、実際の実装については
実現不可能であるものの、暗号に理論上の弱点があることを示唆するいくつかの解析結果があります。こう
した理論上の弱点があるものの、このアルゴリズムは 3-DES の形式で実際には安全であると考えられてい
ます。近年、この暗号は高度暗号化標準 (AES) に置き換えられています。 ⁠ [6]
一部の文献では、標準としての DES と、DEA (Data Encryption Algorithm)　と呼ばれる DES アルゴ

リズムを区別しています。 ⁠ [7] 　
A.2. 公開鍵暗号
公開鍵暗号は、多くの暗号アルゴリズムと暗号化システムで採用されている暗号化のアプローチです。その
際立った特徴は、対称鍵アルゴリズムではなく非対称鍵アルゴリズムを使用する、または対称鍵と共に非対
177
称鍵アルゴリズムを使用する点にあります。公開鍵/秘密鍵の暗号化技術を使用することで、以前には知ら
れていなかった通信を保護し、メッセージを認証する数多くの方法を実用化できるようになりました。ま
た、対称鍵アルゴリズムを使用する際に必要とされていた１つまたは複数の秘密鍵のセキュアな初期交換が
不要になりました。さらに、公開鍵暗号を使って電子署名を作成することもできるようになりました。 ⁠ [8]
公開鍵暗号は、基本的な技術であり世界中で幅広く使用されています。また、トランスポート層セキュリ
ティ (TLS) (SSL の後継)、PGP および GPG などのインターネット標準の土台となるアプローチです。
[9] 　
公開鍵暗号で使用される特徴的な技術は、非対称の鍵アルゴリズムの使用です。このアルゴリズムでは、
メッセージを暗号化するために使われる鍵がメッセージの暗号解読するために使用される鍵と同じではあり
ません。各ユーザーは、暗号鍵と秘密鍵のペアを持ちます。公開鍵が広く配布される可能性があるのに対し
て、秘密鍵は秘密の状態にされます。メッセージは受信者の公開鍵で暗号化され、対応する秘密鍵でのみ暗
号化解除することができます。これらの鍵は数学的に関連付けることができますが、(現在または将来にお
いて) 秘密鍵を公開鍵から導き出すことはできません。このアルゴリズムの発見は、1970 年代中盤に始
まった暗号の使用に変革をもたらすものとなりました。 ⁠ [10]
これとは対照的に、数千年間にわたって使用されてきた各種の対称鍵暗号のアルゴリズムでは、暗号化と暗
号解除のために単一の秘密鍵が使用され、この鍵は送信者と受信者によって共有されます (この秘密鍵は共
有されるものの、秘密の状態にしておく必要があります)。対称的な暗号化スキームを使用するには、送信
者と受信者の両方が前もって鍵を安全に共有しておく必要があります。 ⁠ [11] 　
対称鍵アルゴリズムの方の計算集約度が低くなることがほぼ通例であるため、鍵交換アルゴリズムを用いて
鍵を交換してから、その鍵と対称鍵アルゴリズムを用いてデータを転送することが一般に行われています。
例えば、PGP および各種スキームの SSL/TLS ファミリーがこれを実行するため、それらはハイブリッド
暗号システムと呼ばれています。 ⁠ [12] 　
A.2.1. Dif f ie-Hellman
Diffie –He llman 鍵交換 (D–H) は、相互を認識していない 2 当事者間で、保護されていない通信チャネル

を通して共有秘密鍵を共同で確立できるようにする暗号化プロトコルです。確立される鍵は、対称鍵暗号を
用いて後続の通信を暗号化するために使用されます。 ⁠ [13]
A.2.1.1. Dif f ie-Hellman の歴史
このスキーマは 1976 年に Whitfie ld Diffie と Martin He llman によって初めて公開されました。しか

しながら後に、GCHQ の Britis h s ignals inte llige nce age ncy 内の Malcolm J. Williams on が数年早
くこれを単独で発明しており、かつ機密扱いにされていたことが明らかになりました。2002 年に
He llman は、Ralph Me rkle の公開鍵暗号の発明に対する貢献を認めてこのアルゴリズムを Diffie –
He llman–Me rkle 鍵交換と呼ぶことを提案しました（He llman, 2002）。 ⁠ [14]
Diffie –He llman 鍵合意はそれ自体が匿名の (認証されない) 鍵合意プロトコルであるにも関わらず、さま

ざまな認証されたプロトコルに対する基礎を提供し、トランスポート層セキュリティの超短期モード (暗号
スイートに応じて EDH または DHE と呼ばれる) において PFS (Pe rfe ct Forward Se cre cy) を提供す
るために使用されます。 ⁠ [15]
U.S. Pate nt 4,200,770 (現在は期限が失効) ではこのアルゴリズムを説明しており、発明者は

He llman、Diffie および Me rkle であるとしています。 ⁠ [16]
A.2.2. RSA
暗号学において、RSA (初めて公に説明した Rive s t、Shamir および Adle man の頭文字を表す) は公開

鍵暗号のアルゴリズムです。これは、暗号と署名のどちらにも適しているとされる最初のアルゴリズムであ
り、当初の公開鍵暗号における主要な優位性の 1 つとなってきました。RSA は、電子商取引のプロトコル
178
⁠付録A 暗号の標準
で広く使用されており、十分な長さの鍵と最新の実装が使用されていることからセキュアであると考えられ
ています。
A.2.3. DSA
電子署名アルゴリズム (DSA: Digital Signature Algorithm) は電子署名の標準であり、電子署名におけ

る米連邦政府の標準です。DSA は署名のみに使用されるアルゴリズムであり、暗号アルゴリズムではあり
ません。 ⁠ [17]
A.2.4. SSL/T LS
トランスポート層セキュリティ (TLS: Trans port Laye r Se curity) とその前身である Se cure Socke t

Laye r (SSL) は、インターネットなどのネットワーク上の通信に対してセキュリティを提供する暗号プロ
トコルです。TLS と SSL は、エンドツーエンドでトランスポート層におけるネットワーク接続のセグメン
トを暗号化します。
このプロトコルのいくつかのバージョンは、ウェブ閲覧、電子メール、インターネット FAX、インスタン
トメッセージおよび voice -ove r-IP (VoIP) などのアプリケーションで広く使われています。 ⁠ [18]
A.2.5. Cramer-Shoup 暗号システム
Crame r–Shoup システムは非対称暗号アルゴリズムであり、初の効率的なスキームとして、標準的な暗号

推測に基づく適応的選択暗号文攻撃に対してセキュアであることが証明されました。そのセキュリティは、
決定 Diffie –He llman 仮定の計算的な難解さに基づいています（これは一般的な想定ですが、実証されて
いる訳ではありません)。これは 1998年に Ronald Crame r と Victor Shoup により開発された
ElGamal 暗号の拡張です。極めて頑強性に欠ける ElGamal と比べて、Crame r–Shoup には高度な攻撃
者に対してさえも頑強性を確保する追加の要素が加わります。この頑強性は、衝突耐性のあるハッシュ機能
と追加の計算の使用によって実現され、これにより ElGamal の 2 倍のサイズの暗号文が生成されます。
[19]
A.2.6. ElGamal 暗号
暗号学において、ElGamal 暗号システムは Diffie -He llman 鍵合意に基づく公開鍵暗号の非対称鍵暗号ア

ルゴリズムです。1985年に Tahe r ElGamal がこれを発表しました。ElGamal 暗号は、GNU Privacy
Guard フリーソフトウェアや最近のバージョンの PGP および他の暗号システムで使用されています。
[20]
[2] "Advanced Encryption Standard" Wikipe dia 2009年11月14

日http://en.wikipedia.org/wiki/Advanced_Encryption_Standard
[3] "Advanced Encryption Standard." Wikipe dia. 14 Novem ber 2009

http://en.wikipedia.org/wiki/Advanced_Encryption_Standard
[4] "Advanced Encryption Standard" Wikipe dia 2009年11月14日

http://en.wikipedia.org/wiki/Advanced_Encryption_Standard
[5] "Data Encryption Standard." Wikipe dia. 2009年11月14日

http://en.wikipedia.org/wiki/Data_Encryption_Standard
[6] "Data Encryption Standard" Wikipe dia 2009年11月14日

[7] "Data Encryption Standard" Wikipe dia 2009年11月14日

179
[8] "P ublic-key Encryption" Wikipe dia 2009年11月14日 http://en.wikipedia.org/wiki/P ublic-

key_cryptography
[9] "P ublic-key Encryption." Wikipe dia 2009 年 11 月 14 日 http://en.wikipedia.org/wiki/P ublic-

key_cryptography
[10] "P ublic-key Encryption." Wikipe dia. 2009 年 11 月 14 日 http://en.wikipedia.org/wiki/P ublic-

key_cryptography

key_cryptography

key_cryptography
[13] "Diffie-Hellm an." Wikipe dia 2009 年 11 月 14 日 http://en.wikipedia.org/wiki/Diffie-Hellm an
[14] "Diffie-Hellm an." Wikipe dia 2009 年 11 月 14 日 http://en.wikipedia.org/wiki/Diffie-Hellm an
[15] "Diffie-Hellm an." Wikipe dia2009 年 11 月 14 日 http://en.wikipedia.org/wiki/Diffie-Hellm an
[16] "Diffie-Hellm an." Wikipe dia. 2009 年 11 月 14 日 http://en.wikipedia.org/wiki/Diffie-Hellm an
[17] "DSA." Wikipe dia 2010 年 2 月 24 日 http://en.wikipedia.org/wiki/Digital_Signature_Algorithm
[18] "TLS/SSL." Wikipe dia 2010 年 2 月 24 日

http://en.wikipedia.org/wiki/Transport_Layer_Security
[19] "C ram er-Shoup cryptosystem ." Wikipe dia 2010 年 2 月 24 日

http://en.wikipedia.org/wiki/C ram er–Shoup_cryptosystem
[20] "ElGam al encryption" Wikipe dia 2010 年 2 月 24 日

http://en.wikipedia.org/wiki/ElGam al_encryption
180
⁠付録B Audit システムのリファレンス
付録B Audit システムのリファレンス
B.1. Audit イベントフィールド
表B.1「イベントフィールド」では、現在サポートされている Audit イベントフィールドを一覧表示して

います。イベントフィールドとは、Audit ログファイルで等号記号の前にある値です。
表B.1 イベントフィールド
イベントフィールド説明
a0、a1、a2、a3 システムコールの最初の 4 つの引数を十六進法で記録します。
acct ユーザーのアカウント名を記録します。
addr IPv4 または IPv6 アドレスを記録します。このフィールドは通
常、hostname フィールドの後に来て、ホスト名が解決するアドレスを
含みます。
arch システムの CPU アーキテクチャーについての情報を十六進法にエンコー
ドして記録します。
auid Audit ユーザー ID を記録します。この ID は、ログイン時にユーザーに
割り当てられ、ユーザーの ID が変更された後でもすべてのプロセスに引
き継がれます (たとえば、su - john コマンドでユーザーアカウントを
切り替えた場合)。
capability 特定の Linux 機能の設定に使用されたビット数を記録します。Linux 機
能については、capabilitie s (7) man ページを参照してください。
cap_fi 引き継いだファイルのシステムベースの機能設定に関連したデータを記録
します。
cap_fp 許可されたファイルのシステムベースの機能設定に関連したデータを記録
します。
cap_pe 効果的なプロセスベースの機能設定に関連したデータを記録します。
cap_pi 継承されたプロセスベースの機能設定に関連したデータを記録します。
cap_pp 許可されたプロセスベースの機能設定に関連したデータを記録します。
cgroup Audit イベント生成時のプロセスが含まれる cgroup へのパスを記録し
ます。
cmd 実行されたコマンドライン全体を記録します。これは、exe フィールド
がたとえば /bin/bash を記録するようなシェルインタープリターの場
合に便利です。シェルインタープリターと cmd フィールド
は、helloworld.sh --help のような実行されたコマンドラインの残
りの部分を記録するからです。
comm 実行されたコマンドを記録します。これは、exe フィールドがたとえば
/bin/bash を記録するようなシェルインタープリターの場合に便利で
す。シェルインタープリターと comm フィールドは、helloworld.sh
のような実行されたスクリプト名を記録するからです。
cwd システムコールが開始されたディレクトリーへのパスを記録します。
data TTY 記録に関連するデータを記録します。
dev イベントで記録されたファイルまたはディレクトリーを含むデバイスのマ
イナーおよびメジャー ID を記録します。
devmajor メジャーデバイス ID を記録します。
devminor マイナーデバイス ID を記録します。
egid 分析されているプロセスを開始したユーザーの実効グループ ID を記録し
ます。
euid 分析されているプロセスを開始したユーザーの実効ユーザー ID を記録し
ます。
181
exe 分析されているプロセスを開始するために使用された実行可能ファイルへ
のパスを記録します。
exit システムコールが返した終了コードを記録します。この値は、システム
コールによって異なります。以下のコマンドを使うと、この値をヒューマ
ンリーダブルなものに変換できます。ausearch --interpret --
exit exit_code
family IPv4 または IPv6 の使用されたアドレスプロトコルのタイプを記録しま
す。
filetype ファイルのタイプを記録します。
flags ファイルシステム名のフラグを記録します。
fsgid 分析されているプロセスを開始したユーザーのファイルシステムグループ
fsuid 分析されているプロセスを開始したユーザーのファイルシステムユーザー
gid グループ ID を記録します。
hostname ホスト名を記録します。
icmptype 受信した Inte rne t Control Me s s age Protocol (ICMP) パッケージの
タイプを記録します。このフィールドを含む Audit メッセージは通
常、ipt ables が生成します。
id 変更されたアカウントのユーザー ID を記録します。
inode Audit イベントで記録されたファイルまたはディレクトリーに関連する
inode 番号を記録します。
inode_gid inode の所有者のグループ ID を記録します。
inode_uid inode の所有者のユーザー ID を記録します。
items この記録にアタッチされたパス記録の数を記録します。
key Audit ログで特定のイベントを生成したルールに関連付けられているユー
ザー定義の文字列を記録します。
list Audit ルールリストの ID を記録します。以下が既知の ID リストになり
ます。
0 — user
1 — task
4 — exit
5 — exclude
mode ファイルまたはディレクトリーのパーミッションを数字表記にエンコー
ドして記録します。
msg 記録のタイムスタンプと一意の ID、または各種のイベント固有の
<name>=<value> ペアを記録します。これらは、カーネルもしくはユー
ザースペースアプリケーションが提供します。
msgtype ユーザーベースの AVC 拒否の場合に返されたメッセージのタイプを記録
します。このメッセージタイプは、D-Bus で決定されます。
name システムコールに引数として渡されたファイルまたはディレクトリーへの
完全パスを記録します。
new-disk 仮想マシンに割り当てられた新規ディスクリソースの名前を記録します。
new-mem 仮想マシンに割り当てられた新規メモリーリソースの容量を記録します。
new-vcpu 仮想マシンに割り当てられた新規の仮想 CPU リソースの数を記録しま
す。
new-net 仮想マシンに割り当てられた新規ネットワークインターフェイスのリソー
スの MAC アドレスを記録します。
new_gid ユーザーに割り当てられたグループ ID を記録します。
182
oauid システムにアクセスするためにログインし s ( u を使用してのログインな
どではなく)、ターゲットプロセスを開始したユーザーのユーザー ID を記
録します。このフィールドは、タイプ OBJ_PID の記録専用になります。
ocomm ターゲットプロセスの開始に使用されたコマンドを記録します。この
フィールドは、タイプ OBJ_PID の記録専用になります。
opid ターゲットプロセスのプロセス ID を記録します。このフィールドは、タ
イプ OBJ_PID の記録専用になります。
oses ターゲットプロセスのセッション ID を記録します。このフィールドは、
タイプ OBJ_PID の記録専用になります。
ouid ターゲットプロセスの実際のユーザー ID を記録します。
obj オブジェクトの SELinux コンテキストを記録します。オブジェクトは、
ファイルやディレクトリー、またはサブジェクトのアクションを受信す
るものになります。
obj_gid オブジェクトのグループ ID を記録します。
obj_lev_high オブジェクトの高い SELinux レベルを記録します。
obj_lev_low オブジェクトの低い SELinux レベルを記録します。
obj_role オブジェクトの SELinux の役割を記録します。
obj_uid オブジェクトの UID を記録します。
obj_user オブジェクトに関連付けられたユーザーを記録します。
ogid オブジェクトの所有者のグループ ID を記録します。
old-disk 新規ディスクリソースが仮想マシンに割り当てられた際の古いディスクリ
ソース名を記録します。
old-mem 新しいメモリー容量が仮想マシンに割り当てられた際の古いメモリーリ
ソースの容量を記録します。
old-vcpu 新規の仮想 CPU が仮想マシンに割り当てられた際の古い仮想 CPU リ
ソースの数を記録します。
old-net 新規ネットワークインターフェイスが仮想マシンに割り当てられた際の古
いネットワークインターフェイスリソースの MAC アドレスを記録しま
す。
old_prom ネットワークの無作為フラグの以前の値を記録します。
ouid ターゲットプロセスを開始したユーザーの実際のユーザー ID を記録しま
す。
path AVC 関連の Audi イベントでシステムコールに引数として渡されたファ
イルまたはディレクトリーへの完全パスを記録します。
perm イベント生成に使用されたファイルパーミッション (つまり、読み取り、
書き込み、実行、または属性変更) を記録します。
pid pid フィールドのセマンティックは、このフィールドの値の発生元に
よって異なります。
ユーザースペースから生成されたフィールドの場合、このフィールドはプ
ロセス ID になります。
カーネルが生成したフィールドの場合、このフィールドはスレッド ID に
なります。スレッド ID は単一スレッドプロセスの場合、プロセス ID と
同じになります。このスレッド ID の値は、ユーザースペースで使用され
る pthre ad_t ID の値とは異なることに注意してください。詳細
は、ge ttid(2) man ページを参照してください。
ppid 親プロセス ID (PID) を記録します。

prom ネットワークの無作為フラグを記録します。
proto 使用されたネットワークプロトコルを記録します。このフィールド
は、ipt ables で生成された Audit イベントに固有のものになります。
183
res Audit イベントを開始した操作結果を記録します。
result Audit イベントを開始した操作結果を記録します。
saddr ソケットアドレスを記録します。
sauid 送信者の Audit ログインユーザー ID を記録します。この ID は、元の
auid を送信しているユーザーをカーネルが判別できないため、D-Bus
が提供します。
ses 分析されているプロセスが開始されたセッションのセッション ID を記録
します。
sgid 分析されているプロセスを開始したユーザーのセットグループ ID を記録
します。
sig プログラムを異常終了させたシグナル数を記録します。これは通常、シス
テム侵入を知らせるものです。
subj サブジェクトの SELinux コンテキストを記録します。サブジェクトは、
プロセスやユーザー、またはオブジェクトに対して動作を行なっているも
のになります。
subj_clr サブジェクトの SELinux クリアランスを記録します。
subj_role サブジェクトの SELinux の役割を記録します。
subj_sen サブジェクトの SELinux の秘密度を記録します。
subj_user サブジェクトに関連付けられたユーザーを記録します。
success システムコールが成功したか、失敗したかを記録します。
suid 分析されているプロセスを開始したユーザーのセットユーザー ID を記録
します。
syscall カーネルに送信されたシステムコールのタイプを記録します。
terminal ターミナル名 (/dev/ なしで) を記録します。
tty 制御ターミナルの名前を記録します。プロセスに制御ターミナルがない場
合は、(none) の値を使います。
uid 分析されているプロセスを開始したユーザーの実際のユーザー ID を記録
します。
vm Audit イベントが始まった仮想マシン名を記録します。
B.2. Audit 記録のタイプ
表B.2「記録のタイプ」では、現在サポートされている Audit 記録のタイプを一覧表示しています。イベ

ントのタイプは、すべての Audit 記録の最初にある type= フィールドで指定されています。
表B.2 記録のタイプ
イベントタイプ説明
ADD_GROUP ユーザースペースグループが追加されると開始します。
ADD_USER ユーザースペースユーザーのアカウントが追加されると開始します。
ANOM_ABEND ⁠ [a] プロセスが異常終了すると開始します (コアダンプを引き起こすシグナル
が有効になっていれば、このシグナルを伴います)。
ANOM_ACCESS_FS [a] ファイルまたはディレクトリーアクセスが異常終了すると開始します。
ANOM_ADD_ACCT [a] ユーザースペースアカウントの追加が異常終了すると開始します。
ANOM_AMTU_FAIL [a] Abs tract Machine Te s t Utility (AMTU) の失敗が検出されると開始し
ます。
ANOM_CRYPTO_FAIL [a] 暗号化システムの失敗が検出されると開始します。
ANOM_DEL_ACCT [a] ユーザースペースアカウントの削除が異常終了すると開始します。
184
ANOM_EXEC [a] ファイル実行が異常終了すると開始します。
ANOM_LOGIN_ACCT [a] アカウントのログイン試行が異常終了すると開始します。
ANOM_LOGIN_FAILURES [ ログイン試行が失敗の制限数に達すると開始します。
a]
ANOM_LOGIN_LOCATION [ 許可されていない場所からログイン試行が行われると開始します。
a]
ANOM_LOGIN_SESSIONS [ ログイン試行が同時セッションの最大数に達すると開始します。
a]
ANOM_LOGIN_TIME [a] ログイン試行が pam_time などによって妨げられる場合に開始します。
ANOM_MAX_DAC [a] Dis cre tionary Acce s s Control (DAC) 失敗の最大数に達すると開始し

ます。
ANOM_MAX_MAC [a] Mandatory Acce s s Control (MAC) 失敗の最大数に達すると開始しま
す。
ANOM_MK_EXEC [a] ファイルを実行可能にすると開始します。
ANOM_MOD_ACCT [a] ユーザースペースアカウントの修正が異常終了すると開始します。
ANOM_PROMISCUOUS [a] デバイスが無作為モードを有効または無効にすると開始します。
ANOM_RBAC_FAIL [a] Role -Bas e d Acce s s Control (RBAC) セルフテストの失敗が検出され

ると開始します。
ANOM_RBAC_INTEGRITY_ Role -Bas e d Acce s s Control (RBAC) ファイル整合性テストの失敗が
FAIL [a] 検出されると開始します。
ANOM_ROOT_TRANS [a] ユーザーが root になると開始します。

AVC SELinux パーミッションチェックを記録するために開始します。
AVC_PATH SELinux パーミッションチェックが発生すると、dentry および
vfsmount のペアを記録するために開始します。
BPRM_FCAPS ユーザーがファイルシステム機能でプログラムを実行すると開始します。
CAPSET root で機能を外すなど、プロセスベースの機能に設定されている機能を
記録するために開始します。
CHGRP_ID ユーザースペースのグループ ID が変更されると開始します。
CHUSER_ID ユーザースペースのユーザー ID が変更されると開始します。
CONFIG_CHANGE Audit システムの設定が変更されると開始します。
CRED_ACQ ユーザーがユーザースペースの認証情報を必要とする際に開始します。
CRED_DISP ユーザーがユーザースペースの認証情報を廃棄する際に開始します。
CRED_REFR ユーザーがユーザースペースの認証情報を更新する際に開始します。
CRYPTO_FAILURE_USER 暗号解読、暗号化、ランダム化のいずれかの暗号化演算が失敗すると、開
始します。
CRYPTO_KEY_USER 暗号化の目的で使用される暗号鍵識別子を記録するために開始します。
CRYPTO_LOGIN 暗号化責任者のログイン試行が検出されると開始します。
CRYPTO_LOGOUT 暗号化責任者のログアウト試行が検出されると開始します。
CRYPTO_PARAM_CHANGE_ 暗号化パラメーターで変更が検出されると開始します。
USER
CRYPTO_REPLAY_USER 再生攻撃が検出されると開始します。
CRYPTO_SESSION TLS セッション確立中にパラメーター一式を記録するために開始しま
す。
CRYPTO_TEST_USER FIPS-140 規格で必要とされている暗号化テスト結果を記録するために開
始します。
CWD 現在の作業ディレクトリーを記録するために開始します。
DAC_CHECK DAC チェックの結果を記録するために開始します。
185
DAEMON_ABORT エラーのためにデーモンが停止する際に開始します。
DAEMON_ACCEPT auditd デーモンがリモート接続を受け入れる際に開始します。
DAEMON_CLOSE auditd デーモンがリモート接続を閉じる際に開始します。
DAEMON_CONFIG デーモンの設定変更が検出されると開始します。
DAEMON_END デーモンが正常に停止されると開始します。
DAEMON_RESUME auditd デーモンがロギングを再開する際に開始します。
DAEMON_ROTATE auditd デーモンが Audit ログファイルをローテーションする際に開始
します。
DAEMON_START auditd デーモンが起動されると開始します。
DEL_GROUP ユーザースペースグループが削除されると開始します。
DEL_USER ユーザースペースのユーザーが削除されると開始します。
DEV_ALLOC デバイスが割り当てられると開始します。
DEV_DEALLOC デバイスの割り当てが解除されると開始します。
EOE 複数記録イベントの終了を記録するために開始します。
EXECVE execve(2) システムコールの引数を記録するために開始します。
FD_PAIR pipe および socketpair のシステムコールの使用を記録するために開
始します。
FS_RELABEL ファイルシステムのラベル張り替え操作が検出されると開始します。
GRP_AUTH ユーザースペースのグループに対してグループパスワードを使って認証が
行われると開始します。
INTEGRITY_DATA ⁠ [b] カーネルが実行するデータ整合性検証イベントを記録するために開始しま
す。
INTEGRITY_HASH [b] カーネルが実行するハッシュタイプ整合性検証イベントを記録するために
開始します。
INTEGRITY_METADATA [b] カーネルが実行するメタデータ整合性検証イベントを記録するために開始
します。
INTEGRITY_PCR [b] Platform Configuration Re gis te r (PCR) 無効化メッセージを記録する
ために開始します。
INTEGRITY_RULE [b] ポリシールールを記録するために開始します。
INTEGRITY_STATUS [b] 整合性検証のステータスを記録するために開始します。

IPC システムコールが参照する Inte r-Proce s s Communication オブジェク
トについての情報を記録するために開始します。
IPC_SET_PERM IPCオブジェクト上の IPC_SET 制御操作が設定する新しい値についての
情報を記録するために開始します。
KERNEL Audit システムの初期化を記録するために開始します。
KERNEL_OTHER サードパーティーのカーネルモジュールからの情報を記録するために開始
します。
LABEL_LEVEL_CHANGE オブジェクトのレベルラベルが修正されると開始します。
LABEL_OVERRIDE 管理者がオブジェクトのレベルラベルを上書きすると開始します。
LOGIN ユーザーがシステムにアクセスするためにログインする際に関連するログ
イン情報を記録するために開始します。
MAC_CIPSOV4_ADD Comme rcial Inte rne t Protocol Se curity Option (CIPSO) ユーザー
が新たな Domain of Inte rpre tation (DOI) を追加すると開始します。
DOI の追加は、Ne tLabe l が提供するカーネルのパケットラベル付け機
能の一部です。
MAC_CIPSOV4_DEL CIPSO ユーザーが既存の DOI を削除すると開始します。DOI の追加
は、Ne tLabe l が提供するカーネルのパケットラベル付け機能の一部で
す。
MAC_CONFIG_CHANGE SELinux ブール値が変更されると開始します。
186
MAC_IPSEC_EVENT IPSe c イベントが検出されるか IPSe c 設定が変更されると、IPSe c イベ
ントについての情報を記録するために開始します。
MAC_MAP_ADD 新たな Linux Se curity Module (LSM) ドメインマッピングが追加され
ると開始します。LSM ドメインマッピングは、Ne tLabe l が提供する
カーネルのパケットラベル付け機能の一部です。
MAC_MAP_DEL 既存の LSM ドメインマッピングが追加されると開始します。LSM ドメ
インマッピングは、Ne tLabe l が提供するカーネルのパケットラベル付け
機能の一部です。
MAC_POLICY_LOAD SELinux ポリシーファイルが読み込まれると開始します。
MAC_STATUS SELinux モード (e nforcing、pe rmis s ive 、off) が変更されると開始し
ます。
MAC_UNLBL_ALLOW Ne tLabe l が提供するカーネルのパケットラベル付け機能を使用する際に
ラベルのないトラフィックが許可されると開始します。
MAC_UNLBL_STCADD Ne tLabe l が提供するカーネルのパケットラベル付け機能を使用する際に
静的ラベルが追加されると開始します。
MAC_UNLBL_STCDEL Ne tLabe l が提供するカーネルのパケットラベル付け機能を使用する際に
静的ラベルが削除されると開始します。
MMAP mmap(2) システムコールのファイル記述子およびフラグを記録するため
に開始します。
MQ_GETSETATTR mq_getattr(3) および mq_setattr(3) のメッセージキュー属性を
記録するために開始します。
MQ_NOTIFY mq_notify(3) システムコールの引数を記録するために開始します。
MQ_OPEN mq_open(3) システムコールの引数を記録するために開始します。
MQ_SENDRECV mq_send(3) および mq_receive(3) のシステムコールの引数を記録
するために開始します。
NETFILTER_CFG Ne tfilte r チェーンの修正が検出されると開始します。
NETFILTER_PKT Ne tfilte r チェーンをトラバースするパケットを記録するために開始しま
す。
OBJ_PID 信号の送信先のプロセスについての情報を記録するために開始します。
PATH ファイル名パスの情報を記録するために開始します。
RESP_ACCT_LOCK ⁠ [c] ユーザーのアカウントがロックされると開始します。
RESP_ACCT_LOCK_TIMED ユーザーのアカウントが一定期間ロックされると開始します。
[c]
RESP_ACCT_REMOTE [c] ユーザーのアカウントがリモートセッションからロックされると開始しま

す。
RESP_ACCT_UNLOCK_TIM ユーザーのアカウントが設定された期間の後にロック解除されると開始し
ED [c] ます。
RESP_ALERT [c] 警告 E メールが送信されると開始します。
RESP_ANOMALY [c] 異常に対してアクションが取られないと開始します。
RESP_EXEC [c] プログラムの実行を元とする脅威に侵入検出プログラムが反応すると開始
します。
RESP_HALT [c] システムがシャットダウンすると開始します。
RESP_KILL_PROC [c] プロセスが終了すると開始します。
RESP_SEBOOL [c] SELinux ブール値が設定されると開始します。
RESP_SINGLE [c] システムがシングルユーザーモードになると開始します。
RESP_TERM_ACCESS [c] セッションが終了すると開始します。
RESP_TERM_LOCK [c] ターミナルがロックされると開始します。

ROLE_ASSIGN 管理者がユーザーに SELinux の役割を割り当てると開始します。
187
ROLE_MODIFY 管理者が SELinux の役割を編集すると開始します。
ROLE_REMOVE 管理者がユーザーを SELinux の役割から削除すると開始します。
SELINUX_ERR 内部 SELinux エラーが検出されると開始します。
SERVICE_START サービスが起動すると開始します。
SERVICE_STOP サービスが停止すると開始します。
SOCKADDR ソケットアドレスを記録するために開始します。
SOCKETCALL sys_socketcall システムコール (多くのソケット関連のシステムコー
ルを多重化するために使用) の引数を記録するために開始します。
SYSCALL カーネルへのシステムコールを記録するために開始します。
SYSTEM_BOOT システムが起動すると開始します。
SYSTEM_RUNLEVEL システムのランレベルが変更されると開始します。
SYSTEM_SHUTDOWN システムがシャットダウンすると開始します。
TEST テストメッセージの成功の値を記録するために開始します。
TRUSTED_APP このタイプの記録は、監査を必要とするサードパーティーのアプリケー
ションで使用可能です。
TTY TTY 入力が管理プロセスに送信されると開始します。
USER_ACCT ユーザースペースユーザーのアカウントが編集されると開始します。
USER_AUTH ユーザースペースの認証試行が検出されると開始します。
USER_AVC ユーザースペースの AVC メッセージが生成されると開始します。
USER_CHAUTHTOK ユーザーアカウントの属性が編集されると開始します。
USER_CMD ユーザースペースのシェルコマンドが実行されると開始します。
USER_END ユーザースペースのセッションが終了すると開始します。
USER_ERR ユーザーアカウントの状態のエラーが検出されると開始します。
USER_LABELED_EXPORT SELinux ラベルの付いたオブジェクトがエクスポートされると開始しま
す。
USER_LOGIN ユーザーがログインすると開始します。
USER_LOGOUT ユーザーがログアウトすると開始します。
USER_MAC_POLICY_LOAD ユーザースペースのデーモンが SELinux ポリシーを読み込むと開始しま
す。
USER_MGMT ユーザースペースの管理データを記録するために開始します。
USER_ROLE_CHANGE ユーザーの SELinux の役割が変更されると開始します。
USER_SELINUX_ERR ユーザースペースの SELinux エラーが検出されると開始します。
USER_START ユーザースペースのセッションが開始すると開始します。
USER_TTY 管理プロセスへの TTY 入力についての説明メッセージがユーザースペー
スから送信されると開始します。
USER_UNLABELED_EXPOR SELinux ラベルなしでオブジェクトがエクスポートされると開始しま
T す。
USYS_CONFIG ユーザースペースのシステム設定変更が検出されると開始します。
VIRT_CONTROL 仮想マシンが起動、一時停止、停止すると開始します。
VIRT_MACHINE_ID 仮想マシンへのラベルのバインディングを記録するために開始します。
VIRT_RESOURCE 仮想マシンのリソース割り当てを記録するために開始します。
[a] ANOM が前に付いている Audit イベントタイプはすべて、侵入検出プログラムが処理することになっていま
す。
[b] このイベントタイプは、Integrity Measurem ent Architecture (IMA) に関連しており、これは,
Trusted P latform Module (TP M) チップと一番うまく機能します。
[c] RESP が前に付いている Audit イベントタイプはすべて、侵入検出システムがシステム上で悪意のあるアク
ティビティーを検出した場合に、その侵入検出システムの反応となることが意図されています。
188
⁠付録C 改訂履歴
付録C 改訂履歴
改訂 1-14.17.2 T ue Jun 2 20 15 Kenzo Mo riguchi

翻訳完成
改訂 1-14.17.1 T ue Jun 2 20 15 Chest er Cheng

翻訳ファイルを XML ソースバージョン 1-14.17 と同期
改訂 1-14.17 Wed Feb 18 20 15 Ro bert Krát ký

7.1 GA リリース向けのバージョン
改訂 1-14.15 Fri Dec 0 6 20 14 Ro bert Krát ký

Re d Hat カスタマーポータルでの並び替え順序の更新。
改訂 1-14.13 T hu No v 27 20 14 Ro bert Krát ký

POODLE vuln を反映する更新。
改訂 1-14.12 T ue Jun 0 3 20 14 T o máš Čapek

7.0 GA リリース向けバージョン
189

Red Hat Enterprise Linux 7 Security Guide Ja JP

Uploaded by

Copyright:

Available Formats

Red Hat Enterprise Linux 7 Security Guide Ja JP

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Red Hat Enterprise Linux 7 Security Guide Ja JP

Uploaded by

Copyright:

Available Formats

Red Hat Enterprise Linux 7

Red Hat Enterprise Linux 7 のセキュリティに関するガイド

Martin Prpič Tomáš Čapek Stephen Wadeley

Red Hat Enterprise Linux 7 のセキュリティに関するガイド

Copyright © 2015 Red Hat, Inc.

Java ® is a registered trademark of Oracle and/or its affiliates.

XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the

MySQL ® is a registered trademark of MySQL AB in the United States, the European

Node.js ® is an official trademark of Joyent. Red Hat Software Collections is not

All other trademarks are the property of their respective owners.

しかし残念なことに、多くの組織 (個々のユーザーも含む) が、機能性や生産性、便利さ、使いやすさおよ

本書では、/lib ディレクトリーにあるファイルにも言及しています。64 ビットのシステムを使用

すべての業界の企業は、米国医師会 (AMA: Ame rican Me dical As s ociation) や米国電気電子学会 (IEEE:

アクセス制御リスト (ACL: Acce s s control lis ts )

脆弱性アセスメントは、 外部からの視点と内部からの視点の 2 種類に分類できます。

https ://www.owas p.org/ — 『The Ope n We b Application Se curity Proje ct』

1.3.3.1. Nmap を使用したホストのスキャン

Nmap をインストールするには、root で yum install nmap コマンドを実行します。

1.3.3.1.1. Nmap の使用

Nmap を実行するには、シェルプロンプトに nmap コマンドを入力し、その後にスキャン対象のマシンの

例えば、ホスト名が foo.example.com のマシンをスキャンするには、シェルプロンプトに以下を入力

~]$ nmap foo.example.com

Interesting ports on foo.example.com:

53/tcp open domain

Nmap の使用法に関する詳細情報は、以下の URL にある公式ホームページを参照してください。

http://www.ins e cure .org/

Nessus は完全サービス型のセキュリティスキャナーです。Nessus のプラグインアーキテクチャーを

Nessus に関する詳細は、以下の URL にある公式 We b サイトを参照してください。

OpenVAS (Open Vulnerability Assessment System) は、脆弱性および包括的な脆弱性管理のスキャ

Ope nVAS に関する詳細は、以下の URL にある公式 We b サイトを参照してください。

http://www.ope nvas .org/

Nikt o は、優れた 共通ゲートウェイインターフェース (CGI) のスクリプトスキャナーです。Nikt o は、

Nikt o の詳細については、以下の URL を参照してください。

Re d Hat Ente rpris e Linux 7 を完全にインストールすると、1000 以上のアプリケーションとライブラ

安全ではないサービスの別のカテゴリは、NFS または NIS などのネットワークファイルシステムと情報

Re d Hat Ente rpris e Linux 7 は、上記のサービスをデフォルト時にすべて無効にしてリリースされま

1.4.3. ワークステーションおよび家庭用 PC のセキュリティに対する脅威

デフォルトの共有 セキュアなサービスでは、開発や評価テ 無線アクセスポイントや事前設定済みの

サービスの脆弱性 攻撃者はインターネット上で実行されて CGI などの HTTP ベースのサービス

管理者は、サービスが root ユーザーと

サービス拒否攻撃 単独の攻撃者または攻撃者のグループ 2000 年に発生した米国内での DoS で

2.1. BIOS のセキュア化

BIOS (もしくは BIOS に相当するもの) およびブートローダーのパスワード保護により、システムに物理的

2.1.1. BIOS パスワード

コンピューターの BIOS をパスワードで保護する主な理由は、以下の 2 つです ⁠ [1] 。

1. BIOS 設定の変更を防止する — 侵入者が BIOS にアクセスした場合、CD-ROM やフラッシュド

2. システムの起動を防ぐ — BIOS の中には起動プロセスをパスワードで保護できるものもあります。

BIOS パスワードを忘れた場合は、マザーボード上のジャンパーでリセットするか、CMOS バッテリーを

2.1.1.1. 非 BIOS ベースのシステム

他のシステムやアーキテクチャーでは、異なるプログラムを使用して x86 システム上の BIOS とほぼ同等

Re d Hat では、/boot、/、/tmp および /var/tmp のそれぞれに個別のパーティションを作成すること

ユーザーデータ (/home) が別個のパーティションではなく / に保存されていると、このパー

/tmp および /var/tmp

/tmp と /var/tmp ディレクトリーは、どちらも長期保存の必要がないデータを保存するため

最小限のインストール 環境に関する詳細情報は、Re d Hat Ente rpris e Linux 7 インストールガイドの

以下のステップは、Re d Hat Ente rpris e Linux のインストール直後に実行する必要のあるセキュリティ

~]# yum update

2. ファイアウォールサービスの firewalld は Re d Hat Ente rpris e Linux のインストールで自動

firewalld を開始するには、root で以下のコマンドを実行します。

~]# systemctl start firewalld

脆弱性アセスメントは、外部からの視点と内部からの視点の 2 種類に分類できます。

Nikt o は、優れた共通ゲートウェイインターフェース (CGI) のスクリプトスキャナーです。Nikt o は、

デフォルトの共有セキュアなサービスでは、開発や評価テ無線アクセスポイントや事前設定済みの

サービスの脆弱性攻撃者はインターネット上で実行されて CGI などの HTTP ベースのサービス

サービス拒否攻撃単独の攻撃者または攻撃者のグループ 2000 年に発生した米国内での DoS で

最小限のインストール環境に関する詳細情報は、Re d Hat Ente rpris e Linux 7 インストールガイドの

インストールに関する全般的な情報は、Re d Hat Ente rpris e Linux 7 インストールガイドを参照してく

Re d Hat 製品で発見されたセキュリティ問題はすべて、Red Hat セキュリティレスポンスチームがその

「GPG 鍵の作成」では、個人の GPG 鍵セットを作成し、通信を認証する方法について説明していま

インストールプログラムではセキュリティ目的で、システムがセキュアハッシュアルゴリズム 512