セキュリティーガイド

PDF

Red Hat Enterprise Linux 7

RHEL サーバーとワークステーションをセキュアにする概念と手法

Mirek Jahoda

Red Hat Customer Content Services

mjahoda@redhat.com

Jan Fiala

Red Hat Customer Content Services

jafiala@redhat.com

Stephen Wadeley

Red Hat Customer Content Services

Robert Krátký

Red Hat Customer Content Services

Martin Prpič

Red Hat Customer Content Services

Ioanna Gkioka

Red Hat Customer Content Services

Tomáš Čapek

Red Hat Customer Content Services

Yoana Ruseva

Red Hat Customer Content Services

Miroslav Svoboda

Red Hat Customer Content Services

法律上の通知

概要

本書は、ユーザーおよび管理者が、ローカルおよびリモートの侵入、悪用、および悪意のある行為からワークステーションおよびサーバーを保護するプロセスおよびプラクティスを学ぶのに利用できます。

本ガイドでは、Red Hat Enterprise Linux を対象としていますが、概念および手法はすべての Linux システムに適用できます。データセンター、勤務先、および自宅で安全なコンピューティング環境を構築するのに必要な計画およびツールを詳細に説明します。

管理上の適切な知識、警戒体制、およびツールを備えることで、Linux を実行しているシステムの機能をフルに活用して、大概の一般的な侵入や悪用の手法からシステムを保護できます。

第1章セキュリティーの概要

ビジネスの運営や個人情報の把握ではネットワーク化された強力なコンピューターへの依存度が高まっていることから、各種業界ではネットワークとコンピューターのセキュリティーの実践に関心が向けられています。企業は、システム監査を適正に行い、ソリューションが組織の運営要件を満たすようにするために、セキュリティーの専門家の知識と技能を求めてきました。多くの組織はますます動的になってきていることから、従業員は、会社の重要な IT リソースに、ローカルまたはリモートからアクセスするようになっています。このため、セキュアなコンピューティング環境に対するニーズはより顕著になっています。

にも関わらず、多くの組織 (個々のユーザーも含む) は、機能性、生産性、便利さ、使いやすさ、および予算面の懸念事項にばかり目を向け、セキュリティーをその結果論と見なし、セキュリティーのプロセスが見過ごされています。したがって、適切なセキュリティーの確保は、無許可の侵入が発生して はじめて 徹底されることも少なくありません。多くの侵入の試みを阻止する効果的な方法は、インターネットなどの信頼できないネットワークにサイトを接続する前に、適切な措置を講じることです。

注記

本書では、/lib ディレクトリー内のファイルにいくつかの参照を行います。64 ビットシステムを使用する場合は、上記のファイルの一部は /lib64 にある可能性があります。

1.1. コンピューターセキュリティーとは

コンピューターセキュリティーは、コンピューティングと情報処理の幅広い分野で使用される一般的な用語です。コンピューターシステムとネットワークを使用して日々の業務を行い、重要な情報へアクセスしている業界では、企業データを総体的資産の重要な部分であると見なしています。総保有コスト (Total Cost of Ownership: TCO)、投資利益率 (Return on Investment: ROI)、サービスの品質 (Quality of Service: QoS) などの用語や評価指標は日常的なビジネス用語として用いられるようになっています。各種の業界が、計画およびプロセス管理コストの一環として、これらの評価指標を用いてデータ保全性や可用性などを算出しています。電子商取引などの業界では、データの可用性と信頼性は、成功と失敗の違いを意味します。

1.1.1. セキュリティーの標準化

企業はどの業界でも、米国医師会 (AMA: American Medical Association)、米国電気電子学会 (IEEE: Institute of Electrical and Electronics Engineers) などの標準化推進団体が作成する規制やルールに従っています。情報セキュリティーにも同じことが言えます。多くのセキュリティーコンサルタントやベンダーが 機密性 (Confidentiality)、保全性 (Integrity)、可用性 (Availability) の頭文字をとった CIA として知られる標準セキュリティーモデルを採用しています。この 3 階層モデルは、機密情報のリスク評価やセキュリティー方針の確立において、一般的に採用されているモデルです。以下でこの CIA モデルを説明します。

機密性 - 機密情報は、事前に定義された個人だけが利用できるようにする必要があります。許可されていない情報の送信や使用は、制限する必要があります。たとえば、情報に機密性があれば、権限のない個人が顧客情報や財務情報を悪意のある目的 (ID 盗難やクレジット詐欺など) で入手できません。
保全性 - 情報は、改ざんして不完全または不正確なものにすべきではありません。承認されていないユーザーが、機密情報を変更したり破壊したりする機能を使用できないように制限する必要があります。
可用性 - 情報は、認証されたユーザーが必要な時にいつでもアクセスできるようにする必要があります。可用性は、合意した頻度とタイミングで情報を入手できることを保証します。これは、パーセンテージで表されることが多く、ネットワークサービスプロバイダーやその企業顧客が使用するサービスレベルアグリーメント (SLA) で正式に合意となります。

1.1.2. 暗号化ソフトウェアおよび認定

以下のナレッジベースの記事では、Red Hat Enterprise Linux コア暗号化コンポーネントの概要 (どのコンポーネントか選択されているか、どのように選択されているか、オペレーティングシステムにどのように統合されているかどうか、ハードウェアセキュリティーモジュールおよびスマートカードにどのように対応しているか、および暗号化認証がどのように適用されているか) を説明します。

RHEL7 Core Crypto Components

1.2. セキュリティーコントロール

多くの場合、コンピューターセキュリティーは、一般に コントロール と呼ばれる以下の 3 つのマスターカテゴリーに分類されます。

物理的
技術的
管理的

この 3 つのカテゴリーは、セキュリティーの適切な実施における主な目的を定義するものです。このコントロールには、コントロールと、その実装方法を詳細化するサブカテゴリーがあります。

1.2.1. 物理的コントロール

物理的コントロールは、機密資料への非認証アクセスの抑止または防止のために、明確な構造でセキュリティー対策を実施します。物理的コントロールの例は以下のとおりです。

有線監視カメラ
動作または温度の感知アラームシステム
警備員
写真付き身分証明書
施錠された、デッドボルト付きのスチールドア
バイオメトリクス (本人確認を行うための指紋、声、顔、虹彩、筆跡などの自動認識方法が含まれます)

1.2.2. 技術的コントロール

技術的コントロールでは、物理的な構造物やネットワークにおける機密データのアクセスや使用を制御する基盤となる技術を使用します。技術的コントロールは広範囲に及び、以下のような技術も含まれます。

暗号化
スマートカード
ネットワーク認証
アクセス制御リスト (ACL)
ファイルの完全性監査ソフトウェア

1.2.3. 管理的コントロール

管理的コントロールは、セキュリティーの人的要素を定義します。これは組織内のあらゆるレベルの職員や社員に関連するもので、誰がどのリソースや情報にアクセスするかを、次のような手段で決定します。

トレーニングおよび認識の向上
災害準備および復旧計画
人員採用と分離の戦略
人員登録とアカウンティング

1.3. 脆弱性のアセスメント

時間やリソースがあり、その気になれば、攻撃者はほとんどすべてのシステムに侵入できます。現在利用できるセキュリティーの手順と技術をすべて駆使しても、すべてのシステムを侵入から完全に保護できる訳ではありません。ルーターは、インターネットへのセキュアなゲートウェイを提供します。ファイアウォールは、ネットワークの境界を保護します。仮想プライベートネットワーク (VPN) では、データが、暗号化されているストリームで安全に通過できます。侵入検知システムは、悪意のある活動を警告します。しかし、これらの技術が成功するかどうかは、以下のような数多くの要因によって決まります。

技術の設定、監視、および保守を行うスタッフの専門知識
サービスとカーネルのパッチ、および更新を迅速かつ効率的に行う能力
ネットワーク上での警戒を常に怠らない担当者の能力

データシステムと各種技術が動的であることを考えると、企業リソースを保護するタスクは極めて複雑になる可能性もあります。この複雑さゆえに、使用するすべてのシステムの専門家を見つけることは、多くの場合困難になります。情報セキュリティーの多くの分野によく精通している人材を確保することはできても、多くの分野を専門とするスタッフを確保することは容易ではありません。これは、情報セキュリティーの各専門分野で、継続的な注意と重点が必要となるためです。情報セキュリティーは、常に変化しています。

脆弱性アセスメントは、お使いのネットワークとシステムのセキュリティーに関する内部監査です。(「セキュリティーの標準化」で説明するように) このアセスメントの結果により、ネットワークの機密性、完全性、および可用性の状態が明らかになります。通常、脆弱性アセスメントは、対象システムとリソースに関する重要なデータを収集する調査フェーズから開始します。その後システム準備フェーズとなります。基本的にこのフェーズでは、対象を絞り、すべての既知の脆弱性を調べます。準備フェーズが終わると報告フェーズになります。ここでは、調査結果が高中低のカテゴリーに分類され、対象のセキュリティーを向上させる (または脆弱性のリスクを軽減する) 方法が話し合われます。

たとえば、自宅の脆弱性アセスメントを実施することを想定してみましょう。まずは自宅のドアを点検し、各ドアが閉まっていて、かつ施錠されていることを確認します。また、すべての窓が完全に閉まっていて鍵が閉まっていることも確認します。これと同じ概念が、システム、ネットワーク、および電子データにも適用されます。悪意のあるユーザーはデータを盗んで、破壊します。悪意のあるユーザーが使用するツール、思考、動機に注目すると、彼らの行動にすばやく反応することが可能になります。

1.3.1. アセスメントとテストの定義

脆弱性アセスメントは、外部からの視点 と 内部からの視点 の 2 種類に分類できます。

外部からの視点で脆弱性アセスメントを実施する場合は、外部からシステムに攻撃を試みます。会社を外から見ることで、クラッカーの視点に立つことができます。一般にルーティング可能な IP アドレス、DMZ にあるシステム、ファイアウォールの外部インターフェイスなど、クラッカーが目を付けるものに着目します。DMZ は非武装地帯 (demilitarized zone) を表し、企業のプライベート LAN などの信頼できる内部ネットワークと、公的なインターネットなどの信頼できない外部ネットワークの間にあるコンピューターまたは小さなサブネットワークに相当します。通常、DMZ には Web (HTTP) サーバー、FTP サーバー、SMTP (e-mail) サーバー、DNS サーバーなど、インターネットのトラフィックにアクセスできるデバイスが含まれます。

内部からの視点で脆弱性アセスメントを実施する場合、実行者は内部関係者であり、信頼されるステータスにあることから、有利な立場になります。内部からの視点は、実行者やその同僚がシステムにログオンした時点で得られるものです。プリントサーバー、ファイルサーバー、データベースなどのリソースを見ることができます。

これら 2 種類の脆弱性アセスメントには大きな違いがあります。社内のユーザーには、部外者が得られない多くの特権が付与されています。多くの組織では、侵入者を締め出すようにセキュリティーが設定されています。しかし、組織内の細かい部分 (部門内ファイアウォール、ユーザーレベルのアクセス制御および内部リソースに対する認証手順など) には、セキュリティー対策がほとんど行われていません。また、一般的にほとんどのシステムは社内にあるため、内部からの方がより多くのリソースを確認できます。いったん社外に移動すると、ステータスは信頼されない状態になります。通常、外部から利用できるシステムやリソースは、非常に限られたものになります。

脆弱性アセスメントと 侵入テスト の違いを考えてみましょう。脆弱性アセスメントを、侵入テストの第一歩と捉えてください。このアセスメントで得られる情報は、その後のテストで使用します。アセスメントは抜け穴や潜在的な脆弱性を検査する目的で行われるのに対し、侵入テストでは調査結果を実際に使用する試みがなされます。

ネットワークインフラストラクチャーのアセスメントは動的なプロセスです。セキュリティー (情報セキュリティーおよび物理的なセキュリティー) は動的なものです。アセスメントを実施することで概要が明らかになり、誤検出 (False positives) および検出漏れ (False negatives) が示される場合があります。誤検出は、実際には存在しない脆弱性をツールが検出することを指します。検出漏れは、実際の脆弱性が検出されないことを指します。

セキュリティー管理者の力量は、使用するツールとその管理者が有する知識で決まります。現在使用できるアセスメントツールのいずれかを選び、それらをシステムに対して実行すると、ほぼ間違いなく誤検出がいくつか見つかります。プログラム障害でもユーザーエラーでも、結果は同じです。ツールは、誤検出することもあれば、さらに悪い場合は、検出漏れをすることもあります。

脆弱性アセスメントと侵入テストの違いが定義されたところで、新たなベストプラクティスの一環として侵入テストを実施する前に、アセスメントの結果を注意深く確認し、検討してみましょう。

警告

実稼働システムで脆弱性を悪用する試みを行わないでください。システムおよびネットワークの生産性ならびに効率に悪影響を与える可能性があります。

脆弱性アセスメントの実施には、以下のような利点があります。

情報セキュリティーに事前にフォーカスできる
クラッカーが発見する前に潜在的な不正使用を発見できる
システムを最新の状態に維持し、パッチを適用できる
スタッフの成長と専門知識の開発を促す
経済的な損失や否定的な評判を減らす

1.3.2. 脆弱性評価に関する方法論の確立

脆弱性アセスメントの方法論が確立されれば、脆弱性アセスメント用のツール選択に役立ちます。現時点では、事前定義の方法論や業界で承認された方法論はありませんが、一般常識やベストプラクティスを適切なガイドとして活用できます。

ターゲットとは何を指していますか ?1 台のサーバー、またはネットワーク全体およびネットワーク内にあるすべてのサーバーを確認しますか ?会社外ですか ? それとも内部ですか ? この質問に対する回答は、選択したツールだけでなく、そのツールの使用方法を決定する際に重要です。

方法論の確立の詳細は、以下の Web サイトを参照してください。

https://www.owasp.org/ — 『The Open Web Application Security Project』

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
53/tcp  open   domain
80/tcp  open   http
113/tcp closed auth

Nmap は、リッスンまたはサービスの待機中の最も一般的なネットワーク通信ポートをテストします。この知識は、不要なサービスや未使用のサービスを終了したい管理者に役立ちます。

Nmap の使用に関する詳細は、以下の URL にある公式のホームページを参照してください。

http://www.insecure.org/

1.3.3.2. Nessus

Nessus はフルサービスセキュリティースキャナーです。Nessus のプラグインアーキテクチャーにより、ユーザーはシステムおよびネットワーク用にカスタマイズできます。Nessus は、スキャナーと同様に、依存する署名データベースと同じくらい優れています。幸いなことに、Nessus は頻繁に更新され、完全なレポート機能、ホストスキャン、およびリアルタイムの脆弱性検索を備えています。強力なツールや Nessus として頻繁に更新されるツールであっても、誤検出や誤検出が発生する可能性があることに注意してください。

注記

Nessus クライアントおよびサーバーソフトウェアを使用するには、サブスクリプションが必要です。これは、この人気のあるアプリケーションの使用に興味があるかもしれないユーザーへの参照として、このドキュメントに含まれています。

Nessus の詳細は、以下の URL にある公式 Web サイトを参照してください。

http://www.nessus.org/

1.3.3.3. OpenVAS

OpenVAS (Open Vulnerability Assessment System)は、脆弱性のスキャンや包括的な脆弱性管理に使用できるツールおよびサービスのセットです。OpenVAS フレームワークは、ソリューションのさまざまなコンポーネントを制御するための Web ベース、デスクトップ、およびコマンドラインツールを多数提供します。OpenVAS のコア機能はセキュリティースキャナーによって提供されます。セキュリティースキャナーは、毎日更新される 33 を超えるネットワーク脆弱性テスト(NVT)を使用します。Nessus ( 「Nessus」を参照)とは異なり、OpenVAS はサブスクリプションを必要としません。

OpenVAS の詳細については、以下の URL にある公式 Web サイトを参照してください。

http://www.openvas.org/

1.3.3.4. Nikto

Nikto は優れた 共通ゲートウェイインターフェイス (CGI)スクリプトスキャナーです。Nikto は CGI の脆弱性をチェックするだけでなく、侵入検知システムなど、簡潔な方法でチェックします。これには詳細なドキュメントが含まれており、プログラムを実行する前に入念に確認する必要があります。CGI スクリプトを提供する Web サーバーがある場合、Nikto はこれらのサーバーのセキュリティーをチェックするための優れたリソースになります。

Nikto の詳細は、以下の URL を参照してください。

http://cirt.net/nikto2

1.4. セキュリティーへの脅威

1.4.1. ネットワークセキュリティーへの脅威

ネットワークの以下の要素を設定する際に不適当なプラクティスが行われると、攻撃のリスクが増大します。

セキュリティーが十分ではないアーキテクチャー

間違った設定のネットワークは、未承認ユーザーの主要なエントリーポイントになります。信頼に基づいたオープンなローカルネットワークを、安全性が非常に低いインターネットに対して無防備な状態にしておくことは、犯罪の多発地区でドアを半開きにしておくようなものです。すぐに何かが起きることはないかもしれませんが、いずれ、誰かが、このチャンスを悪用するでしょう。

ブロードキャストネットワーク

システム管理者は、セキュリティー計画においてネットワーキングハードウェアの重要性を見落としがちです。ハブやルーターなどの単純なハードウェアは、ブロードキャストやノンスイッチの仕組みに基づいています。つまり、あるノードがネットワークを介して受信ノードにデータを送信するときは常に、受信ノードがデータを受信して処理するまで、ハブやルーターがデータパケットのブロードキャストを送信します。この方式は、外部侵入者やローカルホストの未認証ユーザーが仕掛けるアドレス解決プロトコル (ARP) およびメディアアクセスコントロール (MAC) アドレスの偽装に対して最も脆弱です。

集中化サーバー

ネットワーキングのもうひとつの落とし穴は、集中化されたコンピューティングの使用にあります。多くの企業では、一般的なコスト削減手段として、すべてのサービスを 1 台の強力なマシンに統合しています。集中化は、複数サーバーを設定するよりも管理が簡単で、コストを大幅に削減できるので便利です。ただし、集中化されたサーバーはネットワークにおける単一障害点となります。中央のサーバーが攻撃されると、ネットワークが完全に使用できなくなるか、データの不正操作や盗難が起きやすくなる可能性があります。このような場合は、中央サーバーがネットワーク全体へのアクセスを許可することになります。

1.4.2. サーバーセキュリティーへの脅威

サーバーには組織の重要情報が数多く含まれることが多いため、サーバーのセキュリティーは、ネットワークのセキュリティーと同様に重要です。サーバーが攻撃されると、クラッカーが意のままにすべてのコンテンツを盗んだり、不正に操作したりできるようになる可能性があります。以下のセクションでは、主要な問題の一部を詳述します。

未使用のサービスと開かれたポート

Red Hat Enterprise Linux 7 のフルインストールを行うと、アプリケーションとライブラリーのパッケージが 1000 個以上含まれます。ただし、サーバー管理者が、ディストリビューションに含まれるすべての個別パッケージをインストールすることはほとんどありません。代わりに、複数のサーバーアプリケーションを含むパッケージのベースインストールを行います。インストールされるパッケージの数を制限する理由の説明と追加のリソースについては「必要なパッケージの最小限のインストール」を参照してください。

システム管理者は、インストールに含まれるプログラムに注意を向けずにオペレーティングシステムをインストールしてしまうことがよくあります。これにより、不要なサービスがインストールされ、デフォルト設定でオンになっていることで、問題が発生する場合があります。つまり、管理者が気が付かないところで、Telnet、DHCP、DNS などの不要なサービスがサーバーやワークステーションで実行し、その結果、サーバーへの不要なトラフィックが発生したり、クラッカーがシステムのパスを悪用できてしまう可能性があります。ポートを閉じる方法や未使用のサービスを無効にする方法についての詳細は、「サービスのセキュア化」を参照してください。

パッチが適用されないサービス

デフォルトのインストールに含まれるほとんどのサーバーアプリケーションは、ソフトウェアの細部まで徹底的にテストされており、堅牢な作りになっています。何年も実稼働環境で使用される中で、そのコードは入念に改良され、数多くのバグが発見されて修正されてきました。

しかし、完璧なソフトウェアというものはなく、改良の余地は常にあります。または、比較的新しいソフトウェアは、実稼働環境に導入されてから日が浅く、他のサーバーソフトウェアほど普及していないこともあるため、厳密なテストが期待通りに行われていない状況も少なくありません。

開発者やシステム管理者が、サーバーアプリケーションで悪用される可能性のあるバグを発見することも多々あり、Bugtraq メーリングリスト (http://www.securityfocus.com)、Computer Emergency Response Team (CERT) Web サイト (http://www.cert.org) などで、バグ追跡やセキュリティー関連の Web サイトに関連する情報が公開されています。このような情報発信は、コミュニティーにセキュリティーの脆弱性を警告する効果的な方法ではありますが、システムに速やかにパッチを当てるかどうかは個々のシステム管理者が決定します。クラッカーも、パッチが適用されていないシステムがあればクラッキングできるように、脆弱性トラッキングサービスにアクセスし、関連情報を利用できることを考慮すると、速やかな対応がとりわけ重要になります。優れたシステム管理を行うには、警戒を怠らず、バグ追跡を絶えず行い、適切なシステム保守を実行して、よりセキュアなコンピューティング環境を維持することが求められます。

システムを最新状態に維持する方法についての詳細は、3章システムを最新の状態に保つ を参照してください。

管理における不注意

管理者がシステムにパッチを当てないことが、サーバーのセキュリティーに対する最大の脅威の 1 つになります。SysAdmin, Audit, Network, Security Institute (SANS) によると、コンピューターのセキュリティー脆弱性の主な原因は、訓練を受けていない人にセキュリティーの保守を任せ、保守を行うために必要な訓練や学ぶ時間を与えないことにあります。^[1] これは、管理者の経験の少なさだけでなく、管理者の過信やモチベーションの低さなども原因となります。

管理者が、サーバーやワークステーションにパッチを当てることを忘れたり、システムのカーネルやネットワーク通信のログメッセージを見落とす場合もあります。その他にも、よく起こるケースとして、サービスのデフォルトパスワードや鍵を変更しないまま放置しておくことが挙げられます。たとえば、データベースにはデフォルトの管理パスワードが設定されているものがありますが、ここでは、システム管理者がインストール後すぐにデフォルトパスワードを変更することを、データベース開発者は想定しています。しかし、データベース管理者がパスワードを変更することを忘れると、クラッカーの経験が浅くても、周知のデフォルトパスワードを使用してデータベースの管理者権限を得ることができます。この他に、管理者の不注意によりサーバーが危険にさらされる場合もあります。

本質的に安全ではないサービス

どんなに注意深い組織であっても、選択するネットワークサービスが本質的に安全でない限り、攻撃を受けやすくなります。たとえば、多くのサービスは、信頼できるネットワークでの使用を想定して開発されますが、このサービスが (本質的に信頼できない) インターネットで利用可能になる時点で、この仮定は成立しなくなります。

安全ではないネットワークサービスの例として、暗号化されていないユーザー名とパスワードを認証時に要求するサービスが挙げられます。具体例としては、Telnet や FTP の 2 つがあげられます。パケット盗聴ソフトウェアがリモートユーザーとこのようなサービスの間のトラフィックを監視していれば、ユーザー名とパスワードは簡単に傍受される可能性があります。

また、基本的にこのようなサービスはセキュリティー業界で 中間者 攻撃と呼ばれる攻撃の被害者になりやすくなります。この種の攻撃では、クラッカーが、ネットワーク上でクラッキングしたネームサーバーを操って、目標のサーバーではなくクラッカーのマシンを指定して、ネットワークトラフィックをリダイレクトします。誰かがサーバーへのリモートセッションを開くと、攻撃者のマシンがリモートサービスと無防備なユーザーとの間に存在する目に見えないパイプとして機能し、この間を流れる情報を取り込みます。このようにして、クラッカーはサーバーやユーザーに気付かれることなく、管理パスワードや生データを収集できるようになります。

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

Red Hat Enterprise Linux 7 では、デフォルトでは、上記のサービスがすべて無効になっています。ただし、管理者は、このようなサービスを使用しないといけない場合があるため、注意して設定することが重要となります。安全な方法でサービスをセットアップする詳細情報は、「サービスのセキュア化」を参照してください。

1.4.3. ワークステーションおよび家庭用 PC のセキュリティーに対する脅威

ワークステーションや家庭用 PC はネットワークやサーバーほど攻撃にさらされることはないかもしれませんが、クレジットカード情報のような機密データが含まれるため、システムクラッカーの標的になります。ワークステーションは知らぬ間に攻撃者によって選択され、一連の攻撃でスレーブマシンとして使用される可能性もあります。このため、ユーザーはワークステーションの脆弱性を理解しておくと、オペレーティングシステムの再インストールや、深刻な場合はデータ盗難からの回復といった問題から免れることができます。

不適切なパスワード

攻撃者が最も簡単にシステムへのアクセスを得る方法の 1 つとして、パスワードが適切でないことが挙げられます。パスワードを作成する際のよくある落とし穴を避ける方法については、「パスワードセキュリティー」を参照してください。

脆弱なクライアントアプリケーション

管理者がサーバーに十分な安全対策を施し、パッチを当てている場合でも、リモートユーザーによるアクセスが安全であるわけではありません。たとえば、サーバーが公開ネットワーク上で Telnet や FTP のサービスを提供している場合、攻撃者はネットワークを通過するプレーンテキストのユーザー名とパスワードを取り込み、アカウント情報を使用してリモートユーザーのワークステーションにアクセスすることが可能です。

SSH などのセキュアなプロトコルを使用している場合であっても、クライアントアプリケーションを定期的に更新していないと、リモートユーザーは特定の攻撃を受けやすくなる可能性があります。たとえば、v.1 SSH クライアントは悪意のある SSH サーバーからの X 転送攻撃に対して脆弱です。クライアントがサーバーに接続すると、攻撃者はネットワーク上でクライアントによるキー入力やマウス操作をひそかに収集できます。この問題は v.2 SSH プロトコルで修正されましたが、ユーザーはどのアプリケーションにこのような脆弱性があるかを追跡し、必要に応じてアプリケーションを更新する必要があります。

「デスクトップのセキュリティー」では、管理者とホームユーザーがコンピューターのワークステーションの脆弱性を限定するために取るべき手順をより詳細に説明しています。

^[1] http://www.sans.org/security-resources/mistakes.php

1.5. 一般的な不正使用と攻撃

表1.1「一般的な不正使用」では、侵入者が組織のネットワークリソースにアクセスするために使用する最も一般的な不正使用とエントリーポイントの例を挙げて詳しく説明します。この一般的な不正使用では、それがどのように実行され、管理者がその攻撃からネットワークをどのように適切に保護できるかを理解していることが重要になります。

表1.1 一般的な不正使用
不正使用	説明	注記
空またはデフォルトのパスワード	管理パスワードを空白のままにしたり、製品ベンダーが設定したデフォルトのパスワードをそのまま使用します。これは、ルーターやファイアウォールなどのハードウェアで最もよく見られますが、Linux で実行するサービスにはデフォルトの管理者パスワードが指定されているものがあります (ただし Red Hat Enterprise Linux 7 には含まれません)。	一般的に、ルーター、ファイアウォール、VPN、ネットワーク接続ストレージ (NAS) の機器など、ネットワークハードウェアに関連するものです。多数のレガシーオペレーティングシステム、特にサービスをバンドルしたオペレーティングシステム (UNIX や Windows など) でよく見られます。管理者が急いで特権ユーザーアカウントを作成したためにパスワードが空白のままになっていることがありますが、このような空白のパスワードは、このアカウントを発見した悪意のあるユーザーが利用できる絶好のエントリーポイントとなります。
デフォルトの共有鍵	セキュアなサービスでは、開発や評価テスト向けにデフォルトのセキュリティー鍵がパッケージ化されていることがあります。この鍵を変更せずにインターネットの実稼働環境に置いた場合は、同じデフォルトの鍵を持つすべてのユーザーがその共有鍵のリソースや、そこにあるすべての機密情報にアクセスできるようになります。	無線アクセスポイントや、事前設定済みでセキュアなサーバー機器に最も多く見られます。
IP スプーフィング	リモートマシンがローカルネットワークのノードのように動作し、サーバーに脆弱性を見つけるとバックドアプログラムまたはトロイの木馬をインストールして、ネットワークリソース全体へのコントロールを得ようとします。	スプーフィングは、攻撃者が標的となるシステムへの接続を調整するのに、TCP/IP シーケンス番号を予測しなければならないため、かなり難しくなりますが、クラッカーの脆弱性の攻撃を支援する利用可能なツールがいくつかあります。ソースベースの認証技術を使用するサービス( rsh、telnet、FTP など)を使用するターゲットシステムの実行サービスに依存します。これは、ssh または SSL/TLS で使用される PKI またはその他の形式の暗号化認証と比較すると推奨されません。
盗聴	2 つのノード間の接続を盗聴することにより、ネットワーク上のアクティブなノード間を行き交うデータを収集します。	この種類の攻撃には大抵、Telnet、FTP、HTTP 転送などのプレーンテキストの転送プロトコルが使用されます。リモートの攻撃者がこのような攻撃を仕掛けるには、LAN で、攻撃するシステムへのアクセス権が必要になります。通常、クラッカーは、LAN 上にあるシステムを危険にさらすためにアクティブ攻撃 (IP スプーフィングや中間者攻撃など) を仕掛けます。パスワードのなりすましに対する防護策としては、暗号化鍵交換、ワンタイムパスワード、または暗号化された認証によるサービス使用が挙げられます。通信中は強力な暗号化を実施することをお勧めします。
サービスの脆弱性	攻撃者はインターネットで実行しているサービスの欠陥や抜け穴を見つけます。攻撃者がこの脆弱性を利用する場合は、システム全体と格納されているデータを攻撃するだけでなく、ネットワーク上の他のシステムも攻撃する可能性があります。	CGI などの HTTP ベースのサービスは、リモートのコマンド実行やインタラクティブなシェルアクセスに対しても脆弱です。HTTP サービスが nobody などの権限のないユーザーとして実行している場合でも、設定ファイルやネットワークマップなどの情報が読み取られる可能性があります。または、攻撃者がサービス拒否攻撃を開始して、システムのリソースを浪費させたり、他のユーザーが利用できないようにする可能性もあります。開発時およびテスト時には気が付かない脆弱性がサービスに含まれることがあります。(アプリケーションのメモリーバッファー領域をあふれさせ、任意のコマンドを実行できるようなインタラクティブなコマンドプロンプトを攻撃者に提供するように、攻撃者が任意の値を使用してサービスをクラッシュさせるバッファーオーバーフローなどの) 脆弱性は、完全な管理コントロールを攻撃者に与えるものとなる可能性があります。管理者は、root 権限でサービスが実行されないようにし、ベンダー、または CERT、CVE などのセキュリティー組織がアプリケーション用のパッチやエラータ更新を提供していないかを常に注意する必要があります。
アプリケーションの脆弱性	攻撃者は、デスクトップやワークステーションのアプリケーション (電子メールクライアントなど) に欠陥を見つけ出し、任意のコードを実行したり、将来のシステム侵害のためにトロイの木馬を移植したり、システムを破壊したりします。攻撃を受けたワークステーションがネットワークの残りの部分に対して管理特権を持っている場合は、さらなる不正使用が起こる可能性があります。	ワークステーションとデスクトップは、ユーザーが侵害を防いだり検知するための専門知識や経験を持たないため、不正使用の対象になりやすくなります。認証されていないソフトウェアをインストールしたり、要求していないメールの添付ファイルを開く際には、それに伴うリスクについて個々に通知することが必須です。電子メールクライアントソフトウェアが添付ファイルを自動的に開いたり、実行したりしないようにするといった、予防手段を取ることが可能です。さらに、Red Hat Network や他のシステム管理サービスなどからワークステーションのソフトウェアを自動更新することにより、マルチシートのセキュリティーデプロイメントの負担を軽減できます。
サービス拒否攻撃 (DoS: Denial of Service)	単独の攻撃者または攻撃者のグループは、目標のホスト (サーバー、ルーター、ワークステーションのいずれか) に認証されていないパケットを送り、組織のネットワークまたはサーバーのリソースに対して攻撃を仕掛けます。これにより、正当なユーザーがリソースを使用できなくなります。	米国で最も多く報告された DOS の問題は、2000 年に発生しました。この時、通信量が非常に多い民間および政府のサイトが一部が利用できなくなりました。ゾンビ (zombie) や、リダイレクトされたブロードキャストノードとして動作する高帯域幅接続を有し、セキュリティー侵害された複数のシステムを使用して、調整された ping フラッド攻撃が行われたためです。通常ソースパケットは、真の攻撃元を調査するのが難しくなるよう、偽装 (または再ブロードキャスト) されています。 iptables および snort などのネットワーク侵入検知システムを使用したイングレスフィルターリング(IETF rfc2267)の進進は、管理者が分散 DoS 攻撃を追跡し、防止するのに役立ちます。

第2章インストール時におけるセキュリティーのヒント

セキュリティーは、Red Hat Enterprise Linux 7 をインストールするためにディスクドライブに CD または DVD を初めて挿入したときから始まります。最初からシステムのセキュリティーを設定することで、追加のセキュリティー設定を実装することがより簡単になります。

2.1. BIOS のセキュア化

BIOS (もしくは BIOS に相当するもの) およびブートローダーをパスワードで保護することで、システムに物理的にアクセス可能な未承認ユーザーがリムーバブルメディアを使用して起動したり、シングルユーザーモードで root 権限を取得することを防ぐことができます。このような攻撃に対するセキュリティー対策は、ワークステーションの情報の機密性とマシンの場所によって異なります。

たとえば、見本市で使用されていて機密情報を含んでいないマシンでは、このような攻撃を防ぐことが重要ではないかもしれません。しかし、同じ見本市で、企業ネットワークに対して暗号化されていない SSH 秘密鍵のある従業員のノートパソコンが、誰の監視下にもなく置かれていた場合は、重大なセキュリティー侵害につながり、その影響は企業全体に及ぶ可能性があります。

一方で、ワークステーションが権限のあるユーザーもしくは信頼できるユーザーのみがアクセスできる場所に置かれてるのであれば、BIOS もしくはブートローダーの安全確保は必要ない可能性もあります。

2.1.1. BIOS パスワード

コンピューターの BIOS をパスワードで保護する主な 2 つの理由を以下に示します。^[2]:

BIOS 設定の変更を防止する - 侵入者が BIOS にアクセスした場合は、CD-ROM やフラッシュドライブから起動するように設定できます。このようにすると、侵入者がレスキューモードやシングルユーザーモードに入ることが可能になり、システムで任意のプロセスを開始したり、機密性の高いデータをコピーできるようになってしまいます。
システムの起動を防止する - BIOS の中には起動プロセスをパスワードで保護できるものもあります。これを有効にすると、攻撃者は BIOS がブートローダーを開始する前にパスワード入力を求められます。

BIOS パスワードの設定方法はコンピューターメーカーで異なるため、具体的な方法はコンピューターのマニュアルを参照してください。

BIOS パスワードを忘れた場合は、マザーボードのジャンパーでリセットするか、CMOS バッテリーを外します。このため、可能な場合はコンピューターのケースをロックすることが推奨されます。ただし、CMOS バッテリーを外す前にコンピューターもしくはマザーボードのマニュアルを参照してください。

2.1.1.1. 非 BIOS ベースのシステムの保護

その他のシステムやアーキテクチャーでは、異なるプログラムを使用して x86 システムの BIOS とほぼ同等の低レベルのタスクを実行します。Unified Extensible Firmware Interface (UEFI) シェルなどがこの例になります。

BIOS のようなプログラムをパスワード保護する方法は、メーカーにお問い合わせください。

2.2. ディスクのパーティション設定

Red Hat は、/boot ディレクトリー、/ ディレクトリー、/home ディレクトリー、/ tmp ディレクトリー、および / var /tmp / ディレクトリーに個別のパーティションを作成することを推奨します。各パーティションを作成する理由は以下のようになります。

/boot: このパーティションは、システムの起動時にシステムが最初に読み込むパーティションです。Red Hat Enterprise Linux 7 でシステムを起動するのに使用するブートローダーとカーネルイメージはこのパーティションに保存されます。このパーティションは暗号化しないでください。このパーティションが / に含まれており、そのパーティションが暗号化されているなどの理由で利用できなくなると、システムを起動できなくなります。
/home: ユーザーデータ(/home)が別のパーティションではなく / に保存されている場合、パーティションが満杯になり、オペレーティングシステムが不安定になる可能性があります。また、システムを Red Hat Enterprise Linux 7 の次のバージョンにアップグレードする際に、/home パーティションにデータを保存できると、このデータはインストール時に上書きされないため、はるかに簡単になります。ルートパーティション(/)が破損すると、データが完全に失われる可能性があります。したがって、パーティションを分けることが、データ損失に対する保護につながります。また、このパーティションを、頻繁にバックアップを作成する対象にすることも可能です。
/tmp および /var/tmp/: /tmp ディレクトリーおよび /var/tmp/ ディレクトリーは、どちらも長期間保存する必要がないデータを保存するために使用されます。しかし、このいずれかのディレクトリーでデータがあふれると、ストレージ領域がすべて使用されてしまう可能性があります。これが発生し、これらのディレクトリーが / に保存されていると、システムが不安定になり、クラッシュする可能性があります。そのため、このディレクトリーは個別のパーティションに移動することが推奨されます。

注記

インストールプロセス時に、パーティションを暗号化するオプションがあります。パスフレーズを入力する必要があります。これは、パーティションのデータを保護するのに使用されるバルク暗号鍵を解除する鍵として使用されます。詳細は、「LUKS ディスクの暗号化の使用」を参照してください。

2.3. 必要なパッケージの最小限のインストール

コンピューターの各ソフトウェアには脆弱性が潜んでいる可能性があるため、実際に使用するパッケージのみをインストールすることがベストプラクティスになります。インストールを DVD から行う場合は、インストールしたいパッケージのみを選択するようにします。その他のパッケージが必要になる場合は、後でいつでもシステムに追加できます。

最小 インストール環境のインストールに関する詳細は、Red Hat Enterprise Linux 7 インストールガイドのソフトウェアの選択の章を参照してください。最小限のインストールは、--nobase オプションを使用したキックスタートファイルでも実行できます。キックスタートインストールの詳細については、Red Hat Enterprise Linux 7 インストールガイドのパッケージの選択セクションを参照してください。

2.4. インストールプロセス時のネットワーク接続の制限

Red Hat Enterprise Linux をインストールする際に使用するインストールメディアは、特定のタイミングで作成されたスナップショットです。そのため、セキュリティー修正が最新のものではなく、このインストールメディアで設定するシステムが公開されてから修正された特定の問題に対して安全性に欠ける場合があります。

脆弱性が含まれる可能性のあるオペレーティングシステムをインストールする場合には、必ず、公開レベルを、必要最小限のネットワークゾーンに限定してください。最も安全な選択肢は、インストールプロセス時にマシンをネットワークから切断した状態にするネットワークなしのゾーンです。インターネット接続からのリスクが最も高く、一方で LAN またはイントラネット接続で十分な場合もあります。セキュリティーのベストプラクティスに従い、ネットワークから Red Hat Enterprise Linux をインストールする場合は、お使いのリポジトリーに最も近いゾーンを選択するようにしてください。

ネットワーク接続の設定に関する詳しい情報は、Red Hat Enterprise Linux 7 インストールガイドのネットワーク & ホストの章を参照してください。

2.5. インストール後の手順

以下は、Red Hat Enterprise Linux のインストール直後に実行する必要があるセキュリティー関連の手順です。

システムを更新します。root で以下のコマンドを入力します。
```
~]# yum update
```
ファイアウォールサービスの firewalld は、Red Hat Enterprise Linux のインストールで自動的に有効になっていますが、キックスタート設定などで明示的に無効となっている場合もあります。このような場合は、ファイアウォールを再度有効にすることが推奨されます。
firewalld を開始するには、root で次のコマンドを実行します。
```
~]# systemctl start firewalld
~]# systemctl enable firewalld
```
セキュリティーを強化するために、不要なサービスは無効にしてください。たとえば、コンピューターにプリンターがインストールされていない場合は、以下のコマンドを使用して cups サービスを無効にします。
```
~]# systemctl disable cups
```
アクティブなサービスを確認するには、次のコマンドを実行します。
```
~]$ systemctl list-units | grep service
```

2.6. 関連情報

インストールに関する全般的な情報は、Red Hat Enterprise Linux 7 インストールガイドを参照してください。

^[2] システム BIOS はメーカーによって異なるため、いずれかのタイプのパスワード保護のみをサポートするものもあれば、いずれのタイプのパスワード保護もサポートしないものもあります。

第3章システムを最新の状態に保つ

この章では、システムを最新の状態に保つためのプロセスについて説明します。これには、セキュリティー更新のインストール方法の計画と設定、新しく更新されたパッケージによって導入された変更の適用、およびセキュリティー勧告を追跡するための Red Hat カスタマーポータルの使用が含まれます。

3.1. インストール済みソフトウェアのメンテナーンス

セキュリティー上の脆弱性が検出されると、潜在的なセキュリティーリスクを制限するために、影響を受けるソフトウェアを更新する必要があります。ソフトウェアが現在サポートされている Red Hat Enterprise Linux ディストリビューション内のパッケージの一部である場合、Red Hat では、脆弱性を修正する更新されたパッケージをできるだけ早くリリースするよう尽力しています。

多くの場合、特定のセキュリティーの不正使用に関する発表には、問題を修正するパッチ (またはソースコード) も含まれます。このパッチは、その後、Red Hat Enterprise Linux パッケージに適用され、エラータ更新としてテストされ、リリースされます。しかし、発表にパッチが含まれていない場合、Red Hat の開発者はまずソフトウェアのメンテナーと協力して問題を解決します。問題が修正されると、パッケージはエラータ更新としてテストされ、リリースされます。

お使いのシステムで使用されているソフトウェアのエラータ更新がリリースされた場合は、システムが潜在的に脆弱となる時間を最小限に抑えるため、影響を受けるパッケージをできるだけ早く更新することを強く推奨します。

3.1.1. セキュリティーの更新の立案と設定

すべてのソフトウェアにはバグが含まれます。多くの場合、これらのバグは、システムを悪意のあるユーザーにさらす可能性のある脆弱性をもたらすことがあります。更新されていないパッケージは、コンピューターへの不正侵入の原因としてよく知られています。発見された脆弱性を迅速に排除し、悪用されないようにするために、セキュリティーパッチを適時にインストールする計画を実施します。

セキュリティー更新が利用可能になったらテストし、インストールするようにスケジュールします。更新がリリースされてからシステムにインストールされるまでの間、システムを保護するために追加の制御を行う必要があります。これらの制御は脆弱性そのものによって異なりますが、追加のファイアウォールルール、外部ファイアウォールの使用、またはソフトウェア設定の変更が含まれる場合があります。

サポート対象パッケージのバグは、エラータメカニズムを使用して修正されます。エラータは、1 つ以上のRPMパッケージとそのエラータが対処する問題の簡単な説明で設定されています。すべてのエラータは、アクティブなサブスクリプションをお持ちのお客様に Red Hat Subscription Management サービスで配布されます。セキュリティー問題に対処するエラータは、Red Hat セキュリティーアドバイザリー と呼ばれます。

セキュリティーエラータを使った作業についての詳細情報は、「カスタマーポータルでのセキュリティーアドバイザリーの表示」を参照してください。RHN Classic からの移行方法など、Red Hat Subscription Management サービスの詳細は、Red Hat Subscription Management に関するドキュメントを参照してください。

3.1.1.1. Yum のセキュリティー機能の使用

Yum パッケージマネージャーには、セキュリティーエラータの検索、一覧表示、表示、インストールに使用できるセキュリティー関連の機能が複数含まれています。これらの機能を使用すると、Yum を使用してセキュリティー更新以外のものをインストールすることもできます。

システムで利用可能なセキュリティー関連の更新を確認するには、root で以下のコマンドを入力します。

~]# 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 updateinfo で使用できるセキュリティー関連コマンドです。」を参照してください。

