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 は長年にわたって利用されており、情報収集を行う際におそらく最もよく使われるツールです。優れた man ページは、そのオプションと使用方法の詳細な説明を提供します。管理者は、ネットワーク上で 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] これは、管理者の経験の少なさだけでなく、管理者の過信やモチベーションの低さなども原因となります。

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

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

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

安全ではないネットワークサービスのカテゴリーの 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

シェル glob を使用して、複数のパッケージを一度にインストールします。たとえば、以下のコマンドを実行すると、現行ディレクトリーにすべての .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コマンドを使って行うことができます。

systemctl restart service_name

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

他のソフトウェア

以下のアプリケーションを正しく更新するには、リソースにリンクされている手順にしたがいます。

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

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

https://access.redhat.com/の Red Hat Customer Portal は、Red Hat 製品に関連する公式情報を提供するお客様向けのメインリソースです。これを使用して、ドキュメントの検索、サブスクリプションの管理、製品およびアップデートのダウンロード、サポートケースの作成、およびセキュリティー更新の詳細を確認できます。

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

お客様が有効なサブスクリプションをお持ちのシステムに関連するセキュリティ勧告（エラッタ）を表示するには、カスタマーポータル（https://access.redhat.com/）にログインし、メインページの「Download Products & Updates」ボタンをクリックしてください。Software & Download Center ページを入力したら、エラータボタンをクリックして、登録したシステムに関連するアドバイザリーのリストを確認します。

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

テーブルの左側にあるエラータコードをクリックし、個別のアドバイザリーに関する詳細情報を表示します。次のページには、原因、結果、必要な修正など、指定のエラータの説明だけでなく、更新の適用方法を説明する特定のパッケージの一覧も含まれます。このページには、関連するCVEなどの参考文献へのリンクもあります。

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

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

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

3.2.3. 問題の影響度の分類について

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

これらの評価は、セキュリティーの問題の影響度を理解するのに役立ち、システムのアップグレードストラテジーをスケジュールおよび優先順位付けできます。評価は、現在の脅威レベルではなく、バグの技術的な分析に基づく、特定の脆弱性の潜在的なリスクを反映しています。つまり、特定の不具合に対して悪用がリリースされても、セキュリティーの影響度評価は変更されません。

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

3.3. 関連情報

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

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

yum(8) -Yumパッケージマネージャーのマニュアルページでは、システムへのパッケージのインストール、アップデート、削除にYumを使用する方法についての情報を提供しています。
rpmkeys(8) -rpmkeysユーティリティのマニュアルページでは、ダウンロードしたパッケージの信頼性を確認するためにこのプログラムを使用する方法が説明されています。

オンラインドキュメント

Red Hat Enterprise Linux 7 システム管理者ガイド- Red Hat Enterprise Linux 7 の『システム管理者ガイド』では、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 Security Blog- Red Hat のセキュリティ専門家による最新のセキュリティ関連問題に関する記事です。

第4章ツールとサービスを使用したシステムの強化

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

Red Hat Enterprise Linux 7 は、攻撃に対してデスクトップを強化し、不正アクセスを阻止する方法が複数あります。本セクションでは、ユーザーパスワード、セッション、アカウントロック、およびリムーバブルメディアの安全な処理に推奨されるプラクティスを説明します。

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

パスワードは、Red Hat Enterprise Linux 7 がユーザーのアイデンティティーの検証に使用する主要な方法です。このため、パスワードセキュリティーはユーザー、ワークステーション、およびネットワークを保護する上で重要なことです。

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

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

シャドウパスワードは、パスワードのハッシュを、rootユーザーのみが読めるファイル/etc/shadowに保存することで、このタイプの攻撃を防ぎます。

これにより、SSH や FTP などのマシンのネットワークサービスにログインして、潜在的な攻撃者がパスワードクラッキングをリモートで試行します。このブルートフォース攻撃のこのソートは大幅に遅くなるため、数百ものログイン試行がシステムファイルに書き込まれます。当然ながら、クラッカーが弱いパスワードを持つシステムの夜間において攻撃を開始すると、クラッカーがダッシュダウン前にアクセスを取得でき、ログファイルを編集することで追跡をカバーします。

フォーマットやストレージの考慮事項は、コンテンツに関する問題です。1 つの重要なことは、パスワードクラッキング攻撃に対してアカウントを保護する上で、強力なパスワードを作成することです。

注記

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

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

セキュアなパスワードを作成する場合は、長いパスワードは短いパスワードよりも強力で複雑なものであることを覚えている必要があります。数字、特殊文字、および大文字が含まれる場合でも、8 文字のみのパスワードを作成することが推奨されます。John(John The Ripper)などのパスワードクラッキングツールは、このようなパスワードに最適化されています。これは、人にとって覚えておくのが困難です。

理論上は、エントロピーはランダム変数に関連付けられた未認定のレベルであり、ビットで表示されます。エントロピー値が大きくなると、パスワードのセキュリティーが強化されます。NIST SP 800-63-1 に従い、一般的に選択した 50000 のパスワードが、少なくとも 10 ビットのエントロピーを持つ必要があります。そのため、4 つのランダムな単語で構成されるパスワードには約 40 ビットのエントロピーが含まれています。セキュリティを高めるために複数の単語で構成された長いパスワードは、パスフレーズなどとも呼ばれます。

randomword1 randomword2 randomword3 randomword4

システムで大文字、数字、特殊文字の使用が強制されている場合は、上記の推奨事項に従ったパスフレーズを簡単な方法で変更することができます。たとえば、最初の文字を大文字に変更し、「1！」を追加します。なお、このような変更を行っても、パスフレーズの安全性が大きく向上するわけではありません。

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

pwmake 128

セキュアなパスワードを作成する方法は複数ありますが、常に以下の不適切なプラクティスを回避します。

1 つのディクショナリー単語を使用すると、外部言語の単語、語句、または数字のみを使用します。
パスワードまたはパスフレーズに 10 文字未満を使用してください。
キーボードレイアウトからのキーシーケンスを使用します。
パスフレーズを書き留める。
個人情報（birth dates、Aniversaries、ファミリーメンバー名、pet 名など）を使用して、パスワードで個人情報を使用します。
複数のマシンで同じパスフレーズまたはパスワードを使用します。

セキュアなパスワードの作成は不変ですが、特に大規模な組織内のシステム管理者では、適切に管理することが重要になります。以下のセクションでは、組織内でユーザーパスワードを作成および管理する方法を説明します。

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

組織にユーザーが多数ある場合、システム管理者は、強固なパスワードの使用を強制するために 2 つの基本的なオプションがあります。ユーザーのパスワードを作成したり、パスワードが適切に強調されていることを検証しつつ、パスワードの作成を許可することができます。

ユーザーのパスワードを作成すると、パスワードが適切であることを確認できますが、組織が拡大するタスクになります。また、パスワードを書き込むユーザーのリスクも高くなるため、これらを公開します。

このような理由により、システム管理者は、ユーザーが独自のパスワードを作成することをお勧めしますが、このパスワードが十分に強調されていることを確認します。管理者がパスワードエージングを通じて定期的にパスワードを変更するように強制する場合もあります。

ユーザーがパスワードの作成や変更を求められた場合、PAM対応(Pluggable Authentication Modules)のコマンドラインユーティリティpasswdを使用して、パスワードが短すぎたり、解明されやすいものでないかどうかをチェックすることができます。このチェックは、PAMモジュールのpam_pwquality.soによって行われます。

注記

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

pam_pwqualityモジュールは、一連のルールに照らし合わせてパスワードの強度をチェックするために使用されます。この手順は、最初に指定したパスワードがディクショナリーで見つかったかどうかを確認する 2 つの手順で構成されます。そうでない場合は、追加のチェックが多数続きます。pam_pwqualityは、/etc/pam.d/passwdファイルのpasswordコンポーネントで他の PAM モジュールと一緒にスタックされ、カスタムルールのセットは/etc/security/pwquality.conf設定ファイルで指定されます。これらのチェックの完全なリストは、pwquality.conf (8)のマニュアルページを参照してください。

