Language:
Format:

Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

セキュリティーガイド

Red Hat Enterprise Linux 7

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

概要

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

本書は 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,000 を超えるネットワーク脆弱性テスト (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 シーケンス番号を予測しなければならないため、かなり難しくなりますが、クラッカーの脆弱性の攻撃を支援する利用可能なツールがいくつかあります。標的となるシステムで実行している source-based 認証技術を使用するサービス (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 を使用したイングレスフィルターリング (IETF rfc2267) や、snort などのネットワーク侵入検知システムにおける進歩は、管理者が分散型サービス拒否攻撃を追跡し、これを防止するのに役立っています。

第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 パーティションにデータを保存できると、このデータはインストール時に上書きされないため、アップグレードが非常に簡単になります。root パーティション (/) が破損すると、データが完全に失われます。したがって、パーティションを分けることが、データ損失に対する保護につながります。また、このパーティションを、頻繁にバックアップを作成する対象にすることも可能です。
/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 サブスクリプション管理サービスで配布されます。セキュリティー問題に対処するエラータは、Red Hat セキュリティーアドバイザリー と呼ばれます。

セキュリティーエラータを使った作業についての詳細情報は、「カスタマーポータルでのセキュリティーアドバイザリーの表示」を参照してください。RHN Classic からの移行を含む Red Hat サブスクリプション管理サービスについての詳細情報は、Red Hat サブスクリプション管理にある関連ドキュメントを参照してください。

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 で使用できるセキュリティー関連コマンドです。

コマンド	説明
advisory [advisories]	1 つ以上のアドバイザリーに関する情報を表示します。advisories をアドバイザリー番号に置き換えます。
cves	CVE (Common Vulnerabilities and Exposures) に関連する情報のサブセットを表示します。
security または sec	すべてのセキュリティー関連情報を表示します。
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/ にログインし、メインページの製品と更新のダウンロードボタンをクリックしてください。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 System Administrator's Guide — Red Hat Enterprise Linux 7 の『System Administrator's Guide』には、Red Hat Enterprise Linux 7 システムでのパッケージのインストール、更新、削除に使用する Yum コマンドと rpm コマンドの使用方法が記載されています。
Red Hat Enterprise Linux 7 SELinux User's and Administrator's Guide — Red Hat Enterprise Linux 7 の『SELinux User's and Administrator's Guide』には、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対応 (Pluggable Authentication Modules) のコマンドラインユーティリティーpasswdを使用して、パスワードが短すぎたり、解明されやすいものでないかどうかをチェックすることができます。このチェックは、pam_pwquality.so PAM モジュールによって実行されます。

注記

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

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 スタックに以下の行を追加します。

password    required    pam_pwquality.so retry=3

チェックのオプションは、1 行に 1 つずつ指定します。たとえば、文字の 4 つのクラスすべてを含め、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 でパスワードエージングを指定するには、chage コマンドを使用します。

重要

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

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

chage -M 90 username

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

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

表4.1 chage コマンドラインオプション

オプション	説明
`-d` days	1970 年 1 月 1 日以降にパスワードを変更した日数を指定します。
`-E` date	アカウントがロックされる日付を YYYY-MM-DD のフォーマットで指定します。日付の代わりに、1970 年 1 月 1 日からの日数を使うこともできます。
`-I` days	パスワードの有効期限後、アカウントをロックするまでの非アクティブ日数を指定します。値が `0` の場合、パスワードの有効期限が切れた後、アカウントはロックされません。
`-l`	現在のアカウントエージングの設定を一覧表示します。
`-m` days	ユーザーがパスワードを変更しなければならない最短日数を指定します。値を `0` とすると、パスワードは失効しません。
`-M` days	パスワードの最大有効日数を指定します。このオプションで指定した日数と、`-d` オプションで指定した日数を足した日数が、現在の日数より少ない場合、ユーザーはアカウントを使用する前にパスワードを変更する必要があります。
`-W` days	パスワードの有効期限の何日前にユーザーに警告を発するかを指定します。

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

chage <username>

以下は、このコマンドを使用した対話セッションの例です。

~]# chage juan
Changing the aging information for juan
Enter the new value, or press ENTER for the default
Minimum Password Age [0]: 10
Maximum Password Age [99999]: 90
Last Password Change (YYYY-MM-DD) [2006-08-18]:
Password Expiration Warning [7]:
Password Inactive [-1]:
Account Expiration Date (YYYY-MM-DD) [1969-12-31]:

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

初期パスワードを設定します。デフォルトのパスワードを割り当てるには、シェルプロンプトで、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 回失敗すると非ルートユーザーをロックアウトし、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/ ディレクトリーの対象サービスのファイルを編集し、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 についての詳細情報は、『The Linux-PAM System Administrator's Guide』を参照してください。/usr/share/doc/pam-<version>/html/ ディレクトリーにあります。

表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 サービス用の動的ポート割り当てデーモンです。認証メカニズムが弱く、制御するサービスに幅広いポート範囲を割り当てることができます。これらの理由から、セキュリティー保護することは困難です。

注記

NFSv4 では rpcbind が不要になったため、rpcbind の保護は 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 リッチ言語コマンドの 2 つの例です。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'

注記

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

4.3.5. rpc.mountd のセキュア化

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

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 リッチ言語コマンドの 2 つの例です。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 マップへのアクセスを困難にするために、DNS ホスト名にo7hfawtgmhwg.domain.comのようなランダムな文字列を作成します。同様に、異なるランダムな NIS ドメイン名を作成します。これにより、攻撃者が NIS サーバーにアクセスすることがより困難になります。

4.3.6.3. `/var/yp/securenets` ファイルを編集する

/var/yp/securenetsファイルが空白または存在しない場合 (デフォルトのインストール後の場合)、NIS はすべてのネットワークをリッスンします。まず最初にすべきことは、ネットマスクとネットワークのペアをファイルに記述し、ypservが適切なネットワークからのリクエストにのみ反応するようにすることです。

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

255.255.255.0     192.168.0.0

警告

NIS サーバーの初回起動時には、必ず /var/yp/securenets ファイルを作成してから起動してください。

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

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

NIS に関連するすべてのサーバーは、ユーザーがログインパスワードを変更するためのデーモンであるrpc.yppasswdd を除いて、特定のポートを割り当てることができます。他の 2 つの NIS サーバーデーモンであるrpc.ypsfrdと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 への接続を許可するということです。1 つ目のルールは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 ストレージ管理ガイドストレージ管理ガイドの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 ユーザーは、共有ファイルシステム上の任意のファイルを変更し、他のユーザーが誤って実行するようにアプリケーションをトロイの木馬に感染したままにすることができます。

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 をネットワーク攻撃から保護します。

ローカルホストの制限を取り除き、Postfix がすべてのインターフェイスをリッスンできるようにするには、inet_interfaces = all 設定を使用することができます。

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

Red Hat Enterprise Linux 7 版のPostfixは、SMTP 認証(またはSMTP AUTH) にDovecotまたはCyrus SASL実装を使用できます。SMTP 認証は、Simple Mail Transfer Protocol のエクステンションです。有効にすると、SMTP クライアントは、サーバーとクライアントの両方がサポートし、受け入れる認証方法を使用して、SMTP サーバーを認証する必要があります。このセクションでは、Dovecot SASL 実装を利用するように Postfix を設定する方法について説明します。

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

~]# yum install dovecot