表3.1 yum updateinfo で使用できるセキュリティー関連コマンドです。
コマンド	説明
[アドバイザリー]	1 つ以上のアドバイザリーに関する情報を表示します。advisories をアドバイザリー番号に置き換えます。
cves	CVE (Common Vulnerabilities and Exposures) に関連する情報のサブセットを表示します。
セキュリティーまたは秒	すべてのセキュリティー関連情報を表示します。
severity [severity_level] または sev [severity_level]	指定された severity_level のセキュリティー関連パッケージに関する情報を表示します。

3.1.2. パッケージの更新とインストール

システムでソフトウェアを更新する場合は、信頼できるソースから更新をダウンロードすることが重要です。攻撃者は、問題を解決するはずのパッケージと同じバージョン番号で、異なるセキュリティーエクスプロイトを施したパッケージを簡単に作り直し、インターネット上で公開することができます。こうした事態が発生すると、元の RPM に対するファイル検証などのセキュリティー対策を講じても、不正アクセスを検知することができません。このため、RPM は Red Hat などの信頼できるソールからのみダウンロードし、その保全性を検証するためにパッケージの署名を確認することが極めて重要になります。

Yum パッケージマネージャーの使用方法に関する詳細情報は、Red Hat Enterprise Linux 7 システム管理者のガイドの Yum の章を参照してください。

3.1.2.1. 署名パッケージの検証

すべての Red Hat Enterprise Linux パッケージは、Red Hat GPG キーで署名されます。gpg は GNU Privacy Guard または GnuPG の略です。これは、分散ファイルの信頼性を確保するために使用するフリーソフトウェアパッケージです。パッケージ署名の検証に失敗した場合は、パッケージが改ざんされている可能性があるため、信頼することができません。

Yum パッケージマネージャーを使用すると、インストールまたはアップグレードするすべてのパッケージを自動的に検証できます。この機能はデフォルトで無効にされています。システムでこのオプションを設定するには、/etc/yum.conf 設定ファイルで gpgcheck 設定ディレクティブが 1 に設定されていることを確認します。

ファイルシステム上のパッケージファイルを手動で確認するには、次のコマンドを使用します。

rpmkeys --checksig package_file.rpm

Red Hat パッケージの署名のプラクティスに関する追加情報は、Red Hat カスタマーポータルの Product Signing (GPG) Keys の記事を参照してください。

3.1.2.2. 署名パッケージのインストール

ファイルシステムから検証済みのパッケージをインストールするには、「署名パッケージの検証」を参照してください。パッケージの検証方法は、以下のように root で yum install コマンドを実行します。

yum install package_file.rpm

シェルグロブを使用して、複数のパッケージを一度にインストールします。たとえば、次のコマンドは、現在のディレクトリーにすべての .rpm パッケージをインストールします。

yum install *.rpm

重要

セキュリティーエラータをインストールする前に、エラータレポートに含まれる特別な指示を必ず読み、それに従って実行してください。エラータ更新に基づく変更の適用についての全般的な指示は、「インストールされた更新によって導入された変更の適用」を参照してください。

3.1.3. インストールされた更新によって導入された変更の適用

セキュリティーエラータや更新をダウンロードしてインストールした後は、古いソフトウェアの使用を停止し、新しいソフトウェアの使用を開始することが重要です。これがどのように行われるかは、更新されたソフトウェアのタイプによって異なります。以下のリストは、ソフトウェアの一般的なカテゴリーを項目別に分類し、パッケージのアップグレード後に更新されたバージョンを使用するための手順を示したものです。

注記

一般に、システムを再起動することが、ソフトウェアパッケージの最新バージョンが使用されていることを確認する最も確実な方法です。ただし、このオプションは必ずしも必須ではなく、システム管理者が常に利用できるわけでもありません。

アプリケーション

ユーザースペースアプリケーションとは、ユーザーが起動することができるすべてのプログラムのことです。通常、このようなアプリケーションは、ユーザー、スクリプト、または自動タスクユーティリティーが、これらのアプリケーションを起動したときにのみ使用されます。

このようなユーザースペースのアプリケーションが更新されたら、システム上のアプリケーションのインスタンスをすべて停止し、プログラムを再度起動して更新されたバージョンを使用します。

カーネル

カーネルは、Red Hat Enterprise Linux 7 オペレーティングシステムの中核となるソフトウェアコンポーネントです。メモリー、プロセッサー、周辺機器へのアクセスを管理し、すべてのタスクをスケジューリングします。

カーネルはその中心的なロールを担っているため、コンピューターを再起動せずにカーネルを再起動することはできません。そのため、システムを再起動するまで、更新されたバージョンのカーネルを使用することはできません。

KVM

qemu-kvm および libvirt のパッケージが更新されると、すべてのゲスト仮想マシンを停止して、関連の仮想化モジュールを再読み込みし (またはホストシステムを再起動し)、仮想マシンを再起動する必要があります。

lsmod コマンドを使用して、kvm、kvm-intel、または kvm -amd からのモジュールが読み込まれます。次に、modprobe -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.0 ライブラリーにリンクするものを確認するには、以下を入力します。

~]# 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 /usr/lib64/libwrap.so.0.7.6
gnome-she 12454 test mem    REG  253,0    42520 34121785 /usr/lib64/libwrap.so.0.7.6

このコマンドは、ホストアクセス制御に TCP ラッパーを使用する実行中のすべてのプログラムの一覧を返します。したがって、tcp_wrappers パッケージの更新時に一覧表示されるプログラムをすべて停止し、再起動する必要があります。

systemd サービス

systemd サービスは通常ブートプロセス中に起動する永続的なサーバープログラムです。systemd サービスの例としては、sshd または vsftpd などがあります。

これらのプログラムは通常、マシンが実行されている限りメモリーに保持されるため、更新された各 systemd サービスは、パッケージがアップグレードされた後に停止して再起動する必要があります。これは、systemctl コマンドを使用して、root ユーザーとして実行できます。

systemctl restart service_name

service_name を、sshd など、再起動するサービスの名前に置き換えます。

他のソフトウェア

下のアプリケーションを正しく更新するには、以下のリンク先のリソースに記載されている手順に従ってください。

Red Hat Directory Server - 問題の Red Hat Directory Server バージョンの『リリースノート』 ( https://access.redhat.com/documentation/ja-JP/Red_Hat_Directory_Server/ )を参照してください。
Red Hat Enterprise Virtualization Manager - 問題となっている Red Hat Enterprise Virtualization のバージョンの『インストールガイド』 ( https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Virtualization/ )を参照してください。

3.2. Red Hat カスタマーポータルの使用

https://access.redhat.com/ の Red Hat カスタマーポータルは、Red Hat 製品に関連する公式情報を提供するお客様向けのメインリソースです。カスタマーポータルでは、ドキュメントの検索、サブスクリプションの管理、製品や更新のダウンロード、サポートケースの作成のほか、セキュリティーの更新情報についても知ることができます。

3.2.1. カスタマーポータルでのセキュリティーアドバイザリーの表示

アクティブなサブスクリプションがあるシステムに関連するセキュリティーアドバイザリー（エラータ）を表示するには、https://access.redhat.com/ でカスタマーポータルにログインし、メインページの Download Products & Updates ボタンをクリックします。Software & Download Center ページを入力するときは、エラータボタンをクリックして、登録済みのシステムに対応するアドバイザリーの一覧が表示されます。

アクティブなすべての Red Hat 製品のセキュリティー更新の一覧を表示するには、ページ上部のナビゲーションメニューを使用して Security → Security Updates → Active Products に移動します。

表の左側にあるエラータコードをクリックして、個々のアドバイザリーに関する詳細情報を表示します。次のページには、原因、結果、必要な修正など、特定のエラータに関する説明だけでなく、特定のエラータが更新するすべてのパッケージのリストと、更新の適用方法についても説明されています。このページには、関連するリファレンス (関連する CVE など) へのリンクも含まれています。

3.2.2. カスタマーポータルページでの CVE への移動

CVECommon Vulnerabilities and Exposures) プロジェクトは、MITRE Corporation によって管理されており、脆弱性やセキュリティーエクスポージャーの標準的な名称のリストです。カスタマーポータルの Red Hat 製品に関連する CVE の一覧を表示するには、https://access.redhat.com/ でアカウントにログインし、ページ上部のナビゲーションメニューを使用して Security → Resources → CVE Database に移動します。

表の左側にある CVE コードをクリックすると、個々の脆弱性の詳細情報が表示されます。次のページには、指定されたCVEの説明だけでなく、影響を受ける Red Hat 製品のリストと関連する Red Hat のエラータへのリンクが記載されています。

3.2.3. 問題の重大度の分類を理解する

Red Hat 製品で発見されたすべてのセキュリティー問題は、問題の重大度に応じて Red Hat 製品セキュリティー によって影響度が評価されます。影響度は、低度の影響、中程度の影響、重要な影響、および重大な影響の 4 段階評価になります。さらに、すべてのセキュリティー問題は、CVSS(Common Vulnerability Scoring System) ベーススコアを使用して評価されます。

これらの評価を組み合わせることで、セキュリティー問題の影響を理解し、システムのアップグレード戦略のスケジュールと優先順位を決定することができます。なお、この評価は、現在の脅威レベルではなく、バグの技術的分析に基づいた特定の脆弱性の潜在的リスクを反映したものであることに注意してください。つまり、特定の欠陥に対するエクスプロイトがリリースされても、セキュリティーの影響度の評価は変更されないことを意味します。

カスタマーポータルの各レベルの重大度評価の詳細は、Severity Ratingsのページをご覧ください。

3.3. 関連情報

セキュリティー更新、その適用方法、Red Hat カスタマーポータル、および関連トピックの詳細については、以下のリソースを参照してください。

インストールされているドキュメント

yum(8) : Yum パッケージマネージャーの man ページには、Yum を使用してシステムにパッケージをインストール、更新、および削除する方法に関する情報が記載されています。
rpmkeys(8) : rpmkeys ユーティリティーの man ページでは、このプログラムを使用してダウンロードしたパッケージの信頼性を検証する方法が説明されています。

オンラインドキュメント

Red Hat Enterprise Linux 7 システム管理者のガイド: Red Hat Enterprise Linux 7 『のシステム管理者ガイド』では、Red Hat Enterprise Linux 7 システムでパッケージのインストール、更新、および削除に使用する Yum コマンドおよび rpm コマンドの使用について説明しています。
Red Hat Enterprise Linux 7 SELinux ユーザーおよび管理者のガイド: Red Hat Enterprise Linux 7 『の SELinux ユーザーおよび管理者のガイド』では、SELinux の 強制アクセス制御 メカニズムの設定が説明されています。

Red Hat カスタマーポータル

Red Hat カスタマーポータル (セキュリティー) — カスタマーポータルのセキュリティーセクションには、Red Hat CVE データベースなどの最も重要なリソースへのリンクのほか、Red Hat 製品セキュリティーの連絡先が含まれています。
Red Hat セキュリティーブログ — Red Hat のセキュリティー専門家による最新のセキュリティー問題に関する記事。

第4章ツールとサービスでシステムを強化する

4.1. デスクトップのセキュリティー

Red Hat Enterprise Linux 7 は、攻撃に対してデスクトップを強化し、不正アクセスを防止するためのいくつかの方法を提供します。このセクションでは、ユーザーパスワード、セッションとアカウントのロック、およびリムーバブルメディアの安全な取り扱いに関する推奨事項を説明します。

4.1.1. パスワードセキュリティー

パスワードは、Red Hat Enterprise Linux 7 がユーザーの ID を確認するために使用する主な方法です。このため、パスワードのセキュリティーは、ユーザー、ワークステーション、ネットワークを保護するために非常に重要です。

セキュリティー上の理由から、インストールプログラムは、セキュアハッシュアルゴリズム 512(SHA512) およびシャドウパスワードを使用するようにシステムを設定します。これらの設定を変更しないことを強く推奨します。

インストール時にシャドウパスワードの選択を解除すると、すべてのパスワードが、誰でも読み取り可能な /etc/passwd ファイルに一方向ハッシュとして保存されます。これにより、システムはオフラインのパスワードクラッキング攻撃に対して脆弱になります。侵入者が通常のユーザーとしてマシンにアクセスできる場合は、/etc/passwd ファイルを自分のマシンにコピーし、それに対して任意の数のパスワードクラッキングプログラムを実行できます。ファイル内に安全でないパスワードがあれば、パスワードクラッカーに発見されるのは時間の問題です。

シャドウパスワードは、root ユーザーのみが読み取り可能なファイル /etc/shadow にパスワードハッシュを保存することで、このタイプの攻撃を排除します。

これにより、潜在的な攻撃者は、SSH や FTP などのマシン上のネットワークサービスにログインして、リモートでパスワードクラッキングを試みるようになります。この種のブルートフォース攻撃ははるかに遅く、何百回ものログイン試行の失敗がシステムファイルに書き込まれるため、明らかな痕跡が残ります。もちろん、クラッカーがパスワードの弱いシステムで深夜に攻撃を開始した場合、夜明け前にアクセスできるようになり、ログファイルを編集して痕跡を消している可能性もある。

形式およびストレージの考慮事項に加えて、コンテンツの問題があります。パスワードクラッキング攻撃からアカウントを保護するためにユーザーができる最も重要なことは、強力なパスワードを作成することです。

注記

Red Hat では、Red Hat Identity Management (IdM) などの中央認証ソリューションを使用することを推奨しています。ローカルパスワードの使用よりも、中央ソリューションの使用が推奨されます。詳細は、次を参照してください。

4.1.1.1. 強固なパスワードの作成

安全なパスワードを作成する際、ユーザーは、短いパスワードや複雑なパスワードよりも長いパスワードの方が強力であることを覚えておく必要があります。数字や特殊文字、大文字を含むとはいえ、たった 8 文字のパスワードを作成することは得策ではありません。John The Ripper などのパスワードクラッキングツールは、このような、人が覚えにくいパスワードの解読に最適化されています。

情報理論では、エントロピーは確率変数に関連する不確実性のレベルであり、ビットで示されます。エントロピー値が高いほど、パスワードの安全性は高くなります。NIST SP 800-63-1 によると、一般的に選択される 50000 個のパスワードで設定される辞書に存在しないパスワードには、少なくとも 10 ビットのエントロピーが必要です。そのため、4 つのランダムな単語で設定されるパスワードは、約 40 ビットのエントロピーを含んでいます。セキュリティーを強化するために複数の単語で設定される長いパスワードは、パスフレーズ とも呼ばれます。次に例を示します。

randomword1 randomword2 randomword3 randomword4

システムが大文字、数字、または特殊文字の使用を強制する場合、上記の推奨事項に続くパスフレーズは、最初の文字を大文字に変更し、1!を追加するなどして簡単に変更できます。このような変更は、パスフレーズのセキュリティーを大幅に 向上させるものではない ことに注意してください。

自分でパスワードを作成するもう 1 つの方法は、パスワードジェネレータを使用することです。pwmake は、大文字、小文字、数字、特殊文字の 4 つの文字グループすべてで設定されるランダムパスワードを生成するためのコマンドラインツールです。このユーティリティーでは、パスワードの生成に使用するエントロピービットの数を指定することができます。エントロピーは /dev/urandom からプルされます。指定できる最小のビット数は 56 ビットで、ブルートフォース攻撃がまれなシステムやサービスのパスワードとしては十分と言えます。攻撃者がパスワードハッシュファイルに直接アクセスできないアプリケーションでは、64 ビットで十分です。攻撃者がパスワードハッシュを直接入手する可能性がある場合や、パスワードを暗号化キーとして使用する場合は、80 ビットから 128 ビットを使用する必要があります。無効な数のエントロピービットを指定すると、pwmake はデフォルトのビットを使用します。128 ビットのパスワードを作成する場合は、次のコマンドを入力します。

pwmake 128

安全なパスワードの作成にはさまざまなアプローチがありますが、以下のような悪い習慣は必ず避けてください。

辞書の単語 1 つ、外国語の単語 1 つ、倒置語、または数字のみを使用すること。
パスワードまたはパスフレーズが 10 文字未満であること。
キーボードレイアウトの一連のキーを使用すること。
パスフレーズを書き留めること。
生年月日、記念日、家族の名前、またはペットの名前など、個人情報をパスワードに使用すること。
複数のマシンで同じパスフレーズやパスワードを使用すること。

安全なパスワードの作成は必須ですが、特に大規模な組織内のシステム管理者にとっては、パスワードを適切に管理することも重要です。以下のセクションでは、組織内でユーザーパスワードを作成し、管理するためのグッドプラクティスについて詳しく説明します。

4.1.1.2. 強固なパスワードの強制

多数のユーザーを抱える組織では、システム管理者は、強力なパスワードの使用を強制するために、2 つの基本的なオプションを利用することができます。システム管理者がユーザーのパスワードを作成することもできますし、パスワードの強度が十分であることを確認しながら、ユーザーが独自のパスワードを作成できるようにすることもできます。

ユーザーのパスワードを作成することで、パスワードの安全性は確保されますが、組織が大きくなるにつれ、大変な作業となります。また、ユーザーがパスワードを書き留めることで、パスワードが流出する危険性も高まります。

このような理由から、多くのシステム管理者は、ユーザー自身がパスワードを作成することを望んでいますが、それらのパスワードが十分に強力であるかについては積極的に検証しています。場合によっては、管理者は、パスワードエージングを通じて、ユーザーに定期的にパスワードを変更するように強制することもあります。

ユーザーがパスワードを作成または変更するように求められると、PAM-aware (Pluggable Authentication Modules)である passwd コマンドラインユーティリティーを使用して、パスワードが短すぎるか、または簡単に解読できるかどうかを確認できます。このチェックは、pam_pwquality.so PAM モジュールにより実行されます。

注記

Red Hat Enterprise Linux 7 では、PAM モジュール pam_pwquality が、パスワード品質チェックのデフォルトモジュールとして Red Hat Enterprise Linux 6 で使用されていました。これは、pam_splunk と同じバックエンドを使用します。

pam_pwquality モジュールは、パスワード強度を一連のルールに対してチェックするために使用されます。その手順は 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    required    pam_pwquality.so retry=3

チェックのオプションは、1 行に 1 つずつ指定します。たとえば、文字の最小長が 8 文字のパスワードを要求するには、以下の行を /etc/security/pwquality.conf ファイルに追加します。

minlen = 8
minclass = 4

文字シーケンスと同じ連続した文字のパスワード強度チェックを設定するには、以下の行を /etc/security/pwquality.conf に追加します。

maxsequence = 3
maxrepeat = 3

この例では、入力されたパスワードには、abcd などの単調なシーケンスで 3 文字以上を含み、1111 などの同一の 3 文字を超える連続した文字を含めることはできません。

注記

root ユーザーは、パスワード作成のルールを適用するユーザーであるため、警告メッセージが表示されても、自分自身または通常のユーザーに任意のパスワードを設定できます。

4.1.1.3. パスワードエージングの設定

パスワードエージングは、組織内の不正なパスワードから保護するためにシステム管理者が使用するもう一つの技術です。パスワードエージングとは、指定された期間 (通常は 90 日間) が経過すると、ユーザーは新しいパスワードを作成するように求められることを意味します。この背景には、ユーザーが定期的にパスワードを変更することを強制された場合、クラックされたパスワードは侵入者にとって限られた時間しか有効でないという理論があります。しかし、パスワードエージングには、ユーザーがパスワードを書き留める可能性が高くなるというデメリットがあります。

Red Hat Enterprise Linux 7 でパスワードエージングを指定するには、コマンドを使用してください。

重要

Red Hat Enterprise Linux 7 では、シャドウパスワードはデフォルトで有効になっています。詳細は、Red Hat Enterprise Linux 7 System Administrator's Guide を参照してください。

コマンドの -M オプションは、パスワードの最大有効日数を指定します。たとえば、ユーザーのパスワードを 90 日間で期限切れになるように設定するには、以下のコマンドを使用します。

chage -M 90 username

上記のコマンドでは、username をユーザー名に置き換えます。パスワードの有効期限を無効にするには、-M オプションの 後に -1 の値を使用します。

このコマンドで使用できるオプションの詳細は、以下の表を参照してください。