例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 システム管理者ガイド』を参照してください。

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` 日	パスワードが有効な最大日数を指定します。このオプションで指定された日数に`-d`オプションで指定された日数を加えた値が現在の日よりも少ない場合、ユーザーはアカウントを使用する前にパスワードを変更する必要があります。
`-W` 日	ユーザーに警告するパスワード失効日までの日数を指定します。

また、対話モードで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 パスワードでアカウントのロックを解除します。
rootで以下のコマンドを実行することで、パスワードの即時失効を強制することができます。
```
chage -d 0 username
```
このコマンドは、パスワードが最後にエポック（1970 年 1 月 1 日）に変更された日付の値を設定します。この値は、パスワードエージングポリシー（ある場合）に関係なく、パスワードの有効期限を強制します。

初回ログイン時に、新しいパスワードの入力が求められます。

4.1.2. アカウントのロック

Red Hat Enterprise Linux 7 では、pam_faillockPAM モジュールにより、システム管理者は指定された回数の試行が失敗するとユーザーアカウントをロックアウトすることができます。ユーザーのログイン試行を制限することは、主にユーザーのアカウントパスワードの取得を目的とするブルートフォース攻撃の攻撃を防ぐことを目指しています。

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 が追加されました。
前述の2つのファイルのaccountセクションに以下の行を追加します。
```
account     required      pam_faillock.so
```

ルートユーザーにもアカウントロックを適用するには、/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

ユーザーごとに失敗した回数を表示するには、ルートとして次のコマンドを実行します。

~]$ 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用に設定すべきではありません。詳しくは、KCS（Knowledge Centered Support）ソリューションをご覧ください。

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文字列を削除します。

nullokオプションを使うと、ユーザーはパスワードを入力せずにログインできますか？詳細については、KCS ソリューションを参照してください。

4.1.3. セッションのロック

日常の操作時に多くの理由でワークステーションを無人のままにする必要があるかもしれません。これは、特に物理的なセキュリティ対策が不十分な環境では、攻撃者がマシンに物理的にアクセスする機会となる可能性があります（「物理的コントロール」参照）。ノートパソコンは、物理的なセキュリティーに干渉するため、とくにさらされます。正しいパスワードの入力が完了するまで、システムへのアクセスを防ぐセッションロック機能を使用することで、このリスクを軽減できます。

注記

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

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

ユーザーは、仮想コンソールをロックする必要がある場合もあります。これには、vlockというユーティリティーを使用します。このユーティリティーをインストールするには、root で以下のコマンドを実行します。

~]# yum install vlock

インストール後は、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として直接ログインできないようにするには、システム管理者が/etc/passwdファイルでrootアカウントのシェルを/sbin/nologinに設定します。

表4.2 Root シェルの無効化

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

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

rootアカウントへのアクセスをさらに制限するために、管理者は/etc/securettyファイルを編集してコンソールでのrootログインを無効にすることができます。このファイルには、rootユーザーがログインを許可されているすべてのデバイスが一覧表示されています。ファイルが全く存在しない場合、ルートユーザーは、コンソールや生のネットワークインターフェースなど、システム上のあらゆる通信デバイスからログインすることができます。これは危険なことです。というのも、ユーザーはTelnetを使って自分のマシンにrootとしてログインすることができるからです。Telnetはパスワードを平文でネットワーク上に送信します。

デフォルトでは、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プロトコルによるルートログインを防止するには、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モジュールを通じて、特定のアカウントを非常に柔軟に拒否することができます。管理者はこのモジュールを使用して、ログインが許可されていないユーザーのリストを参照できます。システムサービスへのルートアクセスを制限するには、/etc/pam.d/ディレクトリ内の対象サービスのファイルを編集し、認証にpam_listfile.soモジュールが必要であることを確認します。

以下は、PAM設定ファイル/etc/pam.d/vsftpdの中で、FTPサーバー「vsftpd」にモジュールを使用した例です（1行目の最後にある「-」は、ディレクティブが1行の場合は不要です）。

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

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

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

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

表4.5 PAM を使用した root の無効化

影響あり	影響なし
PAMを意識したネットワークサービスへの`ルート`アクセスを防ぎます。以下のサービスは、rootアカウントへのアクセスが禁止されています。 login gdm kdm xdm ssh scp sftp FTP クライアント Email クライアントすべての PAM 対応サービス	PAM に対応していないプログラムやサービス

4.2.2. Root アクセスの許可

組織内のユーザーが信頼されていて、コンピュータに詳しい場合は、ルートアクセスを許可しても問題はないでしょう。ユーザーによるrootアクセスを可能にすることで、デバイスの追加やネットワークインターフェースの設定などの細かい作業を個々のユーザーが行うことができ、システム管理者はネットワークセキュリティやその他の重要な問題に対処することができます。

一方で、個々のユーザーにroot権限を与えると、以下のような問題が発生します。

マシンの誤設定-ルートアクセス権を持つユーザーがマシンを誤設定し、問題解決のためのサポートが必要になることがあります。それでも気づかれでも、セキュリティーマースを知らなくても、セキュリティーホールが開かれる可能性があります。
安全でないサービスの実行-root権限を持つユーザーは、マシン上でFTPやTelnetなどの安全でないサーバーを実行する可能性があり、ユーザー名やパスワードが危険にさらされる可能性があります。これらのサービスは、ネットワークにこの情報をプレーンテキストで送信します。
電子メールの添付ファイルをRootとして実行する- まれにですが、Linuxに影響を与える電子メールウイルスが存在します。悪意のあるプログラムが最大の脅威となるのは、ルートユーザーによって実行される場合です。
監査証跡の維持- 複数のシステム管理者がシステムを維持できるように、ルートアカウントは複数のユーザーで共有されることが多いため、ある時点でどのユーザーがルートだったのかを把握することは不可能です。個別のログインを使用する場合は、ユーザーのログイン、セッション追跡の目的で一意の番号が置かれ、ユーザーが起動するすべてのプロセスによって継承されるタスク構造に置かれます。同時ログインを使用する場合は、一意の番号を使用して、特定のログインに対してアクションを追跡できます。アクションが監査イベントを生成すると、ログインアカウントと、その一意の番号に関連付けられたセッションで記録されます。これらのログインとセッションを表示するには、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 ブートローダーをパスワードで保護する主な理由は以下のとおりです。

シングルユーザーモードへのアクセスの防止- 攻撃者がシステムをシングルユーザーモードで起動することができると、ルートパスワードの入力を求められることなく、自動的にルートとしてログインされてしまいます。
警告
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コマンドを使用して情報を収集したりすることができます。
安全でないOSへのアクセスの防止- デュアルブートシステムの場合、攻撃者は起動時にDOSなどのOSを選択し、アクセスコントロールやファイルのパーミッションを無視することができます。

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 には、リンクの作成またはその後に特定の条件を満たすことができる機能が含まれています。

ハードリンクの場合は、以下のいずれかが true である必要があります。

ユーザーは、リンク先のファイルを所有します。
ユーザーは、リンクするファイルへの読み書きアクセスがすでに付与されています。

シンボリックリンクの場合、プロセスは、Sticky ビットを持つ誰でも書き込み可能なディレクトリー外、または以下の 1 つが true である、書き込み可能なディレクトリー外にある場合にのみリンクをフォローできるようにします。

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

この保護は、デフォルトでオンになっています。これは、/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) のマニュアルページを参照してください。

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

管理制御へのユーザーアクセスは、組織内のシステム管理者にとって重要な問題ですが、どのネットワークサービスがアクティブであることをモニタリングしても、Linux システムを管理および運用するユーザーにとって準仮想化の重要性があります。

Red Hat Enterprise Linux 7 のサービスの多くは、ネットワークサーバーです。ネットワークサービスがマシン上で実行されている場合、（デーモンと呼ばれる）サーバーアプリケーションが、1つまたは複数のネットワークポートで接続を待ち受けています。これらの各サーバーは、攻撃の可能性として扱う必要があります。

4.3.1. サービスへのリスク

ネットワークサービスは、Linux システムに対する多くのリスクを引き起こす可能性があります。以下は、主要な問題の一覧です。

サービス拒否攻撃（DoS） - サービスにリクエストを殺到させることで、各リクエストを記録して応答しようとするシステムを使用不能にするサービス拒否攻撃。
分散型サービス拒否攻撃（DDoS） - DoS攻撃の一種で、危険にさらされた複数のマシン（多くの場合、数千台以上）を使ってサービスに協調した攻撃を行い、リクエストを殺到させて使用不能にするもの。
スクリプトの脆弱性への攻撃 - Webサーバのように、サーバ側のアクションを実行するためにスクリプトを使用している場合、攻撃者は不適切に書かれたスクリプトを標的にすることができます。これらのスクリプトの脆弱性攻撃により、バッファーオーバーフロー条件が発生したり、攻撃者がシステム上のファイルを変更できるようになります。
バッファオーバーフロー攻撃- ポート1～1023をリッスンするサービスは、管理者権限で起動するか、CAP_NET_BIND_SERVICEケイパビリティが設定されている必要があります。プロセスがポートにバインドされ、そのプロセスがリッスンすると、権限または機能がドロップされることになります。権限や機能が破棄されず、アプリケーションに悪用可能なバッファーオーバーフローがある場合、攻撃者はデーモンを実行しているユーザーとしてシステムにアクセスできるようになります。悪用可能なバッファーオーバーフローが存在するため、クラッカーは自動ツールを使用して脆弱性のシステムを特定し、アクセスできたら、自動化された root キットを使用してシステムへのアクセスを維持します。

注記

バッファオーバーフローの脆弱性の脅威は、Red Hat Enterprise Linux 7 では、x86 互換のユニプロセッサおよびマルチプロセッサのカーネルでサポートされている実行可能なメモリのセグメンテーションおよび保護テクノロジーであるExecShield によって軽減されています。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- Telnet に代わる安全な OpenSSH サーバーです。

これらのサービスを実行したままにするかどうかを決定する際には、一般的な意味を使用し、リスクが行われないようにすることが推奨されます。たとえば、プリンターが利用できない場合は、cupsを起動したままにしないでください。同じことは portreserve についても言えます。NFSv3ボリュームのマウントやNIS（ypbindサービス）を使用しない場合は、rpcbindを無効にしてください。システムの起動時にどのネットワークサービスを開始するかを確認するだけでは不十分です。開かれているポートとリッスンしているポートを確認することが推奨されます。詳細は、「リッスンしているポートの確認」を参照してください。

4.3.3. 安全でないサービス

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

ネットワークプロトコルによっては、他のプロトコルよりも安全性が低くなります。以下の動作を実行するサービスがそれに当たります。

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

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

すべてのリモートログインとシェルプログラム（rlogin、rsh、telnet）は、SSHを使用することをお勧めします。sshd の詳細に関しては、「SSH のセキュア化」を参照してください。

FTPは、リモートシェルのようにシステムのセキュリティにとって本質的に危険なものではないが、問題を回避するためには、FTPサーバーを注意深く設定し、監視する必要がある。FTP サーバーのセキュア化に関する詳細については、「FTP のセキュア化」を参照してください。

ファイアウォールの内側では、慎重に実装すべきサービスには以下が含まれます。

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

ネットワークサービスの安全性確保に関する詳細は、「ネットワークアクセスのセキュア化」をご覧ください。

4.3.4. rpcbind のセキュア化

rpcbindサービスは、NISやNFSなどのRPCサービス用の動的ポート割り当てデーモンです。認証メカニズムは弱くなり、制御するサービスに幅広いポートを割り当てることができます。このような理由から、安全性は困難です。

注記

NFSv4ではrpcbindが不要になったため、rpcbindの保護はNFSv2およびNFSv3の実装にのみ影響します。NFSv2またはNFSv3サーバーの実装を計画している場合は、rpcbindが必要であり、次のセクションが適用されます。

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

4.3.4.1. TCP Wrapper による rpcbind の保護

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

また、サービスへのアクセスを制限する際には、IPアドレスのみを使用してください。ホスト名は、DNS ポイズニングや他のメソッドによる使用を可能にするため、使用しないでください。

4.3.4.2. firewalld による rpcbind の保護

rpcbindサービスへのアクセスをさらに制限するには、サーバーにfirewalldルールを追加して、特定のネットワークへのアクセスを制限するのがよいでしょう。

以下は、firewalld リッチ言語コマンドの 2 つの例です。1つ目は、192.168.0.0/24ネットワークからポート111番（rpcbindサービスが使用）へのTCP接続を許可するものです。2 つ目は、ローカルホストから同じポートへの 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 MOUNTプロトコルのサーバー側を実装しています。このプロトコルは、NFSバージョン2(『RFC 1904』)とNFSバージョン3(『RFC 1813』).

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

4.3.5.1. TCP Wrapper で rpc.mountd の保護

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

また、サービスへのアクセスを制限する際には、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. NFS のセキュア化

NIS（ Network Information Service）は、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 ドメイン内のマシンは、NIS サーバーの DNS ホスト名と NIS ドメイン名を認識している限り、認証なしでサーバーから情報を抽出できます。

例えば、誰かがラップトップコンピュータをネットワークに接続するか、外部からネットワークに侵入する（そして内部のIPアドレスを偽装することに成功する）と、次のようなコマンドで/etc/passwdマップが明らかになります。

ypcat -d <NIS_domain> -h <DNS_hostname> passwd

この攻撃者がルートユーザーの場合、次のコマンドを入力することで、/etc/shadowファイルを取得できます。

ypcat -d <NIS_domain> -h <DNS_hostname> shadow

注記

Kerberosを使用している場合、/etc/shadowファイルはNISマップ内に保存されません。

攻撃者にとってNISマップへのアクセスを困難にするために、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. 静的ポートの割り当てとリッチ言語ルールの使用

rpc.yppasswdd（ユーザーがログインパスワードを変更するためのデーモン）を除き、NISに関連するすべてのサーバーに特定のポートを割り当てることができます。他の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 Storage Administration Guide』の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オプションは特に必要な場合のみ使用してください。詳細は、manexports(5)のページを参照してください。書き込みアクセスが許可されると、シンボリックリンク攻撃のリスクが高まります。これには、/tmpや/usr/tmpなどの一時的なディレクトリも含まれます。

ディレクトリをrwオプションでマウントする必要がある場合、リスクを減らすために可能な限りワールドライタブルにしないようにしてください。ホームディレクトリーのエクスポートは、クリアテキストでパスワードを保存する、または弱い暗号化でパスワードを保存するため、リスクとして見えます。アプリケーションコードのレビューおよび改善により、このリスクが軽減されます。SSH 鍵にパスワードを設定していないユーザーも、ホームディレクトリーのリスクが発生することを意味します。パスワードの使用を強制したり Kerberos を使用して強制すると、そのリスクが軽減されます。

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

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

secureオプションは、「予約済みの」ポートへのエクスポートを制限するために使用されるサーバー側のエクスポートオプションです。デフォルトでは、サーバは予約済みのポート（1024以下の番号のポート）からのクライアントの通信のみを許可します。これは、従来、クライアントは信頼できるコード（インカーネルのNFSクライアントなど）にのみ、これらのポートの使用を許可していたためです。ただし、多くのネットワークでは一部のクライアントで root になるのは困難なため、予約ポートからの通信が権限を必要とすると想定することはほとんどありません。したがって、予約ポートに制限があるのは限定されています。特定のクライアントへのエクスポート、ファイアウォール、および制限に依存することが推奨されます。

ほとんどのクライアントは、可能な場合は予約ポートを使用します。ただし、予約ポートは制限されたリソースであるため、クライアント（特に多数の 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オプションを使用して、「device-files」がクライアントでハードウェアデバイスとして処理されないようにします。

resvportオプションはクライアント側のマウントオプションで、secureはそれに対応するサーバー側のエクスポートオプションです（上記の説明を参照）。これは、通信を "reserved port" に制限します。予約または「well known」ポートは、root ユーザーなどの特権ユーザーとプロセス用に予約されています。このオプションを設定すると、クライアントは予約ソースポートを使用してサーバーと通信します。

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

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

NFSのマニュアルページ（man 5 nfs）には、「「SECURITY CONSIDERATIONS」」というセクションがあり、NFSv4で強化されたセキュリティについて説明されているほか、NFS特有のマウントオプションがすべて含まれています。

重要

krb5-libsパッケージで提供されているMIT Kerberosライブラリは、新規導入時にDES（Data Encryption Standard）アルゴリズムの使用をサポートしていません。セキュリティー上、および特定の互換性上の理由から、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ファイルの次の行は、ホスト名の後にスペース文字が1つあるため、ホストbob.example.comに対しては読み取り専用の権限で同じディレクトリを共有し、世界に対しては読み取り/書き込みの権限で共有しています。

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

設定されているNFS共有を確認するには、showmountコマンドを使用して、何が共有されているかを確認するのが良い方法です。

showmount -e <hostname>

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

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

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

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

NFSv4 は、Red Hat Enterprise Linux 7 のデフォルト NFS バージョンで、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 のセキュリティー保護

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

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 サーバーの設定

Apache HTTP Server は、Red Hat Enterprise Linux 7 で最も安定し、セキュアなサービスのいずれかです。Apache HTTP Server をセキュアにするには、多数のオプションや手法を使用できます。以下のセクションでは、Apache HTTP Server を実行する際の適切なプラクティスを簡単に説明します。

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

chown root <directory_name>

chmod 755 <directory_name>

システム管理者は、以下の設定オプション（/etc/httpd/conf/httpd.confで設定）を使用する際には注意が必要です。

FollowSymLinks

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

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ディレクティブを削除しないでください。デフォルトでは、SSI（ Server-Side Includes）モジュールはコマンドを実行できません。絶対的に必要でない限り、攻撃者はシステム上でコマンドを実行する可能性があるため、この設定を変更しないことが推奨されます。

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 and 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（ File Transfer Protocol）は、ネットワーク上でファイルを転送するために設計された古いTCPプロトコルです。ユーザー認証など、サーバーがあるすべてのトランザクションは暗号化されていないため、安全ではないプロトコルとみなされ、慎重に設定する必要があります。

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

Red Hat Content Accelerator(tux) - FTP機能を備えたカーネル空間のウェブサーバー。
vsftpd- スタンドアロンで、セキュリティを重視したFTPサービスの実装です。

以下のセキュリティガイドラインは、vsftpdFTPサービスを設定するためのものです。

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

ユーザー名とパスワードを送信する前に、すべてのユーザーに greeting バナーが表示されます。デフォルトでは、このバナーには、システム内の弱度を特定しようとする際に便利なバージョン情報が含まれます。

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ラッパーを使用して、受信する接続に追加のバナーを送信することも可能です。

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

匿名ユーザーがディレクトリーで読み書きできる管理者は、多くの場合、サーバーが、stolen ソフトウェアのリポジトリーとなることがよくあります。

さらに、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 Wrapper および xinetd でのサービスのセキュリティー保護」に記載されているように、TCP ラッパーを使用して、いずれかの FTP デーモンへのアクセスを制御します。

4.3.10. Postfix のセキュア化

Postfix は、Simple Mail Transfer Protocol(SMTP)を使用して他の MTA とメールクライアントまたは配信エージェントとの間の電子メッセージを提供する Mail Transfer Agent(MTA)です。多くの MTA は、相互にトラフィックを暗号化できますが、ほとんどの MTA はトラフィックを暗号化できるため、パブリックネットワークで電子メールを送信することは、本質的に安全ではない通信の形式とみなされます。Postfix は、Red Hat Enterprise Linux 7 のデフォルト MTA として Sendmail を置き換えます。

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 を同じ UID を持ち、互いメールを受信および読み取ることができます。

注記

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

4.3.10.3. メール専用ユーザー

Postfix サーバーでローカルユーザーを悪用するのを手助けするために、メールユーザーが電子メールプログラムを使用して Postfix サーバーにのみアクセスするのが最適です。メールサーバー上のシェルアカウントを許可してはならず、/etc/passwdファイル内のすべてのユーザーシェルを/sbin/nologinに設定する必要があります（rootユーザーを除く）。

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

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

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

inet_interfaces = localhost

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

localhostの制限を解除して、Postfixがすべてのインターフェイスを listenできるようにするには、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

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

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設定ファイルを編集して、DovecotがPostfix SMTPサーバーにプレーン認証とログイン認証の仕組みを提供するように指示します。
```
auth_mechanisms = plain login
```

Postfix のセットアップ

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

Postfix SMTPサーバーのSMTP認証を有効にします。
```
smtpd_sasl_auth_enable = yes
```
Postfixに、SMTP認証にDovecotの SASL実装を使用するように指示します。
```
smtpd_sasl_type = dovecot
```
Postfixのキューディレクトリからの相対パスを指定します（相対パスを使用することで、Postfixサーバーがchrootで動作しているかどうかにかかわらず、この設定が確実に機能することに注意してください）。
```
smtpd_sasl_path = private/auth
```
この手順では、PostfixとDovecotの間の通信にUNIXドメインのソケットを使用することを想定しています。通信にTCPソケットを使用する場合に、Postfixが別のマシンでDovecotを探すように設定するには、以下のような設定値を使用します。
```
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設定を保護するための最も一般的な方法について説明します。no は、推奨の提案の一覧を網羅的なものとみなすべきことを意味します。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 System Administrator's Guide』の「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 つのリストの中ですべてのメソッドを完了する必要があります。一覧は空白で区切る必要があります。一覧内の個々の authentication-method 名はコンマで区切る必要があります。以下に例を示します。

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-2RSA鍵のペアを生成しますが、-tオプションを使用して、DSAまたはECDSA鍵も生成するように指示することができます。 ECDSA(Elliptic Curve Digital Signature Algorithm)は、同じ共通鍵の長さであれば、より優れた性能を発揮します。また、短いキーも生成します。

デフォルト以外のポート

デフォルトでは、sshd デーモンは TCP ポート 22 をリッスンします。ポートを変更すると、自動ネットワークスキャンに基づいて攻撃にシステムがさらされる可能性が低減されるため、不利な方法でセキュリティーが強化されます。ポートは、/etc/ssh/sshd_config設定ファイルのPortディレクティブを使用して指定できます。また、デフォルト以外のポートを使用できるように、デフォルトの SELinux ポリシーを変更する必要があることに注意してください。これは、rootとして以下のコマンドを入力して、ssh_port_tSELinuxタイプを変更することで実現できます。

~]# semanage -a -t ssh_port_t -p tcp port_number

上記のコマンドでは、port_numberを、Portディレクティブで指定した新しいポート番号に置き換えます。

root ログインなし

特定の使用例でルートユーザとしてログインする必要がない場合は、/etc/ssh/sshd_configファイル内のPermitRootLogin構成指令をnoに設定することを検討してください。 rootユーザーとしてログインできないようにすることで、管理者は、どのユーザーが通常のユーザーとしてログインした後にroot権限を得て、どの特権コマンドを実行したかを監査することができます。

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

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