PostfixSMTP サーバーは、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 ユーザーとグループの下で実行されているアプリケーションを含む Postfix SMTP サーバーのデフォルト設定を想定しています。このように、読み取りと書き込みのパーミッションは、postfix のユーザーとグループに制限されます。
また、DovecotがTCP経由でPostfixの認証要求をリッスンするように設定するには、以下のような設定を行います。
```
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 の章には、キーペアの生成に関する詳細な情報が記載されています。

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

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

また、このコマンドは、公開鍵を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 セキュリティーガイドの手順に従ってください。

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 の OPTIONS に -S 値を追加して、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 とロギングの強化

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

この例では、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 で定義された緩慢なモード。

この設定は、

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

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

注記

これらの設定を再起動しても保持するには、/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 -t raw -I PREROUTING -m rpfilter --invert -j DROP

のように、ip6tables コマンドを使用することで、firewalld デーモン なしで これを実行することができます。このルールは、すべてのトラフィックに適用されるように、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-version/Documentation/networking/ip-sysctl.txt - このファイルには、ディレクトリー内で利用可能なファイルとオプションの完全なリストが含まれています。カーネルのドキュメントに初めてアクセスする前に、root で次のコマンドを入力してください。
```
~]# yum install kernel-doc
```
オンラインドキュメント
マルチホームネットワークの Ingress フィルターリングの説明については、RFC 3704 を参照してください。

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

4.5.1. DNS の概要

DNSSEC は、ドメインネームシステムセキュリティー拡張機能(DNSSEC) のセットであり、DNSクライアントがDNSネームサーバーからの応答の整合性を認証およびチェックして、発信元を確認し、転送中に改ざんされていないかどうかを判断できるようにします。

4.5.2. DNSSEC について

インターネットを介して接続するために、HTTPS を使用して安全に接続する機能を提供する Web サイトが増えています。ただし、HTTPSWeb サーバーに接続する前に、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 つの root キーで設定するだけで済みます。暗号チェックに失敗した場合、リゾルバーはアプリケーションに SERVFAIL を返します。

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

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

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

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

DNSSEC 対応の再帰リゾルバーをデプロイするには、BIND または unbound のいずれかを使用できます。いずれもデフォルトで DNSSEC を有効にし、DNSSEC root キーで設定されています。サーバーで DNSSEC を有効にするには、どちらでも構いませんが、ノート PC などのモバイルデバイスでは、ローカルユーザーが動的に DNSSEC オーバーライド (dnssec-trigger 使用時は Hotspot 用、Libreswan 使用時は VPN 用に必要) を再設定できる unbound の使用が望ましいです。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 サーバー自体に到達する以外のすべてをファイアウォールによってブロックされている場合などは、ポート 80 に DNS を使用するか、ポート 443 に TLS カプセル化 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 トンネルが終了すると、unbound キャッシュが再度フラッシュされ、ドメインへのクエリーが以前に取得したプライベート IP アドレスではなく、パブリック IP アドレスを返すようにします。「接続が提供されるドメインの DNSSEC 検証の設定」を参照してください。

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

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

ICANN (The Internet Corporation for Assigned Names and Numbers) は、(.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コマンドは、バインドされていないサービスが実行されていない場合、バインドされていないものを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 はこれを自動的に検出し、セキュアモードに戻るはずですが、場合によっては自動的に行われず、ユーザーは再プローブを選択して手動でこれを行う必要があります。

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 ファイルを公開したとすると、この静的ページのアドレスは、example.com/static/hotspot.txt になります。Red Hat Enterprise Linux 7 System Administrator's Guide の Web Servers の章にある 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 ページ — DNS 検証リゾルバーである unbound のコマンドオプションについて説明しています。
unbound.conf(5) の man ページ — unbound の設定方法に関する情報が含まれています。
resolv.conf(5) の man page — リゾルバールーチンによって読み取られる情報が含まれています。

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 では、VPN (Virtual Private Network) は、Libreswan アプリケーションで対応している IPsec プロトコルを使用して設定できます。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 プロトコルには、トンネルモード (デフォルト) と トランスポートモード の 2 つの異なる動作モードがあります。IKE を使用せずに IPsec を使用してカーネルを設定できます。これは、手動キーリング と呼ばれます。ip xfrm コマンドを使用して手動キーイングを設定することは可能ですが、セキュリティー上の理由から、これは強くお勧めしません。Libreswan では、netlink を使用する Linux カーネルで相互作用が行われます。Linux カーネルでパケットの暗号化と復号が行われます。

Libreswan は、ネットワークセキュリティーサービス (NSS) 暗号化ライブラリーを使用します。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 文字以上にすることが推奨されます。
生の RSA 鍵は、静的なホスト間またはサブネット間の IPsec 設定で一般的に使用されます。ホストは、相互の公開 RSA 鍵を使用して手動で設定します。この方法は、1 ダース以上のホストで、互いに IPsec トンネルを設定する必要がある場合は、適切に調整されません。
X.509 証明書は、共通の IPsec ゲートウェイへの接続が必要になるホストが多数存在する、大規模なデプロイメントに一般的に使用されます。中央の 認証局 (CA) は、ホストまたはユーザーの RSA 証明書の署名に使用されます。この中央 CA は、個別のホストまたはユーザーの取り消しを含む、信頼のリレーを行います。
NULL 認証は、認証なしでメッシュの暗号化を取得するために使用されます。これは、パッシブ攻撃は防ぎますが、アクティブ攻撃は防ぎません。ただし、IKEv2 は非対称認証メソッドを許可するため、NULL 認証は、インターネット規模の日和見 IPsec にも使用できます。この場合、クライアントはサーバーを認証しますが、サーバーはクライアントを認証しません。このモデルは、TLS を使用する安全な Web サイト (https:// websites とも呼ばれます) に似ています。

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

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

Libreswanを設定して、「左」と「右」と呼ばれる 2 つのホスト間にホスト間IPsecVPN を構築するには、「左」と「右」の両方のホスト上で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 データベース」に保存されます。

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

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 の設定

ロードウォーリアーとは、外出先などで、ノート PC など、動的に 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 は、PPK (Postquantum Preshared Keys) を使用して、量子攻撃に対して 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

これで、デフォルトの privacy-enhanced electronic mail (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 によって署名された証明書は、信頼できる証明書と呼ばれます。したがって、自己署名証明書は信頼できない証明書になります。検証ユーティリティーは、OpenSSL が通常の操作で使用するのと同じ SSL および S/MIME 機能を使用して証明書を検証します。エラーが見つかった場合は報告され、他のエラーを報告するためにテストを続行しようとします。

PEM 形式の複数の個別の X.509 証明書を検証するには、次の形式のコマンドを発行します。

~]$ openssl verify cert1.pem cert2.pem

証明書チェーンを検証するには、リーフ証明書を cert.pem にあり、信頼できない中間証明書を untrusted.pem に直接結びつけておく必要があります。信頼できる root CA 証明書は、/etc/pki/tls/certs/ca-bundle.crt または cacert.pem ファイルにリストされているデフォルト CA のいずれかに含まれている必要があります。次に、チェーンを確認するために、次の形式でコマンドを発行します。

~]$ openssl verify -untrusted untrusted.pem -CAfile cacert.pem cert.pem

詳細は、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 ページでは、公開鍵アルゴリズムユーティリティーについて説明しています。

シンメトリックアルゴリズムの使用

利用可能な対称型暗号化アルゴリズムの一覧を表示するには、enc コマンドに -l などのサポートされていないオプションを指定して実行します。

~]$ openssl enc -l

アルゴリズムを指定するには、その名前をオプションとして使用します。たとえば、aes-128-cbc アルゴリズムを使用するには、次の構文を使用します。

openssl enc -aes-128-cbc

aes-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 コマンドは、提供された 1 つまたは複数のファイルのメッセージダイジェストを 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 用に自己署名証明書を作成するには、root で /etc/pki/tls/certs/ ディレクトリーに移動し、以下のコマンドを実行します。
```
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 のディスクドライブといった、モバイルデバイスのコンテンツの保護に適しています。
暗号化されたブロックデバイスの基本的な内容は任意です。これにより、swap デバイスの暗号化に役立ちます。また、とりわけデータストレージ用にフォーマットしたブロックデバイスを使用する特定のデータベースに関しても有用です。
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 (XTS モード) を使用した LUKS のデフォルトの鍵サイズは 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 での暗号化したブロックデバイスの作成

システムインストール時に、暗号化されたデバイスを作成することができます。これにより、暗号化されたパーティションを持つシステムを簡単に設定することができます。