表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` オプションで指定した日数を足した日数が、現在の日数より少ない場合、ユーザーはアカウントを使用する前にパスワードを変更する必要があります。
`-W` days	パスワードの有効期限の何日前にユーザーに警告を発するかを指定します。

インタラクティブモードでコマンドを使用して、複数のパスワードエージングおよびアカウントの詳細を変更することもできます。次のコマンドを使用して、インタラクティブモードに入ります。

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]:

ユーザーが初めてログインしたときにパスワードが失効するように設定することができます。これにより、ユーザーはすぐにパスワードを変更せざるを得なくなります。

初期パスワードを設定します。デフォルトのパスワードを割り当てるには、root で次のコマンドを実行します。
```
passwd username
```
警告
passwd ユーティリティーには、null パスワードを設定するオプションがあります。null パスワードの使用は便利ですが、安全ではありません。第三者がログインして、安全でないユーザー名を使用してシステムにアクセスする可能性があるためです。null パスワードの使用は可能な限り避けてください。避けられない場合は、null パスワードでアカウントのロックを解除する前に、ユーザーがログインする準備ができていることを常に確認してください。
root で以下のコマンドを実行して、パスワードの即時有効期限を強制します。
```
chage -d 0 username
```
このコマンドは、パスワードが最後に変更された日付の値をエポック (1970 年 1 月 1 日) に設定します。この値は、パスワードエージングポリシーがある場合、それに関係なく、パスワードの即時期限切れを強制します。

最初のログイン時に、ユーザーは新しいパスワードの入力を求められるようになりました。

4.1.2. アカウントのロック

Red Hat Enterprise Linux 7 では、pam_faillock PAM モジュールを使用すると、システム管理者は、指定された回数試行の失敗後にユーザーアカウントをロックアウトできます。ユーザーのログイン試行を制限することは、主に、ユーザーのアカウントパスワードを取得することを目的としたブルートフォース攻撃の可能性を防ぐことを目的としたセキュリティー対策として機能します。

pam_faillock モジュールでは、失敗したログイン試行が、各ユーザーの個別のファイル( /var/run/faillock ディレクトリー内)に保存されます。

注記

失敗した試行のログファイルの行の順序は重要です。この順序を変更すると、even_deny_root オプションが使用されると、root ユーザーアカウントを含むすべてのユーザーアカウントがロックされる可能性があります。

以下の手順でアカウントロックを設定します。

3 回失敗した後に root 以外のユーザーをロックアウトし、10 分後にそのユーザーのロックを解除するには、/etc/pam.d/system- auth ファイルおよび /etc/pam.d/password-auth ファイルの auth セクションに 2 行を追加します。編集後、両方のファイルの auth セクション全体は以下のようになります。
```
auth        required      pam_env.so
auth        required      pam_faillock.so preauth silent audit deny=3 unlock_time=600
auth        sufficient    pam_unix.so nullok try_first_pass
auth        [default=die] pam_faillock.so authfail audit deny=3 unlock_time=600
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        required      pam_deny.so
```
2 行目、4 行目が追加されました。
前の手順で指定した両方のファイルの account セクションに、以下の行を追加します。
```
account     required      pam_faillock.so
```

root ユーザーのアカウントロックを適用するには、/etc/pam.d/system-auth ファイルおよび /etc/pam.d/password-auth ファイルの pam_faillock エントリーに even_deny_root オプションを追加します。

auth        required      pam_faillock.so preauth silent audit deny=3 even_deny_root unlock_time=600
auth        sufficient    pam_unix.so nullok try_first_pass
auth        [default=die] pam_faillock.so authfail audit deny=3 even_deny_root unlock_time=600

account     required      pam_faillock.so

ユーザー john が 3 回ログインに失敗した後に 4 回目のログインを試みると、4 回目のアカウントはロックされます。

~]$ 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 で次のコマンドを実行します。

~]$ faillock
john:
When                Type  Source                                           Valid
2013-03-05 11:44:14 TTY   pts/0                                                V

ユーザーのアカウントをアンロックするには、root で次のコマンドを実行します。

faillock --user <username> --reset

重要

cron ジョブを実行すると、cron ジョブを実行しているユーザーの pam_faillock の失敗カウンターがリセットされるため、pam_faillock は cron 用に設定しないでください。詳細は、Knowledge Centered Support (KCS) solution を参照してください。

authconfig でのカスタム設定の保持

authconfig ユーティリティーを使用して認証設定を変更する場合、system-auth および password-auth ファイルは authconfig ユーティリティーの設定で上書きされます。これは、authconfig が認識して上書きしない設定ファイルの代わりにシンボリックリンクを作成することで回避できます。設定ファイルと authconfig でカスタム設定を同時に使用するには、以下の手順に従ってアカウントロックを設定します。

system-auth ファイルと password-auth ファイルがすでに system-auth-ac および password-auth-ac を指すシンボリックリンクであるかどうかを確認します（これはシステムのデフォルトです）。
```
~]# ls -l /etc/pam.d/{password,system}-auth
```
以下のような出力であれば、シンボリックリンクは正しく設定されているので、手順 3 までスキップできます。
```
lrwxrwxrwx. 1 root root 16 24. Feb 09.29 /etc/pam.d/password-auth -> password-auth-ac
lrwxrwxrwx. 1 root root 28 24. Feb 09.29 /etc/pam.d/system-auth -> system-auth-ac
```
system-auth および password-auth ファイルがシンボリックリンクでない場合は、次の手順に進みます。

設定ファイルの名前を変更します。

~]# mv /etc/pam.d/system-auth /etc/pam.d/system-auth-ac
~]# mv /etc/pam.d/password-auth /etc/pam.d/password-auth-ac

カスタム設定で設定ファイルを作成します。

~]# vi /etc/pam.d/system-auth-local

/etc/pam.d/system-auth-local ファイルには、次の行が含まれている必要があります。

auth        required       pam_faillock.so preauth silent audit deny=3 unlock_time=600
auth        include        system-auth-ac
auth        [default=die]  pam_faillock.so authfail silent audit deny=3 unlock_time=600

account     required       pam_faillock.so
account     include        system-auth-ac

password    include        system-auth-ac

session     include        system-auth-ac

~]# vi /etc/pam.d/password-auth-local

/etc/pam.d/password-auth-local ファイルには、次の行が含まれている必要があります。

auth        required       pam_faillock.so preauth silent audit deny=3 unlock_time=600
auth        include        password-auth-ac
auth        [default=die]  pam_faillock.so authfail silent audit deny=3 unlock_time=600

account     required       pam_faillock.so
account     include        password-auth-ac

password    include        password-auth-ac

session     include        password-auth-ac

以下のシンボリックリンクを作成します。

~]# ln -sf /etc/pam.d/system-auth-local /etc/pam.d/system-auth
~]# ln -sf /etc/pam.d/password-auth-local /etc/pam.d/password-auth

さまざまな pam_faillock 設定オプションの詳細は、pam_faillock(8) の man ページを参照してください。

`nullok` オプションの削除

/etc/shadow ファイルのパスワードフィールドが空の場合、ユーザーは空のパスワードでログインできるようにする nullok オプションがデフォルトで有効になります。nullok オプションを無効にするには、/etc/pam.d/ ディレクトリーの設定ファイル( /etc/pam.d/ system-auth、/etc/pam.d/password-auth など)から nullok 文字列を削除します。

Will nullok option allow users to login without entering a password? を参照してください。詳細は、KCS ソリューションを参照してください。

4.1.3. セッションのロック

ユーザーは、平日の操作時に多数の理由でワークステーションを無人状態にしておく必要がある場合があります。特に物理的なセキュリティー対策が不十分な環境では、これにより、攻撃者にマシンに物理的にアクセスする機会を提供することになる可能性があります (「物理的コントロール」を参照)。特にノートパソコンは、その可動性から物理的なセキュリティーが阻害されるため、危険にさらされています。正しいパスワードが入力されるまで、システムにアクセスできないようにするセッションロック機能を使用することで、これらのリスクを軽減することができます。

注記

ログアウトする代わりに画面をロックする主な利点は、ロックによってユーザーのプロセス (ファイル転送など) を実行し続けることができることです。ログアウトしてしまうと、このようなプロセスは中断してしまいます。

4.1.3.1. vlock を使った仮想コンソールのロック

仮想コンソールをロックするには、vlock ユーティリティーを使用します。root で以下のコマンドを入力してインストールします。

~]# yum install kbd

インストール後に、パラメーターを追加せずに vlock コマンドを使用して、任意のコンソールセッションをロックできます。これは、現在アクティブな仮想コンソールセッションをロックし、他のセッションにはアクセスできるようにします。ワークステーション上のすべての仮想コンソールにアクセスできないようにするには、以下を実行します。

vlock -a

この場合、vlock は現在アクティブなコンソールをロックし、-a オプションは他の仮想コンソールに切り替えることを防ぎます。

詳細は、vlock (1) man ページを参照してください。

4.1.4. リムーバブルメディアの読み取り専用マウントの強制

リムーバブルメディア(USB フラッシュディスクなど)の読み取り専用マウントを強制するには、udev ルールを使用してリムーバブルメディアを検出し、blockdev ユーティリティーを使用して読み取り専用にマウントするように設定できます。これは、物理メディアの読み取り専用マウントを強制するには十分です。

リムーバブルメディアの読み取り専用マウントを強制するための blockdev の使用法

すべてのリムーバブルメディアを強制的に読み取り専用でマウントするには、/etc/ udev /rules.d/ ディレクトリーに、80-readonly-removables.rules などの新しい udev 設定ファイルを以下の内容で作成します。

SUBSYSTEM=="block",ATTRS{removable}=="1",RUN{program}="/sbin/blockdev --setro %N"

上記の udev ルールは、新しく接続されたリムーバブルブロック（ストレージ）デバイスが、blockdev ユーティリティーを使用して読み取り専用として自動的に設定されます。

新しい udev 設定の適用

これらの設定を有効にするには、新しい udev ルールを適用する必要があります。udev サービスは設定ファイルへの変更を自動的に検出しますが、既存のデバイスには新しい設定が適用されません。新しい設定の影響を受けるのは、新しく接続されたデバイスのみです。そのため、次に接続したときに新しい設定が適用されるように、接続されているすべてのリムーバブルメディアをアンマウントして取り外す必要があります。

既存のデバイスにすべてのルールを再適用するように udev を強制するには、root で次のコマンドを実行します。

~# udevadm trigger

上記のコマンドを使用して udev がすべてのルールを再適用するように強制しても、すでにマウントされているストレージデバイスには影響がないことに注意してください。

udev がすべてのルールを再ロードするように強制するには（何らかの理由で新しいルールが自動的に検出されない場合）、次のコマンドを使用します。

~# udevadm control --reload

4.2. Root アクセスの制御

ホームマシンを管理する場合、ユーザーは一部のタスクを root ユーザーとして実行するか、sudo や su などの setuid プログラムを使用して有効な root 権限を取得する必要があります。setuid プログラムとは、プログラムを操作するユーザーではなく、プログラムの所有者のユーザー ID(UID) で動作するプログラムのことです。このようなプログラムは、以下の例のように、長い形式一覧の所有者セクションの s で示されます。

~]$ ls -l /bin/su
-rwsr-xr-x. 1 root root 34904 Mar 10  2011 /bin/su

注記

s は大文字または小文字になります。大文字で表示されている場合は、基になる許可ビットが設定されていないことを意味します。

しかし、組織のシステム管理者の場合、組織内のユーザーが自分のマシンに対してどの程度の管理アクセスを持つべきかについて選択する必要があります。pam_console.so と呼ばれる PAM モジュールを介して、リムーバブルメディアの再起動やマウントなど、通常は root ユーザーに対してのみ予約されている一部のアクティビティーは、物理コンソールにログインする最初のユーザーに許可されます。しかし、ネットワーク設定の変更、新しいマウスの設定、ネットワークデバイスのマウントなど、その他の重要なシステム管理タスクは、管理者権限がなければできません。その結果、システム管理者は、ネットワーク上のユーザーがどの程度のアクセスを受けるべきかを決定する必要があります。

4.2.1. Root アクセスの拒否

管理者がこれらの理由や他の理由で root としてログインできないようにする場合は、root パスワードを秘密にして、ブートローダーのパスワード保護によりランレベル 1 または単一ユーザーモードへのアクセスを禁止する必要があります（本トピックの詳細については、「ブートローダーのセキュア化」を参照してください）。

管理者は、次の 4 つの方法を使用して、root ログインを許可しないようにできます。

root シェルの変更

ユーザーが root として直接ログインできないようにするために、システム管理者は、/etc/passwd ファイルで root アカウントのシェルを /sbin/nologin に設定します。

表4.2 Root シェルの無効化
影響あり	影響なし
`root` シェルへのアクセスを阻止し、そのような試みをログに記録します。以下のプログラムは `root` アカウントにアクセスできません。 login gdm kdm xdm su ssh scp sftp	FTP クライアント、メールクライアント、多くの setuid プログラムなど、シェルを必要としないプログラム。以下のプログラムは `root` アカウントにアクセスできません。 sudo FTP クライアント Email クライアント

任意のコンソールデバイス (tty) を使用した root アクセスの無効化

root アカウントへのアクセスをさらに制限するために、管理者は /etc/securetty ファイルを編集してコンソールで root ログインを無効にできます。このファイルは、root ユーザーがログインできるすべてのデバイスを一覧表示します。ファイルがまったく存在しない場合、root ユーザーは、コンソールまたは raw ネットワークインターフェイスを介して、システム上の任意の通信デバイスを介してログインできます。これは危険です。これは、ユーザーが Telnet を使用して root としてマシンにログインできるため、ネットワーク経由でプレーンテキストでパスワードを送信します。

デフォルトでは、Red Hat Enterprise 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 ユーザーが OpenSSH ツールスイートを使用してリモートでログインできません。これは、認証後までコンソールが開かれないためです。

表4.3 Root ログインの無効化
影響あり	影響なし
コンソールまたはネットワークを使用して `root` アカウントにアクセスできないようにします。以下のプログラムは `root` アカウントにアクセスできません。 login gdm kdm xdm tty を開くその他のネットワークサービス	`root` としてログインしないが、setuid またはその他のメカニズムを使用して管理タスクを実行するプログラム。以下のプログラムは `root` アカウントにアクセスできません。 su sudo ssh scp sftp

Root SSH ログインの無効化

SSH プロトコルを介した root ログインを防ぐには、SSH デーモンの設定ファイル /etc/ssh/sshd_config を編集し、以下の行を変更します。

#PermitRootLogin yes

の行を以下のように変更します。

PermitRootLogin no

表4.4 Root SSH ログインの無効化
影響あり	影響なし
ツールの OpenSSH スイートを使用した `root` アクセスを防ぎます。以下のプログラムは `root` アカウントにアクセスできません。 ssh scp sftp	OpenSSH のツール群に含まれないプログラム。

PAM を使用して、サービスへの root アクセスを制限する

PAM は、/lib/security/pam_listfile.so モジュールを通じて、特定のアカウントを拒否するための優れた柔軟性を提供します。管理者は、このモジュールを使用して、ログインを許可されていないユーザーのリストを参照できます。システムサービスへの root アクセスを制限するには、/etc/pam.d/ ディレクトリーの target サービスのファイルを編集し、pam_listfile.so モジュールが認証に必要であることを確認します。

以下は、/etc/pam.d/vsftpd PAM 設定ファイルの vsftpd FTP サーバーにモジュールを使用する方法の例です（ディレクティブが 1 行にある場合は最初の行の最後にある \ 文字は必要あり ません ）。

auth   required   /lib/security/pam_listfile.so   item=user \
sense=deny file=/etc/vsftpd.ftpusers onerr=succeed

これにより、PAM は /etc/vsftpd.ftpusers ファイルを参照し、一覧表示されたユーザーのサービスへのアクセスを拒否します。管理者はこのファイルの名前を変更することができ、各サービスごとに個別のリストを保持することも、1 つの中央リストを使用して複数のサービスへのアクセスを拒否することもできます。

管理者が複数のサービスへのアクセスを拒否する場合は、同様の行を PAM 設定ファイル（メールクライアントの場合は /etc/pam.d/pop および /etc/pam.d/imap、SSH クライアントの場合は /etc/pam.d/ssh など）に追加できます。

PAM の詳細は、/usr/share/doc/pam-<version>/html/ ディレクトリーにある『The Linux-』 PAM System Administrator's Guide を参照してください。

表4.5 PAM を使用した root の無効化
影響あり	影響なし
PAM が認識しているネットワークサービスへの `root` アクセスを防ぎます。以下のサービスは、`root` アカウントにアクセスできません。 login gdm kdm xdm ssh scp sftp FTP クライアント Email クライアントすべての PAM 対応サービス	PAM を意識していないプログラム、サービス。

4.2.2. Root アクセスの許可

組織内のユーザーが信頼され、コンピューターネーカレートである場合は、root アクセスを許可することが問題ではない可能性があります。ユーザーによる root アクセスの許可とは、デバイスの追加やネットワークインターフェイスの設定などのマイナーなアクティビティーを個々のユーザーが処理できるため、システム管理者はネットワークセキュリティーやその他の重要な問題に対処できます。

一方、個々のユーザーに root アクセスを付与すると、次の問題が発生する可能性があります。

マシン の設定ミス - root アクセスを持つユーザーはマシンの設定を誤設定でき、問題の解決に支援が必要になる場合があります。さらに悪いことに、知らずにセキュリティーホールを発生させてしまう可能性があります。
安全で ないサービス の実行 - root アクセスを持つユーザーは、FTP や Telnet などのマシン上で安全でないサーバーを実行する可能性があり、ユーザー名とパスワードが危険にさらされる可能性があります。これらのサービスは、この情報をプレーンテキストでネットワーク経由で送信します。
電子メールの添付ファイルを root で実行 — まれにですが、Linux に影響を与える電子メールウィルスが存在します。悪意のあるプログラムは、root ユーザーによって実行されると、最大の脅威となります。
監査証跡の維持 - root アカウントは複数のユーザーが共有されるため、複数のシステム管理者がシステムを保守できるため、特定の時点でどのユーザーが root であったかを把握することはできません。セパレートログインの場合、ユーザーがログインしたアカウントと、セッション追跡のための一意の番号がタスク構造に入れられ、ユーザーが起動するすべてのプロセスに継承されます。同時ログインを使用する場合、一意の番号を使用して、特定のログインへのアクションを追跡することができます。アクションが監査イベントを生成すると、その一意な番号に関連するログインアカウントとセッションが記録されます。これらのログインとセッションを表示するには、aulast コマンドを使用します。aulast コマンドの --proof オプションを使用すると、特定の ausearch クエリーを提案し、特定のセッションによって生成された監査可能なイベントを分離できます。監査システムの詳細については、7章システム監査を参照してください。

4.2.3. Root アクセスの制限

管理者は、root ユーザーへのアクセスを拒否するのではなく、su または sudo などの setuid プログラムを介したアクセスのみを許可したい場合があります。su および sudo の詳細は、Red Hat Enterprise Linux 7 System Administrator's Guide の Gaining Privileges の章および su (1) および sudo (8 )の man ページを参照してください。

4.2.4. 自動ログアウトの有効化

ユーザーが root としてログインすると、無人ログインセッションが重大なセキュリティーリスクを引き起こす可能性があります。このリスクを減らすために、一定時間後にアイドル状態のユーザーを自動的にログアウトさせるようにシステムを設定することができます。

root として、/etc/profile ファイルの先頭に次の行を追加して、このファイルの処理が中断されないようにします。
```
trap "" 1 2 3 15
```
root として、以下の行を /etc/profile ファイルに追加し、120 秒後に自動的にログアウトします。
```
export TMOUT=120
readonly TMOUT
```
TMOUT 変数は、指定された秒数のアクティビティーがない場合にシェルを終了します（上記の例では 120 に設定）。特定のインストールのニーズに応じて、制限を変更することができます。

4.2.5. ブートローダーのセキュア化

Linux ブートローダーをパスワードで保護する主な理由は、以下のとおりです。

シングルユーザーモードへのアクセスの防止 - 攻撃者がシステムをシングルユーザーモードで起動できる場合、root パスワードを求められることなく、root として自動的にログインします。
警告
/etc/sysconfig/init ファイルの SINGLE パラメーターを編集して、パスワードを使用してシングルユーザーモードへのアクセスを保護することは推奨されません。攻撃者は、GRUB 2 のカーネルコマンドラインでカスタム初期コマンド( init= パラメーターを使用)を指定することにより、パスワードをバイパスできます。Red Hat Enterprise Linux 7 System Administrator's Guide の Protecting GRUB 2 with a Password の章に記載されているように、GRUB 2 ブートローダーをパスワードで保護することが推奨されています。
GRUB 2 コンソールへのアクセスの防止 - マシンがブートローダーとして GRUB 2 を使用する場合、攻撃者は GRUB 2 エディターインターフェイスを使用して設定を変更したり、cat コマンドを使用して情報を収集したりできます。
安全でないオペレーティングシステムへのアクセスの防止 — デュアルブートシステムの場合、攻撃者は、たとえば DOS のような、アクセス制御およびファイルパーミッションを無視するオペレーティングシステムを起動時に選択することができます。

Red Hat Enterprise Linux 7 には、Intel 64 および AMD64 プラットフォームに GRUB 2 ブートローダーが含まれています。GRUB 2 の詳細については、Red Hat Enterprise Linux 7 System Administrator's Guide の Working With the GRUB 2 Boot Loader の章を参照してください。

4.2.5.1. インタラクティブスタートアップの無効化

ブートシーケンスの最初に I キーを押すと、対話的にシステムを起動できます。インタラクティブな起動中に、システムは各サービスを 1 つずつ起動するように要求します。しかし、これでは、お客様のシステムに物理的にアクセスした攻撃者が、セキュリティー関連サービスを無効化し、システムにアクセスすることができる可能性があります。

root としてユーザーが対話的にシステムを起動しないようにするには、/etc/sysconfig/init ファイルの PROMPT パラメーターを無効にします。

PROMPT=no

4.2.6. ハードリンクおよびシンボリックリンクの保護

悪意のあるユーザーが保護されていないハードリンクやシンボリックリンクによって引き起こされる潜在的な脆弱性を悪用するのを防ぐため、Red Hat Enterprise Linux 7 には、特定の条件を満たす場合にのみリンクの作成または追跡を許可する機能が搭載されています。

ハードリンクの場合、次のいずれかが当てはまる必要があります。

ユーザーは、リンク先のファイルを所有しています。
ユーザーは、リンク先のファイルに対して、すでに読み取りと書き込みのアクセス権を持っています。

シンボリックリンクの場合、プロセスは、スティッキービットを持つ誰でも書き込み可能なディレクトリーの外部にある場合にのみリンクをたどることが許可されます。または、以下のいずれかが当てはまる必要があります。

シンボリックリンクに続くプロセスが、シンボリックリンクの所有者となります。
ディレクトリーの所有者は、シンボリックリンクの所有者と同じになります。

この保護機能は、デフォルトでオンになっています。これは、/usr/lib/sysctl.d/50-default.conf ファイルの以下のオプションによって制御されます。

fs.protected_hardlinks = 1
fs.protected_symlinks = 1

デフォルト設定を上書きして保護を無効にするには、以下の内容で /etc/sysctl .d/ ディレクトリーに 51-no-protect-links.conf などの新しい設定ファイルを作成します。

fs.protected_hardlinks = 0
fs.protected_symlinks = 0

注記

デフォルトのシステム設定を上書きするには、新しい設定ファイルに .conf 拡張子が必要で、デフォルトのシステムファイルの後に読み込む必要があることに注意してください（ファイルは辞書的な順序で読み取られます）。そのため、ファイル名の最初に番号が大きいファイルに含まれる設定が優先されます。

sysctl メカニズムを使用した起動時のカーネルパラメーターの設定についての詳細は、sysctl.d(5) の man ページを参照してください。

4.3. サービスのセキュア化

組織内のシステム管理者にとって、管理コントロールへのユーザーアクセスは重要な問題ですが、Linux システムを管理および運用するすべての人にとって、どのネットワークサービスがアクティブであるかを監視することは最も重要なことです。

Red Hat Enterprise Linux 7 のサービスの多くは、ネットワークサーバーです。ネットワークサービスがマシン上で実行されている場合、サーバーアプリケーション (デーモン と呼ばれる) は、1 つ以上のネットワークポートで接続をリッスンしています。これらの各サーバーは、潜在的な攻撃経路として扱われる必要があります。

4.3.1. サービスへのリスク

ネットワークサービスは、Linux システムに多くのリスクをもたらす可能性があります。以下は、一部の主要な問題の一覧になります。

サービス拒否攻撃 (DoS) — サービスにリクエストをフラッディングさせると、サービスは各リクエストをログに記録して応答しようとするため、サービス拒否攻撃はシステムを使用不能にすることができます。
分散型サービス拒否攻撃 (DDoS) — DoS 攻撃の一種で、セキュリティーを侵害された複数のマシン (多くは数千台以上) を使用して、サービスに協調攻撃を仕掛け、リクエストをフラッディングさせて使用不能にするものです。
スクリプト脆弱性攻撃 — Web サーバーが一般的に行うように、サーバーが、サーバーサイドのアクションを実行するためにスクリプトを使用している場合、攻撃者は不適切に記述されたスクリプトをターゲットにすることができます。これらのスクリプトの脆弱性攻撃により、バッファーオーバーフロー状態が発生したり、攻撃者がシステム上のファイルを変更したりできます。
バッファーオーバーフロー攻撃 - ポート 1 から 1023 をリッスンするサービスは、管理者権限で開始するか、CAP_NET_BIND_SERVICE 機能を設定する必要があります。プロセスがポートにバインドされ、そのポートをリッスンするようになると、権限または機能がドロップされることがよくあります。権限や機能がドロっプされず、アプリケーションに悪用可能なバッファーオーバーフローがある場合、攻撃者はデーモンを実行しているユーザーとしてシステムにアクセスできる可能性があります。悪用可能なバッファーオーバーフローが存在するため、クラッカーは自動化ツールを使って脆弱性のあるシステムを特定し、アクセス権を獲得した後は、自動化ルートキットを使ってシステムへのアクセス権を維持します。

注記

バッファーオーバーフローの脆弱性の脅威は、ExecShield によって Red Hat Enterprise Linux 7 で軽減されます。これは、x86 互換のユニプロセッサーおよびマルチプロセッサーカーネルでサポートされる実行可能メモリーのセグメンテーションおよび保護テクノロジーです。ExecShield は、仮想メモリーを実行可能セグメントと非実行セグメントに分離することで、バッファーオーバーフローのリスクを低減します。実行可能セグメントの外で実行しようとするプログラムコード (バッファーオーバーフローの悪用から注入された悪意のあるコードなど) は、セグメンテーションフォールトを引き起こし、終了します。

Execshield には、AMD64 プラットフォームおよび Intel® 64 システムにおける No eXecute (NX) テクノロジーのサポートも含まれます。これらのテクノロジーは ExecShield と連携して動作し、4KB の実行可能コードの粒度で仮想メモリーの実行可能部分で悪意のあるコードが実行されるのを防ぎ、バッファーオーバーフローの悪用による攻撃のリスクを低減します。

重要

ネットワークに対する攻撃に対する公開を制限するには、未使用のすべてのサービスをオフにする必要があります。

4.3.2. サービスの識別と設定

セキュリティーを強化するため、Red Hat Enterprise Linux 7 でインストールされるほとんどのネットワークサービスは、デフォルトでオフになっています。ただし、いくつかの注目すべき例外があります。

cups - Red Hat Enterprise Linux 7 のデフォルトのプリントサーバー。
cups-lpd - 代替のプリントサーバー。
xinetd - gssftp や telnet など、さまざまな下位サーバーへの接続を制御するスーパーサーバー。
sshd - OpenSSH サーバー。Telnet の安全な代替です。

これらのサービスを実行したままにするかどうかを決定するときは、常識的に考え、リスクを冒さないようにすることが最善策となります。たとえば、プリンターが利用できない場合は、cups を実行したままにしないでください。同じことが portreserve にも当てはまります。NFSv3 ボリュームをマウントしない、または NIS ( ypbind サービス)を使用する場合は、rpcbind を無効にする必要があります。起動時にどのネットワークサービスが起動可能かを確認するだけでは十分ではありません。また、どのポートが開いていて、リッスンしているかも確認することをお勧めします。詳細は、「リッスンしているポートの確認」を参照してください。

4.3.3. 安全でないサービス

潜在的に、どのようななネットワークサービスも安全ではありません。そのため、使っていないサービスをオフにすることはとても重要です。サービスの不正使用は定期的に確認され、パッチが適用されるため、ネットワークサービスに関連するパッケージを定期的に更新することが非常に重要です。詳細は、3章システムを最新の状態に保つ を参照してください。

一部のネットワークプロトコルは、本質的に他のプロトコルよりも安全ではありません。以下の動作を実行するサービスがそれに当たります。

暗号化されていないネットワーク上でのユーザー名とパスワードの送信 — Telnet や FTP などの多くの古いプロトコルは、認証セッションを暗号化しないため、可能な限り避ける必要があります。
暗号化されていないネットワーク上での機密データの送信 — 多くのプロトコルは、暗号化されていないネットワーク上でデータを送信します。これらのプロトコルには、Telnet、FTP、HTTP、および SMTP が含まれます。NFS や SMB などの多くのネットワークファイルシステムも、暗号化されていないネットワークを介して情報を送信します。これらのプロトコルを使用する場合、ユーザーの責任において、送信されるデータの種類を制限する必要があります。

本質的に安全ではないサービスの例としては、rlogin、rsh、telnet、vsftpd などがあります。

SSH を優先して、すべてのリモートログインおよびシェルプログラム(rlogin、rsh、および telnet)を回避する必要があります。sshd の詳細は、「SSH のセキュア化」を参照してください。

FTP は、リモートシェルほどシステムのセキュリティーに本質的に危険ではありませんが、問題を回避するために、FTP サーバーは慎重に設定し、監視する必要があります。FTP サーバーのセキュリティー保護に関する詳細は、「FTP のセキュア化」を参照してください。

慎重に実装し、ファイアウォールの内側に置くべきサービスは以下の通りです。

auth
nfs-server
smb および nbm (Samba)
yppasswdd
ypserv
ypxfrd

ネットワークサービスのセキュリティーに関する詳細は、「ネットワークアクセスのセキュア化」を参照してください。

4.3.4. rpcbind のセキュア化

rpcbind サービスは、NIS や NFS などの RPC サービス用の動的ポート割り当てデーモンです。認証メカニズムが弱く、制御するサービスに幅広いポート範囲を割り当てることができます。これらの理由から、セキュリティー保護することは困難です。

注記

rpcbind のセキュリティーは、NFSv4 では不要になったため、NFSv2 および NFSv3 の実装にのみ影響します。NFSv2 または NFSv3 サーバーを実装する予定の場合は、rpcbind が必要で、以下のセクションが適用されます。

RPC サービスを実行している場合は、以下の基本的なルールにしたがってください。

4.3.4.1. TCP Wrapper による rpcbind の保護

rpcbind サービスには認証形式がないため、TCP Wrapper を使用して、rpcbind サービスにアクセスできるネットワークまたはホストを制限することが重要です。

また、サービスへのアクセスを制限する場合は、IP アドレスのみを使用してください。ホスト名は、DNS ポイズニングなどの方法で偽造される可能性があるため、使用しないようにしてください。

4.3.4.2. firewalld による rpcbind の保護

rpcbind サービスへのアクセスをさらに制限するには、サーバーに firewalld ルールを追加し、特定のネットワークへのアクセスを制限することが推奨されます。

以下は、firewalld リッチ言語コマンドの例です。1 つ目は、192.168.0.0/24 ネットワークからポート 111 ( rpcbind サービスで使用される)への TCP 接続を許可します。2 つ目は、localhost から同じポートへの TCP 接続を許可します。それ以外のパケットはすべてドロップされます。

~]# firewall-cmd --add-rich-rule='rule family="ipv4" port port="111" protocol="tcp" source address="192.168.0.0/24" invert="True" drop'
~]# firewall-cmd --add-rich-rule='rule family="ipv4" port port="111" protocol="tcp" source address="127.0.0.1" accept'

同様に UDP トラフィックを制限するには、次のコマンドを使用します。

~]# firewall-cmd --add-rich-rule='rule family="ipv4" port port="111" protocol="udp" source address="192.168.0.0/24" invert="True" drop'

注記

firewalld リッチ言語コマンドに --permanent を追加して、設定を永続化します。ファイアウォールの実装に関する詳細情報は、5章ファイアウォールの使用 を参照してください。

4.3.5. rpc.mountd のセキュア化

rpc.mountd デーモンは、NFS バージョン 2 (RFC 1904)および NFS バージョン 3 (『RFC』1813)が使用するプロトコルである NFS MOUNT プロトコルのサーバー側を実装します。

RPC サービスを実行している場合は、以下の基本的なルールにしたがってください。

4.3.5.1. TCP ラッパーによる rpc.mountd の保護

rpc.mountd サービスには認証が組み込まれていないため、TCP Wrapper を使用して、rpc.mountd サービスにアクセスできるネットワークまたはホストを制限することが重要です。

さらに、サービスへのアクセスを制限する場合は、IP アドレスのみを使用してください。ホスト名は DNS ポイズニングなどの方法で偽造される可能性があるため、使用しないでください。

4.3.5.2. firewalld による rpc.mountd の保護

rpc.mountd サービスへのアクセスをさらに制限するには、サーバーに firewalld リッチ言語ルールを追加し、特定のネットワークへのアクセスを制限します。

以下は、firewalld リッチ言語コマンドの例です。1 つ目は、192.168.0.0/24 ネットワークから mountd 接続を許可します。2 つ目は、ローカルホストからの mountd 接続を許可します。他のパケットはすべて遮断されます。

~]# firewall-cmd --add-rich-rule 'rule family="ipv4" source NOT address="192.168.0.0/24" service name="mountd" drop'
~]# firewall-cmd --add-rich-rule 'rule family="ipv4" source address="127.0.0.1" service name="mountd" accept'

注記

4.3.6. NIS のセキュア化

ネットワーク情報 サービス(NIS)は、ypserv と呼ばれる RPC サービスです。このサービスは、rpcbind や他の関連サービスと組み合わせて使用され、ユーザー名、パスワード、その他の機密情報を、そのドメイン内で要求するコンピューターに配布します。

NIS サーバーは、いくつかのアプリケーションで設定されています。内容は以下の通りです。

/usr/sbin/rpc.yppasswdd - yppasswdd サービスとも呼ばれるこのデーモンにより、ユーザーは NIS パスワードを変更できます。
/usr/sbin/rpc.ypxfrd - ypxfrd サービスとも呼ばれるこのデーモンは、ネットワークを介した NIS マップ転送を行います。
/usr/sbin/ypserv - これは NIS サーバーデーモンです。

NIS は現在の基準からすると、やや安全性に欠けています。ホスト認証メカニズムがなく、パスワードハッシュを含むすべての情報を暗号化せずにネットワーク経由で送信します。そのため、NIS を使用するネットワークを構築する際には、細心の注意が必要です。さらに、NIS のデフォルト設定が本質的に安全でないという事実が、この問題をさらに複雑にしています。

NIS サーバーの実装を計画している人は、「rpcbind のセキュア化」に概説されているように、最初に rpcbind サービスをセキュリティー保護し、ネットワーク計画などの以下の問題に対処することが推奨されます。

4.3.6.1. ネットワークの注意深いプランニング

NIS はネットワーク上で機密情報を暗号化せずに送信するため、サービスをファイアウォールの内側で、そしてセグメント化された安全なネットワーク上で実行することが重要となります。NIS 情報が安全でないネットワークを介して送信される場合は常に、傍受されるリスクがあります。慎重なネットワーク設計は、深刻なセキュリティー侵害を防ぐ上で役立ちます。

4.3.6.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

注記

Kerberos を使用すると、/etc/shadow ファイルは NIS マップに保存されません。

攻撃者にとって NIS マップへのアクセスを困難にするには、o7hfawtgmhwg.domain.com などの DNS ホスト名にランダムな文字列を作成します。同様に、異なるランダムな NIS ドメイン名を作成します。これにより、攻撃者が NIS サーバーにアクセスすることがより困難になります。

4.3.6.3. `/var/yp/securenets` ファイルの編集

/var/yp/securenets ファイルが空白であるか、存在しない場合（デフォルトのインストール後の場合）、NIS はすべてのネットワークをリッスンします。最初の作業の 1 つは、ネットマスク/ネットワークのペアをファイルに配置して、ypserv が適切なネットワークからの要求にのみ応答するようにすることです。

以下は、/var/yp/securenets ファイルからのエントリーの例です。

255.255.255.0     192.168.0.0

警告

/var/yp/securenets ファイルを作成せずに、NIS サーバーを初めて起動しないでください。

この手法では、IP スプーフィング攻撃からの保護はできませんが、少なくとも NIS サーバーがサービスを提供するネットワークに制限を設けることができます。

4.3.6.4. 静的ポートの割り当てとリッチ言語ルールの使用

NIS に関連するサーバーはすべて、rpc.yppasswdd （ユーザーがログインパスワードを変更できるようにするデーモン）以外の特定のポートを割り当てることができます。他の 2 つの NIS サーバーデーモンである rpc.ypxfrd および ypserv にポートを割り当てると、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 のルールです。

注記

iptables コマンドによるファイアウォールの実装についての詳細は、5章ファイアウォールの使用 を参照してください。

4.3.6.5. Kerberos 認証の使用

NIS を認証に使用する際に考慮すべき問題の 1 つは、ユーザーがマシンにログインするたびに、/etc/shadow マップからのパスワードハッシュがネットワーク経由で送信されることです。侵入者が NIS ドメインにアクセスし、ネットワークトラフィックを盗聴した場合、侵入者はユーザー名とパスワードハッシュを収集できます。十分な時間があれば、パスワードクラッキングプログラムは弱いパスワードを推測することができ、攻撃者はネットワーク上の有効なアカウントにアクセスすることができます。

Kerberos は秘密鍵暗号を使用しているので、パスワードハッシュがネットワーク経由で送信されることはなく、システムの安全性が大幅に向上します。Kerberos の詳細については、Linux ドメイン ID、認証、およびポリシーガイドのLogging into IdM Using Kerberosの項を参照してください。

4.3.7. NFS のセキュア化

重要

NFS トラフィックは、すべてのバージョンで TCP を使用して送信することができ、それは UDP ではなく、NFSv3 で使用されるべきであり、NFSv4 を使用する場合は必須となります。NFS のすべてのバージョンは、RPCSEC_GSS カーネルモジュールの一部として Kerberos ユーザーおよびグループ認証をサポートします。Red Hat Enterprise Linux 7 は rpcbind を使用する NFSv3 をサポートしているため、rpcbind に関する情報は引き続き含まれています。

4.3.7.1. ネットワークの注意深いプランニング

NFSv2 と NFSv3 ではこれまで、データの受け渡しは安全に行われていませんでした。NFS のすべてのバージョンで、Kerberos を使用して通常のファイルシステム操作を認証する (オプションで暗号化する) 機能が追加されました。NFSv4 ではすべての操作で Kerberos を使用できますが、NFSv2 または NFSv3 では、ファイルのロックとマウントではまだ使用できません。NFSv4.0 を使用する場合で、クライアントが NAT やファイアウォールの内側にある場合は、委譲がオフになることがあります。NFSv4.1 を使用して NAT やファイアウォールを介して委譲を操作できるようにする方法の詳細については、Red Hat Enterprise Linux 7 ストレージ管理ガイドの pNFS のセクションを参照してください。

4.3.7.2. NFS マウントオプションのセキュア化

/etc/fstab ファイルでの mount コマンドの使用については、Red Hat Enterprise Linux 7 Storage Administration Guide の Using the mount command の章で説明されています。セキュリティー管理の観点からは、NFS マウントオプションは /etc/nfsmount.conf でも指定できます。これは、カスタムのデフォルトオプションを設定するために使用できます。

4.3.7.2.1. NFS サーバーのレビュー

警告

ファイルシステム全体のみをエクスポートします。ファイルシステムのサブディレクトリーをエクスポートすると、セキュリティー上の問題が発生することがあります。クライアントがファイルシステムのエクスポートされた部分から抜け出して、エクスポートされていない部分を取得する場合があります( exports (5) man ページのサブツリーチェックに関するセクションを参照してください)。

ro オプションを使用し、可能な限りファイルシステムを読み取り専用としてエクスポートし、マウントされたファイルシステムに書き込むことができるユーザー数を削減します。特に必要な場合にのみ rw オプションを使用してください。詳細は、exports (5) の man ページを参照してください。書き込みアクセスを許可すると、たとえばシンボリックリンク攻撃によるリスクが高まります。これには、/tmp や /usr /tmp などの一時ディレクトリーが含まれます。

ディレクトリーを rw オプションでマウントする必要がある場合は、リスクを減らすために、可能な限りディレクトリーを誰でも書き込み可能にすることは避けてください。一部のアプリケーションでは、パスワードをクリアテキストまたは弱い暗号化形式で保存するため、ホームディレクトリーのエクスポートもリスクがあると見なされます。このリスクは、アプリケーションコードの見直しや改善によって減少しています。SSH 鍵にパスワードを設定しないユーザーもいるので、これもホームディレクトリーのリスクとなることを意味します。パスワードの使用を強制するか、Kerberos を使用すると、このリスクが軽減されます。

エクスポートはアクセスを必要とするクライアントのみとしてください。NFS サーバーで showmount -e コマンドを使用して、サーバーのエクスポート内容を確認します。特に必要のないものはエクスポートしないでください。

no_root_squash オプションを使用しないでください。また、既存のインストールを確認し、使用されていないことを確認してください。詳細は、「no_root_squash オプションを使用しないでください」を参照してください。

secure オプションは、「予約済み」ポートへのエクスポートを制限するために使用されるサーバー側のエクスポートオプションです。デフォルトでは、サーバーは「予約済み」ポート (1024 未満の番号のポート) からのクライアント通信のみを許可します。これは、従来からクライアントは、「信頼できる」コード (カーネル内の NFS クライアントなど) のみがこれらのポートを使用するように許可していたためです。しかし、多くのネットワークでは、一部のクライアントで root ユーザーになることは難しくないので、予約されたポートからの通信が権限付きであるとサーバーが想定することは安全ではありません。そのため、予約ポートの制限は効果が限定的です。Kerberos、ファイアウォール、および特定クライアントへのエクスポートを制限することに依存すると良いでしょう。

現在でもほとんどのクライアントは、可能な限り予約済みポートを使用します。ただし、予約済みポートは限られたリソースであるため、クライアント (特に、NFS マウントの数が多いクライアント) は、より大きな番号のポートを使用することも選択できます。Linux クライアントは、「noresvport」マウントオプションを使用して、これを行うことができます。エクスポート時にこれを許可したい場合は、「Insecure」エクスポートオプションで許可することができます。

ユーザーのサーバーへのログインを許可しないことが推奨されます。NFS サーバーで上記の設定を確認する場合、誰および何がサーバーにアクセスできるかを確認します。

4.3.7.2.2. NFS クライアントのレビュー

nosuid オプションを使用して、setuid プログラムの使用を無効にします。nosuid オプションは、set-user-identifier ビットまたは set-group-identifier ビットを無効にします。これにより、リモートユーザーは、setuid プログラムを実行してより高い権限を取得できなくなります。このオプションは、クライアント側とサーバー側で使用します。

noexec オプションは、クライアント上のすべての実行可能ファイルを無効にします。これを使用して、ユーザーが共有されているファイルシステムに置かれているファイルを誤って実行しないようにします。nosuid および noexec オプションは、すべてではないにしても、ほとんどのファイルシステムの標準オプションです。

nodev オプションを使用して、「デバイスファイル」がクライアントによってハードウェアデバイスとして処理されないようにします。

resvport オプションはクライアント側のマウントオプションで、secure は対応するサーバー側のエクスポートオプションです (上記の説明を参照してください)。これは、通信を予約済みポートに制限します。予約済みポートまたは既知のポートは、root ユーザーなどの特権ユーザーおよびプロセス用に予約されています。このオプションを設定すると、クライアントは予約済みソースポートを使用してサーバーと通信します。

NFS のすべてのバージョンで、Kerberos 認証を使用したマウントがサポートされるようになりました。これを有効にするためのマウントオプションは、sec=krb5 です。

NFSv4 では、整合性にkrb5i、プライバシー保護にkrb5pを用いた Kerberos によるマウントをサポートしています。これらは、sec=krb5でマウントする際に使用されますが、NFS サーバーで設定する必要があります。詳細は、exports の man ページを参照してください(man 5 exports)。

NFS の man ページ(man 5 nfs)には、NFSv4 のセキュリティー強化を説明する「SECURITY CONSIDERATIONS」セクションがあり、NFS 固有のマウントオプションがすべて含まれています。

重要

krb5-libs パッケージが提供する MIT Kerberos ライブラリーは、新しいデプロイメントで Data Encryption Standard (DES) アルゴリズムに対応しなくなりました。セキュリティーおよび互換性上の理由から、DES は非推奨となり、Kerberos ライブラリーではデフォルトで無効になっています。お使いの環境がより新しく安全なアルゴリズムをサポートしていない場合、互換性の理由に限り DES を使用してください。

4.3.7.3. 構文エラーに注意

NFS サーバーは、/etc/exports ファイルを使って、エクスポートするファイルシステムと、これらのディレクトリーをエクスポートするホストを決定します。このファイルを編集する際には、余計なスペースを加えないように注意してください。

たとえば、/etc/exports ファイルの次の行は、ディレクトリー /tmp/nfs/ を、読み取り/書き込みパーミッションでホスト bob.example.com と共有します。

/tmp/nfs/     bob.example.com(rw)

一方、/etc/exports ファイルの次の行は、同じディレクトリーを読み取り専用パーミッションでホスト bob.example.com と共有し、ホスト名の後の 1 つのスペース文字が原因で読み取り/書き込みパーミッションで ワールド と共有します。

/tmp/nfs/     bob.example.com (rw)

showmount コマンドを使用して、設定されている NFS 共有を確認し、共有しているものを確認することをお勧めします。

showmount -e <hostname>

4.3.7.4. no_root_squash オプションを使用しないでください

デフォルトでは、NFS 共有は root ユーザーを非特権ユーザーアカウントである nfsnobody ユーザーに変更します。これにより、root で作成されたすべてのファイルの所有者が nfsnobody に変更され、setuid ビットが設定されたプログラムのアップロードができなくなります。

no_root_squash を使用すると、リモートの root ユーザーは共有ファイルシステム上の任意のファイルを変更し、他のユーザーが誤って実行できるようにアプリケーションが Trojans に感染した状態にすることができます。

4.3.7.5. NFS ファイアウォールの設定

NFSv4 は、NFS for Red Hat Enterprise Linux 7 のデフォルトバージョンで、TCP 用にポート 2049 が開かれていることだけが必要です。NFSv3 を使用する場合は、以下で説明するように 4 つの追加ポートが必要です。

NFSv3 用のポート設定

NFS に使用されるポートは rpcbind サービスによって動的に割り当てられるため、ファイアウォールルールの作成時に問題が発生する可能性があります。このプロセスを簡素化するには、/etc/sysconfig/nfs ファイルを使用して、使用するポートを指定します。

MOUNTD_PORT — mountd (rpc.mountd) 用の TCP および UDP ポート
STATD_PORT — ステータス (rpc.statd) 用の TCP および UDP ポート

Red Hat Enterprise Linux 7 では、/etc/modprobe.d/lockd.conf ファイルに NFS ロックマネージャー(nlockmgr)の TCP および UDP ポートを設定します。

nlm_tcpport — nlockmgr (rpc.lockd) 用の TCP ポート
nlm_udpport — UDP ポート nlockmgr (rpc.lockd)

指定されたポート番号は、他のサービスでは使用しないでください。指定されたポート番号と、TCP および UDP のポート 2049(NFS) を許可するようにファイアウォールを設定します。カスタマイズ可能な追加の NFS ロックマネージャーパラメーターの説明は、/etc/modprobe.d/lockd.conf を参照してください。

NFS サーバーで rpcinfo -p コマンドを実行して、使用されているポートと RPC プログラムを確認します。

4.3.7.6. Red Hat Identity Management による NFS のセキュリティー保護

Red Hat Enterprise Linux に含まれる Red Hat Identity Management を使用している環境では、Kerberos 対応の NFS セットアップを大幅に簡素化できます。

Red Hat Enterprise Linux 7 Linux Domain Identity, Authentication, and Policy Guide、特にSetting up a Kerberos-aware NFS Serverを参照して、Red Hat Identity Management を使用する際に Kerberos で NFS を保護する方法を確認してください。

4.3.8. HTTP サーバーのセキュリティー保護

4.3.8.1. Apache HTTP Server のセキュリティー保護

Apache HTTP Server は、Red Hat Enterprise Linux 7 で最も安定かつ安全なサービスの 1 つです。Apache HTTP Server を保護するための多数のオプションと手法を利用することができます。数が多いため、ここでは詳細な説明はしません。以下のセクションでは、Apache HTTP Server を実行する際のグッドプラクティスについて簡単に説明します。

システム上で実行されているスクリプトは、実稼働させる前に必ず意図したとおりに動作することを確認してください。また、root ユーザーのみがスクリプトまたは CGI を含むディレクトリーへの書き込み権限を持っていることを確認してください。これを行うには、root ユーザーで以下のコマンドを入力します。

chown root <directory_name>

chmod 755 <directory_name>

システム管理者は、次の設定オプション( /etc/httpd/conf/httpd.confで設定)を使用する場合は注意が必要です。

FollowSymLinks

このディレクティブはデフォルトで有効になっていますので、Web サーバーのドキュメント root へのシンボリックリンクを作成する場合は注意が必要です。たとえば、/ へのシンボリックリンクを提供することは適切ではありません。

Indexes

このディレクティブはデフォルトで有効になっていますが、望ましくない場合もあります。訪問者がサーバー上のファイルを閲覧できないようにするには、このディレクティブを削除してください。

UserDir

UserDir ディレクティブは、システム上にユーザーアカウントが存在することを確認できるため、デフォルトでは無効になっています。サーバーでユーザーディレクトリーの閲覧を可能にするには、以下のディレクティブを使用します。

UserDir enabled
	        UserDir disabled root

これらのディレクティブは、/root/ 以外のすべてのユーザーディレクトリーの閲覧を有効にします。無効化されたアカウントのリストにユーザーを追加するには、UserDir disabled 行にスペースで区切られたユーザーのリストを追加します。

ServerTokens

ServerTokens ディレクティブは、クライアントに送り返されるサーバー応答ヘッダーフィールドを制御します。これには、以下のパラメーターを使用してカスタマイズできるさまざまな情報が含まれています。

ServerTokens Full (デフォルトオプション) — 利用可能なすべての情報 (OS タイプや使用モジュール) を提供します。以下に例を示します。
```
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) モジュールは、コマンドを実行できません。この設定は、攻撃者がシステム上でコマンドを実行できるようになる可能性があるため、絶対に必要な場合を除き、変更しないことを推奨します。

httpd モジュールの削除

特定のシナリオでは、HTTP サーバーの機能を制限するために特定の httpd モジュールを削除することが有益です。これを行うには、/etc/httpd/conf.modules.d ディレクトリーの設定ファイルを編集します。たとえば、プロキシーモジュールを削除するためには、以下のコマンドを実行します。

echo '# All proxy modules disabled' > /etc/httpd/conf.modules.d/00-proxy.conf

/etc/httpd/conf.d/ ディレクトリーには、モジュールの読み込みにも使用される設定ファイルが含まれていることに注意してください。

httpd および SELinux

詳細は、Red Hat Enterprise Linux 7 の SELinux User's Guide および Administrator's Guide の The Apache HTTP Server and SELinux の章を参照してください。

4.3.8.2. NGINX のセキュリティー保護

NGINX は、高性能の HTTP およびプロキシーサーバーです。本セクションでは、NGINX 設定を強化する追加の手順を簡単に説明します。NGINX 設定ファイルの server セクションで、以下の設定変更をすべて実行します。

バージョン文字列の無効化

攻撃者がサーバー上で動作している NGINX のバージョンを知ることを防ぐために、次の設定オプションを使用します。

server_tokens        off;

これには、バージョン番号を削除し、NGINX が提供するすべてのリクエストで文字列 nginx を単に報告するという効果があります。

$ curl -sI http://localhost | grep Server
Server: nginx

追加のセキュリティー関連ヘッダーを含む

NGINX が提供する各リクエストには、特定の既知の Web アプリケーションの脆弱性を緩和する追加の HTTP ヘッダーを含めることができます。

add_header X-Frame-Options SAMEORIGIN; - このオプションは、ドメイン外のページが NGINX が提供するコンテンツをフレーム化するように拒否し、クリックジャッキング攻撃を効果的に軽減します。
add_header X-Content-Type-Options nosniff; - このオプションは、特定の古いブラウザーで MIME タイプのスニッフィングを防ぎます。
add_header X-XSS-Protection "1; mode=block"; - このオプションは、クロスサイトスクリプティング(XSS)フィルターリングを有効にします。これにより、ブラウザーは NGINX の応答に含まれる潜在的に悪意のあるコンテンツをレンダリングできなくなります。

潜在的に有害な HTTP メソッドを無効にする

一部の HTTP メソッドを有効にすると、開発者が Web アプリケーションをテストするために設計された Web サーバー上で、攻撃者がアクションを実行する可能性があります。たとえば、TRACE メソッドはクロスサイトトレース (XST) を許可することが知られています。

NGINX サーバーは、許可されるべきものだけをホワイトリストに登録することで、これらの有害な HTTP メソッドや任意のメソッドを拒否することができます。以下に例を示します。

# Allow GET, PUT, POST; return "405 Method Not Allowed" for all others.
if ( $request_method !~ ^(GET|PUT|POST)$ ) {
    return 405;
}

SSL の設定

NGINX Web サーバーが提供するデータを保護するには、HTTPS でのみサービスを提供することを検討してください。NGINX サーバーで SSL を有効にするための安全な設定プロファイルを生成するには、Mozilla SSL Configuration Generator を参照してください。生成された設定により、既知の脆弱なプロトコル (SSLv2 や SSLv3 など)、暗号、ハッシュアルゴリズム (3DES や MD5 など) が確実に無効化されます。

また、SSL サーバーテストを使用して、設定した内容が最新のセキュリティー要件を満たしていることを確認できます。

4.3.9. FTP のセキュア化

ファイル転送プロトコル (FTP) は、ネットワーク上でファイルを転送するために設計された古い TCP プロトコルです。ユーザー認証を含むサーバーとのすべてのトランザクションが暗号化されていないため、安全でないプロトコルとみなされ、慎重に設定される必要があります。