警告

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 サーバーのみを使用する場合は、localhost トラフィックのみをリッスンするように memcached を設定します。 etc/sysconfig/memcachedのOPTIONSに-l 127.0.0.1,::1の値を追加します。
```
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 にアクセスする場合は、サービスが localhost でのみリッスンするか、ファイアウォールがネットワークから 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 Wrappersバナーを実装するには、バナーオプションを使用します。

以下の例では、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 Wrappersは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トークンは、攻撃者がアクセスしようとしていたサービスの名前を提供します。

接続を許可してログを取るには、/etc/hosts.allowファイルにspawnディレクティブを記述します。

注記

spawn指令は任意のシェルコマンドを実行するので、特定のクライアントがサーバーに接続しようとした場合に、管理者に通知したり、一連のコマンドを実行したりする特別なスクリプトを作成しておくとよいでしょう。

4.4.1.3. TCP Wrapper とロギングの強化

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

この例では、FTP サーバーでポート 23（Telnet ポート）への接続を試みるすべてのユーザーがクラッカーであると仮定します。これを示すために、ログファイルにデフォルトのフラグであるinfoの代わりにemergのフラグを置き、接続を拒否します。

そのためには、/etc/hosts.denyに以下の行を入れてください。

in.telnetd : ALL : severity emerg

これは、デフォルトのauthprivログ機能を使用しますが、優先順位をデフォルトのinfoからemergに昇格させ、ログメッセージをコンソールに直接投稿します。

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

使用できない攻撃を防ぐために、未使用のポートを閉じることが重要です。リッスン状態の予期しないポートの場合、侵入の可能性を調査する必要があります。

開いているポートスキャンに対する netstat の使用

ネットワークからの接続を待ち受けているポートを確認するために、root権限で次のコマンドを入力します。

~]# netstat -pan -A inet,inet6 | grep -v ESTABLISHED
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address       Foreign Address    State     PID/Program name
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      1/systemd
tcp        0      0 192.168.124.1:53        0.0.0.0:*               LISTEN      1829/dnsmasq
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1176/sshd
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      1177/cupsd
tcp6       0      0 :::111                  :::*                    LISTEN      1/systemd
tcp6       0      0 ::1:25                  :::*                    LISTEN      1664/master
sctp              0.0.0.0:2500                                      LISTEN   20985/sctp_darn
udp        0      0 192.168.124.1:53        0.0.0.0:*                           1829/dnsmasq
udp        0      0 0.0.0.0:67              0.0.0.0:*                           977/dhclient
...

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

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

開いているポートスキャンに対する ss の使用

また、ssユーティリティーを使用して、リスニング状態のオープンポートをリストアップすることもできます。 netstatよりも多くのTCPやステート情報を表示できます。

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

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

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

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

次に、ネットワークを介して最初のシステムに接続されている別のリモートマシンから、nmapツールを使用して外部チェックを行います。これは、firewalld でのルールを確認するために使用できます。以下は、TCP 接続をリッスンするポートを決定する例です。

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

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

TCPコネクトスキャン（-sT）は、TCP SYNスキャン（-sS）がオプションでない場合のデフォルトのTCPスキャンタイプです。 Oオプションは、ホストのOSを検出します。

netstatおよびssを使用したオープンSCTPポートのスキャン

netstatユーティリティは、Linuxのネットワークサブシステムに関する情報を表示します。開いているSCTP（Stream Control Transmission Protocol）ポートのプロトコル統計を表示するには、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) のマニュアルページを参照してください。

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

ソースルーティングは、IP パケットの情報を伝送できるようにするインターネットプロトコルのメカニズムで、アドレスの一覧で、パケットが引き継ぐ必要のあるパスを示すルーターを指示します。ルートが通過されるため、ホップを記録するオプションもあります。「ルートレコード」というホップのリストは、宛先にソースへのリターンパスを指定します。これにより、ソース（送信ホスト）がルートを指定でき、一部またはすべてのルーターのルーティングテーブルを無視できます。悪意のある目的で、ユーザーはネットワークトラフィックをリダイレクトすることができます。このため、ソースベースのルーティングは無効にする必要があります。

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

~]# /sbin/sysctl -w net.ipv4.conf.all.accept_source_route=0

パケットの転送の無効化は、可能な場合にも上記のように行う必要があります（無効化転送が、仮想化に干渉する可能性があります）。以下のコマンドを root で発行します。

以下のコマンドは、すべてのインターフェースで IPv4 パケットおよび IPv6 パケットの転送を無効にします。

~]# /sbin/sysctl -w net.ipv4.conf.all.forwarding=0

~]# /sbin/sysctl -w net.ipv6.conf.all.forwarding=0

以下のコマンドは、すべてのインターフェースですべてのマルチキャストパケットの転送を無効にします。

~]# /sbin/sysctl -w net.ipv4.conf.all.mc_forwarding=0

~]# /sbin/sysctl -w net.ipv6.conf.all.mc_forwarding=0

ICMP リダイレクトを許可すると、詳細な用途がいくつかあります。特に必要でない限り、ICMP リダイレクトパケットの受け入れおよび送信を無効にします。

以下のコマンドは、すべてのインターフェースですべての ICMP リダイレクトパケットの受け入れを無効にします。

~]# /sbin/sysctl -w net.ipv4.conf.all.accept_redirects=0

~]# /sbin/sysctl -w net.ipv6.conf.all.accept_redirects=0

このコマンドは、すべてのインターフェースでセキュアな ICMP リダイレクトパケットの受け入れを無効にします。

~]# /sbin/sysctl -w net.ipv4.conf.all.secure_redirects=0

このコマンドは、すべてのインターフェースの IPv4 ICMP リダイレクトパケットの受け入れを無効にします。

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

重要

ICMPリダイレクトの送信は、net.ipv4.conf.all.send_redirectsまたはnet.ipv4.conf.interface.send_redirectsオプションのうち、少なくとも1つが有効に設定されている場合に有効となります。net.ipv4.conf.interface.send_redirectsオプションをすべてのインターフェイスで0に設定していることを確認してください。新しいインターフェースを追加するときに常に ICMP リクエストの送信を自動的に無効にするには、以下のコマンドを入力します。

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

IPv4 リダイレクトしたパケットの送信を無効にするディレクティブのみがあります。このような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を参照してください。

警告

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

4.4.3.1. 逆方向パス転送

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

注記

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

警告

フォワーディングが有効になっている場合、リバースパスフォワーディングは、ソースアドレスの検証のための他の手段（例えばiptablesのルールなど）がある場合にのみ無効にする必要があります。

rp_filter

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

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

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

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

0 — ソースの検証はありません。
1 — RFC 3704 で定義された厳密なモード。
2 — RFC 3704 で定義された緩慢なモード。

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

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

注記

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

net.ipv4.conf.all.rp_filter=2

IPv6_rpfilter

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

リバースパスフォワーディングのカスタム設定が必要な場合は、以下のようにip6tablesコマンドを使用することで、firewalldデーモンを使用せずに実行することができます。

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

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

パケット転送の有効化

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

net.ipv4.ip_forward = 1

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

/sbin/sysctl -p

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

/sbin/sysctl net.ipv4.ip_forward

上記のコマンドが1を返した場合、IPフォワーディングが有効になります。 0が返ってきた場合は、次のコマンドで手動で電源を入れることができます。

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

4.4.3.2. 関連情報

以下は、Reverse Path Forwarding について詳しく説明するリソースです。

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

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

4.5.1. DNS の概要

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

4.5.2. DNSSEC について

インターネットでの接続については、最近ではHTTPSを使って安全に接続できるウェブサイトが増えています。ただし、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 情報の処理は、ルートゾーンの公開鍵で設定されるリゾルバーによって行われます。このキーを使用すると、リゾルバーはルートゾーンで使用される署名を検証できます。例えば、ルートゾーンが.comのDSレコードに署名したとします。ルートゾーンは、.comネームサーバーのNSレコードとglueレコードも提供しています。リゾルバはこの委任に従って、これらの委任されたネームサーバを使って.comのDNSKEYレコードを問い合わせます。取得した DNSKEY レコードのハッシュは、ルートゾーンの DS レコードと一致する必要があります。その場合、リゾルバは取得した.comのDNSKEYを信頼します。 .comゾーンでは、RRSIGレコードは.comのDNSKEYによって作成されます。このプロセスは、redhat.comのような.com内のデリゲーションについても同様に繰り返されます。この方法を使用すると、検証用DNSリゾルバは1つのルート鍵を設定するだけで済むが、通常の運用では世界中から多くのDNSKEYを収集することになる。暗号化チェックに失敗すると、リゾルバーは SERVFAIL をアプリケーションに戻します。

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

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

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

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

DNSSECに対応した再帰的リゾルバを導入するには、BINDまたはunboundのいずれかを使用できる。いずれもデフォルトで DNSSEC を有効にし、DNSSEC ルートキーで設定されます。サーバー上でDNSSECを有効にするには、どちらでも構いませんが、ノートパソコンなどのモバイルデバイスではunboundの使用が推奨されます。これは、dnssec-triggerを使用する場合はホットスポットで、Libreswanを使用する場合はVPNで必要なDNSSECのオーバーライドを、ローカルユーザーが動的に再設定できるためです。 unboundデーモンは、サーバーとモバイルデバイスの両方に有用な、etc/unbound/*.d/ディレクトリにリストアップされたDNSSECの例外の展開をさらにサポートします。

4.5.3. Dnssec-trigger について

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

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

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トンネルが立ち上がると、受信したドメイン名のすべてのエントリーについて、ローカルのアンバウンド・キャッシュがフラッシュされるため、ドメイン名内の名前に対する問い合わせは、VPNを使用して到達した内部のネーム・サーバーから新たに取得されることになります。VPNトンネルが終了すると、アンバウンドキャッシュが再びフラッシュされ、ドメインに対するあらゆる問い合わせが、以前に取得したプライベートIPアドレスではなく、パブリックIPアドレスを返すようになります。「Connection Supplied Domain の DNSSEC Validation の設定」を参照してください。

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

Red Hat は、静的な名前と一時的な名前の両方が、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リゾルバをアンバウンド（またはバインド）でインストールする必要があります。 dnssec-triggerは、モバイルデバイスにのみインストールする必要があります。サーバーの場合は、unboundで十分ですが、サーバーの設置場所（LANまたはインターネット）によっては、ローカルドメインの転送設定が必要な場合があります。dnssec-triggerは、現在のところ、グローバルパブリックDNSゾーンにのみ対応しています。NetworkManager,dhclient, および VPN アプリケーションは、しばしば自動的にドメインリスト (およびネームサーバーリストも)を集めることができるが、dnssec-triggerやunbound はできない。

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

~]# yum install unbound

4.5.7.2. 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 の起動

現在のセッションのunbounddaemonを起動するには、rootユーザーとして次のコマンドを入力します。

~]# systemctl start unbound

systemctl enableコマンドを実行すると、システム起動時に毎回unboundが起動するようになります。

~]# systemctl enable unbound

unbounddaemonでは、以下のディレクトリを使用して、ローカルデータやオーバーライドの設定が可能です。

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)のマニュアルページをご覧ください。

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

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

~]# yum install dnssec-trigger

4.5.7.5. Dnssec-trigger Daemon が実行中であるかどうかを確認

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に記述します。これで、ホットスポットのサインオンページで認証できるようになりました。アンカーアイコンには大きな赤いエクスクラメーションマークが表示され、DNSクエリが安全でない方法で行われていることを警告します。認証されると、dnssec-triggerは自動的にこれを検知してセキュアモードに戻るはずですが、場合によってはそれができず、ユーザーがReprobeを選択して手動でこれを行う必要があります。

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

4.5.9. DNSSEC における dig の使用

DNSSEC が機能しているかどうかを確認するには、さまざまなコマンドラインツールを使用できます。そのためには、bind-utilsパッケージに含まれるdigコマンドが最適です。ldns パッケージからの drill と unbound パッケージからの unbound-host も有用です。古いDNSユーティリティーであるnslookupやhostは時代遅れであり、使用すべきではありません。

digを使ってDNSSECのデータを要求するクエリを送信するには、コマンドに+dnssecというオプションを追加します（例）。

~]$ dig +dnssec whitehouse.gov
; <<>> DiG 9.9.3-rl.13207.22-P2-RedHat-9.9.3-4.P2.el7 <<>> +dnssec whitehouse.gov
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21388
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;whitehouse.gov.			IN	A

;; ANSWER SECTION:
whitehouse.gov.		20	IN	A	72.246.36.110
whitehouse.gov.		20	IN	RRSIG	A 7 2 20 20130825124016 20130822114016 8399 whitehouse.gov. BB8VHWEkIaKpaLprt3hq1GkjDROvkmjYTBxiGhuki/BJn3PoIGyrftxR HH0377I0Lsybj/uZv5hL4UwWd/lw6Gn8GPikqhztAkgMxddMQ2IARP6p wbMOKbSUuV6NGUT1WWwpbi+LelFMqQcAq3Se66iyH0Jem7HtgPEUE1Zc 3oI=

;; Query time: 227 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Aug 22 22:01:52 EDT 2013
;; MSG SIZE  rcvd: 233

A レコードの他に、DNSSEC 署名を含む RRSIG レコードと、署名の対応の日時および期限切れ時間が返されます。 アンバウンドサーバーは、上部の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の出力に表示され、unbounddaemonはこれらのエラーを以下のように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 へのホットスポット検出インフラストラクチャーの設定

ネットワークへの接続時に、dnssec-triggerはホットスポットの検出を試みます。通常、Hotspot は、ユーザーがネットワークリソースを使用する前に、Web ページとの対話を強制するデバイスです。検出は、既知のコンテンツを持つ特定の Web ページをダウンロードしようとして行います。ホットスポットがある場合は、受信したコンテンツは予想通りに機能しません。

dnssec-triggerがホットスポットを検出するために使用できる、既知のコンテンツを持つ固定のWebページを設定するには、以下の手順に従います。

インターネット上で一般に到達可能なマシン上に Web サーバーをセットアップします。Red Hat Enterprise Linux 7 System Administrator's Guide』の「Web Server」の章を参照してください。
サーバーが実行されたら、既知のコンテンツを持つ静的ページを公開します。このページは有効な 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 サーバー」の章にあるDocumentRootディレクティブを参照してください。
/etc/dnssec-trigger/dnssec-trigger.confファイルに次の行を追加します。
```
url: "http://example.com/static/hotspot.txt OK"
```
このコマンドは、HTTP（ポート80）を使用してプローブされるURLを追加します。最初の部分は、解決されるURLとダウンロードされるページです。コマンドの 2 番目の部分は、ダウンロードした Web ページに含まれることが予想されるテキスト文字列です。

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

4.5.11. Connection Supplied Domain の DNSSEC Validation の設定

デフォルトでは、適切なネームサーバーを持つフォワードゾーンが、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 page -DNS検証リゾルバであるunboundのコマンドオプションについて説明します。
unbound.conf(5)man page -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 Deployment Initiative は、Homeland Security の Department が装備したスポンサーに、多くの 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パッケージはOptionalチャネルからのみ入手可能であることに注意してください。Enabling Supplementary and Optional Repositoriesを参照してください。

VPNのIPsecプロトコルは、それ自体がIKE（ Internet Key Exchange）プロトコルを用いて構成されています。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
ESP（ Encapsulated Security Payload）IPsecパケットのプロトコル50
AH（ Authenticated Header）IPsecパケットのプロトコル51（一般的ではない

Libreswanを使ってIPsecVPNを構築した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を使用した安全なウェブサイト（ https:// ウェブサイトとも呼ばれる）と同様です。

これらの認証方法に加えて、量子コンピューターによる攻撃から保護するために、追加の認証を追加できます。この追加の認証方法は、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アドレスやホスト名をもとに、「左」か「右」かを自動的に検出します。一方のホストがモバイルホストの場合、つまりIPアドレスが事前にわからない場合、モバイルクライアントではIPアドレスとして%defaultrouteを使用します。これで自動的にダイナミックIPアドレスがピックアップされます。受信するモバイルホストからの接続を受け付ける静的サーバーホストでは、モバイルホストのIPアドレスに%anyを使用して指定します。

左「側の」ホストからletrsasigkeyの値が取得され、「右側の」ホストから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のパケットはESP（Encapsulated Security Payload）パケットとして表示されます。ESP プロトコルにはポートがありません。VPN接続がNATルーターを通過する必要がある場合、ESPパケットはポート4500のUDPパケットにカプセル化されます。

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

~]# tcpdump -n -i interface ESP または udp ポート 500 または udp ポート 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

インターフェイスは、トラフィックを伝送することが知られているインターフェイスです。tcpdump での表示を終了するには、Ctrl+C を押します。

注記

tcpdumpコマンドは、IPsecと少し意外な関係にあります。送信テキストパケットではなく、送信暗号化パケットだけが表示されます。暗号化された受信パケット、および復号化された受信パケットが表示されます。可能であれば、一方のエンドポイント自体ではなく、2つのマシン間のルーター上でtcpdumpを実行してください。VTI（Virtual Tunnel Interface）を使用している場合、物理インターフェースの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がサイト間IPsecVPNを構築し、2つのネットワークを結合するためには、1つまたは複数のサブネットからのトラフィックの通過を許可するように構成された2つのホスト（エンドポイント）の間にIPsecトンネルを作成します。したがって、ネットワークのリモート部分へのゲートウェイとして考えることができます。サイト間の VPN の設定は、設定ファイル内で複数のネットワークまたはサブネットを指定する必要がある点のみが、ホスト間の VPN とは異なります。

サイト間IPsecVPNを作成するようにLibreswanを設定するには、まず、「Libreswan を使用したホスト間の VPN の作成」で説明されているようにホスト間IPsecVPNを設定し、そのファイルを/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 を使用したサイト/Site Single Tunnel VPN の設定

サイト間トンネルを構築する際、ゲートウェイはパブリックIPアドレスではなく、内部IPアドレスを使用して相互に通信する必要がある場合がよくあります。これは、1 つのトンネルを使用して実行できます。ホスト名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 シンプルなサブネット Extrusion 設定の構成

以下の例では、本社を10.0.0.0/8、2つの支店をより小さい/24サブネットを使用するように設定しています。

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

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. Libreswan の IKEv2 リモートアクセスの設定

ロードウォーリアーとは、外出先などで、ノート 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)のマニュアルページを参照してください。

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

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. IKEv1 リモートアクセス VPN Libreswan および XAUTH を X.509 で設定

Libreswanでは、XAUTHIPsecエクステンションを使用して、接続の確立時にローミングVPNクライアントにIPアドレスとDNS情報をネイティブに割り当てる方法を提供しています。拡張認証(XAUTH)は、PSK または X.509 証明書を使用してデプロイできます。X.509 を使用したデプロイの方がより安全です。クライアント証明書は、証明書失効リストまたはオンライン証明書ステータスプロトコル（OCSP）によって失効させることができます。X.509 証明書を使用すると、個々のクライアントはサーバーの権限を借用できません。PSK(Group Password)では、理論的にこれは理論的に可能です。

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

XAUTH には、以下の 3 つのバックエンドがあります。

xauthby=pam

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

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をチェックすることができます。そのようなユーザーは、例えばiptablesDNATを使用して、管理者に連絡したり、サービスの有料会員を更新したりすることができる「ウォールドガーデン」にリダイレクトされます。

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クライアントは10.0.0.0/8のトラフィックのみをVPN経由で送信します。

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

xauthby=file: 管理者がパスワードを生成し、/etc/ipsec.d/passwdファイルに保存しました。
xauthby=pam: パスワードは、PAMの設定で指定した場所（/etc/pam.d/plutoファイル）で取得します。
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 リリースノートを参照してください。

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は、指定された名前のコマンド-nameが利用可能かどうかをテストします。シェルスクリプトでの使用を目的としています。詳しくはmanopenssl(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

秘密鍵の生成については、mangenpkey(1) を参照してください。

4.7.2. 証明書の生成

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

証明書を認証局（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 ElectronicMailに由来しています。DER形式の証明書ファイルを生成するには、-outformDERコマンドオプションを使用します。

上記のコマンドを実行すると、証明書の識別名（DN）を作成するために、あなたと組織に関する情報の入力が求められます。以下の情報が必要になります。

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

req(1) マンページでは、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/ディレクトリにはMakefileがあり、makeコマンドを使用して証明書を作成することができます。使用方法を表示するには、以下のコマンドを実行します。

~]$ make -f /etc/pki/tls/certs/Makefile

または、ディレクトリに移動して、以下のようにmakeコマンドを実行します。

~]$ cd /etc/pki/tls/certs/
~]$ make

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

4.7.3. 証明書の確認

CA が署名する証明書は、信頼できる証明書と呼ばれます。そのため、自己署名証明書は信頼できない証明書になります。verify ユーティリティーは、OpenSSLが通常の操作で使用するのと同じ SSL および S/MIME 機能を使用して証明書を検証します。エラーが見つかった場合は、それが報告され、他のエラーを報告してテストを続行しようとします。

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

~]$ openssl verify cert1.pem cert2.pem

証明書チェーンを検証するには、リーフ証明書をcert.pemに格納し、信頼していない中間証明書をuntrusted.pem に直接連結する必要があります。信頼できるルートCA証明書は、/etc/pki/tls/certs/ca-bundle.crtに記載されているデフォルトCAの中にあるか、cacert.pemファイルの中にあるものでなければなりません。次に、チェーンを検証するには、以下の形式でコマンドを実行します。

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

詳しくはmanverify(1) をご覧ください。

重要

このアルゴリズムの強度が不十分なため、Red Hat Enterprise Linux 7 では MD5 ハッシュアルゴリズムを使用した署名の検証は無効になっています。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 plain -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) マニュアルページでは、公開鍵アルゴリズムユーティリティーについて説明しています。

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

利用可能な対称暗号化アルゴリズムの一覧を表示するには、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 plain

重要

encコマンドはAEAD暗号を適切にサポートしておらず、ecbモードは安全とは言えません。最良の結果を得るためには、cbc、cfb、ofb、またはctr以外のモードを使用しないでください。

4.7.5. メッセージダイジェストの生成

dgstコマンドは、指定されたファイルのメッセージダイジェストを16進数で表示します。このコマンドは、デジタル署名および検証にも使用できます。message digest コマンドは以下の形式になります。

openssl dgst algorithm -out filename -sign private-key

ここでアルゴリズムはmd5|md4|md2|sha1|sha|mdc2|ripemd160|dss1のいずれかです。書き込み時に、SHA1 アルゴリズムが推奨されます。DSAによる署名・検証が必要な場合は、dss1オプションと、-randオプションで指定したランダムデータを含むファイルを併用する必要があります。

sha1 アルゴリズムを使用して、デフォルトの Hex 形式でメッセージダイジェストを生成するには、以下のコマンドを実行します。

~]$ openssl dgst sha1 -out digest-file

ダイジェストにデジタル署名するには、秘密鍵.pemを使って次のコマンドを実行します。

~]$ openssl dgst sha1 -out digest-file -sign privkey.pem

詳しくはmandgst(1) をご覧ください。

4.7.6. パスワードハッシュの生成

passwd コマンドは、パスワードのハッシュを計算します。コマンドラインでパスワードのハッシュを計算するには、以下のコマンドを実行します。

~]$ openssl passwd password

デフォルトでは、-cryptアルゴリズムが使用されます。

MD5ベースのBSDアルゴリズム1を使って、標準入力からパスワードのハッシュを計算するには、次のようなコマンドを実行します。

~]$ openssl passwd -1 パスワード

apr1オプションは、BSDアルゴリズムのApacheバージョンを指定します。

注記

openssl passwd -1 passwordコマンドは、FIPSモードが無効の場合のみ使用してください。そうでない場合は、コマンドは機能しません。

ファイルに保存されているパスワードのハッシュを、ソルトxxを使って計算するには、次のようなコマンドを実行します。

~]$ openssl passwd -salt xx -in password-file

パスワードは標準出力に送られ、出力ファイルを指定する-outオプションはありません。 tableは、パスワードのハッシュとそれに対応する平文パスワードの表を生成します。

詳細と例については、mansslpasswd(1) を参照してください。

4.7.7. ランダムデータの生成

シードファイルを使用して、ランダムなデータを含むファイルを生成するには、以下のコマンドを発行します。

~]$ openssl rand -out rand-file -rand seed-file

ランダムデータ処理を行うための複数のファイルを、コロン「:」を用いてリストセパレータとして指定することができます。

詳しくはmanrand(1) をご覧ください。

4.7.8. システムのベンチマーキング

特定のアルゴリズムに対してシステムの計算速度をテストするには、以下の形式でコマンドを発行します。

~]$ openssl speed algorithm

ここで、algorithmは、サポートされているアルゴリズムのうち、使用を意図したものです。利用可能なアルゴリズムを一覧表示するには、openssl speedと入力し、tabを押します。

4.7.9. OpenSSL の設定

OpenSSLには、マスター設定ファイルと呼ばれる設定ファイル/etc/pki/tls/openssl.cnfがあり、OpenSSLライブラリがこれを読み込みます。各アプリケーションに個別の設定ファイルを使用することもできます。設定ファイルには、以下のようなセクション名を持ついくつかのセクションが含まれています。[ セクション名 ] です。なお、ファイルの最初の[ section_name ]までは、デフォルトセクションと呼ばれています。OpenSSL が設定ファイルで名前を検索すると、名前付きセクションが最初に検索されます。すべての OpenSSL コマンドは、別の設定ファイルを指定するためにオプションが使用されていない限り、マスター OpenSSL 設定ファイルを使用します。コンフィギュレーションファイルについては、config(5)のマニュアルページで詳しく説明されています。

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には有効な証明書が必要です。適切な証明書をお持ちでない場合は、認証局に申請して証明書を取得するか、自己署名証明書を作成してください。
警告
実稼働環境で稼働するサーバーには、認証局が署名した証明書を常に使用します。自己署名証明書は、テスト目的またはプライベートネットワークの場合にのみ適しています。
認証局から付与される証明書の詳細については、「証明書署名要求の作成」を参照してください。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は独立した暗号プロトコルですが、ここでTLSを使用することができます。
- chroot - 安全性を高めるために、stunnelプロセスが実行されるルートディレクトリを変更する。
- 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 のセキュア化
CUPSのTLSラッパーとしてstunnelを設定するには、以下の値を使用します。
```
[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 コンピューターのパーティションを暗号化できます。これは、モバイルコンピューターやリムーバブルメディアの場合に特に重要になります。LUKS を使用すれば、複数のユーザー鍵が、パーティションのバルク暗号化に使用されるマスター鍵を複号できるようになります。

LUKS の概要

LUKS の機能

LUKS は、ブロックデバイス全体を暗号化するため、リムーバブルストレージメディアやラップトップディスクドライブなどのモバイルデバイスのコンテンツを保護するのに適していることになります。
暗号化されたブロックデバイスの基礎となるコンテンツは任意です。そのため、スワップデバイスの暗号化にも有効です。また、とりわけデータストレージ用にフォーマットしたブロックデバイスを使用する特定のデータベースに関しても有用です。
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. 手動でのディレクトリーの暗号化

警告

この手順では、暗号化しているパーティションのデータをすべて削除します。WILL ですべての情報を失うことになります。この手順を開始する前に、データを外部ソースにバックアップしてください。

runlevel 1 を入力し、シェルプロンプトで root として以下を入力します。
```
telinit 1
```
既存の /home のマウントを解除します。
```
umount /home
```
前のステップのコマンドが失敗した場合、fuserを使って/homeを占有しているプロセスを見つけ、それらを殺す。
```
fuser -mvk /home
```
/home がもはやマウントされていないことを確認します。
```
grep home /proc/mounts
```
パーティションをランダムなデータで埋めます。
```
shred -v --iterations=1 /dev/VG00/LV_home
```
このコマンドは、デバイスの連続書き込み速度で続行し、完了までに時間がかかる場合があります。暗号化されていないデータが使用されたデバイスに残らないようにし、無作為のデータではなく、暗号化されたデータを含むデバイスの一部を難読化する重要な手順です。

パーティションを初期化します。

cryptsetup --verbose --verify-passphrase luksFormat /dev/VG00/LV_home

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

これで、コンピューターがオフになっていた間、すべてのデータで安全を確保できる暗号化パーティションがあります。

4.9.1.3. 既存のデバイスへの新しいパスフレーズの追加

以下のコマンドを使用して、既存のデバイスに新しいパスフレーズを追加します。

cryptsetup luksAddKey device

認証用に既存のパスのいずれかの入力を求めるプロンプトが出されたら、新しいパスフレーズを入力するように求められます。

4.9.1.4. 既存のデバイスからのパスフレーズ削除

以下のコマンドを使用して、既存のデバイスからパスフレーズを削除します。

cryptsetup luksRemoveKey device

削除するパスフレーズの入力を求めるプロンプトを出し、次に認証用に残りのパスフレーズになります。

4.9.1.5. Anaconda での暗号化したブロックデバイスの作成

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

ブロックデバイスの暗号化を有効にするには、自動パーティショニングを選択する際に「Encrypt System」チェックボックスをチェックするか、個々のパーティション、ソフトウェアRAIDアレイ、または論理ボリュームの作成時に「Encrypt」チェックボックスをチェックします。パーティションの設定が完了すると、暗号化パスフレーズの入力が求められます。このパスフレーズは、暗号化されたデバイスにアクセスするために必要です。インストールプロセスで、既存の LUKS デバイスがあり、そのパスフレーズについて正しいパスフレーズを入力した場合は、パスフレーズのエントリーダイアログにチェックボックスも含まれます。このチェックボックスを確認すると、既存の各ブロックデバイスで利用可能なスロットに、新しいパスフレーズを追加したいことを示しています。

注記

自動パーティション設定」画面で「システムの暗号化」チェックボックスをチェックしてから「カスタムレイアウトの作成」を選択しても、ブロックデバイスが自動的に暗号化されることはありません。

注記

キックスタートを使用して、新しい暗号化ブロックデバイスごとに個別のパスフレーズを設定することができます。

4.9.1.6. 関連情報

Red Hat Enterprise Linux 7 の LUKS または暗号化ハードドライブの詳細は、以下のリンクのいずれかを参照してください。

4.9.2. GPG 鍵の作成

GPG は、自分自身を特定し、通信の認証に使用されます。これには、知らないユーザーも含まれます。GPG により、GPG 署名のメールの読み取りが誰でもその認証を検証できるようになります。つまり、GPG では、実際に署名した通信が合理的に特定されます。GPG は、サードパーティーによるコード変更や対話の傍受やメッセージの変更を防ぐのに役立ちます。

4.9.2.1. GNOME での GPG 鍵の作成

GNOMEでGPG Keyを作成するには、以下の手順で行います。

GPGキーの管理を容易にするユーティリティー「Seahorse」をインストールします。
```
~]# yum install seahorse
```
キーを作成するには、メニューからアプリケーション → アクセサリーメニューから「パスワードと暗号化キー」を選択すると、アプリケーション「Seahorse」が起動します。
ファイルメニューから「新規作成」を選択し、「PGPキー」を選択します。そして、「Continue」をクリックします。
お客様のフルネーム、Eメールアドレス、およびお客様が誰であるかを示す任意のコメントを入力してください（例：John C. Smith,jsmith@example.com, Software Engineer）。Create をクリックします。パスフレーズの入力を求めるダイアログが表示されます。強固なパスフレーズを選択しますが、覚えるのが簡単です。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 はほぼすべてのユーザーには十分で、非常に強固なセキュリティーのレベルを表します。
鍵の有効期限を選択します。デフォルトの「なし」ではなく、「有効期限」を選択することをお勧めします。たとえば、キーのメールアドレスは無効です。
```
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 キーを使用している場合は、そのリストで使用するメールアドレスを入力します。
aliases やその他の情報を含めるには、comment フィールドを使用します。（場合によっては、目的ごとに異なるキーを使用し、「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]
```
鍵フィンガープリントは、鍵の「signature」の略です。これにより、改ざんを行わずに、実際の公開鍵を受信していることを確認することができます。このフィンガープリントは作成する必要はありません。フィンガープリントはいつでも表示するには、以下のコマンドを使用して、メールアドレスを置き換えます。
```
~]$ 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

使用するハードウェアトークンのタイプによっては、特定のユースケースに対応する追加パッケージをインストールしなければならない場合があります。例えば、TPM（ Trusted Platform Module）デバイスのサポートを得るためには、opencryptoki-tpmtokパッケージをインストールする必要があります。

Yumパッケージマネージャーを使用してパッケージをインストールする方法についての一般的な情報は、『Red Hat Enterprise Linux 7 システム管理者ガイド』の「パッケージのインストール」セクションを参照してください。

openCryptokiサービスを有効にするには、pkcsslotdデーモンを実行する必要があります。 rootで次のコマンドを実行して、現在のセッションのデーモンを起動します。

~]# systemctl start pkcsslotd

システムの起動時にサービスが自動的に起動されるようにするには、以下のコマンドを入力します。

~]# systemctl enable pkcsslotd

サービスを管理するために systemd ターゲットを使用する方法の詳細については、Red Hat Enterprise Linux 7 System Administrator's Guide の「Managing Services with systemd」の章を参照してください。

4.9.3.2. openCryptoki の設定と使用

起動すると、pkcsslotdデーモンは、/etc/opencryptoki/opencryptoki.conf設定ファイルを読み込み、システムで動作するように設定されたトークンとそのスロットに関する情報を収集するために使用します。

ファイルは、キーと値のペアを使用して個別のスロットを定義します。各スロット定義には、説明、使用されるトークンライブラリーの仕様、およびスロットの製造元の ID を含めることができます。必要に応じて、スロットのハードウェアおよびファームウェアのバージョンを定義できます。ファイルのフォーマットや、個々のキーとそのキーに割り当てられる値の詳細については、opencryptoki.conf(5) のマニュアルページを参照してください。

ランタイム時の pkcsslotd デーモンの動作を修正するには、pkcsconf ユーティリティーを使用します。このツールを使用すると、デーモンの状態を表示し、設定したり、現在設定されているスロットおよびトークンを一覧表示および変更できます。たとえば、トークンに関する情報を表示するには、次のコマンドを実行します（pkcsslotdデーモンと通信する必要のある非rootユーザーは、すべてpkcs11システムグループに属している必要があることに注意してください）。

~]$ pkcsconf -t

pkcsconfツールで使用できる引数のリストについては、pkcsconf(1) マニュアルページを参照してください。

警告

このグループのすべてのメンバーは、構成された PKCS#11 トークンへのアクセスからopenCryptokiサービスの他のユーザーをブロックする権利を持つため、完全に信頼できるユーザーのみがpkcs11グループのメンバーシップを割り当てる必要があることに注意してください。また、このグループのすべてのメンバーは、openCryptokiの他のユーザーの特権で任意のコードを実行することができます。

4.9.4. OpenSSH に認証情報を提供するスマートカードの使用

スマートカードは、USB スティック、マイクロSD、または SmartCard フォームファクターの軽量なハードウェアセキュリティーモジュールです。リモートで管理できるセキュアなキーストアを提供します。Red Hat Enterprise Linux 7 では、OpenSSH は、スマートカードを使用した認証をサポートします。

スマートカードを OpenSSH で使うには、カードの公開鍵を~/.ssh/authorized_keysファイルに保存します。openscパッケージで提供されるPKCS#11ライブラリをクライアントにインストールします。PKCS#11はPublic-Key Cryptography Standardの一つで、トークンと呼ばれる暗号デバイスに対するアプリケーション・プログラミング・インターフェース（API）を定義したものです。root で以下のコマンドを入力します。

~]# yum install opensc

4.9.4.1. カードからの公開鍵の取得

カード上の鍵を一覧表示するには、ssh-keygenコマンドを使用します。 D指令で共有ライブラリ（以下の例ではOpenSC）を指定します。

~]$ 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 PIV Digital Signature Key (NISTIR 7863)レポートを参照してください。

4.9.4.5. 関連情報

ハードウェアまたはソフトウェアトークンのセットアップについては、「Red Hat Enterprise Linux 7 におけるスマートカードのサポート」で説明しています。

スマートカードと、同様の PKCS#11 セキュリティートークンを管理および使用する pkcs11-tool ユーティリティーの詳細は、man ページの pkcs11-tool(1) を参照してください。

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

信頼できる鍵と暗号化された鍵は、カーネルキーリングサービスを使用するカーネルが生成する可変長の対称鍵です。鍵が暗号化されていない状態でユーザースペースに現れることがないということは、その整合性を検証できるということであり、その結果、例えば拡張検証モジュール（EVM）が実行中のシステムの整合性を検証・確認するために鍵を使用することができるということです。ユーザーレベルのプログラムは、暗号化されたblobの形でしか鍵にアクセスできません。

信頼できる鍵は、Trusted Platform Module (TPM) チップというハードウェアが必要になります。これは、鍵を作成し、暗号化 (保護) するために使用されます。TPM は storage root key (SRK) という 2048 ビットの RSA 鍵を使用して鍵を保護します。

さらに、TPMのPCR（ Platform Configuration Register）値の特定のセットを使用して、信頼できる鍵を封印することもできます。 PCRには、BIOS、ブートローダー、OSを反映した整合性管理のための値が設定されています。つまり、PCRで封印された鍵は、暗号化されたのと全く同じシステム上のTPMでしか復号化できないということです。ただし、PCR で保護された信頼できる鍵が読み込まれると (キーリングに追加されると)、新しいカーネルなどを起動できるように、関連する PCR 値が検証され、新しい (または今後の) PCR 値に更新されます。1 つの鍵を複数のブロブとして保存することもできますが、それぞれ PCR 値が異なります。

暗号化された鍵は、カーネルのAES暗号を使用しているためTPMを必要とせず、信頼された鍵よりも高速に処理することができます。暗号化鍵は、カーネルが生成した乱数を使用して作成され、ユーザー空間のブロブへのエクスポート時に マスターキー により暗号化されます。このマスターキーは信頼できる鍵またはユーザーキーのいずれかです。これは、マスターキーが信頼できる鍵ではない場合に、暗号化鍵は、暗号化に使用されたユーザーキーほど安全です。

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" キーリング

上記の構文を使用すると、コマンド例を以下のように作成できます。

~]$ 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

次に、random-number ユーザーキーを使用して暗号化鍵を生成します。

~]$ 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) のマニュアルページを参照してください。

あるシステムでどのエントロピー源が利用できるかを確認するには、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

注記

詳細およびソフトウェアコードの例については、『インテルデジタル・ランダム・ナンバー・ジェネレーター（DRNG）ソフトウェア・インプリメンテーション・ガイド』を参照してください。

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) マニュアルページを参照してください。

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 のインストール中にホストエントロピーを利用できるようになりました。

重要

シナリオで使用すべき乱数生成器を正しく判断するには、「Red Hat Enterprise Linux の乱数生成器インターフェースの理解」を参照してください。

4.10. ポリシーベースの復号を使用して暗号化ボリュームの自動アンロックの設定

Policy-Based Decryption(PBD)は、ユーザーパスワード、TPM(Trusted Platform Module)デバイス、システムに接続されている PKCS#11 デバイスなどを使用して、物理マシンおよび仮想マシンのハードドライブの、暗号化ルートおよびセカンダリーボリュームのロックを解除できる技術です。

PBD をテクノロジーとして分類することで、ポリシーにさまざまなアンロック方法を組み合わせることで、さまざまな方法で同じボリュームのロックを解除する機能を作成できます。Red Hat Enterprise Linux における PBD の現在の実装は、Clevis フレームワークおよび pin と呼ばれるプラグインで構成されます。各ピンは、個別のアンロック機能を提供します。現在、利用できる 2 つのピンのみが TPM でボリュームのロックを解除できる、またはネットワークサーバーを使用してロックを解除できます。

NBDE(Network Bound Disc Encryption)は、暗号化ボリュームを特別なネットワークサーバーにバインドできるようにする PBD テクノロジーのサブカテゴリーです。NBDE の現在の実装には、Tang サーバー自体と、Tang サーバー用の Clevis ピンが含まれます。

4.10.1. NBDE (Network-Bound Disk Encryption)

NBDE(Network-Bound Disk Encryption)を使用すると、システムの再起動時にパスワードを手動で入力しなくても、ユーザーは物理および仮想マシンでハードドライブの root ボリュームを暗号化できます。

Red Hat Enterprise Linux 7 では、NBDE は、以下のコンポーネントおよび技術を使用して実装されます。

図4.2 Clevis および Tang を使用した Network-Bound ディスク暗号化

Tang は、ネットワークのプレゼンスにデータをバインドするためのサーバーです。セキュリティーが保護された特定のネットワークにシステムをバインドする際に利用可能なデータを含めるようにします。Tang はステートレスで、TLS または認証は必要ありません。エスクローベースのソリューション (サーバーが暗号鍵をすべて保存し、使用されたことがあるすべての鍵に関する知識を有する) とは異なり、Tang はクライアントの鍵と相互作用することはないため、クライアントから識別情報を得ることがありません。

Clevis は、自動化された復号用のプラグイン可能なフレームワークです。NBDE では、Clevis は、LUKS ボリュームの自動アンロックを提供します。clevis パッケージは、クライアントで使用される機能を提供します。

Clevis ピン は、Clevis フレームワークへのプラグインです。このようなピンの 1 つは、NBDE サーバー (Tang) との相互作用を実装するプラグインです。

Clevis および Tang は、一般的なクライアントおよびサーバーのコンポーネントで、ネットワークがバインドされた暗号化を提供します。Red Hat Enterprise Linux 7 では、LUKS と併用され、root および非 root ストレージボリュームの暗号化および復号化で、Network-Bound Disk Encryption を実現します。

クライアントおよびサーバーのコンポーネントはともに 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_tSELinux タイプが提供されており、Tang サーバーは SELinux enforcing モードの confined service として展開することができます。

前提条件

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.srvURLを、tangがインストールされているサーバーのURLに合わせて変更します。JWE 出力ファイルには、暗号化された暗号文が含まれます。この暗号文は PLAINTEXT 入力ファイルから読み込まれます。

データを複号するには、clevis decrypt コマンドを実行して、暗号文 (JWE) を提供します。

~]$ clevis decrypt < JWE > PLAINTEXT

詳細については、clevis-encrypt-tang(1)のマニュアルページを参照するか、内蔵のCLIヘルプを使用してください。

~]$ clevis
Usage: clevis COMMAND [OPTIONS]

  clevis decrypt      Decrypts using the policy defined at encryption time
  clevis encrypt http Encrypts using a REST HTTP escrow server policy
  clevis encrypt sss  Encrypts using a Shamir's Secret Sharing policy
  clevis encrypt tang Encrypts using a Tang binding server policy
  clevis 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アーキテクチャのシステムで、TPM 2.0（Trusted Platform Module 2.0）チップを使用して暗号化するクライアントを展開するには、clevis encrypt tpm2サブコマンドを使用し、唯一の引数としてJSON構成オブジェクトを指定します。

~]$ 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. ルートボリュームの手動登録の設定

既存のLUKSで暗号化されたルートボリュームを自動的にロック解除するには、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 で新しい鍵を暗号化します。
LUKSMeta を使用して LUKS ヘッダーに Clevis JWE オブジェクトを保存します。
LUKS を使用する新しい鍵を有効にします。

このディスクは、既存のパスワードと Clevis ポリシーを使用してロックを解除できます。詳しくは、clevis-luks-bind(1)のマニュアルページをご覧ください。

注記

バインド手順では、空き 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 ポリシーを使用する場合は、同様の手順を使用できます。

Kickstart インストールの詳細については、Red Hat Enterprise Linux 7 インストールガイドを参照してください。Linux Unified Key Setup-on-disk-format（LUKS）については、「LUKS ディスクの暗号化の使用」を参照してください。

4.10.8. 削除可能なストレージデバイスの自動ロック解除の設定

USB ドライブなど、LUKS で暗号化したリムーバブルストレージデバイスを自動的にアンロックするには、clevis-udisks2 パッケージをインストールします。

~]# yum install clevis-udisks2

システムを再起動してから、「ルートボリュームの手動登録の設定」で説明されているように、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.

「ルートボリュームの手動登録の設定」で説明されているように、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 マスター鍵を共有しなければ共有できません。

仮想化環境に自動ロック解除を導入する場合、Red Hat は lorax や virt-install などのシステムとキックスタートファイル (「キックスタートを使用した自動登録の設定」を参照) や他の自動プロビジョニングツールを併用して、暗号化された VM がそれぞれ固有のマスターキーを持つようにすることを強く推奨します。

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ユーザーズガイドおよびアドミニストレーターズガイドを参照してください。

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 は毎日実行する必要があります。例えば、毎日午前4時5分にAIDEを実行するようにcron（システム管理者ガイドの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):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)のマニュアルページを参照してください。使用例は「Rule Language を使用した独自のポリシーの作成」を参照してください。

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オプションを使用します。デバイスの認証を解除するだけの場合は、usbguardコマンドにblock-deviceオプションを付けて使用します。

~]# usbguard block-device 6

USBGuardでは、ブロックと拒否の用語を以下の意味で使用しています。

block - 今は、このデバイスとはやりとりしない
reject - このデバイスを if not exist と無視します。

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)マニュアルページの「IPCアクセスコントロール」の項を参照してください。

4.12.3. Rule Language を使用した独自のポリシーの作成

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)のマニュアルページを参照してください。

例4.6 USBguard のサンプルポリシー

USB mass ストレージデバイスと、その他のものをすべてブロックする

このポリシーは、大量ストレージデバイスではないデバイスをブロックします。USB フラッシュドライブに非表示のキーボードインターフェースを持つデバイスは、ブロックされます。オペレーティングシステムと対話できるのは、mass ストレージインターフェースが 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:*:* }

注記

ブラックリストは間違ったアプローチであるため、デバイスセットをブラックリストに指定して、残りを許可すべきではありません。上記のポリシーは、ブロックが暗黙的のデフォルトであることを前提としています。「bad」とみなされるデバイスのセットを拒否する方法は、できるだけ多くのデバイスにシステムの公開を制限する方法が推奨されます。

キーボードのみの 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などのAEAD（ Authenticated Encryption with AssociatedData）モードの暗号をサポートしており、これらの暗号には既知の問題はありません。上記の緩和策はすべて、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'

ciphersサブコマンドに他のパラメータ（OpenSSLのドキュメントでは暗号文字列やキーワードと呼ばれている）を渡すことで、出力を絞り込むことができます。特別なキーワードを使用して、特定の条件を満たすスイートのみを一覧表示できます。例えば、HIGH グループに属すると定義されているスイートのみをリストアップするには、次のコマンドを使用します。

~]$ openssl ciphers -v 'HIGH'

使用可能なキーワードと暗号文字列の一覧は、ciphers(1) のマニュアルページを参照してください。

「有効にするアルゴリズムの選択」の推奨事項を満たす暗号化スイートを一覧表示するには、以下のようなコマンドを実行します。

~]$ 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インストールでは、最適なデフォルト設定値が用意されており、大半のユースケースに十分なセキュリティを提供しています。特別なセキュリティー要件を満たす必要がある場合は、指定されたデフォルトを使用することが推奨されます。

gnutls-cliコマンドに-l（または--list）オプションを付けて使用すると、サポートされているすべての暗号スイートの一覧が表示されます。

~]$ gnutls-cli -l

lオプションで表示される暗号スイートのリストを絞り込むには、--priorityオプションに1つ以上のパラメータ（GnuTLSのドキュメントでは優先度文字列やキーワードと呼ばれています）を渡します。利用可能なすべての優先度文字列の一覧は、GnuTLSのドキュメント（http://www.gnutls.org/manual/gnutls.html#Priority-Strings）を参照してください。たとえば、次のコマンドを実行して、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 サーバーの設定

Apache HTTP Server は、TLS のニーズに OpenSSL ライブラリーおよび NSS ライブラリーの両方を使用できます。 TLSライブラリの選択に応じて、mod_sslまたはmod_nssモジュール（同名のパッケージで提供）をインストールする必要があります。例えば、OpenSSL のmod_sslモジュールを提供するパッケージをインストールするには、rootで以下のコマンドを実行します。

~]# yum install mod_ssl

mod_ssl パッケージは、/etc/httpd/conf.d/ssl.conf 設定ファイルをインストールします。これは、Apache HTTP Server の TLS 関連の設定を変更するのに使用できます。同様に、mod_nssパッケージは、/etc/httpd/conf.d/nss.conf設定ファイルをインストールします。

httpd-manual パッケージをインストールして、TLS 設定を含む Apache HTTP サーバーの完全ドキュメントを取得します。/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. 共通システム証明書の使用

Shared System Certificates ストレージは、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. 新しい証明書の追加

シンプルなPEMファイル形式やDERファイル形式の証明書を、システムで信頼されているCAのリストに追加するには、証明書ファイルを/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/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パッケージをインストールします。

~]# yum install scrub

スクラブユーティリティは、以下の基本モードのいずれかで動作します。

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

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

scrub [OPTIONS] special 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(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 設定ツールのインストール

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

~]# yum install firewall-config

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

firewall-configを実行するには、firewall-configコマンドを使うか、Superキーを押してActivity Overviewに入り、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ツールを起動し、「Configuration」と書かれたメニューから「Permanent」を選択します。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 --new-zone=zone-name
```
作成したゾーンが永続設定に追加されたかどうかを確認します。
```
~]# 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 http
  ...

5.8.6. プロトコルに基づいてゾーンが許可するトラフィックの設定

プロトコルに基づいて、ゾーンが着信トラフィックを許可できます。指定したプロトコルを使用したすべてのトラフィックがゾーンにより許可されていますが、そこにさらにルールおよびフィルタリングを適用できます。

ゾーンへのプロトコルの追加

特定ゾーンへプロトコルを追加すると、このゾーンが許可するこのプロトコルを使用するすべてのトラフィックを許可します。

プロトコルをゾーンに追加するには、次のコマンドを実行します。

~]# firewall-cmd --zone=zone-name --add-protocol=port-name/tcp|udp|sctp|dccp|igmp

注記

マルチキャストトラフィックを受けるには、--add-protocol オプションで igmp 値を使用します。

ゾーンからプロトコルの削除

特定ゾーンからプロトコルを削除するには、ゾーンにより、このプロトコルに基づいたすべてのトラフィックの許可を停止します。

ゾーンからプロトコルを削除するには、次のコマンドを削除します。

~]# firewall-cmd --zone=zone-name --remove-protocol=port-name/tcp|udp|sctp|dccp|igmp

5.9. ポート転送

firewalld を使用して、システムで特定のポートを到達するための着信トラフィックが、選択した別の内部ポート、または別のマシンの外部ポートに配信されるようにポートのリダイレクトを設定できます。

5.9.1. リダイレクトするポートの追加

あるポートから別のポートにトラフィックをリダイレクトする前に、パケットが到達するポート、使用されるプロトコル、リダイレクト先を確認しておく必要があります。

ポートを別のポートにリダイレクトする場合は、次のコマンドを実行します。

~]# firewall-cmd --add-forward-port=port=port-number:proto=tcp|udp|sctp|dccp:toport=port-number

別の IP アドレスで、別のポートにポートをリダイレクトする場合は、次のコマンドを実行します。

転送するポートを追加します。

~]# firewall-cmd --add-forward-port=port=port-number:proto=tcp|udp:toport=port-number:toaddr=IP

マスカレードを有効にします。
```
~]# firewall-cmd --add-masquerade
```

例5.1 同一マシンで TCP ポート 80 からポート 88 へのリダイレクト

ポートをリダイレクトするには、以下を行います。

TCP トラフィックに対して、ポート 80 からポート 88 へリダイレクトします。
```
~]# firewall-cmd --add-forward-port=port=80:proto=tcp:toport=88
```
新しい設定を永続化します。
```
~]# firewall-cmd --runtime-to-permanent
```
そのポートがリダイレクトされていることを確認します。
```
~]# firewall-cmd --list-all 
```

5.9.2. リダイレクトしているポートの削除

リダイレクトしているポートを削除するには、次のコマンドを実行します。

~]# firewall-cmd --remove-forward-port=port=port-number:proto=<tcp|udp>:toport=port-number:toaddr=<IP>

別のアドレスにリダイレクトした転送ポートを削除するには、以下を実行します。

転送したポートを削除するには、以下を行います。

~]# firewall-cmd --remove-forward-port=port=port-number:proto=<tcp|udp>:toport=port-number:toaddr=<IP>

マスカレードを無効にするには、次のコマンドを実行します。
```
~]# firewall-cmd --remove-masquerade
```

注記

この方法を使用するポートのリダイレクトは、IPv4 ベースのトラフィックでのみ機能します。IPv6 リダイレクト設定には、リッチルールを使用する必要があります。詳細は、「「Rich Language」の構文を使用した複合ファイアウォールルールの設定」を参照してください。

外部システムにリダイレクトするには、マスカレードを有効にする必要があります。詳細は、「IP アドレスのマスカレードの設定」を参照してください。

例5.2 同じマシンで TCP ポート 88 に転送されるポート 80 の削除

ポートのリダイレクトを削除するには、以下を行います。

リダイレクトしたポートの一覧を表示します。

~]# firewall-cmd --list-forward-ports 
port=80:proto=tcp:toport=88:toaddr=

ファイアウォールからリダイレクトしたポートを削除します。
```
~]# firewall-cmd --remove-forward-port=port=80:proto=tcp:toport=88:toaddr=
```
新しい設定を永続化します。
```
~]# firewall-cmd --runtime-to-permanent
```

5.10. IP アドレスのマスカレードの設定

external ゾーンなどで IP マスカレーディングが有効かどうかを確認するには、root で次のコマンドを実行します。

~]# firewall-cmd --zone=external --query-masquerade

このコマンドでは、有効な場合は yes と出力され、終了ステータスは 0 になります。無効の場合は no と出力され、終了ステータスは 1 になります。zone を省略すると、デフォルトのゾーンが使用されます。

IP マスカレードを有効にするには、root で次のコマンドを実行します。

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

この設定を永続的にするには、--permanent オプションを追加してコマンドを繰り返します。

IP マスカレードを無効にするには、root で次のコマンドを実行します。

~]# firewall-cmd --zone=external --remove-masquerade

この設定を永続的にするには、--permanent オプションを追加してコマンドを繰り返します。

5.11. `ICMP` リクエストの管理

Internet Control Message Protocol (ICMP) は、接続問題 (要求されているサービスが利用できないなど) を示すエラーメッセージと運用情報を送信するために、様々なネットワークデバイスにより使用されているサポート対象のプロトコルです。ICMP は、システム間でデータを交換するのに使用されていないため、TCP、UDP などの転送プロトコルとは異なります。

ただし、ICMP メッセージ (特に echo-request および echo-reply) を利用して、ネットワークに関する情報を明らかにし、その情報をさまざまな不正行為に悪用することが可能です。したがって、firewalld は、ネットワーク情報を保護するため、ICMP リクエストをブロックできます。

5.11.1. `ICMP` リクエストの一覧表示

ICMP リクエストは、/usr/lib/firewalld/icmptypes/ ディレクトリーにある各 XML ファイルで説明されています。リクエストの説明は、このファイルを参照してください。firewall-cmd コマンドは、ICMP リクエストの操作を制御します。

利用可能な ICMP タイプの一覧を表示するには、次のコマンドを実行します。

~]# firewall-cmd --get-icmptypes

ICMP リクエストは、IPv4、IPv6、またはその両方のプロトコルで使用できます。ICMP リクエストが使用されてるプロトコルを表示するには、次のコマンドを実行します。

~]# firewall-cmd --info-icmptype=<icmptype>

ICMP リクエストのステータスは、リクエストが現在ブロックされている場合は yes、ブロックされていない場合は no となります。ICMP リクエストが現在ブロックされているかどうかを確認するには、次のコマンドを実行します。

~]# firewall-cmd --query-icmp-block=<icmptype>

5.11.2. `ICMP` リクエストのブロックまたはブロックの解除

サーバーが ICMP リクエストをブロックした場合は、通常の情報が提供されません。ただし、情報が全く提供されないというわけではありません。クライアントは、特定の ICMP リクエストがブロックされている (拒否されている) 情報を受け取ります。ICMP リクエストは、特に IPv6 トラフィックを使用すると、接続問題が発生することがあるため、注意深く検討する必要があります。

ICMP リクエストが現在ブロックされているかどうかを確認するには、次のコマンドを実行します。

~]# firewall-cmd --query-icmp-block=<icmptype>

ICMP リクエストをブロックするには、次のコマンドを実行します。

~]# firewall-cmd --add-icmp-block=<icmptype>

ICMP リクエストのブロックを削除するには、次のコマンドを実行します。

~]# firewall-cmd --remove-icmp-block=<icmptype>

5.11.3. 情報を提供せずに `ICMP` リクエストのブロック

通常、ICMP リクエストをブロックすると、ブロックしていることをクライアントは認識します。したがって、ライブの IP アドレスを傍受している潜在的な攻撃者は、IP アドレスがオンラインであることを確認できます。この情報を完全に非表示にするには、ICMP リクエストをすべて破棄する必要があります。

すべての ICMP リクエストをブロックして破棄するには、次のコマンドを実行します。

ゾーンのターゲットを DROP に設定します。
```
~]# firewall-cmd --set-target=DROP
```
新しい設定を永続化します。
```
~]# firewall-cmd --runtime-to-permanent
```

これで、明示的に許可されるトラフィックを除き、ICMP リクエストを含むすべてのトラフィックが破棄されます。

特定の ICMP リクエストをブロックして破棄し、その他のリクエストを許可するには、以下を行います。

ゾーンのターゲットを DROP に設定します。
```
~]# firewall-cmd --set-target=DROP
```
すべての ICMP リクエストを一度にブロックする、ICMP ブロックの反転を追加します。
```
~]# firewall-cmd --add-icmp-block-inversion
```
許可する ICMP リクエストに ICMP ブロックを追加する場合は、次のコマンドを実行します。
```
~]# firewall-cmd --add-icmp-block=<icmptype>
```
新しい設定を永続化します。
```
~]# firewall-cmd --runtime-to-permanent
```

ブロックの反転 は、ICMP リクエストブロックの設定を反転します。そのため、ブロックしていないリクエストをすべてブロックするようになります。ブロックされているものはブロックされません。したがって、リクエストのブロックを解除する必要がある場合は、ブロックコマンドを使用してください。

これを完全許容(Permissive)設定に戻すには、次のコマンドを実行します。

ゾーンのターゲットを default または ACCEPT に戻すには、次のコマンドを設定します。
```
~]# firewall-cmd --set-target=default
```
ICMP リクエストに追加したすべてのブロックを削除します。
```
~]# firewall-cmd --remove-icmp-block=<icmptype>
```

ICMP ブロックの反転を削除します。

~]# firewall-cmd --remove-icmp-block-inversion

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

5.11.4. GUI を使用した `ICMP` フィルターの設定

ICMP フィルターを有効または無効にするには、firewall-config ツールを起動して、フィルターをかけるメッセージのネットワークゾーンを選択します。ICMP フィルタータブを選択し、フィルターをかける ICMP メッセージの各タイプのチェックボックスを選択します。フィルターを無効にするには、チェックボックスの選択を外します。これは方向ごとに設定され、デフォルトではすべてが許可されます。

ICMP タイプを編集するには、firewall-config ツールを起動してから設定ラベルのあるメニューで永続モードを選択します。サービスウィンドウの下部に新たなアイコンが表示されます。以下のダイアログではいを選択し、マスカレーディングを有効にし、動作している別のマシンに転送します。

ICMP フィルターの反転を有効にするには、右側のフィルターの反転チェックボックスをクリックします。マークがついた ICMP タイプだけが許可され、その他はすべて拒否されます。DROP ターゲットを使用するゾーンでは破棄されます。

5.12. `firewalld` を使用した IP セットの設定および制御

firewalld で対応する IP セットタイプの一覧を表示するには、root で次のコマンドを実行します。

~]# firewall-cmd --get-ipset-types
hash:ip hash:ip,mark hash:ip,port hash:ip,port,ip hash:ip,port,net hash:mac hash:net hash:net,iface hash:net,net hash:net,port hash:net,port,net

5.12.1. コマンドラインクライアントを使用した IP 設定オプションの設定

IP セットは、firewalld ゾーンでソースとして使用でき、リッチルールでソースとして使用できます。Red Hat Enterprise Linux 7では、firewalldで作成したIPセットをダイレクトルールで使用する方法が推奨されています。

永続的な環境で firewalld に認識されている IP セットの一覧を表示するには、次のコマンドを root で実行します。

~]# firewall-cmd --permanent --get-ipsets

新しい IP セットを追加するには、永続化環境を使用し、root で次のコマンドを実行します。

~]# firewall-cmd --permanent --new-ipset=test --type=hash:net
success

上記のコマンドは、名前 test とタイプ hash:net で、IPv4 の新しい IP セットを作成します。IPv6 で使用する IP セットを作成する場合は、--option=family=inet6 オプションを追加します。ランタイム環境で新しい設定を有効にするには、firewalld を再読み込みします。root で次のコマンドを実行して、新しい IP セットの一覧を表示します。

~]# firewall-cmd --permanent --get-ipsets
test

IP セットの詳細は、root で次のコマンドを実行します。

~]# firewall-cmd --permanent --info-ipset=test
test
type: hash:net
options:
entries:

この時点では IP セットにエントリーがありません。IP セット test にエントリーを追加するには、root で次のコマンドを実行します。

~]# firewall-cmd --permanent --ipset=test --add-entry=192.168.0.1
success

上記のコマンドは、IP アドレス 192.168.0.1 を IP セットに追加します。IP セットの現在のエントリーを一覧表示するには、root で次のコマンドを実行します。

~]# firewall-cmd --permanent --ipset=test --get-entries
192.168.0.1

IP アドレスの一覧を含むファイルを生成します。以下に例を示します。

~]# cat > iplist.txt <<EOL
192.168.0.2
192.168.0.3
192.168.1.0/24
192.168.2.254
EOL

IP セットの IP アドレスの一覧が含まれるファイルには、行ごとにエントリーが含まれている必要があります。ハッシュ、セミコロン、また空の行から始まる行は無視されます。

iplist.txt ファイルからアドレスを追加するには、root で次のコマンドを実行します。

~]# firewall-cmd --permanent --ipset=test --add-entries-from-file=iplist.txt
success

拡張された IP セットのエントリー一覧を表示するには、root で次のコマンドを実行します。

~]# firewall-cmd --permanent --ipset=test --get-entries
192.168.0.1
192.168.0.2
192.168.0.3
192.168.1.0/24
192.168.2.254

IP セットからアドレスを削除し、更新したエントリー一覧を確認するには、root で次のコマンドを実行します。

~]# firewall-cmd --permanent --ipset=test --remove-entries-from-file=iplist.txt
success
~]# firewall-cmd --permanent --ipset=test --get-entries 192.168.0.1

IP セットをゾーンへのソースとして追加し、ゾーンを使用して、IP セットに記載されるアドレスから受信するすべてのトラフィックを処理します。たとえば、IP セットの test をソースとして drop ゾーンに追加し、IP セットの test の一覧に表示されるすべてのエントリーから発信されるパケットをすべて破棄するには、root で次のコマンドを実行します。

~]# firewall-cmd --permanent --zone=drop --add-source=ipset:test
success

ソースの ipset: プレフィックスは、ソースが IP セットで、IP アドレスまたはアドレス範囲ではない firewalld を示しています。

IP セットの作成および削除は、永続環境に限定されますが、その他の IP セットオプションは、--permanent オプションを使用しないランタイム環境で使用できます。

5.12.2. IP セットのカスタムサービスの設定

firewalldの起動前にIPセット構造を作成してロードするようにカスタムサービスを設定するには

rootで起動しているエディターを使って、以下のようなファイルを作成します。

~]# vi /etc/systemd/system/ipset_name.service
[Unit]
Description=ipset_name
Before=firewalld.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/bin/ipset_name.sh start
ExecStop=/usr/local/bin/ipset_name.sh stop

[Install]
WantedBy=basic.target

firewalld で IP セットを永続的に使用します。

~]# vi /etc/firewalld/direct.xml
<?xml version="1.0" encoding="utf-8"?>
<direct>
	<rule ipv="ipv4" table="filter" chain="INPUT" priority="0">-m set --match-set <replaceable>ipset_name</replaceable> src -j DROP</rule>
</direct>

変更内容を有効にするには、firewalldのリロードが必要です。
```
~]# firewall-cmd --reload
```
これにより、状態情報が失われることなくファイアウォールが再読み込みされます（TCP セッションは終了しません）、再読み込み時にサービスの中断が生じる可能性があります。

警告

Red Hat は、firewalld を介して管理していない IP セットを使用することは推奨しません。このような IP セットを使用すると、そのセットを参照する永続的なダイレクトルールが必要で、IP セットを作成するカスタムサービスを追加する必要があります。このサービスは、firewalld を起動する前に起動する必要があります。先に起動しておかないと、firewalld が、このセットを使用してダイレクトルールを追加できません。/etc/firewalld/direct.xml ファイルを使用して、永続的なダイレクトルールを追加できます。

5.13. `iptables` を使用した IP セットの設定および制御

firewalldとiptables（およびip6tables）サービスの本質的な違いは以下の通りです。

iptablesサービスでは、/etc/sysconfig/iptablesと/etc/sysconfig/ip6tablesに設定を保存し、firewalldでは/usr/lib/firewalld/と/etc/firewalld/にある様々なXMLファイルに設定を保存しています。なお、Red Hat Enterprise Linuxではfirewalldがデフォルトでインストールされているため、/etc/sysconfig/iptablesファイルは存在しません。
iptablesサービスでは、変更のたびに古いルールをすべて消去し、/etc/sysconfig/iptablesから新しいルールをすべて読み込む必要がありますが、firewalldではすべてのルールを再作成する必要はありません。相違点のみが適用されます。その結果、firewalldは実行時に設定を変更しても、既存の接続が失われることはありません。

どちらも、カーネルのパケットフィルターと対話するためにiptablesツールを使用しています。

firewalld の代わりに iptables および ip6tables の各サービスを使用するには、まず root で以下のコマンドを実行して firewalld を無効にします。

~]# systemctl disable firewalld
~]# systemctl stop firewalld

そして、rootで以下のコマンドを入力して、iptables-servicesパッケージをインストールします。

~]# yum install iptables-services

iptables-servicesパッケージには、iptablesサービスとip6tablesサービスが含まれています。

そして、iptablesとip6tablesのサービスを開始するために、rootで以下のコマンドを入力します。

~]# systemctl start iptables
~]# systemctl start ip6tables

すべてのシステム起動時にサービスが起動するようにするには、以下のコマンドを実行します。

~]# systemctl enable iptables
~]# systemctl enable ip6tables

ipsetユーティリティは、LinuxカーネルのIPセットを管理するために使用されます。IP セットは、IP アドレス、ポート番号、IP アドレスと MAC アドレスのペア、または IP アドレスとポート番号のペアを保存するフレームワークです。セットは、セットが非常に大きくなっても、セットに対して非常に高速な一致が行われるようにインデックス化されます。IPセットは、よりシンプルで管理しやすい設定を可能にするだけでなく、iptablesを使用する際のパフォーマンスを向上させます。セットを参照するiptablesのマッチとターゲットは、カーネル内で指定されたセットを保護する参照を作成します。参照が 1 つある場合は、セットを破棄できません。

ipsetを使うと、以下のようなiptablesのコマンドをセットで置き換えることができます。

~]# iptables -A INPUT -s 10.0.0.0/8 -j DROP
~]# iptables -A INPUT -s 172.16.0.0/12 -j DROP
~]# iptables -A INPUT -s 192.168.0.0/16 -j DROP

セットは、以下のように作成されます。

~]# ipset create my-block-set hash:net
~]# ipset add my-block-set 10.0.0.0/8
~]# ipset add my-block-set 172.16.0.0/12
~]# ipset add my-block-set 192.168.0.0/16

このセットは、以下のようにiptablesコマンドで参照されます。

~]# iptables -A INPUT -m set --set my-block-set src -j DROP

設定時間が 1 回以上使用されると、設定時間が長くなります。セットに多くのエントリーが含まれている場合は、処理時間が長くなります。

5.14. ダイレクトインターフェースの使用

firewall-cmdツールの--directオプションを使うことで、ランタイム中にチェーンを追加・削除することが可能です。以下にいくつか例を示します。詳しくは、firewall-cmd(1)のマニュアルページをご覧ください。

iptablesにあまり精通していない人がダイレクトインターフェースを使用するのは、誤ってファイアウォールに侵入してしまう可能性があるので危険です。

ダイレクトインターフェースモードは、ランタイム中にサービスまたはアプリケーションが特定のファイアウォールルールを追加することが意図されています。ルールを永続的なものにするには、firewall-cmd --permanent --directコマンドで--permanentオプションを追加するか、/etc/firewalld/direct.xmlを修正します。 etc/firewalld/direct.xmlファイルについては、manfirewalld.direct(5)を参照してください。

5.14.1. ダイレクトインターフェースを使用するルールの追加

「IN_public_allow」チェーンにルールを追加するには、rootで次のコマンドを入力します。

~]# firewall-cmd --direct --add-rule ipv4 filter IN_public_allow \
        0 -m tcp -p tcp --dport 666 -j ACCEPT

設定を永続的なものにするために、--permanentオプションを追加します。

5.14.2. ダイレクトインターフェースを使用したルールの削除

「IN_public_allow」チェーンからルールを削除するには、rootで次のコマンドを入力します。

~]# firewall-cmd --direct --remove-rule ipv4 filter IN_public_allow \
        0 -m tcp -p tcp --dport 666 -j ACCEPT

設定を永続的なものにするために、--permanentオプションを追加します。

5.14.3. ダイレクトインターフェースを使用したルールの一覧表示

「IN_public_allow」チェーンのルールを一覧表示するには、rootで次のコマンドを入力します。

~]# firewall-cmd --direct --get-rules ipv4 filter IN_public_allow

なお、このコマンド（--get-ruleオプション）は、--add-ruleオプションで追加したルールのみをリストアップします。他の方法で追加された既存のiptablesのルールはリストアップされません。

5.15. 「Rich Language」の構文を使用した複合ファイアウォールルールの設定

「豊富な言語」構文により、複雑なファイアウォールルールを、ダイレクトインターフェース方式よりもわかりやすく作成することができます。さらに、設定は永続化できます。この言語は、値を持つキーワードを使用し、iptablesのルールを抽象的に表現したものです。ゾーンは、この言語を使用して設定できますが、現在の設定方法は引き続きサポートされます。

5.15.1. リッチ言語コマンドの形式

このセクションのコマンドは、すべてrootで実行する必要があります。ルールを追加するコマンドの形式は以下のとおりです。

firewall-cmd [--zone=zone][]

--add-rich-rule='rule' --timeout=timeval

これにより、ゾーンゾーンにリッチランゲージルールのルールが追加されます。このオプションは複数回指定できます。ゾーンを省略すると、デフォルトのゾーンが使用されます。タイムアウトを指定すると、ルールまたはルールは指定された期間のみアクティブな状態を維持し、後で自動的に削除されます。時間値の後にs（秒）、m（分）、h（時）をつけて、時間の単位を指定することができます。デフォルトは秒です。

ルールの削除

firewall-cmd [--zone=zone]

--remove-rich-rule='rule'

これにより、ゾーンゾーンのリッチランゲージルール規則が削除されます。このオプションは複数回指定できます。ゾーンを省略すると、デフォルトのゾーンが使用されます。

ルールが存在するかを確認するには、以下を実行します。

firewall-cmd [--zone=zone]

--query-rich-rule='rule'

これは、ゾーンゾーンにリッチランゲージルールのルールが追加されたかどうかを返します。このコマンドでは、有効な場合は yes と出力され、終了ステータスは 0 になります。無効の場合は no と出力され、終了ステータスは 1 になります。ゾーンを省略すると、デフォルトのゾーンが使用されます。

ゾーン設定ファイルで使われているリッチな言語表現については、firewalld.zone(5) manページを参照してください。

5.15.2. リッチルールの構造について

リッチルールコマンドの形式または構造は以下のとおりです。

rule [family="rule family]"
    [ source [NOT][][][]] address="address" mac="mac-address" ipset="ipset" 
    [ destination [NOT]] address="address" 
    [ element] 
    [ log [prefix="prefix text][][]]" level="log level" limit value="rate/duration" 
    [ audit ]
    [ action]

注記

ファイル内のリッチルールの構造では、NOTキーワードを使用して送信元と送信先のアドレスコマンドの意味を反転させていますが、コマンドラインではinvert="true"オプションを使用しています。

ルールは特定のゾーンに関連付けられています。ゾーンには複数のルールを関連付けることができます。一部のルールが対話または矛盾する場合、そのパケットに一致する最初のルールが適用されます。

5.15.3. リッチルールのコマンドオプションについて

family: ルールファミリーにipv4またはipv6が指定されている場合は、ルールをそれぞれIPv4またはIPv6に限定します。ルールファミリーが指定されていない場合は、IPv4とIPv6の両方に対してルールが追加されます。ルール内で送信元または宛先アドレスを使用する場合は、ルールファミリーを指定する必要があります。これは、ポート転送も該当します。

ソースアドレスおよび宛先のアドレス

source: ソースアドレスを指定すると、接続試行の起点をソースアドレスに限定できます。送信元アドレスまたはアドレス範囲は、IPv4またはIPv6のIPアドレスまたはマスク付きネットワークIPアドレスです。 IPv4では、マスクにはネットワークマスクまたはプレーンナンバーを使用します。IPv6 のマスクは単純な番号になります。ホスト名の使用はサポートされません。 NOTキーワードを追加することで、ソースアドレスコマンドの意味を反転させることができ、指定されたアドレス以外はすべてマッチします。
ルールにファミリーが指定されていない場合は、IPv4およびIPv6のMACアドレスおよびタイプがhash:macのIPセットを追加できます。他のIPセットは、ルールのファミリー設定と一致する必要があります。
destination: 宛先アドレスを指定して、ターゲットを宛先アドレスに制限することができます。宛先アドレスは、IP アドレスまたはアドレス範囲のソースアドレスと同じ構文を使用します。ソースアドレスおよび宛先アドレスの使用は任意ですが、宛先アドレスはすべての要素で使用することはできません。これは、サービスエントリーなどの宛先アドレスの使用によって異なります。 デスティネーションとアクションを組み合わせることができます。

要素

要素の種類は、service、port、protocol、masquerade、icmp-block、forward-port、source-portの中から1つだけを指定します。

サービス

サービスエレメントは、firewalldが提供するサービスの1つです。事前定義したサービス一覧を取得するには、以下のコマンドを入力します。

~]$ firewall-cmd --get-services

サービスが宛先アドレスを提供する場合は、ルール内の宛先アドレスと競合してエラーが発生します。宛先アドレスを使用するサービスは、主にマルチキャストを使用するサービスです。コマンドの形式は、

service name=service_name

になります。

ポート

port要素には、単一のポート番号または5060～5062などのポート範囲を指定し、その後にtcpまたはudpのプロトコルを指定します。コマンドの形式は、

port port=number_or_range protocol=protocol

になります。

protocol

プロトコル値には、プロトコルID番号またはプロトコル名を指定します。許可されるプロトコルエントリについては、/etc/protocolsを参照してください。コマンドの形式は、

protocol value=protocol_name_or_ID

になります。

icmp-block

1 つ以上の ICMP タイプをブロックするには、このコマンドを使用します。 ICMPタイプは、firewalldがサポートするICMPタイプの1つです。サポートされているICMPタイプの一覧を表示するには、次のコマンドを入力します。

~]$ firewall-cmd --get-icmptypes

ここではアクションの特定はできません。icmp-blockは、アクションrejectを内部的に使用します。コマンドの形式は、

icmp-block name=icmptype_name

になります。

masquerade

ルール内の IP マスカレードを有効にします。ソースアドレスは、この領域へのマスカレードを制限できますが、宛先アドレスではありません。ここではアクションの特定はできません。

forward-port

プロトコルがtcpまたはudpに指定されたローカルポートからのパケットを、ローカルの他のポート、他のマシン、または他のマシンの他のポートのいずれかに転送する。 portおよびto-portには、単一のポート番号またはポートの範囲を指定できます。宛先アドレスは単純な IP アドレスです。ここではアクションの特定はできません。 forward-portコマンドは、内部でactionacceptを使用しています。コマンドは以下の形式になります。

forward-port port=number_or_range protocol=protocol /
            to-port=number_or_range to-addr=address

source-port

パケットのソースポートにマッチします。接続試行の起点で使用されるポート。現在のマシンのポートに一致させるには、port要素を使用します。 source-port要素には、単一のポート番号、またはポートの範囲（例えば、5060-5062）を指定し、その後にtcpまたはudpのプロトコルを指定します。コマンドは以下の形式になります。

source-port port=number_or_range protocol=protocol

ロギング

log

新しい接続をログに記録すると、カーネルロギング（syslog など）でルールが試行されます。ログメッセージに追加する接頭辞テキストを接頭辞として定義できます。ログレベルは、emerg、alert、crit、error、warning、notice、info、debugのいずれかです。ログの使用はオプションです。以下のようにログを制限することが可能です。

log [prefix=prefix text] [level=log level] limit value=rate/duration

レートは自然な正の数[1, ...]で、期間はs,m,h,dとなります。sは「秒」、mは「分」、hは「時間」、dは「日」を意味します。最大制限値は1/dで、1日に最大1つのログエントリを意味します。

audit

Auditは、サービスauditdに送信される監査記録を使用してログを記録する代替手段を提供します。監査タイプは、ACCEPT、REJECT、DROPのいずれかを指定できますが、監査タイプはルールアクションから自動的に収集されるため、コマンド監査の後には指定しません。監査には独自のパラメーターがありませんが、制限をオプションに追加できます。監査の使用はオプションになります。

アクション

accept|reject|drop|mark

アクションは、accept、reject、drop、markのいずれかです。ルールには要素またはソースのみを含めることができます。ルールに要素が含まれる場合には、要素に一致する新しい接続はアクションで処理されます。ルールにソースが含まれる場合、ソースアドレスのすべてのものは指定されたアクションで処理されます。

accept | reject [type=reject type] | drop | mark set="mark[/mask]"

acceptでは、すべての新規接続試行が許可されます。 rejectの場合、それらは拒否され、そのソースには拒否メッセージが表示されます。reject タイプは別の値を使用するように設定できます。 dropでは、すべてのパケットが直ちにドロップされ、ソースには何の情報も送られません。 マークでは、すべてのパケットに指定されたマークとオプションのマスクが付けられます。

5.15.4. リッチルールログコマンドの使用

ログの記録は、Netfilterのログターゲットでも、監査ターゲットでも行うことができます。すべてのゾーンに、「zone」_log（zoneはゾーン名）という形式の名前で新しいチェーンが追加される。これは、適切な順序であるために、デニーチェーンの前に処理されます。ルールやその一部は、ルールの作用に応じて、以下のように別々のチェーンに配置されています。

zone_log
			zone_deny
			zone_allow

すべてのロギングルールは「zone」_logチェインに配置され、最初に解析されます。すべての拒否およびドロップルールは「zone」_denyチェーンに置かれ、logチェーンの後に解析されます。すべての受け入れルールはzone_allowチェーンに配置され、denyチェーンの後に解析されます。ルールにログが含まれ、さらに拒否または許可のアクションがある場合、これらのアクションを指定するルールの部分がマッチングチェーンに配置されます。

5.15.4.1. リッチルールログコマンドの使用例 1

認証ヘッダープロトコルAHの新規IPv4およびIPv6接続を有効にする。

rule protocol value="ah" accept

5.15.4.2. リッチルールログコマンドの使用例 2

プロトコルFTPの新しいIPv4およびIPv6接続を許可し、監査を使用して1分ごとに1件のログを記録する。

rule service name="ftp" log limit value="1/m" audit accept

5.15.4.3. リッチルールログコマンドの使用例 3

アドレス192.168.0.0/24からの新しいIPv4接続をプロトコルTFTPで許可し、syslogを使って1分ごとに1回ログを取る。

rule family="ipv4" source address="192.168.0.0/24" service name="tftp" log prefix="tftp" level="info" limit value="1/m" accept

5.15.4.4. リッチルールログコマンドの使用例 4

プロトコルRADIUS用の1:2:3:4:6::からの新しいIPv6接続がすべて拒否され、1分あたり3件の割合でログに記録されます。その他のソースからの新たな IPv6 接続は許可されます。

rule family="ipv6" source address="1:2:3:4:6::" service name="radius" log prefix="dns" level="info" limit value="3/m" reject
rule family="ipv6" service name="radius" accept

5.15.4.5. リッチルールログコマンドの使用例 5

ポート4011の1:2:3:4:6::からプロトコルTCPで受信したIPv6パケットをポート4012の1::2:3:4:7に転送します。

rule family="ipv6" source address="1:2:3:4:6::" forward-port to-addr="1::2:3:4:7" to-port="4012" protocol="tcp" port="4011"

5.15.4.6. リッチルールログコマンドの使用例 6

ソースアドレスをホワイトリストに登録して、このソースからのすべての接続を許可します。

rule family="ipv4" source address="192.168.2.2" accept

詳しい例は、firewalld.richlanguage(5)のマニュアルページを参照してください。

5.16. ファイアウォールロックダウンの設定

ローカルのアプリケーションやサービスは、root で実行していれば、ファイアウォール設定を変更できます (たとえば libvirt)。管理者は、この機能を使用してファイアウォール設定をロックし、すべてのアプリケーションでファイアウォール変更を要求できなくするか、ロックダウンのホワイトリストに追加されたアプリケーションのみがファイアウォール変更を要求できるようにすることが可能になります。ロックダウン設定はデフォルトで無効になっています。これを有効にすると、ローカルのアプリケーションやサービスによるファイアウォールへの望ましくない設定変更を確実に防ぐことができます。

5.16.1. コマンドラインクライアントを使用したロックの設定

ロックダウンが有効になっているかどうかを確認するには、root で次のコマンドを使用します。

~]# firewall-cmd --query-lockdown

ロックダウンが有効な場合は、yes と出力され、終了ステータスは 0 になります。無効の場合は no と出力され、終了ステータスは 1 になります。

ロックダウンを有効にするには、root で次のコマンドを実行します。

~]# firewall-cmd --lockdown-on

ロックダウンを無効にするには、root で次のコマンドを実行します。

~]# firewall-cmd --lockdown-off

5.16.2. コマンドラインクライアントを使用したロックダウンホワイトリストオプションの設定

ロックダウンのホワイトリストには、コマンド、セキュリティーのコンテキスト、ユーザー、およびユーザー ID を追加できます。ホワイトリストのコマンドエントリーがアスタリスク「「*」」で終了している場合は、そのコマンドで始まるすべてのコマンドラインが一致することになります。「「*」」がなければ、コマンドと引数が完全に一致する必要があります。

ここでのコンテキストは、実行中のアプリケーションやサービスのセキュリティー (SELinux) コンテキストです。実行中のアプリケーションのコンテキストを確認するには、次のコマンドを実行します。

~]$ ps -e --context

このコマンドは、実行中のアプリケーションをすべて返します。grep ツールを使用して、出力から目的のアプリケーションをパイプ処理します。以下に例を示します。

~]$ ps -e --context | grep example_program

ホワイトリストにあるコマンドラインの一覧を表示するには、root で次のコマンドを実行します。

~]# firewall-cmd --list-lockdown-whitelist-commands

ホワイトリストに command コマンドを追加するには、root で次のコマンドを実行します。

~]# firewall-cmd --add-lockdown-whitelist-command='/usr/bin/python -Es /usr/bin/command'

ホワイトリストから command コマンドを削除するには、root で次のコマンドを実行します。

~]# firewall-cmd --remove-lockdown-whitelist-command='/usr/bin/python -Es /usr/bin/command'

command コマンドがホワイトリストに含まれるかどうかを確認するには、root で次のコマンドを実行します。

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

このコマンドでは、含まれる場合は yes が出力され、終了ステータスは 0 になります。無効の場合は no と出力され、終了ステータスは 1 になります。

ホワイトリストにあるセキュリティーコンテキストの一覧を表示するには、root で次のコマンドを実行します。

~]# firewall-cmd --list-lockdown-whitelist-contexts

ホワイトリストに context コンテキストを追加するには、root で次のコマンドを実行します。

~]# firewall-cmd --add-lockdown-whitelist-context=context

ホワイトリストから context コンテキストを削除するには、root で次のコマンドを実行します。

~]# firewall-cmd --remove-lockdown-whitelist-context=context

context コンテキストがホワイトリストに含まれるかどうかを確認するには、root で次のコマンドを実行します。

~]# firewall-cmd --query-lockdown-whitelist-context=context

含まれる場合は、yes と出力され、終了ステータスは 0 になります。含まれない場合は、no が出力され、終了ステータスは 1 になります。

ホワイトリストにあるユーザー ID の一覧を表示するには、root で次のコマンドを実行します。

~]# firewall-cmd --list-lockdown-whitelist-uids

ホワイトリストにユーザー ID (uid) を追加するには、root で次のコマンドを実行します。

~]# firewall-cmd --add-lockdown-whitelist-uid=uid

ホワイトリストからユーザー ID (uid) を削除するには、root で次のコマンドを実行します。

~]# firewall-cmd --remove-lockdown-whitelist-uid=uid

ホワイトリストにユーザー ID (uid) があるかどうかを確認するには、次のコマンドを実行します。

~]$ firewall-cmd --query-lockdown-whitelist-uid=uid

含まれる場合は、yes と出力され、終了ステータスは 0 になります。含まれない場合は、no が出力され、終了ステータスは 1 になります。

ホワイトリストにあるユーザー名の一覧を表示するには、root で次のコマンドを実行します。

~]# firewall-cmd --list-lockdown-whitelist-users

ホワイトリストにユーザー名 (user) を追加するには、root で次のコマンドを実行します。

~]# firewall-cmd --add-lockdown-whitelist-user=user

ホワイトリストからユーザー名 (user) を削除するには、root で次のコマンドを実行します。

~]# firewall-cmd --remove-lockdown-whitelist-user=user

ホワイトリストにユーザー名 (user) があるかどうかを確認するには、次のコマンドを実行します。

~]$ firewall-cmd --query-lockdown-whitelist-user=user

含まれる場合は、yes と出力され、終了ステータスは 0 になります。含まれない場合は、no が出力され、終了ステータスは 1 になります。

5.16.3. 設定ファイルを使用した Lockdown Whitelist オプションの設定

デフォルトのホワイトリスト設定ファイルには、NetworkManager コンテキストと、libvirt のデフォルトコンテキストが含まれます。リストには、ユーザー ID (0) もあります。

<?xml version="1.0" encoding="utf-8"?>
	<whitelist>
	  <selinux context="system_u:system_r:NetworkManager_t:s0"/>
	  <selinux context="system_u:system_r:virtd_t:s0-s0:c0.c1023"/>
	  <user id="0"/>
	</whitelist>

以下のホワイトリスト設定ファイルの例では、firewall-cmd ユーティリティーのコマンドと、ユーザー ID が 815 である user のコマンドをすべて有効にしています。

<?xml version="1.0" encoding="utf-8"?>
	<whitelist>
	  <command name="/usr/bin/python -Es /bin/firewall-cmd*"/>
	  <selinux context="system_u:system_r:NetworkManager_t:s0"/>
	  <user id="815"/>
	  <user name="user"/>
	</whitelist>

この例では、user id と user name の両方が使用されていますが、実際にはどちらか一方のオプションだけが必要です。Python はインタープリターとしてコマンドラインに追加されています。また、特定のコマンドを使用することもできます。例えば、

/usr/bin/python /bin/firewall-cmd --lockdown-on

この例では、--lockdown-onコマンドのみが許可されています。

注記

Red Hat Enterprise Linux 7 では、すべてのユーティリティは/usr/bin/ディレクトリに置かれ、/bin/ディレクトリは/usr/bin/ディレクトリにシンボリックリンクされています。つまり、rootで実行したときのfirewall-cmdのパスは、/bin/firewall-cmdに解決されるかもしれませんが、/usr/bin/firewall-cmdが使用できるようになりました。新たなスクリプトは、すべて新しい格納場所を使用する必要があります。ただし、rootで実行するスクリプトが/bin/firewall-cmdパスを使用するように書かれている場合は、従来から非rootユーザーにのみ使用されている/usr/bin/firewall-cmdパスに加えて、そのコマンドパスもホワイトリストに登録する必要があることに注意してください。

コマンドのname属性の最後の「*」は、この文字列で始まるすべてのコマンドにマッチすることを意味します。「「*」」がなければ、コマンドと引数が完全に一致する必要があります。

5.17. 拒否されたパケットに対するロギングの設定

firewalld で LogDenied オプションを使用して、拒否したパケットに簡易ロギングメカニズムを追加できます。対象となるのは、拒否または破棄されるパケットになります。ログ設定を変更するには、/etc/firewalld/firewalld.conf ファイルを変更するか、コマンドラインまたは GUI 設定ツールを使用します。

LogDenied を有効にすると、デフォルトルールの INPUT チェイン、FORWARD チェイン、および OUTPUT チェインの reject ルールおよび drop ルールと、ゾーンの最後の reject ルールおよび drop ルールの直前に、ロギングルールが追加されます。ここに設定できる値は、all、unicast、broadcast、multicast、および off です。デフォルト設定は off です。unicast、broadcast、および multicast の設定では、リンク層のパケットタイプを一致させるのに pkttype 一致を使用します。all を使用すると、すべてのパケットがログに記録されます。

firewall-cmd で実際の LogDenied 設定を一覧表示するには、root で次のコマンドを使用します。

~]# firewall-cmd --get-log-denied
off

LogDenied 設定を変更するには、root で次のコマンドを実行します。

~]# firewall-cmd --set-log-denied=all
success

firewalld の GUI 設定ツールを使用して LogDenied 設定を変更する場合は、firewall-config を起動して Options メニューをクリックし、Change Log Denied を選択します。LogDenied ウィンドウが表示されます。メニューから新しい LogDenied 設定を選択し、OK をクリックします。

5.18. 関連情報

以下の資料は、firewalld の関連情報を提供します。

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

man ページの firewalld(1) - firewalld のコマンドオプションが説明されています。
man ページの firewalld.conf(5) - firewalld を設定する情報が含まれます。
man ページの firewall-cmd(1) - firewalld コマンドラインクライアントのコマンドオプションが説明されています。
man ページの firewall-config(1) - firewall-config ツールのデフォルト設定が説明されています。
man ページの firewall-offline-cmd(1) - firewalld オフラインコマンドラインクライアントのコマンドオプションが説明されています。
man ページの firewalld.icmptype(5) - ICMP フィルタリングの XML 設定ファイルが説明されています。
man ページの firewalld.ipset(5) - firewalld IP セットの XML 設定ファイルが説明されています。
man ページの firewalld.service(5) - firewalld service 用の XML 設定ファイルが説明されています。
man ページの firewalld.zone(5) - firewalld ゾーン設定の XML 設定ファイルが説明されています。
man ページの firewalld.direct(5) - firewalld ダイレクトインターフェースの設定ファイルが説明されています。
man ページの firewalld.lockdown-whitelist(5) - firewalld ロックダウンホワイトリストの設定ファイルが説明されています。
man ページの firewalld.richlanguage(5) - firewalld リッチ言語のルール構文が説明されています。
man ページの firewalld.zones(5) - ゾーンの全般的な説明と設定方法が説明されています。
man ページの firewalld.dbus(5) - firewalld の D-Bus インターフェースが説明されています。

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

http://www.firewalld.org/ - firewalld ホームページ

第6章 nftables の使用

nftables フレームワークは、パケットの分類機能を提供し、iptables ツール、ip6tables ツール、arptables ツール、ebtables ツール、および ipset ツールの後継となります。利便性、機能、パフォーマンスにおいて、以前のパケットフィルタリングツールに多くの改良が追加されました。以下に例を示します。

線形処理の代わりに組み込みルックアップテーブルを使用
IPv4 プロトコルおよび IPv6 プロトコルに対する 1 つのフレームワーク
完全ルールセットのフェッチ、更新、および保存を行わず、すべてアトミックに適用されるルール
ルールセットにおけるデバッグおよびトレースへの対応 (nftrace) およびトレースイベントの監視 (nft ツール)
より統一されたコンパクトな構文、プロトコル固有の拡張なし
サードパーティーのアプリケーション用 Netlink API

iptables と同様、nftables は、チェーンを保存するテーブルを使用します。このチェーンには、アクションを実行する個々のルールが含まれます。nft ツールは、以前のパケットフィルタリングフレームワークのツールをすべて置き換えます。libnftnl ライブラリーは、libmnl ライブラリーの Netlink API の nftables で、低レベルの対話のために使用できます。

ルールセット変更が適用されていることを表示するには、nft list ruleset コマンドを使用します。これらのツールは、テーブル、チェーン、ルール、セットなどのオブジェクトを nftables ルールセットに追加するため、nft flush ruleset コマンドなどの nftables ルールセット操作は、先に別の従来のコマンドを使用してインストールしたルールセットに影響を及ぼす可能性があることに注意してください。

firewalld または nftables を使用する場合

firewalld: 簡単な firewall のユースケースには、firewalld ユーティリティーを使用します。このユーティリティーは、使いやすく、このようなシナリオの一般的な使用例に対応しています。
nftables: nftables ユーティリティーを使用して、ネットワーク全体など、複雑なパフォーマンスに関する重要なファイアウォールを設定します。

重要

異なるファイアウォールサービスが相互に影響することを回避するには、RHEL ホストでそのうちの 1 つだけを実行し、他のサービスを無効にします。

6.1. nftables スクリプトの作成および実行

nftables フレームワークは、シェルスクリプトを使用して firewall ルールを維持するための主な利点を提供するネイティブのスクリプト環境を提供します。スクリプトの実行はアトミックです。つまり、システムがスクリプト全体を適用するか、エラーが発生した場合には実行を阻止することを意味します。これにより、ファイアウォールは常に一貫した状態になります。

さらに、管理者は、nftables スクリプト環境で以下を行うことができます。

コメントの追加
変数の定義
他のルールセットファイルの組み込み

本セクションでは、この機能を使用する方法と、nftables スクリプトの作成方法と実行方法を説明します。

nftables パッケージをインストールすると、Red Hat Enterprise Linux が自動的に *.nft スクリプトを /etc/nftables/ ディレクトリーに作成します。このスクリプトには、さまざまな目的でテーブルと空のチェーンを作成するコマンドが含まれます。

6.1.1. 対応している nftables スクリプトの形式

nftables スクリプト環境は、次の形式でスクリプトに対応します。

nft list ruleset コマンドが、ルールセットを表示するのと同じ形式でスクリプトを作成できます。

#!/usr/sbin/nft -f

# Flush the rule set
flush ruleset

table inet example_table {
  chain example_chain {
    # Chain for incoming packets that drops all packets that
    # are not explicitly allowed by any rule in this chain
    type filter hook input priority 0; policy drop;

    # Accept connections to port 22 (ssh)
    tcp dport ssh accept
  }
}

nft コマンドと同じ構文を使用できます。

#!/usr/sbin/nft -f

# Flush the rule set
flush ruleset

# Create a table
add table inet example_table

# Create a chain for incoming packets that drops all packets
# that are not explicitly allowed by any rule in this chain
add chain inet example_table example_chain { type filter hook input priority 0 ; policy drop ; }

# Add a rule that accepts connections to port 22 (ssh)
add rule inet example_table example_chain tcp dport ssh accept

6.1.2. nftables スクリプトの実行

nftables スクリプトを実行するには、nft ユーティリティーに渡すか、スクリプトを直接実行します。

前提条件

このセクションの手順では、nftables スクリプトを /etc/nftables/example_firewall.nft ファイルに保存していることを前提としています。

手順6.1 nftユーティリティによるnftablesスクリプトの実行

nftables スクリプトを nft ユーティリティーに渡して実行するには、次のコマンドを実行します。
```
# nft -f /etc/nftables/example_firewall.nft
```

手順6.2 nftablesスクリプトを直接実行する。

以下の手順は、一度だけ必要です。
1. スクリプトが以下のシバンシーケンスで始まることを確認します。
```
#!/usr/sbin/nft -f
```
  重要
  -f パラメータを省略すると、nftユーティリティはスクリプトを読み込まず、次のように表示します。Error: syntax error, unexpected newline, expecting string.
2. 必要に応じて、スクリプトの所有者を root に設定します。
```
# chown root /etc/nftables/example_firewall.nft
```
3. 所有者のスクリプトを実行ファイルに変更します。
```
# chmod u+x /etc/nftables/example_firewall.nft
```
スクリプトを実行します。
```
# /etc/nftables/example_firewall.nft
```
出力が表示されない場合は、システムがスクリプトを正常に実行します。

重要

nft はスクリプトを正常に実行しますが、ルールの配置やパラメーター不足、またはスクリプト内のその他の問題により、ファイアウォールが期待通りの動作を起こさない可能性があります。

6.1.3. nftables スクリプトでコメントの使用

nftables スクリプト環境は、# 文字の右側にあるすべてをコメントとして解釈します。

例6.1 nftables スクリプトのコメント

コメントは、コマンドの横だけでなく、行の先頭からも開始できます。

...
# Flush the rule set
flush ruleset

add table inet example_table  # Create a table
...

6.1.4. nftables スクリプトで変数の使用

nftables スクリプトで変数を定義するには、define キーワードを使用します。シングル値および匿名セットを変数に保存できます。より複雑なシナリオの場合は、名前付きセットまたは決定マップを使用します。

値を 1 つ持つ変数

以下の例では、INET_DEV という名前の変数にenp1s0 という値を定義しています。

define INET_DEV = enp1s0

スクリプトで変数を使用するには、$ 記号と、それに続く変数名を指定します。

...
add rule inet example_table example_chain iifname $INET_DEV tcp dport ssh accept
...

匿名セットを含む変数

以下の例では、匿名セットを含む変数を定義します。

define DNS_SERVERS = { 192.0.2.1, 192.0.2.2 }

スクリプトで変数を使用するには、$ 記号と、それに続く変数名を指定します。

add rule inet example_table example_chain ip daddr $DNS_SERVERS accept

注記

中括弧は、変数がセットを表していることを示すため、ルールで使用する場合は、特別なセマンティクスを持つことに注意してください。

6.1.5. nftables スクリプトへのファイルの追加

nftables スクリプト環境を使用すると、管理者は include ステートメントを使用して他のスクリプトを追加できます。

絶対パスまたは相対パスのないファイル名のみを指定すると、nftables には、デフォルトの検索パスのファイルが含まれます。これは、Red Hat Enterprise Linux では /etc に設定されています。

例6.2 デフォルト検索ディレクトリーからのファイルを含む

デフォルトの検索ディレクトリーからファイルを指定するには、次のコマンドを実行します。

include "example.nft"

例6.3 ディレクトリーの *.nft ファイルをすべて含む

*.nft で終わるすべてのファイルを /etc/nftables/rulesets/ ディレクトリーに保存するには、次のコマンドを実行します。

include "/etc/nftables/rulesets/*.nft"

include ステートメントは、ドットで始まるファイルに一致しないことに注意してください。

6.1.6. システムの起動時に nftables ルールの自動読み込み

systemd サービス nftables は、/etc/sysconfig/nftables.conf ファイルに含まれるファイアウォールスクリプトを読み込みます。本セクションでは、システムの起動時にファイアウォールルールを読み込む方法を説明します。

前提条件

nftables スクリプトは、/etc/nftables/ ディレクトリーに保存されます。

手順6.3 システムの起動時に nftables ルールの自動読み込み

/etc/sysconfig/nftables.conf ファイルを編集します。
- nftables パッケージをインストールしたときに /etc/nftables/ に作成された *.nft スクリプトを拡張する場合は、そのスクリプトの include ステートメントのコメントを解除します。
- スクリプトを新規に作成する場合は、そのスクリプトを含む include ステートメントを追加します。たとえば、nftables サービスの起動時に /etc/nftables/example.nft スクリプトを読み込むには、以下を追加します。
```
include "/etc/nftables/example.nft"
```
必要に応じて、nftables サービスを開始して、システムを再起動せずにファイアウォールルールを読み込みます。
```
# systemctl start nftables
```
nftables サービスを有効にします。
```
# systemctl enable nftables
```

6.2. nftables テーブル、チェーン、およびルールの作成および管理

ここでは、nftablesルールセットの表示方法と管理方法について説明します。

6.2.1. nftables ルールセットの表示

nftablesのルールセットには、テーブル、チェーン、ルールが含まれています。本セクションでは、このルールセットを表示する方法を説明します。

ルールセットを表示するには、以下のコマンドを実行します。

# nft list ruleset
table inet example_table {
  chain example_chain {
    type filter hook input priority filter; policy accept;
    tcp dport http accept
    tcp dport ssh accept
  }
}

注記

デフォルトで、nftables は事前作成のテーブルではありません。したがって、テーブルがないホストに設定したルールを表示すると、nft list ruleset コマンドが出力を表示しません。

6.2.2. nftables テーブルの作成

nftables の表は、チェーン、ルール、セットなどのオブジェクトを含む名前空間です。本セクションでは、テーブルの作成方法を説明します。

各テーブルには、アドレスファミリーが定義されている必要があります。テーブルのアドレスファミリーは、テーブルプロセスのアドレスタイプを定義します。テーブルを作成する際に、以下のいずれかのアドレスファミリーを設定できます。

ip - IPv4 パケットのみと一致します。アドレスファミリーを指定しないと、これがデフォルトになります。
ip6 - IPv6 パケットのみと一致します。
inet - IPv4 パケットと IPv6 パケットの両方と一致します。
arp- IPv4 アドレス解決プロトコル (ARP) パケットと一致します。
bridge - ブリッジデバイスを通過するパケットと一致します。
netdev - ingress からのパケットに一致します。

手順6.4 nftables テーブルの作成

nft add table コマンドを使用してテーブルを新規作成します。たとえば、IPv4 パケットおよび IPv6 パケットを処理する example_table という名前のテーブルを作成するには、次のコマンドを実行します。
```
# nft add table inet example_table
```
必要に応じて、ルールセットのテーブルを一覧表示します。
```
# nft list tables
table inet example_table
```

6.2.3. nftables チェーンの作成

チェーンは、ルールのコンテナーです。次の 2 つのルールタイプが存在します。

ベースチェーン - ネットワークスタックからのパケットのエントリーポイントとしてベースチェーンを使用できます。
通常のチェーン - ジャンプ ターゲットとして通常のチェーンを使用し、ルールをより適切に整理できます。

この手順では、既存のテーブルにベースチェーンを追加する方法を説明します。

前提条件

新しいチェーンを追加するテーブルが存在する。

手順6.5 nftables チェーンの作成

nft add chain コマンドを使用してチェーンを新規作成します。たとえば、example_table に、example_chain という名前のチェーンを作成するには、次のコマンドを実行します。
```
# nft add chain inet example_table example_chain '{ type filter hook input priority 0 ; policy accept ; }'
```
重要
シェルで、セミコロンがコマンドの最後として解釈されないようにするには、セミコロンをバックスラッシュでエスケープする必要があります。さらに、シェルの中には中括弧も解釈するものがあるので、中括弧とその中のものをティック（'）で囲んでください。
このチェーンは、着信パケットをフィルタリングします。priority パラメーターは、nftables プロセスが同じフック値を持つチェーンを処理する順序を指定します。優先度の値が低いほど優先されます。policy パラメーターは、このチェーン内のルールのデフォルトアクションを設定します。サーバーにリモートでログインし、デフォルトのポリシーを drop に設定すると、他のルールでリモートアクセスが許可されていなければ、すぐに切断されることに注意してください。

必要に応じて、すべてのチェーンを表示します。

# nft list chains
table inet example_table {
  chain example_chain {
    type filter hook input priority filter; policy accept;
  }
}

6.2.4. nftables チェーンの最後に対するルールの追加

本セクションでは、既存の nftables チェーンの最後にルールを追加する方法を説明します。

前提条件

ルールを追加するチェーンが存在する。

手順6.6 nftables チェーンの最後に対するルールの追加

新規ルールを追加するには、nft add rule コマンドを使用します。たとえば、example_table の example_chain に、ポート 22 の TCP トラフィックを許可するルールを追加するには、次のコマンドを実行します。
```
# nft add rule inet example_table example_chain tcp dport 22 accept
```
代わりに、ポート番号の代わりにサービスの名前を指定することもできます。この例では、ポート番号 22 の代わりに ssh を使用できます。サービス名は、/etc/services ファイルのエントリーに基づいてポート番号に解決されることに注意してください。

必要に応じて、example_table ですべてのチェーンとそのルールを表示します。

# nft list table inet example_table
table inet example_table {
  chain example_chain {
    type filter hook input priority filter; policy accept;
    ...
    tcp dport ssh accept
  }
}

6.2.5. nftables チェーンの先頭へのルールの挿入

本セクションでは、既存の nftables チェーンの先頭にルールを追加する方法を説明します。

前提条件

ルールを追加するチェーンが存在する。

手順6.7 nftables チェーンの先頭へのルールの挿入

新しいルールを追加するには、nft insert rule コマンドを使用します。たとえば、ポート 22 で TCP トラフィックを許可するルールを example_table の example_chain に追加するには、次のコマンドを実行します。
```
# nft insert rule inet example_table example_chain tcp dport 22 accept
```
代わりに、ポート番号の代わりにサービスの名前を指定することもできます。この例では、ポート番号 22 の代わりに ssh を使用できます。サービス名は、/etc/services ファイルのエントリーに基づいてポート番号に解決されることに注意してください。

必要に応じて、example_table ですべてのチェーンとそのルールを表示します。

# nft list table inet example_table
table inet example_table {
  chain example_chain {
    type filter hook input priority filter; policy accept;
    tcp dport ssh accept
    ...
  }
}

6.2.6. nftables チェーンの特定の位置へのルールの挿入

本セクションでは、nftables チェーンで、既存のルールの前後にルールを追加する方法を説明します。これにより、正しい場所に新しいルールを配置することができます。

前提条件

ルールを追加するチェーンが存在する。

手順6.8 nftables チェーンの特定の位置へのルールの挿入

nft -a list ruleset コマンドを使用して、ハンドルなど、example_table 内のすべてのチェーンとそのルールを表示します。
```
# nft -a list table inet example_table
table inet example_table { # handle 1
  chain example_chain { # handle 1
    type filter hook input priority filter; policy accept;
    tcp dport 22 accept # handle 2
    tcp dport 443 accept # handle 3
    tcp dport 389 accept # handle 4
  }
}
```
-a を使用すると、ハンドルが表示されます。次の手順で新しいルールを配置するときに、この情報が必要です。
example_table の example_chain チェーンに新しいルールを挿入します。
- ハンドル 3 の前に、ポート 636 で TCP トラフィックを許可するルールを挿入するには、次のコマンドを実行します。
```
# nft insert rule inet example_table example_chain position 3 tcp dport 636 accept
```
- ハンドル 3 の後ろに、ポート 80 で TCP トラフィックを許可するルールを追加するには、次のコマンドを実行します。
```
# nft add rule inet example_table example_chain position 3 tcp dport 80 accept
```

必要に応じて、example_table ですべてのチェーンとそのルールを表示します。

# nft -a list table inet example_table
table inet example_table { # handle 1
  chain example_chain { # handle 1
    type filter hook input priority filter; policy accept;
    tcp dport 22 accept # handle 2
    tcp dport 636 accept # handle 5
    tcp dport 443 accept # handle 3
    tcp dport 80 accept # handle 6
    tcp dport 389 accept # handle 4
  }
}

6.3. nftables を使用した NAT の設定

nftables を使用すると、以下のネットワークアドレス変換 (NAT) タイプを設定できます。

マスカレーディング
ソース NAT (SNAT)
宛先 NAT (DNAT)
リダイレクト

6.3.1. 異なる NAT タイプ: マスカレード、ソース NAT、宛先 NAT、リダイレクト

以下は、さまざまなネットワークアドレス変換 (NAT) タイプになります。

マスカレードおよびソースの NAT (SNAT)

この NAT タイプのいずれかを使用して、パケットのソース IP アドレスを変更します。たとえば、インターネットサービスプロバイダーは、プライベート IP 範囲 (10.0.0.0/8 など) をルーティングしません。ネットワークでプライベート IP 範囲を使用し、ユーザーがインターネット上のサーバーにアクセスできるようにする必要がある場合は、この範囲のパケットのソース IP アドレスをパブリック IP アドレスにマップします。

マスカレードおよび SNAT の両方は非常に似ています。相違点は次のとおりです。

マスカレードは、出力インターフェースの IP アドレスを自動的に使用します。したがって、出力インターフェースが動的 IP アドレスを使用する場合は、マスカレードを使用します。
SNAT は、パケットのソース IP アドレスを指定された IP に設定し、出力インターフェースの IP アドレスを動的に検索しません。そのため、SNAT の方がマスカレードよりも高速です。出力インターフェースが固定 IP アドレスを使用する場合は、SNAT を使用します。

宛先 NAT (DNAT)

この NAT タイプを使用して、着信トラフィックを別のホストにルーティングします。たとえば、Web サーバーが予約済み IP 範囲の IP アドレスを使用しているため、インターネットから直接アクセスできない場合は、ルーターに DNAT ルールを設定し、着信トラフィックをこのサーバーにリダイレクトできます。

リダイレクト

このタイプは、チェーンフックに応じてパケットをローカルマシンにリダイレクトする DNAT の特殊なケースです。たとえば、サービスが標準ポートとは異なるポートで実行する場合は、標準ポートからこの特定のポートに着信トラフィックをリダイレクトすることができます。

6.3.2. nftables を使用したマスカレードの設定

マスカレードを使用すると、ルーターは、インターフェースを介して送信されるパケットのソース IP を、インターフェースの IP アドレスに動的に変更できます。これは、インターフェースに新しい IP が割り当てられている場合に、nftables はソース IP の置き換え時に新しい IP を自動的に使用することを意味します。

次の手順では、ens3 インターフェイスを介して、ホストから ens3 の IP セットに送信されるパケットのソース IP を置き換える方法を説明します。

手順6.9 nftables を使用したマスカレードの設定

テーブルを作成します。
```
# nft add table nat
```
テーブルに、prerouting チェーンおよび postrouting チェーンを追加します。
```
# nft -- add chain nat prerouting { type nat hook prerouting priority -100 \; }
# nft add chain nat postrouting { type nat hook postrouting priority 100 \; }
```
重要
prerouting チェーンにルールを追加しなくても、nftables フレームワークでは、着信パケット返信に一致するようにこのチェーンが必要になります。
nft コマンドに -- オプションを渡すと、シェルが優先度の負の値を nft コマンドのオプションとして解釈する必要がなくなります。
postrouting チェーンに、ens3 インターフェースの出力パケットに一致するルールを追加します。
```
# nft add rule nat postrouting oifname "ens3" masquerade
```

6.3.3. nftables を使用したソース NAT の設定

ルーターでは、ソース NAT (SNAT) を使用して、インターフェースを介して特定の IP アドレスに送信するパケットの IP を変更できます。

次の手順では、ens3 インターフェイスを介して、ルーターから 192.0.2.1 に送信されるパケットのソース IP を置き換える方法を説明します。

手順6.10 nftables を使用したソース NAT の設定

テーブルを作成します。
```
# nft add table nat
```
テーブルに、prerouting チェーンおよび postrouting チェーンを追加します。
```
# nft -- add chain nat prerouting { type nat hook prerouting priority -100 \; }
# nft add chain nat postrouting { type nat hook postrouting priority 100 \; }
```
重要
ポストルーティングチェーンにルールを追加しても、nftablesフレームワークでは、このチェーンが発信パケットのリプライにマッチする必要があります。
nft コマンドに -- オプションを渡すと、シェルが優先度の負の値を nft コマンドのオプションとして解釈する必要がなくなります。
ens3 を介した発信パケットのソース IP を 192.0.2.1 に置き換えるルールを postrouting チェーンに追加します。
```
# nft add rule nat postrouting oifname "ens3" snat to 192.0.2.1
```

6.3.4. nftables を使用した宛先 NAT の設定

宛先 NAT により、ルーター上のトラフィックをインターネットから直接アクセスできないホストにリダイレクトできます。

以下の手順では、ルーターの 80 ポートおよ�

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. 自動ログアウトの有効化

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

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

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

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

第4章ツールとサービスを使用したシステムの強化

`nullok` オプションの削除

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