ブロックデバイスの暗号化を有効にするには、自動パーティション設定を選択するときにシステムの暗号化チェックボックスをオンにするか、個々のパーティション、ソフトウェア RAID アレイ、または論理ボリュームを作成するときに暗号化チェックボックスをオンにします。パーティション設定が完了すると、暗号化用のパスフレーズの入力が求められます。このパスフレーズは、暗号化されたデバイスにアクセスする際に必要となります。既存の 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
```
キーを作成するには、アプリケーション → アクセサリーメニューから、パスワードと暗号化キーを選択します。これにより、アプリケーション Seahorse が起動します。
ファイルメニューから、新規、PGP Key の順に選択します。続いて、続行をクリックします。
フルネーム、メールアドレス、および自身に関して説明するオプションのコメントを入力します (例:John C. Smith、jsmith@example.com、ソフトウェアエンジニア)。作成をクリックします。キーのパスフレーズを要求するダイアログが表示されます。強力かつ覚えやすいパスフレーズを選んでください。OK をクリックすると鍵が作成されます。

警告

パスフレーズを忘れると、データの暗号解除ができなくなります。

GPG 鍵の ID を見つけるには、新規に作成された鍵の横にある鍵の ID コラムを確認します。多くの場合、鍵 ID を求められる際には、0x6789ABCD などのように、鍵 ID の前に 0x を付けます。秘密鍵のバックアップを取り、安全な場所に保管してください。

4.9.2.2. KDE での GPG 鍵の作成

KDE で GPG 鍵を作成するには、以下の手順に従います。

メインメニューからアプリケーション → ユーティリティー → 暗号ツールを選択して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 は、ほとんどすべてのユーザーにとって十分であり、非常に強力なセキュリティーレベルを表しています。
鍵の有効期限を選択します。デフォルトの none を使用する代わりに、有効期限を選択することをお勧めします。たとえば、キーの電子メールアドレスが無効になった場合、有効期限があると、他の人にその公開キーの使用を停止するように知らせることができます。
```
Please specify how long the key should be valid.
0 = key does not expire
d = key expires in n days
w = key expires in n weeks
m = key expires in n months
y = key expires in n years
key is valid for? (0)
```
たとえば、1y の値を入力すると、キーは 1 年間有効になります。(気が変わった場合は、キーが生成された後にこの有効期限を変更できます。)
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 を求められる際には、0x6789ABCD などのように、鍵 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 システム管理者ガイドの Installing Packages のセクションを参照してください。

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. PIN でのログインを自動化するための ssh-agent の使用

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 ユーティリティーの詳細は、man ページの pkcs11-tool(1) を参照してください。

4.9.5. 信頼できる鍵および暗号化された鍵

信頼できる鍵と暗号化された鍵は、カーネルキーリングサービスを使用するカーネルが生成する可変長の対称鍵です。キーが暗号化されていない形式でユーザースペースに表示されないという事実は、キーの整合性を検証できることを意味します。つまり、拡張検証モジュール (EVM) などで実行中のシステムの整合性を検証および確認するために使用できます。ユーザーレベルのプログラムは、暗号化された blobs の形式でのみキーにアクセスできます。

信頼できる鍵は、Trusted Platform Module (TPM) チップというハードウェアが必要になります。これは、鍵を作成し、暗号化 (保護) するために使用されます。TPM は storage root key (SRK) という 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 サブコマンドは、暗号化されたキーを標準出力に出力します。キーをユーザースペースの blob にエクスポートするには、次のように pipe サブコマンドを使用します。

~]$ keyctl pipe 642500861 > kmk.blob

ユーザースペースの blob から信頼できる鍵を読み込むには、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 では virtio RNG (乱数ジェネレーター) デバイスが導入され、ホストマシンからエントロピーにアクセスできる KVM 仮想マシンが提供されています。推奨される設定では、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

詳細は、clevis-encrypt-tang(1) の man ページを参照するか、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 ポリシーだけでなく、既存のパスワードでもロック解除ができるようになりました。詳細は、clevis-luks-bind(1) の man ページを参照してください。

注記

バインド手順では、空き LUKS パスワードスロットが少なくとも 1 つあることが前提となっています。そのスロットの 1 つを clevis luks bind コマンドが使用します。

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 は、キックスタートと統合して、登録プロセスを完全に自動化にできます。

一時パスワードを使用して、LUKS 暗号化が有効になっているディスクを、/boot 以外のすべてのマウントポイントで分割するように、キックスタートに指示します。パスワードは、登録プロセスの手順に使用するための一時的なものです。

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 設定ファイルに追加します。詳細は man ページの crypttab(5) を参照してください。
/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 ページ
zipl.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 アクセス制御のセクションを参照してください。

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 の詳細については、以下のドキュメントを参照してください。

man ページの usbguard(1)
man ページの usbguard-rules.conf(5)
man ページの usbguard-daemon(8)
man ページの usbguard-daemon.conf(5)
USBGuard ホームページ

4.13. TLS 設定の強化

TLS (トランスポート層セキュリティー) は、ネットワーク通信のセキュリティー保護に使用する暗号化プロトコルです。優先する 鍵交換プロトコル、認証方法、および暗号化アルゴリズムを設定してシステムのセキュリティー設定を強化する際には、対応するクライアントの範囲が広ければ広いほど、セキュリティーのレベルが低くなることを認識しておく必要があります。反対に、セキュリティー設定を厳密にすると、クライアントとの互換性が制限され、システムからロックアウトされるユーザーが出てくる可能性もあります。可能な限り厳密な設定を目指し、互換性に必要な場合に限り、設定を緩めるようにしてください。

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 暗号は、パディングオラクル攻撃の影響は受けないため、CBC モード暗号よりも推奨されます。さらに、多くの場合、特にハードウェアに AES 用の暗号化アクセラレーターがある場合、AES-GCM は CBC モードの AES よりも高速です。

ECDSA 証明書で ECDHE 鍵交換を使用すると、トランザクションは純粋な RSA 鍵交換よりもさらに高速になります。レガシークライアントに対応するため、サーバーには証明書と鍵のペアを 2 つ (新しいクライアント用の 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 モジュール (同名のパッケージで提供) のいずれかをインストールする必要があります。たとえば、OpenSSLmod_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には適用されないmod_sslの設定ディレクティブの一覧など、mod_nssに関する情報の概要はhttps://git.fedorahosted.org/cgit/mod_nss.git/plain/docs/mod_nss.htmlを参照してください。

4.13.3.2. Dovecot メールサーバーの設定

Dovecot メールサーバーのインストールが TLS を使用するように設定するには、/etc/dovecot/conf.d/10-ssl.conf 設定ファイルを修正します。このファイルで利用できる基本的な設定ディレクティブの一部は、/usr/share/doc/dovecot-2.2.10/wiki/SSL.DovecotConfiguration.txt ファイルで説明されています。このヘルプファイルは、Dovecotの標準インストールと一緒にインストールされています。

/etc/dovecot/conf.d/10-ssl.conf 設定ファイルの設定を修正する場合は、少なくとも下記の 3 つのディレクティブを確認してください。

ssl_protocols: このディレクティブを使用して、許可する TLS (または SSL) のバージョンを指定します。
ssl_cipher_list: 優先する暗号化スイートを指定する、もしくは許可しないスイートを無効にするディレクティブです。
ssl_prefer_server_ciphers: コメントを解除して、このディレクティブを yes に設定すると、接続先のクライアントは指定した暗号化の順序に従います。

以下に例を示します。

ssl_protocols = !SSLv2 !SSLv3
ssl_cipher_list = HIGH:!aNULL:!MD5
ssl_prefer_server_ciphers = yes

4.13.4. 追加情報

TLS 設定と関連トピックの詳細は、以下に挙げるリソースを参照してください。

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

config(1) — /etc/ssl/openssl.conf 設定ファイルの形式が説明されています。
ciphers(1) — 利用可能な OpenSSL キーワードと暗号文字列の一覧が記載されています。
/usr/share/httpd/manual/mod/mod_ssl.html — Apache HTTP Server 用に mod_ssl が使用する /etc/httpd/conf.d/ssl.conf 設定ファイルで利用可能なディレクティブを詳細に説明しています。
/usr/share/httpd/manual/ssl/ssl_howto.html — Apache HTTP Server のmod_sslモジュールが使用する/etc/httpd/conf.d/ssl.conf設定ファイルの実際の設定例を掲載しています。
/usr/share/doc/dovecot-2.2.10/wiki/SSL.DovecotConfiguration.txt — Dovecotメールサーバーで使用される/etc/dovecot/conf.d/10-ssl.conf設定ファイルで利用可能な基本的な設定ディレクティブのいくつかを説明しています。

オンラインドキュメント

Red Hat Enterprise Linux 7 SELinux ユーザーおよび管理者のガイド: Red Hat Enterprise Linux 7 の『SELinux ユーザーおよび管理者のガイド』では、SELinux の原則と、SELinux を Apache HTTP Server などの様々なサービスに設定して使用する方法が詳細に説明されています。
http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-00 — TLSとDTLS を安全に使用するための推奨事項です。

4.14. 共通システム証明書の使用

共有システム証明書ストレージは、NSS、GnuTLS、OpenSSL、および Java が、システムの証明書アンカーと、ブラックリスト情報を取得するデフォルトソースを共有することを許可します。トラストストアには、デフォルトで、Mozilla CA の一覧 (信頼される一覧および信頼されない一覧) を含みます。このシステムでは、コアとなる Mozilla CA リストの更新や、他の証明書リストの選択が可能です。

4.14.1. システム全体でトラストストアの使用

Red Hat Enterprise Linux 7 では、統合されたシステム全体のトラストストアは /etc/pki/ca-trust/ ディレクトリーおよび /usr/share/pki/ca-trust-source/ ディレクトリーに配置されています。/usr/share/pki/ca-trust-source/ のトラスト設定は、/etc/pki/ca-trust/ の設定よりも低い優先順位で処理されます。

証明書ファイルは、インストールされているサブディレクトリーによって扱われ方が異なります。

/usr/share/pki/ca-trust-source/anchors/ または /etc/pki/ca-trust/source/anchors/ - トラストアンカーの場合。「トラストアンカーについて」を参照してください。
/usr/share/pki/ca-trust-source/blacklist/ または /etc/pki/ca-trust/source/blacklist/ - 信頼できない証明書の場合。
/usr/share/pki/ca-trust-source/ または /etc/pki/ca-trust/source/ - 拡張された BEGIN TRUSTED ファイル形式の証明書の場合。

4.14.2. 新しい証明書の追加

システムで信頼されている CA の一覧に、シンプルな PEM または DER のファイルフォーマットに含まれる証明書を追加するには、/usr/share/pki/ca-trust-source/anchors/ ディレクトリーまたは /etc/pki/ca-trust/source/anchors/ ディレクトリーに証明書ファイルをコピーします。システム全体のトラストストアの設定を更新するには、update-ca-trust コマンドを実行します。以下に例を示します。

# cp ~/certificate-trust-examples/Cert-trust-test-ca.pem /usr/share/pki/ca-trust-source/anchors/
# update-ca-trust

注記

Firefox ブラウザーでは、update-ca-trust を実行しなくても、追加した証明書を使用できますが、CA 変更後に update-ca-trust を実行することが推奨されます。Firefox、Epiphany、Chromium などのブラウザーはファイルをキャッシュするため、現在のシステム証明書の設定を読み込むために、ブラウザーのキャッシュを削除して、ブラウザーを再起動することが必要になるかもしれません。

4.14.3. 信頼されているシステム証明書の管理

トラストアンカーの一覧表示、抽出、追加、削除、または変更を行うには、trust コマンドを使用します。このコマンドの組み込みヘルプを表示するには、引数を付けずに、または --help ディレクティブを付けて実行します。

$ trust
usage: trust command <args>...

Common trust commands are:
  list             List trust or certificates
  extract          Extract certificates and trust
  extract-compat   Extract trust compatibility bundles
  anchor           Add, remove, change trust anchors
  dump             Dump trust objects in internal format

See 'trust <command> --help' for more information

すべてのシステムのトラストアンカーおよび証明書の一覧を表示するには、trust list コマンドを実行します。

$ trust list
pkcs11:id=%d2%87%b4%e3%df%37%27%93%55%f6%56%ea%81%e5%36%cc%8c%1e%3f%bd;type=cert
    type: certificate
    label: ACCVRAIZ1
    trust: anchor
    category: authority

pkcs11:id=%a6%b3%e1%2b%2b%49%b6%d7%73%a1%aa%94%f5%01%e7%73%65%4c%ac%50;type=cert
    type: certificate
    label: ACEDICOM Root
    trust: anchor
    category: authority
...
[output has been truncated]

trust コマンドのすべてのサブコマンドは、以下のような詳細な組み込みヘルプを提供します。

$ trust list --help
usage: trust list --filter=<what>

  --filter=<what>     filter of what to export
                        ca-anchors        certificate anchors
                        blacklist         blacklisted certificates
                        trust-policy      anchors and blacklist (default)
                        certificates      all certificates
                        pkcs11:object=xx  a PKCS#11 URI
  --purpose=<usage>   limit to certificates usable for the purpose
                        server-auth       for authenticating servers
                        client-auth       for authenticating clients
                        email             for email protection
                        code-signing      for authenticating signed code
                        1.2.3.4.5...      an arbitrary object id
  -v, --verbose       show verbose debug output
  -q, --quiet         suppress command output

トラストアンカーをシステム全体のトラストストアに保存するには、trust anchor サブコマンドを使用し、証明書の path.to を指定します。以下に例を示します。

# trust anchor path.to/certificate.crt

証明書を削除するには、証明書の path.to、または証明書の ID を使用します。

# trust anchor --remove path.to/certificate.crt
# trust anchor --remove "pkcs11:id=%AA%BB%CC%DD%EE;type=cert"

4.14.4. 関連情報

詳細は、以下の man ページを参照してください。

update-ca-trust(8)
trust(1)

4.15. MACsec の使用

MACsec (Media Access Control Security (IEEE 802.1AE)) は、LAN におけるすべてのトラフィックを、GCM-AES-128 アルゴリズムで認証します。MACsec は、IP だけでなく、ARP (Address Resolution Protocol)、ND (Neighbor Discovery) または DHCP も保護できます。IPsec は、ネットワークレイヤー (レイヤー 3)、およびアプリケーションレイヤー (レイヤー 7) の SSL または TLS で動作しますが、MACsec はデータリンクレイヤー (レイヤー 2) で動作します。その他のネットワークレイヤーのセキュリティープロトコルと MACsec を組み合わせて、これらの規格が提供する複数のセキュリティー機能を活用してください。

MACsec ネットワークのアーキテクチャー、ユースケースのシナリオ、および設定例の詳細については、MACsec: a different solution to encrypt network traffic の記事を参照してください。

wpa_supplicant および NetworkManager を使用して MACsec を設定する方法の例については、Red Hat Enterprise Linux 7 Networking Guide を参照してください。

4.16. scrub を使用してデータを安全に削除

scrub ユーティリティーは、特別なファイルまたはディスクデバイスにパターンを設定して、データの取得をより困難にします。scrub を使用すると、ディスクにランダムデータを書き込むよりも高速です。このプロセスは、高可用性、信頼性、およびデータ保護を提供します。

scrub コマンドを使い始めるには、scrub パッケージをインストールします。

~]# yum install scrub

scrub ユーティリティーは、次の基本モードのいずれかで動作します。

文字またはブロックデバイス

ディスク全体に対応する 特殊ファイル がスクラブされ、その上のすべてのデータが破棄されます。これが最も効果的な方法です。

scrub [OPTIONS] special file

File

通常のファイルはスクラブされ、ファイル内のデータのみが破棄されます。

scrub [OPTIONS] file

ディレクトリー

-X オプションを使用すると、ディレクトリーが作成され、ファイルシステムがいっぱいになるまで、ファイルで埋め尽くされます。次に、ファイルモードの場合と同様にファイルがスクラブされます。

scrub -X [OPTIONS] directory

例4.7 Raw デバイスのスクラブ

米国国家核安全保障局 (NNSA) のデフォルトパターンで RAW デバイス/dev/sdf1をスクラブするには、次のコマンドを入力します。

~]# scrub /dev/sdf1
scrub: using NNSA NAP-14.1-C patterns
scrub: please verify that device size below is correct!
scrub: scrubbing /dev/sdf1 1995650048 bytes (~1GB)
scrub: random  |................................................|
scrub: random  |................................................|
scrub: 0x00    |................................................|
scrub: verify  |................................................|

例4.8 ファイルのスクラブ

1MB ファイルを作成します。

~]$ base64 /dev/urandom | head -c $[ 1024*1024 ] > file.txt

ファイルサイズを表示します。

~]$ ls -lh
total 1.0M
-rw-rw-r--. 1 username username 1.0M Sep  8 15:23 file.txt

ファイルの内容を表示します。

~]$ head -1 file.txt
JnNpaTEveB/IYsbM9lhuJdw+0jKhwCIBUsxLXLAyB8uItotUlNHKKUeS/7bCRKDogEP+yJm8VQkL

ファイルをスクラブします。

~]$ scrub file.txt
scrub: using NNSA NAP-14.1-C patterns
scrub: scrubbing file.txt 1048576 bytes (~1024KB)
scrub: random  |................................................|
scrub: random  |................................................|
scrub: 0x00    |................................................|
scrub: verify  |................................................|

ファイルの内容がスクラブされていることを確認します。
```
~]$ cat file.txt
SCRUBBED!
```

ファイルサイズに変更がないことを確認します。

~]$ ls -lh
total 1.0M
-rw-rw-r--. 1 username username 1.0M Sep  8 15:24 file.txt

scrub モード、オプション、方法、および注意事項に関する詳細は、scrub(1) の man ページを参照してください。

第5章ファイアウォールの使用

5.1. `firewalld` の使用

ファイアウォール は、外部からの不要なトラフィックからマシンを保護する方法です。ファイアウォールルール セットを定義することで、ホストマシンへの着信ネットワークトラフィックを制御できます。このようなルールは、着信トラフィックを分類して、拒否または許可するために使用されます。

firewalld は、D-Bus インターフェイスを使用して、動的にカスタマイズできるホストベースのファイアウォールを提供するファイアウォールサービスデーモンです。ルールが変更するたびに、ファイアウォールデーモンを再起動しなくても、ルールの作成、変更、および削除を動的に可能にします。

firewalld は、ゾーン および サービス の概念を使用して、トラフィック管理を簡素化します。ゾーンは、事前定義したルールセットです。ネットワークインターフェイスおよびソースをゾーンに割り当てることができます。許可されているトラフィックは、コンピューターが接続するネットワークと、このネットワークが割り当てられているセキュリティーレベルに従います。ファイアウォールサービスは、特定のサービスに着信トラフィックを許可するのに必要なすべての設定を扱う事前定義のルールで、ゾーンに適用されます。

サービスは、ネットワーク接続に 1 つ以上の ポート または アドレス を使用します。ファイアウォールは、ポートに基づいて接続のフィルターを設定します。サービスに対してネットワークトラフィックを許可するには、そのポートを開く必要があります。firewalld は、明示的に開いていないポートのトラフィックをすべてブロックします。trusted などのゾーンでは、デフォルトですべてのトラフィックを許可します。

図5.1 ファイアウォールスタック

[D]

5.1.1. ゾーン

⁠firewalld は、インターフェイスに追加する信頼レベルと、そのネットワークのトラフィックに従って、複数のネットワークを複数のゾーンに分類できます。接続は、1 つのゾーンにしか指定できませんが、ゾーンは多くのネットワーク接続に使用できます。

NetworkManager は、firewalld にインターフェイスのゾーンを通知します。インターフェイスにゾーンを割り当てるには、NetworkManager と、firewall-config ツール、または firewall-cmd コマンドラインツールを使用できます。後者の 2 つは、適切な NetworkManager 設定ファイルの編集のみを行います。firewall-cmd または firewall-config を使用してインターフェイスのゾーンを変更する場合、リクエストは NetworkManager に転送され、firewalld には処理されません。

事前定義したゾーンは /usr/lib/firewalld/zones/ ディレクトリーに保存され、利用可能なネットワークインターフェイスに即座に適用されます。このファイルは、修正しないと /etc/firewalld/zones/ ディレクトリーにコピーされません。以下の表は、事前定義したゾーンのデフォルト設定について説明しています。

block: IPv4 の場合は icmp-host-prohibited メッセージ、IPv6 の場合は icmp6-adm-prohibited メッセージで、すべての着信ネットワーク接続が拒否されます。システムで開始したネットワーク接続のみが可能です。
dmz: 公開アクセスは可能ですが、内部ネットワークへのアクセスに制限がある非武装地帯にあるコンピューター向けです。選択した着信接続のみが許可されます。
drop: 着信ネットワークパケットは、通知なしで遮断されます。発信ネットワーク接続だけが可能です。
external: マスカレードをルーター用に特別に有効にした外部ネットワークでの使用向けです。自分のコンピューターを保護するため、ネットワーク上の他のコンピューターを信頼しません。選択した着信接続のみが許可されます。
home: そのネットワークでその他のコンピューターをほぼ信頼できる自宅での使用向けです。選択した着信接続のみが許可されます。
internal: そのネットワークでその他のコンピューターをほぼ信頼できる内部ネットワーク向けです。選択した着信接続のみが許可されます。
public: そのネットワークでその他のコンピューターを信頼できないパブリックエリーア向けです。選択した着信接続のみが許可されます。
trusted: すべてのネットワーク接続が許可されます。
work: そのネットワークで、その他のコンピューターをほぼ信頼できる職場での使用向けです。選択した着信接続のみが許可されます。

このゾーンのいずれかを デフォルト ゾーンに設定できます。インターフェイス接続を NetworkManager に追加すると、デフォルトゾーンに割り当てられます。firewalld のデフォルトゾーンは、インストール時に public ゾーンに設定されます。デフォルトゾーンは変更できます。

注記

ネットワークゾーン名は、分かりやすく、ユーザーが妥当な決定をすばやく下せるような名前が付けられています。セキュリティー問題を回避するために、ニーズおよびリスク評価に合わせて、デフォルトゾーンの設定の見直しを行ったり、不要なサービスを無効にしてください。

5.1.2. 事前定義サービス

サービスが、ローカルポート、プロトコル、ソースポート、宛先、そしてサービスが有効になると自動的に読み込まれるファイアウォールのヘルパーモジュールの一覧を指す場合があります。サービスを使用すると、ポートのオープン、プロトコルの定義、パケット転送の有効化などを 1 つ 1 つ行うのではなく、1 回のステップで定義できます。

サービス設定オプションと、一般的なファイル情報は、man ページの firewalld.service(5) で説明されています。サービスは、個々の XML 設定ファイルを使用して指定し、名前は、service-name.xml のような形式になります。プロトコル名は、firewalld のサービス名またはアプリケーション名よりも優先されます。

5.1.3. ランタイムおよび永続化の設定

runtime モードで行った変更は、firewalld が実行している間しか適用されません。firewalld を再起動すると、設定内容は 永続的 な値に戻ります。

変更した内容を再起動後も持続させる場合は、--permanent オプションを使用して適用します。firewalld が実行している間だけ変更を持続させる場合は、--runtime-to-permanent firewall-cmd オプションを使用します。

--permanent オプションのみを使用して firewalld を実行している場合にルールを設定すると、firewalld が再起動するまで有効にはなりません。ただし、firewalld を再起動すると、開いているポートがすべて閉じ、ネットワーキングトラフィックを停止します。

5.1.4. CLI を使用したランタイムおよび永続化の設定の変更

CLI では、2 つのモードのファイアウォール設定を同時に修正することができません。CLI では、ランタイムまたは永続モードを修正します。永続化モードでファイアウォール設定を修正するには、firewall-cmd コマンドで --permanent オプションを使用します。

~]# firewall-cmd --permanent <other options>

このオプションを使用しないと、コマンドはランタイムモードを変更します。

両方のモードで設定を変更する場合は、2 つの方法を使用できます。

以下のように、ランタイム設定を変更して、永続化します。
```
~]# firewall-cmd <other options>
~]# firewall-cmd --runtime-to-permanent
```
永続的な設定を行い、ランタイムモードで設定を再ロードします。
```
~]# firewall-cmd --permanent <other options>
~]# firewall-cmd --reload
```

最初の方法では、永続モードで設定を適用する前に、設定をテストできます。

注記

特にリモートシステムでは、設定を間違えると、ユーザーが自身をロックする結果となります。そのような状況を回避するには、--timeout オプションを使用します。指定した時間が経つと、変更は元に戻ります。このオプションを使用した場合は、--permanent オプションが無効になります。

たとえば、15 分間 SSH サービスを追加するには、次のコマンドを実行します。

~]# firewall-cmd --add-service=ssh --timeout 15m

5.2. firewall-config GUI 設定ツールのインストール

firewall-config GUI 設定ツールを使用するには、firewall-config パッケージを root でインストールします。

~]# yum install firewall-config

または、GNOME で、Super キーを使用して Software と入力し、Software Sources アプリケーションを起動します。右上隅の検索ボタンを選択すると表示される検索ボックスに、firewall と入力します。検索結果から Firewall アイテムを選択し、Install ボタンをクリックします。

firewall-config を実行するために、firewall-config コマンドを実行するか、Super キーを押してアクティビティーの概要に入り、firewall を入力して Enter を押します。

5.3. `firewalld` の現在の状況および設定の表示

5.3.1. `firewalld` の現在の状況の表示

ファイアウォールサービス firewalld は、システムにデフォルトでインストールされています。CLI インターフェイス firewalld を使用して、サービスが実行していることを確認します。

サービスの状況を表示するには、次のコマンドを実行します。

~]# firewall-cmd --state

サービスの状況の詳細は、systemctl status サブコマンドを実行します。

~]# systemctl status firewalld
firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor pr
   Active: active (running) since Mon 2017-12-18 16:05:15 CET; 50min ago
     Docs: man:firewalld(1)
 Main PID: 705 (firewalld)
    Tasks: 2 (limit: 4915)
   CGroup: /system.slice/firewalld.service
           └─705 /usr/bin/python3 -Es /usr/sbin/firewalld --nofork --nopid

さらに、設定を編集する前に、firewalld の設定方法と、適用されているルールを確認することが重要です。ファイアウォール設定を表示する場合は、「現在の firewalld 設定の表示」を参照してください。

5.3.2. 現在の `firewalld` 設定の表示

5.3.2.1. GUI を使用して許可されるサービスの表示

グラフィカルの firewall-config ツールを使用してサービスの一覧を表示する場合は、Super キーを押してアクティビティーの概要を開き、firewall と入力して Enter を押します。firewall-config ツールが表示されます。Services タブの下にサービスの一覧が表示されます。

もしくは、コマンドラインを使用してグラフィカルなファイアウォール設定ツールを起動する場合は、次のコマンドを入力します。

~]$ firewall-config

Firewall Configuration ウィンドウが開きます。このコマンドは通常のユーザーとして実行できますが、監理者パスワードが求められる場合もあります。

図5.2 firewall-config のサービスタブ

[D]

5.3.2.2. CLI を使用した `firewalld` 設定の表示

CLI クライアントで、現在のファイアウォール設定を、複数の方法で表示できます。--list-all オプションは、firewalld 設定の完全概要を表示します。

firewalld は、ゾーンを使用してトラフィックを管理します。--zone オプションでゾーンを指定しないと、コマンドは、アクティブネットワークインターフェイスおよび接続に割り当てたデフォルトゾーンに対して有効になります。

デフォルトゾーンに関連する情報をすべて表示するには、次のコマンドを実行します。

~]# firewall-cmd --list-all
public
  target: default
  icmp-block-inversion: no
  interfaces:
  sources:
  services: ssh dhcpv6-client
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

注記

設定を表示するゾーンを指定するには、たとえば、--zone=zone-name 引数を firewall-cmd --list-all コマンドに指定します。

~]# firewall-cmd --list-all --zone=home
home
  target: default
  icmp-block-inversion: no
  interfaces:
  sources:
  services: ssh mdns samba-client dhcpv6-client
... [output truncated]

サービス、ポートなど、特定情報の設定を確認するには、特定のオプションを使用します。man ページの firewalld か、コマンドの help でオプションの一覧を表示します。

~]# firewall-cmd --help

Usage: firewall-cmd [OPTIONS...]

General Options
  -h, --help           Prints a short help text and exists
  -V, --version        Print the version string of firewalld
  -q, --quiet          Do not print status messages

Status Options
  --state              Return and print firewalld state
  --reload             Reload firewall and keep state information
... [output truncated]

たとえば、現在のゾーンで許可されているサービスを表示します。

~]# firewall-cmd --list-services
ssh dhcpv6-client

CLI ツールを使用して一覧表示した特定のサブパートの設定は、解釈が難しいことがしばしばあります。たとえば、firewalld で SSH サービスを許可し、そのサービスに必要なポート (22) を開くことができます。許可されたサービスを一覧表示すると、一覧には SSH サービスが表示されますが、開いているポートを一覧表示しても、何も表示されません。したがって、--list-all オプションを使用して、完全な情報を取得することが推奨されます。

5.4. `firewalld` の起動

firewalld を開始するには、root で次のコマンドを実行します。

~]# systemctl unmask firewalld
~]# systemctl start firewalld

システムの起動時に firewalld を自動的に起動するように設定するには、root で次のコマンドを実行します。

~]# systemctl enable firewalld

5.5. `firewalld` の停止

firewalld を停止するには、root で次のコマンドを実行します。

~]# systemctl stop firewalld

システムの起動時に firewalld が自動的に起動しないようにするには、root で以下のコマンドを入力します。

~]# systemctl disable firewalld

firewalld D-Bus インターフェイスにアクセスすることで firewalld が開始されないことを確認し、そして他のサービスが firewalld を必要としているかどうかを確認するには、root で以下のコマンドを実行します。

~]# systemctl mask firewalld

5.6. トラフィックの制御

5.6.1. 事前定義サービス

サービスは、グラフィカルな firewall-config ツールと、firewall-cmd および firewall-offline-cmd を使用して追加または削除できます。

または、/etc/firewalld/services/ ディレクトリーの XML ファイルを変更できます。ユーザーがサービスを追加または変更しないと、/etc/firewalld/services/ には、対応する XML ファイルが記載されません。/usr/lib/firewalld/services/ ディレクトリーのファイルは、サービスを追加または変更する場合にテンプレートとして使用できます。

5.6.2. 緊急時に CLI を使用してすべてのトラフィックの無効化

システムへの攻撃などの緊急な状態にあるとき、すべてのネットワークトラフィックを無効にし、攻撃を遮断できます。

ネットワークトラフィックを直ちに無効にするには、パニックモードをオンにします。

~]# firewall-cmd --panic-on

パニックモードをオフにし、ファイアウォールを永続設定に戻します。パニックモードを無効にするには、次のコマンドを実行します。

~]# firewall-cmd --panic-off

パニックモードを有効または無効にするには、次のコマンドを実行します。

~]# firewall-cmd --query-panic

5.6.3. CLI を使用して事前定義されたサービスでトラフィックの制御

トラフィックを制御する最も簡単な方法は、事前定義したサービスを firewalld に追加する方法です。これにより、必要なすべてのポートが開き、service definition file に従ってその他の設定が変更されます。

サービスが許可されていないことを確認します。
```
~]# firewall-cmd --list-services
ssh dhcpv6-client
```

事前定義したサービスの一覧を表示します。

~]# firewall-cmd --get-services
RH-Satellite-6 amanda-client amanda-k5-client bacula bacula-client bitcoin bitcoin-rpc bitcoin-testnet bitcoin-testnet-rpc ceph ceph-mon cfengine condor-collector ctdb dhcp dhcpv6 dhcpv6-client dns docker-registry ...
[output truncated]

サービスを、許可されたサービスに追加します。
```
~]# firewall-cmd --add-service=<service-name>
```
新しい設定を永続化します。
```
~]# firewall-cmd --runtime-to-permanent
```

5.6.4. GUI を使用して事前定義サービスでトラフィックを制御

事前定義されたサービスまたはカスタムサービスを有効または無効にするには、firewall-config ツールを起動し、サービスを設定するネットワークゾーンを選択します。サービスタブを選択し、信頼するサービスタイプのチェックボックスをオンにします。サービスをブロックする場合は、チェックボックスをオフにします。

サービスを編集するには、firewall-config ツールを起動し、設定というラベルの付いたメニューから永続を選択します。Services ウィンドウの下部に、その他のアイコンおよびメニューボタンが表示されます。設定するサービスを選択します。

Ports、Protocols、Source Port のタブでは、選択したサービスのポート、プロトコル、およびソースポートの追加、変更、ならびに削除が可能です。モジュールタブは、Netfilter ヘルパーモジュールの設定を行います。Destination タブは、特定の送信先アドレスとインターネットプロトコル (IPv4 または IPv6) へのトラフィックが制限できます。

注記

ランタイムモードでは、サービス設定を変更できません。

5.6.5. 新しいサービスの追加

サービスは、グラフィカルな firewall-config ツールと、firewall-cmd および firewall-offline-cmd を使用して追加または削除できます。または、/etc/firewalld/services/ にある XML ファイルを編集できます。ユーザーがサービスを追加または変更しないと、対応する XML ファイルが /etc/firewalld/services/ に作成されません。/usr/lib/firewalld/services/ のファイルは、サービスを追加または変更する際にテンプレートとして使用できます。

ターミナルで新しいサービスを追加するには、firewall-cmd を使用するか、firewalld がアクティブでない場合は firewall-offline-cmd を使用します。次のコマンドを入力して、新しい空のサービスを追加します。

~]$ firewall-cmd --new-service=service-name

ローカルファイルを使用して新規サービスを追加するには、次のコマンドを使用します。

~]$ firewall-cmd --new-service-from-file=service-name.xml

追加オプション --name=service-name を指定して、サービス名を変更できます。

サービス設定を変更すると、直ちにサービスの更新コピーが /etc/firewalld/services/ に作成できます。

root で次のコマンドを実行して、サービスを手動でコピーします。

~]# cp /usr/lib/firewalld/services/service-name.xml /etc/firewalld/services/service-name.xml

firewalld は、最初に /usr/lib/firewalld/services のファイルを読み込みます。ファイルは /etc/firewalld/services に置かれ、そのファイルが有効な場合は、/usr/lib/firewalld/services で一致するファイルを上書きします。/usr/lib/firewalld/services で上書きしたファイルは、/etc/firewalld/services で一致するファイルが削除されるとすぐに、もしくはサービスのデフォルトを読み込むように firewalld が求められた場合に使用されます。これに該当するのは永続環境のみです。ランタイム環境でフォールバックさせるには、再読み込みが必要です。

5.6.6. CLI を使用したポートの制御

ポートは、オペレーティングシステムが、ネットワークトラフィックを受信し、区別し、システムサービスに従って転送する論理デバイスです。これは、通常、ポートをリッスンするデーモンにより示されますが、このポートに入るトラフィックを待ちます。

通常、システムサービスは、サービスに予約されている標準ポートでリッスンします。httpd デーモンは、たとえば、ポート 80 をリッスンします。ただし、デフォルトでは、システム管理者は、セキュリティーを強化するため、またはその他の理由により、別のポートをリッスンするようにデーモンを設定します。

ポートを開く

開かれたポートを介して、システムが外部からアクセスできます。これはセキュリティーリスクでもあります。一般的に、ポートを閉じたままにし、特定サービスに要求される場合に限り開きます。

現在のゾーンで開かれたポートの一覧を表示するには、以下を行います。

許可されているポートの一覧を表示します。
```
~]# firewall-cmd --list-ports
```
許可されているポートにポートを追加して、着信トラフィックに対してそのポートを開きます。
```
~]# firewall-cmd --add-port=port-number/port-type
```
新しい設定を永続化します。
```
~]# firewall-cmd --runtime-to-permanent
```

ポートタイプは、tcp、udp、sctp、または dccp になります。このタイプは、ネットワーク接続の種類と一致させる必要があります。

ポートを閉じる

開しているポートが必要なくなった場合に、firewalld のポートを閉じます。ポートをそのままにするとセキュリティーリスクとなるため、使用されなくなったらすぐに不要なポートを閉じることが強く推奨されます。

ポートを閉じるには、許可されているポートの一覧からそれを削除します。

許可されているポートの一覧を表示します。

~]# firewall-cmd --list-ports
[WARNING]
====
This command will only give you a list of ports that have been opened as ports. You will not be able to see any open ports that have been opened as a service. Therefore, you should consider using the --list-all option instead of --list-ports.
====

許可されているポートからポートを削除し、着信トラフィックに対して閉じます。
```
~]# firewall-cmd --remove-port=port-number/port-type
```
新しい設定を永続化します。
```
~]# firewall-cmd --runtime-to-permanent
```

5.6.7. GUI を使用してポートを開く

特定のポートへのトラフィックがファイアウォールを通過できるようにするには、firewall-config ツールを起動して、設定を変更するネットワークゾーンを選択します。右側の Ports タブを選択し、Add ボタンをクリックします。Port and Protocol ウィンドウが開きます。

許可するポート番号またはポートの範囲を入力します。リストから tcp または udp を選択します。

5.6.8. GUI を使用してプロトコルを使用したトラフィックの制御

特定のプロトコルを使用してファイアウォールを通過するトラフィックを許可するには、firewall-config ツールを起動し、設定を変更するネットワークゾーンを選択します。右側で Protocols タブを選択し、Add ボタンをクリックします。Protocol ウィンドウが開きます。

リストからプロトコルを選択するか、Other Protocol チェックボックスを選択し、そのフィールドにプロトコルを入力します。

5.6.9. GUI を使用してソースポートを開く

特定のポートからのトラフィックがファイアウォールを通過できるようにするには、firewall-config ツールを起動して、設定を変更するネットワークゾーンを選択します。右側の Source Port タブを選択し、Add ボタンをクリックします。Source Port ウィンドウが開きます。

許可するポート番号またはポートの範囲を入力します。リストから tcp または udp を選択します。

5.7. ゾーンの使用

ゾーンは、着信トラフィックをより透過的に管理する概念を表しています。ゾーンはネットワークインターフェイスに接続されているか、ソースアドレスの範囲に割り当てられます。各ゾーンは個別にファイアウォールルールを管理しますが、これにより、複雑なファイアウォール設定を定義してトラフィックに割り当てることができます。

5.7.1. ゾーンの一覧

システムで利用可能なゾーンを確認するには、次のコマンドを実行します。

~]# firewall-cmd --get-zones

firewall-cmd --get-zones コマンドは、システムで利用可能な全てのゾーンを表示し、特定ゾーンの詳細は表示しません。

すべてのゾーンで詳細情報を表示する場合は、次のコマンドを実行します。

~]# firewall-cmd --list-all-zones

特定ゾーンに関する詳細情報を表示する場合は、次のコマンドを実行します。

~]# firewall-cmd --zone=zone-name --list-all

5.7.2. 特定ゾーンに対する `firewalld` 設定の修正

「CLI を使用して事前定義されたサービスでトラフィックの制御」および「CLI を使用したポートの制御」は、現在作業中のゾーンの範囲にサービスを追加するか、またはゾーンの範囲にあるポートを修正する方法を説明します。別のゾーンへのルールの設定が必要になる場合もあります。

別のゾーンに指定するには、--zone=zone-name オプションを使用します。たとえば、public ゾーンで SSH サービスを許可するには、次のコマンドを実行します。

~]# firewall-cmd --add-service=ssh --zone=public

5.7.3. デフォルトゾーンの変更

システム管理者は、設定ファイルのネットワークインターフェイスにゾーンを割り当てます。特定のゾーンに割り当てられないインターフェイスは、デフォルトゾーンに割り当てられます。firewalld サービスを再起動するたびに、firewalld は、デフォルトゾーンの設定を読み込み、それをアクティブにします。

デフォルトゾーンを設定するには、以下を行います。

現在のデフォルトゾーンを表示します。
```
~]# firewall-cmd --get-default-zone
```
新しいデフォルトゾーンを設定します。
```
~]# firewall-cmd --set-default-zone zone-name
```

注記

この手順では、--permanent オプションを使用しなくても、設定は永続化します。

5.7.4. ゾーンへのネットワークインターフェイスの割り当て

複数のゾーンに複数のルールセットを定義して、使用されているインターフェイスのゾーンを変更することで、迅速に設定を変更できます。各インターフェイスに特定のゾーンを設定して、そのゾーンを通過するトラフィックを設定できます。

特定インターフェイスにゾーンを割り当てるには、以下を行います。

アクティブゾーン、およびそのゾーンに割り当てられているインターフェイスを一覧表示します。
```
~]# firewall-cmd --get-active-zones
```

別のゾーンにインターフェイスを割り当てます。

~]# firewall-cmd --zone=zone-name --change-interface=<interface-name>

注記

再起動後も設定を持続させる --permanent オプションを使用する必要はありません。新しいデフォルトゾーンを設定すると、設定は永続化されます。

5.7.5. ネットワーク接続にデフォルトゾーンの割り当て

NetworkManager で接続を管理する場合は、NetworkManager が使用するゾーンを認識する必要があります。すべてのネットワーク接続にゾーンを指定できます。これにより、ポータブルデバイスを使用したコンピューターの場所に従って、様々なファイアウォールを柔軟に設定できるようになります。したがって、ゾーンおよび設定には、会社または自宅など、様々な場所を指定できます。

インターネット接続にデフォルトゾーンを設定するには、NetworkManager の GUI を使用するか、/etc/sysconfig/network-scripts/ifcfg-connection-name ファイルを変更して、この接続にゾーンを割り当てる行を追加します。

ZONE=zone-name

5.7.6. 新しいゾーンの作成

カスタムゾーンを使用するには、新しいゾーンを作成したり、事前定義したゾーンなどを使用したりします。

注記

新しいゾーンには --permanent オプションが必要となり、このオプションがなければコマンドは動作しません。

新しいゾーンを作成します。

~]# firewall-cmd --permanent --new-zone=zone-name

新しいゾーンをリロードします。
```
~]# firewall-cmd --reload
```
作成したゾーンが永続設定に追加されたかどうかを確認します。
```
~]# firewall-cmd --get-zones
```
新しい設定を永続化します。
```
~]# firewall-cmd --runtime-to-permanent
```

5.7.7. 設定ファイルを使用した新しいゾーンの作成

また、ゾーンの設定ファイル を使用してゾーンを作成できます。このアプローチは、新しいゾーンを作成する必要がある場合に、別のゾーンの設定を変更して利用する場合に便利です。

firewalld ゾーン設定ファイルには、ゾーンに対する情報があります。これは、XML ファイル形式で、ゾーンの説明、サービス、ポート、プロトコル、icmp-block、マスカレード、転送ポート、およびリッチ言語ルールです。ファイル名は zone-name.xml となります。zone-name の長さは 17 文字に制限されます。ゾーンの設定ファイルは、/usr/lib/firewalld/zones/ ディレクトリーおよび /etc/firewalld/zones/ ディレクトリーに置かれています。

以下の例は、TCP プロトコルまたは UDP プロトコルの両方に、1 つのサービス (SSH) および 1 つのポート範囲を許可する設定を示します。

<?xml version="1.0" encoding="utf-8"?>
<zone>
  <short>My zone</short>
  <description>Here you can describe the characteristic features of the zone.</description>
  <service name="ssh"/>
  <port port="1025-65535" protocol="tcp"/>
  <port port="1025-65535" protocol="udp"/>
</zone>

そのゾーンの設定を変更するには、セクションを追加または削除して、ポート、転送ポート、サービスなどを追加します。詳細は、man ページの firewalld.zone を参照してください。

5.7.8. 着信トラフィックにデフォルトの動作を設定するゾーンターゲットの使用

すべてのゾーンに対して、特に指定されていない着信トラフィックを処理するデフォルト動作を設定できます。そのような動作は、ゾーンのターゲットを設定することで定義されます。オプションは、default の ACCEPT、REJECT、および DROP の 3 つになります。ターゲットを ACCEPT に設定すると、特定ルールで無効にした着信パケット以外のパケットをすべて許可します。REJECT または DROP にターゲットを設定すると、特定のルールで許可したパケット以外の着信パケットがすべて無効になります。パケットが拒否されるとソースマシンに通知されますが、パケットが破棄される時は情報が送信されません。

ゾーンにターゲットを設定するには、以下を行います。

特定ゾーンに対する情報を一覧表示して、デフォルトゾーンを確認します。
```
~]$ firewall-cmd --zone=zone-name --list-all
```

ゾーンに新しいターゲットを設定します。

~]# firewall-cmd --zone=zone-name --set-target=<default|ACCEPT|REJECT|DROP>

5.8. ゾーンを使用し、ソースに応じた着信トラフィックの管理

ゾーンを使用して、そのソースに基づいて着信トラフィックを管理するゾーンを使用できます。これにより、着信トラフィックを分類し、複数のゾーンに向け、トラフィックにより到達できるサービスを許可または拒否できます。

ソースをゾーンに追加する場合は、ゾーンがアクティブになり、そのソースからの着信トラフィックは、それを介して行われます。各ゾーンに異なる設定を指定できますが、それは指定したソースから順次トラフィックに適用されます。ネットワークインターフェイスが 1 つしかない場合でも、複数のゾーンを使用できます。

5.8.1. ソースの追加

着信トラフィックを特定のソースに転送する場合は、そのゾーンにソースを追加します。ソースは、CIDR (Classless Inter-domain Routing) 表記法の IP アドレスまたは IP マスクになります。

現在のゾーンにソースを設定するには、次のコマンドを実行します。
```
~]# firewall-cmd --add-source=<source>
```
特定ゾーンのソース IP アドレスを設定するには、次のコマンドを実行します。
```
~]# firewall-cmd --zone=zone-name --add-source=<source>
```

以下の手順は、trusted ゾーンで 192.168.2.15 からのすべての着信トラフィックを許可します。

利用可能なゾーンの一覧を表示します。
```
~]# firewall-cmd --get-zones
```
永続化モードで、信頼ゾーンにソース IP を追加します。
```
~]# firewall-cmd --zone=trusted --add-source=192.168.2.15
```
新しい設定を永続化します。
```
~]# firewall-cmd --runtime-to-permanent
```

5.8.2. ソースの削除

ゾーンからソースを削除すると、そのゾーンからのトラフィックを遮断します。

必要なゾーンに対して許可されているソースの一覧を表示します。
```
~]# firewall-cmd --zone=zone-name --list-sources
```

ゾーンからソースを永続的に削除します。

~]# firewall-cmd --zone=zone-name --remove-source=<source>

新しい設定を永続化します。
```
~]# firewall-cmd --runtime-to-permanent
```

5.8.3. ソースポートの追加

発信源となるポートに基づいたトラフィックの分類を有効にするには、--add-source-port オプションを使用してソースポートを指定します。--add-source オプションと組み合わせて、トラフィックを特定の IP アドレスまたは IP 範囲に制限できます。

ソースポートを追加するには、次のコマンドを実行します。

~]# firewall-cmd --zone=zone-name --add-source-port=<port-name>/<tcp|udp|sctp|dccp>

5.8.4. ソースポートの削除

ソースポートを削除して、送信元ポートに基づいてトラフィックの分類を無効にします。

ソースポートを削除するには、次のコマンドを実行します。

~]# firewall-cmd --zone=zone-name --remove-source-port=<port-name>/<tcp|udp|sctp|dccp>

5.8.5. ゾーンおよびソースを使用して特定ドメインのみに対してサービスの許可

特定のネットワークからのトラフィックを許可して、マシンのサービスを使用するには、ゾーンおよびソースを使用します。以下の手順では、他のトラフィックがブロックされている間に 192.0.2.0/24 ネットワークからの HTTP トラフィックのみを許可します。

警告

このシナリオを設定する場合は、default のターゲットを持つゾーンを使用します。192.0.2.0/24 からのトラフィックではネットワーク接続がすべて許可されるため、ターゲットが ACCEPT に設定されたゾーンを使用することは、セキュリティー上のリスクになります。

利用可能なゾーンの一覧を表示します。

~]# firewall-cmd --get-zones
block dmz drop external home internal public trusted work

IP 範囲を internal ゾーンに追加し、ソースから発信されるトラフィックをゾーン経由でルーティングします。
```
~]# firewall-cmd --zone=internal --add-source=192.0.2.0/24
```
http サービスを internal ゾーンに追加します。
```
~]# firewall-cmd --zone=internal --add-service=http
```
新しい設定を永続化します。
```
~]# firewall-cmd --runtime-to-permanent
```

internal ゾーンがアクティブで、サービスが許可されていることを確認します。

~]# firewall-cmd --zone=internal --list-all
internal (active)
  target: default
  icmp-block-inversion: no
  interfaces:
  sources: 192.0.2.0/24
  services: dhcpv6-client mdns samba-client ssh

Language and Page Formatting Options

Red Hat Training

セキュリティーガイド

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

第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. リムーバブルメディアの読み取り専用マウントの強制

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

新しい udev 設定の適用

4.2. Root アクセスの制御

4.2.1. Root アクセスの拒否

4.2.2. Root アクセスの許可

4.2.3. Root アクセスの制限

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

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

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

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

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

`nullok` オプションの削除

4.3.6.3. `/var/yp/securenets` ファイルを編集する