Red Hat Enterprise Linux 7 は 2 つの FTP サーバーを提供します。

Red Hat Content Accelerator (tux): FTP 機能を持つカーネルスペースの Web サーバー。
vsftpd: スタンドアロンの、セキュリティー指向の FTP サービスの実装。

vsftpd FTP サービスを設定するためのセキュリティーガイドラインを以下に示します。

4.3.9.1. FTP グリーティングバナー

ユーザー名とパスワードを送信する前に、すべてのユーザーにグリーティングバナーが表示されます。デフォルトでは、このバナーには、システムの弱点を特定しようとするクラッカーに有用なバージョン情報が含まれています。

vsftpd のグリーティングバナーを変更するには、以下のディレクティブを /etc/vsftpd/vsftpd.conf ファイルに追加します。

ftpd_banner=<insert_greeting_here>

上記のディレクティブの <insert_greeting_here> をグリーティングメッセージのテキストで置き換えます。

複数行バナーの場合は、バナーファイルを使用することが推奨されます。複数のバナーの管理を簡素化するには、すべてのバナーを /etc/banners/ という新しいディレクトリーに配置します。この例の FTP 接続のバナーファイルは /etc/banners/ftp.msg です。以下は、このようなファイルの例です。

######### Hello, all activity on ftp.example.com is logged. #########

注記

「TCP Wrapper と xinetd を使用したサービスの保護」で指定されているように、ファイルの各行を 220 で始める必要はありません。

vsftpd のこのグリーティングバナーファイルを参照するには、以下のディレクティブを /etc/vsftpd/vsftpd.conf ファイルに追加します。

banner_file=/etc/banners/ftp.msg

また、「TCP Wrapper と接続バナー」で説明されているように、TCP Wrappers を使用して着信接続に追加のバナーを送信することも可能です。

4.3.9.2. 匿名アクセス

/var/ftp/ ディレクトリーが存在すると、匿名アカウントが有効になります。

このディレクトリーを作成する最も簡単な方法は、vsftpd パッケージをインストールすることです。本パッケージは、匿名ユーザーのためのディレクトリーツリーを構築し、匿名ユーザーのためにディレクトリーのパーミッションを読み取り専用に設定します。

デフォルトでは、匿名ユーザーはどのディレクトリーにも書き込むことができません。

警告

FTP サーバーへの匿名アクセスを可能にする場合、機密データが保存される場所に注意してください。

4.3.9.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.9.3. ユーザーアカウント

FTP は、認証用に非セキュアなネットワークで暗号化されていないユーザー名とパスワードを送信するため、ユーザーアカウントからサーバーへのシステムユーザーアクセスを拒否することが推奨されます。

vsftpd ですべてのユーザーアカウントを無効にするには、以下のディレクティブを /etc/vsftpd/vsftpd.conf に追加します。

local_enable=NO

4.3.9.3.1. ユーザーアカウントの制限

特定のアカウントまたは特定のアカウントグループ(root ユーザーや、sudo 権限を持つユーザーなど)の FTP アクセスを無効にするには、「Root アクセスの拒否」で説明されているように PAM リストファイルを使用するのが最も簡単な方法です。vsftpd の PAM 設定ファイルは /etc/pam.d/vsftpd です。

また、各サービスでユーザーアカウントを直接無効にすることもできます。

vsftpd で特定のユーザーアカウントを無効にするには、ユーザー名を /etc/vsftpd/ftpusersに追加します。

4.3.9.4. TCP Wrapper を使用してアクセスを制御する

TCP Wrappers を使用して、「TCP Wrapper と xinetd を使用したサービスの保護」で概説されているように、いずれかの FTP デーモンへのアクセスを制御します。

4.3.10. Postfix のセキュア化

Postfix は、Simple Mail Transfer Protocol (SMTP) を使用して他の MTA 間で電子メッセージを配信したり、クライアントや配信エージェントに電子メールを送信したりするメール転送エージェント (MTA) です。多くの MTA は相互にトラフィックを暗号化することが可能ですが、ほとんどの場合は暗号化しません。そのため、パブリックネットワークを介して電子メールを送信することは、本質的に安全でない通信形式と見なされます。Red Hat Enterprise Linux 7 では、Sendmail に代わり、Postfix がデフォルト MTA となっています。

Postfix サーバーの実装を計画している人は、以下の問題に対処することが推奨されます。

4.3.10.1. サービス拒否攻撃を制限する

電子メールの性質上、断固とした攻撃者は、サーバーを非常に簡単にメールで溢れさせ、サービス拒否を引き起こすことができます。このような攻撃の有効性は、/etc/postfix/main.cf ファイルのディレクティブの制限を設定することで制限できます。すでにあるディレクティブの値を変更したり、必要なディレクティブを以下のような形式で好きな値で追加したりすることができます。

<directive> = <value>

.サービス拒否攻撃を制限するために使用できるディレクティブの一覧を以下に示します。

smtpd_client_connection_rate_limit - 時間単位ごとにクライアントがこのサービスに対して実行できる接続試行の最大数（以下で説明）。デフォルト値は 0 です。これは、クライアントが時間単位で Postfix が受け入れることができる数と同じ数の接続を行うことができることを意味します。デフォルトでは、信頼できるネットワーク内のクライアントは除外されます。
anvil_rate_time_unit: この時間単位は、レート制限の計算に使用されます。デフォルト値は、60 秒です。
smtpd_client_event_limit_exceptions - 接続およびレート制限コマンドから除外されるクライアント。デフォルトでは、信頼できるネットワーク内のクライアントは除外されます。
smtpd_client_message_rate_limit - クライアントが時間単位ごとに要求できるメッセージ配信の最大数(Postfix が実際にこれらのメッセージを受け入れるかどうかに関係なく)。
default_process_limit: 指定されたサービスを提供する Postfix 子プロセスのデフォルトの最大数。この制限は、master.cf ファイルの特定サービスに対してオーバーライドできます。デフォルト値は 100 です。
queue_minfree - メールを受信するために必要なキューファイルシステムの空き領域の最小空き容量（バイト単位）。これは現在、Postfix SMTP サーバーがメールをまったく受け取らないかどうかを決定するために使用されています。デフォルトでは、Postfix SMTP サーバーは、空き容量が message_size_limit の 1.5 倍未満の場合、MAIL FROM コマンドを拒否します。空き容量の最小値をこれよりも高く指定するには、message_size_limit の 1.5 倍以上の queue_minfree 値を指定します。デフォルトの queue_minfree 値は 0 です。
header_size_limit: メッセージヘッダーを保存するためのメモリーの最大量（バイト単位）。ヘッダーの方が大きい場合、超過分は破棄されます。デフォルト値は 102400 です。
message_size_limit: エンベロープ情報を含むメッセージの最大サイズ（バイト単位）。デフォルト値は 10240000 です。

4.3.10.2. NFS と Postfix

メールスプールディレクトリー /var/spool/postfix/ を NFS 共有ボリュームに配置しないでください。NFSv2 および NFSv3 では、ユーザー ID およびグループ ID の管理を行わないため、2 人以上のユーザーが同じ UID を持ち、互いのメールを受信および読み取ることができます。

注記

Kerberos を使用する NFSv4 では、SECRPC_GSS カーネルモジュールは UID ベースの認証を使用しないため、これは当てはまりません。しかし、メールスプールディレクトリーを NFS 共有ボリュームに 置かない ことは、引き続きグッドプラクティスとされています。

4.3.10.3. メール専用ユーザー

Postfix サーバーのローカルユーザーによる不正使用を防止するために、メールユーザーは電子メールプログラムを使用してのみ Postfix サーバーにアクセスすることが最善とされます。メールサーバーのシェルアカウントは許可しないでください。/etc/passwd ファイルのすべてのユーザーシェルは /sbin/nologin に設定する必要があります(root ユーザーを除く可能性があります)。

4.3.10.4. Postfix ネットワークリスニングの無効化

デフォルトでは、Postfix はローカルのループバックアドレスのみをリッスンするように設定されています。これを確認するには、/etc/postfix/main.cf ファイルを表示します。

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

inet_interfaces = localhost

これにより、Postfix はネットワークからではなく、ローカルシステムからのメールメッセージ (cron ジョブのレポートなど) のみを受け入れるようになります。これはデフォルトの設定で、Postfix をネットワーク攻撃から保護します。

localhost の制限を削除し、Postfix がすべてのインターフェイスをリッスンできるようにするには、inet_interfaces = all 設定を使用できます。

4.3.10.5. Postfix が SASL を使用する設定

Red Hat Enterprise Linux 7 バージョンの Postfix は、SMTP 認証（または SMTPAUTH ）に Dovecot または Cyrus SASL 実装を使用できます。SMTP 認証は Simple Mail Transfer Protocol の拡張機能です。有効にすると、SMTP クライアントは、サーバーとクライアントの両方でサポートおよび許可される認証方法を使用して SMTP サーバーに対して認証する必要があります。本セクションでは、Dovecot SASL 実装を利用するように Postfix を設定する方法について説明します。

Dovecot POP/IMAP サーバーをインストールし、システムで Dovecot SASL 実装を利用できるようにするには、root ユーザーとして次のコマンドを発行します。

~]# yum install dovecot

Postfix SMTP サーバーは、UNIX ドメインソケットまたは TCP ソケット のいずれかを使用して、Dovecot SASL 実装と通信できます。後者の方法は、Postfix と Dovecot のアプリケーションが別々のマシンで実行されている場合にのみ必要です。このガイドでは、プライバシーを強化する UNIX ドメインソケット方式を優先しています。

Postfix に Dovecot SASL 実装を使用するように指示するには、両方のアプリケーションに対して多くの設定変更を実行する必要があります。以下の手順に従ってください。

Dovecot のセットアップ

メインの Dovecot 設定ファイル /etc/dovecot/conf.d/10-master.conf を変更して、次の行を含めます（デフォルトの設定ファイルにほとんどの関連セクションがすでに含まれているため、その行はコメント解除する必要があります）。
```
service auth {
  unix_listener /var/spool/postfix/private/auth {
    mode = 0660
    user = postfix
    group = postfix
  }
}
```
上記の例では、Postfix と Dovecot の間の通信に UNIX ドメインソケットを使用することを前提としています。また、/var/spool/postfix/ ディレクトリーにあるメールキューを含む Postfix SMTP サーバーのデフォルト設定と、postfix ユーザーおよびグループで実行されているアプリケーションを想定しています。このようにして、読み取りおよび書き込みのパーミッションは postfix ユーザーおよびグループに制限されます。
または、以下の設定を使用して、TCP を介して Postfix 認証要求をリッスンするように Dovecot を設定できます。
```
service auth {
  inet_listener {
    port = 12345
  }
}
```
上記の例では、12345 を使用するポートの数に置き換えます。
/etc/dovecot/conf.d/10-auth.conf 設定ファイルを編集して、Postfix SMTP サーバーに plain および login 認証メカニズムを提供するように Dovecot に指示します。
```
auth_mechanisms = plain login
```

Postfix のセットアップ

Postfix の場合、メインの設定ファイル /etc/postfix/main.cf のみを変更する必要があります。以下の設定ディレクティブを設定できます。

Postfix SMTP サーバーで SMTP 認証を有効にします。
```
smtpd_sasl_auth_enable = yes
```
SMTP 認証に Dovecot SASL 実装を使用するように Postfix に指示します。
```
smtpd_sasl_type = dovecot
```
Postfix キューディレクトリーに相対的な認証パスを指定します（相対パスを使用すると、Postfix サーバーが chroot で実行されているかどうかに関係なく設定が機能することが保証されます）。
```
smtpd_sasl_path = private/auth
```
この手順では、Postfix と Dovecot の間の通信に UNIX ドメインソケットを使用することを前提としています。通信に TCP ソケットを使用する場合に、別のマシンで Dovecot を検索するように Postfix を設定するには、以下のような設定値を使用します。
```
smtpd_sasl_path = inet:127.0.0.1:12345
```
上記の例では、127.0.0.1 を Dovecot マシンの IP アドレスに置き換え、12345 を Dovecot の/etc/dovecot/conf.d/10-master.conf 設定ファイルで指定されたポートに置き換える必要があります。
Postfix SMTP サーバーがクライアントに提供する SASL メカニズムを指定します。暗号化されたセッションと暗号化されていないセッションで、異なるメカニズムを指定できることに注意してください。
```
smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_tls_security_options = noanonymous
```
上記の例では、暗号化されていないセッションの間、匿名認証は許可されず、暗号化されていないユーザー名やパスワードを送信するメカニズムも許可されないことを指定しています。暗号化されたセッション( TLSを使用)の場合、非匿名認証メカニズムのみが許可されます。
許可される SASL メカニズムを制限するためにサポートされるすべてのポリシーの一覧は、http://www.postfix.org/SASL_README.html#smtpd_sasl_security_options を参照してください。

4.3.11. SSH のセキュア化

Secure Shell(SSH) は、他のシステムと安全なチャンネルで通信するために使用される強力なネットワークプロトコルです。SSH を介した送信は暗号化され、傍受から保護されます。SSH プロトコルおよび Red Hat Enterprise Linux 7 での SSH サービスの使用に関する一般的な情報は、Red Hat Enterprise Linux 7 システム管理者のガイドの OpenSSH の章を参照してください。

重要

このセクションでは、SSH 設定を保護するための最も一般的な方法について説明します。この提案された対策のリストは、完璧または決定的なものと見なされるべきではありません。sshd デーモンの動作を変更するために利用できるすべての設定ディレクティブの説明については、sshd _config (5 )を参照してください。また、SSH の基本的な概念については ssh (1) を参照してください。

4.3.11.1. 暗号化ログイン

SSH は、コンピューターにログインするための暗号鍵の使用をサポートしています。これは、パスワードのみを使用するよりもはるかに安全です。この方法を他の認証方法と組み合わせると、多要素認証と見なすことができます。複数の認証方法を使用する場合の詳細は、「複数の認証方法」を参照してください。

認証に暗号化キーを使用できるようにするには、/etc/ssh/sshd_config ファイルの PubkeyAuthentication 設定ディレクティブを yes に設定する必要があります。これがデフォルト設定であることに注意してください。PasswordAuthentication ディレクティブを no に設定して、ログインにパスワードを使用する可能性を無効にします。

SSH キーは、ssh-keygen コマンドを使用して生成できます。追加の引数なしで呼び出されると、2048 ビットの RSA キーセットが作成されます。鍵はデフォルトで ~/.ssh/ ディレクトリーに保存されます。-b スイッチを利用すると、キーのビット強度を変更できます。通常、2048 ビットのキーを使用するだけで十分です。Red Hat Enterprise Linux 7 システム管理者ガイドの Configuring OpenSSH の章には、キーペアの生成に関する詳細な情報が記載されています。

~/.ssh/ ディレクトリーに 2 つのキーが表示されるはずです。ssh-keygen コマンドの実行時にデフォルトを受け入れた場合、生成されたファイルの名前は id_rsa と id_rsa.pub で、それぞれ秘密鍵と公開鍵が含まれます。秘密鍵は、ファイルの所有者以外には読めないようにして、常に漏洩から保護する必要があります。ただし、公開鍵は、ログインするシステムに転送する必要があります。ssh-copy-id コマンドを使用して、鍵をサーバーに転送できます。

~]$ ssh-copy-id -i [user@]server

また、このコマンドは公開鍵を サーバー の ~/.ssh/authorized_keys ファイルに自動的に追加します。sshd デーモンは、サーバーにログインしようとするとこのファイルをチェックします。

パスワードやその他の認証メカニズムと同様に、SSH キーを定期的に変更する必要があります。その場合は、authorized_keys ファイルから未使用のキーが削除されていることを確認してください。

4.3.11.2. 複数の認証方法

複数の認証方法または多要素認証を使用すると、不正アクセスに対する保護レベルが向上するため、システムを強化してシステムが危険にさらされるのを防ぐ場合は、考慮する必要があります。多要素認証を使用するシステムにログインしようとするユーザーは、アクセスを許可されるために、指定されたすべての認証方法を正常に完了する必要があります。

/etc/ssh/sshd_config ファイルの AuthenticationMethods 設定ディレクティブを使用して、使用する認証方法を指定します。このディレクティブを使用して、必要な認証方法のリストを複数定義できることに注意してください。その場合、ユーザーは少なくとも 1 つのリストのすべてのメソッドを完了する必要があります。リストは空白で区切る必要があり、リスト内の個々の認証方法名はコンマで区切る必要があります以下に例を示します。

AuthenticationMethods publickey,gssapi-with-mic publickey,keyboard-interactive

上記の AuthenticationMethods ディレクティブを使用して設定された sshd デーモンは、ログインしようとしているユーザーが publickey 認証の後に gssapi-with-mic 認証または keyboard-interactive 認証のいずれかが正常に完了した場合にのみアクセスを許可します。要求された各認証方法は、/etc/ssh/sshd_config ファイルの対応する設定ディレクティブ( PubkeyAuthenticationなど)を使用して明示的に有効にする必要があります。利用可能な認証方法の一般的な一覧は、ssh (1) の『AUTHENTICATION』セクションを参照してください。

4.3.11.3. SSH の他のセキュア化

プロトコルのバージョン

Red Hat Enterprise Linux 7 で提供される SSH プロトコルの実装は、SSH クライアント用の SSH-1 バージョンと SSH-2 バージョンの両方をサポートしますが、可能な限り後者のみを使用する必要があります。SSH-2 バージョンには、古い SSH-1 に比べて多くの改良が含まれており、高度な設定オプションの大部分は、SSH-2 を使用している場合にのみ使用できます。

Red Hat は、SSH プロトコルが使用される認証と通信を保護する範囲を最大化するために、SSH -2 を使用することを推奨します。sshd デーモンがサポートするプロトコルのバージョンは、/etc/ssh/sshd_config ファイルの Protocol 設定ディレクティブを使用して指定できます。デフォルト設定は 2 です。SSH-2 バージョンは、Red Hat Enterprise Linux 7 SSH サーバーでサポートされている唯一のバージョンであることに注意してください。

鍵のタイプ

ssh-keygen コマンドは、デフォルトで SSH-2 RSA 鍵のペアを生成しますが、-t オプションを使用して、DSA 鍵または ECDSA 鍵を生成するように指示することもできます。ECDSA (Elliptic Curve Digital Signature Algorithm) は、同等の対称鍵長で RSA よりも優れたパフォーマンスを提供します。また、短いキーも生成します。

デフォルト以外のポート

デフォルトでは、sshd デーモンは TCP ポート 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 ディレクティブを使用して指定された新しいポート番号に置き換えます。

root ログインなし

特定のユースケースで root ユーザーとしてログインする必要がない場合は、/etc/ssh/sshd_config ファイルで PermitRootLogin 設定ディレクティブを no に設定することを検討してください。root ユーザーとしてログインする可能性を無効にすることで、管理者は、通常のユーザーとしてログインし、root 権限を取得した後に、どのユーザーがどの特権コマンドを実行するかを監査できます。

⁠X セキュリティー拡張機能の使用

Red Hat Enterprise Linux 7 クライアントの X サーバーは、X Security 拡張を提供しません。そのため、クライアントは X11 転送を使用して信頼できない SSH サーバーに接続するときに別のセキュリティー層を要求できません。ほとんどのアプリケーションは、この拡張機能を有効にして実行できませんでした。デフォルトでは、/etc/ssh/ssh_config ファイルの ForwardX11Trusted オプションが yes に設定され、ssh -X remote_machine （信頼できないホスト）コマンドと ssh -Y remote_machine （信頼できるホスト）コマンドには違いがありません。

警告

Red Hat では、信頼できないホストへの接続時は X11 転送を使用しないことを推奨しています。

4.3.12. PostgreSQL のセキュリティー確保

PostgreSQLは、オブジェクトリレーショナルデータベース管理システム (DBMS) です。Red Hat Enterprise Linux 7 では、postgresql-server パッケージは PostgreSQL を提供します。インストールされていない場合は、root ユーザーになり、以下のコマンドを入力してインストールします。

~]# yum install postgresql-server

PostgreSQL の使用を開始する前に、ディスク上のデータベースストレージ領域を初期化する必要があります。これは、データベースのクラスターと呼ばれます。データベースクラスターを初期化するには、PostgreSQL と共にインストールされる initdb コマンドを使用します。データベースクラスターの希望するファイルシステムの場所は、-D オプションで示されます。以下に例を示します。

~]$ initdb -D /home/postgresql/db1

initdb コマンドは、指定したディレクトリーがまだ存在しない場合は作成しようとします。今回の例では、/home/postgresql/db1 という名前を使用します。/home/postgresql/db1 ディレクトリーには、データベースに保存されているすべてのデータと、クライアント認証設定ファイルが含まれています。

~]$ cat pg_hba.conf
# PostgreSQL Client Authentication Configuration File
# This file controls: which hosts are allowed to connect, how clients
# are authenticated, which PostgreSQL user names they can use, which
# databases they can access.  Records take one of these forms:
#
# local      DATABASE  USER  METHOD  [OPTIONS]
# host       DATABASE  USER  ADDRESS  METHOD  [OPTIONS]
# hostssl    DATABASE  USER  ADDRESS  METHOD  [OPTIONS]
# hostnossl  DATABASE  USER  ADDRESS  METHOD  [OPTIONS]

pg_hba.conf ファイルの以下の行により、認証されたローカルユーザーはユーザー名を使用してデータベースにアクセスできます。

local   all             all                                     trust

これは、データベースユーザーを作成し、ローカルユーザーを作成しないレイヤー型アプリケーションを使用する場合に、問題となることがあります。システム上のすべてのユーザー名を明示的に制御しない場合は、pg_hba.conf ファイルからこの行を削除します。

4.3.13. Docker のセキュリティー確保

Dockerは、Linux コンテナー内でのアプリケーションのデプロイメントを自動化するオープンソースプロジェクトで、アプリケーションとそのランタイム依存関係をコンテナーにパッケージ化する機能を提供しています。Docker ワークフローをより安全にするには、Red Hat Enterprise Linux Atomic Host 7 Container Security Guide の手順に従います。

4.3.14. DDoS 攻撃からの memcached の保護

Memcached は、オープンソースの高性能分散メモリーオブジェクトキャッシングシステムです。これは、本来は汎用的なものですが、データベースの負荷を軽減することで、動的 Web アプリケーションのパフォーマンスを向上させるために主に使用されます。

Memcached は、データベース呼び出し、API 呼び出し、またはページレンダリングの結果から、文字列やオブジェクトなどの任意のデータの小さなチャンクを格納するメモリー内のキーと値のストアです。Memcached を使用すると、アプリケーションは、システムが必要以上にメモリーを搭載している部分からメモリーを取り出し、アプリケーションが必要未満のメモリーしか搭載していない領域へアクセスできるようにします。

memcached の脆弱性

2018 年に、パブリックインターネットに公開されている memcached サーバーを悪用することによる DDoS 増幅攻撃の脆弱性が発見されました。これらの攻撃は、トランスポートに UDP プロトコルを使用する memcached 通信を利用します。増幅率が高いため、攻撃は効果的です。数百バイトのサイズの要求は、数メガバイトまたは数百メガバイトのサイズの応答を生成することができます。この問題には CVE-2018-1000115 が割り当てられています。

ほとんどの場合、memcached サービスはパブリックインターネットに公開する必要はありません。このような露出には、リモートの攻撃者が memcached に保存されている情報を漏洩または変更できるなど、独自のセキュリティー問題があります。

memcached の強化

セキュリティーリスクを軽減するために、以下の手順のうち、お使いの設定に該当するものをできるだけ多く実行してください。

LAN にファイアウォールを設定してください。ローカルネットワーク内からのみ、memcached サーバーにアクセスできるようにする必要がある場合は、memcached が使用するポートへの外部トラフィックを許可しないでください。たとえば、許可されているポートのリストから、デフォルトで memcached によって使用されるポート 11211 を削除します。
```
~]# firewall-cmd --remove-port=11211/udp
~]# firewall-cmd --runtime-to-permanent
```
特定の IP 範囲にポート 11211 の使用を許可する firewalld コマンドについては、「ゾーンを使用し、ソースに応じた着信トラフィックの管理」を参照してください。
クライアントが本当にこのプロトコルを必要としない限り、/etc/sysconfig/memcached ファイルの OPTIONS 変数に -U 0 -p 11211 値を追加して UDP を無効にします。
```
OPTIONS="-U 0 -p 11211"
```
アプリケーションと同じマシンで単一の memcached サーバーを使用する場合、ローカルホストトラフィックのみをリッスンするように memcached を設定します。-l 127.0.0.1,::1 の値を /etc/sysconfig/memcached の OPTIONS に追加します。
```
OPTIONS="-l 127.0.0.1,::1"
```
認証の変更が可能な場合は、SASL (Simple Authentication and Security Layer) 認証を有効にしてください。
1. /etc/sasl2/memcached.conf ファイルでを変更または追加します。
  sasldb_path: /path.to/memcached.sasldb
2. SASL データベースにアカウントを追加します。
  ~]# saslpasswd2 -a memcached -c cacheuser -f /path.to/memcached.sasldb
3. memcached のユーザーとグループがデータベースにアクセスできることを確認します。
  ~]# chown memcached:memcached /path.to/memcached.sasldb
4. /etc/sysconfig/memcached に -S 値を OPTIONS に追加して、memcached で SASL サポートを有効にします。
  OPTIONS="-S"
5. memcached サーバーを再起動して、変更を適用します。
6. SASL データベースで作成したユーザー名とパスワードを、お使いのアプリケーションの memcached クライアント設定に追加します。
memcached クライアントとサーバー間の通信を stunnel で暗号化します。memcached は TLS をサポートしていないため、回避策は、memcached プロトコルの上に TLS を提供する stunnel などのプロキシーを使用することです。
PSK (Pre Shared Keys)を使用するか、ユーザー証明書を使用するように stunnel を設定できます。証明書を使用する場合、認証されたユーザーのみがお使いの memcached サーバーにアクセスでき、トラフィックは暗号化されます。
重要
トンネルを使用して memcached にアクセスする場合は、サービスがローカルホストでのみリッスンしているか、ファイアウォールがネットワークから memcached ポートへのアクセスを阻止しているかを確認してください。
詳細は、「stunnel の使用」を参照してください。

4.4. ネットワークアクセスのセキュア化

4.4.1. TCP Wrapper と xinetd を使用したサービスの保護

TCP Wrapper の機能は、サービスへのアクセスを拒否するだけではありません。このセクションでは、これらを使用して接続バナーを送信し、特定のホストからの攻撃を警告し、ロギング機能を強化する方法を説明します。TCP Wrapper の機能および制御言語に関する詳細は、hosts_options(5) の man ページを参照してください。利用可能なフラグ (サービスに適用できるオプションとして機能) については、xinetd.conf(5) の man ページを参照してください。

4.4.1.1. TCP Wrapper と接続バナー

ユーザーがサービスに接続する際に適切なバナーを表示することは、潜在的な攻撃者に対して、システム管理者が警戒していることを知らせる良い方法です。システムに関するどの情報をユーザーに表示するかを制御することもできます。サービスに TCP Wrapper バナーを実装するには、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. TCP Wrapper と攻撃警告

特定のホストまたはネットワークがサーバーの攻撃を検出した場合、TCP Wrapper を使用して、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. TCP Wrapper とロギングの強化

特定のタイプの接続が他の接続よりも懸念される場合は、severity オプションを使用してそのサービスのログレベルを上げることができます。

この例では、FTP サーバーのポート 23 (Telnet ポート) に接続しようとしている人はクラッカーであると想定します。これを示すには、ログファイルにデフォルトのフラグ info の代わりに emerg フラグを配置し、接続を拒否します。

これを行うには、以下の行を /etc/hosts.deny に配置します。

in.telnetd : ALL : severity emerg

これはデフォルトの authpriv ロギング機能を使用しますが、優先度をデフォルト値の info から emerg に上げます。これにより、ログメッセージがコンソールに直接投稿されます。

4.4.2. リッスンしているポートの確認

使用されていないポートは、攻撃の可能性を避けるために閉じることが重要です。リスニング状態にある予期せぬポートについては、侵入の可能性がないか調査する必要があります。

開いているポートスキャンでの netstat の使用

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
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      1/systemd
tcp        0      0 192.168.124.1:53        0.0.0.0:*               LISTEN      1829/dnsmasq
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1176/sshd
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      1177/cupsd
tcp6       0      0 :::111                  :::*                    LISTEN      1/systemd
tcp6       0      0 ::1:25                  :::*                    LISTEN      1664/master
sctp              0.0.0.0:2500                                      LISTEN   20985/sctp_darn
udp        0      0 192.168.124.1:53        0.0.0.0:*                           1829/dnsmasq
udp        0      0 0.0.0.0:67              0.0.0.0:*                           977/dhclient
...

netstat コマンドの -l オプションを使用して、リッスンしているサーバーソケットのみを表示します。

~]# netstat -tlnw
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN
tcp        0      0 192.168.124.1:53        0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN
tcp6       0      0 :::111                  :::*                    LISTEN
tcp6       0      0 :::22                   :::*                    LISTEN
tcp6       0      0 ::1:631                 :::*                    LISTEN
tcp6       0      0 ::1:25                  :::*                    LISTEN
raw6       0      0 :::58                   :::*                    7

開いているポートスキャンでの ss の使用

または、ss ユーティリティーを使用して、リスニング状態で開いているポートを一覧表示します。netstat よりも多くの TCP および状態情報を表示できます。

~]# ss -tlw
etid State      Recv-Q Send-Q     Local Address:Port                      Peer Address:Port
udp   UNCONN     0      0                     :::ipv6-icmp                           :::*
tcp   LISTEN     0      128                    *:sunrpc                               *:*
tcp   LISTEN     0      5          192.168.124.1:domain                               *:*
tcp   LISTEN     0      128                    *:ssh                                  *:*
tcp   LISTEN     0      128            127.0.0.1:ipp                                  *:*
tcp   LISTEN     0      100            127.0.0.1:smtp                                 *:*
tcp   LISTEN     0      128                   :::sunrpc                              :::*
tcp   LISTEN     0      128                   :::ssh                                 :::*
tcp   LISTEN     0      128                  ::1:ipp                                 :::*
tcp   LISTEN     0      100                  ::1:smtp                                :::*

~]# ss -plno -A tcp,udp,sctp
Netid State      Recv-Q Send-Q       Local Address:Port                      Peer Address:Port
udp   UNCONN     0      0            192.168.124.1:53                                   *:*                   users:(("dnsmasq",pid=1829,fd=5))
udp   UNCONN     0      0                 *%virbr0:67                                   *:*                   users:(("dnsmasq",pid=1829,fd=3))
udp   UNCONN     0      0                        *:68                                   *:*                   users:(("dhclient",pid=977,fd=6))
...
tcp   LISTEN     0      5            192.168.124.1:53                                   *:*                   users:(("dnsmasq",pid=1829,fd=6))
tcp   LISTEN     0      128                      *:22                                   *:*                   users:(("sshd",pid=1176,fd=3))
tcp   LISTEN     0      128              127.0.0.1:631                                  *:*                   users:(("cupsd",pid=1177,fd=12))
tcp   LISTEN     0      100              127.0.0.1:25                                   *:*                   users:(("master",pid=1664,fd=13))
...
sctp  LISTEN     0      5                        *:2500                                 *:*                   users:(("sctp_darn",pid=20985,fd=3))

UNCONN 状態は、UDP リスニングモードのポートを示します。

外部システムから、ss 出力に示されるすべての IP アドレス(localhost 127.0.0.0 または ::1 範囲を除く)に対してスキャンを行います。IPv6 アドレスをスキャンするには、-6 オプションを使用します。

次に、ネットワーク経由で最初のシステムに接続している別のリモートマシンから nmap ツールを使用して外部チェックを行います。これは、firewalld のルールを検証するために使用できます。次に、TCP 接続をリッスンしているポートを判別する例を示します。

~]# nmap -sT -O 192.168.122.65
    Starting Nmap 6.40 ( http://nmap.org ) at 2017-03-27 09:30 CEST
    Nmap scan report for 192.168.122.65
    Host is up (0.00032s latency).
    Not shown: 998 closed ports
    PORT    STATE SERVICE
    22/tcp  open  ssh
    111/tcp open  rpcbind
    Device type: general purpose
    Running: Linux 3.X
    OS CPE: cpe:/o:linux:linux_kernel:3
    OS details: Linux 3.7 - 3.9
    Network Distance: 0 hops

    OS detection performed. Please report any incorrect results at http://nmap.org/submit/ .
    Nmap done: 1 IP address (1 host up) scanned in 1.79 seconds

TCP 接続スキャン (-sT) は、TCP SYN スキャン (-sS) がオプションでない場合のデフォルトの TCP スキャンタイプです。-O オプションは、ホストのオペレーティングシステムを検出します。

netstat と ss を使用して開いている SCTP ポートのスキャン

netstat ユーティリティーは、Linux ネットワークサブシステムに関する情報を出力します。開いている Stream Control Transmission Protocol (SCTP)ポートのプロトコル統計を表示するには、root で以下のコマンドを入力します。

~]# netstat -plnS
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address   Foreign Address  State    PID/Program name
sctp                127.0.0.1:250                    LISTEN   4125/sctp_darn
sctp       0      0 127.0.0.1:260   127.0.0.1:250    CLOSE    4250/sctp_darn
sctp       0      0 127.0.0.1:250   127.0.0.1:260    LISTEN   4125/sctp_darn

~]# netstat -nl -A inet,inet6 | grep 2500
sctp                0.0.0.0:2500                                    LISTEN

ss ユーティリティーは、SCTP のオープンポートを表示することもできます。

~]# ss -an | grep 2500
sctp   LISTEN     0      5         *:2500                  *:*

詳細は、ss(8)、netstat(8)、nmap(1)、および services(5) の man ページを参照してください。

4.4.3. ソースルーティングの無効化

ソースルーティングは、IP パケットが情報 (アドレスのリスト) を伝送できるようにするインターネットプロトコルメカニズムであり、パケットがたどる必要のあるパスをルーターに通知します。ルートが通過するときにホップを記録するオプションもあります。取得されたホップのリストである "route record" は、宛先に送信元へのリターンパスを提供します。これにより、送信元 (送信ホスト) は、一部またはすべてのルーターのルーティングテーブルを無視して、大まかにまたは厳密にルートを指定できます。これにより、ユーザーは悪意のある目的でネットワークトラフィックをリダイレクトできます。このため、ソースベースのルーティングは無効にする必要があります。

accept_source_route オプションを使用すると、ネットワークインターフェイスが Strict Source Routing (SSR) または Loose Source Routing (LSR) のオプションが設定されたパケットを受け入れます。ソースルーティングされたパケットの受け入れは、sysctl の設定によって制御されます。SSR または LSR オプションが設定されたパケットをドロップするために、root で次のコマンドを発行します。

~]# /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

重要

少なくとも、net.ipv4.conf.all.send_redirects オプションまたは net.ipv4.conf.interface.send_redirects オプションのいずれか一方が有効になっていると、ICMP リダイレクトの送信はアクティブなままとなります。すべてのインターフェイスの net.ipv4.conf. interface .send_redirects オプションを 0 の値に設定するようにしてください。新しいインターフェイスを追加するたびに ICMP リクエストの送信を自動的に無効にするには、次のコマンドを入力します。

~]# /sbin/sysctl -w net.ipv4.conf.default.send_redirects=0

IPv4 リダイレクトパケットの送信を無効にするディレクティブは 1 つのみです。このような IPv4 と IPv6 の違いを生んだ「IPv6 Node Requirements」については、RFC4294を参照してください。

注記

これらの設定を再起動後も保持するには、/etc/sysctl.conf ファイルを変更します。たとえば、すべてのインターフェイスですべての IPv4 ICMP リダイレクトパケットの受け入れを無効にするには、root ユーザーとして実行しているエディターで /etc/sysctl.conf ファイルを開き、以下の行を追加します。

net.ipv4.conf.all.send_redirects=0

詳細は、sysctl の man ページの sysctl (8) を参照してください。ソースベースのルーティングとそのバリアントに関連するインターネットオプションの説明については、RFC791 を参照してください。

警告

イーサネットネットワークは、ARP または MAC アドレスのスプーフィング、承認されていない DHCP サーバー、IPv6 ルーターまたはネイバーアドバタイズメントなど、トラフィックをリダイレクトする方法をさらに提供します。また、ユニキャストトラフィックがブロードキャストされることもあり、情報漏えいの原因となります。これらの弱点は、ネットワークオペレーターが実装する具体的な対策によってのみ対処することができます。ホストベースの対策は十分に効果的ではありません。

4.4.3.1. 逆方向パス転送

逆方向パス転送は、あるインターフェイスを介して到達したパケットが、別のインターフェイスを介して出ることを防ぐために使用されます。発信経路と着信経路が異なる場合、非対称ルーティングと呼ばれることがあります。ルーターは多くの場合、この方法でパケットをルーティングしますが、ほとんどのホストはこれを行う必要はありません。ただし、あるリンクでトラフィックを送信し、別のリンクで別のサービスプロバイダーからトラフィックを受信するようなアプリケーションは例外となります。たとえば、専用回線と xDSL の組み合わせや、衛星回線と 3G モデムの併用などです。このようなシナリオに該当する場合は、受信インターフェイスで逆方向パス転送をオフにする必要があります。つまり、ユーザーがローカルサブネットから IP アドレスのスプーフィングを防ぎ、DDoS 攻撃の可能性を低減するため、必要であると分からない限り、有効にすることが最適です。

注記

Red Hat Enterprise Linux 7 はデフォルトで Strict Reverse Path Forwarding を使用します。これは、RFC 3704, Ingress Filtering for Multihomed Networks の厳密な逆方向パスに関する推奨事項に準拠します。

警告

転送が有効になっている場合、逆方向パス転送は、（たとえば iptables ルールなど）ソースアドレス検証の他の手段がある場合にのみ無効にする必要があります。

rp_filter

逆方向パス転送は、rp_filterディレクティブによって有効になります。sysctl ユーティリティーを使用すると、実行中のシステムに変更を加えることができます。永続的な変更は、行を /etc/sysctl.conf ファイルに追加することで実行できます。rp_filter オプションは、カーネルに 3 つのモードのうち 1 つを選択するよう指示するために使用されます。

一時的なグローバル変更を行うには、root で以下のコマンドを入力します。

sysctl -w  net.ipv4.conf.default.rp_filter=integer
sysctl -w net.ipv4.conf.all.rp_filter=integer

ここで、integer は、以下のいずれかになります。

0 - ソースの検証がありません。
1 - RFC 3704 で定義された厳密なモード。
2 - RFC 3704 で定義された疎結合モード。

この設定は、以下のように net.ipv4.conf. interface .rp_filter コマンドを使用して、ネットワークインターフェイス ごとに上書きできます。

sysctl -w net.ipv4.conf.interface.rp_filter=integer

注記

これらの設定を再起動後も保持するには、/etc/sysctl.conf ファイルを変更します。たとえば、すべてのインターフェイスのモードを変更するには、root ユーザーとして実行しているエディターで /etc/sysctl.conf ファイルを開き、以下の行を追加します。

net.ipv4.conf.all.rp_filter=2

IPv6_rpfilter

IPv6 プロトコルの場合、firewalld デーモンはデフォルトで逆方向パス転送に適用されます。この設定は、/etc/firewalld/firewalld.conf ファイルで確認できます。IPv6_rpfilter オプションを設定することで、firewalld の動作を変更できます。

逆方向パス転送のカスタム設定が必要な場合は、以下のように ip6tables コマンドを使用して、firewalld デーモンなしでこれを実行できます。

ip6tables -t raw -I PREROUTING -m rpfilter --invert -j DROP

このルールは、特にステートフルマッチングルールの前にすべてのトラフィックに適用されるように、raw/PREROUTING チェーンの先頭の近くに挿入される必要があります。iptables サービスおよび ip6tables サービスの詳細は、「iptablesを使用した IP セットの設定および制御」を参照してください。

パケット転送の有効化

システム外部から到着したパケットを別の外部ホストに転送できるようにするには、カーネルで IP フォワーディングを有効にする必要があります。root としてログインし、/etc/sysctl.conf ファイルの net.ipv4.ip_forward = 0 を読み取る行を以下のように変更します。

net.ipv4.ip_forward = 1

/etc/sysctl.conf ファイルから変更を読み込むには、以下のコマンドを入力します。

/sbin/sysctl -p

IP 転送が有効になっているかどうかを確認するには、root で以下のコマンドを実行します。

/sbin/sysctl net.ipv4.ip_forward

上記のコマンドが 1 を返すと、IP 転送が有効になります。0 を返す場合は、以下のコマンドを使用して手動でオンにできます。

/sbin/sysctl -w net.ipv4.ip_forward=1

4.4.3.2. 関連情報

逆方向パス転送の詳細については、以下のリソースを参照してください。

インストールされているドキュメント
/usr/share/doc/kernel-doc-バージョン/Documentation/networking/ip-sysctl.txt: このファイルには、ディレクトリーで利用可能なファイルとオプションの完全なリストが含まれています。カーネルのドキュメントに初めてアクセスする前に、root で以下のコマンドを入力します。
```
~]# yum install kernel-doc
```
オンラインドキュメント
マルチホームネットワークの Ingress フィルターリングの説明については、RFC 3704 を参照してください。

4.5. DNSSEC を使用した DNS トラフィックのセキュア化

4.5.1. DNS の概要

DNSSEC は、DNSSEC( Domain Name System Security Extensions )のセットで、DNS クライアントが DNS ネームサーバーからの応答の整合性を認証およびチェックし、発信元を検証し、転送中に改ざんされているかどうかを判断できるようにします。

4.5.2. DNSSEC について

インターネット経由で接続するために、Web サイトの数が増え、HTTPS を使用して安全に接続する機能が提供されるようになりました。ただし、HTTPS Web サーバーに接続する前に、IP アドレスを直接入力しない限り、DNS ルックアップを実行する必要があります。これらの DNS ルックアップは安全 ではなく、認証がないため、中間者 攻撃の対象となります。つまり、DNS クライアントは、特定の DNS ネームサーバーから送られるように見える応答が本物であり、改ざんされていないことを確信できません。さらに重要なことに、再帰的ネームサーバーは、他のネームサーバーから取得したレコードが本物であることを確認できません。DNS プロトコルは、クライアントが中間者攻撃を受けないようにするためのメカニズムを提供していませんでした。DNSSEC は、DNS を使用してドメイン名を解決する際に認証および整合性チェックの欠如に対処するために導入されました。DNSSEC は、機密性の問題には対処しません。

DNSSEC 情報の公開には、DNS リソースレコードのデジタル署名や、DNS リゾルバーが信頼の階層チェーンを構築できるようにするなどの方法で公開鍵を配布することが含まれます。すべての DNS リソースレコードのデジタル署名が生成され、デジタル署名リソースレコード(RRSIG)としてゾーンに追加されます。ゾーンの公開鍵は、DNSKEY リソースレコードとして追加されます。階層的な連鎖を構築するために、DNSKEY のハッシュをDS(Delegation of Signing) リソースレコードとして親ゾーンで公開します。消極的事実の証明を容易にするために、NextSECure (NSEC) および NSEC3 リソースレコードが使用されます。DNSSEC 署名付きゾーンでは、各 リソースレコードセット (RRset) には対応する RRSIG リソースレコードがあります。子ゾーンへの委任に使用されるレコード (NS レコードおよび glue レコード) は署名されないことに注意してください。これらのレコードは子ゾーンに表示され、そこに署名されています。

DNSSEC 情報の処理は、root ゾーン公開鍵が設定されたリゾルバーによって実行されます。この鍵を使用して、リゾルバーは root ゾーンで使用される署名を検証できます。たとえば、ルートゾーンは .com の DS レコードに署名しています。ルートゾーンは、.com ネームサーバーの NS レコードおよび glue レコードも提供します。リゾルバーはこの委譲に従い、これらの委譲されたネームサーバーを使用して .com の DNSKEY レコードをクエリーします。取得した DNSKEY レコードのハッシュは、root ゾーンの DS レコードと一致する必要があります。その場合、リゾルバーは .com の取得した DNSKEY を信頼します。 .com ゾーンでは、RRSIG レコードは .com DNSKEY によって作成されます。このプロセスは、redhat.com など、.com 内の委譲についても同様に繰り返されます。この方法を使用すると、検証用 DNS リゾルバーは、通常の操作中に世界中から多くの DNSKEY を収集する間、1 つのルートキーでのみ設定する必要があります。暗号チェックに失敗した場合、リゾルバーはアプリケーションに SERVFAIL を返します。

DNSSEC は、DNSSEC をサポートしていないアプリケーションからは完全に見えないように設計されています。DNSSEC 非対応のアプリケーションが DNSSEC 対応リゾルバーにクエリーした場合、RRSIG などのこれらの新しいリソースレコードタイプがなくても応答を受け取ります。ただし、DNSSEC 対応のリゾルバーは引き続きすべての暗号化チェックを実行し、悪意のある DNS 応答を検出すると、アプリケーションに引き続き SERVFAIL エラーを返します。DNSSEC は、DNS サーバー（権威および再帰的）間のデータの整合性を保護します。これは、アプリケーションとリゾルバー間のセキュリティーを提供しません。したがって、アプリケーションにリゾルバーへの安全なトランスポートを提供することが重要です。これを実現する最も簡単な方法は、DNSSEC 対応のリゾルバーを localhost で実行し、/etc/resolv.conf で 127.0.0.1 を使用することです。または、リモート DNS サーバーへの VPN 接続を使用することもできます。

ホットスポットの問題について

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

DNSSEC 対応の再帰的リゾルバーの選択

DNSSEC 対応の再帰リゾルバーをデプロイするには、BIND または unbound のいずれかを使用できます。いずれもデフォルトで DNSSEC を有効にし、DNSSEC root キーで設定されています。サーバーで DNSSEC を有効にするには、どちらのサーバーも機能しますが、ノートブックなどのモバイルデバイスでは、ローカルユーザーが動的に DNSSEC オーバーライドを再設定できるため、dnssec-trigger を使用する際にローカルユーザーが Hotspot に必要な DNSSEC オーバーライドを動的に再設定し、Libreswan を使用する場合は VPN 向けにを使用することが推奨されます。unbound デーモンは、サーバーとモバイルデバイスの両方で役立つ etc/unbound/*.d/ ディレクトリーにリストされている DNSSEC 例外のデプロイメントをさらにサポートします。

4.5.3. Dnssec-trigger について

unbound が /etc/resolv.conf にインストールされ、設定されると、アプリケーションからの DNS クエリーはすべて unbound によって処理されます。dnssec-trigger は、トリガーされた場合にのみ unbound リゾルバーを再設定します。これは、ノートパソコンなど、異なる Wi-Fi ネットワークに接続するローミングクライアントマシンに主に適用されます。プロセスは以下のようになります。

NetworkManager は、新しい DNS サーバーが DHCP 経由で取得されたときに dnssec-trigger を「トリガー」します。
dnssec-trigger は、サーバーに対して多くのテストを実行し、DNSSEC を適切にサポートしているかどうかを判断します。
その場合、dnssec-trigger は unbound を再設定し、その DNS サーバーをすべてのクエリーのフォワーダーとして使用します。
テストが失敗した場合、dnssec-trigger は新しい DNS サーバーを無視し、いくつかの利用可能なフォールバック方法を試します。
無制限のポート 53 (UDP および TCP)が使用可能であると判断した場合、フォワーダーを使用せずに完全な再帰 DNS サーバーになるように unbound に指示します。
これが不可能な場合（たとえば、ポート 53 がネットワークの DNS サーバー自体に到達する場合を除きすべてについてファイアウォールによってブロックされている場合）は、DNS を使用してポート 80 に到達するか、または TLS でポート 443 にカプセル化された DNS を使用しようとします。ポート 80 および 443 で DNS を実行しているサーバーは、/etc/dnssec-trigger/dnssec-trigger.conf で設定できます。コメントアウトされた例は、デフォルトの設定ファイルで利用できるはずです。
これらのフォールバック方法も失敗すると、dnssec-trigger は、DNSSEC を完全にバイパスする安全でない方法で動作するか、新しい DNS クエリーを試行しないが、キャッシュ内にすでに存在するすべてのものに応答する「cache only」モードで実行することを提案します。

Wi-Fi ホットスポットは、インターネットへのアクセスを許可する前に、ユーザーをサインオンページにリダイレクトすることが多くなっています。上記のプロービングシーケンス中にリダイレクトが検出された場合、インターネットにアクセスするためにログインが必要かどうかを尋ねるプロンプトがユーザーに表示されます。dnssec-trigger デーモンは、10 秒ごとに DNSSEC リゾルバーのプローブを続行します。dnssec-trigger グラフィカルユーティリティーの使用方法は、「Dnssec-trigger の使用」を参照してください。

4.5.4. VPN が提供されるドメインサーバーおよびネームサーバー

VPN 接続のタイプによっては、VPN トンネル設定の一環として、ドメインとそのドメインに使用するネームサーバーのリストを伝達できます。Red Hat Enterprise Linux では、これは NetworkManager でサポートされています。つまり、unbound なdnssec-trigger と NetworkManager の組み合わせは、VPN ソフトウェアが提供するドメインおよびネームサーバーを適切にサポートできます。VPN トンネルが起動すると、受信したドメイン名のすべてのエントリーに対してローカルの unbound キャッシュがフラッシュされるため、ドメイン名内の名前に対するクエリーは VPN を使用して到達した内部ネームサーバーから新たにフェッチされます。VPN トンネルが終了すると、バインド されていないキャッシュが再度フラッシュされ、ドメインに対するクエリーが以前に取得したプライベート IP アドレスではなくパブリック IP アドレスを返すようにします。「接続が提供されるドメインの DNSSEC 検証の設定」を参照してください。

4.5.5. 推奨される命名プラクティス

Red Hat は、static および transient の両方の 名前が host.example.com などの DNS 内のマシンに使用される完全修飾ドメイン 名(FQDN)と一致することを推奨します。

Internet Corporation for Assigned Names and Numbers (ICANN)は、以前に登録解除されたトップレベルドメイン( .yourcompanyなど)をパブリックレジスターに追加することがあります。このため、Red Hat では、プライベートネットワーク上であっても委任されていないドメイン名を使用しないことを強く推奨しています。その結果、ネットワークリソースは利用できなくなります。また、委任されていないドメイン名を使うと、DNSSEC の実装および維持がより困難になります。これは、ドメイン名の競合が DNSSEC 検証の有効化に手動の設定ペナルティーを必要とするためです。この問題の詳細は、ドメイン名の衝突に関する ICANN のよくある質問を参照してください。

4.5.6. トラストアンカーについて

階層暗号化システムでは、トラストアンカーは信頼できると想定される、信頼できるエンティティーです。たとえば、X.509 アーキテクチャーでは、ルート証明書がトラストチェーンの元となるトラストアンカーとなっています。トラストアンカーは、パスの検証ができるように、事前に信頼できる団体が所有しておく必要があります。

DNSSEC のコンテキストでは、トラストアンカーは、その名前に関連付けられた DNS 名と公開鍵（または公開鍵のハッシュ）で設定されます。これは、base 64 でエンコードされたキーとして表されます。DNS レコードの検証および認証に使用できる公開鍵を含む情報を交換する手段である点で、証明書と似ています。RFC 4033 は、トラストアンカーを設定された DNSKEY RR または DNSKEY RR の DS RR ハッシュと定義しています。検証用セキュリティー対応リゾルバーは、この公開鍵またはハッシュを、署名された DNS 応答への認証チェーンを構築するための開始点として使用します。一般に、検証用リゾルバーは、DNS プロトコルの外部にある安全な手段または信頼できる手段を介してトラストアンカーの初期値を取得する必要があります。トラストアンカーの存在はまた、リゾルバーがトラストアンカーが指すゾーンが署名されていることを想定すべきことを意味します。

4.5.7. DNSSEC のインストール

4.5.7.1. unbound のインストール

マシン上でローカルに DNSSEC を使用して DNS を検証するには、DNS リゾルバーを unbound （または bind ）にインストールする必要があります。モバイルデバイスに dnssec-trigger をインストールするだけで済みます。サーバーの場合は、サーバーが置かれている場所(LAN またはインターネット)によってはローカルドメインの転送設定が必要になる場合がありますが、unbound で十分です。dnssec-trigger は現在、グローバルパブリック DNS ゾーンでのみ役立ちます。NetworkManager、dhclient、VPN アプリケーションは、多くの場合、ドメインリスト（およびネームサーバーリスト）を自動的に収集できますが、dnssec-trigger や unbound は収集できません。

unbound をインストールするには、root ユーザーとして次のコマンドを入力します。

~]# yum install unbound

4.5.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

systemctl status コマンドは、バインド されていないサービスが実行されていない場合に、unbound を Active: inactive (dead) として報告します。

4.5.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 署名としてマークされません。

NetworkManager と一部の VPN ソフトウェアは、設定を動的に変更することがあります。これらのコンフィギュレーションディレクトリーには、コメントアウトされたサンプルエントリーが含まれています。詳細は、unbound.conf (5) の man ページを参照してください。

4.5.7.4. Dnssec-trigger のインストール

dnssec-trigger アプリケーションはデーモン dnssec-triggerd として実行されます。dnssec-trigger をインストールするには、root ユーザーとして次のコマンドを入力します。

~]# yum install dnssec-trigger

4.5.7.5. dnssec-trigger デーモンが動作しているかどうかの確認

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

dnssec-triggerd デーモンが実行していない場合は、systemctl status コマンドは dnssec-triggerd を Active: inactive (dead) として報告します。現行セッションで起動するには、root ユーザーとして次のコマンドを入力します。

~]# systemctl start dnssec-triggerd

systemctl enable コマンドを実行して、システムが起動するたびに dnssec-triggerd が起動するようにします。

~]# systemctl enable dnssec-triggerd

4.5.8. Dnssec-trigger の使用

dnssec-trigger アプリケーションには、DNSSEC プローブ結果を表示し、DNSSEC プローブ要求をオンデマンドで実行するための GNOME パネルユーティリティーがあります。ユーティリティーを起動するには、Super キーを押してアクティビティーの概要に入り、DNSSEC と 入力 して Enter を押します。画面下のメッセージトレイに、船の錨に似たアイコンが追加されます。画面の右下にある青い丸い通知アイコンを押して表示します。錨アイコンを右クリックすると、ポップアップメニューが表示されます。

通常の操作では、unbound はローカルでネームサーバーとして使用され、resolv.conf は 127.0.0.1 を指します。Hotspot Sign-On パネルで OK をクリックすると、これが変更されます。DNS サーバーは NetworkManager からクエリーされ、resolv.conf に配置されます。これで、Hotspot のサインオンページで認証ができるようになりました。アンカーアイコンには、DNS クエリーが安全ではないことを警告するために、大きな赤い感嘆符が表示されます。認証されると、dnssec-trigger は自動的にこれを検出し、セキュアモードに戻す必要がありますが、場合によってはユーザーではなく、ユーザーは Reprobe を選択して手動でこれを行う必要があります。

dnssec-trigger は通常、ユーザーの対話を必要としません。一度起動するとバックグラウンドで動作し、問題が発生した場合は、ポップアップのテキストボックスでユーザーに通知します。また、resolv.conf ファイルへの変更について unbound に通知します。

4.5.9. DNSSEC における dig の使用

DNSSEC が機能しているかどうかを確認するために、さまざまなコマンドラインツールを使用することができます。最適なツールは、bind-utils パッケージの dig コマンドです。ldns パッケージからの drill と unbound パッケージの unbound-host に役立つその他のツール。古い DNS ユーティリティー nslookup および host は廃止されているため、使用しないでください。

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 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 レコードに加えて、DNSSEC 署名、および署名の開始時刻と有効期限を含む RRSIG レコードが返されます。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
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 1010
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;badsign-a.test.dnssec-tools.org. IN	A

;; Query time: 1284 msec
;; 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
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26065
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;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=

;; Query time: 1 msec
;; 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.dnssec-tools.org の人々がこの RRSIG 署名を故意に理解不能にしており、この出力を手動で確認しても検出することはできません。このエラーは systemctl status unbound の出力に表示され、unbound デーモンはこれらのエラーを以下のように syslog に記録します。

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)
whitehouse.gov mail is handled by 110 mail5.eop.gov. (secure)
whitehouse.gov mail is handled by 105 mail4.eop.gov. (secure)
whitehouse.gov mail is handled by 110 mail6.eop.gov. (secure)
whitehouse.gov mail is handled by 105 mail2.eop.gov. (secure)
whitehouse.gov mail is handled by 105 mail3.eop.gov. (secure)

4.5.10. Dnssec-trigger の Hotspot 検出インフラストラクチャーのセットアップ

ネットワークに接続すると、dnssec-trigger は Hotspot を検出しようとします。Hotspot は通常、ユーザーがネットワークリソースを使用する前に、Web ページとのユーザーインタラクションを強制するデバイスです。検出は、既知のコンテンツを含む特定の固定 Web ページのダウンロードを試みることによって行われます。Hotspot がある場合、受信したコンテンツは想定どおりではありません。

dnssec-trigger が Hotspot を検出するために使用できる既知のコンテンツを含む固定 Web ページを設定するには、次の手順に従います。

インターネット上で公開されているマシンに Web サーバーをセットアップします。Red Hat Enterprise Linux 7 システム管理者ガイドの Web Servers の章を参照してください。
サーバーを実行したら、既知のコンテンツを含む static ページを公開します。ページは有効な HTML ページである必要はありません。たとえば、文字列 OK のみを含む hotspot.txt という名前のプレーンテキストファイルを使用できます。サーバーが example.com にあり、Web サーバーの document_root/static/ サブディレクトリーに hotspot.txt ファイルをパブリッシュした場合、静的 Web ページのアドレスは example.com/static/hotspot.txt になります。Red Hat Enterprise Linux 7 システム管理者のガイドの Web サーバーの章の DocumentRoot ディレクティブを参照してください。
/etc/dnssec-trigger/dnssec-trigger.conf ファイルに以下の行を追加します。
```
url: "http://example.com/static/hotspot.txt OK"
```
このコマンドは、HTTP （ポート 80）を使用してプローブされる URL を追加します。最初の部分は、解決される URL とダウンロードされるページです。コマンドの 2 番目の部分は、ダウンロードされた Web ページが含むと予想されるテキスト文字列です。

設定オプションの詳細は、man ページの dnssec-trigger.conf (8)を参照してください。

4.5.11. 接続が提供されるドメインの DNSSEC 検証の設定

デフォルトでは、適切なネームサーバーを持つ正引きゾーンは、NetworkManager を介した Wi-Fi 接続を除き、すべての接続で dnssec-trigger によって unbound に自動的に追加されます。デフォルトでは、unbound に追加されたすべての転送ゾーンは DNSSEC 検証済みです。

転送ゾーンの検証に関するデフォルトの動作は、デフォルトではすべての転送ゾーンが DNSSEC で 検証されない ように、変更することができます。これを行うには、dnssec-trigger 設定ファイル /etc/dnssec.conf の validate_connection_provided_zones 変数を変更します。root ユーザーとして、以下のように行を開いて編集します：

validate_connection_provided_zones=no

この変更は、既存の正引きゾーンではなく、将来の正引きゾーンに対してのみ行われます。したがって、現在提供されているドメインの DNSSEC を無効にする場合は、再接続する必要があります。

4.5.11.1. Wi-Fi 提供ドメインの DNSSEC 検証の設定

Wi-Fi 提供ゾーンの転送ゾーンの追加を有効にすることができます。これを行うには、dnssec-trigger 設定ファイル /etc/dnssec.conf の add_wifi_provided_zones 変数を変更します。root ユーザーとして、以下のように行を開いて編集します：

add_wifi_provided_zones=yes

この変更は、既存の正引きゾーンではなく、将来の正引きゾーンに対してのみ行われます。したがって、現在の Wi-Fi 提供ドメインで DNSSEC を有効にする場合は、Wi-Fi 接続を再接続 (再起動) する必要があります。

警告

Wi-Fi 提供ドメインを転送ゾーンとして unbound に追加をオンにすると、以下のようなセキュリティー上の影響が生じる可能性があります。

Wi-Fi アクセスポイントは、権限を持たない DHCP を介してドメインを意図的に提供し、すべての DNS クエリーを DNS サーバーにルーティングできます。
正引きゾーンの DNSSEC 検証がオフになっている場合、Wi-Fi が提供する DNS サーバーは、知らなくても提供されたドメインからドメイン名の IP アドレスをスプーフィングできます。

4.5.12. 関連情報

DNSSEC の詳細については、以下を参照してください。

4.5.12.1. インストールされているドキュメント

dnssec-trigger (8) man ページ - dnssec-triggerd、dnssec-trigger-control、dnssec-trigger-panel のコマンドオプションを説明しています。
dnssec-trigger.conf (8) man ページ - dnssec-triggerd の設定オプションを説明しています。
unbound (8) man ページ： unbound のコマンドオプションを説明しています。これは、DNS 検証リゾルバーです。
unbound.conf (5) man ページ - unbound の設定方法に関する情報が含まれています。
resolv.conf (5) man ページ - リゾルバールーチンが読み込む情報が含まれています。

4.5.12.2. オンラインドキュメント

http://tools.ietf.org/html/rfc4033: RFC 4033 DNS Security Introduction and Requirements.
http://www.dnssec.net/: DNSSEC に関する多くのリソースへのリンクがある Web サイト。
http://www.dnssec-deployment.org/: 米国国土安全保障省が後援する DNSSEC デプロイメントイニシアチブには、多くの DNSSEC 情報が含まれており、DNSSEC のデプロイメントに関する問題を議論するためのメーリングリストもあります。
http://www.internetsociety.org/deploy360/dnssec/community/: DNSSEC のデプロイメントを刺激し、調整するための Internet Society の「Deploy 360」イニシアチブは、世界中のコミュニティーと DNSSEC 活動を見つけるための優れたリソースです。
http://www.unbound.net/: 本書には、バインドされていない DNS サービスに関する一般的な情報が記載されています。
http://www.nlnetlabs.nl/projects/dnssec-trigger/: 本書には、dnssec-trigger に関する一般的な情報が記載されています。

4.6. Libreswan を使った仮想プライベートネットワーク (VPN) の保護

Red Hat Enterprise Linux 7 では、Libreswan アプリケーションでサポートされている IPsec プロトコルを使用して、仮想プライベートネットワーク (VPN)を設定できます。Libreswan は、Openswan アプリケーションの継続であり、Openswan ドキュメントの多くの例は Libreswan と相互に置き換え可能です。NetworkManager IPsec プラグインは、NetworkManager-libreswan と呼ばれます。GNOME Shell をお使いの方は、NetworkManager-libreswan を依存関係に持つ NetworkManager-libreswan-gnome パッケージをインストールする必要があります。NetworkManager-libreswan-gnome パッケージは、オプションチャネルからのみ利用可能であることに注意してください。Enabling Supplementary and Optional Repositoriesを参照してください。

VPN の IPsec プロトコル自体は、Internet Key Exchange (IKE)プロトコルを使用して設定されます。IPsec と IKE は同義語です。IPsec VPN は、IKE VPN、IKEv2 VPN、XAUTH VPN、Cisco VPN、または IKE/IPsec VPN とも呼ばれます。Level 2 Tunneling Protocol (L2TP)も使用する IPsec VPN のバリアントは、通常 L2TP/IPsec VPN と呼ばれます。これには、Optional チャンネル xl2tpd アプリケーションが必要です。

Libreswan は、Red Hat Enterprise Linux 7 で利用可能なオープンソースのユーザー空間の IKE 実装です。IKE バージョン 1 および 2 は、ユーザーレベルのデーモンとして実装されます。IKE プロトコル自体も暗号化されています。IPsec プロトコルは Linux カーネルで実装され、Libreswan は、VPN トンネル設定を追加および削除するようにカーネルを設定します。

IKE プロトコルは UDP ポート 500 および 4500 を使用します。IPsec プロトコルは、プロトコル番号 50 を持つ Encapsulated Security Payload (ESP)とプロトコル番号 51 の Authenticated Header (AH)の 2 つの異なるプロトコルで設定されます。AH プロトコルの使用は推奨されません。AH のユーザーは、null 暗号化で ESP に移行することが推奨されます。

IPsec プロトコルには、Tunnel Mode （デフォルト）と Transport Mode の 2 つの異なる操作モードがあります。IKE を使用せずに IPsec を使用してカーネルを設定できます。これは手動キー設定 と呼ば れます。ip xfrm コマンドを使用して手動キーを設定することは可能ですが、セキュリティー上の理由から、これは強く推奨されません。Libreswan は、netlink を使用して Linux カーネルとインターフェイスします。Linux カーネルでパケットの暗号化と復号が行われます。

Libreswan は、NSS( Network Security Services )暗号化ライブラリーを使用します。libreswan および NSS はともに、連邦情報処理標準 (FIPS) の公開文書 140-2 での使用が認定されています。

重要

Libreswan および Linux カーネルが実装する IKE/IPsec VPN は、Red Hat Enterprise Linux 7 での使用が推奨される唯一の VPN 技術です。その他の VPN 技術は、そのリスクを理解せずに使用しないでください。

4.6.1. Libreswan のインストール

Libreswan をインストールするには、root で以下のコマンドを入力します。

~]# yum install libreswan

Libreswan がインストールされていることを確認するには、次のコマンドを実行します。

~]$ yum info libreswan

Libreswan を新規インストールしたら、インストールプロセスの一部として NSS データベースを初期化する必要があります。新しいデータベースを開始する前に、次のように古いデータベースを削除します。

~]# systemctl stop ipsec
~]# rm /etc/ipsec.d/*db

次に、新しい NSS データベースを初期化するには、root で以下のコマンドを入力します。

~]# ipsec initnss
Initializing NSS database

FIPS モードで運用する場合のみ、NSS データベースをパスワードで保護する必要があります。FIPS モード用にデータベースを初期化する場合は、前のコマンドの代わりに以下を使用します。

~]# certutil -N -d sql:/etc/ipsec.d
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:

Libreswan が提供する ipsec デーモンを起動するには、root で以下のコマンドを実行します。

~]# systemctl start ipsec

デーモンが実行中であることを確認するには、次のようにします。

~]$ systemctl status ipsec
* ipsec.service - Internet Key Exchange (IKE) Protocol Daemon for IPsec
   Loaded: loaded (/usr/lib/systemd/system/ipsec.service; disabled; vendor preset: disabled)
   Active: active (running) since Sun 2018-03-18 18:44:43 EDT; 3s ago
     Docs: man:ipsec(8)
           man:pluto(8)
           man:ipsec.conf(5)
  Process: 20358 ExecStopPost=/usr/sbin/ipsec --stopnflog (code=exited, status=0/SUCCESS)
  Process: 20355 ExecStopPost=/sbin/ip xfrm state flush (code=exited, status=0/SUCCESS)
  Process: 20352 ExecStopPost=/sbin/ip xfrm policy flush (code=exited, status=0/SUCCESS)
  Process: 20347 ExecStop=/usr/libexec/ipsec/whack --shutdown (code=exited, status=0/SUCCESS)
  Process: 20634 ExecStartPre=/usr/sbin/ipsec --checknflog (code=exited, status=0/SUCCESS)
  Process: 20631 ExecStartPre=/usr/sbin/ipsec --checknss (code=exited, status=0/SUCCESS)
  Process: 20369 ExecStartPre=/usr/libexec/ipsec/_stackmanager start (code=exited, status=0/SUCCESS)
  Process: 20366 ExecStartPre=/usr/libexec/ipsec/addconn --config /etc/ipsec.conf --checkconfig (code=exited, status=0/SUCCESS)
 Main PID: 20646 (pluto)
   Status: "Startup completed."
   CGroup: /system.slice/ipsec.service
           └─20646 /usr/libexec/ipsec/pluto --leak-detective --config /etc/ipsec.conf --nofork

システムの起動時に Libreswan が起動するようにするには、root で以下のコマンドを実行します。

~]# systemctl enable ipsec

中間およびホストベースのファイアウォールを設定して、ipsec サービスを許可します。ファイアウォールと特定のサービスの通過許可についての詳細は、5章ファイアウォールの使用 を参照してください。Libreswan では、ファイアウォールで以下のパケットを許可する必要があります。

Internet Key Exchange (IKE)プロトコルの UDP ポート 500 および 4500
Encapsulated Security Payload (ESP) IPsec パケットのプロトコル 50
Authenticated Header (AH) IPsec パケットのプロトコル 51 （一般的ではありません）

Libreswan を使用して IPsec VPN を設定する 3 つの例を示します。最初の例は、2 つのホストを接続し、安全に通信するためのものです。2 つ目の例では、2 つのサイトを接続して 1 つのネットワークを形成します。3 番目の例は、このコンテキストでは ロードウォリアー と呼ばれるリモートユーザーをサポートすることです。

4.6.2. Libreswan を使用した VPN 設定の作成

IKE/IPsec はピアツーピアプロトコルであるため、Libreswan は「送信『元』および宛先」または「サーバー」および「クライアント」という用語を使用しません。終了点 (ホスト) を参照する場合は、代わりに「左」と「右」という用語を使用します。これにより、ほとんどの場合、両方のエンドポイントで同じ設定を使用できますが、多くの管理者は、常にローカルホストに「左」を、リモートホストに「右」を使用することを選択します。

エンドポイントの認証には、一般的に 4 つの方法があります。

Pre-Shared Keys (PSK) は、最も簡単な認証メソッドです。PSK はランダムな文字で設定されており、長さが 20 文字以上になります。FIPS モードでは、PSK が、使用する整合性アルゴリズムにより、最低強度の要件を満たす必要があります。PSK の値は 64 文字以上にすることが推奨されます。
Raw RSA 鍵は、静的なホスト間またはサブネット間の IPsec 設定で一般的に使用されます。ホストは、相互の公開 RSA 鍵を使用して手動で設定します。この方法は、数十以上のホストがすべて互いに IPsec トンネルを設定する必要がある場合、適切にスケーリングされません。
X.509 証明書は、共通の IPsec ゲートウェイに接続する必要があるホストが多数ある大規模なデプロイメントで一般的に使用されます。中央の 認証局 (CA) は、ホストまたはユーザーの RSA 証明書の署名に使用されます。この中央 CA は、個別のホストまたはユーザーの取り消しを含む、信頼のリレーを行います。
NULL 認証は、認証なしでメッシュの暗号化を取得するために使用されます。これは、パッシブ攻撃は防ぎますが、アクティブ攻撃は防ぎません。ただし、IKEv2 は非対称認証メソッドを許可するため、NULL 認証は、インターネットスケール Opportunistic IPsec にも使用できます。この場合、クライアントはサーバーを認証しますが、サーバーはクライアントを認証しません。このモデルは、TLS (https:// websites としても知られている)を使用してセキュアな Web サイトと似ています。

これらの認証方法に加えて、量子コンピューターからの考えられる攻撃から保護するために、認証を追加することができます。この追加認証方式は、Postquantum Preshared Keys (PPK と呼ばれます。個々のクライアントまたはクライアントグループは、帯域幅を設定した事前共有鍵に対応する (PPKID) を指定して、独自の PPK を使用できます。「量子コンピューターに対する保護の使用」を参照してください。

4.6.3. Libreswan を使用したホスト間 VPN の作成

Libreswan が、左と右と呼ばれる 2 つのホスト間に、ホスト間の IPsec VPN を作成するように設定するには、両ホスト(「『左』」および「『右』」の)で以下のコマンドを root として入力し、新しい生の RSA 鍵ペアを作成します。

~]# ipsec newhostkey --output /etc/ipsec.d/hostkey.secrets
Generated RSA key pair with CKAID 14936e48e756eb107fa1438e25a345b46d80433f was stored in the NSS database

これでホストの RSA 鍵のペアが生成されます。RSA キーを生成するプロセスは、特にエントロピーの低い仮想マシンでは、数分かかる場合があります。

ホストの公開鍵を表示して、「左側」の設定で指定できるようにするには、「newhostkey」コマンドで返された CKAID を使用して、新しいホストキーが追加されたホストで以下のコマンドを root として発行します。

~]# ipsec showhostkey --left --ckaid 14936e48e756eb107fa1438e25a345b46d80433f
	# rsakey AQPFKElpV
	leftrsasigkey=0sAQPFKElpV2GdCF0Ux9Kqhcap53Kaa+uCgduoT2I3x6LkRK8N+GiVGkRH4Xg+WMrzRb94kDDD8m/BO/Md+A30u0NjDk724jWuUU215rnpwvbdAob8pxYc4ReSgjQ/DkqQvsemoeF4kimMU1OBPNU7lBw4hTBFzu+iVUYMELwQSXpremLXHBNIamUbe5R1+ibgxO19l/PAbZwxyGX/ueBMBvSQ+H0UqdGKbq7UgSEQTFa4/gqdYZDDzx55tpZk2Z3es+EWdURwJOgGiiiIFuBagasHFpeu9Teb1VzRyytnyNiJCBVhWVqsB4h6eaQ9RpAMmqBdBeNHfXwb6/hg+JIKJgjidXvGtgWBYNDpG40fEFh9USaFlSdiHO+dmGyZQ74Rg9sWLtiVdlH1YEBUtQb8f8FVry9wSn6AZqPlpGgUdtkTYUCaaifsYH4hoIA0nku4Fy/Ugej89ZdrSN7Lt+igns4FysMmBOl9Wi9+LWnfl+dm4Nc6UNgLE8kZc+8vMJGkLi4SYjk2/MFYgqGX/COxSCPBFUZFiNK7Wda0kWea/FqE1heem7rvKAPIiqMymjSmytZI9hhkCD16pCdgrO3fJXsfAUChYYSPyPQClkavvBL/wNK9zlaOwssTaKTj4Xn90SrZaxTEjpqUeQ==

このキーは、以下に説明するように、両方のホストの設定ファイルに追加するために必要です。CKAID を忘れてしまった場合は、以下を使用してマシン上のすべてのホスト鍵のリストを取得することができます。

~]# ipsec showhostkey --list
< 1 >  RSA keyid: AQPFKElpV ckaid: 14936e48e756eb107fa1438e25a345b46d80433f

キーペアのシークレット部分は、/etc/ipsec.d/*.db にある「NSS データベース」内に保存されます。

このホスト間トンネルの設定ファイルを作成するには、上記の leftrsasigkey= と rightrsasigkey= の行を /etc/ipsec.d/ ディレクトリーにあるカスタム設定ファイルに追加します。

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
    rightrsasigkey=0sAQO3fwC6nSSGgt64DWiYZzuHbc4 [...] D/v8t5YTQ==
    authby=rsasig
    # load and initiate automatically
    auto=start

また、公開鍵は RSAID ではなく、CKAID で設定することも可能です。この場合、「leftrsasigkey=」の代わりに「leftckaid=」を使用します。

左のホストと右のホストの両方で、同一の設定ファイルを使用することができます。Libreswan は、指定された IP アドレスやホストネームをもとに、自動的に「左」か「右」かを検出します。ホストの 1 つがモバイルホストであり、その IP アドレスが事前に認識されていないことを意味する場合には、モバイルクライアントでは %defaultroute を IP アドレスとして使用します。これにより、動的 IP アドレスが自動的に選択されます。受信モバイルホストからの接続を受け入れる静的サーバーホストで、IP アドレスに %any を使用してモバイルホストを指定します。

leftrsasigkey 値が「左」のホストから取得され、rightrsasigkey 値が「右」のホストから取得されていることを確認します。leftckaid と rightckaid を使用する場合も同じことが当てはまります。

ipsec を再起動して、新しい設定を読み取り、システムの起動時に開始するように設定されている場合には、トンネルが確立されていることを確認します。

~]# systemctl restart ipsec

auto=start オプションを使用する場合は、IPsec トンネルを数秒以内に確立する必要があります。root で以下のコマンドを入力して、トンネルを手動でロードおよび起動できます。

~]# ipsec auto --add mytunnel
~]# ipsec auto --up mytunnel

4.6.3.1. Libreswan を使用したホスト間 VPN の検証

IKE ネゴシエーションは UDP ポート 500 および 4500 で行われます。IPsec パケットは、Encapsulated Security Payload (ESP)パケットとして表示されます。ESP プロトコルにはポートがありません。VPN 接続が NAT ルーターを通過する必要がある場合、ESP パケットはポート 4500 の UDP パケットにカプセル化されます。

パケットが VPN トンネルを介して送信されていることを確認するには、root で以下の形式のコマンドを実行します。

~]# tcpdump -n -i interface esp or udp port 500 or 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
00:32:33.632731 IP 192.0.2.254 > 192.0.1.254: ICMP echo reply, id 2489, 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
00:32:34.632607 IP 192.0.2.254 > 192.0.1.254: ICMP echo reply, id 2489, 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
00:32:35.632685 IP 192.0.2.254 > 192.0.1.254: ICMP echo reply, id 2489, seq 10, length 64

ここで、interface は、トラフィックを伝送することがわかっているインターフェイスです。tcpdump でキャプチャーを終了するには、Ctrl+C を押します。

注記

tcpdump コマンドは、IPsec と予期せず対話します。送信される暗号化されたパケットのみが表示され、送信されるプレーンテキストパケットは表示されません。暗号化された着信パケットと、復号化された着信パケットは表示されます。可能な場合は、エンドポイント自体ではなく、2 つのマシン間のルーターで tcpdump を実行します。Virtual Tunnel Interface (VTI)を使用する場合、物理インターフェイスの tcpdump は ESP パケットを表示し、VTI インターフェイスの tcpdump にはクリアテキストトラフィックが表示されます。

トンネルが正常に確立されたことを確認し、さらにトンネルを通過したトラフィックの量を確認するには、root で以下のコマンドを入力します。

~]# ipsec whack --trafficstatus
006 #2: "mytunnel", type=ESP, add_time=1234567890, inBytes=336, outBytes=336, id='@east'

4.6.4. Libreswan を使用したサイト間の VPN の設定

Libreswan がサイト間 IPsec VPN を作成し、2 つのネットワークを結合するために、1 つ以上のサブネットからのトラフィックが通過できるように設定された 2 つのホスト、エンドポイントの間に IPsec トンネルが作成されます。したがって、これらはネットワークのリモート部分へのゲートウェイと見なすことができます。サイト間の VPN の設定は、設定ファイル内で複数のネットワークまたはサブネットを指定する必要がある点のみが、ホスト間の VPN とは異なります。

サイト間 IPsec VPN を作成するように Libreswan を設定するには、最初に「Libreswan を使用したホスト間 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
    auto=start

conn mysubnet6
    also=mytunnel
    connaddrfamily=ipv6
    leftsubnet=2001:db8:0:1::/64
    rightsubnet=2001:db8:0:2::/64
    auto=start

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
    rightrsasigkey=0sAQO3fwC6nSSGgt64DWiYZzuHbc4 [...] D/v8t5YTQ==
    authby=rsasig

トンネルを起動するには、Libreswan を再起動するか、root で以下のコマンドを使用して、すべての接続を手動でロードして開始します。

~]# ipsec auto --add mysubnet

~]# ipsec auto --add mysubnet6

~]# 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
003 "mytunnel" #1: received Vendor ID payload [FRAGMENTATION]
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}

4.6.4.1. Libreswan を使用したサイト間 VPN の検証

VPN トンネルを通してパケットが送信されていることを確認する方法は、「Libreswan を使用したホスト間 VPN の検証」で説明した手順と同じです。

4.6.5. Libreswan を使ったサイト間シングルトンネル VPN の設定

多くの場合、サイト間トンネルが構築されると、ゲートウェイはパブリック IP アドレスではなく内部 IP アドレスを使用して相互に通信する必要があります。これは、単一のトンネルを使用して実現することができます。ホスト名 west の左側のホストに、内部 IP アドレスが 192.0.1.254 で、ホスト名が east の正しいホストの内部 IP アドレスが 192.0. 2.254 の場合には、単一のトンネルを使用して以下の設定を両方のサーバーの /etc/ipsec.d/myvpn.conf ファイルに保存します。

conn mysubnet
    leftid=@west.example.com
    leftrsasigkey=0sAQOrlo+hOafUZDlCQmXFrje/oZm [...] W2n417C/4urYHQkCvuIQ==
    left=192.1.2.23
    leftsourceip=192.0.1.254
    leftsubnet=192.0.1.0/24
    rightid=@east.example.com
    rightrsasigkey=0sAQO3fwC6nSSGgt64DWiYZzuHbc4 [...] D/v8t5YTQ==
    right=192.1.2.45
    rightsourceip=192.0.2.254
    rightsubnet=192.0.2.0/24
    auto=start
    authby=rsasig

4.6.6. Libreswan を使用したサブネット押し出しの設定

多くの場合、IPsec はハブアンドスポークアーキテクチャーにデプロイされます。各リーフノードには、より大きな範囲の一部である IP 範囲があります。リーフはハブを介して相互に通信します。これは サブネットの押出 と呼ばれます。

例4.2 単純なサブネット押し出しセットアップの設定

以下の例では、10.0.0.0/ 8 と、より小さな /24 サブネットを使用する 2 つのブランチを使用して、ヘッドオフィスを設定します。

本社では以下のようになります。

conn branch1
    left=1.2.3.4
    leftid=@headoffice
    leftsubnet=0.0.0.0/0
    leftrsasigkey=0sA[...]
    #
    right=5.6.7.8
    rightid=@branch1
    rightsubnet=10.0.1.0/24
    rightrsasigkey=0sAXXXX[...]
    #
    auto=start
    authby=rsasig

conn branch2
    left=1.2.3.4
    leftid=@headoffice
    leftsubnet=0.0.0.0/0
    leftrsasigkey=0sA[...]
    #
    right=10.11.12.13
    rightid=@branch2
    rightsubnet=10.0.2.0/24
    rightrsasigkey=0sAYYYY[...]
    #
    auto=start
    authby=rsasig

「branch1」オフィスでは、同一の接続を使用します。さらに、パススルー接続を使用して、ローカル LAN トラフィックがトンネルを介して送信されないようにします。

conn branch1
    left=1.2.3.4
    leftid=@headoffice
    leftsubnet=0.0.0.0/0
    leftrsasigkey=0sA[...]
    #
    right=10.11.12.13
    rightid=@branch2
    rightsubnet=10.0.1.0/24
    rightrsasigkey=0sAYYYY[...]
    #
    auto=start
    authby=rsasig

conn passthrough
    left=1.2.3.4
    right=0.0.0.0
    leftsubnet=10.0.1.0/24
    rightsubnet=10.0.1.0/24
    authby=never
    type=passthrough
    auto=route

4.6.7. IKEv2 リモートアクセス VPN Libreswan の設定

ロードウォーリアーは、ラップトップなどの IP アドレスを動的に割り当てられたモバイルクライアントを持つ移動ユーザーです。これらは証明書を使用して認証されます。古い IKEv1 XAUTH プロトコルを使用する必要がないように、次の例では IKEv2 を使用しています。

サーバーの場合:

conn roadwarriors
    ikev2=insist
    # Support (roaming) MOBIKE clients (RFC 4555)
    mobike=yes
    fragmentation=yes
    left=1.2.3.4
    # if access to the LAN is given, enable this, otherwise use 0.0.0.0/0
    # leftsubnet=10.10.0.0/16
    leftsubnet=0.0.0.0/0
    leftcert=vpn-server.example.com
    leftid=%fromcert
    leftxauthserver=yes
    leftmodecfgserver=yes
    right=%any
    # trust our own Certificate Agency
    rightca=%same
    # pick an IP address pool to assign to remote users
    # 100.64.0.0/16 prevents RFC1918 clashes when remote users are behind NAT
    rightaddresspool=100.64.13.100-100.64.13.254
    # if you want remote clients to use some local DNS zones and servers
    modecfgdns="1.2.3.4, 5.6.7.8"
    modecfgdomains="internal.company.com, corp"
    rightxauthclient=yes
    rightmodecfgclient=yes
    authby=rsasig
    # optionally, run the client X.509 ID through pam to allow/deny client
    # pam-authorize=yes
    # load connection, don't initiate
    auto=add
    # kill vanished roadwarriors
    dpddelay=1m
    dpdtimeout=5m
    dpdaction=%clear

詳細は以下のようになります。

left=1.2.3.4: 1.2.3.4 の値は、サーバーの実際の IP アドレスまたはホスト名を指定します。
leftcert=vpn-server.example.com: このオプションは、証明書をインポートする際に使用されたそのフレンドリーネームまたはニックネームを参照する証明書を指定します。通常、名前は .p12 ファイルの形式で PKCS #12 証明書バンドルの一部として生成されます。詳細は、pkcs12 (1) および pk12util (1) の man ページを参照してください。

ロードウォーリアーのデバイスであるモバイルクライアントでは、上記の設定に多少変更を加えて使用します。

conn to-vpn-server
    ikev2=insist
    # pick up our dynamic IP
    left=%defaultroute
    leftsubnet=0.0.0.0/0
    leftcert=myname.example.com
    leftid=%fromcert
    leftmodecfgclient=yes
    # right can also be a DNS hostname
    right=1.2.3.4
    # if access to the remote LAN is required, enable this, otherwise use 0.0.0.0/0
    # rightsubnet=10.10.0.0/16
    rightsubnet=0.0.0.0/0
    # trust our own Certificate Agency
    rightca=%same
    authby=rsasig
    # allow narrowing to the server’s suggested assigned IP and remote subnet
    narrowing=yes
    # Support (roaming) MOBIKE clients (RFC 4555)
    mobike=yes
    # Initiate connection
    auto=start

詳細は以下のようになります。

auto=start: このオプションを使用すると、ユーザーは ipsec システムサービスが開始されるたびに VPN に接続できるようになります。後で接続を確立する場合は、auto=add に置き換えます。

4.6.8. X.509 を使用した IKEv1 リモートアクセス VPN Libreswan および XAUTH の設定

Libreswan は、XAUTH IPsec 拡張機能を使用して接続を確立する際に、ローミング VPN クライアントに IP アドレスと DNS 情報をネイティブに割り当てる方法を提供します。拡張認証 (XAUTH) は、PSK または X.509 証明書を使用してデプロイすることができます。X.509 を使用したデプロイの方がより安全です。クライアント証明書は、証明書失効リストまたは オンライン証明書ステータスプロトコル (OCSP) により取り消すことができます。X.509 証明書を使用すると、個々のクライアントがサーバーになりすますことはできません。グループパスワードとも呼ばれる PSK を使用すると、これは理論的には可能です。

XAUTH では、VPN クライアントがユーザー名とパスワードで自身を追加で識別する必要があります。Google 認証システムや RSA SecureID トークンなどのワンタイムパスワード (OTP) の場合、ワンタイムトークンがユーザーパスワードに追加されます。

XAUTH には 3 つの可能なバックエンドがあります。

xauthby=pam

これは、/etc/pam.d/pluto の設定を使用してユーザーを認証します。Pluggable Authentication Modules (PAM) は、さまざまなバックエンドを単独で使用するように設定できます。システムアカウントのユーザーパスワードスキーム、LDAP ディレクトリー、RADIUS サーバー、またはカスタムパスワード認証モジュールを使用できます。詳細は、Using Pluggable Authentication Modules (PAM) の章を参照してください。

xauthby=file

これは /etc/ipsec.d/passwd 設定ファイルを使用します( /etc/ipsec.d/nsspassword ファイルと混同しないでください)。このファイルのフォーマットは Apache .htpasswd ファイルと似ており、Apache htpasswd コマンドを使用してこのファイルのエントリーを作成できます。ただし、ユーザー名とパスワードの後に、使用される IPsec 接続の接続名を指定して 3 番目の列が必要になります。たとえば、conn remoteusers を使用してユーザーを削除するために VPN を提供する場合、パスワードファイルのエントリーは以下のようになります。

user1:$apr1$MIwQ3DHb$1I69LzTnZhnCT2DPQmAOK.:remoteusers

注記

htpasswd コマンドを使用する場合、各行の user:password 部分の後に接続名を手動で追加する必要があります。

xauthby=alwaysok

サーバーは常に、XAUTH ユーザーとパスワードの組み合わせが正しいふりをします。クライアントは引き続き、ユーザー名とパスワードを指定しなければなりませんが、サーバーはこれらを無視します。これは、ユーザーがすでに X.509 証明書によって識別されている場合、または XAUTH バックエンドを必要とせずに VPN をテストする場合にのみ使用されるべきものです。

X.509 証明書を使用したサーバーの設定例:

conn xauth-rsa
    ikev2=never
    auto=add
    authby=rsasig
    pfs=no
    rekey=no
    left=ServerIP
    leftcert=vpn.example.com
    #leftid=%fromcert
    leftid=vpn.example.com
    leftsendcert=always
    leftsubnet=0.0.0.0/0
    rightaddresspool=10.234.123.2-10.234.123.254
    right=%any
    rightrsasigkey=%cert
    modecfgdns="1.2.3.4,8.8.8.8"
    modecfgdomains=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 ではなく soft に設定されている場合、認証の失敗は無視され、VPN はユーザーが適切に認証されたかのように設定されます。カスタムアップダウンスクリプトを使用して、環境変数 XAUTH_FAILED をチェックすることができます。このようなユーザーは、たとえば iptables DNAT を使用して、ウォードガーンにリダイレクトできます。ここで、管理者に問い合わせたり、サービスの有料サブスクリプションを更新したりできます。「」

VPN クライアントは、modecfgdomain 値と DNS エントリーを使用して、指定されたドメインのクエリーをこれらの指定されたネームサーバーにリダイレクトします。これにより、ローミングユーザーは内部 DNS 名を使用して内部専用リソースにアクセスすることができます。IKEv2 は modecfgdomains と modecfgdns を使用して、ドメイン名とネームサーバー IP アドレスのコンマ区切りリストをサポートしますが、IKEv1 プロトコルは 1 つのドメイン名のみをサポートし、libreswan は最大 2 つのネームサーバー IP アドレスのみをサポートすることに注意してください。オプションで、バナーテキストを VPN クライアントに送信するには、modecfgbanner オプションを使用します。

leftsubnet が 0.0.0.0/0 ではない場合には、スプリットトンネリング設定要求はクライアントに自動的に送信されます。たとえば、leftsubnet=10.0.0.0/8 を使用する場合、VPN クライアントは VPN 経由で 10.0.0.0/8 のトラフィックのみを送信します。

クライアントでは、ユーザーはユーザーパスワードを入力する必要がありますが、これは使用するバックエンドに依存します。以下に例を示します。

xauthby=file: 管理者がパスワードを生成し、/etc/ipsec.d/passwd ファイルに保存しました。
xauthby=pam: パスワードは、/etc/pam.d/pluto ファイルの PAM 設定で指定された場所で取得されます。
xauthby=alwaysok: パスワードはチェックされず、常に受け入れられます。このオプションは、テスト目的や、xauth のみのクライアントの互換性を確保したい場合に使用します。

4.6.9. 量子コンピューターに対する保護の使用

事前共有鍵が設定されている IKEv1 を使用すると、量子攻撃者に対する保護が可能になります。IKEv2 の再設計は、この保護をネイティブに提供しません。Libreswan は、Postquantum Preshared Keys (PPK)を使用して、量子攻撃に対して IKEv2 接続を保護します。

任意の PPK 対応を有効にする場合は、接続定義に ppk=yes を追加します。PPK が必要な場合は ppk=insist を追加します。次に、各クライアントには、帯域外で通信する (および可能であれば量子攻撃に対して安全な) シークレット値を持つ PPK ID を付与できます。PPK はランダム性において非常に強力で、辞書の単語は使用しません。PPK ID および PPK データ自体は ipsec.secrets に保存されます。以下に例を示します。

@west @east : PPKS "user1" "thestringismeanttobearandomstr"

PPKS オプションは、静的な PPK を参照します。ワンタイムパッドベースのダイナミック PPK を使用する実験的な関数があります。各接続では、ワンタイムパッドの新しい部分が PPK として使用されます。これを使用すると、ファイル内の動的な PPK の部分がゼロで上書きされ、再利用を防ぐことができます。複数のタイムパッドマテリアルが残っていないと、接続は失敗します。詳細は、man ページの ipsec.secrets (5) を参照してください。

警告

動的の PPK の実装はテクノロジープレビューとして提供されており、この機能は注意して使用する必要があります。詳細は、Red Hat Enterprise Linux 7.5 Release Notes 参照してください。

4.6.10. 関連情報

以下の資料は、Libreswan および ipsec デーモンに関するその他のリソースを提供します。

4.6.10.1. インストールされているドキュメント

man ページの ipsec (8) - ipsec のコマンドオプションが説明されています。
man ページの ipsec.conf (5) - ipsec の設定に関する情報が記載されています。
man ページの ipsec.secrets (5) - ipsec.secrets ファイルの形式が説明されています。
man ページの ipsec_auto (8) - 鍵の自動交換を使用して確立された Libreswan IPsec 接続を操作する auto コマンドラインクライアントの使用方法が説明されています。
man ページの ipsec_rsasigkey (8) - RSA 署名鍵の生成に使用されるツールが説明されています。
/usr/share/doc/libreswan-version/

4.6.10.2. オンラインドキュメント

https://libreswan.org: アップストリームプロジェクトの Web サイトです。
https://libreswan.org/wiki: Libreswan プロジェクトの Wiki です。
https://libreswan.org/man/: Libreswan に関する全 man ページ
NIST Special Publication 800-77: Guide to IPsec VPNs: IPsec に基づくセキュリティーサービスの実装に関する組織への実用的なガイダンス。

4.7. OpenSSL の使用

OpenSSL は、アプリケーションに暗号化プロトコルを提供するライブラリーです。openssl コマンドラインユーティリティーは、シェルからの暗号化機能の使用を可能にします。これには、インタラクティブモードが含まれています。

openssl コマンドラインユーティリティーには、システムにインストールされている openssl のバージョンがサポートするコマンドに関する情報を提供する多数の疑似コマンドがあります。疑似コマンド list-standard-commands、list-message-digest-commands、および list-cipher-commands は、現在の openssl ユーティリティーで利用可能なすべての標準コマンド、メッセージダイジェストコマンド、または暗号コマンドの一覧を出力します。

疑似コマンド list-cipher-algorithms および list-message-digest-algorithms は、すべての暗号名とメッセージダイジェスト名を一覧表示します。擬似コマンド list-public-key-algorithms は、サポートされているすべての公開鍵アルゴリズムを一覧表示します。たとえば、サポートされている公開鍵アルゴリズムを一覧表示するには、次のコマンドを発行します。

~]$ openssl list-public-key-algorithms

疑似コマンド no-command-name は、指定された名前の command-name が使用可能かどうかをテストします。シェルスクリプトでの使用を目的としています。詳細は、man openssl(1) を参照してください。

4.7.1. 暗号鍵の作成および管理

OpenSSL では、公開鍵は対応する秘密鍵から派生します。したがって、アルゴリズムを決定した後の最初のステップは、秘密鍵を生成することです。以下の例では、秘密鍵を privkey.pem とします。たとえば、デフォルトのパラメーターを使用して RSA 秘密鍵を作成する場合は、次のコマンドを実行します。

~]$ openssl genpkey -algorithm RSA -out privkey.pem

RSA アルゴリズムは、以下のオプションをサポートしています。

rsa_keygen_bits:numbits — 生成されたキーのビット数。指定されていない場合は、1024 が使用されます。
rsa_keygen_pubexp:value — RSA パブリック指数値。これは、大きな 10 進数値、または 0x で始まる場合は 16 進数の値になります。デフォルト値は 65537 です。

たとえば、公開指数として 3 を使用して 2048 ビットの RSA 秘密鍵を作成するには、以下のコマンドを実行します。

~]$ openssl genpkey -algorithm RSA -out privkey.pem -pkeyopt rsa_keygen_bits:2048 \ -pkeyopt rsa_keygen_pubexp:3

128 ビット AES とパスフレーズ「hello」を使用して、出力される秘密鍵を暗号化するには、次のコマンドを発行します。

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

秘密鍵の生成に関する詳細は、man genpkey(1) を参照してください。

4.7.2. 証明書の生成

OpenSSL を使用して証明書を生成するには、秘密鍵が利用可能である必要があります。以下の例では、秘密鍵を privkey.pem とします。秘密鍵をまだ生成していない場合は、「暗号鍵の作成および管理」を参照してください。

認証局 (CA) に証明書に署名してもらうには、証明書を生成してから CA に送信して署名する必要があります。これは、証明書署名要求と呼ばれます。詳細は、「証明書署名要求の作成」を参照してください。別の方法は、自己署名証明書を作成することです。詳細は、「自己署名証明書の作成」を参照してください。

4.7.2.1. 証明書署名要求の作成

CA に送信するための証明書を作成するには、次の形式でコマンドを発行します。

~]$ openssl req -new -key privkey.pem -out cert.csr

これにより、デフォルトの PEM 形式(PEM)形式でエンコードされた cert.csr という名前の X.509 証明書が作成されます。PEM という名前は、RFC1424 で説明されている「Privacy Enhancement for Internet Electronic Mail」に由来しています。代替 DER 形式で証明書ファイルを生成するには、-outform DER コマンドオプションを使用します。

上記のコマンドを発行すると、証明書の distinguished name (DN) を作成するために、お客様や組織に関する情報を入力する画面が表示されます。以下の情報が必要になります。

2 文字の国コード
州または県の名前
市または自治体
組織の名前
組織内のユニット名
ユーザー名もしくはシステムのホスト名
メールアドレス

req(1) man ページでは、PKCS# 10 証明書要求と生成ユーティリティーについて説明しています。証明書の作成プロセスで使用されるデフォルト設定は、/etc/pki/tls/openssl.cnf ファイルに含まれます。詳細は、openssl.cnf (5) の man ページを参照してください。

4.7.2.2. 自己署名証明書の作成

366 日間有効な自己署名証明書を生成するには、以下の形式でコマンドを発行します。

~]$ openssl req -new -x509 -key privkey.pem -out selfcert.pem -days 366

4.7.2.3. Makefile を使った証明書の作成

/etc/pki/tls/certs/ ディレクトリーには、make コマンドを使用して証明書を作成するのに使用できる Makefile が含まれています。使用説明書を表示するには、次のようにコマンドを発行します。

~]$ make -f /etc/pki/tls/certs/Makefile

または、ディレクトリーに移動し、以下のように make コマンドを実行します。

~]$ cd /etc/pki/tls/certs/
~]$ make

詳細は、make(1) の man ページを参照してください。

4.7.3. 証明書の確認

CA によって署名された証明書は、信頼できる証明書と呼ばれます。したがって、自己署名証明書は信頼できない証明書になります。verify ユーティリティーは、同じ SSL および S/MIME 機能を使用して、通常の操作で OpenSSL が使用する証明書を検証します。エラーが見つかった場合は報告され、他のエラーを報告するためにテストを続行しようとします。

PEM 形式の複数の個別の X.509 証明書を検証するには、次の形式のコマンドを発行します。

~]$ openssl verify cert1.pem cert2.pem

証明書チェーンを確認するには、リーフ証明書が cert.pem にあり、信頼しない中間証明書を untrusted.pem に直接連結する必要があります。信頼できるルート CA 証明書は、/etc/pki/tls/certs/ca-bundle.crt または cacert.pem ファイルに一覧表示されているデフォルト CA に含まれている必要があります。次に、チェーンを確認するために、次の形式でコマンドを発行します。

~]$ openssl verify -untrusted untrusted.pem -CAfile cacert.pem cert.pem

詳細は、man verify(1) を参照してください。

重要

MD5 ハッシュアルゴリズムを使用した署名の検証は、このアルゴリズムの強度が不十分であるため、Red Hat Enterprise Linux 7 では無効になっています。SHA 256 などの強度の高いアルゴリズムを常に使用するようにしてください。

4.7.4. ファイルの暗号化および暗号化解除

OpenSSL でファイルを暗号化（および復号化）するには、pkeyutl または enc の組み込みコマンドのいずれかを使用できます。pkeyutl では、RSA キーを使用して暗号化と復号化を実行しますが、enc では対称アルゴリズムが使用されます。

RSA 鍵の使用

プレーンテキスト と呼ばれるファイルを暗号化するには、以下のコマンドを実行します。

~]$ 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

ここで、id は、暗号化エンジンの ID です。エンジンの可用性を確認するには、次のコマンドを発行します。

~]$ openssl engine -t

プレーンテキスト と呼ばれるデータファイルに署名するには、次のようにコマンドを発行します。

~]$ 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 ページでは、公開鍵アルゴリズムユーティリティーについて説明しています。

シンメトリックアルゴリズムの使用

利用可能な対称暗号化アルゴリズムを一覧表示するには、-l などのサポート対象外のオプションを指定して enc コマンドを実行します。

~]$ openssl enc -l

アルゴリズムを指定するには、その名前をオプションとして使用します。たとえば、aes-128-cbc アルゴリズムを使用するには、以下の構文を使用します。

openssl enc -aes-128-cbc

a es-128-cbc アルゴリズムを使用して plaintext という名前のファイルを暗号化するには、以下のコマンドを入力します。

~]$ openssl enc -aes-128-cbc -in plaintext -out plaintext.aes-128-cbc

前の例で取得したファイルを復号化するには、次の例のように -d オプションを使用します。

~]$ openssl enc -aes-128-cbc -d -in plaintext.aes-128-cbc -out plaintext

重要

enc コマンドは AEAD 暗号を適切にサポートせず、ecb モードは安全とは見なされません。最適な結果を得るには、cbc、cfb、ofb、または ctr 以外のモードを使用しないでください。

4.7.5. メッセージダイジェストの生成

dgst コマンドは、提供されたファイルまたはファイルのメッセージダイジェストを 16 進数形式で生成します。また、このコマンドは、デジタル署名や検証にも使用することができます。message digest コマンドの形式は次のとおりです。

openssl dgst algorithm -out filename -sign private-key

ここで、algorithm は、md5|md4|md2|sha1|sha|mdc2|ripemd160|dss1 のいずれかになります。執筆時点では、SHA1 アルゴリズムが推奨されます。DSA を使った署名や検証が必要な場合は、-rand オプションで指定したランダムデータを含むファイルと一緒に dss1 オプションを使用する必要があります。

sha1 アルゴリズムを使用してデフォルトの Hex 形式でメッセージダイジェストを生成するには、次のコマンドを実行します。

~]$ openssl dgst sha1 -out digest-file

秘密鍵 privekey.pem を使用してダイジェストに電子署名を行うには、以下のコマンドを実行します。

~]$ openssl dgst sha1 -out digest-file -sign privkey.pem

詳細は、man dgst(1) を参照してください。

4.7.6. パスワードハッシュの生成

passwd コマンドは、パスワードのハッシュを計算します。コマンドラインでパスワードのハッシュを計算するには、次のようにコマンドを発行します。

~]$ openssl passwd password

デフォルトでは、-crypt アルゴリズムが使用されます。

MD5 ベースの BSD アルゴリズム 1 を使用して、標準入力からパスワードのハッシュを計算するには、以下のコマンドを実行します。

~]$ openssl passwd -1 password

-apr1 オプションは、BSD アルゴリズムの Apache バリアントを指定します。

注記

openssl passwd -1 password コマンドは、FIPS モードが無効になっている場合にのみ使用してください。そうでない場合は、コマンドは機能しません。

ファイルに保存されているパスワードのハッシュを計算し、salt xx を使用するには、以下のコマンドを実行します。

~]$ openssl passwd -salt xx -in password-file

パスワードは標準出力に送られ、出力ファイルを指定する -out オプションはありません。-table は、対応するクリアテキストパスワードを含むパスワードハッシュのテーブルを生成します。

詳細および例は、man sslpasswd(1) を参照してください。

4.7.7. ランダムデータの生成

シードファイルを用いて、ランダムなデータを含むファイルを生成するには、次のコマンドを実行します。

~]$ openssl rand -out rand-file -rand seed-file

ランダムデータプロセスをシードする複数のファイルは、コロン（）をリスト区切り文字と し て使用して指定できます。

詳細は、man rand(1) を参照してください。

4.7.8. システムのベンチマーキング

特定のアルゴリズムのシステムの計算速度をテストするには、次の形式でコマンドを発行します。

~]$ openssl speed algorithm

ここで、algorithm は、使用する予定のサポートされているアルゴリズムの 1 つになります。利用可能なアルゴリズムを一覧表示するには、openssl speed と入力し、Tab を押します。

4.7.9. OpenSSL の設定

OpenSSL には、マスター設定ファイルと呼ばれる /etc/pki/tls/openssl.cnf 設定ファイルがあり、OpenSSL ライブラリーにより読み取られます。また、アプリケーションごとに個別の設定ファイルを用意することも可能です。設定ファイルには、[ section_name ] のようなセクション名を持つセクションが多数含まれています。最初の [ section_name ] までのファイルの最初の部分は、デフォルトのセクションと呼ばれることに注意してください。OpenSSL が設定ファイルで名前を検索する場合、名前付きセクションが最初に検索されます。すべての OpenSSL コマンドは、コマンド内で代替の設定ファイルを指定するためのオプションが使用されていない限り、マスター OpenSSL 設定ファイルを使用します。設定ファイルの詳細は、config (5) の man ページで説明されています。

2 つの RFC は、証明書ファイルの内容を説明しています。以下のとおりです。

4.8. stunnel の使用

stunnel プログラムは、クライアントとサーバー間の暗号化ラッパーです。設定ファイルで指定されたポートでリッスンし、クライアントとの通信を暗号化して、通常のポートでリッスンしている元のデーモンにデータを転送します。こうすることで、それ自体がどのタイプの暗号化もサポートしていないサービスを保護したり、POODLE SSL 脆弱性 (CVE-2014-3566) の影響を受ける SSL バージョン 2 および 3 など、セキュリティー上の理由から避けたいタイプの暗号化を使用しているサービスのセキュリティーを向上させたりすることができます。詳しくは https://access.redhat.com/solutions/1234773 を参照してください。CUPS は、独自の設定で SSL を無効にする方法を提供しないコンポーネントの例です。

4.8.1. stunnel のインストール

root で以下のコマンドを入力して、stunnel パッケージをインストールします。

~]# yum install stunnel

4.8.2. stunnel を TLS Wrapper として設定する

stunnel を設定するには、次の手順に従います。

使用するサービスに関係なく、stunnel の有効な証明書が必要です。適切な証明書がない場合は、認証局 に申請して取得するか、自己署名証明書を作成することができます。
警告
実稼働環境で実行されているサーバーには、常に認証局によって署名された証明書を使用してください。自己署名証明書は、テスト目的またはプライベートネットワークにのみ適しています。
認証局から付与される証明書の詳細については、「証明書署名要求の作成」を参照してください。一方、stunnel の自己署名証明書を作成するには、/etc/pki/tls/certs/ ディレクトリーに移動し、root で以下のコマンドを入力します。
```
certs]# make stunnel.pem
```
すべての質問に答えて、プロセスを完了してください。
証明書がある場合は、stunnel の設定ファイルを作成します。これは、すべての行がオプションまたはサービス定義の開始を指定するテキストファイルです。コメントと空の行をファイルに残して、コメントがセミコロンで始まる読みやすさを向上させることもできます。
stunnel RPM パッケージには、設定ファイルを保存できる /etc/stunnel/ ディレクトリーが含まれています。stunnel はファイル名やその拡張子の特別な形式を必要としませんが、/etc/stunnel/stunnel.conf を使用します。以下のコンテンツは、stunnel を TLS ラッパーとして設定します。
```
cert = /etc/pki/tls/certs/stunnel.pem
; Allow only TLS, thus avoiding SSL
sslVersion = TLSv1
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 は 2 つの独立した暗号化プロトコルですが、ここでは TLS を使用できることに注意してください。
- chroot — セキュリティーを強化するために stunnel プロセスが実行される変更された root ディレクトリー
- setuid, setgid - stunnel プロセスが実行されるユーザーおよびグループ。nobody は制限されたシステムアカウントです。
- pid - stunnel がプロセス ID を保存するファイル( chrootと相対的)
- socket — ローカルおよびリモートのソケットオプション。この場合、ネットワーク遅延を改善するために Nagle のアルゴリズム を無効にします。
- [service_name] : サービス定義の先頭。この行の下で使用されるオプションは指定のサービスのみに適用されますが、上記のオプションは stunnel にグローバルに影響します。
- accept — リッスンするポート
- connect — 接続先のポート。これは、セキュリティー保護対象のサービスが使用するポートである必要があります
- TIMEOUTclose - クライアントからの close_notify アラートを待機する秒数。0 は stunnel にまったく待機しないように指示します。
- options — OpenSSL ライブラリーオプション
例4.3 CUPS のセキュア化
stunnel を CUPS の TLS ラッパーとして設定するには、以下の値を使用します。
```
[cups]
accept = 632
connect = 631
```
632 の代わりに、任意の空きポートを使用できます。631 は CUPS が通常使用するポートです。
chroot ディレクトリーを作成し、setuid オプションで指定されたユーザーに、そのディレクトリーへの書き込みアクセス権を付与します。これを行うには、root で以下のコマンドを入力します。
```
~]# mkdir /var/run/stunnel
~]# chown nobody:nobody /var/run/stunnel
```
これにより、stunnel が PID ファイルを作成できます。
システムが新しいポートへのアクセスを許可しないファイアウォール設定を使用している場合は、それに応じて変更してください。詳細は「GUI を使用してポートを開く」を参照してください。
設定ファイルと chroot ディレクトリーを作成し、指定したポートにアクセスできることを確認したら、stunnel の使用を開始する準備が整います。

4.8.3. stunnel の起動、停止、再起動

stunnel を起動するには、root で以下のコマンドを入力します。

~]# stunnel /etc/stunnel/stunnel.conf

デフォルトでは、stunnel は /var/log/secure を使用して出力をログに記録します。

stunnel を終了するには、root で以下のコマンドを実行してプロセスを強制終了します。

~]# kill `cat /var/run/stunnel/stunnel.pid`

stunnel の実行中に設定ファイルを編集した場合は、stunnel を終了して再度起動し、変更を有効にします。

4.9. 暗号化

4.9.1. LUKS ディスクの暗号化の使用

Linux Unified Key Setup-on-disk-format (または LUKS) を使用すると、Linux コンピューター上のパーティションを暗号化できます。特に、モバイル PC やリムーバブルメディアに関しては特に重要です。LUKS を使用すれば、複数のユーザー鍵が、パーティションのバルク暗号化に使用されるマスター鍵を複号できるようになります。

LUKS の概要

LUKS の機能

LUKS は、ブロックデバイス全体を暗号化するため、脱着可能なストレージメディアやノート PC のディスクドライブといった、モバイルデバイスのコンテンツの保護に適しています。
暗号化されたブロックデバイスの基本的な内容は任意です。これにより、スワップ デバイスの暗号化に役立ちます。また、とりわけデータストレージ用にフォーマットしたブロックデバイスを使用する特定のデータベースに関しても有用です。
LUKS は、既存のデバイスマッパーのカーネルサブシステムを使用します。
LUKS は、パラフレーズの強化を提供し、辞書攻撃から保護します。
LUKS デバイスには複数のキースロットが含まれ、ユーザーはこれを使用してバックアップキーやパスフレーズを追加できます。

LUKS が 行わない こと

LUKS は、多くのユーザー (8 人以上) が同じデバイスへの個別のアクセスキーを持つことを必要とするシナリオには適していません。
LUKS は、ファイルレベルの暗号化を必要とするアプリケーションには適していません。

重要

LUKS などのディスク暗号化ソリューションは、システムの停止時にしかデータを保護しません。システムの電源がオンになり、LUKS がディスクを復号すると、そのディスクのファイルは、通常、そのファイルにアクセスできるすべてのユーザーが使用できます。

4.9.1.1. Red Hat Enterprise Linux における LUKS の実装

Red Hat Enterprise Linux 7 は LUKS を利用してファイルシステム暗号化を実行します。デフォルトではインストール時に、ファイルシステムを暗号化するオプションが指定されていません。ハードドライブを暗号化するオプションを選択すると、コンピューターを起動するたびに尋ねられるパスフレーズの入力を求められます。このパスフレーズは、あなたのパーティションを復号化するために使用されるバルク暗号化キーの "ロックを解除" します。デフォルトのパーティションテーブルの変更を選択すると、暗号化するパーティションを選択できます。この設定は、パーティションテーブル設定で行われます。

LUKS に使用されるデフォルトの暗号( cryptsetup --helpを参照)は aes-cbc-essiv:sha256 (ESSIV - Encrypted Salt-Sector Initialization Vector)です。インストールプログラム Anaconda は、デフォルトで XTS モード(aes-xts-plain64)を使用することに注意してください。LUKS のデフォルトの鍵サイズは 256 ビットです。Anaconda を使用した LUKS のデフォルトの鍵サイズ(XTS モード)は 512 ビットです。利用可能な暗号は以下のとおりです。

AES (Advanced Encryption Standard) - FIPS PUB 197
Twofish (128 ビットブロック暗号)
Serpent
cast5 - RFC 2144
cast6 - RFC 2612

4.9.1.2. 手動でのディレクトリーの暗号化

警告

この手順を実行すると、暗号化するパーティションにあるすべてのデータが削除されます。すべての情報を失うことになります。この手順を開始する前に、必ずデータを外部ソースにバックアップしてください。

root でシェルプロンプトに次のように入力し、ランレベル 1 に入ります。
```
telinit 1
```
既存の /home をアンマウントします。
```
umount /home
```
前の手順のコマンドが失敗した場合は、fuser を使用して、/home を占有しているプロセスを見つけ、それらを強制終了します。
```
fuser -mvk /home
```
/home がマウントされていないことを確認します。
```
grep home /proc/mounts
```
パーティションをランダムなデータで埋めます。
```
shred -v --iterations=1 /dev/VG00/LV_home
```
このコマンドは、デバイスのシーケンシャル書き込み速度で進行し、完了するまでに時間がかかる場合があります。使用済みのデバイスに暗号化されていないデータが残らないようにし、ランダムなデータだけでなく、暗号化されたデータを含むデバイスの部分を難読化することが重要なステップとなります。

パーティションを初期化します。

cryptsetup --verbose --verify-passphrase luksFormat /dev/VG00/LV_home

新たに暗号化したデバイスを開きます。
```
cryptsetup luksOpen /dev/VG00/LV_home home
```
デバイスがあることを確認します。
```
ls -l /dev/mapper | grep home
```
ファイルシステムを作成します。
```
mkfs.ext3 /dev/mapper/home
```
ファイルシステムをマウントします。
```
mount /dev/mapper/home /home
```
ファイルシステムが表示されていることを確認します。
```
df -h | grep home
```
以下を /etc/crypttab ファイルに追加します。
```
home /dev/VG00/LV_home none
```
/etc/fstab ファイルを編集し、/home の古いエントリーを削除し、以下の行を追加します。
```
/dev/mapper/home /home ext3 defaults 1 2
```
SELinux のセキュリティーコンテキストをデフォルトに戻します。
```
/sbin/restorecon -v -R /home
```
マシンを再起動します。
```
shutdown -r now
```
/etc/crypttab のエントリーにより、コンピューターが起動時に luks のパスフレーズを要求します。
root でログインして、バックアップを復元してください。

これで、コンピューターの電源がオフのときにすべてのデータを安全に保管するための暗号化されたパーティションができました。

4.9.1.3. 既存のデバイスへの新しいパスフレーズの追加

既存のデバイスに新しいパスフレーズを追加するには、次のコマンドを使用します。

cryptsetup luksAddKey device

認証のために既存のパスフレーズのいずれかを入力するように求められた後、新しいパスフレーズを入力するように求められます。

4.9.1.4. 既存のデバイスからのパスフレーズ削除

既存のデバイスからパスフレーズを削除するには、次のコマンドを使用します。

cryptsetup luksRemoveKey device

削除するパスフレーズの入力を求められ、次に認証用にに残りのパスフレーズのいずれかを入力するように求められます。

4.9.1.5. Anaconda での暗号化したブロックデバイスの作成

システムインストール時に、暗号化されたデバイスを作成することができます。これにより、暗号化されたパーティションを持つシステムを簡単に設定することができます。

ブロックデバイスの暗号化を有効にするには、自動パーティション設定を選択する際に Encrypt System チェックボックスをオンにするか、個別のパーティション、ソフトウェア RAID アレイ、または論理ボリュームを作成するときに Encrypt チェックボックスをオンにします。パーティション設定が完了すると、暗号化用のパスフレーズの入力が求められます。このパスフレーズは、暗号化されたデバイスにアクセスする際に必要となります。既存の LUKS デバイスがあり、インストール時に正しいパスフレーズを入力した場合、パスフレーズ入力ダイアログにもチェックボックスが表示されます。このチェックボックスをオンにすると、既存の各暗号化ブロックデバイスの使用可能なスロットに、新しいパスフレーズを追加する必要があることを意味します。

注記

自動パーティション設定画面のシステムの暗号化チェックボックスを選択し、カスタムレイアウトの作成を選択しても、ブロックデバイスは自動的に暗号化されません。

注記

キックスタート を使用して、新しい暗号化ブロックデバイスごとに個別のパスフレーズを設定できます。

4.9.1.6. 関連情報

LUKS または Red Hat Enterprise Linux 7 でのハードドライブの暗号化に関する詳細情報については、以下のリンクのいずれかを参照してください。

4.9.2. GPG 鍵の作成

GPG は、あなた自身を識別し、あなたの知らない人とのコミュニケーションを含むあなたのコミュニケーションを認証するために使用されます。GPG を使用すると、GPG で署名された電子メールを読んでいる人は誰でも、その信頼性を確認できます。言い換えれば、GPG は、あなたが署名した通信が実際にあなたからのものであることを合理的に確信できるようにします。GPG は、サードパーティーがコードを変更したり、会話を傍受したり、メッセージを変更したりすることを阻止できるので便利です。

4.9.2.1. GNOME での GPG 鍵の作成

GNOME で GPG キーを作成するには、以下の手順に従います。

Seahorse ユーティリティーをインストールします。これにより、GPG キーの管理が容易になります。
```
~]# yum install seahorse
```
キーを作成するには、Applications → Accessories メニューから Passwords and Encryption Keys を選択します。これにより、アプリケーションの Seahorse が起動します。
File メニューから New を選択してから PGP Key を選択します。次に、Continue をクリックします。
フルネーム、メールアドレス、および自身に関して説明するオプションのコメントを入力します (例:John C. Smith、jsmith@example.com、ソフトウェアエンジニア)。Create をクリックします。キーのパスフレーズを要求するダイアログが表示されます。強力かつ覚えやすいパスフレーズを選んでください。OK をクリックすると、キーが作成されます。

警告

パスフレーズを忘れると、データの暗号解除ができなくなります。

GPG キー ID を見つけるには、新しく作成された鍵の横にある Key ID 列を確認します。ほとんどの場合、キー ID を求められた場合は、 0x 6789ABCD のように、キー ID の前に 0x を付けます。秘密鍵のバックアップを取り、安全な場所に保管してください。

4.9.2.2. KDE での GPG 鍵の作成

KDE で GPG キーを作成するには、以下の手順に従います。

メインメニューから Applications → Utilities → Encryption Tool を選択して、KGpg プログラムを起動します。以前に KGpg を使用したことがない場合、プログラムは独自の GPG キーペアを作成するプロセスを順を追って説明します。
新しいキーペアを作成するように求めるダイアログボックスが表示されます。名前、メールアドレス、およびオプションのコメントを入力します。キーの有効期限、キーの強度 (ビット数) およびアルゴリズムを選択することもできます。
次のダイアログボックスでパスフレーズを入力します。この時点で、キーが KGpg のメインウィンドウに表示されます。

警告

パスフレーズを忘れると、データの暗号解除ができなくなります。

4.9.2.3. コマンドラインを用いた GPG 鍵の生成

次のシェルコマンドを使用します。
```
~]$ gpg2 --gen-key
```
このコマンドは、公開鍵と秘密鍵からなるキーペアを生成します。他の人はあなたの公開鍵を使用してあなたの通信を認証および復号化します。公開鍵をできるだけ広く配布します。特に、メーリングリストなど、認証された通信の受信希望者に配布します。
一連のプロンプトがプロセスを指示します。必要に応じて、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 鍵は、通信の署名だけでなく、ファイルの暗号化も可能にします。
鍵のサイズを選択します。
```
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)
```
この場合も、デフォルトの 2048 は、ほとんどすべてのユーザーにとって十分であり、非常に強力なセキュリティーレベルを表しています。
鍵の有効期限を選択します。デフォルトのなしを使用する代わりに、有効期限を選択することが推奨され ます。たとえば、キーの電子メールアドレスが無効になった場合、有効期限があると、他の人にその公開キーの使用を停止するように知らせることができます。
```
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 年間有効になります。(気が変わった場合は、キーが生成された後にこの有効期限を変更できます。)
gpg2 アプリケーションが署名情報を要求する前に、以下のプロンプトが表示されます。
```
Is this correct (y/N)?
```
y を入力してプロセスを終了します。
GPG 鍵用に氏名と電子メールアドレスを入力します。このプロセスは、あなたが実在する人物であることを証明するためのものであることを忘れないでください。このため、本当の名前を入力してください。偽の電子メールアドレスを選択すると、他の人があなたの公開鍵を見つけるのがより困難になります。これにより、通信の認証が困難になります。たとえば、この GPG キーをメーリングリストでの自己紹介に使用している場合は、そのリストで使用している電子メールアドレスを入力します。
コメントフィールドには、エイリアスなどの情報を記載してください。(人によっては、目的別にキーを使い分け、それぞれのキーに "Office" または "Open Source Projects" などのコメントをつけて識別しています)。
すべてのエントリーが正しい場合は、確認プロンプトで O を入力して続行するか、他のオプションを使用して問題を修正します。最後に、秘密鍵のパスフレーズを入力します。gpg2 プログラムでは、入力エラーが発生しないようにパスフレーズを 2 回入力するように求められます。
最後に、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]
```
キーのフィンガープリントは、キーの省略形の "署名" です。これにより、実際の公開鍵を改ざんされることなく受け取ったことを他者に確認することができるのです。このフィンガープリントを書き留める必要はありません。いつでもフィンガープリントを表示するには、以下のコマンドを使用し、電子メールアドレスは置き換えます。
```
~]$ gpg2 --fingerprint jqdoe@example.com
```
"GPG キー ID" は、公開鍵を識別する 8 桁の 16 進数で設定されています。上記の例では、GPG キー ID は 1B2AFA1C です。ほとんどの場合、キー ID を求められた場合は、 0x 6789ABCD のように、キー ID の前に 0x を付けます。

警告

パスフレーズを忘れると、キーは使用できなくなり、そのキーを使用して暗号化されたデータはすべて失われます。

4.9.2.4. 公開鍵の暗号化について

4.9.3. 公開鍵暗号化における openCryptoki の使用

openCryptoki は PKCS#11 の Linux 実装で、トークンと呼ばれる暗号化デバイスへのアプリケーションプログラミングインターフェイス(API)を定義する 公開鍵暗号化標準 です。トークンは、ハードウェアまたはソフトウェアに実装することが可能です。本章では、openCryptoki システムを Red Hat Enterprise Linux 7 でインストール、設定、および使用する方法の概要を説明します。

4.9.3.1. openCryptoki のインストールとサービスの起動

テスト目的でトークンのソフトウェア実装を含む、基本的な openCryptoki パッケージをシステムにインストールするには、root で以下のコマンドを実行します。

~]# yum install opencryptoki

使用する予定のハードウェアトークンの種類によっては、特定のユースケースをサポートする追加のパッケージをインストールする必要がある場合があります。たとえば、Trusted Platform Module (TPM) デバイスのサポートを取得するには、opencryptoki-tpmtok パッケージをインストールする必要があります。

Yum パッケージマネージャーを使用してパッケージをインストールする方法は、Red Hat Enterprise Linux 7 システム管理者のガイドのパッケージのインストールセクションを参照してください。

openCryptoki サービスを有効にするには、pkcsslotd デーモンを実行する必要があります。root で以下のコマンドを実行して、現行セッションでデーモンを起動します。

~]# systemctl start pkcsslotd

起動時に自動的にサービスが開始されるようにするには、次のコマンドを入力します。

~]# systemctl enable pkcsslotd

systemd ターゲットを使ってサービスを管理する方法の詳細については、Red Hat Enterprise Linux 7 システム管理者ガイドの Managing Services with systemd の章を参照してください。

4.9.3.2. openCryptoki の設定と使用

起動すると、pkcsslotd デーモンは /etc/opencryptoki/opencryptoki.conf 設定ファイルを読み取ります。このファイルは、システムで動作するように設定されたトークンとスロットに関する情報を収集します。

このファイルは、キーと値のペアを使用して個々のスロットを定義します。各スロット定義には、説明、使用するトークンライブラリーの仕様、およびスロットの製造元の ID を含めることができます。オプションで、スロットのハードウェアとファームウェアのバージョンを定義できます。ファイルのフォーマットや、個々のキーとそれに割り当てられる値の詳細については、opencryptoki.conf(5) の man ページを参照してください。

ランタイム時に pkcsslotd デーモンの動作を変更するには、pkcsconf ユーティリティーを使用します。このツールでは、デーモンの状態の表示や設定、現在設定されているスロットやトークンの一覧表示や変更を行うことができます。たとえば、トークンに関する情報を表示するには、以下のコマンドを実行します( pkcsslotd デーモンと通信する必要があるすべての非 root ユーザーは、pkcs11 システムグループの一部である必要があることに注意してください)。

~]$ pkcsconf -t

pkcsconf ツールで利用可能な引数の一覧は、pkcsconf(1) の man ページを参照してください。

警告

このグループのすべてのメンバーには、openCryptoki サービスの他のユーザーが設定済みの PKCS#11 トークンにアクセスできないようにブロックする権利があるため、完全に信頼できるユーザーのみが pkcs11 グループのメンバーシップを割り当てる必要があることに注意してください。このグループのすべてのメンバーは、openCryptoki の他のユーザーの権限で任意のコードを実行することもできます。

4.9.4. OpenSSH に認証情報を提供するスマートカードの使用

スマートカードは、USB メモリー、MicroSD、または SmartCard のフォームファクターを持つ軽量のハードウェアセキュリティーモジュールです。リモートで管理可能なセキュアなキーストアを提供します。Red Hat Enterprise Linux 7 では、OpenSSH はスマートカードを使用した認証をサポートしています。

OpenSSH でスマートカードを使用するには、カードからの公開鍵を ~/.ssh/authorized_keys ファイルに保存します。opensc パッケージが提供する PKCS#11 ライブラリーをクライアントにインストールします。PKCS#11 は、トークンと呼ばれる暗号化デバイスへのアプリケーションプログラミングインターフェイス(API)を定義する公開鍵暗号化標準です。root で以下のコマンドを入力します。

~]# yum install opensc

4.9.4.1. カードからの公開鍵の取得

カードの鍵を一覧表示するには、ssh-keygen コマンドを使用します。共有ライブラリー (以下の例では OpenSC) を -D ディレクティブで指定します。

~]$ ssh-keygen -D /usr/lib64/pkcs11/opensc-pkcs11.so
ssh-rsa AAAAB3NzaC1yc[...]+g4Mb9

4.9.4.2. サーバーへの公開鍵の保存

リモートサーバーでスマートカードを使用した認証を有効にするには、公開鍵をリモートサーバーに転送します。これを行うには、取得した文字列（キー）をコピーしてリモートシェルに貼り付けるか、鍵をファイル（以下の例ではsmartcard.pub ）に保存し、ssh-copy-id コマンドを使用します。

~]$ ssh-copy-id -f -i smartcard.pub user@hostname
user@hostname's password:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh user@hostname"
and check to make sure that only the key(s) you wanted were added.

秘密鍵ファイルなしで公開鍵を保存するには、環境変数SSH_COPY_ID_LEGACY=1 または -f オプションを使用する必要があります。

4.9.4.3. スマートカードのキーを使用したサーバーへの認証

OpenSSH は、スマートカードからあなたの公開鍵を読み取り、鍵そのものを公開することなく、あなたの秘密鍵を使った操作を実行することができます。これは、秘密鍵がカードを離れないことを意味します。スマートカードを認証に使用してリモートサーバーに接続するには、次のコマンドを入力し、カードを保護する PIN を入力してください。

[localhost ~]$ ssh -I /usr/lib64/pkcs11/opensc-pkcs11.so hostname
Enter PIN for 'Test (UserPIN)':
[hostname ~]$

ホスト名 を、接続する実際のホスト名に置き換えます。

次回リモートサーバーに接続する際に不要な入力を保存するには、~/.ssh/config ファイルの PKCS#11 ライブラリーへのパスを保存します。

Host hostname
    PKCS11Provider /usr/lib64/pkcs11/opensc-pkcs11.so

追加オプションを指定せずに ssh コマンドを実行して接続します。

[localhost ~]$ ssh hostname
Enter PIN for 'Test (UserPIN)':
[hostname ~]$

4.9.4.4. ssh-agent を使用した PIN ログインの自動化

ssh-agent の使用を開始するための環境変数を設定します。ssh-agent は通常のセッションですでに実行されているため、ほとんどの場合、この手順をスキップできます。以下のコマンドを使用して、認証エージェントに接続できるかどうかを確認します。

~]$ ssh-add -l
Could not open a connection to your authentication agent.
~]$ eval `ssh-agent`

このキーを使って接続するたびに PIN を書き込まないようにするには、次のコマンドを実行してカードをエージェントに追加してください。

~]$ ssh-add -s /usr/lib64/pkcs11/opensc-pkcs11.so
Enter PIN for 'Test (UserPIN)':
Card added: /usr/lib64/pkcs11/opensc-pkcs11.so

カードを ssh-agent から削除するには、次のコマンドを使用します。

~]$ ssh-add -e /usr/lib64/pkcs11/opensc-pkcs11.so
Card removed: /usr/lib64/pkcs11/opensc-pkcs11.so

注記

FIPS 201-2 は、カードに格納されたデジタル署名鍵の使用条件として、Personal Identity Verification (PIV) カード保持者による明示的なユーザーアクションを要求します。OpenSC には、この要件が正しく適用されます。

しかし、アプリケーションによっては、カード保有者が署名のたびに PIN を入力することを要求するのは現実的ではありません。スマートカード PIN をキャッシュするには、/etc/opensc-x86_64.conf の pin_cache_ignore_user_consent = true; オプションの前に # 文字を削除します。

詳細は、Cardholder Authentication for the PIV Digital Signature Key (NISTIR 7863) レポートを参照してください。

4.9.4.5. 関連情報

ハードウェアまたはソフトウェアトークンのセットアップについては、Smart Card support in Red Hat Enterprise Linux 7 の記事で説明されています。

スマートカードや同様の PKCS# 11 セキュリティートークンを管理および使用する pkcs11-tool ユーティリティーの詳細は、pkcs11-tool (1) の man ページを参照してください。

4.9.5. 信頼できる鍵および暗号化された鍵

信頼できる鍵と暗号化された鍵は、カーネルキーリングサービスを使用するカーネルが生成する可変長の対称鍵です。キーが暗号化されていない形式でユーザースペースに表示されないという事実は、キーの整合性を検証できることを意味します。つまり、拡張検証モジュール (EVM) などで実行中のシステムの整合性を検証および確認するために使用できます。ユーザーレベルのプログラムは、暗号化された blobs の形式でのみキーにアクセスできます。

信頼できる鍵は、Trusted Platform Module (TPM) チップというハードウェアが必要になります。これは、鍵を作成し、暗号化 (保護) するために使用されます。TPM は、ストレージルートキー(SK)と呼ばれる 2048 ビットの RSA キーを使用して鍵 を保護します。

それに加えて、信頼できるキーは、TPM の プラットフォーム設定レジスター (PCR) 値の特定のセットを使用してシールすることもできます。PCR には、BIOS、ブートローダー、およびオペレーティングシステムを反映する一連の整合性管理値が含まれています。つまり、PCR でシールされたキーは、暗号化されたのとまったく同じシステム上の TPM でのみ復号化できます。ただし、PCR で保護された信頼できる鍵が読み込まれると (キーリングに追加されると)、新しいカーネルなどを起動できるように、関連する PCR 値が検証され、新しい (または今後の) PCR 値に更新されます。1 つの鍵を複数の blobs として保存することもできますが、それぞれ PCR 値が異なります。

暗号化鍵はカーネルの AES 暗号化を使用するため、TPM は必要ありません。これにより、信頼できる鍵よりも高速になります。暗号化鍵は、カーネルが生成した乱数を使用して作成され、ユーザー空間の blobs へのエクスポート時に マスターキー により暗号化されます。このマスターキーは、信頼できるキーでもユーザーキーでも構いませんが、これが主な欠点となっています。マスターキーが信頼できるキーでない場合、暗号化されたキーは、それを暗号化するために使用したユーザーキーと同等の安全性しか得られません。

4.9.5.1. 鍵を使った作業

鍵を使用して操作を実行する前に、trusted および encrypted-keys カーネルモジュールがシステムに読み込まれていることを確認してください。さまざまな RHEL カーネルアーキテクチャーでカーネルモジュールをロードするときは、次の点を考慮してください。

x86_64 アーキテクチャーを持つ RHEL カーネルの場合、TRUSTED_KEYS および ENCRYPTED_KEYS コードはコアカーネルコードの一部として組み込まれています。その結果、x86_64 システムユーザーは、trusted モジュールおよび encrypted-keys モジュールを読み込むことなく、これらの鍵を使用できます。
その他のアーキテクチャーでは、鍵で操作を実行する前に、trusted および encrypted-keys カーネルモジュールを読み込む必要があります。カーネルモジュールをロードするには、以下のコマンドを実行します。
```
~]# modprobe trusted encrypted-keys
```

信頼できる鍵および暗号化された鍵は、keyctl ユーティリティーを使用して作成、読み込み、エクスポート、および更新できます。keyctl の使用に関する詳細は、keyctl(1) を参照してください。

注記

TPM を使用するには (信頼できる鍵の作成および保護目的など)、これを有効かつアクティブにする必要があります。これは通常、マシンの BIOS の設定、またはユーティリティーの tpm-tools パッケージから tpm_setactive コマンドを使用して実行できます。また、TPM と通信するには、TrouSers アプリケーション( trousers パッケージ)と、TrouSers スイートの一部である tcsd デーモンをインストールする必要があります。

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

次に、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

重要

暗号化鍵がマスターの信頼できる鍵で保護されていない場合には、そのセキュリティーは、ユーザーのマスターキー (乱数キー) を使用して暗号化したものと同じでしかない点に注意してください。そのため、マスターユーザーキーはできるだけ安全に、システムの起動プロセスの早い段階で読み込む必要があります。

4.9.5.2. 関連情報

次のオフラインおよびオンラインリソースを使用して、信頼できる暗号化されたキーの使用に関する追加情報を取得できます。

インストールされているドキュメント

keyctl(1) : keyctl ユーティリティーとそのサブコマンドの使用を説明します。

オンラインドキュメント

Red Hat Enterprise Linux 7 SELinux ユーザーおよび管理者のガイド: Red Hat Enterprise Linux 7 『の SELinux ユーザーおよび管理者のガイド』では、SELinux の原則と、SELinux を Apache HTTP Server などのさまざまなサービスで設定および使用する方法を説明します。
https://www.kernel.org/doc/Documentation/security/keys-trusted-encrypted.txt — Linux カーネルの信頼できる鍵および暗号化された鍵機能に関する公式ドキュメントです。

4.9.6. 乱数ジェネレーターの使用

簡単に破ることができない安全な暗号化キーを生成できるようにするには、乱数のソースが必要です。一般に、番号がランダムであるほど、一意のキーを取得する可能性が高くなります。乱数を生成するための エントロピー は、通常、環境の "ノイズ" を計算するか、ハードウェア 乱数ジェネレーター を使用して取得されます。

rng-tools パッケージの一部である rngd デーモンは、エントロピーを抽出するために環境ノイズとハードウェア乱数ジェネレーターの両方を使用できます。デーモンは、乱数性のソースによって供給されるデータが十分にランダムなものかどうかをチェックしてから、カーネルの乱数エントロピープールにデータを格納します。生成する乱数は、/dev/random および /dev/urandom キャラクターデバイスで利用できます。

/dev/random と /dev/urandom の違いは、前者はブロッキングデバイスであることです。つまり、エントロピーの量が適切なランダム出力を生成するのに不十分なと判断すると、番号の供給を停止します。逆に、/dev/urandom はノンブロッキングソースであり、カーネルのエントロピープールを再利用するため、エントロピーが少ない疑似乱数を無制限に提供できます。そのため、/dev/urandom は、長期暗号化キーの作成には使用しないでください。

rng-tools パッケージをインストールするには、root で以下のコマンドを発行します。

~]# yum install rng-tools

rngd デーモンを起動するには、root で以下のコマンドを実行します。

~]# systemctl start rngd

デーモンの状態を問い合わせるには、次のコマンドを使用します。

~]# systemctl status rngd

オプションのパラメーターを使用して rngd デーモンを起動するには、直接実行します。たとえば、乱数入力の代替ソース( /dev/hwrandom以外)を指定するには、以下のコマンドを使用します。

~]# rngd --rng-device=/dev/hwrng

上記のコマンドは、乱数が読み取られるデバイスとして、/dev/hwrng で rngd デーモンを起動します。同様に、-o （または --random-device）オプションを使用して、乱数出力用のカーネルデバイスを選択できます（デフォルトの /dev/random以外）。利用可能なすべてのオプションの一覧は、rngd(8) の man ページを参照してください。

特定のシステムで利用可能なエントロピーのソースを確認するには、root で以下のコマンドを実行します。

~]# rngd -vf
Unable to open file: /dev/tpm0
Available entropy sources:
	DRNG

注記

rngd -v コマンドを入力すると、以下のプロセスがバックグラウンドで実行を継続します。-b, --background オプション (デーモンになる) はデフォルトで適用されます。

TPM デバイスが存在しない場合は、エントロピーのソースとして Intel Digital Random Number Generator (DRNG) のみが表示されます。お使いの CPU が RDRAND プロセッサー命令をサポートしているかどうかを確認するには、以下のコマンドを入力します。

~]$ cat /proc/cpuinfo | grep rdrand

注記

詳細およびソフトウェアコードの例については、Intel Digital Random Number Generator (DRNG) Software Implementation Guide. を参照してください。

rng-tools パッケージには、データのランダム性を確認するために使用できる rngtest ユーティリティーも含まれています。/dev/random の出力のランダム性のレベルをテストするには、次のように rngtest ツールを使用します。

~]$ cat /dev/random | rngtest -c 1000
rngtest 5
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 998
rngtest: FIPS 140-2 failures: 2
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 2
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=1.171; avg=8.453; max=11.374)Mibits/s
rngtest: FIPS tests speed: (min=15.545; avg=143.126; max=157.632)Mibits/s
rngtest: Program run time: 2390520 microseconds

rngtest ツールの出力に表示される多数の障害は、テストされたデータのランダム性が不十分であり、依存しないことを示しています。rngtest ユーティリティーで利用可能なオプションの一覧は、rngtest(1) の man ページを参照してください。

Red Hat Enterprise Linux 7 では、ホストマシンからエントロピーにアクセスできる KVM 仮想マシンを提供する virtio RNG （乱数ジェネレーター）デバイスが導入されました。推奨される設定では、hwrng はホスト Linux カーネルのエントロピープールに( /dev/randomを介して)フィードし、QEMU はゲストが要求するエントロピーのソースとして /dev/random を使用します。

図4.1 virtio RNG デバイス

[D]

以前は、Red Hat Enterprise Linux 7.0 ゲストおよび Red Hat Enterprise Linux 6 ゲストは、rngd ユーザースペースデーモンを介してホストからのエントロピーを利用できました。デーモンの設定は、Red Hat Enterprise Linux のインストールごとに手作業で行っていました。Red Hat Enterprise Linux 7.1 では、手動の手順が不要になり、プロセス全体がシームレスかつ自動化されています。rngd を使用する必要がなくなり、使用可能なエントロピーが特定のしきい値を下回ると、ゲストカーネル自体がホストからエントロピーをフェッチします。これにより、ゲストカーネルは、アプリケーションが要求するとすぐに乱数を使用できるようにします。

Red Hat Enterprise Linux インストーラーである Anaconda は、インストーラーイメージに virtio-rng モジュールを提供し、Red Hat Enterprise Linux のインストール時にホストエントロピーを利用できるようにするようになりました。

重要

シナリオで使用する乱数ジェネレーターを正しく決定するには、Understanding the Red Hat Enterprise Linux random number generator interface の記事を参照してください。

4.10. ポリシーベースの復号を使用して暗号化ボリュームの自動アンロックの設定

Policy-Based Decryption (PBD) は、ユーザーパスワード、Trusted Platform Module (TPM) デバイス、スマートカードなどのシステムに接続された PKCS#11 デバイス、または特殊なネットワークサーバーなどを使用した異なる方法を用いて、物理および仮想マシンのハードドライブの暗号化された root ボリュームとセカンダリーボリュームを解除できるテクノロジーのコレクションです。

テクノロジーとしての PBD を使用すると、さまざまなロック解除方法をポリシーに組み合わせて、同じボリュームをさまざまな方法でロック解除する機能を作成できます。現在、Red Hat Enterprise Linux に実装されている PBD は、Clevis フレームワークと pins と呼ばれるプラグインで設定されています。各ピンは、個別のアンロック機能を提供します。現在のところ、TPM によるボリュームのロック解除とネットワークサーバーによるロック解除の 2 つのピンしか用意されていません。

NBDE (Network Bound Disc Encryption) は、特定のネットワークサーバーに暗号化ボリュームをバインドできるようにする PBD テクノロジーのサブカテゴリーです。NBDE の現在の実装には、Tang サーバー用の Clevis ピンと Tang サーバー自体が含まれています。

4.10.1. NBDE (Network-Bound Disk Encryption)

Network Bound Disk Encryption (NBDE) を使用すると、システムの再起動時にパスワードを手動で入力することなく、物理マシンおよび仮想マシンのハードドライブの root ボリュームを暗号化できます。

Red Hat Enterprise Linux 7 では、NBDE は以下のコンポーネントおよび技術により実装されます。

図4.2 Clevis と Tang を使用した Network-Bound Disk Encryption

Tang は、ネットワークのプレゼンスにデータをバインドするためのサーバーです。セキュリティーが保護された特定のネットワークにシステムをバインドする際に利用可能なデータを含めるようにします。Tang はステートレスで、TLS または認証は必要ありません。エスクローベースのソリューション (サーバーが暗号鍵をすべて保存し、使用されたことがあるすべての鍵に関する知識を有する) とは異なり、Tang はクライアントの鍵と相互作用することはないため、クライアントから識別情報を得ることがありません。

Clevis は、自動化された復号用のプラグイン可能なフレームワークです。NBDE では、Clevis は、LUKS ボリュームの自動アンロックを提供します。clevis パッケージは、クライアントで使用される機能を提供します。

Clevis ピン は、Clevis フレームワークへのプラグインです。このようなピンの 1 つは、NBDE サーバー (Tang) との相互作用を実装するプラグインです。

Clevis および Tang は、一般的なクライアントおよびサーバーのコンポーネントで、ネットワークがバインドされた暗号化を提供します。Clevis および Tang は、Red Hat Enterprise Linux 7 で LUKS と組み合わせて、root および非 root のストレージボリュームの暗号化および複号に使用し、NBDE を実現します。

クライアントおよびサーバーのコンポーネントはともに José ライブラリーを使用して、暗号化および複号の操作を実行します。

NBDE のプロビジョニングを開始すると、Tang サーバーの Clevis ピンは、Tang サーバーの、アドバタイズされている非対称鍵の一覧を取得します。もしくは、鍵が非対称であるため、Tang の公開鍵の一覧を帯域外に配布して、クライアントが Tang サーバーにアクセスしなくても動作できるようにします。このモードは オフラインプロビジョニング と呼ばれます。

Tang 用の Clevis ピンは、公開鍵のいずれかを使用して、固有で、暗号論的に強力な暗号鍵を生成します。この鍵を使用してデータを暗号化すると、この鍵は破棄されます。Clevis クライアントは、使いやすい場所に、このプロビジョニング操作で生成した状態を保存する必要があります。データを暗号化するこのプロセスは プロビジョニング手順 と呼ばれています。NBDE のプロビジョニング状態は、luksmeta パッケージを活用して LUKS ヘッダーに格納されます。

クライアントがそのデータにアクセスする準備ができると、プロビジョニング手順で生成したメタデータを読み込み、応答して暗号鍵を戻します。このプロセスは 復旧手順 と呼ばれます。

Clevis は、NBDE ではピンを使用して LUKS ボリュームをバインドしているため、自動的にロックが解除されます。バインドプロセスが正常に終了すると、提供されている Dracut アンロックを使用してディスクをアンロックできます。

ネットワーク接続が確立される前に起動する必要があるファイルシステムを含む /tmp ディレクトリー、/var ディレクトリー、および /usr/local/ ディレクトリーなどのすべての LUKS 暗号化デバイスは、root ボリューム とみなされます。さらに、/var/log/、var/log/audit/、または /opt など、ネットワークが起動する前に実行されるサービスが使用するすべてのマウントポイントは、ルートデバイスに切り替えた後に早期にマウントする必要があります。/etc/fstab ファイルに _netdev オプションがないため、root ボリュームを識別することもできます。

4.10.2. 暗号化クライアント (Clevis) のインストール

Clevis のプラグ可能なフレームワークとピンを暗号化されたボリューム（クライアント）を備えたマシンにインストールするには、root で以下のコマンドを入力します。

~]# yum install clevis

データを復号するには、clevis decrypt コマンドを使用して、暗号テキスト(JWE)を提供します。

~]$ clevis decrypt < JWE > PLAINTEXT

詳細は、CLI ヘルプを参照してください。

~]$ clevis
Usage: clevis COMMAND [OPTIONS]

  clevis decrypt      Decrypts using the policy defined at encryption time
  clevis encrypt http Encrypts using a REST HTTP escrow server policy
  clevis encrypt sss  Encrypts using a Shamir's Secret Sharing policy
  clevis encrypt tang Encrypts using a Tang binding server policy
  clevis encrypt tpm2 Encrypts using a TPM2.0 chip binding policy

~]$ clevis decrypt
Usage: clevis decrypt < JWE > PLAINTEXT

Decrypts using the policy defined at encryption time

~]$ clevis encrypt tang
Usage: clevis encrypt tang CONFIG < PLAINTEXT > JWE

Encrypts using a Tang binding server policy

This command uses the following configuration properties:

  url: <string>   The base URL of the Tang server (REQUIRED)

  thp: <string>   The thumbprint of a trusted signing key

  adv: <string>   A filename containing a trusted advertisement
  adv: <object>   A trusted advertisement (raw JSON)

Obtaining the thumbprint of a trusted signing key is easy. If you
have access to the Tang server's database directory, simply do:

    $ jose jwk thp -i $DBDIR/$SIG.jwk

Alternatively, if you have certainty that your network connection
is not compromised (not likely), you can download the advertisement
yourself using:

    $ curl -f $URL/adv > adv.jws

4.10.3. SELinux を Enforcing モードで有効にした Tang サーバーのデプロイメント

Red Hat Enterprise Linux 7.7 以降では、tangd_port_t SELinux タイプが提供され、Tang サーバーは、SELinux Enforcing モードで制限のあるサービスとしてデプロイできます。

前提条件

policycoreutils-python-utils パッケージおよび依存関係がインストールされている。

手順

tang パッケージとその依存関係をインストールするには、root で以下のコマンドを実行します。
```
~]# yum install tang
```
7500/tcp などの不要なポートを選択し、tangd サービスがそのポートにバインドできるようにします。
```
~]# semanage port -a -t tangd_port_t -p tcp 7500
```
ポートは一度に 1 つのサービスでのみ使用できるため、すでに使用しているポートを使用しようとすると、ValueError: Port already defined というエラーメッセージが表示されます。

ファイアウォールのポートを開きます。

~]# firewall-cmd --add-port=7500/tcp
~]# firewall-cmd --runtime-to-permanent

systemd を使用して tangd サービスを有効にします。

~]# systemctl enable tangd.socket
Created symlink from /etc/systemd/system/multi-user.target.wants/tangd.socket to /usr/lib/systemd/system/tangd.socket.

オーバーライドファイルを作成します。
```
~]# systemctl edit tangd.socket
```
以下のエディター画面で、/etc/systemd/system/tangd.socket.d/ ディレクトリーにある空の override.conf ファイルを開き、以下の行を追加して Tang サーバーのデフォルトポートを、80 から以前に取得した番号に変更します。
```
[Socket]
ListenStream=
ListenStream=7500
```
ファイルを保存して、エディターを終了します。
変更した設定を再読み込みし、tangd サービスを起動します。
```
~]# systemctl daemon-reload
```

設定が機能していることを確認します。

~]# systemctl show tangd.socket -p Listen
Listen=[::]:7500 (Stream)

tangd サービスを起動します。
```
~]# systemctl start tangd.socket
```

tangd は systemd ソケットアクティベーションメカニズムを使用するため、サーバーは最初の接続を受け取るとすぐに起動します。最初の起動時に、一組の暗号鍵が自動的に生成されます。

キーの手動生成などの暗号化操作を実行するには、jose ユーティリティーを使用します。詳細は、jose -h コマンドを入力するか、man ページの jose (1) を参照してください。

例4.4 Tang 鍵のローテーション

鍵を定期的に変更することが重要です。鍵を変更するのに適した間隔は、アプリケーション、鍵サイズ、および組織のポリシーにより異なります。一般的な推奨事項はCryptographic Key Length Recommendation ページを参照してください。

キーをローテーションするには、キーデータベースディレクトリー（通常は /var/db/tang ）の新しいキーの生成から開始します。たとえば、以下のコマンドを使用して、新しい署名を作成し、鍵を交換します。

~]# DB=/var/db/tang
~]# jose jwk gen -i '{"alg":"ES512"}' -o $DB/new_sig.jwk
~]# jose jwk gen -i '{"alg":"ECMR"}' -o $DB/new_exc.jwk

古いキーの名前を先頭に . に変更して、アドバタイズメントから非表示にします。以下の例のファイル名は、鍵データベースディレクトリーに実在する固有のファイル名とは異なります。

~]# mv $DB/old_sig.jwk $DB/.old_sig.jwk
~]# mv $DB/old_exc.jwk $DB/.old_exc.jwk

Tang は、直ちにすべての変更を適用します。再起動は必要ありません。

この時点で、新しいクライアントバインディングは新しい鍵を選択し、以前のクライアントは古い鍵を使用し続けます。すべてのクライアントが新しい鍵を使用することを確認すると、古い鍵を削除できます。

警告

クライアントが使用している最中に古い鍵を削除すると、データが失われる場合があります。

4.10.3.1. 高可用性システムのデプロイメント

Tang は、高可用性デプロイメントを構築する方法を 2 つ提供します。

クライアントの冗長性 (推奨)
クライアントは、複数の Tang サーバーにバインドする機能を使用して設定する必要があります。この設定では、各 Tang サーバーは独自の鍵を持ち、クライアントはこれらのサーバーのサブセットに連絡することで復号化できます。Clevis は、sss プラグインを使用してこのワークフローをすでにサポートしています。
この設定の詳細については、以下の man ページを参照してください。
- tang (8)、High Availability セクション
- clevis (1) の Shamir's Secret Sharing セクション
- clevis-encrypt-sss(1)
Red Hat は、高可用性のデプロイメントにこの方法を推奨します。
鍵の共有
冗長性を確保するために、Tang のインスタンスは複数デプロイできます。2 番目以降のインスタンスを設定するには、tang パッケージをインストールし、SSH 経由で rsync を使用して鍵ディレクトリーを新規ホストにコピーします。鍵を共有すると鍵への不正アクセスのリスクが高まり、追加の自動化インフラストラクチャーが必要になるため、Red Hat はこの方法を推奨していません。

4.10.4. Tang を使用する NBDE システムへの暗号化クライアントのデプロイメント

前提条件

Clevis フレームワークがインストールされている。「暗号化クライアント (Clevis) のインストール」を参照
Tang サーバーまたはそのダウンロードされた広告が利用可能です。「SELinux を Enforcing モードで有効にした Tang サーバーのデプロイメント」を参照

手順

Clevis 暗号化クライアントを Tang サーバーにバインドするには、clevis encrypt tang サブコマンドを使用します。

~]$ clevis encrypt tang '{"url":"http://tang.srv"}' < PLAINTEXT > JWE
The advertisement contains the following signing keys:

_OsIk0T-E2l6qjfdDiwVmidoZjA

Do you wish to trust these keys? [ynYN] y

先ほどの例の http://tang.srv の URL を、tang がインストールされているサーバーの URL と一致するように変更します。JWE 出力ファイルには、暗号化された暗号文が含まれます。この暗号文は、PLAINTEXT 入力ファイルから読み込まれます。

データを復号するには、clevis decrypt コマンドを使用して、暗号テキスト(JWE)を提供します。

~]$ clevis decrypt < JWE > PLAINTEXT

詳細は、man ページの clevis-encrypt-tang (1) を参照するか、同梱の CLI ヘルプを使用します。

~]$ clevis
Usage: clevis COMMAND [OPTIONS]

  clevis decrypt      Decrypts using the policy defined at encryption time
  clevis encrypt http Encrypts using a REST HTTP escrow server policy
  clevis encrypt sss  Encrypts using a Shamir's Secret Sharing policy
  clevis encrypt tang Encrypts using a Tang binding server policy
  clevis luks bind    Binds a LUKSv1 device using the specified policy
  clevis luks unlock  Unlocks a LUKSv1 volume

~]$ clevis decrypt
Usage: clevis decrypt < JWE > PLAINTEXT

Decrypts using the policy defined at encryption time

~]$ clevis encrypt tang
Usage: clevis encrypt tang CONFIG < PLAINTEXT > JWE

Encrypts using a Tang binding server policy

This command uses the following configuration properties:

  url: <string>   The base URL of the Tang server (REQUIRED)

  thp: <string>   The thumbprint of a trusted signing key

  adv: <string>   A filename containing a trusted advertisement
  adv: <object>   A trusted advertisement (raw JSON)

Obtaining the thumbprint of a trusted signing key is easy. If you
have access to the Tang server's database directory, simply do:

    $ jose jwk thp -i $DBDIR/$SIG.jwk

Alternatively, if you have certainty that your network connection
is not compromised (not likely), you can download the advertisement
yourself using:

    $ curl -f $URL/adv > adv.jws

4.10.5. TPM 2.0 ポリシーを使用した暗号化クライアントのデプロイメント

64 ビット Intel または 64 ビットの AMD アーキテクチャーのシステムでは、Trusted Platform Module 2.0 (TPM 2.0)チップを使用して暗号化するクライアントをデプロイするには、JSON 設定オブジェクトの形式で唯一の引数を指定して clevis encrypt tpm2 サブコマンドを使用します。

~]$ clevis encrypt tpm2 '{}' < PLAINTEXT > JWE

別の階層、ハッシュ、および鍵アルゴリズムを選択するには、以下のように、設定プロパティーを指定します。

~]$ clevis encrypt tpm2 '{"hash":"sha1","key":"rsa"}' < PLAINTEXT > JWE

データを復号するには、暗号文 (JWE) を提供します。

~]$ clevis decrypt < JWE > PLAINTEXT

ピンは、PCR (Platform Configuration Registers) 状態へのデータのシーリングにも対応します。このように、PCP ハッシュ値が、シーリング時に使用したポリシーと一致する場合にのみ、データのシーリングを解除できます。

たとえば、SHA1 バンクに対して、インデックス 0 および 1 の PCR にデータをシールするには、以下を行います。

~]$ clevis encrypt tpm2 '{"pcr_bank":"sha1","pcr_ids":"0,1"}' < PLAINTEXT > JWE

詳細と可能な設定プロパティーの一覧は、man ページの clevis-encrypt-tpm2 (1) を参照してください。

4.10.6. root ボリュームの手動登録の設定

LUKS で暗号化した既存の root ボリュームを自動的にアンロックするには、clevis-luks サブパッケージをインストールし、clevis luks bind コマンドを使用してボリュームを Tang サーバーにバインドします。

~]# yum install clevis-luks

~]# clevis luks bind -d /dev/sda tang '{"url":"http://tang.srv"}'
The advertisement contains the following signing keys:

_OsIk0T-E2l6qjfdDiwVmidoZjA

Do you wish to trust these keys? [ynYN] y
You are about to initialize a LUKS device for metadata storage.
Attempting to initialize it may result in data loss if data was
already written into the LUKS header gap in a different format.
A backup is advised before initialization is performed.

Do you wish to initialize /dev/sda? [yn] y
Enter existing LUKS password:

このコマンドは、以下の 4 つの手順を実行します。

LUKS マスター鍵と同じエントロピーを使用して、新しい鍵を作成します。
Clevis で新しい鍵を暗号化します。
LUKS ヘッダーに Clevis JWE オブジェクトを LUKSMeta で格納します。
LUKS を使用する新しい鍵を有効にします。

このディスクは、Clevis ポリシーだけでなく、既存のパスワードでもロック解除ができるようになりました。詳細は、man ページの clevis-luks-bind (1) を参照してください。

注記

バインド手順では、空き LUKS パスワードスロットが少なくとも 1 つあることが前提となっています。clevis luks bind コマンドは、スロットの 1 つを取ります。

Clevis JWE オブジェクトが LUKS ヘッダーに正常に配置されていることを確認するには、luksmeta show コマンドを使用します。

~]# luksmeta show -d /dev/sda
0   active empty
1   active cb6e8904-81ff-40da-a84a-07ab9ab5715e
2 inactive empty
3 inactive empty
4 inactive empty
5 inactive empty
6 inactive empty
7 inactive empty

システムの起動プロセスの初期段階でディスクバインディングを処理するようにするには、インストール済みのシステムで次のコマンドを実行します。

~]# yum install clevis-dracut
~]# dracut -f --regenerate-all

重要

(DHCP を使用しない) 静的な IP 設定を持つクライアントに NBDE を使用するには、以下のように、手動でネットワーク設定を dracut ツールに渡します。

~]# dracut -f --regenerate-all --kernel-cmdline "ip=192.0.2.10 netmask=255.255.255.0 gateway=192.0.2.1 nameserver=192.0.2.45"

または、静的ネットワーク情報を使用して、/etc/dracut.conf.d/ ディレクトリーに .conf ファイルを作成します。以下に例を示します。

~]# cat /etc/dracut.conf.d/static_ip.conf
kernel_cmdline="ip=10.0.0.103 netmask=255.255.252.0 gateway=10.0.0.1 nameserver=10.0.0.1"

初期 RAM ディスクイメージを再生成します。

~]# dracut -f --regenerate-all

詳細は、man ページの dracut.cmdline (7) を参照してください。

4.10.7. キックスタートを使用した自動登録の設定

Clevis は、キックスタートと統合して、登録プロセスを完全に自動化にできます。

一時パスワードを使用して、/boot 以外のすべてのマウントポイントで LUKS 暗号化が有効になっているディスクを分割するように、キックスタートに指示します。パスワードは、登録プロセスの手順に使用するための一時的なものです。

part /boot --fstype="xfs" --ondisk=vda --size=256
part / --fstype="xfs" --ondisk=vda --grow --encrypted --passphrase=temppass

OSPP 準拠のシステムには、より複雑な設定が必要であることに注意してください。次に例を示します。

part /boot --fstype="xfs" --ondisk=vda --size=256
part / --fstype="xfs" --ondisk=vda --size=2048 --encrypted --passphrase=temppass
part /var --fstype="xfs" --ondisk=vda --size=1024 --encrypted --passphrase=temppass
part /tmp --fstype="xfs" --ondisk=vda --size=1024 --encrypted --passphrase=temppass
part /home --fstype="xfs" --ondisk=vda --size=2048 --grow --encrypted --passphrase=temppass
part /var/log --fstype="xfs" --ondisk=vda --size=1024 --encrypted --passphrase=temppass
part /var/log/audit --fstype="xfs" --ondisk=vda --size=1024 --encrypted --passphrase=temppass

関連する Clevis パッケージを %packages セクションに追加してインストールします。
```
%packages
clevis-dracut
%end
```
clevis luks bind を呼び出して、%post セクションでバインディングを実行します。その後、一時パスワードを削除します。
```
%post
clevis luks bind -f -k- -d /dev/vda2 \
tang '{"url":"http://tang.srv","thp":"_OsIk0T-E2l6qjfdDiwVmidoZjA"}' \ <<< "temppass"
cryptsetup luksRemoveKey /dev/vda2 <<< "temppass"
%end
```
上記の例では、バインディングの設定で、Tang サーバーで信頼するサムプリントを指定することで、バインディングを完全に非対話にします。
Tang サーバーの代わりに TPM 2.0 ポリシーを使用する場合は、同様の手順を使用できます。

キックスタートのインストールに関する詳細は、Red Hat Enterprise Linux 7 Installation Guide を参照してください。Linux Unified Key Setup-on-disk-format (LUKS) の詳細は、「LUKS ディスクの暗号化の使用」を参照してください。

4.10.8. リムーバブルストレージデバイスの自動ロック解除の設定

USB ドライブなど、LUKS で暗号化したリムーバブルストレージデバイスを自動的にアンロックするには、clevis-udisks2 パッケージをインストールします。

~]# yum install clevis-udisks2

システムを再起動してから、「root ボリュームの手動登録の設定」の説明に従って、clevis luks bind コマンドを使用したバインディング手順を実行します。以下に例を示します。

~]# clevis luks bind -d /dev/sdb1 tang '{"url":"http://tang.srv"}'

LUKS で暗号化したリムーバブルデバイスは、GNOME デスクトップセッションで自動的にアンロックできるようになりました。Clevis ポリシーにバインドされているデバイスは、clevis luks unlock コマンドでロックを解除することもできます。

~]# clevis luks unlock -d /dev/sdb1

Tang サーバーの代わりに TPM 2.0 ポリシーを使用する場合は、同様の手順を使用できます。

4.10.9. ブート時に非 root ボリュームのロックを自動解除する設定

NBDE を使用して、LUKS で暗号化した非 root ボリュームをアンロックするには、以下の手順を行います。

clevis-systemd パッケージをインストールします。
```
~]# yum install clevis-systemd
```

Clevis のアンロックサービスを有効にします。

~]# systemctl enable clevis-luks-askpass.path
Created symlink from /etc/systemd/system/remote-fs.target.wants/clevis-luks-askpass.path to /usr/lib/systemd/system/clevis-luks-askpass.path.

「root ボリュームの手動登録の設定」の説明に従って、clevis luks bind コマンドを使用したバインディング手順を実行します。
システムの起動時に暗号化されたブロックデバイスを設定するには、_netdev オプションを指定して対応する行を /etc/crypttab 設定ファイルに追加します。詳細は、crypttab (5) man ページを参照してください。
/etc/fstab ファイルでアクセス可能なファイルシステムの一覧にボリュームを追加します。この設定ファイルに _netdev オプションを使用します。詳細は、man ページの fstab (5) を参照してください。

4.10.10. NBDE ネットワークでの仮想マシンのデプロイ

clevis luks bind コマンドは、LUKS マスターキーを変更しません。これは、仮想マシンまたはクラウド環境で使用する、LUKS で暗号化したイメージを作成する場合に、このイメージを実行するすべてのインスタンスがマスター鍵を共有することを意味します。これにはセキュリティーの観点で大きな問題があるため、常に回避する必要があります。

これは、Clevis の制限ではなく、LUKS の設計原理です。クラウドに暗号化された root ボリュームが必要な場合は、クラウドの Red Hat Enterprise Linux の各インスタンスにインストールプロセスを実行できるようにする (通常はキックスタートを使用) 必要があります。このイメージは、LUKS マスター鍵を共有しなければ共有できません。

仮想化環境に自動アンロックをデプロイする場合は、キックスタートファイルを使用して lorax、virt-install などのシステムを使用すること (「キックスタートを使用した自動登録の設定」を参照)、または暗号化した各仮想マシンに固有のマスター鍵があるようにする別の自動プロビジョニングツールを使用することを Red Hat は強く推奨します。

4.10.11. NBDE を使用してクラウド環境に自動的に登録可能な仮想マシンイメージの構築

自動登録可能な暗号化イメージをクラウド環境にデプロイすると、特有の課題が発生する可能性があります。他の仮想化環境と同様に、LUKS マスター鍵を共有しないように、1 つのイメージから起動するインスタンス数を減らすことが推奨されます。

したがって、ベストプラクティスは、どのパブリックリポジトリーでも共有されず、限られたインスタンスのデプロイメントのベースを提供するように、イメージをカスタマイズすることです。作成するインスタンスの数は、デプロイメントのセキュリティーポリシーで定義する必要があります。また、LUKS マスター鍵の攻撃ベクトルに関連するリスク許容度に基づいて決定する必要があります。

LUKS に対応する自動デプロイメントを構築するには、Lorax、virt-install などのシステムとキックスタートファイルを一緒に使用し、イメージ構築プロセス中にマスター鍵の一意性を確保する必要があります。

クラウド環境では、ここで検討する 2 つの Tang サーバーデプロイメントオプションが利用できます。まず、クラウド環境そのものに Tang サーバーをデプロイできます。もしくは、2 つのインフラストラクチャー間で VPN リンクを使用した独立したインフラストラクチャーで、クラウドの外に Tang サーバーをデプロイできます。

クラウドに Tang をネイティブにデプロイすると、簡単にデプロイできます。ただし、別のシステムの暗号文のデータ永続化層でインフラストラクチャーを共有します。Tang サーバーの秘密鍵および Clevis メタデータは、同じ物理ディスクに保存できる場合があります。この物理ディスクでは、暗号文データへのいかなる不正アクセスが可能になります。

重要

このため、Red Hat は、データを保存する場所と、Tang が実行しているシステムを、物理的に分離させることを強く推奨します。クラウドと Tang サーバーを分離することで、Tang サーバーの秘密鍵が、Clevis メタデータと誤って結合することがないようにします。さらに、これにより、クラウドインフラストラクチャーが危険にさらされている場合に、Tang サーバーのローカル制御を提供します。

4.10.12. 関連情報

ナレッジベースの記事How to set up Network Bound Disk Encryption with multiple LUKS devices (Clevis+Tang unlocking)

詳細は、以下の man ページを参照してください。

tang(8)
clevis(1)
jose(1)
clevis-luks-unlockers(1)
tang-nagios(1)

4.11. AIDEで整合性の確認

AIDE(Advanced Intrusion Detection Environment)は、システム上でファイルのデータベースを作成し、そのデータベースを使用してファイルの整合性を確保し、システムの侵入を検出するユーティリティーです。

4.11.1. AIDEのインストール

aide パッケージをインストールするには、root で以下のコマンドを入力します。

~]# yum install aide

初期データベースを生成するには、root で以下のコマンドを入力します。

~]# aide --init

AIDE, version 0.15.1

### AIDE database at /var/lib/aide/aide.db.new.gz initialized.

注記

デフォルト設定では、aide --init コマンドは、/etc/aide.conf ファイルで定義されているディレクトリーとファイルのセットのみをチェックします。AIDE データベースに追加のディレクトリーまたはファイルを含め、監視パラメーターを変更するには、それに応じて /etc/aide.conf を編集します。

データベースの使用を開始するには、初期データベースファイル名から .new 部分文字列を削除します。

~]# mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

AIDE データベースの場所を変更するには、/etc/aide.conf ファイルを編集し、DBDIR 値を変更します。セキュリティーを強化するために、データベース、設定、および /usr/sbin/aide バイナリーファイルを読み取り専用メディアなどの安全な場所に保存します。

重要

AIDE データベースの場所を変更した後に SELinux が拒否されるのを防ぐため、SELinux ポリシーを適宜更新してください。詳細は、SELinux User's and Administrator's Guide を参照してください。

4.11.2. 整合性確認の実行

手動チェックを開始するには、root で以下のコマンドを入力します。

~]# aide --check
AIDE 0.15.1 found differences between database and filesystem!!
Start timestamp: 2017-03-30 14:12:56

Summary:
  Total number of files:	147173
  Added files:			1
  Removed files:		0
  Changed files:		2
...

少なくとも、AIDE は週次スキャンを実行するように設定する必要があります。AIDE は毎日実行する必要があります。たとえば、cron を使用して 4:05 am に AIDE の毎日の実行をスケジュールするには（システム管理者のガイドの Automating System Tasks の章を参照）、以下の行を /etc/crontab に追加します。

05 4 * * * root /usr/sbin/aide --check

4.11.3. AIDE データベースの更新

パッケージの更新や設定ファイルの調整など、システムの変更を確認したら、ベースライン AIDE データベースを更新します。

~]# aide --update

aide --update コマンドは、/var/lib/aide/aide.db.new.gz データベースファイルを作成します。整合性チェックに使用を開始するには、ファイル名から .new サブストリングを削除します。

4.11.4. 関連情報

AIDE の詳細については、以下のドキュメントを参照してください。

aide (1) の man ページ
aide.conf (5) の man ページ
Guide to the Secure Configuration of Red Hat Enterprise Linux 7 (OpenSCAP Security Guide): Verify Integrity with AIDE

4.12. USBGuardの使用

USBGuard ソフトウェアフレームワークは、デバイス属性に基づく基本的なホワイトリスト機能およびブラックリスト機能を実装することにより、侵入型 USB デバイスに対するシステム保護を提供します。ユーザー定義のポリシーを適用するために、USBGuard は Linux カーネルの USB デバイス認証機能を使用します。USBGuard フレームワークは、以下のコンポーネントを提供します。

動的対話とポリシー施行のためのプロセス間通信 (IPC) インターフェイスを持つデーモンコンポーネント。
実行中の USBGuard インスタンスと対話するコマンドラインインターフェイス。
USB デバイス認証ポリシーを記述するルール言語
共有ライブラリーに実装されているデーモンコンポーネントと対話する C++ API

4.12.1. USBGuardのインストール

usbguard パッケージをインストールするには、root で以下のコマンドを入力します。

~]# yum install usbguard

初期ルールセットを作成するには、root で以下のコマンドを入力します。

~]# usbguard generate-policy > /etc/usbguard/rules.conf

注記

USBGuard ルールセットをカスタマイズするには、/etc/usbguard/rules.conf ファイルを編集します。詳細は、usbguard-rules.conf (5) の man ページを参照してください。使用例は「ルール言語を使って独自のポリシーを作成する」を参照してください。

USBGuard デーモンを起動するには、root で以下のコマンドを入力します。

~]# systemctl start usbguard.service
~]# systemctl status usbguard
● usbguard.service - USBGuard daemon
   Loaded: loaded (/usr/lib/systemd/system/usbguard.service; disabled; vendor preset: disabled)
   Active: active (running) since Tue 2017-06-06 13:29:31 CEST; 9s ago
     Docs: man:usbguard-daemon(8)
 Main PID: 4984 (usbguard-daemon)
   CGroup: /system.slice/usbguard.service
           └─4984 /usr/sbin/usbguard-daemon -k -c /etc/usbguard/usbguard-daem...

システムの起動時に USBGuard が自動的に開始するようにするには、root で以下のコマンドを使用します。

~]# systemctl enable usbguard.service
Created symlink from /etc/systemd/system/basic.target.wants/usbguard.service to /usr/lib/systemd/system/usbguard.service.

USBGuard が認識するすべての USB デバイスを一覧表示するには、root で次のコマンドを実行します。

~]# usbguard list-devices
1: allow id 1d6b:0002 serial "0000:00:06.7" name "EHCI Host Controller" hash "JDOb0BiktYs2ct3mSQKopnOOV2h9MGYADwhT+oUtF2s=" parent-hash "4PHGcaDKWtPjKDwYpIRG722cB9SlGz9l9Iea93+Gt9c=" via-port "usb1" with-interface 09:00:00
...
6: block id 1b1c:1ab1 serial "000024937962" name "Voyager" hash "CrXgiaWIf2bZAU+5WkzOE7y0rdSO82XMzubn7HDb95Q=" parent-hash "JDOb0BiktYs2ct3mSQKopnOOV2h9MGYADwhT+oUtF2s=" via-port "1-3" with-interface 08:06:50

デバイスがシステムと対話することを許可するには、allow-device オプションを使用します。

~]# usbguard allow-device 6

デバイスの認証を解除してシステムから削除するには、reject-device オプションを使用します。デバイスの認証を解除するには、block-device オプションを指定して usbguard コマンドを使用します。

~]# usbguard block-device 6

USBGuard では、block および reject は以下の意味で使用されます。

block - 今は、このデバイスとはやりとりしない
reject - このデバイスは存在しないものとして無視する

usbguard コマンドのすべてのオプションを表示するには、--help ディレクティブを指定して入力します。

~]$ usbguard --help

4.12.2. ホワイトリストおよびブラックリストの作成

usbguard-daemon.conf ファイルは、コマンドラインオプションを解析した後に usbguard デーモンによって読み込まれ、デーモンのランタイムパラメーターを設定するために使用されます。デフォルトの設定ファイル(/etc/usbguard/usbguard-daemon.conf)をオーバーライドするには、-c コマンドラインオプションを使用します。詳細は、usbguard-daemon (8)の man ページを参照してください。

ホワイトリストまたはブラックリストを作成するには、usbguard-daemon.conf ファイルを編集し、以下のオプションを使用します。

USBGuard 設定ファイル

RuleFile=<path>

usbguard デーモンは、このファイルを使用して、そこからポリシールールセットを読み込み、IPC インターフェイスを介して受信した新しいルールを書き込みます。

IPCAllowedUsers=<username> [<username> ...]

デーモンが IPC 接続を受け入れるユーザー名のスペース区切りのリスト。

IPCAllowedGroups=<groupname> [<groupname> ...]

デーモンが IPC 接続を受け入れるグループ名のスペース区切りのリスト。

IPCAccessControlFiles=<path>

IPC アクセス制御ファイルを保持するディレクトリーへのパス。

ImplicitPolicyTarget=<target>

ポリシーのどのルールにも一致しないデバイスを処理する方法。許容される値は allow、block、および reject です。

PresentDevicePolicy=<policy>

デーモンの起動時にすでに接続されているデバイスを処理する方法:

allow - 存在するデバイスをすべて認証する
block - 存在するデバイスの認証をすべて解除する
reject - 存在するデバイスをすべて削除する
keep - 内部ステータスの同期してそのままにする
apply-policy - 存在するすべてのデバイスに対してルールセットを評価する

PresentControllerPolicy=<policy>

デーモンの起動時にすでに接続されている USB コントローラーを処理する方法:

allow - 存在するデバイスをすべて認証する
block - 存在するデバイスの認証をすべて解除する
reject - 存在するデバイスをすべて削除する
keep - 内部ステータスの同期してそのままにする
apply-policy - 存在するすべてのデバイスに対してルールセットを評価する

例4.5 USBGuard 設定

以下の設定ファイルは、usbguard デーモンが /etc/usbguard/rules.conf ファイルからルールをロードするように順序付け、usbguard グループのユーザーのみが IPC インターフェイスを使用できるようにします。

RuleFile=/etc/usbguard/rules.conf
IPCAccessControlFiles=/etc/usbguard/IPCAccessControl.d/

IPC アクセス制御リスト(ACL)を指定するには、usbguard add-user または usbguard remove-user コマンドを使用します。詳細は usbguard (1) を参照してください。この例では、usbguard グループのユーザーが USB デバイス承認状態の変更、USB デバイスの一覧表示、例外イベントのリッスン、USB 認証ポリシーの一覧表示を許可するには、root で次のコマンドを実行します。

~]# usbguard add-user -g usbguard --devices=modify,list,listen --policy=list --exceptions=listen

重要

デーモンは、USBGuard パブリック IPC インターフェイスを提供します。Red Hat Enterprise Linux では、このインターフェイスへのアクセスはデフォルトで root ユーザーのみに制限されます。IPC インターフェイスへのアクセスを制限するには、IPCAccessControlFiles オプション (推奨)、IPCAllowedUsers オプション、および IPCAllowedGroups オプションを設定することを検討してください。ACL を未設定のままにしないでください。設定しないと、すべてのローカルユーザーに IPC インターフェイスが公開され、USB デバイスの認証状態を操作して USBGuard ポリシーを変更できるようになります。

詳細は、usbguard-daemon.conf (5) man ページの IPC Access Control セクションを参照してください。

4.12.3. ルール言語を使って独自のポリシーを作成する

usbguard デーモンは、一連のルールで定義されたポリシーに基づいて USB デバイスを承認するかどうかを決定します。USB デバイスがシステムに挿入されると、デーモンは既存のルールを順次スキャンし、一致するルールが見つかると、ルールのターゲットに基づいて、デバイスを承認 (許可)、非承認 (ブロック)、または削除 (拒否) します。一致するルールが見つからない場合、決定は暗黙のデフォルトターゲットに基づいて行われます。この暗黙のデフォルトとは、ユーザーが決定を下すまでデバイスをブロックすることです。

ルール言語の文法は以下のようになります。

rule ::= target device_id device_attributes conditions.

target ::= "allow" | "block" | "reject".

device_id ::= "*:*" | vendor_id ":*" | vendor_id ":" product_id.

device_attributes ::= device_attributes | attribute.
device_attributes ::= .

conditions ::= conditions | condition.
conditions ::= .

ターゲット、デバイス仕様、デバイス属性などのルール言語の詳細は、usbguard-rules.conf (5) の man ページを参照してください。

例4.6 USBguard のサンプルポリシー

USB 大容量ストレージデバイスを許可し、それ以外をすべてブロックする

このポリシーは、単なる大容量ストレージデバイスではないあらゆるデバイスをブロックします。USB フラッシュディスクにキーボードインターフェイスが隠されているデバイスはブロックされます。大容量ストレージインターフェイスが 1 つあるデバイスのみが、オペレーティングシステムと対話することを許可されます。ポリシーは、以下のような 1 つのルールで設定されます。

allow with-interface equals { 08:*:* }

ブロックルールがないため、ブロックは暗黙のうちに行われます。USBGuard イベントをリッスンするデスクトップアプレットは、デバイスに対して暗黙的なターゲットが選択されているかどうかをユーザーに尋ねることができるため、暗黙的なブロックはデスクトップユーザーにとって便利です。

特定の Yubikey デバイスを特定のポート経由で接続できるようにする

そのポートの他のすべてを拒否します。

allow 1050:0011 name "Yubico Yubikey II" serial "0001234567" via-port "1-2" hash "044b5e168d40ee0245478416caf3d998"
reject via-port "1-2"

インターフェイスの組み合わせに不審な点があるデバイスは排除する

キーボードやネットワークインターフェイスを実装した USB フラッシュディスクは非常に疑わしいものです。次の一連のルールは、USB フラッシュディスクを許可し、追加の疑わしいインターフェイスを備えたデバイスを明示的に拒否するポリシーを形成します。

allow with-interface equals { 08:*:* }
reject with-interface all-of { 08:*:* 03:00:* }
reject with-interface all-of { 08:*:* 03:01:* }
reject with-interface all-of { 08:*:* e0:*:* }
reject with-interface all-of { 08:*:* 02:*:* }

注記

ブラックリストは間違ったアプローチであり、あるデバイスだけをブラックリストに入れ、残りを許可するということはしないでください。上記のポリシーは、ブロッキングが暗黙のデフォルトであることを前提としています。"不良" と見なされる一連のデバイスを拒否することは、そのようなデバイスへのシステムの露出を可能な限り制限するための良いアプローチです。

キーボードのみの USB デバイスを許可

以下のルールは、キーボードインターフェイスを持つ USB 機器がすでに許可されていない場合にのみ、キーボードのみの USB 機器を許可するものです。

allow with-interface one-of { 03:00:01 03:01:01 } if !allowed-matches(with-interface one-of { 03:00:01 03:01:01 })

usbguard generate-policy コマンドを使用して最初のポリシーを生成したら、/etc/usbguard/rules.conf を編集して USBGuard ポリシールールをカスタマイズします。

~]$ usbguard generate-policy > rules.conf
~]$ vim rules.conf

更新されたポリシーをインストールし、変更を有効にするには、次のコマンドを使用します。

~]# install -m 0600 -o root -g root rules.conf /etc/usbguard/rules.conf

4.12.4. 関連情報

USBGuard の詳細は、以下のドキュメントを参照してください。

usbguard (1) の man ページ
usbguard-rules.conf(5) man page
usbguard-daemon(8) man page
usbguard-daemon.conf(5) man page
USBGuard ホームページ

4.13. TLS 設定の強化

TLS (Transport Layer Security)は、ネットワーク通信のセキュリティーを保護するために使用される暗号化プロトコルです。優先する 鍵交換プロトコル、認証方法、および暗号化アルゴリズムを設定してシステムのセキュリティー設定を強化する際には、対応するクライアントの範囲が広ければ広いほど、セキュリティーのレベルが低くなることを認識しておく必要があります。反対に、セキュリティー設定を厳密にすると、クライアントとの互換性が制限され、システムからロックアウトされるユーザーが出てくる可能性もあります。可能な限り厳密な設定を目指し、互換性に必要な場合に限り、設定を緩めるようにしてください。

Red Hat Enterprise Linux 7 に含まれるライブラリーが提供するデフォルト設定は、ほとんどのデプロイメントで十分に安全である点に留意してください。TLS 実装は、可能な場合は安全なアルゴリズムを使用しますが、レガシークライアントまたはサーバーへの接続を防止しません。セキュリティーが保護されたアルゴリズムまたはプロトコルに対応しないレガシーなクライアントまたはサーバーの接続が期待できないまたは許可されない場合に、厳密なセキュリティー要件の環境で、このセクションで説明されている強化された設定を適用します。

4.13.1. 有効にするアルゴリズムの選択

選択して設定する必要のあるコンポーネントがいくつかあります。以下の各項目は、結果として得られる設定の堅牢性 (および結果的にはクライアントでのサポートレベル)、またはソリューションがシステムに与える計算上の要求に直接影響します。

プロトコルのバージョン

最新バージョンの TLS は、最高のセキュリティーメカニズムを提供します。古いバージョンの TLS （または SSL）のサポートを含めるという面倒な理由がない限り、システムが最新バージョンの TLS のみを使用して接続をネゴシエートできるようにします。

SSL バージョン 2 または 3 を使用したネゴシエーションを許可しないでください。これらのバージョンは両方とも、深刻なセキュリティーの脆弱性があります。TLS バージョン 1.0 以降を使用したネゴシエーションのみを許可します。TLS の現行バージョン 1.2 が常に推奨されます。

注記

現在、TLS のすべてのバージョンのセキュリティーは、 TLS 拡張機能、特定の暗号（以下を参照）、およびその他の回避策の使用に依存することに注意してください。すべての TLS 接続ピアは、安全な再ネゴシエーション表示(RFC 5746)を実装する必要があり、圧縮をサポートしてはならず、CBCモード暗号(Lucky Thirteen 攻撃)に対するタイミング攻撃の緩和策を実装する必要があります。TLS 1.0 クライアントは、レコード分割を追加で実装する必要があります(BEAST 攻撃に対する回避策)。TLS 1.2 は、既知の問題のない AES-GCM、AES-CCM、または Camellia-GCM などの Authenticated Encryption with Associated Data (AEAD)モード暗号をサポートします。ここで述べた緩和策はすべて、Red Hat Enterprise Linux に含まれる暗号ライブラリーに実装されています。

プロトコルのバージョンと推奨される使用方法の概要については、表4.6「プロトコルのバージョン」を参照してください。

表4.6 プロトコルのバージョン
プロトコルのバージョン	推奨される使用方法
`SSL v2`	使用しないでください。深刻なセキュリティー上の脆弱性があります。
`SSL v3`	使用しないでください。深刻なセキュリティー上の脆弱性があります。
`TLS 1.0`	必要に応じて相互運用性の目的で使用します。相互運用性を保証する方法で緩和できない既知の問題があるため、緩和策はデフォルトで有効になっていません。最新の暗号スイートには対応しません。
`TLS 1.1`	必要に応じて相互運用性の目的で使用します。既知の問題はありませんが、Red Hat Enterprise Linux のすべての `TLS` 実装に含まれるプロトコル修正に依存します。最新の暗号スイートには対応しません。
`TLS 1.2`	推奨されるバージョン。最新の `AEAD` 暗号スイートに対応します。

Red Hat Enterprise Linux の一部のコンポーネントは、TLS 1. 1 または 1.2 のサポートを提供していても、TLS 1.0 を使用するように設定されて い ます。これは、最新バージョンの TLS をサポートしていない可能性のある外部サービスとの最高レベルの相互運用性を実現しようとする試みによって動機付けされます。相互運用性の要件に応じて、利用可能な最高バージョンの TLS を有効にします。

重要

SSL v3 の使用は推奨されません。ただし、安全ではなく、一般的な使用には適していないと考えられているにもかかわらず、SSL v3 を有効にしておく必要があります。暗号化をサポートしていないサービスを使用している場合でも、stunnel を使用して通信を安全に暗号化する方法については、「stunnel の使用」を参照してください。

暗号化スイート

旧式で、安全ではない 暗号化スイート ではなく、最近の、より安全なものを使用してください。暗号化スイートの eNULL および aNULL は、暗号化や認証を提供しないため、常に無効にしてください。重大な欠点がある RC4 または HMAC-MD5 をベースとする暗号化スイートも可能であれば、無効にする必要があります。いわゆるエクスポート暗号化スイートも同様です。エクスポート暗号化スイートは意図的に弱くなっているため、侵入が容易になっています。

128 ビット未満のセキュリティーしか提供しない暗号化スイートでは直ちにセキュリティーが保護されなくなるというわけではありませんが、使用できる期間が短いため考慮すべきではありません。アルゴリズムが 128 ビット以上のセキュリティーを使用している場合は、少なくとも数年間は解読不可能であることが期待されているため、強く推奨されます。3DES 暗号は 168 ビットの使用を公開しますが、実際には 112 ビットのセキュリティーを提供します。

サーバーの鍵が危険にさらされた場合でも、暗号化したデータの機密性を保証する (完全な) 前方秘匿性 (PFS) に対応する暗号スイートを常に優先します。このルールにより、高速 RSA 鍵交換は除外されますが、ECDHE および DHE を使用できます。この 2 つのうち、ECDHE が高速であるため、選択が推奨されます。

また、AES-GCM などの AEAD 暗号は、パディング oracle 攻撃に対して脆弱ではないため、CBC-mode 暗号よりも優先する必要があります。また、多くの場合、特にハードウェアに AES の暗号化アクセラレーターがある場合、AES-GCM は CBC モードの AES よりも高速です。

ECDSA 証明書で ECDHE 鍵交換を使用する場合、トランザクションは純粋な RSA 鍵交換よりもさらに高速になります。レガシークライアントのサポートを提供するために、サーバーに証明書と鍵のペアを 2 つインストールします。1 つは ECDSA 鍵（新しいクライアント用）と RSA 鍵（レガシークライアント用）です。

公開鍵の長さ

RSA 鍵を使用する場合は、少なくとも SHA-256 で署名されている 3072 ビット以上の鍵の長さを常に優先します。これは、実際の 128 ビットのセキュリティーに対して十分な大きさです。

警告

システムのセキュリティー強度は、チェーンの中の最も弱いリンクが示すものと同じになることを覚えておいてください。たとえば、強力な暗号化だけではすぐれたセキュリティーは保証されません。鍵と証明書も同様に重要で、認証機関 (CA) が鍵の署名に使用するハッシュ機能と鍵もまた重要になります。

4.13.2. TLS 実装の使用

Red Hat Enterprise Linux 7 には、TLS の複数のフル機能の実装が同梱されています。このセクションでは、OpenSSL および GnuTLS の設定について説明します。個々のアプリケーションで TLS サポートを設定する方法については、「特定アプリケーションの設定」を参照してください。

利用可能な TLS 実装は、TLSで保護された通信を確立および使用する際に結合されるすべての要素を定義するさまざまな 暗号スイート のサポートを提供します。

さまざまな実装に含まれるツールを使用して、「有効にするアルゴリズムの選択」で概説されている推奨事項を考慮しながら、ユースケースに可能な限り最適なセキュリティーを提供する暗号スイートをリストアップし、指定することができます。このようにして得られた暗号スイートは、個々のアプリケーションが接続をネゴシエートして保護する方法を設定するために使用することができます。

重要

使用する TLS 実装またはその実装を利用するアプリケーションの更新またはアップグレードごとに、必ず設定を確認してください。新しいバージョンでは、有効化したくない、かつ現在の設定では無効化できない新しい暗号スイートが導入される可能性があります。

4.13.2.1. OpenSSL での暗号化スイートの使用

OpenSSL は、SSL プロトコルおよび TLS プロトコルをサポートするツールキットおよび暗号化ライブラリーです。Red Hat Enterprise Linux 7 では、設定ファイルは /etc/pki/tls/openssl.cnf で提供されます。この設定ファイルのフォーマットは、config(1) に記載されています。「OpenSSL の設定」も参照してください。

OpenSSL のインストールでサポートされているすべての暗号スイートの一覧を取得するには、以下のように openssl コマンドを ciphers サブコマンドと共に使用します。

~]$ openssl ciphers -v 'ALL:COMPLEMENTOFALL'

その他のパラメーター( OpenSSL ドキュメントの 暗号文字列 および キーワード と呼ばれます)を ciphers サブコマンドに渡して、出力を絞り込みます。特別なキーワードを使用して、特定の条件を満たすスイートのみを一覧表示できます。たとえば、HIGH グループに属すると定義されているスイートのみをリストアップするには、次のコマンドを使用します。

~]$ openssl ciphers -v 'HIGH'

利用可能なキーワードと暗号文字列の一覧は、ciphers(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  Enc=AESGCM(128)  Mac=AEAD
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    Enc=AESGCM(256)  Mac=AEAD
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    Enc=AESGCM(128)  Mac=AEAD
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    Enc=AESGCM(256)  Mac=AEAD
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    Enc=AESGCM(128)  Mac=AEAD
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

上記のコマンドは、セキュアでないすべての暗号を省略し、一時的な省略曲線 Diffie-Hellman 鍵交換および ECDSA 暗号を優先し、RSA 鍵交換を省略します（これにより 完全な転送秘密性が確保されます）。

これはかなり厳密な設定であり、より広範囲のクライアントとの互換性を確保するために、実際のシナリオの条件を緩和する必要がある場合があることに注意してください。

4.13.2.2. GnuTLS での暗号化スイートの使用

GnuTLS は、SSL および TLS プロトコルおよび関連テクノロジーを実装する通信ライブラリーです。

注記

Red Hat Enterprise Linux 7 での GnuTLS インストールは、ほとんどのユースケースに十分なセキュリティーを提供する最適なデフォルト設定値を提供します。特別なセキュリティー要件を満たす必要がない限り、提供されたデフォルトを使用することが推奨されます。

-l （または --list）オプションを指定して gnutls-cli コマンドを使用して、サポートされているすべての暗号スイートを一覧表示します。

~]$ gnutls-cli -l

-l オプションによって表示される暗号スイートのリストを絞り込むには、1 つ以上のパラメーター( GnuTLS ドキュメントの 優先度文字列 および キーワード と呼ばれます)を --priority オプションに渡します。利用可能なすべての優先度文字列の一覧は、http://www.gnutls.org/manual/gnutls.html#Priority-Strings の GnuTLS ドキュメントを参照してください。たとえば、次のコマンドを実行すると、少なくとも 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
TLS_ECDHE_ECDSA_AES_128_CBC_SHA256                      0xc0, 0x23      TLS1.2
TLS_ECDHE_ECDSA_AES_128_CBC_SHA1                        0xc0, 0x09      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
TLS_ECDHE_RSA_AES_128_CBC_SHA256                        0xc0, 0x27      TLS1.2
TLS_ECDHE_RSA_AES_128_CBC_SHA1                          0xc0, 0x13      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
TLS_DHE_RSA_AES_128_CBC_SHA256                          0x00, 0x67      TLS1.2
TLS_DHE_RSA_AES_128_CBC_SHA1                            0x00, 0x33      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.13.3. 特定アプリケーションの設定

さまざまなアプリケーションが TLS に独自の設定メカニズムを提供します。このセクションでは、最も一般的に使用されるサーバーアプリケーションで採用されている TLS関連の設定ファイルについて説明し、一般的な設定の例を提供します。

いずれの設定を選択しても、サーバーアプリケーションが強制的に サーバー側が指定した順序 で暗号を利用することを確認し、使用される暗号化スイートの選択がサーバーでの設定順に行われるように設定してください。

4.13.3.1. Apache HTTP Server の設定

Apache HTTP Server は、TLS のニーズに OpenSSL ライブラリーと NSS ライブラリーの両方を使用できます。TLS ライブラリーの選択に応じて、mod_ssl または mod_nss モジュールのいずれかをインストールする必要があります（ディープパッケージで提供される）。たとえば、OpenSSL mod_ssl モジュールを提供するパッケージをインストールするには、root で以下のコマンドを実行します。

~]# yum install mod_ssl

mod_ssl パッケージは、/etc/httpd/conf.d/ssl.conf 設定ファイルをインストールします。このファイルを使用して、Apache HTTP Server の TLS関連の設定を変更します。同様に、mod_nss パッケージは /etc/httpd/conf.d/nss.conf 設定ファイルをインストールします。

httpd-manual パッケージをインストールして、TLS 設定を含む Apache HTTP Server の完全なドキュメントを取得します。/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

上記の設定は最低限のものであり、「有効にするアルゴリズムの選択」に概説されている推奨事項に従うことで、大幅に強化できることに注意してください。

mod_nss モジュールを設定して使用するには、/etc/httpd/conf.d/nss.conf 設定ファイルを変更します。mod_nss モジュールは mod_ssl から派生しているため、設定ファイルの構造や利用可能なディレクティブなど、多くの機能を共有します。mod_nss ディレクティブには、SSL の代わりに NSS の接頭辞があることに注意してください。mod_nss に該当しない

セキュリティーガイド

RHEL サーバーとワークステーションをセキュアにする概念と手法

Mirek Jahoda

Jan Fiala

Stephen Wadeley

Robert Krátký

Martin Prpič

Ioanna Gkioka

Tomáš Čapek

Yoana Ruseva

Miroslav Svoboda

第1章 セキュリティーの概要

1.1. コンピューターセキュリティーとは

1.1.1. セキュリティーの標準化

1.1.2. 暗号化ソフトウェアおよび認定

1.2. セキュリティーコントロール

1.2.1. 物理的コントロール

1.2.2. 技術的コントロール

1.2.3. 管理的コントロール

1.3. 脆弱性のアセスメント

1.3.1. アセスメントとテストの定義

1.3.2. 脆弱性評価に関する方法論の確立

1.3.3. 脆弱性アセスメントのツール

1.3.3.1. Nmap を使用したホストのスキャン

1.3.3.1.1. Nmap の使用

1.3.3.2. Nessus

1.3.3.3. OpenVAS

1.3.3.4. Nikto

1.4. セキュリティーへの脅威

1.4.1. ネットワークセキュリティーへの脅威

セキュリティーが十分ではないアーキテクチャー

ブロードキャストネットワーク

集中化サーバー

1.4.2. サーバーセキュリティーへの脅威

未使用のサービスと開かれたポート

パッチが適用されないサービス

管理における不注意

本質的に安全ではないサービス

1.4.3. ワークステーションおよび家庭用 PC のセキュリティーに対する脅威

不適切なパスワード

脆弱なクライアントアプリケーション

1.5. 一般的な不正使用と攻撃

第2章 インストール時におけるセキュリティーのヒント

2.1. BIOS のセキュア化

2.1.1. BIOS パスワード

2.1.1.1. 非 BIOS ベースのシステムの保護

2.2. ディスクのパーティション設定

2.3. 必要なパッケージの最小限のインストール

2.4. インストールプロセス時のネットワーク接続の制限

2.5. インストール後の手順

2.6. 関連情報

第3章 システムを最新の状態に保つ

3.1. インストール済みソフトウェアのメンテナーンス

3.1.1. セキュリティーの更新の立案と設定

3.1.1.1. Yum のセキュリティー機能の使用

3.1.2. パッケージの更新とインストール

3.1.2.1. 署名パッケージの検証

3.1.2.2. 署名パッケージのインストール

3.1.3. インストールされた更新によって導入された変更の適用

3.2. Red Hat カスタマーポータルの使用

3.2.1. カスタマーポータルでのセキュリティーアドバイザリーの表示

3.2.2. カスタマーポータルページでの CVE への移動

3.2.3. 問題の重大度の分類を理解する

3.3. 関連情報

インストールされているドキュメント

オンラインドキュメント

Red Hat カスタマーポータル

関連項目

第4章 ツールとサービスでシステムを強化する

4.1. デスクトップのセキュリティー

4.1.1. パスワードセキュリティー

4.1.1.1. 強固なパスワードの作成

4.1.1.2. 強固なパスワードの強制

4.1.1.3. パスワードエージングの設定

4.1.2. アカウントのロック

authconfig でのカスタム設定の保持

nullok オプションの削除

4.1.3. セッションのロック

4.1.3.1. vlock を使った仮想コンソールのロック

4.1.4. リムーバブルメディアの読み取り専用マウントの強制

第1章セキュリティーの概要

第2章インストール時におけるセキュリティーのヒント

第3章システムを最新の状態に保つ

第4章ツールとサービスでシステムを強化する

`nullok` オプションの削除

4.3.6.3. `/var/yp/securenets` ファイルの編集