Red Hat Enterprise Linux 6

セキュリティガイド

Red Hat Enterprise Linux のセキュリティに関するガイド

Logo

Martin Prpič

Red Hat Customer Content Services

Tomáš Čapek

Red Hat Customer Content Services

Stephen Wadeley

Red Hat Customer Content Services

Yoana Ruseva

Red Hat Customer Content Services

Miroslav Svoboda

Red Hat Customer Content Services

Robert Krátký

Red Hat Customer Content Services

法律上の通知

Copyright © 2014 Red Hat, Inc.
Based on the Fedora Security Guide (current version at http://docs.fedoraproject.org/en-US/Fedora/16/html/Security_Guide/index.html), written by Johnray Fuller, Eric Christensen, Adam Ligas, and other Fedora Project contributors.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
All other trademarks are the property of their respective owners.

 1801 Varsity Drive RaleighNC 27606-2072 USA Phone: +1 919 754 3700 Phone: 888 733 4281 Fax: +1 919 754 3701

概要

本書は、ユーザーおよび管理者が、ローカルまたはリモートからの侵入、悪用および悪意のある行為に対してワークステーションとサーバーを保護するプロセスと方法を習得する際の手助けとなります。
本ガイドは Red Hat Enterprise Linux にフォーカスしたものですが、概念と手法はすべての Linux システムに適用できるものです。データセンター、勤務先および個人宅での安全なコンピューター環境の構築に必要となるプランニングとツールについて詳細に説明しています。
管理上の適切な知識と警戒体制およびツールを備えることで、Linux を実行しているシステムの機能をフルに活用し、かつこれらのシステムをほとんどの一般的な侵入や悪用の手法から保護することができます。
1. セキュリティの概要
1.1. セキュリティの概要
1.1.1. コンピューターセキュリティとは
1.1.2. SELinux
1.1.3. セキュリティ制御
1.1.4. 結論
1.2. 脆弱性のアセスメント
1.2.1. 敵の視点で考える
1.2.2. アセスメントとテストの定義
1.2.3. ツールの評価
1.3. 攻撃者と脆弱性
1.3.1. ハッカーの歴史の概観
1.3.2. ネットワークセキュリティへの脅威
1.3.3. サーバーセキュリティへの脅威
1.3.4. ワークステーションおよび家庭用 PC のセキュリティに対する脅威
1.4. 一般的な不正使用と攻撃
1.5. セキュリティの更新
1.5.1. パッケージの更新
1.5.2. 署名パッケージの検証
1.5.3. 署名パッケージのインストール
1.5.4. 変更の適用
2. ネットワークのセキュリティ保護
2.1. ワークステーションのセキュリティ
2.1.1. ワークステーションのセキュリティ評価
2.1.2. BIOS およびブートローダーのセキュリティ
2.1.3. パスワードのセキュリティ
2.1.4. 組織内でのユーザーパスワード作成
2.1.5. 動きのないアカウントをロックする
2.1.6. アクセス制御のカスタマイズ
2.1.7. 時間ベースのアクセス制限
2.1.8. アカウント制限の適用
2.1.9. 管理者コントロール
2.1.10. セッションのロック
2.1.11. 利用可能なネットワーク
2.1.12. 個人用ファイアウォール
2.1.13. セキュリティ強化の通信ツール
2.2. サーバーのセキュリティ
2.2.1. TCP Wrapperおよび xinetd によるサービスのセキュア化
2.2.2. ポートマップのセキュア化
2.2.3. NIS のセキュア化
2.2.4. NFS のセキュア化
2.2.5. Apache HTTP サーバーのセキュア化
2.2.6. FTP のセキュア化
2.2.7. Postfix のセキュア化
2.2.8. Sendmail のセキュア化
2.2.9. リッスンしているポートの確認
2.2.10. ソースルーティングの無効化
2.2.11. 逆方向パス転送
2.3. シングルサインオン (SSO)
2.4. PAM (プラグ可能な認証モジュール)
2.5. Kerberos
2.6. TCP Wrapper と xinetd
2.6.1. TCP Wrapper
2.6.2. TCP Wrapper の設定ファイル
2.6.3. xinetd
2.6.4. xinetd の設定ファイル
2.6.5. その他のリソース
2.7. 仮想プライベートネットワーク (VPN)
2.7.1. VPN の機能
2.7.2. Openswan
2.7.3. Openswan を使った IPsec VPN
2.7.4. Openswan を使った VPN 設定
2.7.5. Openswan を使用したホスト間の VPN
2.7.6. Openswan を使ったサイト間の VPN
2.7.7. Openswan を使ったサイト間の単一トンネル VPN
2.7.8. Openswan を使ったサブネット押し出し
2.7.9. Openswan を使ったロードウォリアーアプリケーション
2.7.10. その他のリソース
2.8. ファイアウォール
2.8.1. Netfilter と IPTables
2.8.2. 基本的なファイアウォールの設定
2.8.3. IPTables の使用
2.8.4. 一般的な IPTables によるフィルタリング
2.8.5. FORWARD および NAT ルール
2.8.6. 悪意のあるソフトウェアと偽装された IP アドレス
2.8.7. IPTables と接続追跡 (Connection Tracking)
2.8.8. IPv6
2.8.9. IPTables
3. 暗号化
3.1. 静止しているデータ
3.1.1. ディスク全体の暗号化
3.1.2. ファイルベースの暗号化
3.1.3. LUKS のディスク暗号化
3.2. 移動中のデータ
3.2.1. 仮想プライベートネットワーク (VPN)
3.2.2. SSH (Secure Shell)
3.3. OpenSSL インテル AES-NI エンジン
3.4. 乱数ジェネレーターの使用
3.5. GNU Privacy Guard (GPG)
3.5.1. GNOME での GPG 鍵の生成
3.5.2. KDE での GPG 鍵の作成
3.5.3. コマンドラインを用いた GPG 鍵の生成
3.5.4. 公開鍵の暗号化について
3.6. stunnel の使用
3.6.1. stunnel のインストール
3.6.2. stunnel を TLS ラッパーとして設定する
3.6.3. stunnel の起動、停止、再起動
3.7. TLS 設定の強化
3.7.1. 有効にするアルゴリズムの選択
3.7.2. TLS 実装の使用
3.7.3. 特定アプリケーションの設定
3.7.4. その他の情報
4. 情報セキュリティの一般原則
5. セキュアなインストール
5.1. ディスクパーティション
5.2. LUKS パーティション暗号化の利用
6. ソフトウェアのメンテナンス
6.1. 最小限のソフトウェアインストール
6.2. セキュリティ更新の計画と設定
6.3. 自動更新の調整
6.4. 一般的なリポジトリからの署名パッケージのインストール
7. システム監査
7.1. Audit システムのアーキテクチャー
7.2. audit パッケージのインストール
7.3. audit サービスの設定
7.3.1. CAPP 環境用の auditd 設定
7.4. audit サービスの起動
7.5. Audit ルールの定義
7.5.1. auditctl ユーティリティーを使った Audit ルールの定義
7.5.2. 永続的な Audit ルールの定義と /etc/audit/audit.rules ファイルでの制御
7.6. Audit ログファイルについて
7.7. Audit ログファイルの検索
7.8. Audit レポートの作成
7.9. Audit 用の PAM 設定
7.9.1. pam_tty_audit の設定
7.10. その他のリソース
8. コンプライアンスおよび OpenSCAP を使った脆弱性のスキャン
8.1. Red Hat Enterprise Linux におけるセキュリティコンプライアンス
8.2. コンプライアンスポリシーの定義
8.2.1. XCCDF ファイル形式
8.2.2. OVAL ファイル形式
8.2.3. データストリームの形式
8.3. oscap の使用
8.3.1. oscap のインストール
8.3.2. SCAP コンテンツの表示
8.3.3. システムのスキャン
8.3.4. レポートおよびガイドの生成
8.3.5. SCAP コンテンツの検証
8.4. Red Hat Satellite での OpenSCAP の使用
8.5. 実用的な使用例
8.5.1. Red Hat 製品のセキュリティ脆弱性の監査
8.5.2. SCAP セキュリティガイドを使ったシステム設定の監査
8.6. その他のリソース
9. 米連邦政府の標準および規制
9.1. はじめに
9.2. 連邦情報処理標準 (FIPS: Federal Information Processing Standard)
9.2.1. FIPS モードの有効化
9.3. NISPOM (National Industrial Security Program Operating Manual)
9.4. PCI DSS (Payment Card Industry Data Security Standard)
9.5. セキュリティ技術導入ガイド (Security Technical Implementation Guide)
10. 参考資料
A. 暗号の標準
A.1. 同期式の暗号
A.1.1. 高度暗号化標準 (AES)
A.1.2. データ暗号化標準 (DES)
A.2. 公開鍵暗号
A.2.1. Diffie-Hellman
A.2.2. RSA
A.2.3. DSA
A.2.4. SSL/TLS
A.2.5. Cramer-Shoup 暗号システム
A.2.6. ElGamal 暗号
B. Audit システムのリファレンス
B.1. Audit イベントフィールド
B.2. Audit 記録のタイプ
C. 改訂履歴

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

ビジネスの運営や個人情報の記録において、ネットワーク化された強力なコンピューターへの依存度が高まっていることから、各種業界ではネットワークとコンピューターのセキュリティの実践に関心が向けられています。企業は、システム監査の適正な実施やソリューションが組織の運営要件を満たすようにするために、セキュリティ専門家の知識と技能を求めてきました。ほとんどの組織はますます動的になってきていることから、従業員は会社の重要な IT リソースにローカルまたはリモートでアクセスするようになっています。このため、セキュアなコンピューティング環境に対するニーズはより顕著になっています。
しかし残念なことに、多くの組織 (個々のユーザーも含む) が、機能性や生産性、便利さ、使いやすさおよび予算面の懸念事項にばかり目を向けてセキュリティを付け足しと見なし、セキュリティのプロセスが見過ごされています。さらに、セキュリティの適切な実施については、無許可の侵入が発生したにはじめて徹底されることも多くあります。多くの侵入の試みを阻止する効果的な方法は、インターネットなどの信頼できないネットワークにサイトを接続する前に、適切な措置を講じることです。

注記

本書では、/lib ディレクトリにあるファイルにも言及しています。64 ビットのシステムを使用している場合は、それらのファイルの一部は /lib64 にある可能性があります。

1.1. セキュリティの概要

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

コンピューターセキュリティは、コンピューティングと情報処理の幅広い領域で使用される一般的な用語です。日常業務や重要な情報へのアクセスにおいてコンピューターシステムとネットワークに依存する業界は、企業データを総体的資産の重要な部分であると見なしています。総保有コスト (Total Cost of Ownership: TCO) や サービスの品質 (Quality of Service: QoS) などのいくつかの用語および評価指標は日常的なビジネス用語として用いられるようになっていますが、これらの評価指標を用いて、各種の業界はプランニングおよびプロセス管理コストの一環としてデータ保全性や可用性などを算出しています。電子商取引などを行う業界では、データの可用性と信頼性がビジネスの成否を決める可能性があります。

1.1.1.1. コンピューターセキュリティの成り立ち

公開ネットワークへの依存度が高まり、個人情報、金融情報その他の機密情報の開示を防ぐために、情報セキュリティが長年にわたって進歩してきました。Mitnick[1]や Vladimir Levin[2]事件などの数多くの事例が起こる度に、あらゆる業界の企業は、情報の送信と開示などの取扱い方法の見直しを迫られてきました。さらにインターネットの普及は、データセキュリティにおける一層の努力を喚起する最も重要な進化の 1 つとなりました。
個人のコンピューターからインターネット上のリソースにアクセスする人の数は増え続けています。リサーチや情報収集から電子メールや電子商取引に至るまで、インターネットは 20 世紀の最も重要な進歩の 1 つと見なされています。
しかし、インターネットとその初期のプロトコルは、信頼ベースのシステムとして開発されました。つまり、インターネットプロトコルはそれ自体がセキュリティ保護されるものとしては設計されませんでした。TCP/IP 通信スタックには承認されたセキュリティ標準が組み込まれておらず、ネットワーク全体で潜在的に悪意のあるユーザーやプロセスに対して無防備な状態になっています。最近の開発によりインターネット通信の安全性は高まっていますが、依然として全国で注目されるような事件も起こっており、完全に安全なものはないという警告になっています。

1.1.1.2. 今日のセキュリティ

2000 年 2 月には、分散サービス妨害 (DDoS: Distributed Denial of Service) 攻撃が、インターネット上のトラフィックの最も多いサイトのいくつかに仕掛けられました。攻撃者は ping flood とも呼ばれる大型の ICMP パケットを送信してルーターを数時間使用不可能にし、yahoo.com、cnn.com、amazon.com、fbi.gov および他のいくつかのサイトを通常のユーザーから完全にアクセス不能にしました。この攻撃は、不明の攻撃者が特別な目的で作成された広く出回っているプログラムを使ってなされました。これらのプログラムは、脆弱なネットワークサーバーをスキャンし、サーバーに トロイの木馬と呼ばれるクライアントアプリケーションをインストールし、それに感染したサーバーが犠牲サイトを溢れさせ、かつそれらを利用不可能して攻撃のタイミングを設定します。使用されるルーターやプロトコルがパケットの目的や送信先にかかわらず、すべての受信データを受け取ってしまう構造になっている点に根本的な弱点があると、多くの人が非難しました。will possibly be removed
2007 年には、Wired Equivalent Privacy (WEP) 無線暗号化プロトコルの広く知られた脆弱性を悪用するデータ侵害により、世界中の金融機関から 4500 万件を超えるクレジットカード番号が盗まれました。
残念なことに、システムとネットワークのセキュリティ問題は複雑化する可能性があるため、組織の情報に対する捉え方や、使用法、処理方法、および送信方法などの複雑な要素を十分に把握しておくことが求められます。組織 (および組織を構成する人々) がビジネスを行う方法を理解することは、適切なセキュリティ計画を実施する上で非常に重要になります。

1.1.1.3. セキュリティの標準化

すべての業界の企業は、米国医師会 (AMA: American Medical Association) や米国電気電子学会 (IEEE: Institute of Electrical and Electronics Engineers) などの標準化推進団体によって作成される規制やルールに従っています。情報セキュリティにも同じことが言えます。多くのセキュリティコンサルタントやベンダーは機密性 (Confidentiality)、保全性 (Integrity)、可用性 (Availability) の頭文字をとった CIA として知られる標準セキュリティモデルを採用しています。この 3 階層モデルは、機密情報のリスク評価やセキュリティ方針の確立において一般的に採用されているモデルです。以下でこの CIA モデルについて説明します。
  • 機密性 — 機密情報は、事前に定義された個人に対してのみ利用可能とする必要があります。情報の許可されていない送信や使用は、制限する必要があります。例えば、情報に機密性があれば、権限のない個人が ID 盗難やクレジット詐欺などの悪意のある目的で顧客情報や財務情報を入手できません。
  • 保全性 — 情報は、不完全または不正確になるように改ざんすべきではありません。認証されていないユーザーは、機密情報を変更したり破壊する機能を使用できないように制限される必要があります。
  • 可用性 — 情報は、認証されたユーザーが必要な時にいつでもアクセスできる必要があります。可用性は、情報が合意された頻度とタイミングで入手できることを保証します。これは、パーセンテージで測定されることが多く、ネットワークサービスプロバイダーやその企業顧客が使用するサービスレベルアグリーメント (SLA) で正式に合意されます。

1.1.2. SELinux

Red Hat Enterprise Linux には、SELinux と呼ばれる Linux カーネルの拡張機能が含まれ、この機能は、システム内のファイル、プロセス、ユーザーおよびアプリケーションに対して詳細な制御を提供する強制アクセス制御 (MAC: Mandatory Access Control) アーキテクチャーを実装します。SELinux の詳細な議論は本書のスコープ外となりますが、SELinux の詳細と Red Hat Enterprise Linux での使用法については、 Red Hat Enterprise Linux SELinux ユーザーガイド を参照してください。SELinux によって保護されるサービスの設定と実行に関する詳細は、SELinux Managing Confined Services Guide を参照してください。SELinux についてのその他の入手可能なリソースは、10章参考資料 に記載されています。

1.1.3. セキュリティ制御

コンピューターセキュリティは多くの場合、以下の 3 つの異なるマスターカテゴリーに分類され、一般にはコントロールと呼ばれています。
  • 物理的
  • 技術的
  • 管理的
これら 3 つの大まかカテゴリーは、セキュリティの適切な実施における主な目的を定義するものです。これらのコントロールには、コントロールおよびそれらの実装方法を詳細化するサブカテゴリーがあります。

1.1.3.1. 物理的コントロール

物理的コントロールは、機密資料への認証されていないアクセスの抑止または防止のために、明確な構造でセキュリティ対策を実施することです。物理的コントロールの例は以下の通りです。
  • 有線監視カメラ
  • 動作/温度感知アラームシステム
  • 警備員
  • 写真付き身分証明書
  • 施錠されたデッドボルト付きのスチールドア
  • バイオメトリクス (指紋、声、顔、虹彩、筆跡、および本人確認を行うためのその他の自動認識方法が含まれます)

1.1.3.2. 技術的コントロール

技術的コントロールでは、物理的な構造物やネットワークにおける機密データのアクセスや使用を制御するための基盤となる技術を使用します。技術的コントロールは広い範囲に及び、以下のような技術も含まれます。
  • 暗号化
  • スマートカード
  • ネットワーク認証
  • アクセス制御リスト (ACL: Access control lists)
  • ファイル完全性監査ソフトウェア

1.1.3.3. 管理的コントロール

管理的コントロールは、セキュリティの人的要素を定義します。これらは組織内のあらゆるレベルの人員に関連するもので、次のような手段によって、誰がどのリソースや情報にアクセスするかを決定します。
  • トレーニングおよび認識の向上
  • 災害準備および復旧計画
  • 人員採用と分離の戦略
  • 人員登録とアカウンティング

1.1.4. 結論

セキュリティの起源、セキュリティが必要な理由およびセキュリティのさまざまな分野に触れたことで、Red Hat Enterprise Linux に関する適切な行動指針の決定が容易になると思われます。適切な戦略の計画と実行には、セキュリティを構成する要素や条件を知ることが重要です。これらを把握することで、プロセスを明確にでき、さらにセキュリティプロセスの細部を掘り下げる際の方向性がより明らかになります。

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

時間、リソースおよびやる気のある攻撃者は、ほとんどすべてのシステムに侵入することができます。現在利用できるすべてのセキュリティ手順と技術を駆使しても、すべてのシステムを侵入から完全に保護できる訳ではありません。ルーターはインターネットへのセキュアなゲートウェイの提供に役立ちます。ファイアウォールはネットワークの境界を保護します。仮想プライベートネットワーク (VPN) は、暗号化されたストリームにおいてデータを安全に通過させます。侵入検知システムは悪意のある活動について警告します。しかし、これらの技術が成功するかどうかは、以下を含む数多くの要因によって決まります。
  • 技術の設定、監視および保守を行うスタッフの専門知識
  • サービスとカーネルのパッチおよび更新を迅速かつ効率的に行う能力
  • ネットワーク上での警戒を常に怠らない担当者の能力
データシステムと各種技術の動的な組み合わせを考慮すると、企業リソースの確保は極めて複雑なタスクになり得ます。この複雑さゆえに、使用するすべてのシステムについての専門家リソースを見つけることは多くの場合、困難になります。高レベルの情報セキュリティの多くの分野をよく知っている人員を確保することはできても、複数分野における専門家スタッフを確保することは容易ではありません。これは主に、情報セキュリティの各専門分野では継続的な注意とフォーカスが必要とされるためです。情報セキュリティは常に変化しています。

1.2.1. 敵の視点で考える

例えば、企業ネットワークの管理者であることを想定してください。通常、企業ネットワークはオペレーティングシステム、アプリケーション、サーバー、ネットワークモニターおよび侵入検知システムなどから構成されます。これらを常に最新の状態に保たなければならないことを想像してみてください。現在のソフトウェアとネットワーク環境の複雑さを考えると、不正使用やバグが必然的に発生すると言えます。ネットワーク全体をパッチと更新によって最新の状態に維持することは、複数の異種システムを持つ大企業においては困難な作業であることが分かります。
専門知識を有し、最新の状態を維持するタスクを実施していたとしても、有害なインシデントが発生したり、システムの侵害やデータ破壊およびサービス中断の発生を避けることはできません。
セキュリティ技術を強化し、システム、ネットワークおよびデータの保護を支援するには、攻撃者の視点で弱点のチェックして、システムのセキュリティを判断する必要があります。システムとネットワークリソースに対する予防的な脆弱性アセスメントにより、事前に対処できる問題が明らかになり、攻撃者による悪用を防ぐことができます。
脆弱性アセスメントは、ネットワークとシステムのセキュリティについての内部監査です。このアセスメントの結果で、ネットワークの機密性、保全性および可用性の状態が明らかになります (「セキュリティの標準化」に詳述)。通常、脆弱性アセスメントは、対象システムとリソースに関する重要なデータを収集する調査フェーズから開始されます。この後にはシステム準備フェーズが続きます。基本的にこのフェーズでは、対象を絞り、それが持つすべての既知の脆弱性を検査します。準備フェーズの後には報告フェーズが続きます。ここでは、調査結果が高中低のカテゴリに分類され、対象のセキュリティを向上させる (または脆弱性のリスクを軽減する) 方法が検討されます。
自宅の脆弱性アセスメントを実施することを想定してみましょう。まずは自宅のドアが閉じられており、かつ施錠されているのを確認するために各ドアの点検を行うことでしょう。また、すべての窓が完全に閉じられていて掛け金が締められていることもチェックするでしょう。これと同じ概念がシステムやネットワーク、および電子データにも適用されます。悪意のあるユーザーはデータを盗み、これを破壊します。悪意のあるユーザーが使用するツールや考え方および動機に注目すると、彼らの行動にすばやく反応することが可能になります。

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

脆弱性アセスメントは、外部からの視点内部からの視点の 2 種類に分類できます。
外部からの視点で脆弱性アセスメントを実施する場合、システムに外部から攻撃を試みます。会社の外部に位置することで、攻撃者の視点を得ることができます。一般にルーティング可能な IP アドレスや DMZ にあるシステムやファイアウォールの外部インターフェースなど、攻撃者が目を付けるものに着目します。DMZ は「非武装地帯 (demilitarized zone)」を表し、企業のプライベート LAN などの信頼できる内部ネットワークと公的なインターネットなどの信頼できない外部ネットワークの間にあるコンピューターまたは小さなサブネットワークに相当します。通常、DMZ には Web (HTTP) サーバー、FTP サーバー、SMTP (e-mail) サーバーおよび DNS サーバーなど、インターネットのトラフィックにアクセスできるデバイスが含まれます。
内部からの視点で脆弱性アセスメントを実施する場合、実行者は内部関係者であり、信頼されるステータスにあることから、有利な位置に立ちます。内部からの視点は、実行者やその同僚がシステムにログオンした時点で得られるものです。プリントサーバーやファイルサーバー、データベースおよびその他のリソースを見ることができます。
これら 2 種類の脆弱性アセスメントには大きな違いがあります。会社の内部にいる場合は、外部者にはない多くの特権が与えられます。多くの組織では、侵入者を締め出すようにセキュリティが構成されています。しかし、組織内の各分野に対しては、ほとんどセキュリティ対策が取られていません (部門内ファイアウォール、ユーザーレベルのアクセス制御および内部リソースに対する認証手順など)。また、一般的にほとんどのシステムは社内にあるので、内部からの方がより多くのリソースを確認できます。いったん社外に移動すると、ステータスは信頼されない状態になります。外部から利用できるシステムやリソースは、通常は非常に限られたものになります。
脆弱性アセスメントと侵入テストの違いを考えてみましょう。脆弱性テストを侵入テストの第一歩と捉えてください。アセスメントで得られる情報は、その後のテストで使用されます。アセスメントはホールや潜在的な脆弱性を検査する目的で行われるのに対し、侵入テストでは調査結果を実際に使用する試みがなされます。
ネットワークインフラストラクチャーのアセスメントは動的なプロセスです。セキュリティ (情報セキュリティと物理的なセキュリティ) は動的に実施されます。システムでアセスメントを実施することで概要が明らかになり、誤検出 (False positives) と検出漏れ (False negatives) が示される場合があります。誤検出では、実際には存在しない脆弱性をツールが検出します。検出漏れでは、実際の脆弱性が省略されます。
セキュリティ管理者の力量は、使用するツールとその管理者が有する知識で決まります。現在使用できるアセスメントツールのいずれかを選び、それらをシステムに対して実行すると、ほぼ間違いなくいくつかの誤検出が見つかります。プログラム障害かユーザーエラーかに関わらず、結果は同じです。ツールは誤検出することもあれば、さらに悪い場合は、検出漏れをすることもあります。
脆弱性アセスメントと侵入テストの違いが定義されたところで、新たなベストプラクティスの一環として侵入テストを実施する前に、アセスメントの結果を注意深く確認、検討してみましょう。

警告

実稼働システム上で脆弱性を悪用する試みを行わないでください。システムとネットワークの生産性と効率に悪影響を与える可能性があります。
脆弱性アセスメントの実施には、以下のような利点があります。
  • 情報セキュリティに事前にフォーカスできる
  • 攻撃者が発見する前に潜在的な不正使用を発見できる
  • システムを最新の状態に維持し、パッチを適用できる
  • スタッフの成長と専門知識の開発を促す
  • 経済的な損失とマイナスの評判を緩和する

1.2.2.1. 方法論の確立

脆弱性アセスメントの方法論を確立すると、脆弱性アセスメント用のツール選択に役立ちます。残念ながら、現時点では事前定義の方法論や業界で承認された方法論はありませんが、一般常識やベストプラクティスを適切なガイドとして活用することができます。
ターゲットは何か? 1 つのサーバーまたはネットワーク全体、およびネットワーク内のすべてが含まれるのか? 会社の外部にいるのか、それとも内部にいるのか? これらの質問に対する答えは、ツールの選択のみならず、ツールの使用方法決定する際にも役立ちます。
方法論の確立についての詳細は、以下の Web サイトを参照してください。

1.2.3. ツールの評価

アセスメントは、情報収集ツールを使用することから始まります。ネットワーク全体を評価する際は、最初にレイアウトを描いて実行されているホストを把握します。ホストの場所を確認したら、それぞれのホストを個別に検査します。これらのホストにフォーカスするには別のツールセットが必要になります。どのツールを使用すべきかを知っておくことは、脆弱性の発見において最も重要なステップである可能性があります。
日常生活のあらゆる状況と同様に、同じジョブを実行できる異なるツールは数多くあります。この概念は脆弱性アセスメントの実施にも当てはまります。ツールには、オペレーティングシステムやアプリケーションに固有ものや、(使用されるプロトコルに基づいて) ネットワークに固有のツールもあります。ツールにはフリーのものもあれば、そうでないものもあり、直感的で使いやすいツールもあれば、難解で適切に文書化されてはいないものの、他のツールにはない機能を持つツールもあります。
適切なツールを見つけることは困難なタスクとなる場合もあり、最終的には経験が重要になります。可能であれば、実験ラボをセットアップし、各ツールの長所と短所を発見できるようできる限り多くのツールをテストするようにします。ツールの README ファイルや man ページも確認してください。さらに、インターネットからツールについての記事やステップバイステップのガイドまたはツール固有のメーリングリストなどの詳細情報を入手してください。
以下で説明するツールは、利用可能なツールのごくわずかなサンプルです。

1.2.3.1. Nmap を使用したホストのスキャン

Nmap はネットワークのレイアウトを決定するためによく使用されるツールです。Nmap は長年にわたって利用されており、情報収集を行う際におそらく最もよく使われるツールです。各種のオプションと使用法を詳述した優れたマニュアルページが含まれています。管理者は、ネットワーク上で Nmap を使用し、ホストシステムやそれらのシステム上で開かれているポートを見つけることができます。
Nmap は、脆弱性アセスメントにおける最初の有効なステップです。ネットワーク内にあるすべてのホストのマッピングができるほか、Nmap が特定ホスト上で実行中のオペレーティングシステムを特定できるようにするオプションを渡すこともできます。Nmap はセキュアなサービスの使用と不必要なサービスの停止についての方針を定める際の優れた土台を提供します。
Nmap をインストールするには、root ユーザーとして yum install nmap コマンドを実行します。
1.2.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 にある公式ホームページを参照してください。

1.2.3.2. Nessus

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

注記

Nessus クライアントおよびサーバーソフトウェアを使用するには、サブスクリプションが必要です。本ガイドでは、このアプリケーションに関心のあるユーザー向けに参考情報として説明しています。
Nessus に関する詳細は、以下の URL にある公式 Web サイトを参照してください。

1.2.3.3. Nikto

Nikto は、共通ゲートウェイインターフェース (CGI) の優れたスクリプトスキャナーです。Nikto は、CGI の脆弱性をチェックするだけでなく、侵入検知システムを逃れるために回避的な方法でチェックを行います。Nikto には詳細の資料が同梱されており、プログラムの実行前に注意して確認してください。Nikto は、CGI スクリプトに対応する Web サーバーのセキュリティをチェックする優れたリソースになります。
Nikto の詳細については、以下の URL を参照してください。

1.2.3.4. 今後のニーズの予測

ターゲットおよびリソースに応じて、数多くのツールが利用可能です。無線ネットワーク、Novell ネットワーク、Windows システム、Linux システム用などのツールがあります。アセスメントの他の重要な要素には、物理的なセキュリティのレビューや人的スクリーニング、または音声/PBX ネットワークのアセスメントなどもあります。war walking および wardriving (無線ネットワークの脆弱性を評価するために企業の物理構造の境界線をスキャンする) などの概念は検討に値するものであり、必要に応じてアセスメントに組み込むことができます。脆弱性アセスメントの計画と実施は、考え得るあらゆる範囲で実行可能です。

1.3. 攻撃者と脆弱性

優れたセキュリティ戦略を計画して導入するために、まず強い決意と動機を持つ攻撃者がシステムを攻撃するために悪用するいくつかの問題点を理解しましょう。これらの問題を詳細に見る前に、攻撃者を特定する際に使う用語を定義する必要があります。

1.3.1. ハッカーの歴史の概観

現在のハッカーという言葉の意味をたどると、マサチューセッツ工科大学 (MIT) の技術モデル鉄道クラブが大規模で複雑な鉄道セットを設計した 1960 年代に遡ります。ハッカーは、巧妙なトリックや問題の回避方法を発見したクラブのメンバーの名前として使われていました。
これ以降、ハッカーという用語はコンピュータ通から天才プログラマーにまで幅広く使われるようになりました。多くのハッカーに見られる一般的な特徴は、コンピューターのシステムとネットワーク機能の詳細を自力で掘り下げる意欲に満ちているという点です。オープンソースソフトウェアの開発者は自身と自身の仲間をハッカーと見なすことが多くあり、ハッカーを尊敬を表す言葉として使用することがあります。
通常ハッカーは、ある種のハッカー倫理に従います。ハッカー倫理は、情報と専門知識の探求は必須のものであり、この知識を共有することがコミュニティに対するハッカーの義務であると規定します。この知識の探求において、一部のハッカーはコンピューターシステムのセキュリティコントロールの裏をかくことに非実用的な意欲を燃やす人々もいます。このため、マスコミはハッカーという用語を、悪質で悪意があるか、または犯罪の意図を持ってシステムやネットワークに不正にアクセスする人々を説明するためによく用います。この種類のコンピューターハッカーをより的確に説明する名前がクラッカーです。クラッカーは、これらの 2 つのコミュニティを区別するために 1980 年代中ごろにハッカーによって作成された造語です。

1.3.1.1. ハッカーの帽子

システムやネットワークにある脆弱性を見つけてこれを利用する人々のコミュニティは、いくつかの異なるグループに分かれています。これらのグループは、セキュリティ調査の際に「着用する」帽子の色によって表され、その色はそれぞれの意図を示します。
ホワイトハットハッカーは、パフォーマンスの検査や侵入に対する脆弱性を判別するためにネットワークやシステムをテストする人々です。通常ホワイトハットハッカーは、自らのシステムか、またはセキュリティ監査のためにホワイトハットハッカーを雇用した顧客のシステムに対し、クラッキング行為を行ないます。この顧客には、学術研究員やセキュリティコンサルタントの専門家などが含まれます。
ブラックハットハッカーはクラッカーの同義語です。通常、クラッカーはプログラミングやシステム侵入に関する非実用的な側面にはあまり重きを置きません。多くの場合、クラッカーは利用可能なクラッキング用のプログラムに依存し、システムの既知の脆弱性を悪用して、個人的な利益のために機密情報を暴露したり、標的となるシステムやネットワークに損害を与えます。
他方、グレーハットハッカーは、たいていの場合はホワイトハットハッカーと同様のスキルと意図を持ちますが、自らの知識を高潔な目的以外で利用することがあります。グレーハットハッカーとは、自らの目的を遂行する際にはブラックハットを着用するホワイトハットハッカーであると考えることができるでしょう。
グレーハットハッカーのハッカー倫理は通常のものとは異なるもので、盗難や機密漏洩などの違反を犯さない限り、ハッカーはシステムに侵入してもよいとするのが通例です。しかしながらこれについては、システムに侵入する行為自体が非倫理的であるという反論があります。
侵入者の意図を何であれ、クラッカーが悪用しかねない弱点について知っておくことが重要です。本章の残りの部分では、これらの問題点に焦点を当てていきます。

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

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

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

間違った構成のネットワークは、未承認ユーザーの主要のエントリーポイントになります。信頼ベースのオープンなローカルネットワークを非常に安全でないインターネットに対して無防備な状態にしておくことは、犯罪の多発地区でドアを半開きにしておくようなものです。すぐに何かが起きることはないかもしれませんが、いずれ誰かがこの機会を悪用するでしょう。
1.3.2.1.1. ブロードキャストネットワーク
システム管理者は、セキュリティ計画においてネットワーキングハードウェアの重要性を見落としがちです。ハブやルーターなどの単純なハードウェアは、ブロードキャストやノンスイッチの仕組みに基づいています。つまり、あるノードがネットワークを介して受信ノードにデータを送信するときは常に、受信ノードが受信してデータを処理するまで、ハブやルーターはデータパケットのブロードキャストを送信します。この方式は、外部侵入者やローカルホスト上の認証されていないユーザーが仕掛けるアドレス解決プロトコル (ARP) およびメディアアクセスコントロール (MAC) アドレスの偽装に対して最も脆弱です。
1.3.2.1.2. 集中化サーバー
ネットワーキングのもうひとつの落とし穴は、集中化されたコンピューティングの使用にあります。多くの企業では、一般的なコスト削減手段として、すべてのサービスを 1 台の強力なマシンに統合しています。集中化は、複数サーバーの設定よりも管理がより簡単な上、コストを大幅に削減できるので便利な手段と言えます。しかし、集中化されたサーバーはネットワークにおける単一障害点となるため、集中化サーバーが攻撃されると、ネットワークは完全に使えなくなるか、またはデータの不正操作や盗難が起きやすくなる可能性があります。こうした状況では、1 つの集中化サーバーが侵入口となり、ネットワーク全体へのアクセスを許してしまうことになります。

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

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

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

Red Hat Enterprise Linux 7 を完全にインストールすると、1000 以上のアプリケーションとライブラリのパッケージが含まれます。しかし、ほとんどのサーバー管理者は、ディストリビューションに含まれるすべての個別パッケージをインストールすることはありません。その代わりに、複数のサーバーアプリケーションを含むパッケージのベースインストールを行います。
システム管理者は、どのアプリケーションがインストールに含まれるかを気にせずにオペレーティングシステムをインストールしてしまうことがよくあります。必要のないパッケージがインストールされ、デフォルト設定でオンにしてしまうと、これが問題になる場合があります。これにより、管理者の気づかないところで、Telnet や DHCP、または DNS などの不要なサービスがサーバーやワークステーションで実行され、その結果、サーバーへの不要なトラフィックが発生したり、攻撃者にシステムへのパスが提供される可能性があります。ポートを閉じる方法や未使用のサービスを無効にする方法についての詳細は、「サーバーのセキュリティ」を参照してください。

1.3.3.2. 管理における不注意

システムにパッチを当てようとしない管理者は、サーバーセキュリティへの最大の脅威の 1 つとなります。SysAdmin, Audit, Network, Security Institute (SANS) によると、コンピューターのセキュリティ脆弱性の主な原因は、「訓練を受けていない人にセキュリティの保守を任せ、保守を行うために必要な訓練や時間を与えないこと」にあります。これは、自信過剰な管理者やモチベーションの高い管理者だけではなく、経験の少ない管理者にも起こり得ます。
サーバーやワークステーションにパッチを当てない管理者のほかに、システムのカーネルやネットワーク通信からのログメッセージを見落とす管理者もいます。またよく起こるエラーとして、サービスのデフォルトパスワードやキーを変更しないまま放置しておくことがあります。例えば、データベースにはデフォルトの管理パスワードが設定されているものがありますが、この設定では、システム管理者がインストール後すぐにデフォルトパスワードを変更することをデータベース開発者が想定しています。しかし、データベース管理者がこのパスワードの変更を忘れると、経験の浅い攻撃者でさえ、周知のデフォルトパスワードを使ってデータベースの管理者権限を得ることができます。これらは、管理者の不注意がサーバーを危険にさらすことになる数例に過ぎません。

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

どんなに注意深い組織であっても、選択するネットワークサービスが本質的に安全でない限り、攻撃を受けやすくなります。例えば、多くのサービスは、信頼できるネットワークで使用されるとの仮定に基づいて開発されますが、これらのサービスが (本質的に信頼できない) インターネット上で利用可能になる時点で、この仮定は成立しなくなります。
安全ではないネットワークサービスのカテゴリの 1 つに、暗号化されていないユーザー名とパスワードを認証時に要求するサービスがあります。Telnet や FTP がこの種のサービスです。パケット盗聴ソフトウェアがリモートユーザーとこのようなサービス間のトラフィックをモニタリングしていれば、ユーザー名とパスワードは簡単に傍受される可能性があります。
また、基本的にこのようなサービスはセキュリティ業界で中間者攻撃と呼ばれる攻撃の餌食になりやすくなります。この種の攻撃では、攻撃者は、ネットワーク上のクラッキングされたネームサーバーをだまし、目標のサービスではなくクラッカーのマシンにポイントすることで、ネットワークトラフィックをリダイレクトします。誰かがサーバーへリモートセッションを開くと、攻撃者のマシンがリモートサービスと用心していなユーザー間に静かに存在する目に見えないパイプとして機能し、この間を流れる情報を取り込みます。このようにして、攻撃者はサーバーやユーザーに気づかれることなく、管理パスワードや生データを収集できるようになってしまいます。
安全ではないサービスの別のカテゴリは、NFS または NIS などのネットワークファイルシステムと情報サービスです。これらは、LAN 利用を目的として開発されましたが、(リモートユーザー用の) WAN も対象に含まれるように拡張されます。NFS では、攻撃者による NFS 共有のマウントやそこに格納されているものへのアクセスを防ぐ認証やセキュリティの仕組みがデフォルトで設定されていません。NIS も、プレーンテキスト ASCII または DBM (ASCII から派生) データベースの中に、パスワードやファイルパーミッションなどの、ネットワーク上のすべてのコンピューターに知らせる必要のある重要な情報を保持しています。攻撃者がこのデータベースのアクセス権を取得すると、管理者のアカウントを含む、ネットワーク上のすべてのユーザーアカウントにアクセスできるようになってしまいます。
Red Hat Enterprise Linux は、上記のサービスをデフォルト時にすべて無効にしてリリースされます。しかし、管理者はこれらのサービスの使用を迫られる場合も多くあるため、注意して設定することが重要になります。安全な方法でサービスをセットアップする詳細情報は、「サーバーのセキュリティ」を参照してください。

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

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

1.3.4.1. 不適切なパスワード

不適切なパスワードの設定は、システムにアクセスする最も簡単な方法を攻撃者に提供します。パスワードを作成する際のよくある落とし穴を避ける方法については、「パスワードのセキュリティ」を参照してください。

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

管理者がサーバーに十分な安全対策を施し、パッチを当てている場合でも、リモートユーザーによるアクセスが安全であるわけではありません。例えば、サーバーが公開ネットワーク上で Telnet や FTP サービスを提供している場合、攻撃者はネットワークを通過するプレーンテキストのユーザー名とパスワードを取り込み、アカウント情報を使用してリモートユーザーのワークステーションにアクセスすることが可能です。
SSH などのセキュアなプロトコルを使用している場合であっても、クライアントアプリケーションを定期的に更新していないと、リモートユーザーは特定の攻撃を受けやすくなる可能性があります。例えば、v.1 SSH クライアントは、悪意のある SSH サーバーからの X 転送攻撃に対して脆弱です。クライアントがサーバーに接続すると、攻撃者はネットワーク上でクライアントによるキー入力やマウス操作をひそかに収集できます。この問題は v.2 SSH プロトコルで修正されましたが、ユーザーはどのアプリケーションにこのような脆弱性があるかを追跡し、必要に応じてアプリケーションを更新する必要があります。
「ワークステーションのセキュリティ」では、管理者とホームユーザーがコンピューターのワークステーションの脆弱性を限定するために取るべき手順をより詳細に説明しています。

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

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

表1.1 一般的な不正使用

不正使用説明注意事項
空またはデフォルトのパスワード管理パスワードを空白のままにしたり、製品ベンダーが設定したデフォルトパスワードをそのまま使用します。ルーターやファイアウォールなどのハードウェアで最もよく見られますが、Linux で実行するサービスにはデフォルトの管理者パスワードが入っているものがあります(ただし Red Hat Enterprise Linux はパスワードなしで出荷されます)。
ルーター、ファイアウォール、VPN および Network Attached Storage (NAS) アプライアンスなどのネットワークハードウェアに一般的に関連するものです。
数多くのレガシーオペレーティングシステム、とくにサービスをバンドルしたオペレーティングシステム (UNIX や Windows など) によくあります。
管理者が急いで特権ユーザーアカウントを作成したためにパスワードが空白のままになっていることがありますが、これは、このアカウントを発見した悪意のあるユーザーにとっては、絶好のエントリーポイントとなります。
デフォルトの共有鍵セキュアなサービスでは、開発や評価テスト用にデフォルトのセキュリティ鍵がパッケージ化されていることがあります。これらの鍵を変更せずにインターネット上の実稼働環境に置いた場合、同じデフォルトの鍵を持つすべてのユーザーがその共有鍵のリソースや、そこにあるすべての機密情報にアクセスできるようになります。無線アクセスポイントや事前設定済みのセキュアなサーバー機器に最も多く見られます。
IP スプーフィングリモートマシンがローカルネットワーク上でノードとして動作し、サーバーに脆弱性を見つけるとバックドアプログラムまたはトロイの木馬をインストールして、ネットワークリソース全体へのコントロールを得ようとします。
スプーフィングは、攻撃者が標的となるシステムへの接続を調整するのに TCP/IP シーケンス番号を予測しなければならないのでかなり難しいことですが、攻撃者による脆弱性への攻撃を支援するツールはいくつかあります。
標的となるシステムで実行される、ソースベース認証技術を使用するサービス (rshtelnet、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) 単独の攻撃者または攻撃者のグループは、目標のホスト(サーバー、ルーター、ワークステーションのいずれか)に認証されていないパケットを送ることにより、組織のネットワークまたはサーバーのリソースに対して攻撃を仕掛けます。これにより、正当なユーザーはリソースを使用できなくなります。
通常ソースパケットは、攻撃の本当のもとを調査するのが難しくなるよう、偽装 (または再ブロードキャスト)されています。
iptables を使用したイングレスフィルタリング (IETF rfc2267) や snort などのネットワーク侵入検知システムにおける進歩は、管理者が分散型サービス拒否攻撃を追跡し、これを防止するのに役立っています。

1.5. セキュリティの更新

セキュリティの脆弱性が発見された場合、セキュリティ上のリスクを最小限に抑えるために、影響を受けるソフトウェアを更新する必要があります。そのソフトウェアが現在サポートされている Red Hat Enterprise Linux ディストリビューション内のパッケージの一部である場合、Red Hat は脆弱性を修正する更新パッケージをできるだけ迅速にリリースするように全力を尽くします。多くの場合、セキュリティ上の特定の不正使用に関する発表にはパッチ (または問題を解決するソースコード) が伴われています。このパッチは Red Hat Enterprise Linux パッケージに適用されます。パッチはテストされ、エラータ更新としてリリースされるものです。しかし、発表にパッチが含まれていない場合には、開発者は問題の解決に向けてそのソフトウェアの保守担当者と協力します。問題が解決されると、パッケージがテストされ、エラータ更新としてリリースされます。
システムで使用しているソフトウェアのエラータ更新がリリースされている場合、システムが攻撃される可能性のある期間を最小限にするため、影響を受けるパッケージをできる限り早く更新することが強く推奨されます。

1.5.1. パッケージの更新

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

注記

Red Hat Enterprise Linux には、利用可能なシステム更新があると、目につくアラートを表示する便利なパネルアイコンが含まれます。

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

Red Hat Enterprise Linux のパッケージはすべて、Red Hat GPG 鍵を使って署名されています。GPG は GNU Privacy Guard または GnuPG の略で、配信ファイルの信頼性を保証するために使用されるフリーソフトウェアのパッケージです。例えば、秘密鍵 (シークレットキー) はパッケージをロックし、公開鍵はパッケージのロックを解除し、パッケージを検証します。RPM の検証時に、Red Hat Enterprise Linux が配信する公開鍵が秘密鍵と一致しなければ、パッケージは改ざんされている可能性があるので信頼できません。
Red Hat Enterprise Linux 6 内の RPM ユーティリティは、RPM パッケージのインストール前に、GPG 署名の検証を自動的に試行します。Red Hat GPG 鍵がインストールされていない場合は、Red Hat インストール CD-ROM または DVD などの安全で静的な場所からインストールしてください。
ディスクが /mnt/cdrom にマウントされていると仮定すると、root ユーザーとして以下のコマンドを使用して keyring (システム上の信頼できるキーのデータベース) にインポートすることができます。
~]# rpm --import /mnt/cdrom/RPM-GPG-KEY
これで Red Hat GPG 鍵が /etc/pki/rpm-gpg/ ディレクトリに置かれます。
RPM の検証用にインストールされたすべてのキーを一覧表示するには、次のコマンドを実行します。
~]# rpm -qa gpg-pubkey*
gpg-pubkey-db42a60e-37ea5438
特定のキーに関する詳細を表示するには、以下の例のように、先のコマンドの出力の前に rpm -qi コマンドを使用します。
~]# rpm -qi gpg-pubkey-db42a60e-37ea5438
Name        : gpg-pubkey                   Relocations: (not relocatable)
Version     : 2fa658e0                          Vendor: (none)
Release     : 45700c69                      Build Date: Fri 07 Oct 2011 02:04:51 PM CEST
Install Date: Fri 07 Oct 2011 02:04:51 PM CEST      Build Host: localhost
Group       : Public Keys                   Source RPM: (none)[出力は省略されています]
RPM ファイルのインストール前に、そのファイルの署名を検証してパッケージの元のソースからの改ざんされていないことを確認することは極めて重要です。ダウンロードしたパッケージすべてを一度に検証するには、以下のコマンドを実行します。
~]# rpm -K /root/updates/*.rpm
alsa-lib-1.0.22-3.el6.x86_64.rpm: rsa sha1 (md5) pgp md5 OK
alsa-utils-1.0.21-3.el6.x86_64.rpm: rsa sha1 (md5) pgp md5 OK
aspell-0.60.6-12.el6.x86_64.rpm: rsa sha1 (md5) pgp md5 OK
それぞれのパッケージについて GPG 鍵が問題なく検証されると、このコマンドは gpg OK を返します。検証に失敗した場合は、コンテンツのソースを検証するほか、Red Hat の適切な公開鍵を使用していることを確認してください。GPG 検証に失敗したパッケージは、第三者によって改ざんされている可能性があるためにインストールしないでください。
GPG 鍵を検証し、エラータレポートに関連する全パッケージをダウンロードした後に、シェルプロンプトで root としてこれらのパッケージをインストールします。
または、Yum ユーティリティを使って、署名されたパッケージを検証することもできます。Yum は、すべてのパッケージリポジトリ (つまりパッケージソース) または個別のリポジトリに対し、GPG 署名されたパッケージの GPG 署名検証を有効にして、セキュアなパッケージ管理を可能にします。署名の検証を有効にすると、Yum は該当リポジトリの適切な鍵を使って GPG 署名されていないパッケージのインストールを拒否します。つまりこれにより、システムにダウンロードし、インストールできる RPM パッケージは Red Hat のような信頼できるソースからのものであり、転送時に変更されるていないことが確信できます。
Yum を使ったパッケージのインストールまたは更新の際に GPG 署名の自動検証を有効にするには、/etc/yum.conf ファイルの [main] セクション下に以下のオプションが定義されていることを確認します。
gpgcheck=1

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

次のコマンドを root として実行すると、ほとんどのパッケージを安全にインストールすることができます (カーネルパッケージを除く)。
rpm -Uvh <package>
たとえば、/tmp/ ディレクトリー下で updates/ という新規のディレクトリー下にすべてのパッケージをインストールするには、以下を実行します。
~]# rpm -Uvh /tmp/updates/*.rpm
Preparing...                ########################################### [100%]
   1:alsa-lib               ########################################### [ 33%]
   2:alsa-utils             ########################################### [ 67%]
   3:aspell                 ########################################### [100%]
カーネルパッケージの場合は、以下のコマンドを使用します。
rpm -ivh <kernel-package>
例えば、kernel-2.6.32-220.el6.x86_64.rpm をインストールするには、シェルプロンプトに以下を入力します。
~]# rpm -ivh /tmp/updates/kernel-2.6.32-220.el6.x86_64.rpm
Preparing...                ########################################### [100%]
   1:kernel                 ########################################### [100%]
新しいカーネルを使用してマシンが安全に再起動されると、以下のコマンドを使用して古いカーネルを削除することができます。
rpm -e <old-kernel-package>
例えば、kernel-2.6.32-206.el6.x86_64 を削除するには、以下を入力します。
~]# rpm -e kernel-2.6.32-206.el6.x86_64
または、Yum を使ってパッケージをインストールするには、root として以下のコマンドを実行します。
~]# yum install kernel-2.6.32-220.el6.x86_64.rpm
Yum を使用してローカルパッケージをインストールするには、root として以下のコマンドを実行します。
~]# yum localinstall /root/updates/emacs-23.1-21.el6_2.3.x86_64.rpm

注記

古いカーネルを削除する必要はありません。デフォルトのブートローダー GRUB を使うと、複数のカーネルをインストールし、ブート時にメニューから選択することができます。

重要

セキュリティに関するエラータをインストールする前に、エラータレポートに記載されているすべての特別な指示をよく読み、指示に従ってインストールしてください。エラータ更新に基づく変更の適用についての一般的な情報は、「変更の適用」 を参照してください。

1.5.4. 変更の適用

セキュリティに関するエラータと更新をダウンロードしてインストールした後は、古いソフトウェアの使用を中止して新しいソフトウェアの使用を開始することが重要です。これを実際に行う方法は、更新済みのソフトウェアの種類によって異なります。以下では、ソフトウェアの一般的なカテゴリを示し、パッケージのアップグレード後に更新バージョンを使用する方法について説明します。

注記

一般に、システムの再起動は、ソフトウェアパッケージの最新バージョンが使用されていることを確認するための最も確実な方法です。ただし、このオプションはシステム管理者に常に必要、または利用可能というわけではありません。
アプリケーション
ユーザースペースのアプリケーションとは、システムユーザーが開始可能なすべてのプログラムのことです。一般的に、このようなアプリケーションは、ユーザー、スクリプトまたは自動化されたタスクユーティリティがそれらを起動する場合にのみ使用されるものであり、長い期間持続するものではありません。
ユーザースペースのアプリケーションが更新されると、システムにあるアプリケーションのすべてのインスタンスが停止し、更新バージョンを使用するためにプログラムが再起動されます。
カーネル
カーネルは、Red Hat Enterprise Linux オペレーティングシステムの中心的なソフトウェアコンポーネントです。カーネルはメモリー、プロセッサーおよび周辺機器へのアクセスを管理するだけでなく、すべてのタスクをスケジュールします。
カーネルは中心的な役割を担うので、カーネルの再起動にはコンピューターの停止が伴います。つまりカーネルの更新バージョンは、システムの再起動後にはじめて使用できるようになります。
共有ライブラリ
共有ライブラリは、glibc のように、多くのアプリケーションやサービスにより使用されるコードの集合です。通常、共有ライブラリを使用しているアプリケーションは、アプリケーションが初期化されるときに共有コードを読み込みます。そのため、更新されたライブラリを使用しているすべてのアプリケーションは、まず停止してから再起動する必要があります。
特定ライブラリにリンクしている実行中のアプリケーションを判別するには、以下の例のように lsof コマンドを使用します。
lsof <path>
例えば、libwrap.so ライブラリにリンクしている実行中のアプリケーションを判別するには、以下を入力します。
~]# lsof /lib64/libwrap.so*
COMMAND     PID      USER  FD   TYPE DEVICE SIZE/OFF   NODE NAME
sshd      13600 root mem    REG  253,0    43256 400501 /lib64/libwrap.so.0.7.6
sshd      13603 juan mem    REG  253,0    43256 400501 /lib64/libwrap.so.0.7.6
gnome-set 14898 juan mem    REG  253,0    43256 400501 /lib64/libwrap.so.0.7.6
metacity  14925 juan mem    REG  253,0    43256 400501 /lib64/libwrap.so.0.7.6[出力は省略されています]
このコマンドは、ホストのアクセス制御に TCP Wrapper を使用する実行中のプログラムの一覧を返します。そのため tcp_wrappers パッケージが更新される場合には、リストにあるすべてのプログラムを中止し、再起動する必要があります。
SysV サービス
SysV サービスは、ブート中に起動される永続的なサーバープログラムです。SysV サービスの例としては、 sshdvsftpd、および xinetd があります。
通常、これらのプログラムはマシンが稼働している間はメモリ内に残るので、パッケージのアップグレード後にはそれぞれの更新 SysV サービスを停止してから再起動する必要があります。これは、サービス設定ツールを使用するか、または root としてシェルプロンプトにログインし、以下の例のように /sbin/service コマンドを発行することで実行されます。
/sbin/service <service-name> restart
上記の例にある <service-name>sshd などのサービス名に置き換えます。
xinetd サービス
xinetd スーパーサービスによって管理されているサービスは、アクティブな接続があるときにのみ実行されます。xinetd に制御されるサービスの例には、Telnet、IMAP、および POP3 などがあります。
これらのサービスの新規インスタンスは、新しい要求が受信されるたびに xinetd が起動されるので、アップグレード後に発生する接続は更新ソフトウェアによって処理されます。ただし、xinetd が制御するサービスのアップグレード時にアクティブな接続がある場合、それらは古いバージョンのソフトウェアによって処理されます。
xinetd が制御する特定サービスの古いインスタンスを停止するには、そのサービスのパッケージをアップグレードしてから、現在実行中のすべてのプロセスを停止します。プロセスが実行中であるかどうかを判別するには ps または pgrep コマンドを使用し、kill または killall コマンドを使用してサービスの現在のインスタンスを停止します。
例えば、imap パッケージのセキュリティエラータがリリースされている場合、パッケージをアップグレードしてから、シェルプロンプトに root として以下のコマンドを入力します。
~]# pgrep -l imap
1439 imapd
1788 imapd
1793 imapd
このコマンドはすべてのアクティブな IMAP セッションを返します。それぞれのセッションを終了するには、root として以下のコマンドを発行します。
kill <PID>
セッションの終了に失敗した場合は、代わりに以下のコマンドを使用します。
kill -9 <PID>
上記の例では、<PID> を IMAP セッションのプロセス ID 番号 (pgrep -l コマンドの 2 番目の列) に置き換えます。
すべてのアクティブな IMAP セッションを終了するには、以下のコマンドを発行します。
~]# killall imapd


[1] http://law.jrank.org/pages/3791/Kevin-Mitnick-Case-1999.html
[2] http://www.livinginternet.com/i/ia_hackers_levin.htm

第2章 ネットワークのセキュリティ保護

2.1. ワークステーションのセキュリティ
2.1.1. ワークステーションのセキュリティ評価
2.1.2. BIOS およびブートローダーのセキュリティ
2.1.3. パスワードのセキュリティ
2.1.4. 組織内でのユーザーパスワード作成
2.1.5. 動きのないアカウントをロックする
2.1.6. アクセス制御のカスタマイズ
2.1.7. 時間ベースのアクセス制限
2.1.8. アカウント制限の適用
2.1.9. 管理者コントロール
2.1.10. セッションのロック
2.1.11. 利用可能なネットワーク
2.1.12. 個人用ファイアウォール
2.1.13. セキュリティ強化の通信ツール
2.2. サーバーのセキュリティ
2.2.1. TCP Wrapperおよび xinetd によるサービスのセキュア化
2.2.2. ポートマップのセキュア化
2.2.3. NIS のセキュア化
2.2.4. NFS のセキュア化
2.2.5. Apache HTTP サーバーのセキュア化
2.2.6. FTP のセキュア化
2.2.7. Postfix のセキュア化
2.2.8. Sendmail のセキュア化
2.2.9. リッスンしているポートの確認
2.2.10. ソースルーティングの無効化
2.2.11. 逆方向パス転送
2.3. シングルサインオン (SSO)
2.4. PAM (プラグ可能な認証モジュール)
2.5. Kerberos
2.6. TCP Wrapper と xinetd
2.6.1. TCP Wrapper
2.6.2. TCP Wrapper の設定ファイル
2.6.3. xinetd
2.6.4. xinetd の設定ファイル
2.6.5. その他のリソース
2.7. 仮想プライベートネットワーク (VPN)
2.7.1. VPN の機能
2.7.2. Openswan
2.7.3. Openswan を使った IPsec VPN
2.7.4. Openswan を使った VPN 設定
2.7.5. Openswan を使用したホスト間の VPN
2.7.6. Openswan を使ったサイト間の VPN
2.7.7. Openswan を使ったサイト間の単一トンネル VPN
2.7.8. Openswan を使ったサブネット押し出し
2.7.9. Openswan を使ったロードウォリアーアプリケーション
2.7.10. その他のリソース
2.8. ファイアウォール
2.8.1. Netfilter と IPTables
2.8.2. 基本的なファイアウォールの設定
2.8.3. IPTables の使用
2.8.4. 一般的な IPTables によるフィルタリング
2.8.5. FORWARD および NAT ルール
2.8.6. 悪意のあるソフトウェアと偽装された IP アドレス
2.8.7. IPTables と接続追跡 (Connection Tracking)
2.8.8. IPv6
2.8.9. IPTables

2.1. ワークステーションのセキュリティ

Linux 環境の安全を確保する作業はワークステーションから始めます。個人用のマシンをロックダウンするにしてもエンタープライズシステムのセキュリティ保護をするにしても、信頼できるセキュリティポリシーは個別のコンピューターが第一歩となります。コンピューターネットワークのセキュリティは、一番弱いノードのレベルで決められてしまいます。

2.1.1. ワークステーションのセキュリティ評価

Red Hat Enterprise Linux ワークステーションのセキュリティを評価する際は、以下の点を考慮してください。
  • BIOS およびブートローダーのセキュリティ — 未承認ユーザーがマシンに物理的にアクセス可能で、パスワードなしでシングルユーザーモードまたはレスキューモードによる起動が可能ですか?
  • パスワードのセキュリティ — マシンのユーザーアカウントのパスワードはどの程度安全ですか?
  • 管理者コントロール — システムにアカウントを持っているのは誰で、どの程度の管理者コントロールがありますか?
  • 利用可能なネットワークサービス — ネットワークからの要求をリッスンしているのはどのサービスで、それらは稼働しているべきですか?
  • パーソナルファイアウォール — もし使うのであれば、どのタイプのファイアウォールが必要ですか?
  • セキュリティ強化の通信ツール — ワークステーション間の通信で使用すべきツールはどれで、使用すべきでないツールはどれですか?

2.1.2. BIOS およびブートローダーのセキュリティ

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

2.1.2.1. BIOS パスワード

コンピューターの BIOS をパスワードで保護する主な理由は、以下の 2 つです[3]
  1. BIOS 設定の変更を防止する — 侵入者が BIOS にアクセスした場合、CD-ROM やフラッシュドライブから起動するように設定できます。このようにすると、侵入者がレスキューモードやシングルユーザーモードに入ることが可能になり、システム上で任意のプロセスを開始したり、機密性の高いデータをコピーできるようになってしまいます。
  2. システムの起動を防ぐ — BIOS の中には起動プロセスをパスワードで保護できるものもあります。これを有効にすると、攻撃者は BIOS がブートローダーを開始する前にパスワード入力を求められます。
BIOS パスワードの設定方法はコンピューターメーカーで異なるため、具体的な方法についてはコンピューターのマニュアルを参照してください。
BIOS パスワードを忘れた場合は、マザーボード上のジャンパーでリセットするか、CMOS バッテリーを外します。このため、可能な場合はコンピューターのケースをロックすることがよい方法です。ただし、CMOS バッテリーを外す前にコンピューターもしくはマザーボードのマニュアルを参照してください。
2.1.2.1.1. x86 以外のプラットフォームのセキュリティ
他のアーキテクチャーでは、x86 システム上の BIOS とほぼ同等の低レベルのタスクを実行するために異なるプログラムを使用します。例えば、Intel® Itanium™ コンピューターは Extensible Firmware Interface (EFI) シェルを使用します。
他のアーキテクチャー上で BIOS と同様のプログラムをパスワード保護する方法については、メーカーの指示を参照してください。

2.1.2.2. ブートローダーのパスワード

Linux ブートローダーをパスワードで保護する主要な理由は以下のとおりです。
  1. シングルユーザーモードへのアクセスを防ぐ — 攻撃者がシステムを起動してシングルユーザーモードに入れるとすると、root パスワードの入力なしで自動的に root としてログインすることになってしまいます。

    警告

    /etc/sysconfig/init ファイルで SINGLE パラメーターを編集してシングルユーザーモードへのアクセスを保護する方法は推奨されません。攻撃者は、GRUB のカーネルコマンドライン上で (init= を使って) カスタム初期コマンドを特定することでパスワードを迂回できます。「GRUB のパスワード保護」 にあるように、GRUB ブートローダーをパスワードで保護することが推奨されます。
  2. GRUB コンソールへのアクセスを防ぐ — マシンがブートローダーに GRUB を使用している場合、攻撃者は GRUB エディターインターフェイスを使って設定を変更したり、cat コマンドを使用して情報収集が可能になります。
  3. 安全でないオペレーティングシステムへのアクセスを防ぐ — デュアルブートシステムの場合、攻撃者はアクセス制御やファイルパーミッションを無視する (例えば、DOS などの) OS を起動時に選択できます。
Red Hat Enterprise Linux 6 は、出荷時に x86 プラットフォーム上で GRUB ブートローダーが組み込まれています。GRUB の詳細については、Red Hat Enterprise Linux インストールガイド を参照してください。
2.1.2.2.1. GRUB のパスワード保護
「ブートローダーのパスワード」 にある初めの 2 つの問題は、GRUB の設定ファイルに パスワード指示文を追加することで対処できます。これを行うには、まず強固なパスワードを選択し、シェルを開いて root でログインした後、以下のコマンドを実行します。
/sbin/grub-md5-crypt
パスワードの入力を求められたら、GRUB パスワードを入力して Enter を押します。すると、パスワードの MD5 ハッシュが返されます。
次に GRUB 設定ファイル /boot/grub/grub.conf を編集します。これを開いて、ドキュメンテーションの主要セクションにある timeout 行の下に以下の行を追加します。
password --md5 <password-hash>
<password-hash> の部分を /sbin/grub-md5-crypt が返した値に置き換えます [4]
次回のシステム起動時には、p を押して GRUB パスワードを押さないとエディターやコマンドインターフェイスにアクセスできないように、GRUB メニューが保護します。
残念ながらこの方法では、攻撃者がデュアルブートシステムで起動して安全でないオペレーティングシステムに侵入することは防げません。この問題に関しては、/boot/grub/grub.conf ファイルの別の部分を編集する必要があります。
安全にしたいオペレーティングシステムの title 行のすぐ下に lock 指示文の行を追加します。
DOS システムでは、最初の部分は以下のようになります。
title DOS
	lock

警告

この方法が正常に機能するには、password 行は /boot/grub/grub.conf ファイルの主要セクションにある必要があります。それ以外の場所では、攻撃者は GRUB エディターにアクセスして lock 行を削除することが可能になってしまいます。
特定のカーネルやオペレーティングシステムに異なるパスワードを作成するには、この部分に lock 行を追加して、その次の行をパスワード行にします。
一意のパスワードで保護された各節は、以下の例と同様の行で始まります。
title DOS
	lock
	password --md5 <password-hash>
2.1.2.2.2. インタラクティブスタートアップの無効化
起動順序の最初に I キーを押すと、インタラクティブな方法でシステムを起動できます。この方法では、システムがユーザーにサービスを 1 つずつ開始するように求めます。しかし、システムに物理的なアクセスがある攻撃者の場合は、この方法だとセキュリティ関連のサービスを無効にし、システムへのアクセスを許すことになってしまいます。
このようなインタラクティブなスタートアップを防止するには、root で /etc/sysconfig/init ファイルの PROMPT パラメーターを以下のように無効にします。
PROMPT=no

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

パスワードは、Red Hat Enterprise Linux がユーザーの ID を確認する第一の手段です。ユーザーやワークステーション、ネットワークの保護にパスワードのセキュリティが重要であるのは、このためです。
セキュリティ目的で、インストールプログラムはシステムが セキュアハッシュアルゴリズム 512 (SHA512) とシャドウパスワードを使うように設定します。この設定を変更しないことが強く推奨されます。
インストール中にシャドウパスワードが検出されると、すべてのパスワードは全ユーザーが読み取り可能な /etc/passwd ファイルに一方向のハッシュとして保存されます。この場合、システムはオフラインのパスワードクラッキング攻撃に脆弱なものとなってしまいます。侵入者が通常のユーザーとしてマシンにアクセスすると、/etc/passwd ファイルを侵入者自身のマシンにコピーして、パスワードクラッキングプログラムをいくつでも実行できるようになります。このファイルに安全でないパスワードがあれば、パスワードクラッカーがこれを見つけるのは時間の問題となります。
シャドウパスワードは、パスワードハッシュを /etc/shadow ファイルに保存することで、このタイプの攻撃を排除します。このファイルは、root ユーザーのみが読み取り可能なためです。
この場合、攻撃者は SSH や FTP などのマシン上のネットワークサービスにログインしてリモートからパスワードクラッキングを試みることが強いられます。このようなブルートフォース攻撃は時間がかかり、何百回ものログイン失敗がシステムファイルに書き込まれるので、明らかな痕跡が残ります。もちろん、クラッカーが脆弱なパスワードがあるシステムに真夜中から攻撃を開始した場合、夜明け前にはアクセスに成功し、痕跡を隠すためにログファイルを編集してしまう、という可能性もあります。
フォーマットやストレージに加えて考慮すべき点は、コンテンツの問題です。パスワードクラッキングからアカウントを保護するためにユーザーがなし得る最重要事項は、強固なパスワードを作成することです。

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

安全なパスワードを作成するには、長いパスワードの方が短くかつ複雑なものよりも強固であることをユーザーは認識する必要があります。あるパスワードが数字や特殊文字、大文字のアルファベットを含んでいても、それが 8 文字の長さしかなければ、強固なパスワードとは言えません。「John The Ripper」のようなパスワード解析ツールは、人間が記憶するには困難なパスワードを分解するために最適なものです。
情報の理論上では、エントロピーはランダムな変数に関連付けられる不確実性のレベルで、ビット表示されます。エントロピーの値が高ければ高いほど、パスワードはより安全と言えます。NIST (米標準技術研究所) の SP 800-63-1 文書によると、一般的に選択される 5 万件のパスワードからなる辞書にないパスワードには、少なくとも 10 ビットのエントロピーがあります。このため、ランダムな 4 単語からなるパスワードには、およそ 40 ビットのエントロピーがあることになります。安全性を高めるために複数の単語で構成される長いパスワードは、パスフレーズ とも呼ばれます。例を示します。
randomword1 randomword2 randomword3 randomword4
大文字や数字、特殊文字の使用が強制されるシステムでは、上記の推奨事項に合致するパスフレーズは簡単に修正することができます。たとえば、最初の文字を大文字にして、"1!" を追加します。このような修正は、パスフレーズの安全性を大幅に高めるもの ではない ことに注意してください。
安全なパスワードの作成にはいくつものアプローチがありますが、以下の悪い点は必ず避けてください。
  • 辞書の 1 単語を使用する。外国語の 1 単語を使用する。反転した単語を使用する。数字のみを使用する。
  • パスワードまたはパスフレーズを 10 文字未満にする。
  • キーボードのレイアウトにおけるキーの配列を使用する。
  • パスフレーズを書き留める。
  • 誕生日や記念日、家族の名前、ペットの名前などの個人情報をパスフレーズに使用する。
  • 複数のマシンで同じパスワードまたはパスフレーズを使用する。
セキュアなパスワードの作成は不可欠ですが、パスワードの適切な管理も特に大きな組織のシステム管理者にとっては重要です。次のセクションでは、組織内でのユーザーパスワードの作成および管理で推奨される方法を説明します。

2.1.4. 組織内でのユーザーパスワード作成

組織内に多くのユーザーがいる場合、システム管理者は 2 つの基本的な方法で強固なパスワードの使用を強制できます。つまり、管理者がパスワードを作成してユーザーに渡すか、パスワードが受容可能なレベルにあるかどうかを検証しながらユーザー自身がパスワードを作成する方法です。
前者の方法だとパスワードは強固なものになりますが、組織が拡大するにつれてタスクが重荷になります。また、ユーザーが自分のパスワードを書き留めるリスクも高まります。
これらの理由で、多くのシステム管理者は後者を選択します。ただし、パスワードが強固かどうかを積極的に検証し、場合によってはパスワードエージングで定期的にユーザーが強制的にパスワードを変更するようにします。

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

ネットワークを侵入から守るには、組織内で使われているパスワードが強固なものであることをシステム管理者が確認することが推奨されます。ユーザーはパスワードを作成・変更する際に、コマンドラインアプリケーション passwd を使用できます。これは、Pluggable Authentication Modules (PAM) 対応なので、パスワードが短すぎないかまたは簡単にクラックされないかをチェックします。このチェックは、pam_cracklib.so PAM モジュールを使って実行されます。Red Hat Enterprise Linux では、pam_cracklib PAM モジュールを使って、パスワードの強度を規則セットに対してチェックすることができます。これは、他の PAM モジュールとともに /etc/pam.d/passwd ファイルの password コンポーネント内にスタックして、ユーザーログイン用のカスタムルールセットを設定することができます。pam_cracklib には、以下の 2 つのルーチンがあります。ひとつは、示されたパスワードが辞書内にあるかどうかをチェックすること。辞書にない場合は、さらなるチェックを行うことです。チェック項目の完全一覧については、pam_cracklib(8) の man ページを参照してください。

例2.1 pam_cracklib を使ったパスワード強度チェックの設定

パスワードを 8 文字以上にして、4 種類すべての文字を含めることを要件とするには、/etc/pam.d/passwd ファイルの password セクションに以下の行を追加します。
password   required     pam_cracklib.so retry=3 minlen=8 minclass=4
パスワード強度チェックで連続文字または反復文字のチェックを行うには、/etc/pam.d/passwd ファイルの password セクションに以下の行を追加します。
password   required     pam_cracklib.so retry=3 maxsequence=3 maxrepeat=3
この例では、「abcd」や「1234」など、4 つ以上連続する文字をパスワードに含めることはできません。また、同じ文字は、3 つまでしか繰り返すことはできません。

注記

root ユーザーに対してはこれらのチェックは実行されないので、警告メッセージが出ても root ユーザーは通常ユーザー用にどんなパスワードでも設定することができます。
PAM はカスタマイズ可能なので、pam_passwdqc (http://www.openwall.com/passwdqc/ から入手可能) などのパスワード健全性チェッカーをさらに追加したり、新たなモジュールを書き込んだりすることができます。入手可能な PAM モジュールのリストについては、http://uw714doc.sco.com/en/SEC_pam/pam-6.html を参照してください。PAM の詳細情報については、Managing Single Sign-On and Smart Cards ガイドを参照してください。
パスワード作成時に行われるパスワードチェックは、脆弱なパスワードの発見において、パスワードクラッキングプログラムが実行するチェックほど効果的ではありません。
Red Hat Enterprise Linux 下で実行可能な多くのパスワードクラッキングプログラムがありますが、これらはオペレーティングシステムに同梱されていません。以下に一般的なパスワードクラッキングプログラムの例を挙げます。
  • John The Ripper — 高速かつ柔軟性のあるパスワードクラッキングプログラムです。複数の単語リストが使用可能で、ブルートフォースパスワードクラッキングも実行できます。オンラインで http://www.openwall.com/john/ から入手できます。
  • Crack — おそらく最も知名度の高いパスワードクラッキングソフトウェアです。Crack は非常に高速ですが、扱いは John The Ripper ほど簡単ではありません。
  • SlurpieSlurpieJohn The Ripper および Crack と類似したものですが、複数のコンピューター上で同時に実行するように設計されており、分散パスワードクラッキング攻撃を生成します。他の多くの分散攻撃セキュリティ評価ツールとともに、オンラインで http://www.ussrback.com/distributed.htm で入手可能です。

警告

組織内でパスワードのクラッキングを試みる場合は常に、最初に書面で許可を得てください。

2.1.4.2. パスフレーズ

パスフレーズとパスワードは、現在のほとんどのシステムおけるセキュリティの土台となっています。残念ながら、生体認証や 2 要素認証はまだ多くのシステムで主流になっていません。システムの安全確保にパスワードを使用するのであれば、パスフレーズの使用を検討することが推奨されます。パスフレーズはパスワードよりも長く、数字や記号などの非標準文字で実行してもパスワードよりもすぐれた保護を提供します。

2.1.4.3. パスワードエージング

パスワードエージングは、システム管理者が組織内での脆弱なパスワードに対する防御として用いるもうひとつのテクニックです。パスワードエージングとは、一定期間後 (通常 90 日) にユーザーが新たなパスワードを作成するように求められるシステムのことです。理論上は、ユーザーに定期的なパスワード変更を強制すれば、クラックされたパスワードは侵入者にとって一定期間しか有効でないことになります。しかし、パスワードエージングのマイナス面は、ユーザーがパスワードを書き留める可能性が高くなるという点です。
Red Hat Enterprise Linux では、パスワードエージングを指定する主要プログラムは次の 2 つになります。chage コマンド、もしくはグラフィカルな User Manager (system-config-users) アプリケーションです。

重要

chage コマンドを使用するには、シャドウパスワードが有効となっている必要があります。詳細は Red Hat Enterprise Linux 6 導入ガイド を参照してください。
chage コマンドの -M オプションでは、パスワードが有効となる最長日数を指定します。例えば、ユーザーのパスワードが 90 日間で期限切れとなるように設定するには、以下のコマンドを実行します。
chage -M 90 <username>
上記のコマンドでは、<username> をユーザー名で置き換えます。パスワードの期限切れを無効にするには、通常 -M オプションの後に 99999 の値を使います (これは 273 年余りに相当します)。
chage コマンドで使用可能なオプションの詳細情報については、以下の表を参照してください。

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

オプション説明
-d days1970 年 1 月 1 日から最後にパスワードを変更した日までの日数を指定します。
-E dateアカウントがロックされる日付を YYYY-MM-DD の形式で指定します。日付の代わりに、 1970 年 1 月 1 日からの日数を指定することも可能です。
-I daysパスワードが失効してからアカウントがロックされるまでのアクティブでない日数を指定します。値を 0 とすると、パスワード失効後にアカウントはロックされません。
-l現在のアカウントエージングの設定を一覧表示します。
-m daysパスワード変更が必要となる間隔の最短日数を指定します。値を 0 とすると、パスワードは失効しません。
-M daysパスワードの有効最長日数を指定します。このオプションで指定した日数と -d オプションで指定した日数の合計が、1970 年 1 月 1 日から数えた現在までの日数より少ない場合は、ユーザーはアカウントを使用する前にパスワードを変更する必要があります。
-W daysパスワードが失効する前にユーザーに警告を発する日数を指定します。
インタラクティブモードで chage を使用して、複数のパスワードエージングおよびアカウントの詳細を修正することもできます。以下のコマンドでインタラクティブモードに入ります。
chage <username>
以下は、このコマンドを使用したインタラクティブセッションの例です。
~]# chage juan
Changing the aging information for juan
Enter the new value, or press ENTER for the default
Minimum Password Age [0]: 10
Maximum Password Age [99999]: 90
Last Password Change (YYYY-MM-DD) [2006-08-18]:
Password Expiration Warning [7]:
Password Inactive [-1]:
Account Expiration Date (YYYY-MM-DD) [1969-12-31]:
ユーザーの初回ログイン時にパスワードが失効するように設定できます。これにより、ユーザーはパスワードを直ちに変更するよう強制されます。
  1. 初期パスワードを設定します。この手順には 2 つの一般的なアプローチがあります。デフォルトのパスワードを割り当てる、もしくは null パスワードを使用します。
    デフォルトのパスワードを割り当てるには、root としてシェルプロンプトで以下を入力します。
    passwd username
    代わりに null パスワードを割り当てるには、次のコマンドを使用します。
    passwd -d username

    できる限り null パスワードは使用しないで下さい

    null パスワードの使用は便利ですが、安全性は極めて低くなります。これは、いかなる第三者でも、セキュアでないユーザー名を使用して最初にシステムにログインし、アクセスできるためです。null パスワードでアカウントのロック解除を行う前に、ユーザーがログインできる状態にあることを常に確かめてください。
  2. パスワードを直ちに強制的に失効させるには、root として以下のコマンドを実行します。
    chage -d 0 username
    このコマンドは、パスワードが最後に変更された日付の値を 1970 年 1 月 1 日に設定します。パスワードエージングのポリシーが設定されていても、この値はパスワードを直ちに強制的に期限切れにします。
これで、ユーザーは初回ログイン時に新規パスワードを入力するよう要求されます。
グラフィカルの ユーザー管理 アプリケーションを使って、以下のようにパスワードエージングポリシーを作成することもできます。注: この手順を行うには、管理者権限が必要です。
  1. パネル上の システム メニューをクリックして 管理 から ユーザーとグループ をクリックして ユーザー管理 を表示させます。別の方法では、シェルプロンプトで system-config-users のコマンドを入力します。
  2. ユーザー タブをクリックして、ユーザーリストの中から必要なユーザーを選択します。
  3. ツールバーの プロパティ をクリックして、ユーザー設定のダイアログボックスを表示させます (または ファイル メニューで プロパティ を選択します) 。
  4. パスワード情報 タブをクリックして、パスワード失効を有効にする のチェックボックスにチェックマークを付けます。
  5. 変更が要求されるまでの日数 フィールドに必要な値を入力し、OK をクリックします。
パスワードエージングオプションの指定

図2.1 パスワードエージングオプションの指定

screenshot needs to be updated

2.1.5. 動きのないアカウントをロックする

pam_lastlog PAM モジュールを使うと、しばらくログインしていないユーザーをロックアウトしたり、最後のログイン試行についての情報を表示できます。このモジュールは root アカウントはチェックしないので、root アカウントがロックアウトされることはありません。
lastlog コマンドは、ユーザーの最後のログインを表示します。一方、last コマンドは、すべての現行および以前のログインセッションを表示します。これらのコマンドはそれぞれ、/var/log/lastlog/var/log/wtmp ファイルからデータを読み込みます。データは、バイナリ形式で保存されています。
  • ユーザーが最後にログインした前に試行されたログイン失敗数を表示するには、root で以下の行を /etc/pam.d/login ファイルの session セクションに追加します。
    session     optional      pam_lastlog.so silent noupdate showfailed
    
アクティビティーがないことによるアカウントのロックは、コンソールもしくは GUI、またはこれら両方に適用するよう設定することができます。
  • アクティビティーが 10 日間なかった場合にアカウントをロックするには、root で以下の行を /etc/pam.d/login ファイルの auth セクションに追加します。
    auth  required  pam_lastlog.so inactive=10
    
  • GNOME デスクトップ環境でアカウントをロックするには、root で以下の行を /etc/pam.d/gdm ファイルの auth セクションに追加します。
    auth  required  pam_lastlog.so inactive=10
    

注記

他のデスクトップ環境では、その環境における該当ファイルを編集してください。

2.1.6. アクセス制御のカスタマイズ

pam_access PAM モジュールを使用すると、管理者はログイン名、ホストもしくはドメイン名、または IP アドバイスに基づいてアクセス制御をカスタマイズできます。デフォルトでは、他の指定がない場合、モジュールがアクセスルールを /etc/security/access.conf ファイルから読み込みます。これらルールの形式についての完全な説明は、access.conf(5) の man ページを参照してください。Red Hat Enterprise Linux ではデフォルトで、pam_access/etc/pam.d/crond および /etc/pam.d/atd の各ファイルに含まれています。
ユーザー john がコンソールおよびグラフィックデスクトップ環境からシステムにアクセスできないようにするには、以下の手順を実行します。
  1. 以下の行を /etc/pam.d/login および /etc/pam.d/gdm-* の各ファイルの account セクションに追加します。
    account     required     pam_access.so
    
  2. /etc/security/access.conf ファイルで、以下のルールを指定します。
    - : john : ALL
    
    このルールでは、ユーザー john がどの場所からログインしようとしても、拒否されます。
ユーザー john が IP アドレス 1.2.3.4 からログインしようとする場合を除いて、SSH 経由ですべてのユーザーによるログインを許可するには、以下の手順を実行します。
  1. 以下の行を /etc/pam.d/sshd ファイルの account セクションに追加します。
    account     required     pam_access.so
    
  2. /etc/security/access.conf ファイルで以下の ルールを指定します。
    + : ALL EXCEPT john : 1.2.3.4
    
他のサービスからのアクセスを制限するには、/etc/pam.d ディレクトリー内の各ファイル内で pam_access モジュールが必要になります。
システム全体の PAM 設定ファイル (/etc/pam.d ディレクトリー内の *-auth ファイル) を呼び出すすべてのサービス向けに pam_access モジュールを呼び出すには、以下のコマンドを使用します。
authconfig --enablepamaccess --update
別の方法では、認証設定ユーティリティーを使って pam_access モジュールを有効にすることができます。このユーティリティーを起動するには、トップメニューから システム管理認証 を選択します。高度なオプション タブで、「ローカルアクセス制御を有効にする」にチェックを入れます。これで、pam_access モジュールがシステム全体の PAM 設定に追加されます。

2.1.7. 時間ベースのアクセス制限

pam_time PAM モジュールでは、一定の時間帯にアクセスを制限することができます。また、特定の曜日やユーザー名、システムサービスの使用などに基づいてアクセスを制限するように設定することも可能です。デフォルトでは、モジュールはアクセスルールを /etc/security/time.conf ファイルから読み取ります。これらルールの形式についての完全な説明は、time.conf(5) の man ページを参照してください。
root ユーザー以外の全ユーザーが月曜から金曜までの午後 5:30 から午前 8:00 までと土曜日および日曜日にログインできないようにするには、以下の手順を実行します。
  1. 以下の行を /etc/pam.d/login ファイルの account セクションに追加します。
    account     required     pam_time.so
  2. /etc/security/time.conf ファイルで、以下のルールを指定します。
    login ; ALL ; !root ; tty* ; !Wk1730-0800
ユーザー john が (月曜始まりの) 営業日の営業時間中のみに SSH サービスを使用できるようにするには、以下の手順を実行します。
  1. 以下の行を /etc/pam.d/sshd ファイルに追加します。
    account     required     pam_time.so
  2. /etc/security/time.conf ファイルで、以下のルールを指定します。
    sshd ; john ; tty* ; Wk0800-1730

注記

これらの設定がデスクトップで適用されるには、pam_time モジュールが /etc/pam.d ディレクトリー内の対応ファイルに含まれている必要があります。

2.1.8. アカウント制限の適用

pam_limits PAM モジュールを使うと、以下のことができます。
  • ユーザーあたりの同時ログインセッションの最大数など、ユーザーログインセッションの制限を適用する。
  • ulimit ユーティリティーで設定する制限を指定する。
  • nice ユーティリティーで設定する優先順位を指定する。
デフォルトでは、ルールは /etc/security/limits.conf ファイルから読み取られます。これらルールの形式についての完全な説明は、limits.conf(5) の man ページを参照してください。さらに、特定のアプリケーションやサービス向けに、/etc/security/limits.d ディレクトリー内に個別の設定ファイルを作成することもできます。デフォルトでは、pam_limits モジュールは、/etc/pam.d/ ディレクトリー内の多くのファイルに含まれています。ユーザープロセスのデフォルト制限は /etc/security/limits.d/90-nproc.conf ファイルで定義され、fork 爆弾のような悪意のあるサービス拒否攻撃を防ぎます。デフォルトのユーザープロセス制限を 50 に変更するには、/etc/security/limits.d/90-nproc.conf 内の値をファイル内の形式にしたがって変更します。
* soft nproc 50

例2.2 ユーザーあたりの最大ログイン数の指定

  1. office という名前のグループにおけるユーザーの同時ログイン最大数を設定するには、以下の ルールを /etc/security/limits.conf ファイル内で指定します。
    @office - maxlogins 4
  2. 以下の行は、デフォルトで /etc/pam.d/system-auth 内にあるはずです。ない場合は、手動で追加します。
    session  required  pam_limits.so

2.1.9. 管理者コントロール

ホームとなるマシンを管理する際には、ユーザーは root ユーザーとして、または sudosu などの setuid プログラムで有効な root 権限を取得してから実行する必要のあるタスクがあります。setuid プログラムは、プログラムを実行しているユーザーではなく、プログラムの所有者のユーザー ID (UID) で実行されるプログラムです。これらのプログラムは、以下の例のように、ロング形式の所有者セクションにある s で示されます。
~]$ ls -l /bin/su
-rwsr-xr-x. 1 root root 34904 Mar 10  2011 /bin/su

注記

s は大文字または小文字の場合があります。大文字の場合は、基になるパーミッションビットが設定されていないことを示します。
しかし、組織のシステム管理者は、組織のユーザーが自身のマシンにどの程度の管理者アクセスを持つかを決定しなくてはなりません。pam_console.so と呼ばれる PAM モジュールを使うと、再起動やリムーバブルメディアのマウントなど通常は root ユーザーのみとなっているアクティビティーを、物理コンソールに最初にログインしたユーザーが実行できるようになります (pam_console.so の詳細については、Managing Single Sign-On and Smart Cards を参照してください)。しかし、ネットワーク設定の変更や新たなマウスの設定、ネットワークデバイスのマウントといったシステム管理者の他の重要なタスクは、管理者権限なしでは実行できません。その結果、システム管理者はネットワーク上のユーザーにどの程度のアクセスを許可するかを判断する必要があります。

2.1.9.1. Root アクセスの許可

組織内のユーザーが信頼できてコンピューターの知識を持っているユーザーであれば、root アクセスを許可することに問題はありません。ユーザーに root アクセスを許可すれば、デバイスの追加やネットワークインターフェイスの設定といった重要性の低いアクティビティを個別のユーザーが処理できるので、システム管理者はネットワークセキュリティや他の重要な問題に専念できます。
一方で、個別のユーザーに root アクセスを許可すると、以下のような問題も発生します。
  • マシンの誤った設定 — root アクセスを持つユーザーは自身のマシンを間違って設定する可能性があり、この問題を解決するにはヘルプを必要とします。ひどい場合には、知らないうちにセキュリティに穴を開けてしまう可能性もあります。
  • 安全でないサービスの実行 — root アクセスを持つユーザーは、FTP や Telnet といった安全でないサービスを自身のマシン上で実行して、ユーザー名やパスワードを危険にさらす可能性があります。これらのサービスは、ユーザー名やパスワードをプレーンテキストでネットワーク上で送信します。
  • Email の添付ファイルを root として実行 — 滅多にないことですが、Linux に影響を及ぼす Email ウイルスも存在します。しかしこれが脅威となるのは、root ユーザーとして実行された場合のみです。
  • 監査証跡がそのままになる — root アカウントは通常複数のユーザーが共有し、複数のシステム管理者がシステムのメインテナンスをできるようになっているため、ある時点でこのうちのどのユーザーが root だったかを見分けることは不可能です。別個のログインを使用すると、ユーザーがログインしたアカウントとセッション追跡目的の一意の番号がタスク構造に組み込まれ、これはユーザーが開始するプロセスすべてで継承されます。同時ログインを使用すると、一意の番号は特定ログインのアクションの追跡に使用できます。アクションが監査イベントを生成する際には、ログインアカウントとその一意の番号に関連付けられているセッションとともに記録されます。これらのログインとセッションを表にするには、aulast コマンドを使用します。aulast--proof オプションを使うと、特定のセッションで生成された監査可能なイベントを切り離す特定の ausearch クエリの提示が可能になります。

2.1.9.2. Root アクセスの拒否

上記またはその他の理由でユーザーが root でログインすることに管理者が不安に感じる場合、root パスワードは公開せず、ランレベル 1 へのアクセスやシングルユーザーモードへのアクセスをブートローダーパスワード保護で拒否してください (このトピックについての詳細は 「ブートローダーのパスワード」 を参照してください)。
管理者は以下の 4 つの方法で、root ログインが拒否されるようにできます。
Root シェルの変更
ユーザーが直接 root としてログインしないように、システム管理者は /etc/passwd ファイルで root アカウントのシェルを /sbin/nologin に設定できます。

表2.2 Root シェルの無効化

影響あり影響なし
Root シェルへのアクセスを防ぎ、アクセスの試みをすべてログに記録します。以下のプログラムは root アカウントへのアクセスが止められます。
  • login
  • gdm
  • kdm
  • xdm
  • su
  • ssh
  • scp
  • sftp
FTP クライアントや メールクライアント、多くの setuid プログラムはシェルを必要としません。以下のプログラムは root アカウントへのアクセスが 止められません
  • sudo
  • FTP クライアント
  • Email クライアント
どのコンソールデバイス (tty) からの root アクセスも無効にする
Root アカウントへのアクセスをさらに制限するために、管理者は /etc/securetty ファイルを編集してコンソールでの root ログインを無効にすることができます。このファイルは、root ユーザーがログイン可能なすべてのデバイスを一覧表示します。このファイル自体がない場合、コンソールからでも raw ネットワークインターフェイスからでも、システム上のいかなる通信デバイスからでも root ユーザーはログイン可能となってしまいます。ユーザーは Telnet 経由で root としてマシンにログイン可能で、こうするとプレーンテキストのパスワードがネットワーク上で送信されてしまうので、危険なことになります。
デフォルトでは、Red Hat Enterprise Linux の /etc/securetty ファイルは root ユーザーにのみ、マシンに物理的につながれたコンソールでのログインを許可します。root ユーザーによるログインを拒否するには、root でシェルプロンプトから以下のコマンドを入力して、このファイルのコンテンツ削除します。
echo > /etc/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 スイートを使用してログインすることは止められません。これは、コンソールは認証が終わるまで開かれないためです。

表2.3 Root ログインの無効化

影響あり影響なし
コンソールまたはネットワーク経由での root アカウントへのアクセスを防ぎます。以下のプログラムは root アカウントへのアクセスが止められます。
  • login
  • gdm
  • kdm
  • xdm
  • tty を開くその他のネットワークサービス
Root としてはログインしませんが、setuid または別のメカニズムで管理タスクを実行するプログラムです。以下のプログラムは root アカウントへのアクセスが 止められません
  • su
  • sudo
  • ssh
  • scp
  • sftp
Root SSH ログインを無効にする
SSH プロトコル経由での root ログインを防ぐには、SSH デーモンの設定ファイルである /etc/ssh/sshd_config を編集し、
#PermitRootLogin yes
の行を以下のように変更します。
PermitRootLogin no

表2.4 Root SSH ログインの無効化

影響あり影響なし
ツールの OpenSSH スイート経由での root アクセスを防ぎます。以下のプログラムは root アカウントへのアクセスが止められます。
  • ssh
  • scp
  • sftp
ツールの OpenSSH スイートの一部ではないプログラム
PAM を使用してサービスへの root アクセスを制限する
PAM は /lib/security/pam_listfile.so を使って、特定アカウントの拒否に大幅な柔軟性を提供します。管理者はこのモジュールを使ってログインが許可されないユーザーリストを引用できます。システムサービスへの root アクセスを制限するには、/etc/pam.d/ ディレクトリー内の対象サービスのファイルを編集して、pam_listfile.so モジュールが認証に必要となるようにします。
以下の例では、/etc/pam.d/vsftpd PAM 設定ファイルの vsftpd FTP サーバーにこのモジュールを使用しています (一行目の末にある \ の文字は、指示文が一行の場合は必要ありません)。
auth   required   /lib/security/pam_listfile.so   item=user \
 sense=deny file=/etc/vsftpd.ftpusers onerr=succeed
これにより、PAM が/etc/vsftpd.ftpusers ファイルを見て、リストに載っているユーザーにサービスへのアクセスを拒否するように指示します。管理者はこのファイル名を変更し、各サービスごとに別個のリストを維持したり、複数サービスへのアクセスを拒否する集中リストを使用したりすることができます。
管理者が複数サービスへのアクセスを拒否したい場合、メールクライアントでは /etc/pam.d/pop/etc/pam.d/imap ファイルに、SSH クライアントでは /etc/pam.d/ssh ファイルのような PAM 設定ファイルに同様の行を追加することができます。
PAM についての詳細は、Red Hat Enterprise Linux Managing Single Sign-On and Smart Cards ガイドの Using Pluggable Authentication Modules (PAM) の章を参照してください。

表2.5 PAM を使った root の無効化

影響あり影響なし
PAM 対応のネットワークサービスへの root アクセスを防ぎます。以下のサービスは root アカウントへのアクセスが止められます。
  • login
  • gdm
  • kdm
  • xdm
  • ssh
  • scp
  • sftp
  • FTP クライアント
  • Email クライアント
  • すべての PAM 対応サービス
PAM 非対応のプログラムおよびサービス

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

ユーザーが root としてログインしている場合、このセッションを無人状態にしておくと、重大なセキュリティリスクをもたらす恐れがあります。このリスクを減らすために、一定期間が経過してからアイドル状態のユーザーを自動的にログアウトするようにシステムを設定することができます。
  1. screen パッケージがインストールされていることを確認して下さい。root として以下のコマンドを実行します。
    ~]# yum install screen
    Red Hat Enterprise Linux にパッケージをインストールする方法についての詳細情報は、Red Hat Enterprise Linux 6 導入ガイドパッケージのインストール のセクションを参照してください。
  2. root として /etc/profile ファイルの先頭に以下の行を追加して、このファイルの処理が中断されないようにします。
    trap "" 1 2 3 15
  3. /etc/profile ファイルの最後に以下の行を追加して、ユーザーが仮想コンソールまたはリモートからログインする度に screen セッションが開始するようにします。
    
    SCREENEXEC="screen"
    if [ -w $(tty) ]; then
      trap "exec $SCREENEXEC" 1 2 3 15
      echo -n 'Starting session in 10 seconds'
      sleep 10
      exec $SCREENEXEC
    fi
    新規セッションが開始される度にメッセージが表示されるため、ユーザーは 10 秒間待たなければならない点に注意して下さい。セッション開始までの待機時間を調節するには、sleep コマンドの後にある値を変更します。
  4. アクティブでない状態が一定期間経過した後に、screen セッションを閉じるようにするには、以下の行を /etc/screenrc 設定ファイルに追加します。
    
    idle 120 quit 
    autodetach off
    上記は、制限時間を 120 秒に設定しています。この制限を調節するには、idle 指示文の後にある値を変更します。
    別の方法として、以下の行を使用してセッションのロックだけが行われるようにシステムを設定することも可能です。
    
    idle 120 lockscreen
    autodetach off
    この方法では、セッションのロックを解除するためにパスワードが必要になります。
これらの変更は、ユーザーが次回システムにログインする時に反映されます。

2.1.9.4. Root アクセスの制限

Root ユーザーへのアクセスを完全に拒否するのではなく、管理者が susudo といった setuid プログラム経由のアクセスのみを許可したい場合もあるかもしれません。su および sudo についての詳細は Red Hat Enterprise Linux 6 導入ガイド および su(1)sudo(8) の man ページを参照してください。

2.1.9.5. アカウントのロック

Red Hat Enterprise Linux 6 では、pam_faillock PAM モジュールを使うとシステム管理者は特定回数のログイン失敗の後にユーザーアカウントをロックアウトすることができます。ユーザーログインの試行回数を制限する主な目的はセキュリティ措置であり、ユーザーアカウントのパスワード獲得を目的とする総当たり攻撃を防ぐためのものです。
pam_faillock モジュールを使うと、ログイン失敗はユーザーごとに /var/run/faillock ディレクトリー内の個別ファイルに保存されます。

注記

ログイン失敗のログファイルにおける行の順番は重要なものです。even_deny_root オプションが使用されている場合、この順番が変更されると root アカウントを含むすべてのユーザーアカウントがロックされます。
アカウントのロックを設定するには、以下の手順を実行します。
  1. root 以外のユーザーがログインに 3 回失敗した後にロックアウトし、その 10 分後にこのユーザーのロックアウトを解除するようにするには、以下の行を /etc/pam.d/system-auth および /etc/pam.d/password-auth の各ファイルの auth セクションに追加します。
    auth        required       pam_faillock.so preauth silent audit deny=3 unlock_time=600
    auth        sufficient     pam_unix.so nullok try_first_pass
    auth        [default=die]  pam_faillock.so authfail audit deny=3 unlock_time=600
    
  2. 以下の行を上記の手順の両ファイルの account セクションに追加します。
    account     required      pam_faillock.so
    
  3. アカウントのロックアウトを root ユーザーにも適用するには、/etc/pam.d/system-auth および /etc/pam.d/password-auth の各ファイルの pam_faillock エントリーに even_deny_root オプションを追加します。
    auth        required      pam_faillock.so preauth silent audit deny=3 even_deny_root unlock_time=600
    auth        sufficient    pam_unix.so nullok try_first_pass
    auth        [default=die] pam_faillock.so authfail audit deny=3 even_deny_root unlock_time=600
    auth        sufficient    pam_faillock.so authsucc audit deny=3 even_deny_root unlock_time=600
    
ユーザー john がログインに 3 回失敗した後に再度ログインしようとすると、このユーザーのアカウントはこの 4 回目のログイン試行でロックされます。
[user@localhost ~]$ su - john
Account locked due to 3 failed logins
su: incorrect password
複数回のログイン失敗の後でもユーザーがロックアウトされないようにするには、以下の行を /etc/pam.d/system-auth および /etc/pam.d/password-auth の各ファイルで pam_faillock が最初に呼び出される行のすぐ上に追加します。また、user1user2user3 を実際のユーザー名で置き換えます。
auth [success=1 default=ignore] pam_succeed_if.so user in user1:user2:user3
ユーザー別のログイン失敗数を表示するには、root で以下のコマンドを実行します。
[root@localhost ~]# faillock 
john:
When                Type  Source                                           Valid
2013-03-05 11:44:14 TTY   pts/0                                                V
ユーザーのアカウントのロックを解除するには、root で以下のコマンドを実行します。
faillock --user <username> --reset
authconfig ユーティリティーを使って認証設定を修正すると、system-auth および password-auth の各ファイルは authconfig ユーティリティーからの設定で上書きされます。設定ファイルと authconfig を同時に使うには、以下の手順でアカウントロックを設定する必要があります。
  1. 以下のシンボリックリンクを作成します。
    ~]# ln -s /etc/pam.d/system-auth /etc/pam.d/system-auth-local
    ~]# ln -s /etc/pam.d/password-auth /etc/pam.d/password-auth-local
  2. /etc/pam.d/system-auth-local ファイルに以下の行を記載します。
    auth        required       pam_faillock.so preauth silent audit deny=3 unlock_time=600 include system-auth-ac 
    auth        [default=die]  pam_faillock.so authfail silent audit deny=3 unlock_time=600
    
    account     required       pam_faillock.so
    account     include        system-auth-ac 
    
    password    include        system-auth-ac
    
    session     include        system-auth-ac
    
  3. /etc/pam.d/password-auth-local ファイルに以下の行を記載します。
    auth        required       pam_faillock.so preauth silent audit deny=3 unlock_time=600 include password-auth-ac 
    auth        [default=die]  pam_faillock.so authfail silent audit deny=3 unlock_time=600
    
    account     required       pam_faillock.so
    account     include        password-auth-ac 
    
    password    include        system-auth-ac
    
    session     include        system-auth-ac
    
pam_faillock の設定オプションについての詳細情報は、pam_faillock(8) の man ページを参照してください。

2.1.10. セッションのロック

日常の業務中にユーザーがワークステーションから離れなければならない時もあります。こういう場合は、特に十分な物理的セキュリティ対策がとられていない環境 (「物理的コントロール」 を参照) では、攻撃者にマシンに物理的にアクセスする機会を与えてしまいます。ノートパソコンの場合は特に、持ち運びが便利なので物理的な安全性が脅かされます。このリスクは、正しいパスワードが入力されないとシステムにアクセスできないようにするセッションロッキング機能を使うことで緩和できます。

注記

画面のロックがログアウトよりも優れている点は、ロックの場合は (ファイル転送といった) ユーザーのプロセスを続行できるという点です。ログアウトしてしまうと、このようなプロセスは中断してしまいます。

2.1.10.1. GNOME スクリーンセーバーコマンドを使用して GNOME をロックする

Red Hat Enterprise Linux 6 のデフォルトのデスクトップ環境である GNOME には、ユーザーがいつでも画面をロックできる機能が含まれています。このロックを実行するにはいくつかの方法があります。
  • システム設定キーボード・ショートカットデスクトップ画面をロックする で指定されているキーの組み合わせを押します。デフォルトでは、Ctrl+Alt+L となっています。
  • パネル上で システム画面のロック を選択します。
  • コマンドラインインターフェイスで以下のコマンドを実行します。
    gnome-screensaver-command -l
上記の方法はどれも、スクリーンセーバーが実行されて画面がロックされる、という同じ結果になります。ユーザーがいずれかのキーを押すとスクリーンセーバーが解除され、パスワードを入力して作業を続けられます。
この機能は gnome-screensaver プロセスの稼働を必要とすることに注意してください。これが稼働中かどうかは、プロセスについての情報を提供するコマンドを使用してチェックします。例えば、以下のコマンドを端末から実行します。
pidof gnome-screensaver
gnome-screensaver が実行中であれば、識別番号 (PID) を示す番号がコマンド実行後に画面に表示されます。プロセスが実行中でなければ、出力がありません
詳細は gnome-screensaver-command(1) man ページを参照してください。

重要

上記の画面をロックする方法は、手動でのアクティベーションに依存しています。そのため管理者はユーザーに、短時間でもマシンから離れる場合は必ずコンピューターをロックすることアドバイスする必要があります。
2.1.10.1.1. スクリーンセーバーロックの自動アクティベーション
gnome-screensaver-command の名前が示すように、ロック機能は GNOME のスクリーンセーバーと連動しています。ロック機能をスクリーンセーバーのアクティベーションと連動させて、ワークステーションが一定時間無人となったらロックするようにできます。この機能はデフォルトで、5 分間のタイムアウトでアクティベートするようになっています。
この自動ロック設定を変更するには、メインパネルから システム設定スクリーンセーバー を選択します。これで、タイムアウトの時間設定をするウィンドウが開き (アイドル状態になるまでの時間 スライダー) 自動ロックの有効/無効化ができます (スクリーンセーバーを起動したら画面をロックする チェックボックス)。
スクリーンセーバーの設定変更

図2.2 スクリーンセーバーの設定変更

注記

スクリーンセーバーの設定 ダイアログで アイドル状態になったらスクリーンセーバーを起動する のオプションを無効にすると、スクリーンセーバーが自動で起動しなくなります。このため、自動ロックも無効になりますが、「GNOME スクリーンセーバーコマンドを使用して GNOME をロックする」 にある手動作業でのワークステーションのロックはできます。
2.1.10.1.2. リモートでのセッションロック
ロック対象のワークステーションが ssh プロトコルでの接続を受け入れれば、これを使用して GNOME セッションをリモートでロックすることもできます。アクセスしたマシンの画面をリモートでロックするには、以下のコマンドを実行します。
ssh -X <username>@<server> "export DISPLAY=:0; gnome-screensaver-command -l"
<username> を自分のユーザー名で、<server> をロックするワークステーションの IP アドレスで置き換えます。
ssh に関する詳細は、「SSH (Secure Shell)」 を参照してください。

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

仮想コンソールをロックする必要がある場合は、vlock というユーティリティーを使って実行できます。このユーティリティーをインストールするには、以下のコマンドを root で実行します。
~]# yum install vlock
インストール後は、新たなパラメーターなしで vlock コマンドを使えば、コンソールセッションはすべてロックできます。このコマンドでは、アクティブな仮想コンソールをロックしますが、他のセッションへのアクセスは可能です。ワークステーション上のすべての仮想コンソールへのアクセスを防止するには、以下のコマンドを実行します。
vlock -a
この場合、vlock がアクティブなコンソールをロックし、-a オプションが他の仮想コンソールへのスイッチを防ぎます。
詳細は vlock(1) man ページを参照してください。

重要

Red Hat Enterprise Linux 6 で現在利用可能な vlock のバージョンに関する既知の問題がいくつかあります。
  • このプログラムでは現在、root パスワードを使ったコンソールのロック解除ができません。詳細は BZ#895066 を参照してください。
  • コンソールをロックしても、画面およびスクロールバックバッファを削除しないので、それまでのコマンドやコンソールで表示された出力が、ワークステーションに物理的アクセスできれば誰でも見れることになります。詳細については、BZ#807369 を参照してください。

2.1.11. 利用可能なネットワーク

組織内のシステム管理者にとっては管理機能へのユーザーアクセスは重要な問題ですが、どのネットワークサービスがアクティブかを監視することは、Linux システムのすべての管理・運営担当者にとって最重要事項です。
Red Hat Enterprise Linux 6 における多くのサービスは、ネットワークサーバーとして動作します。マシン上でネットワークサービスが稼働中であれば、(デーモン と呼ばれる) サーバーアプリケーションが 1 つ以上のネットワークポート上での接続をリッスンします。これらの各サーバーは、潜在的な攻撃の接近手段として扱われる必要があります。

2.1.11.1. サービスへのリスク

ネットワークサービスは Linux システムに多くのリスクを与える可能性があります。主な問題を以下に挙げます。
  • サービス拒否攻撃 (DoS) — サービス拒否攻撃は、サービスに対して要求を大量に送信することでシステムがすべての要求をログ記録・応答しようとし、使用不可能になります。
  • 分散型サービス拒否攻撃 (DDoS) — これは DoS 攻撃の一種で、複数の脆弱なマシンを使用し (通常、数千以上)、サービスに対して一斉攻撃を仕掛けます。大量の要求が送信され、サービスを使用不可能にしてしまいます。
  • スクリプトの脆弱性への攻撃 — Web サーバーが通常行うように、サーバー全体のアクションにサーバーがスクリプトを使用している場合、クラッカーは誤って書かれたスクリプトを攻撃することができます。このスクリプトの脆弱性に対する攻撃により、バッファがオーバーフロー状態になるか、攻撃者がシステム上のファイルを変更できる可能性があります。
  • バッファオーバーフロー攻撃 — ポート番号 0 から 1023 までに接続するサービスは、管理ユーザーとして実行する必要があります。アプリケーションに利用可能なバッファオーバーフローがある場合、攻撃者はデーモンを実行中のユーザーとしてシステムにアクセスすることができます。利用可能なバッファオーバーフローが存在することから、クラッカーは自動ツールを使って脆弱性のあるシステムを特定でき、アクセスを確保した後に自動ルートキットを使ってシステムへのアクセスを維持します。

注記

Red Hat Enterprise Linux では、ExecShield と呼ばれる x86 互換のシングルおよびマルチプロセッサのカーネルがサポートする実行可能メモリのセグメント化および保護技術により、バッファオーバーフローの脆弱性における脅威は緩和されています。ExecShield は仮想メモリを実行可能なセグメントと非実行可能セグメントに分けることでバッファオーバーフローのリスクを下げます。(バッファオーバーフローエクスプロイトから注入された悪意のあるコードなど) 実行可能セグメント外で実行を試みるすべてのプログラムコードは、セグメント化の失敗を発生させ、終了します。
Execshield には AMD64 プラットフォーム上の No eXecute (NX) と Itanium 上の eXecute Disable (XD) テクノロジー、Intel® 64 システムのサポートが含まれます。これらのテクノロジーが ExecShield と組み合わさることで、4 KB の実行可能コードという粒度で仮想メモリの実行可能な部分での悪意のあるコードの実行を防ぎます。これで、バッファオーバーフローエクスプロイトからの攻撃リスクを減らします。

重要

ネットワーク上での攻撃への露出を限定するには、使用していないサービスをすべて無効にしてください。

2.1.11.2. サービスの特定および設定

セキュリティを強化するために、Red Hat Enterprise Linux でインストールされているネットワークサービスのほとんどはデフォルトでオフとなっています。ただし、以下のものは例外となります。
  • cupsd — Red Hat Enterprise Linux のデフォルトのプリントサーバー
  • lpd — 代替プリントサーバー
  • xinetdgssftptelnet などの下位サーバーへの接続を管理するスーパーサーバー
  • sendmail — Sendmail メール転送エージェント (MTA) はデフォルトでは有効となっていますが、localhost からの接続のみをリッスンします。
  • sshd — Telnet の安全な代替となる OpenSSH サーバー
これらサービスの稼働を継続しておくかどうかを判断する際は、常識にしたがってリスクを避けるのが最善策です。例えば、プリンターが利用できない場合は cupsd を無効にします。同じことは portmap についても言えます。NFSv3 ボリュームをマウントしていなかったり、NIS (ypbind サービス) を使用しないのであれば、portmap を無効にすべきです。
サービス設定ツール

図2.3 サービス設定ツール

特定サービスの目的が明確でない場合は、図2.3「サービス設定ツール」 にあるように、サービス設定ツール の説明フィールドで追加情報が提供されています。
起動時にどのネットワークサービスが開始されるかをチェックするだけでは十分ではありません。どのポートが開いていて、リッスンしているかをチェックすることも推奨されます。詳細は、「リッスンしているポートの確認」 を参照してください。

2.1.11.3. 安全でないサービス

潜在的にはどのネットワークサービスも安全ではありません。未使用のサービスをオフにすることが重要なのは、このためです。サービスのエクスプロイトは定期的に発見され修正プログラムが提供されているので、ネットワークサービスはどんなものでも関連するパッケージを定期的に更新することが非常に重要です。詳細は 「セキュリティの更新」 を参照してください。
ネットワークプロトコルの中にはもともと他のものよりも安全性が低いものがあります。以下の動作を実行するサービスがそれに当たります。
  • 暗号化されていないネットワークでユーザー名やパスワードを送信する — Telnet や FTP など多くの古いプロトコルは認証セッションを暗号化しないので、できるだけ避けてください。
  • 暗号化されていないネットワークで機密性の高いデータを送信する — Telnet や FTP、HTTP、SMTP など多くのプロトコルでは暗号化されていないネットワークでデータを送信します。また、NFS や SMB などの多くのネットワークファイルシステムでも暗号化されていないネットワークで情報を送信します。これらのプロトコルを使用する際に送信するデータの種類を制限することは、ユーザーの責任になります。
    netdump といったリモートのメモリダンプサービスは、暗号化されていないネットワークでメモリのコンテンツを送信します。メモリダンプにはパスワードや、さらに深刻な場合にはデータベースエントリや他の機密性の高い情報が含まれている場合もあります。
    fingerrwhod といったサービスは、システムのユーザーについての情報を明らかにします。
もともと安全性が低いサービスには、rloginrshtelnetvsftpd などがあります。
リモートログインおよびシェルプログラム (rloginrshtelnet) はすべて避けて、SSH を選択するべきです。sshd についての詳細情報は、「セキュリティ強化の通信ツール」を参照してください。
FTP はリモートシェルと比べるとシステムの安全性にそれほど危険ではありませんが、問題を回避するには FTP サーバーは慎重に設定、監視する必要があります。FTP サーバーを安全にする詳細情報については、「FTP のセキュア化」 を参照してください。
実装時に注意が必要で、ファイアウォールの背後に配置する必要があるサービスは以下のものです。
  • finger
  • authd (以前の Red Hat Enterprise Linux リリースでは identd と呼ばれていました)
  • netdump
  • netdump-server
  • nfs
  • rwhod
  • sendmail
  • smb (Samba)
  • yppasswdd
  • ypserv
  • ypxfrd
ネットワークサービスの安全性を高めるための詳細情報は、「サーバーのセキュリティ」 を参照してください。
次のセクションでは、簡単なファイアウォールを設定するツールについて説明します。

2.1.12. 個人用ファイアウォール

必要な ネットワークサービスを設定した後は、ファイアウォールの設置が重要になります。

重要

インターネットや信頼できないネットワークに接続する に、必要なサービスを設定し、ファイアウォールを設置してください。
ファイアウォールは、ネットワークパケットがシステムのネットワークインターフェイスにアクセスすることを防ぎます。ファイアウォールがブロックしているポートに要求がなされた場合、この要求は無視されます。サービスがブロックされているポートの一つをリッスンしている場合、パケットは受信されず、実質的には無視されます。このため、ファイアウォールを設定する際は、設定済みサービスが使用しているポートへのアクセスをブロックしないようにする一方で、使用されていないポートへのアクセスを確実にブロックするようにしてください。
ほとんどのユーザーにとって、簡単なファイアウォールを設定する最善のツールは、Red Hat Enterprise Linux に同梱されているグラフィカルのファイアウォール設定ツールである Firewall Configuration Tool (system-config-firewall) です。このツールは、コントロールパネルのインターフェイスを使って全般目的のファイアウォール用に幅広い iptables ルールを作成します。
このアプリケーションと利用可能なオプションについての詳細情報は、「基本的なファイアウォールの設定」 を参照してください。
上級ユーザーおよびサーバー管理者の場合は、iptables を使って手動でファイアウォールを設定する方法が望まれます。詳細は 「ファイアウォール」 を参照してください。iptables コマンドに関する総合的なガイドについては、「IPTables」 を参照してください。

2.1.13. セキュリティ強化の通信ツール

インターネットの規模と人気が拡大するにつれて、通信傍受の脅威も増大しています。通信はネットワーク上で行われるため、長年にわたってこれを暗号化するツールが開発されてきました。
Red Hat Enterprise Linux 6 に同梱されている基本的ツールは 2 つあり、これらはネットワーク上を行き来する情報を保護するために高レベルの公開キー暗号作成法に基づいた暗号化アルゴリズムを使います。
  • OpenSSH — ネットワーク通信暗号化のための SSH プロトコルの無料実装
  • Gnu Privacy Guard (GPG) — データ暗号化用の PGP (Pretty Good Privacy) 暗号化アプリケーションの無料実装
OpenSSH はリモートマシンにアクセスする安全な方法で、telnetrsh などの旧式かつ暗号化されていないサービスに代わるものです。OpenSSH には sshd と呼ばれるネットワークサービスのほか、以下の 3 つのコマンドラインアプリケーションが含まれています。
  • ssh — 安全なコンソールアクセスクライアント
  • scp — 安全なリモートコピーコマンド
  • sftp — インタラクティブなファイル転送セッションを可能にする安全な擬似 ftp クライアント
OpenSSH に関する詳細は、「SSH (Secure Shell)」 を参照してください。

重要

sshd サービスはもともと安全なものですが、セキュリティ脅威を回避するにはサービスが最新のものである 必要があります。詳細は、「セキュリティの更新」 を参照してください。
GPG は Email 通信の秘密性を確保する方法の一つです。公開ネットワークで機密性の高いデータを Email で送るためと、ハードドライブ上の機密性の高いデータを保護するための両方に使用できます。

2.2. サーバーのセキュリティ

システムは、公開ネットワーク上のサーバーとして使われる際には攻撃対象となります。このため、システム管理者にとってはシステムを堅牢にし、サービスをロックダウンすることは、最重要事項になります。
特定の問題を詳細に見る前に、以下に挙げるサーバーセキュリティを強化する一般的なヒントについて概説します。
  • 最新の脅威から保護するために、すべてのサービスを最新に保つ
  • できるだけ安全なプロトコルを使う
  • できるだけマシン 1 台あたり 1 種類のネットワークサービスのみを実行する
  • 不審なアクティビティがないか、すべてのサーバーを注意深く監視する

2.2.1. TCP Wrapperおよび xinetd によるサービスのセキュア化

TCP Wrapper は、幅広いサービスにアクセス制御を提供します。SSH や Telnet、FTP といった現在のネットワークサービスのほとんどは TCP Wrapperを使用します。TCP Wrapperは、着信する要求と要求されたサービスの間の防護機能を提供します。
TCP Wrapper の利点は、追加のアクセス、ロギング、リダイレクション、リソース使用制御を提供するスーパーサーバーの xinetd と合わせて使うことで高まります。

注記

TCP Wrapper と xinetd を iptables ファイアウォールルールとともに使用して、サービスアクセス制御内に冗長性を作成するとよいでしょう。iptables コマンドを使ってファイアウォールを実装する方法の詳細情報は、「ファイアウォール」 を参照してください。
以下のサブセクションでは、各トピックについての基本的な情報があることを前提としており、特定のセキュリティオプションについてフォーカスしています。

2.2.1.1. TCP Wrapper によるセキュリティ強化

TCP Wrapper では、単にサービスへのアクセスを拒否する以上のことができます。このセクションでは、TCP Wrapperを使って接続バナーを送信し、特定ホストからの攻撃に対して警告し、ロギング機能を強化する方法を説明します。TCP Wrapper の機能と制御言語についての情報は、hosts_options man ページを参照してください。サービスに適用可能なオプションとして機能する利用可能なフラグについては、オンラインの http://linux.die.net/man/5/xinetd.conf にある xinetd.conf man ページを参照してください。
2.2.1.1.1. TCP Wrapper と接続バナー
システム管理者が警戒していることを潜在的な攻撃者に知らせるには、ユーザーがサービスに接続する際に適切なバナーを表示させるのがよい方法です。また、ユーザーに対してシステムのどの情報を表示させるかを制御することもできます。サービスに TCP Wrapper のバナーを実装するには、banner オプションを使用します。
以下の例では、vsftpd にバナーを導入します。最初にバナーファイルを作成します。これはシステム上のどこでも構いませんが、デーモンと同じ名前にする必要があります。例えば、ファイル名 /etc/banners/vsftpd には以下の行が含まれます。
220-Hello, %c 
          220-All activity on ftp.example.com is logged.
          220-Inappropriate use will result in your access privileges being removed.
%c トークンは、ユーザー名およびホスト名、またはユーザー名および IP アドレスなどの幅広いクライアント情報を提供し、接続をより威圧的なものにします。
このバナーを受信接続に表示させるには、以下の行を /etc/hosts.allow ファイルに追加します。
vsftpd : ALL : banners /etc/banners/
2.2.1.1.2. TCP Wrapper と攻撃警告
特定のホストまたはネットワークによるサーバーへの攻撃が検出された場合、TCP Wrapper は spawn 指示文を使ってそのホストまたはネットワークからのその後の攻撃について管理者に警告することができます。
以下の例では、206.182.68.0/24 ネットワークからのクラッカーがサーバーに攻撃を仕掛けようとしていることが検出されたとします。/etc/hosts.deny ファイルに以下の行を挿入すると、そのネットワークからの接続の試みが拒否され、特別ファイルにログ記録されます。
ALL : 206.182.68.0 : spawn /bin/echo `date` %c %d >> /var/log/intruder_alert
%d トークンは、攻撃者がアクセスを試みるサービス名を提供します。
接続とログインを許可するには、 spawn 指示文を /etc/hosts.allow ファイル内に置きます。

注記

spawn 指示文はどんなシェルコマンドも実行するので、特定のクライアントがサーバーに接続しようとする際に、管理者に通知したり一連のコマンドを実行したりする特別スクリプトを作成するとよいでしょう。
2.2.1.1.3. TCP Wrapper とロギングの強化
特定の種類の接続が他のものよりも懸念される場合は、severity オプションを使うと該当サービスに対するログレベルを高めることができます。
以下の例では、FTP サーバーのポート 23 (Telnet ポート) への接続はクラッカーによるものとします。これを示すために、デフォルトのフラグである info の代わりに emerg フラグをログファイルに置いて接続を拒否します。
これを実行するには、以下の行を /etc/hosts.deny に挿入します。
in.telnetd : ALL : severity emerg
これはデフォルトの authpriv ロギング機能を使用しますが、優先順位をデフォルト値の info から emerg に引き上げ、ログメッセージを直接コンソールに投稿します。

2.2.1.2. xinetd を使用したセキュリティの強化

このセクションでは、xinetd を使用してトラップサービスを設定し、特定の xinetd サービスで利用可能なリソースレベルを制御する方法にフォーカスしています。サービスに対するリソースの制限設定は、サービス拒否 (DoS) 攻撃の防止に役立ちます。利用可能なオプション一覧は、xinetd および xinetd.conf の man ページを参照してください。
2.2.1.2.1. トラップの設定
xinetd の重要な機能の一つは、ホストをグローバルの no_access リストに追加することです。このリスト上のホストは、xinetd が管理するサービスに特定の期間または xinetd が再起動するまで、接続が拒否されます。SENSOR 属性を使うとこれを実行できます。サーバー上のポートをスキャンしようとするホストをブロックするには、これが簡単な方法です。
SENSOR の設定における最初のステップでは、使用しない予定のサービスを選択します。この例では、Telnet を使います。
/etc/xinetd.d/telnet ファイルを編集して flags 行を以下のように変更します。
flags           = SENSOR
以下の行を追加します。
deny_time       = 30
これにより、当該ホストによるポートへのさらなる接続の試みを 30 分間拒否します。deny_time で利用可能な別の属性には FOREVER があり、これは実際には xinetd が再起動するまで接続を禁止します。また、NEVER は、接続を許可してログ記録します。
最後に、最終行は以下のようにします。
disable         = no
これでトラップ自体が有効になります。
SENSOR を使用して望ましくないホストからの接続を検出、停止することはよい方法ですが、マイナス面が 2 つあります。
  • ステルススキャンに対しては効果がありません。
  • SENSOR が実行中であることを攻撃者が認識している場合、特定ホストの IP アドレスを偽造し、禁止されているポートに接続することで、このホストに対するサービス拒否攻撃を仕掛けることが可能です。
2.2.1.2.2. サービスリソースの制御
xinetd のもう一つの重要な機能は、制御下にあるサービスに対するリソース制限を設定することです。
以下の指示文でこれを実行します。
  • cps = <number_of_connections> <wait_period> — 受信接続の割合を制限します。この指示文は 2 つの引数を取ります。
    • <number_of_connections> — 1 秒あたりに処理する接続数です。受信接続数がこの割合よりも高い場合、このサービスは一時的に無効になります。デフォルト値は 50 です。
    • <wait_period> — サービスが無効になった後に再度有効になるまでの秒数です。デフォルトの間隔は 10 秒です。
  • instances = <number_of_connections> — サービスへ許可される接続数の合計を指定します。この指示文は整数値もしくは UNLIMITED を受け付けます。
  • per_source = <number_of_connections> — ホスト毎に許可される接続数を指定します。この指示文は整数値もしくは UNLIMITED を受け付けます。
  • rlimit_as = <number[K|M]> — サービスが占有可能なメモリアドレス領域の量をキロバイトもしくはメガバイトで指定します。この指示文は整数値もしくは UNLIMITED を受け付けます。
  • rlimit_cpu = <number_of_seconds> — あるサービスが CPU を占有できる時間を秒数で指定します。この指示文は整数値もしくは UNLIMITED を受け付けます。
これらの指示文を使用することで、 xinetd サービスの 1 つがシステムを圧倒し、サービス拒否になることを防ぐ手助けとなります。

2.2.2. ポートマップのセキュア化

portmap サービスは、NIS やNFS などの RPC サービス用の動的なポート割り当てデーモンです。この認証メカニズムは脆弱なもので、制御対象のサービスに幅広いポートを割り当てる機能があります。このため、セキュア化は困難になります。

注記

NFSv4 は portmap を必要としなくなったので、portmap のセキュア化が影響するのは NFSv2 と NFSv3 のみです。NFSv2 もしくは NFSv3 サーバーの導入を計画する場合は、portmap が必要となり、以下のセクションが適用されます。
RPC サービスを実行している場合は、以下の基本的なルールにしたがってください。

2.2.2.1. TCP Wrapper でポートマップを保護する

ポートマップサービスにはビルトインの認証がないので、TCP Wrapper を使用して portmap サービスにアクセスするネットワークやホストを制限することが重要です。
さらに、サービスへのアクセスを制限する際には、IP アドレス のみ を使用してください。ホスト名は DNS ポイズニングやその他の方法で偽造される恐れがあるので、使用しないでください。

2.2.2.2. iptables でポートマップを保護する

portmap サービスへのアクセスをさらに制限するには、サーバーに iptables ルールを追加し、特定ネットワークへのアクセスを制限するとよいでしょう。
以下は、iptables コマンドの 2 つの例です。最初のコマンドは 192.168.0.0/24 ネットワークからポート 111 (portmap サービスが使用) への TCP 接続を許可します。2 つ目のコマンドは、ローカルホストからの同一ポートへの接続を許可します。これは、Nautilus が使用する sgi_fam サービスに必要なものです。他のパケットはすべて遮断されます。
~]# iptables -A INPUT -p tcp -s ! 192.168.0.0/24 --dport 111 -j DROP
~]# iptables -A INPUT -p tcp -s 127.0.0.1 --dport 111 -j ACCEPT
UDP トラフィックを同様に制限するには、以下のコマンドを使用します。
~]# iptables -A INPUT -p udp -s ! 192.168.0.0/24 --dport 111 -j DROP

注記

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

2.2.3. NIS のセキュア化

ネットワーク情報サービス (NIS) は ypserv と呼ばれる RPC サービスの一つで、portmap および他の関連サービスと一緒に使用することで、ドメイン内にあると主張するすべてのコンピューターに、ユーザー名やパスワード、他の機密性のある情報のマップを配布します。
NIS サーバーは、以下のものを含むいくつかのアプリケーションで構成されています。
  • /usr/sbin/rpc.yppasswddyppasswdd サービスとも呼ばれます。このデーモンを使用することで、ユーザーは NIS パスワードを変更できます。
  • /usr/sbin/rpc.ypxfrdypxfrd サービスとも呼ばれます。このデーモンは、ネットワーク上での NIS マップ転送を担当します。
  • /usr/sbin/yppush — このアプリケーションは、変更された NIS データベースを複数の NIS サーバーに伝達します。
  • /usr/sbin/ypserv — これは NIS サーバーデーモンです。
NIS は今日の基準ではあまり安全なものではありません。ホスト認証メカニズムがなく、パスワードハッシュを含むすべての情報をネットワーク上で暗号化せずに送信します。このため、NIS を使用するネットワークの設定時には、非常に注意深い作業が必要になります。さらに、NIS のデフォルト設定がもともと安全でないことで複雑性が増してしまいます。
NIS サーバーの実装を予定している場合は、「ポートマップのセキュア化」 に概説があるようにまず portmap サービスのセキュア化を図ることが推奨されます。その後に、以下のようなネットワークプラニングの問題などに対処してください。

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

NIS は機密性の高い情報を暗号化せずにネットワーク上で送信するので、ファイアウォールの背後で、またセグメント化された安全なネットワーク上で実行することが重要です。NIS 情報が安全でないネットワーク上で送信される際は、常に傍受される危険があります。ネットワークを注意深く設計することで、重大なセキュリティ侵害の防止に役立ちます。

2.2.3.2. パスワードのような NIS ドメイン名およびホスト名を使用する

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

注記

Kerberos を使用していれば、/etc/shadow ファイルは NIS マップ内に保存されません。
攻撃者による NIS マップへのアクセスをより困難にするには、o7hfawtgmhwg.domain.com のようなランダムの文字列を DNS ホスト名にします。同様に、異なる ランダムな NIS ドメイン名を作成します。これにより、攻撃者は NIS サーバーへのアクセスが非常に困難になります。

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

/var/yp/securenets ファイルが空白もしくは存在しない場合 (デフォルトインストールの後の場合のように)、NIS はすべてのネットワークをリッスンします。最初にすることのひとつは、ネットマスクとネットワークのペアをファイルに置くことで、これにより ypserv は適正なネットワークからの要求のみに応答するようになります。
以下は /var/yp/securenets ファイルからのエントリのサンプルです。
255.255.255.0     192.168.0.0

警告

/var/yp/securenets ファイルを作成せずに NIS サーバーを初回起動することは、絶対にしないでください。
このテクニックは IP スプーフィングからの保護は提供しませんが、少なくとも NIS サーバーが対応するネットワークに対して制限をかけます。

2.2.3.4. 静的ポートの割り当てと iptables ルールの使用

NIS に関連付けられているサーバーは、rpc.yppasswdd を除いて特定のポートの割り当てが可能です。このデーモンを使うと、ユーザーは自身のログインパスワードを変更できるようになります。rpc.ypxfrdypserv の 2 つの NIS サーバーデーモンにポートを割り当てると、NIS サーバーデーモンをさらに侵入者から保護するためのファイアウォールルールが作成できます。
これを実行するには、以下の行を /etc/sysconfig/network に追加します。
YPSERV_ARGS="-p 834"
YPXFRD_ARGS="-p 835"
すると、以下の iptables ルールを使ってこれらのポートでサーバーがリッスンするネットワークを強制できます。
~]# iptables -A INPUT -p ALL -s ! 192.168.0.0/24 --dport 834 -j DROP
~]# iptables -A INPUT -p ALL -s ! 192.168.0.0/24 --dport 835 -j DROP
つまり、プロトコルにかかわらず、192.168.0.0/24 ネットワークからの要求であれば、サーバーはポート 834 および 835 への接続のみを許可することになります。

注記

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

2.2.3.5. Kerberos 認証を使用する

認証に NIS を使用する際に考慮すべきことの一つは、ユーザーがマシンにログインする際は常に、/etc/shadow マップからのパスワードハッシュがネットワーク上で送信されるということです。侵入者が NIS ドメインへアクセスしてネットワークトラフィックを傍受した場合、ユーザー名とパスワードハッシュを取得できることになります。さらに時間があれば、攻撃者はパスワードクラッキングプログラムで脆弱なパスワードを推測し、ネットワーク上の有効なアカウントへのアクセスを取得できるようになります。
Kerberos は秘密鍵の暗号作成方法を使用するので、パスワードハッシュがネットワーク上で送信されることはなく、システムを大幅に安全なものとします。Kerberos についての詳細は、Managing Single Sign-On and Smart Cards を参照してください。

2.2.4. NFS のセキュア化

重要

Red Hat Enterprise Linux 6 に同梱されている NFS である NFSv4 では、「ポートマップのセキュア化」 で説明したような portmap サービスは不要となりました。 NFS トラフィックは今や全バージョンで UDP ではなく TCP を使用し、NFSv4 を使用の際はこれを必要とします。NFSv4 には RPCSEC_GSS カーネルモジュールの一部として Kerberos ユーザーおよびグループ認証が含まれています。Red Hat Enterprise Linux 6 は NFSv2 と NFSv3 をサポートしており、この両方が portmap を使用することから、portmap に関する情報も引き続き含まれています。

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

NFSv2 と NFSv3 ではこれまで、データの受け渡しは安全に行われていませんでした。今では NFS の全バージョンで Kerberos を使った通常のファイルシステム操作の認証 (およぴオプションで暗号化) ができます。NFSv4 では、すべての操作で Kerberos の使用が可能です。v2 または v3 では、ファイルロックとマウントにまだ Kerberos が使用されていません。NFSv4 使用時は、クライアントが NAT もしくはファイアウォールの背後にあるのであれば、委任はオフにすることができます。NFSv4.1 を使うことで NAT およびファイアウォールを通じた委任による操作を可能にする方法については、ストレージ管理ガイドの pNFS のセクションを参照してください。

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

/etc/fstab ファイル内での mount コマンド使用については、ストレージ管理ガイドで説明されています。セクション管理の観点からは、NFS マウントオプションは /etc/nfsmount.conf でも指定可能であることは注目に値します。これを使うと、カスタムのデフォルトオプションを設定することが可能です。
2.2.4.2.1. NFS サーバーのレビュー

警告

ファイルシステムをエクスポートする際は、全体のエクスポートのみを行なってください。ファイルシステムのサブディレクトリをエクスポートすると、セキュリティ問題につながる可能性があります。場合によってはクライアントがファイルシステムのエクスポートされた部分から抜け出し、エクスポートされていない部分に至ることもあります (exports(5) man ページのサブツリーチェックのセクションを参照)。
マウント済みファイルシステムへの書き込み可能なユーザー数を減らすためには、可能な場合は常に ro オプションを使用してファイルシステムを読み取り専用としてエクスポートしてください。rw オプションの使用は、明確に必要な場合のみとしてください。詳細は exports(5) man ページを参照してください。書き込みアクセスを許可すると、シンボリックリンク攻撃などのリスクが高まります。これには、/tmp/usr/tmp などの一時ディレクトリーが含まれます。
ディレクトリーを rw オプションでマウントする必要がある場合は、リスク低減のためにできる限り全ユーザー書き込み可能としないようにします。アプリケーションのなかにはパスワードをクリアテキストで保存したり暗号化が弱いものもあるので、ホームディレクトリーのエクスポートもリスクとみなされます。このリスクは、アプリケーションコードがレビューされ、改善されることで軽減されてきています。SSH キーにパスワードを設定しないユーザーもいるので、ホームディレクトリーがリスクをもたらすことになります。パスワードや Kerberos の使用を強制することで、このリスクは緩和されます。
エクスポートはアクセスを必要とするクライアントのみに制限してください。NFS サーバーで howmount -e コマンドを使用して、サーバーが何をエクスポートしているかを確認します。特に必要でないものはエクスポートしないでください。
no_root_squash オプションを使用しないでください。また、既存のインストールのレビューを行い、これが使用されていないことを確認してください。詳細は no_root_squash オプションは使用しない」 を参照してください。
secure オプションはサーバー側のエクスポートオプションで、予約済み ポートへのエクスポートを制限する際に使用します。デフォルトでは、サーバーは 予約済み ポート (ポート番号 1024 未満のもの) からのクライアント通信のみを許可します。これは、クライアントが通常これらのポートの使用を許可するのは 信頼できる コード (カーネル内の NFS クライアントなど) のみだったためです。しかし、多くのネットワークではクライアント上で root になるのは難しいことではないので、予約済みポートからの通信が権限を伴うものであると仮定するのは安全ではありません。このため、予約済みポートへの制限は限定的な価値しかありません。Kerberos やファイアウォール、エクスポートを特定のクライアントに制限するという方法を信頼する方がより安全です。
ほとんどのクライアントでは、可能な場合はまだ予約済みポートを使用しています。しかし、予約済みポートは限定的なリソースなので、クライアント (特に NFS マウント数が多いもの) はより高い番号のポートを使う選択をする場合もあります。Linux クライアントは、noresvport マウントオプションを使用してこれを行うことができます。エクスポートでこれを許可したい場合は、insecure エクスポートオプションで行うことができます。
ユーザーがサーバーにログインできないようにしておくのは、よい方法です。上記の NFS サーバー設定を確認する間に、誰および何がサーバーにアクセス可能かを確認してください。
2.2.4.2.2. NFS クライアントのレビュー
setuid プログラムを使用できないようにするには、nosuid オプションを使用します。nosuid オプションは set-user-identifier または set-group-identifier ビットを無効にします。これにより、リモートユーザーが setuid プログラムを実行してより高い権限を取得することを防ぎます。このオプションは、クライアントおよびサーバー側で使用してください。
noexec オプションはクライアント上のすべての実行可能ファイルを無効にします。共有しているファイルシステムにあるファイルをユーザーが不注意で実行しないようにこのオプションを使用します。nosuid および noexec オプションは、ほとんどのファイルシステムの標準オプションです。
nodev オプションを使うと、クライアントが device-files をハードウェアデバイスとして処理することを防ぎます。
resvport オプションはクライアント側のマウントオプションで、secure はこれに対応するサーバー側のエクスポートオプションです (上記の説明を参照)。これは「予約済みポート」への通信を制限します。予約済みまたは「よく知られた」ポートは、root ユーザーなどの権限のあるユーザーやプロセス用に確保されています。このオプションを設定すると、クライアントが予約済みソースのポートを使ってサーバーと通信するようになります。
NFS の全バージョンですでに Kerberos 認証に対応しています。これを有効にするマウントオプションは、次の通りです。sec=krb5
NFSv4 は、整合性には krb5i を、プライバシー保護には krb5p を使用して Kerberos によるマウントをサポートします。これらは sec=krb5 でのマウント時に使用されますが、NFS サーバー上での設定が必要です。詳細はエクスポートに関する man ページ (man 5 exports) を参照してください。
NFS man ページ (man 5 nfs) には SECURITY CONSIDERATIONS セクションがあり、ここでは NFSv4 のセキュリティ強化の説明と NFS の特定のマウントオプションすべてが含まれています。

2.2.4.3. 構文エラーに注意

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

2.2.4.4. no_root_squash オプションは使用しない

デフォルトで NFS 共有は、root ユーザーを権限のないユーザーアカウントである nfsnobody ユーザーに変更します。これにより、root で作成された全ファイルの所有者は nfsnobody に変更されます。この変更で setuid ビットが設定されたプログラムのアップロードが防止されます。
no_root_squash を使用すると、リモートの root ユーザーは共有ファイルシステム上のどのファイルも変更できるようになり、トロイの木馬に感染したアプリケーションを他のユーザーが間違って実行できる状態にしてしまいます。

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

NFS に使用されるポートは rpcbind が動的に割り当てますが、ファイアウォールルールの作成時に問題を起こす恐れがあります。このプロセスを簡素化するには、/etc/sysconfig/nfs ファイルを使って使用するポートを特定します。
  • MOUNTD_PORT — mountd (rpc.mountd) 用の TCP および UDP ポート
  • STATD_PORT — status (rpc.statd) 用の TCP および UDP ポート
  • LOCKD_TCPPORT — nlockmgr (rpc.lockd) 用 TCP ポート
  • LOCKD_UDPPORT — nlockmgr (rpc.lockd) 用 UDP ポート
指定されたポート番号は、他のサービスが使用してはいけません。ポート番号の指定と TCP および UDP ポート 2049 (NFS) を許可するようにファイアウォールを設定してください。
NFS サーバーで rpcinfo -p コマンドを実行し、どのポートと RPC プログラムが使用されているかを確認します。

2.2.5. Apache HTTP サーバーのセキュア化

Apache HTTP サーバーは Red Hat Enterprise Linux に同梱されているサービスのなかで最も安定性があり安全なものの一つです。Apache HTTP サーバーを安全にするには多くのオプションとテクニックがあり、ここで詳述するには多すぎるほどです。以下のセクションでは、Apache HTTP サーバー稼働時に実行できる優れた方法を簡単に説明します。
スクリプトを実稼働環境で実行する 前に、常にそのシステムがシステム上で意図したとおりに稼働していることを確認してください。また、スクリプトもしくは CGI を含むディレクトリーに書き込みパーミッションを持っているのは root ユーザーのみであることを確認してください。これを行うには、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 Full (デフォルトのオプション) — (OS の種類や使用されるモジュールなど) 利用可能なすべての情報を提供します。例えば、
    Apache/2.0.41 (Unix) PHP/4.2.2 MyMod/1.2
  • ServerTokens Prod または ServerTokens ProductOnly — 以下の情報を提供します。
    Apache
  • ServerTokens Major — 以下の情報を提供します。
    Apache/2
    
  • ServerTokens Minor — 以下の情報を提供します。
    Apache/2.0
  • ServerTokens Min または ServerTokens Minimal — 以下の情報を提供します。
    Apache/2.0.41
  • ServerTokens OS — 以下の情報を提供します。
    Apache/2.0.41 (Unix)
潜在的な攻撃者がユーザーのシステムについて価値ある情報を取得できないないようにするには、ServerTokens Prod の使用が推奨されます。

重要

IncludesNoExec 指示文は削除しないでください。デフォルトでは、Server-Side Includes (SSI) モジュールはコマンドの実行ができません。絶対に必要な場合以外は、この設定を変更しないことが推奨されます。変更すると、攻撃者がシステム上でコマンドを実行できるようになる可能性があります。

httpd モジュールの削除

特定のシナリオでは、特定の httpd モジュールを削除して HTTP サーバーの機能を制限した方がよい場合もあります。これを行うには、/etc/httpd/conf/httpd.conf ファイルで削除したいモジュールを読み込み行全体をコメントアウトするだけです。例えば、プロキシモジュールを削除するには、以下の行の先頭にハッシュ記号を加えてコメントアウトします。
#LoadModule proxy_module modules/mod_proxy.so
/etc/httpd/conf.d/ ディレクトリーにもモジュールの読み込みに使われる設定ファイルが含まれていることに注意してください。

httpd および SELinux

Apache HTTP サーバーおよび SELinux に関する情報は、Managing Confined Services Guide を参照してください。

2.2.6. FTP のセキュア化

File Transfer Protocol (FTP) は旧式の TCP プロトコルで、ネットワーク上でファイル転送するために設計されています。ユーザー認証を含むサーバーとのトランザクションがすべて暗号化されないので、安全でないプロトコルとみなされ、慎重に設定する必要があります。
Red Hat Enterprise Linux は以下の 3 つの FTP サーバーを提供します。
  • gssftpd — Kerberos 対応の xinetd ベースの FTP デーモンで、ネットワーク上で認証情報を送信することはしません。
  • Red Hat Content Accelerator (tux) — FTP 機能のあるカーネル空間の Web サーバーです。
  • vsftpd — スタンドアロンでセキュリティ重視の FTP サービス実装です。
以下のセキュリティガイドラインは vsftpd FTP サービス設定のためのものです。

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

ユーザー名とパスワードの送信前に、すべてのユーザーにグリーティングバナーが示されます。デフォルトでは、このバナーにはシステムの脆弱性を特定しようとしているクラッカーに有益なバージョン情報が含まれています。
vsftpd のグリーティングバナーを変更するには、以下の指示文を /etc/vsftpd/vsftpd.conf ファイルに追加します。
ftpd_banner=<insert_greeting_here>
上記の指示文の <insert_greeting_here> をグリーティングメッセージのテキストで置き換えます。
複数行のバナーの場合、バナーファイルの使用が最善の方法となります。複数のバナーの管理を簡素化するには、/etc/banners/ という新規ディレクトリにすべてのバナーを格納します。この例では、FTP 接続のバナーファイルは、/etc/banners/ftp.msg となります。以下はこのファイルのサンプルになります。
######### Hello, all activity on ftp.example.com is logged. #########

注記

「TCP Wrapper と接続バナー」 にあるように、各行を 220 で始める必要はありません。
vsftpd でこのバナーを参照するようにするには、以下の指示文を /etc/vsftpd/vsftpd.conf ファイルに追加します。
banner_file=/etc/banners/ftp.msg
「TCP Wrapper と接続バナー」 にあるように、 TCP Wrapper を使って着信接続に新たなバナーを送信することも可能です。

2.2.6.2. 匿名のアクセス

/var/ftp/ ディレクトリーが存在すると、匿名アカウントがアクティベートされます。
このディレクトリーを作成する最も簡単な方法は、vsftpd パッケージをインストールすることです。このパッケージは、匿名ユーザー向けのディレクトリーツリーを確立し、匿名ユーザーによる読み取り専用のパーミッションをディレクトリーに設定します。
デフォルトでは、匿名ユーザーはどのディレクトリーにも書き込みできません。

警告

FTP サーバーへの匿名アクセスを有効にする場合は、機密性の高いデータの保存場所に注意してください。

手順2.1 匿名のアップロード

  1. 匿名ユーザーによるファイルのアップロードを許可する場合は、/var/ftp/pub/ ディレクトリー内に書き込み専用のディレクトリーを作成することが推奨されます。/upload/ という名前のディレクトリーを作成するには、以下のコマンドを root で実行します。
    ~]# mkdir /var/ftp/pub/upload
  2. 次に、パーミッションを変更して、匿名ユーザーがディレクトリーのコンテンツを閲覧できないようにします。
    ~]# 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

    注記

    管理者が匿名ユーザーによるディレクトリー内での書き込みや読み取りを許可すると、そのサーバーが盗難ソフトウェアのレポジトリになってしまう場合が多くあります。
  3. vsftpd で、以下の行を /etc/vsftpd/vsftpd.conf ファイルに追加します。
    anon_upload_enable=YES
  4. Red Hat Enterprise Linux では、SELinux はデフォルトで強制モードで実行されます。このため、vsftpd でのファイルのアップロードを可能にするには、allow_ftpd_anon_write ブール値を有効にする必要があります。
    ~]# setsebool -P allow_ftpd_anon_write=1
  5. /upload/ ディレクトリーおよびそのファイルを public_content_rw_t の SELinux コンテキストでラベル付けします。
    ~]# semanage fcontext -a -t public_content_rw_t '/var/ftp/pub/upload(/.*)'

    注記

    semanage ユーティリティーは policycoreutils-python パッケージで提供されますが、これはデフォルトではインストールされません。これをインストールするには、root で以下のコマンドを実行します。
    ~]# yum install policycoreutils-python
  6. restorecon ユーティリティーを使って /upload/ およびそのファイルのタイプを変更します。
    ~]# restorecon -R -v /var/ftp/pub/upload
    これでディレクトリーが public_content_rw_t で適切にレベル付けされ、強制モードの SELinux で匿名ユーザーがファイルをアップロードできるようになりました。
    ~]$ ls -dZ /var/ftp/pub/upload
    drwx-wx---. root root unconfined_u:object_r:public_content_t:s0 /var/ftp/pub/upload/
    
    SELinux の使用に関する詳細情報は、Security-Enhanced Linux ユーザーガイド および 制限のあるサービスの管理 の各ガイドを参照してください。

2.2.6.3. ユーザーアカウント

FTP は安全でないネットワーク上で認証用のユーザー名とパスワードを暗号化せずに送信するので、ユーザーアカウントからサーバーへのシステムユーザーアクセスを拒否することはよい方法です。
vsftpd のすべてのユーザーアカウントを無効にするには、以下の指示文を /etc/vsftpd/vsftpd.conf に追加します。
local_enable=NO
2.2.6.3.1. ユーザーアカウントの制限
root ユーザーや sudo 権限を持つユーザーなど、特定のアカウントや特定のアカウントグループの FTP アクセスを無効にする最も簡単な方法は、「Root アクセスの拒否」 にあるように PAM リストファイルを使用することです。vsftpd の PAM 設定ファイルは、/etc/pam.d/vsftpd です。
また、各サービス内で直接ユーザーアカウントを無効にすることもできます。
vsftpd で特定のユーザーアカウントを無効にするには、ユーザー名を /etc/vsftpd/ftpusers に追加します。

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

「TCP Wrapper によるセキュリティ強化」 にあるように、TCP Wrapper を使用して各 FTP デーモンへのアクセスを制御します。

2.2.7. Postfix のセキュア化

Postfix は メール転送エージェント (MTA) で、他の MTA や Email クライアント、配信エージェント間で電子メッセージを配信するために Simple Mail Transfer Protocol (SMTP) を使用します。多くの MTA には MTA 間のトラフィックを暗号化する機能がありますが、ほとんど使用されていないので、公開ネットワーク上での Email 送信はもともと安全でない通信方法とみなされています。
Postfix サーバーの実装を計画している場合は、以下の問題に対処することが推奨されます。

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

Email の性質上、攻撃者が本気になるとサーバーに大量のメールを送信し、サービス拒否を発生させることが簡単にできます。/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 コマンドを拒否します。空き領域の最低限度をより大きくするように指定するには、queue_minfree の値が少なくとも message_size_limit の 1.5 倍になるように指定します。デフォルトの queue_minfree 値は 0 です。
  • header_size_limit — メッセージヘッダー保存に使用するメモリの最大バイト数です。ヘッダーサイズがこの制限を超える場合は、超過分が廃棄されます。デフォルト値は 102400 です。
  • message_size_limit — メッセージの最大バイト数で、これにはエンベロープ情報も含まれます。デフォルト値は 10240000 です。

2.2.7.2. NFS と Postfix

メールスプールディレクトリーの /var/spool/postfix/ を NFS 共有ボリュームに置くことは絶対にしないでください。
NFSv2 と NFSv3 ではユーザー ID とグループ ID の制御を維持しないので、2 人以上のユーザーが同一 UID を持つ可能性があり、それぞれがお互いのメールを受信、閲覧してしまう可能性があります。

注記

Kerberos を使用する NFSv4 ではこういうことはありません。これは SECRPC_GSS カーネルモジュールが UID ベースの認証を使用しないためです。ただし、それでも NFS 共有ボリュームにメールスプールディレクトリーを 置かない 方がよいと考えられます。

2.2.7.3. メール専用ユーザー

ローカルユーザーによる Postfix サーバーの悪用を避けるには、メールユーザーが Email プログラムを使用して Postfix サーバーにアクセスするだけにするのが最善の方法です。メールサーバー上のシェルアカウントを許可せず、/etc/passwd ファイル内のすべてのユーザーシェルを /sbin/nologin に設定します (root ユーザーは例外とする場合もある)。

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

デフォルトでは、Postfix はローカルのループバックアドレスのみをリッスンするように設定されています。これは、/etc/postfix/main.cf ファイルを表示すると確認できます。
/etc/postfix/main.cf ファイルを閲覧して、以下の inet_interfaces 行のみが表示されることを確認してください。
inet_interfaces = localhost
これにより、Postfix は ネットワークからではなく、(cron ジョブレポートなどの) ローカルシステムからのメールメッセージのみを受信することが確認できます。これがデフォルト設定で、Postfix をネットワーク攻撃から守ります。
ローカルホストの制限を取り除き、Postfix がすべてのインターフェイスをリッスンできるようにするには、inet_interfaces = all と設定します。

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

Postfix の Red Hat Enterprise Linux バージョンは、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 実装と通信します。後者の方法は、PostfixDovecot アプリケーションが別個のマシンで実行中の場合にのみ、必要となります。UNIX ドメインソケットの方がよりすぐれたプライバシーを提供するので、本ガイドではこちらを推奨しています。
PostfixDovecot SASL 実装を使用するように指示するには、両方のアプリケーションで多くの設定変更が必要になります。以下の手順にしたがってください。
Dovecot のセットアップ
  1. Dovecot のメインの設定ファイルである /etc/dovecot/conf.d/10-master.conf に以下の行を含めます (デフォルトの設定ファイルには、ほとんどの関連セクションがすでに記載されており、これらの行はコメント解除するだけです)。
    service auth {
      unix_listener /var/spool/postfix/private/auth {
        mode = 0660
        user = postfix
        group = postfix
      }
    }
    上記の例では、PostfixDovecot の通信に UNIX ドメインソケットを使用することを仮定しています。また、Postfix SMTP サーバーの設定はデフォルトとしています。この設定では、メールキューが /var/spool/postfix/ ディレクトリーに配置され、アプリケーションは postfix のユーザーおよびグループで実行されることになります。この方法では、読み取りおよび書き込み許可は、postfix ユーザーおよびグループに限定されます。
    別の方法では、以下の設定を使うと DovecotTCP 経由で Postfix 認証リクエストをリッスンするようになります。
    service auth {
      inet_listener {
        port = 12345
      }
    }
    上記の例では、12345 を実際に使用するポート番号に置き換えます。
  2. /etc/dovecot/conf.d/10-auth.conf 設定ファイルを編集して、DovecotPostfix SMTP サーバーに plain および login の認証メカニズムを提供するようにします。
    auth_mechanisms = plain login
Postfix のセットアップ
Postfix の場合、メインの設定ファイルである /etc/postfix/main.cf を修正するだけです。以下の設定指示文を追加もしくは編集します。
  1. Postfix SMTP サーバーの SMTP 認証を有効にします。
    smtpd_sasl_auth_enable = yes
  2. Postfix が SMTP 認証に Dovecot SASL 実装を使用するように指示します。
    smtpd_sasl_type = dovecot
  3. Postfix キューディレクトリーの認証相対パスを提供します (相対パスを使用することで、Postfix サーバーが chroot で稼働しているかどうかにかかわらず、この設定が確実に機能するようになります)。
    smtpd_sasl_path = private/auth
    この手順では、PostfixDovecot の通信に UNIX ドメインソケットを使用することを仮定しています。通信に TCP ソケットを使用する場合で、Postfix が 別のマシンにある Dovecot を探すように設定するには、以下のような設定値を使用します。
    smtpd_sasl_path = inet:127.0.0.1:12345
    上記の例では、127.0.0.1Dovecot マシンの IP アドレスに、12345Dovecot/etc/dovecot/conf.d/10-master.conf 設定ファイルで指定されているポート番号に置き換えます。
  4. 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 を参照してください。
その他のリソース
以下のオンラインのリソースでは、SASL による Postfix SMTP 認証の設定に便利な追加情報が提供されています。

2.2.8. Sendmail のセキュア化

Sendmail は メール転送エージェント (MTA) で、他の MTA や Email クライアント、配信エージェント間で電子メッセージを配信するために Simple Mail Transfer Protocol (SMTP) を使用します。多くの MTA には MTA 間のトラフィックを暗号化する機能がありますが、ほとんど使用されていないので、公開ネットワーク上での Email 送信はもともと安全でない通信方法とみなされています。
Sendmail サーバーの実装を計画している場合は、以下の問題に対処することが推奨されます。

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

Email の性質上、攻撃者が本気になるとサーバーに大量のメールを送信し、サービス拒否を発生させることが簡単にできます。/etc/mail/sendmail.mc の以下の指示文に制限を設定すると、このような攻撃の有効性が制限されます。
  • confCONNECTION_RATE_THROTTLE — サーバーが 1 秒当たりに受信できる接続数です。デフォルトでは、Sendmail は接続数を制限しません。制限が設定され、その数に達した場合は、新たな接続は遅延します。
  • confMAX_DAEMON_CHILDREN — サーバーが生成する子プロセスの最大数です。デフォルトでは、Sendmail は子プロセス数を制限しません。制限が設定され、その数に達した場合は、新たな接続は遅延します。
  • confMIN_FREE_BLOCKS — サーバーがメールを受信するために必要な利用可能空きブロックの最低数です。デフォルトは 100 ブロックです。
  • confMAX_HEADERS_LENGTH — 受信可能なメッセージヘッダーの最大サイズ (バイト単位) です。
  • confMAX_MESSAGE_SIZE — 受信可能な単一メッセージの最大サイズ (バイト単位) です。

2.2.8.2. NFS と Sendmail

メールスプールディレクトリー /var/spool/mail/ を NFS 共有ボリュームに配置しないでください。NFSv2 と NFSv3 ではユーザー ID とグループ ID の制御を維持しないので、2 人以上のユーザーが同一 UID を持つ可能性があり、それぞれがお互いのメールを受信、閲覧してしまう可能性があります。

注記

Kerberos を使用する NFSv4 ではこういうことはありません。これは SECRPC_GSS カーネルモジュールが UID ベースの認証を使用しないためです。ただし、それでも NFS 共有ボリュームにメールスプールディレクトリーを 置かない 方がよいと考えられます。

2.2.8.3. メール専用ユーザー

ローカルユーザーによる Sendmail サーバーの悪用を避けるには、メールユーザーが Email プログラムを使用して Sendmail サーバーにアクセスするのみするのが最善の方法です。メールサーバー上のシェルアカウントを許可せず、/etc/passwd ファイル内のすべてのユーザーシェルを /sbin/nologin に設定します (root ユーザーは例外とする場合もある)。

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

デフォルトでは、Sendmail はローカルのループバックアドレスのみをリッスンするように設定されています。これは、/etc/mail/sendmail.mc ファイルを表示して、以下の行が表示されることで確認できます。
DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl
これにより、Sendmail は ネットワークからではなく、(cron ジョブレポートなどの) ローカルシステムからのメールメッセージのみを受信することが確認できます。これがデフォルト設定で、Sendmail をネットワーク攻撃から守ります。
ローカルホストの制限を取り除くには、Addr=127.0.0.1 の文字列を削除する必要があります。Sendmail の設定を変更するにはまず sendmail-cf パッケージをインストールし、次に .mc ファイルを編集して /etc/mail/make を実行します。最後に sendmail を再起動します。.cf 設定ファイルが再生成されます。設定ファイルが自動的に再生成されるようにするには、システムクロックが正確で機能しており、これらのアクションの間にシステムクロックの時間のシフトがないようにする必要があります。

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

ポートを必要以上に開くとシステムの攻撃対象領域を増やすことになるので、避けるべきです。システムがサービスを開始した後で予期しないポートがリスニング状態になっている場合は、侵入の形跡である可能性があり、調査が必要になります。
root でコンソールから以下のコマンドを実行して、ネットワークからの接続をリッスンしているポートを判断します。
~]# netstat -tanp | grep LISTEN
tcp        0      0 0.0.0.0:45876               0.0.0.0:*                   LISTEN      1193/rpc.statd      
tcp        0      0 192.168.122.1:53            0.0.0.0:*                   LISTEN      1241/dnsmasq        
tcp        0      0 127.0.0.1:631               0.0.0.0:*                   LISTEN      1783/cupsd          
tcp        0      0 127.0.0.1:25                0.0.0.0:*                   LISTEN      7696/sendmail       
tcp        0      0 0.0.0.0:111                 0.0.0.0:*                   LISTEN      1167/rpcbind        
tcp        0      0 127.0.0.1:30003             0.0.0.0:*                   LISTEN      1118/tcsd           
tcp        0      0 :::631                      :::*                        LISTEN      1/init              
tcp        0      0 :::35018                    :::*                        LISTEN      1193/rpc.statd      
tcp        0      0 :::111                      :::*                        LISTEN      1167/rpcbind
システムで必要なサービスをコマンドの出力で確認して、特に必要でないものや権限が与えられていないものをオフにしてから、再度チェックを実行します。次に、ネットワーク経由で最初のシステムに接続している別のシステムから nmap を使用して、外部チェックを行います。これは、iptables のルールの確認に使用できます。外部システムから netstat 出力で表示されているすべての IP アドレス (localhost 127.0.0.0 または ::1 レンジを除く) をスキャンします。IPv6 のスキャンには -6 オプションを使用します。詳細は man nmap(1) を参照してください。
以下は、ネットワークからの TCP 接続をリッスンしているポートを判断するために、別のシステムのコンソールから発行するコマンドの例です。
~]# nmap -sT -O 192.168.122.1
詳細情報は、netstat(8)nmap(1)、および services(5) の man ページを参照してください。

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

ソースルーティングはインターネットプロトコルメカニズムで、IP パケットがアドレス一覧の情報を持ち運べるようにします。このアドレスは、パケットが通過する必要のあるパスをルーターに知らせるものです。ルートが移動する際にホップを記録するオプションもあります。「ルート記録」と呼ばれるホップの記録は、宛先にソースまでの帰りのパスを提供します。これによりソースは (つまり送信ホスト)、すべてもしくは一部のルーターのルーティングテーブルを無視して、ルートを厳密もしくは緩やかに特定することができます。これによりユーザーは、不正目的でネットワークトラフィックをリダイレクトすることが可能になります。このため、ソースベースのルーティングは無効にする必要があります。
accept_source_route オプションを使用すると、ネットワークインターフェイスが 厳密なソースルート (SSR) もしくは 緩やかなソースルーティング (LSR) オプションセットのあるパケットを受け付けるようになります。ソースルーティングパケットの受け付けは 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
IPv4 リダイレクトパケットの送信を無効にできるのは指示文のみです。IPv4 と IPv6 の差異を生み出している IPv6 Node Requirements の説明については、RFC4294 を参照してください。
設定を永続的なものにするには、/etc/sysctl.conf に追加する必要があります。
詳細は sysctl(8) の man ページを参照してください。ソースベースのルーティングおよびそのバリエーションに関連するインターネットオプションの説明については、RFC791 を参照してください。

警告

イーサネットネットワークは、ARP や MAC アドレススプーフィング、権限のない DHCP サーバー、IPv6 ルーターまたは近隣アドバタイズメントといったトラフィックをリダイレクトする新たな方法を提供します。さらに、ユニキャストトラフィックはブロードキャストの場合もたまにあり、情報の漏洩を引き起こします。これらの脆弱性は、ネットワークオペレーター導入する特定の対策によってのみ、対処可能になります。ホストベースの対応策の有効性は、完全なものではありません。

2.2.11. 逆方向パス転送

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

注記

(Red Hat Enterprise Linux 5 とは異なり) Red Hat Enterprise Linux 6 はデフォルトで厳密な逆方向パス転送を使用します。Red Hat Enterprise Linux 6 は、RFC 3704 の Ingress Filtering for Multihomed Networks からの厳密な逆方向パスに関する推奨事項にしたがっています。現在これが適用されるのは、Red Hat Enterprise Linux 6 の IPv4 のみです。

警告

転送が有効になっていれば、(iptables ルールなど) ソースアドレス確認に他の方法がある場合にのみ、逆方向パス転送を無効にしてください。
rp_filter
逆方向パス転送は rp_filter 指示文で有効にします。rp_filter オプションは、3 つのモードから 1 つを選択するようにカーネルに指示します。
デフォルト動作の設定時には以下の形式になります。
~]# /sbin/sysctl -w net.ipv4.conf.default.rp_filter=INTEGER
ここでの INTEGER は、以下のいずれかになります。
  • 0 — ソース確認なし
  • 1 — RFC 3704 で定義された厳密モード
  • 2 — RFC 3704 で定義された緩やかなモード
この設定はネットワークインターフェイスごとに net.ipv4.interface.rp_filter を使って無効にすることが可能です。これらの設定を再起動後も維持するには、/etc/sysctl.conf ファイルを修正します。

2.2.11.1. その他のリソース

以下のリソースでは、逆方向パス転送について詳細な説明が提供されています。
  • インストール済みドキュメンテーション
    usr/share/doc/kernel-doc-version/Documentation/networking/ip-sysctl.txt — このファイルには /proc/sys/net/ipv4/ ディレクトリーで使用可能なファイルおよびオプションの完全一覧が含まれています。
  • 便利なウェブサイト
    https://access.redhat.com/knowledge/solutions/53031rp_filterについての Red Hat ナレッジベースの記事。
    Ingress Filtering for Multihomed Networks の説明については、RFC 3704 を参照してください。

2.3. シングルサインオン (SSO)

Red Hat Enterprise Linux の SSO 機能は、Red Hat Enterprise Linux デスクトップのユーザーがパスワードを入力する回数を減らします。複数の主要なアプリケーションで同一の基本的認証および承認メカニズムを活用することで、ユーザーがログイン画面から Red Hat Enterprise Linux にログインし、パスワードを再入力せずにすむようになっています。これらアプリケーションの詳細は、以下で説明しています。
プラグ可能な認証モジュールについての詳細情報は、Red  Hat Enterprise Linux 6 Managing Single Sign-On and Smart Cards ガイドを参照してください。

2.4. PAM (プラグ可能な認証モジュール)

プラグ可能な認証モジュールは、認証とセキュリティ用の一般的なフレームワークです。Kerberos やスマートカードなどの Red Hat Enterprise Linux のシングルサインオンの方法は、どちらもこの基本的な PAM 設定に依存しています。
プラグ可能な認証モジュールについての詳細情報は、Red  Hat Enterprise Linux 6 Managing Single Sign-On and Smart Cards ガイドの該当する章を参照してください。

2.5. Kerberos

ネットワーク内でのシステムのセキュリティと完全性を維持することは非常に重要であり、この対象となるのはすべてのユーザー、アプリケーション、サービスおよびサーバーです。このタスクを実行するには、ネットワーク上で実行されているすべてのサービスやそれらのサービスがどのように使用されているかを把握していることが必要です。このセキュリティ維持の中心的なタスクには、アプリケーションやサービスへのアクセスを維持し、そのアクセスを実行することが含まれます。
Kerberos は、ユーザーとマシンの両方がネットワークに対して自らを識別し、管理者が設定した領域とサービスへのアクセス (定義済みの制限されたアクセス) を得られる仕組みを提供します。Kerberos はエンティティ (ユーザーおよびマシンなど) の ID を検証してそれらを認証するほか、外部の人間のアクセス、使用または改ざんを防ぐための認証データの保護も行います。
プラグ可能な認証モジュールについての詳細情報は、Red  Hat Enterprise Linux 6 Managing Single Sign-On and Smart Cards ガイドの該当する章を参照してください。

2.6. TCP Wrapper と xinetd

ネットワークサービスへのアクセス制御は、サーバー管理者にとって最も重要なセキュリティ関連のタスクのひとつです。Red Hat Enterprise Linux は、このためにいくつかのツールを提供しています。例えば、iptables ベースのファイアウォールは、カーネルのネットワークスタック内の不要なネットワークパケットを除去します。それを利用するネットワークサービスについては、TCP Wrapper はどのホストが「ラップされた」ネットワークサービスに接続許可または拒否されるかを定義することで、新たな保護層を追加します。このようにラップされたネットワークサービスの 1 つが xinetd スーパーサーバーです。このサービスは、ネットワークサービスのサブセットへの接続を制御し、アクセス制御を改善するので、スーパーサーバーと呼ばれています。
図2.4「ネットワークサービスへのアクセス制御」は、ネットワークサービスを保護するためにこれらのツールがどのように連動するかを示す基本的な図です。
ネットワークサービスへのアクセス制御

図2.4 ネットワークサービスへのアクセス制御

iptables を使ったファイアウォールの使用についての詳細情報は、「IPTables」 を参照してください。

2.6.1. TCP Wrapper

TCP Wrapper パッケージ (tcp_wrapperstcp_wrappers-libs) はデフォルトでインストールされ、ネットワークサービスに対するホストベースのアクセス制御を提供します。パッケージ内の最も重要なコンポーネントは /lib/libwrap.so または /lib64/libwrap.so ライブラリです。一般的に言うと、TCP でラップしたサービスとは libwrap.so ライブラリに対してコンパイルされたものです。
TCP でラップされたサービスへの接続を試行する際には、クライアントが接続を許可されるかどうかを決定するために、サービスはホストのアクセスファイル (/etc/hosts.allow および /etc/hosts.deny) をまず参照します。多くの場合、サービスは、要求しているクライアントと要求されたサービスの名前を /var/log/secure または /var/log/messages に書き込むために、syslog デーモン (syslogd) を使用します。
クライアントが接続を許可されると、TCP Wrapper は要求されたサービスへの接続制御を解放し、それ以降はクライアントとサーバー間の通信に介入しません。
アクセス制御とロギング以外にも、TCP Wrapper は、要求されたネットワークサービスへの接続制御の拒否や開放を行う前に、クライアントとやりとりするためのコマンドを実行できます。
TCP Wrapper はサーバー管理者の数多くのセキュリティツールに加わる重要なツールになるので、Red Hat Enterprise Linux 内のほとんどのネットワークサービスは libwrap.so ライブラリにリンクされています。これらのアプリケーションには、/usr/sbin/sshd/usr/sbin/sendmail、および /usr/sbin/xinetd などがあります。

注記

ネットワークサービスのバイナリが libwrap.so にリンクされていることを確認するには、root ユーザーとして以下のコマンドを入力します。
ldd <binary-name> | grep libwrap
<binary-name> をネットワークサービスのバイナリの名前で置き換えます。コマンドが何も出力せずにそのままプロンプトに戻る場合、ネットワークサービスは libwrap.so にリンクされていません
以下の例は /usr/sbin/sshdlibwrap.so にリンクしていることを示しています。
~]# ldd /usr/sbin/sshd | grep libwrap
        libwrap.so.0 => /lib/libwrap.so.0 (0x00655000)

2.6.1.1. TCP Wrapper の利点

TCP Wrapper は他のネットワークサービス制御にはない、以下の利点を提供します。
  • クライアントとラップされたネットワークサービス双方への透過性 — 接続しているクライアントとラップされたネットワークサービスは共に TCP Wrapper が使用されていることを認識しません。正当なユーザーはログに記録されて要求したサービスに接続される一方、禁止されたクライアントからの接続は失敗します。
  • 複数プロトコルの一元管理 — TCP Wrapper は、保護対象のネットワークサービスとは独立して動作し、数多くのサーバーアプリケーションがアクセス制御設定ファイルの共通セットを共有してよりシンプルな管理を行えるようにします。

2.6.2. TCP Wrapper の設定ファイル

クライアントがサービスへの接続を許可されるかを決定するために、TCP Wrapper は、一般的にホストアクセス (hosts access) ファイルと呼ばれる、以下の 2 つのファイルを参照します。
  • /etc/hosts.allow
  • /etc/hosts.deny
TCP でラップされたサービスがクライアントの要求を受け取ると、以下の手順が実行されます。
  1. /etc/hosts.allow を参照します。 — TCP でラップされたサービスは /etc/hosts.allow ファイルを順番に解析し、そのサービスに指定された最初のルールを適用します。マッチするルールを見つけると、接続を許可し、見つからなければ、次のステップに進みます。
  2. /etc/hosts.denyを参照します。 — TCP でラップされたサービスは /etc/hosts.deny ファイルを順番に解析します。マッチするルールを見つけると、接続を拒否し、見つからなければ、サービスへのアクセスを許可します。
TCP Wrapper を使ってネットワークサービスを保護する際に考慮する重要なポイントは以下の通りです。
  • hosts.allow にあるアクセスルールが最初に適用されるので、それらのルールが hosts.deny で指定されたルールよりも優先されます。そのため、サービスへのアクセスが hosts.allow で許可されると、hosts.deny にある同じサービスへのアクセス拒否ルールは無視されます。
  • 各ファイルにあるルールは上から下に読み込まれ、指定されたサービスに最初にマッチするルールのみが適用されます。ルールの順序は極めて重要です。
  • サービスについてのルールがどのファイルにも見つからないか、またはいずれのファイルも存在しなければ、サービスへのアクセスは許可されます。
  • TCP でラップされたサービスは、ホストのアクセスファイルからのルールをキャッシュしません。そのため、hosts.allowhosts.deny のすべての変更は、ネットワークサービスを再起動しなくても直ちに有効になります。

警告

ホストのアクセスファイルの最後の行が改行文字 (Enter キーを押して作成される)でなければ、ファイルにある最後のルールは失敗して、エラーが /var/log/messages または /var/log/secure のどちらかにログ記録されます。バックスラッシュ文字を使用しない、複数行にわたるルールについても同様です。以下の例は、これらのいずれかの状況によるルールの失敗を示す、ログメッセージの関連部分を示しています。
warning: /etc/hosts.allow, line 20: missing newline or line too long

2.6.2.1. アクセスルールのフォーマット

/etc/hosts.allow/etc/hosts.deny のフォーマットは同じです。 各ルールはそれぞれの行に置かれる必要があります。空行またはハッシュ (#) で始まる行は無視されます。
各ルールは、ネットワークサービスへのアクセスを制御するために以下の基本的なフォーマットを使用します。
<daemon list> : <client list> [: <option> : <option> : …]
  • <daemon list> — コンマ区切りのプロセス名 (サービス名ではない) の一覧、または ALL ワイルドカード。デーモンの一覧は、柔軟性を高めるために演算子 (「演算子」を参照) も受け付けます。
  • <client list> — ルールによって影響されるホストを特定するためのホスト名、ホスト IP アドレス、特別なパターン、またはワイルドカードのコンマ区切りのリスト。クライアントリストは、柔軟性を高めるために「演算子」にリストされた演算子も受け付けます。
  • <option> — ルールが起動されたときに実行されるオプションのアクション、またはアクションのコロン区切りのリスト。オプションのフィールドは、拡張、シェルコマンドの起動、アクセスの許可または拒否、および他のロギング動作をサポートします。

注記

上記の用語についての詳細は、このガイドの以下の箇所を参照してください。
以下は、ホストアクセス規則の基本的なサンプルです。
vsftpd : .example.com
このルールは、TCP Wrapper に対し、example.com ドメインにあるすべてのホストからの FTP デーモン (vsftpd) への接続を待つよう指示します。このルールが hosts.allow に表示される場合、接続は受け付けられます。このルールが hosts.deny に表示される場合は、接続は拒否されます。
次のホストアクセスルールのサンプルはさらに複雑で、2 つのオプションフィールドを使用しています。
sshd : .example.com  \
	: spawn /bin/echo `/bin/date` access denied>>/var/log/sshd.log \
	: deny
それぞれのオプションフィールドの前にはバックスラッシュ (\) が付けられることに注意してください。バックスラッシュを使用すると、長さが原因となるルールの失敗を防ぐことができます。
このサンプルルールは、以下のことを記述しています。example.com ドメインにあるホストが SSH デーモン (sshd) への接続を試みると、echo コマンドが実行されて特殊なログファイルにこの試行が追加され、接続が拒否されます。オプションの deny 指示文が使われているので、この行は hosts.allow ファイルに表示されても、アクセスは拒否されます。利用可能なオプションについての詳細は、「オプションフィールド」を参照してください。
2.6.2.1.1. ワイルドカード
ワイルドカードは、TCP Wrapper がデーモンやホストのグループにより簡単にマッチできるようにします。ワイルドカードはアクセスルールのクライアントリストフィールドで最も頻繁に使われます。
以下のワイルドカードを利用できます。
  • ALL — すべてにマッチします。デーモンリストとクライアントリストの両方に対して使用できます。
  • LOCAL — ローカルホストなどのピリオド (.) を含まないすべてのホストにマッチします。
  • KNOWN — ホスト名またはホストアドレスが既知であるか、またはユーザーが既知であるすべてのホストにマッチします。
  • UNKNOWN — ホスト名またはホストアドレスが未知であるかユーザーが未知であるか、またはユーザーが未知であるすべてのホストにマッチします。
  • PARANOID — ホスト名を取得するために逆 DNS ルックアップがソース IP アドレス上で実行されます。次に、DNS ルックアップが IP アドレスを解決するために実行されます。 2 つの IP アドレスが一致しない場合、接続が切断され、ログが更新されます。

重要

KNOWNUNKNOWN、および PARANOID のワイルドカードが正常に動作ために DNS サーバーの機能に依存しているので、注意して使用する必要があります。名前解決が中断されると、正当なユーザーによるサービスへのアクセスが妨害される可能性があります。
2.6.2.1.2. パターン
パターンをアクセスルールのクライアントフィールドで使用すると、クライアントホストのグループをより正確に指定することができます。
以下は、クライアントフィールドのエントリーについての一般的なパターンのリストです。
  • ピリオド (.) で始まるホスト名 —ホスト名の始めにピリオドを置くことにより、その名前についてリストされる構成部分を共有するすべてのホストにマッチします。以下の例は example.com ドメイン内のすべてのホストに適用されます。
    ALL : .example.com
  • ピリオド (.) で終わる IP アドレス — IP アドレスの終わりにピリオドを置くことにより、IP アドレスの最初の数値のグループが同じのすべてのホストにマッチします。以下の例は 192.168.x.x ネットワーク内のすべてのホストに適用されます。
    ALL : 192.168.
  • IP アドレス/ネットマスクのペア — ネットマスク表現は、IP アドレスの特定のグループへのアクセスを制御するためのパターンとしても使われます。192.168.0.0 から 192.168.1.255 までのアドレス範囲を持つすべてのホストに適用されます。
    ALL : 192.168.0.0/255.255.254.0

    重要

    IPv4 アドレス空間で動作している際には、アドレス/プレフィックスの長さ (prefixlen) のペアの宣言 (CIDR 表記) はサポートされません。IPv6 ルールのみがこの形式を利用できます。
  • [IPv6 アドレス]/プレフィックス長のペア — [ネット]/プレフィックス長の組み合わせは IPv6 アドレスの特定グループに対するアクセスを制御するためのパターンとして使用することができます。以下の例は、3ffe:505:2:1:: から3ffe:505:2:1:ffff:ffff:ffff:ffff までのアドレス範囲を持つすべてのホストに適用されます。
    ALL : [3ffe:505:2:1::]/64
  • アスタリスク (*) — アスタリスクは、他のタイプのパターンを含むクライアントリストと混在しない限り、ホスト名または IP アドレスのグループ全体にマッチするために使用できます。以下の例は example.com ドメイン内にあるすべてのホストに適用されます。
    ALL : *.example.com
  • スラッシュ (/) — クライアントリストがスラッシュで始まる場合、それはファイル名として処理されます。これは、多数のホストを指定するルールが必要な場合に役立ちます。以下の例では、TCP Wrapper がすべての Telnet 接続で /etc/telnet.hosts ファイルを参照します。
    in.telnetd : /etc/telnet.hosts
あまり使われない他のパターンも TCP Wrapper によって受け付けられます。詳細は、hosts_access man(5) ページを参照してください。

警告

ホスト名とドメイン名を使用するときは特に注意してください。正確な名前解決を防ぐために、攻撃者は様々なトリックを仕掛けます。さらに、DNS サービスの中断により、許可されているユーザーがネットワークサービスを使用することもできなくなります。そのため、可能な場合は常に IP アドレスを使用するのが最善の策です。
2.6.2.1.3. Portmap と TCP Wrapper
Portmap の TCP Wrapper の実装は、ホストの検索をサポートしません。このことは、 portmap はホストの識別にホスト名を使用できないことを意味します。結果として、 hosts.allowhosts.deny における portmap のアクセス制御ルールでは、ホストを指定するために IP アドレスを使用するか、またはキーワード ALL を使用する必要があります。
portmap アクセス制御ルールへの変更は直ちに反映されません。そのため、portmap サービスを再起動する必要があります。
NIS および NFS などの広く使われるサービスの動作は portmap に依存します。そのため、これらの制限を把握しておいてください。
2.6.2.1.4. 演算子
現在、アクセス制御ルールは演算子 EXCEPTを受け付けます。これは、ルールのデーモンリストとクライアントリストの両方で使用することができます。
EXCEPT 演算子は、同じルール内でより幅広くマッチさせるために特定の例外を許可します。
hosts.allow ファイルの以下の例では、すべての example.com ホストは、cracker.example.com を除くすべてのサービスに接続することが許可されます。
ALL : .example.com EXCEPT cracker.example.com
hosts.allow ファイルの他の例では、192.168.0.x ネットワークのクライアントは FTP を除くすべてのサービスを使用できます。
ALL EXCEPT vsftpd : 192.168.0.

注記

組織的には、EXCEPT 演算子を使用しない方が容易になる場合が多く、これにより、他の管理者は EXCEPT 演算子をソートせずに、サービスへのアクセスを許可/拒否されるホストを判断するのに適切なファイルを素早くスキャンすることができます。

2.6.2.2. オプションフィールド

アクセスを許可または拒否する基本的なルールに加えて、Red Hat Enterprise Linux の TCP Wrapper の実装は、オプションフィールドによるアクセス制御言語への機能拡張をサポートします。ホストアクセスルール内のオプションフィールドを使用することで、管理者はログ動作の変更、アクセス制御の統合、シェルコマンドの起動などの各種タスクを実行することができます。
2.6.2.2.1. ロギング
オプションフィールドを使うと、管理者は severity 指示文を使用してログファシリティおよびルールの優先レベルをより簡単に変更できます。
以下の例では、example.com ドメインのすべてのホストから SSH デーモンへの接続が emerg の優先度でデフォルトの authpriv syslog ファシリティ(ファシリティ値が指定されていないため)に記録されます。
sshd : .example.com : severity emerg
severity オプションを使用してファシリティを指定することも可能です。以下の例では、example.com ドメインのホストからの SSH 接続の試行が alert の優先度で local0 ファシリティに記録されます。
sshd : .example.com : severity local0.alert

注記

実際にはこの例は、syslog デーモン (syslogd) が local0 ファシリティに記録されるように設定されるまで機能しません。カスタムログファシリティ設定の詳細は、syslog.conf man ページを参照してください。
2.6.2.2.2. アクセス制御
オプションフィールドを使用すると、管理者は allow または deny 指示文を最終オプションとして追加し、1 つのルール内でホストを明示的に許可するか、または拒否することができるようになります。
例えば、以下の 2 つのルールは、client-1.example.com からの SSH 接続を許可しますが、client-2.example.com からの接続は拒否します。
sshd : client-1.example.com : allow
sshd : client-2.example.com : deny
ルールごとにアクセス制御を許可することで、管理者はオプションフィールドを使って 1 つのファイル hosts.allow または hosts.deny にすべてのアクセスルールを統合できるようになります。一部の管理者にとって、これはアクセスルールを構成する際のより簡単な方法になっています。
2.6.2.2.3. シェルコマンド
オプションフィールドを使うと、アクセスルールは以下の 2 つの指示文でシェルコマンドを起動できるようになります。
  • spawn — 子プロセスとしてシェルコマンドを起動します。要求しているクライアントについてのより詳しい情報を得るために /usr/sbin/safe_finger の使用などのタスクを実行できます。または echo コマンドを使用して特殊なログファイルを作成することもできます。
    以下の例では、example.com ドメインから Telnet サービスにアクセスしようとしているクライアントが特殊ファイルのログに暗黙的に記録されます。
    in.telnetd : .example.com \
    	: spawn /bin/echo `/bin/date` from %h>>/var/log/telnet.log \
    	: allow
  • twist — 要求されたサービスを指定したコマンドに置き換えます。この指示文は、侵入者に対するトラップ (「ハニーポット」とも呼ばれる) をセットアップするために使用されることが多くあります。また、接続しているクライアントにメッセージを送るためにも使用できます。 twist 指示文は、ルール行の末尾に置く必要があります。
    以下の例では、example.com ドメインから FTP サービスへのアクセスを試みているクライアントに、echo コマンドを使ってメッセージが送信されます。
    vsftpd : .example.com \
    	: twist /bin/echo "421 This domain has been black-listed. Access denied!"
シェルコマンドのオプションについての詳細情報は、 hosts_options man ページを参照してください。
2.6.2.2.4. 拡張機能
拡張機能は、spawn および twist 指示文と一緒に使用される場合に、関連するクライアント、サーバーおよびプロセスの情報を提供します。
以下は、サポートされている拡張機能のリストです。
  • %a — クライアントの IP アドレスを返します。
  • %A — サーバーの IP アドレスを返します。
  • %c — ユーザー名とホスト名、またはユーザー名と IP アドレスなどのさまざまなクライアント情報を返します。
  • %d — デーモンのプロセス名を返します。
  • %h — クライアントのホスト名 (または、ホスト名が利用できない場合は IP アドレス) を返します。
  • %H — サーバーのホスト名 (または、ホスト名が利用できない場合は IP アドレス) を返します。
  • %n — クライアントのホスト名を返します。利用できない場合は、unknown が出力されます。クライアントのホスト名とホストのアドレスが一致しなければ、paranoid が出力されます。
  • %N — サーバーのホスト名を返します。利用できない場合は、unknown が出力されます。サーバーのホスト名とホストのアドレスが一致しなければ、 paranoid が出力されます。
  • %p — デーモンのプロセス ID を返します。
  • %s —デーモンプロセスおよびサーバーのホストまたは IP アドレスなどの、さまざまな種類のサーバー情報を返します。
  • %u — クライアントのユーザー名を返します。これがない場合は、unknown がプリントされます。
以下のサンプルルールは、カスタマイズされたログファイルでクライアントホストを識別するために、spawn コマンドと共に拡張を使用します。
SSH デーモン (sshd) への接続が example.com ドメインにあるホストから試行される際に、クライアントのホスト名 (%h 拡張を使用) を含む試行を特殊ファイルのログに記録するために echo コマンドを実行します。
sshd : .example.com  \
	: spawn /bin/echo `/bin/date` access denied to %h>>/var/log/sshd.log \
	: deny
同様に、拡張機能はクライアントに返すメッセージをカスタマイズするために使用できます。以下の例では、example.com ドメインから FTP サービスにアクセスを試行しているクライアントは、それらがサーバーに接続するのが禁止されていることを通知されます。
vsftpd : .example.com \
: twist /bin/echo "421 %h has been banned from this server!"
利用可能な拡張機能および追加のアクセス制御オプションについての総合的な説明は、hosts_access man ページのセクション 5 (man 5 hosts_access) およびhosts_options man ページを参照してください。
TCP Wrapper についての詳細は、「その他のリソース」を参照してください。

2.6.3. xinetd

xinetd デーモンは、FTP、IMAP および Telnet を含む一般的なネットワークサービスのサブセットへのアクセスを制御する TCP でラップされたスーパーサービスです。アクセス制御、高度なロギング、バインディング、リダイレクトおよびリソース使用の制御についてのサービス固有の設定オプションも提供します。
クライアントが xinetd で制御されたネットワークサービスへの接続を試みると、スーパーサービスは要求を受けて、すべての TCP Wrapper アクセス制御ルールをチェックします。
アクセスが許可されると、xinetd は接続がそのサービスについての自らのアクセスルール下で許可されることを確認し、さらにサービスがその割り当て以上のリソースを持てることや、定義されたルールに違反していないことを確認します。
これらの条件がすべて満たされている場合 (つまり、サービスへのアクセスが許可され、サービスがそのリソース制限に達しておらず、かつサービスが定義されたいずれのルールにも違反していない場合)、xinetd は要求されたインスタンスを開始し、その接続の制御を通過させます。接続が確立されると、xinetd はこれ以上クライアントとサーバー間の通信には干渉しません。

2.6.4. xinetd の設定ファイル

xinetd の設定ファイルは以下の通りです。
  • /etc/xinetd.conf — 全体の xinetd 設定ファイル。
  • /etc/xinetd.d/ — サービス固有のファイルすべてを含むディレクトリー。

2.6.4.1. /etc/xinetd.conf ファイル

/etc/xinetd.conf ファイルには、xinetd の制御下ですべてのサービスに影響する一般的な設定が含まれます。その設定は、xinetd サービスの初回起動時に読み込まれます。そのため、設定の変更を反映するためには、xinetd サービスを再起動する必要があります。以下は /etc/xinetd.conf ファイルのサンプルです。
defaults
{
	 instances               = 60        
	 log_type                = SYSLOG	authpriv
	 log_on_success          = HOST PID
	 log_on_failure          = HOST
	 cps                     = 25 30
}
includedir /etc/xinetd.d
これらの行は xinetd の以下の側面を制御します。
  • instancesxinetd が処理できる同時要求の最大数を指定します。
  • log_typexinetdauthpriv ログファシリティを使用するように設定し、ログエントリーを /var/log/secure ファイルに書き込みます。FILE /var/log/xinetdlog などの指示文を追加することにより、/var/log/ ディレクトリーに xinetdlog というカスタムログファイルを作成します。
  • log_on_success — 成功した接続の試行をログに記録するよう xinetd を設定します。デフォルトでは、リモートホストの IP アドレスおよび要求を処理するサーバーのプロセス ID が記録されます。
  • log_on_failure — 失敗した接続試行をログに記録するように、または接続が拒否された場合に xinetd を設定します。
  • cps — 所定のサービスに対して 1 秒に 25 接続のみを許可するように xinetd を設定します。この制限を超えた場合は、サービスの使用が 30 秒間停止します。
  • includedir /etc/xinetd.d//etc/xinetd.d/ ディレクトリーにあるサービス固有の設定ファイルで宣言されたオプションが含まれます。詳細は、「/etc/xinetd.d/ ディレクトリー」を参照してください。

注記

多くの場合、/etc/xinetd.conf にある log_on_success および log_on_failure の設定は、サービス固有の設定ファイルで追加で修正されます。そのため、/etc/xinetd.conf ファイルが示すよりも多くの情報が所定サービスのログファイルに表示される可能性があります。詳細は「ロギングのオプション」を参照してください。

2.6.4.2. /etc/xinetd.d/ ディレクトリー

/etc/xinetd.d/ ディレクトリーには xinetd によって管理される各サービスについての設定ファイルが含まれ、ファイルの名前はサービスに関連付けられます。xinetd.conf と同様に、このディレクトリーは xinetd サービスの起動時にのみ読み込まれます。すべての変更を有効にするには、管理者は xinetd サービスを再起動する必要があります。
/etc/xinetd.d/ ディレクトリーにあるファイルのフォーマットは、/etc/xinetd.conf と同じ規則を使用します。各サービスの設定が別個のファイルに保存される理由には、主としてカスタマイズをより簡単にし、他のサービスへの影響を少なくすることがあります。
これらのファイルの構造を把握するために、/etc/xinetd.d/krb5-telnet ファイルを検討します。
service telnet
{
	 flags           = REUSE
	 socket_type     = stream
	 wait            = no
	 user            = root
	 server          = /usr/kerberos/sbin/telnetd
	 log_on_failure  += USERID
	 disable         = yes
}
これらの行は telnet サービスのさまざまな側面を制御します。
  • service — サービス名を指定します、通常は /etc/services ファイルでリストされるものの 1 つです。
  • flags — 接続についての数多くの属性を設定します。REUSE は Telnet 接続のソケットを再利用するように xinetd に指示します。

    注記

    REUSE フラグは廃止されています。すべてのサービスは暗黙的に REUSE フラグを使用します。
  • socket_type — ネットワークソケットの種類を stream に設定します。
  • wait — サービスがシングルスレッド (yes) かマルチスレッド (no) のどちらかを指定します。
  • user — プロセスが実行されるユーザー ID を指定します。
  • server — 起動する実行可能バイナリを指定します。
  • log_on_failurexinetd.conf ですでに定義されているものに加えて、log_on_failure に対するログのパラメーターを指定します。
  • disable — サービスを無効にする (yes) か有効にする (no) かを指定します。
これらのオプションとその使用法についての詳細は、xinetd.conf man ページを参照してください。

2.6.4.3. xinetd 設定ファイルの変更

xinetd で保護されるサービスでは、多くの指示文が利用できます。本セクションでは、より一般的に使用されるオプションのいくつかを説明しています。
2.6.4.3.1. ロギングのオプション
以下のロギングオプションは、/etc/xinetd.conf および /etc/xinetd.d/ ディレクトリーにあるサービス固有の設定ファイルで利用できます。
以下は、より一般的に使われるロギングオプションのいくつかのリストです。
  • ATTEMPT — 試行が失敗した事実をログに記録します (log_on_failure)。
  • DURATION — サービスがリモートシステムによって使用された時間の長さをログに記録します (log_on_success)。
  • EXIT — 終了状態またはサービスの終了シグナルをログに記録します (log_on_success)。
  • HOST — リモートホストの IP アドレスをログに記録します (log_on_failure および log_on_success)。
  • PID — 要求を受け取るサーバーのプロセス ID をログに記録します (log_on_success)。
  • USERID — すべてのマルチスレッド化されたストリームサービスについて、RFC 1413 で定義された方法でリモートユーザーをログ記録します (log_on_failure および log_on_success)。
ロギングオプションの完全なリストは、xinetd.conf man ページを参照してください。
2.6.4.3.2. アクセス制御オプション
xinetd サービスのユーザーは、TCP Wrapper のホストアクセスルールを使用するか、xinetd 設定ファイル経由のアクセス制御を提供するか、またはこれらの両方の組み合わせを選択することができます。TCP Wrapper のホストアクセス制御ファイルについての詳細は、「TCP Wrapper の設定ファイル」を参照してください。
本セクションは、xinetd を使用したサービスへのアクセス制御を説明します。

注記

TCP Wrapper とは異なり、アクセス制御の変更は、xinetd 管理者がxinetd サービスを再起動する場合にのみ、反映されます。
また TCP Wrapper とは異なり、xinetd によるアクセス制御は xinetd が制御するサービスにのみ影響を与えます。
xinetd ホストアクセス制御は、TCP Wrapper で使われる方式とは異なります。TCP Wrapper では、/etc/hosts.allow および /etc/hosts.deny の 2 つの設定ファイル内にすべてのアクセス設定を置いていますが、xinetd のアクセス制御は /etc/xinetd.d/ ディレクトリー内の各サービスの設定ファイル内にあります。
以下のホストアクセスオプションは xinetd で対応しています。
  • only_from — 指定されたホストによるサービスの使用のみを許可します。
  • no_access — リストされたホストによるサービスの使用をブロックします。
  • access_times — 特定のサービスが使用可能な時間帯を指定します。時間帯は 24 時間表記の HH:MM-HH:MM で記載する必要があります。
only_fromno_access オプションは、IP アドレスまたはホスト名のリストを使用できるか、またはネットワーク全体を指定できます。TCP Wrapper のように xinetd アクセス制御と高度なロギング設定を組み合わせると、各接続の試行を詳細に記録しながら、禁止されたホストからの要求をブロックすることにより、セキュリティを向上させることができます。
例えば、以下の /etc/xinetd.d/telnet ファイルを使用すると、特定のネットワークグループからの Telnet アクセスをブロックし、許可されたユーザーがログインできる時間帯を制限できます。
service telnet
{
	 disable         = no
	 flags           = REUSE
	 socket_type     = stream
	 wait            = no
	 user            = root
	 server          = /usr/kerberos/sbin/telnetd
	 log_on_failure  += USERID
	 no_access       = 172.16.45.0/24
	 log_on_success  += PID HOST EXIT
	 access_times    = 09:45-16:15
}
この例では、172.16.45.2 などの 172.16.45.0/24 ネットワークからのクライアントシステムが Telnet サービスにアクセスを試みると、以下のメッセージが表示されます。
Connection closed by foreign host.
さらに、ログインの試行は /var/log/messages のログに以下のように記録されます。
Sep  7 14:58:33 localhost xinetd[5285]: FAIL: telnet address from=172.16.45.107
Sep  7 14:58:33 localhost xinetd[5283]: START: telnet pid=5285 from=172.16.45.107
Sep  7 14:58:33 localhost xinetd[5283]: EXIT: telnet status=0 pid=5285 duration=0(sec)
xinetd アクセス制御と共に TCP Wrapper を使用する際は、これら 2 つのアクセス制御メカニズムの関係を理解することが重要です。
以下は、クライアントが接続を要求する際に、xinetd が実行する一連のイベントです。
  1. xinetd デーモンが libwrap.so ライブラリコールを使用して TCP Wrapper のホストアクセスルールにアクセスします。拒否ルールがクライアントにマッチすると、接続は切断されます。許可ルールがクライアントにマッチすると、接続は xinetd に渡されます。
  2. xinetd デーモンが、xinetd サービスと要求されたサービスの両方に対して自らのアクセス制御ルールをチェックします。拒否ルールがクライアントにマッチすると、接続は切断されます。マッチしないと、xinetd は要求されたサービスのインスタンスを起動し、そのサービスに接続の制御を渡します。

重要

xinetd アクセス制御と共に TCP Wrapper を使用する場合には注意する必要があります。設定の誤りが意図しない効果を引き起こす可能性があります。
2.6.4.3.3. バインドとリダイレクトのオプション
xinetd のサービス設定ファイルは、サービスの IP アドレスへのバインド、およびサービスの入力要求の、他の IP アドレスやホスト名またはポートへのリダイレクトをサポートします。
バインドは、サービス固有の設定ファイルで bind オプションを使って制御され、サービスをシステム上の IP アドレス 1 つにリンクします。これが設定されて bind オプションを使用すると、正しい IP アドレスへの要求のみがサービスへのアクセスを許可されます。この方式を使うと、要求に基づいて異なるネットワークインタフェースに異なるサービスをバインドすることができます。
これは、複数のネットワークアダプタまたは複数の IP アドレスを持つシステムの場合に特に有用です。そのようなシステムでは、セキュアではないサービス (Telnet など)は、プライベートネットワークに接続されたインタフェースのみをリッスンするようにし、インターネットに接続されたインタフェースはリッスンしないように設定できます。
redirect オプションは、IP アドレスまたはホスト名とそれに続くポート番号を受け付けます。あるサービスに対するすべての要求を、このサービスが指定されたホストとポート番号へリダイレクトするように設定します。この機能は、同一システム上の別のポート番号をポイントしたり、要求を同じマシンにある別の IP アドレスにリダイレクトしたり、この要求を全く異なるシステムとポート番号に移動したりする他、これらのオプションを組み合わせて使用することができます。このため、システム上の特定のサービスに接続しているユーザーは、接続が切断されることなく他のシステムに再接続することが可能です。
xinetd デーモンは、要求側のクライアントマシンと実際にサービス提供するホスト間の接続中に有効となるプロセスを発生させ、この 2 つのシステム間でデータを転送することで、このリダイレクトを達成できます。
bind および redirect オプションの利点は、それらが一緒に使用される場合に最も明確になります。システム上の特定の IP アドレスにサービスをバインドした後、このサービスに対する要求を 最初のマシンのみが見ることができる 2 番目のマシンへリダイレクトすることで、内部のシステムを使って全く異なるネットワークに対してサービスを提供することができます。または、これらのオプションを使うと、複数ホームのマシン上の特定サービスが既知の IP アドレスへ露出することを制限したり、そのサービスに対するすべての要求をその目的のみ特別設定された別のマシンにリダイレクトすることもできます。
例えば、以下の設定の Telnet サービスがある、ファイアウォールとして使用されるシステムについて考えてみましょう。
service telnet
{
	 socket_type		= stream
	 wait			= no
	 server			= /usr/kerberos/sbin/telnetd
	 log_on_success		+= DURATION USERID
	 log_on_failure		+= USERID
	 bind                    = 123.123.123.123
	 redirect                = 10.0.1.13 23
}
このファイルにある bind および redirect オプションは、マシン上の Telnet サービスをインターネットに向いている外部 IP アドレス (123.123.123.123) にバインドします。さらに、123.123.123.123 に送信された Telnet サービスについてのすべての要求は、2 つ目のネットワークアダプターを経由して、ファイアウォールと内部システムだけがアクセスできる内部 IP アドレス (10.0.1.13) にリダイレクトされます。その後、ファイアウォールは 2 つのシステム間に通信を送り、接続しているシステムは別のマシンに接続されている際も、123.123.123.123 に接続しているように見えます。
ブロードバンド接続で固定 IP アドレスが 1 つのみのユーザーにとって、この機能はとくに有用です。NAT (Network Address Translation) を使用する際に、ゲートウェイマシンの後ろにあるシステムで内部専用の IP アドレスを使用するものは、ゲートウェイシステムの外側から利用することはできません。ただし、xinetd が制御す特定のサービスを bind および redirect のオプションを使って設定する場合は、ゲートウェイマシンは外側システムと、そのサービスを提供するように設定された特定の内部マシンとの間のプロキシとして作動することが可能です。さらに追加の保護目的で、様々な xinetd のアクセス制御およびロギングのオプションも利用可能です。
2.6.4.3.4. リソース管理オプション
xinetd デーモンは、サービス妨害 (DoS) 攻撃に対する基本的なレベルの保護を追加することができます。以下は、それらの攻撃の有効性を限定するために役立つ指示文のリストです。
  • per_source — ソース IP アドレスあたりのサービス用のインスタンス最大数を定義します。引数として整数のみを受け付け、xinetd.confxinetd.d/ ディレクトリー内のサービス固有の設定ファイルの両方で使用できます。
  • cps — 1 秒あたりの最大の接続数を定義します。この指示文は空白区切りの 2 つの整数を取ります。最初の引数は、1 秒あたりにサービスに許可される接続の最大数です。2 つ目の引数は、xinetd がサービスを再び有効にするまでに待機する秒数です。これは、引数として整数のみを受け付け、xinetd.conf ファイルまたは xinetd.d/ ディレクトリ内のサービス固有の設定ファイルで使用できます。
  • max_load — サービスの CPU 利用率またはロードアベレージのしきい値を定義します。浮動小数点数を受け付けます。
    ロードアベレージは、ある時点でいくつのプロセスがアクティブであるかを大まかに測定する方法です。負荷平均についての詳細は、uptimewho、および procinfo コマンドを参照してください。
xinetd には、利用可能な多くのリソース管理オプションがあります。詳細は、xinetd.conf man ページを参照してください。

2.6.5. その他のリソース

TCP Wrapper と xinetd に関する詳細は、システムのドキュメントとインターネットで入手できます。

2.6.5.1. インストール済みの TCP Wrapper ドキュメント

TCP Wrapper、xinetd およびアクセス制御についての追加の設定オプションについて調べる際には、システムにあるドキュメントをまず参照することをお勧めします。
  • /usr/share/doc/tcp_wrappers-<version>/ — このディクトリーには README ファイルが含まれています。このファイルでは、TCP Wrapper がどのように機能するか、また存在するさまざまなホスト名やホストアドレスのスプーフィングのリスクについて説明しています。
  • /usr/share/doc/xinetd-<version>/ — このディレクトリーには README ファイルが含まれており、/etc/xinetd.d/ ディレクトリー内のサービス固有の設定ファイルの編集に関する各種のアイディアとともに、アクセス制御や sample.conf ファイルについて説明しています。
  • TCP Wrapper および xinetd 関連の man ページ — TCP Wrapper および xinetd に関連するさまざまなアプリケーションや設定ファイルについて、数多くの man ページがあります。以下はより重要な man ページです。
    サーバーアプリケーション
    • man xinetdxinetd の man ページ
    設定ファイル
    • man 5 hosts_access — TCP Wrapper のホストアクセス制御ファイルの man ページ。
    • man hosts_options — TCP Wrapper オプションフィールドの man ページ。
    • man xinetd.confxinetd 設定オプションをリストしている man ページ。

2.6.5.2. 有用な TCP Wrapper の Web サイト

2.6.5.3. 関連書籍

  • Hacking Linux Exposed; Osbourne/McGraw-Hill (Brian Hatch、James Lee、および George Kurtz )— TCP Wrapper および xinetd についての情報を含む優れたセキュリティリソースです。

2.7. 仮想プライベートネットワーク (VPN)

複数のサテライトオフィスを持つ組織は、機密データの送信における効率性と保護のために専用回線で相互接続しています。例えば、多くの企業はオフィスとオフィスをつなぐためにエンドツーエンドのネットワークソリューションとして、フレームリレーまたは非同期転送モード (ATM) 回線を使用しています。しかしこれは、企業レベルの専用デジタル回線に多くの費用をかけずに拡張を望む中小企業にとっては、コストのかかる方法となる可能性があります。
こうしたニーズに対応するために、仮想プライベートネットワーク (VPN) が開発されました。VPN は、専用回線と同じ機能原理にしたがい、2 つの関係者間 (またはネットワーク) でのセキュリティ保護されたデジタル通信を可能にし、既存のローカルエリアネットワーク (LAN) からワイドエリアネットワーク (WAN) を作成します。VPN とフレームリレーや ATM との違いは、そのトランスポートメディアにあります。VPN はデータグラムをトランスポート層として使用して IP 上で送信を行い、インターネット経由で送信先までをセキュアな状態にします。ハードウェアおよびソフトウェアの VPN 実装は通常、VPN 接続の確立と認証に IETF IPsec 標準を実行します。データの暗号化も IETF IPsec 標準となっていますが、FIPS 規定は使用可能なオプションを制限します。
組織の中にはセキュリティ強化のためにハードウェア VPN ソリューションを使用するところもありますが、ソフトウェアまたはプロトコルベースの実装を活用しているところもあります。Cisco、Nortel、IBM および Checkpoint などの複数のベンダーは、ハードウェアの VPN ソリューションを提供しています。また、Openswan のようなフリーソフトウェアベースの VPN ソリューションは、標準化された Internet Protocol Security (IPsec) 実装を利用しています。これらの VPN ソリューションは、ハードウェアかソフトウェアベースかに関わらず、1 つのオフィスから別のオフィスへの IP 接続間における専用ルーターとして機能します。

重要

Openswan が実施する IPsec は、Red Hat Enterprise Linux 6 での使用が推奨される唯一の VPN 技術です。リスクを理解せずに他の VPN を使用しないでください。

2.7.1. VPN の機能

パケットはクライアントから送信されると、VPN ルーターまたはゲートウェイを経由して送信されます。これらは、認証とオプションでデータを暗号化するものです。IPsec にはいくつものモードがあります。最も一般的に使用される設定では、カプセル化セキュリティペイロード (ESP: Encapsulating Security Payload) による トンネルモード が使用されます。商用 VPN クライアントのなかには ESP による トランスポートモード を使用するものもありますが、このモードを NAT で導入する際には困難を伴います。認証ヘッダー (AH) の導入は、最近では珍しいものとなっています。これは通常、ESP のオーバーヘッドが望ましくなく、暗号化が不要なコアルーター間で使用されます。Red Hat Enterprise Linux で導入される ESP には常に、認証済みのヘッダーが含まれています。ただし、古いバージョンや racoon ソフトウェアベースの実装は、時折間違って ESP + AH と一緒に導入されて、認証層が二重になることがあります。
受信 VPN ルーターはヘッダー情報を分離してデータの暗号化解読を行い、目的の宛先 (ワークステーションまたはネットワークにある他のノード) までのルートを決定します。ローカルネットワーク上の受信ノードは、ネットワーク間の接続を使用して、暗号解読された処理可能な状態のパケットを受け取ります。ネットワーク間の VPN 接続では、暗号化および暗号化解除プロセスはローカルノードに対して透過的に実行されます。
このようにセキュリティレベルが強化されていると、攻撃者はパケットの傍受だけでなく、暗号解読も可能である必要があります。サーバーとクライアント間に中間者攻撃を仕掛ける侵入者は、少なくとも認証セッション用の秘密鍵 1 つにアクセスする必要もあります。また、このような秘密鍵を獲得しても、危険にさらされるのは過去に暗号化されて送信されたトラフィックではなく、現在のトラフィックのみです。VPN は複数層の認証と暗号化を用いるため、複数のリモートノードを連結させて単一のイントラネットとして動作させるセキュアで効率的な手段になります。

2.7.2. Openswan

Openswan は、Red Hat Enterprise Linux 6 で利用可能なオープンソースのユーザースペース IPsec 実装です。ユーザーレベルのデーモンとして実装される、鍵を確立するプロトコルである IKE (インターネット鍵交換) v1 および v2 を使用します。ip xfrm コマンドで手動の鍵の確立も可能ですが、これは推奨されません。Openswan は、netlink を使って Linux カーネルとインターフェイス接続し、暗号化鍵を送信します。パケットの暗号化と暗号解読は、Linux カーネルで行われます。
暗号化サポート
Openswan は、FIPS セキュリティのコンプライアンスに必要な NSS (Network Security Services: ネットワークセキュリティサービス) の暗号化ライブラリを使用します。FIPS (Federal Information Processing Standard: 連邦情報処理規格) については、「連邦情報処理標準 (FIPS: Federal Information Processing Standard)」を参照してください。
インストール
Openswan をインストールするには、yum install openswan コマンドを実行します。

2.7.2.1. 設定

場所
このセクションでは、Openswan の設定に使用される重要なディレクトリーとファイルについて説明します。
  • /etc/ipsec.d - Openswan 関連のファイルを保存するメインディレクトリーです。
  • /etc/ipsec.conf - マスター設定ファイル。個々の設定用に、追加の *.conf 設定ファイルを /etc/ipsec.d に作成できます。
  • /etc/ipsec.secrets - マスター secrets ファイル。個々の設定用に、追加の *.secrets ファイルを /etc/ipsec.d に作成できます。
  • /etc/ipsec.d/cert*.db - 証明書データベースファイル。古いデフォルトの NSS データベースファイルは cert8.db です。Red Hat Enterprise Linux 6 以降、NSS SQLite データベースは cert9.db ファイルで使用されています。
  • /etc/ipsec.d/key*.db - 鍵データベースファイル。古いデフォルトの NSS データベースファイルは key3.db です。Red Hat Enterprise Linux 6 以降、NSS SQLite データベースは key4.db ファイルで使用されています。
  • /etc/ipsec.d/cacerts - 認証局 (CA) の証明書の以前の場所です。CA 証明書は、NSS データベースファイルにインポートすることが推奨されます。この場所は、Red Hat Enterprise Linux の次のバージョンでは廃止となります。
  • /etc/ipsec.d/certs - マシンの証明書の以前の場所です。マシン証明書は、NSS データベースファイルにインポートすることが推奨されます。この場所は、Red Hat Enterprise Linux の次のバージョンでは廃止となります。
  • /etc/ipsec.d/policies - 日和見暗号化グループポリシーです。Red Hat Enterprise Linux 6 では使用されていません。
  • /etc/ipsec.d/nsspassword - NSS パスワードファイル。このファイルはデフォルトでは存在せず、使用中の NSS データベースがパスワードを使って作成されると必要になります。
グローバル設定のパラメーター
本セクションでは、/etc/ipsec.conf の グローバル config setup セクションで利用可能な設定オプションをいくつか説明します。
  • protostack - どのプロトコルスタックを使用するかを定義します。Red Hat Enterprise Linux 6 のデフォルトオプションは netkey です。他の有効な値は klips および mast です。これら代替の IPsec カーネルスタックは、Red Hat Enterprise Linux が対応していないサードパーティーのカーネルモジュールを必要とします。代替スタックは通常、埋め込み Linux デバイスと使用されます。
  • nat_traversal - NAT-トラバーサル (RFC 3947) が接続に使用可能かどうかを定義します。デフォルトでは、使用可能です。
  • dumpdir - コアダンプファイルの場所を定義します。これを変更する場合は、SELinux ポリシーを新たな場所に適合するように変更する必要があります。
  • nhelpers - 暗号化操作に使用されるヘルパースレッドの数を定義します。
  • virtual_private - クライアント接続を可能にするサブネットです。クライアントが接続する NAT ルーターの後ろまで範囲が及ぶ可能生があります。サーバーが使用する LAN 範囲を除いて、RFC 1918 アドレススペースを含めます。
  • plutorestartoncrash - デフォルトでは Yes に設定されています。
  • plutostderrlog - これが有効にすると、syslog 機能の代わりにログファイル名が使用されます。
接続固有のパラメーター
本セクションでは、conn セクションで接続ごとに利用可能な設定オプションのいくつかを説明します。
  • auto - 接続の startup プロファイルを定義します。デフォルトは ignore です。他の有効な値は、start (起動)、add (反応のみ) および route (オンデマンドの起動) になります。
  • type - 使用されるトンネルポリシーを定義します。デフォルトは、トンネルモード用の tunnel です。他の有効な値は、トランスポートモード用 (L2TP と使用) の transport と、IPsec を完全に迂回する passthrough になります。
  • authby - 使用される認証タイプを定義します。デフォルトは、生 RSA 鍵用の rsasig です。他の有効な値は、事前共有鍵 (PSK) 用の secret とパススルー接続用の never です。
  • rekey - 接続の有効期限が切れる際に、鍵を更新するかどうかを定義します。デフォルトは yes で、通常静的 VPN に使用されます。no の値は通常、サポートの動的 VPN クライアントに使用されます。
Openswan の設定に関する詳細は、ipsec.conf(5) および ipsec.secrets(5) の man ページを参照してください。

2.7.2.2. コマンド

本セクションでは、Openswan で使用されるコマンド例を紹介します。サービスステータスのチェック以外は、コマンドは root で実行する必要があることに注意してください。
Openswan のサービスコマンド
  • service ipsec start
  • service ipsec stop
  • service ipsec status
接続のロードおよびアンロード
  • ipsec auto --add connection_name
  • ipsec auto --delete connection_name
接続の起動、オンデマンド、および終了
  • ipsec auto --up connection_name
  • ipsec auto --route connection_name
  • ipsec auto --down connection_name
IPsec カーネルサブシステムのチェック
  • ip xfrm policy
  • ip xfrm state
  • ip -s xfrm monitor
IPsec ユーザースペースサブシステムのチェック
  • ipsec auto --status
  • ipsec verify
IPsec 用の生 RSA

注記

生 RSA 鍵を生成するコマンドは、システムのエントロピーに依存しています。システムアクティビティーおよび鍵のサイズによっては、これらのコマンドは実行終了までに数分かかる場合があります。
  • 生 RSA 鍵の生成:
    • ipsec newhostkey --configdir /etc/ipsec.d --output /etc/ipsec.d/name-of-file.secret
  • IPsec 設定ファイルに使用する生 RSA 鍵の一覧表示
    • ipsec showhostkey --left | --right
  • DNS で公開する生 RSA 鍵の一覧表示
    • ipsec showhostkey --ipseckey
IPsec での証明書の設定
証明書エージェンシーの作成および維持は、別個のマシンで行う必要があります。このマシンから IPsec サーバーに移動する必要があるのは、作成済みの PKCS #12 ファイルのみです。PKCS #12 (.p12) ファイルのエクスポートには、CA 管理者がパスワードを使って .p12 ファイルを暗号化する必要があります。これらのファイルをインポートするには、システム管理者がこのパスワードを知っている必要があります。このため、このパスワードが電話など Email 以外の方法で共有されていれば、.p12 ファイル自体は Email で安全に送信できます。
(自己署名) CA 証明書を作成します。
  • certutil -S -k rsa -n ca.example.com -s \ "CN=ca.example.com" -w 12 -t "C,C,C" -x -d ~/CAstore
この CA で署名されたホスト証明書を作成します。
  • certutil -S -k rsa -c ca.example.com -n west.example.com -s "CN=west.example.com" -w 12 -t "u,u,u" -d ~/CAstore
ターゲットマシンに移動するエクスポートファイルを PKCS #12 形式で作成します。
  • pk12util -o west.p12 -n west.example.com -d ~/CAstore
エクスポートされたマシン証明書を IPsec NSS データベースにインポートします。
  • pk12util -i west.example.com.p12 -d /etc/ipsec.d 
NSS データベース (IPsec ゲートウェイまたは CA) のコンテンツを一覧表示します。
  • certutil -L -d /etc/ipsec.d
  • certutil -L -d ~/CAstore

2.7.3. Openswan を使った IPsec VPN

Openswan のインストール

Openswan をインストールするには、root で以下のコマンドを実行します。
~]# yum install openswan
パッケージに加えて、2 つの鍵のインストールを許可するよう尋ねられます。
root で以下のコマンドを実行して、network security services (NSS) データベースを初期化します。
~]# certutil -N -d /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:
NSS にパスワードを使用しない場合は、パスワードのプロンプトで Enter を 2 回押します。パスワードを入力した場合は、システム起動時など、Openswan の起動ごとに毎回パスワードの入力が必要になります。
デフォルトの SELinux セキュリティコンテンツを復元します。
~]# restorecon -Rv /etc/ipsec.d
Openswan が提供する ipsec デーモンを起動するには、root で以下のコマンドを実行します。
~]# service ipsec start
ipsec_setup: Starting Openswan IPsec U2.6.32/K2.6.32-358.el6.x86_64...
システム起動時に Openswan も起動するようにするには、root で以下のコマンドを実行します。
~]# chkconfig ipsec on
中間およびホストベースのファイアウォールが ipsec サービスを許可するように設定します。ファイアウォールおよび特定サービスの通過を許可することについての詳細情報は、「Netfilter と IPTables」 を参照してください。Openswan の使用には、以下のパケットがファイアウォールを通過できるようにしておく必要があります。
  • Internet Key Exchange (IKE) プロトコル用に UDP ポート 500
  • IKE NAT-Traversal 用に UDP ポート 4500
  • Encapsulated Security Payload (ESP) IPsec パケット用に プロトコル 50
  • Authenticated Header (AH) IPsec パケット用にプロトコル 51 (まれ)
Openswan を使って IPsec VPN を設定する例を 3 つ紹介します。ひとつ目は、2 つのホストを接続してセキュアな通信ができるようにします。2 つ目は、2 つのサイトを接続して 1 つのネットワークを形成します。3 つ目は、このコンテキストでは ロードウォリアー と呼ばれるローミングユーザーをサポートします。

2.7.4. Openswan を使った VPN 設定

Openswan では、ソース宛先 といった用語を使用しません。代わりに、エンドポイント (ホスト) に向かって および という用語を使用します。これにより、ほとんどのケースで両方のエンドポイントで同じ設定が使えるようになります。ただし、ほとんどの管理者はローカルホストにを、リモートホストにを使用します。キーワードに といった言葉が含まれるものは任意のものです。これは文字通り、左は使用するネットワーク図の左にあるホスト、と解釈することができます。Openswan は、またはを自動で検出します。例では、Openswan コマンドが と呼んでいるホストに、合致するホスト名が与えられます。通常、およびに合致するよう、それぞれ西およびがホスト名に使用されます。本ガイドでは、west.example.comに、east.example.comに使用します。
エンドポイントの認証には、3 つの一般的な方法が使用されます。
  • 事前共有鍵 (PSK) は、最もシンプルな認証方法です。PSK は任意の 20 以上の文字で構成されます。PSK が任意でなくかつ短いものになる危険があることから、システムが FIPS モードで稼働している際は、この方法は利用できません。
  • 生 RSA 鍵は、静的なホスト間またはサブネット間で一般的に使用される IPsec 設定です。ホストは、それぞれの公開 RSA 鍵で手動で設定されます。この方法は、12 以上のホストで相互に IPsec トンネルを設定する必要がある場合には、うまく拡張できません。
  • X.509 certificates は、共通の IPsec ゲートウェイに接続する必要のあるホストが多くある、大型の導入案件でよく使用されます。ホストまたはユーザーの RSA 証明書の署名には、中央 認証機関 (CA) が使用されます。この中央 CA は、個別ホストまたはユーザーの取り消しを含む信頼の中継を担当します。

2.7.5. Openswan を使用したホスト間の VPN

Openswan および と呼ばれる 2 つのホスト間で IPsec VPN を作成するよう設定するには、leftのホスト上で root で以下のコマンドを実行して新たな生 RSA 鍵のペアを作成します。
~]# ipsec newhostkey --configdir /etc/ipsec.d \
        --output /etc/ipsec.d/ipsec.secrets --bits 4096
Generated RSA key pair using the NSS database
これで ホストの RSA 鍵ペアが生成されます。エントロピーが低い仮想マシンでは特に、RSA 鍵の生成プロセスは時間が長くかかります。
公開鍵を表示するには、 と呼ばれるホスト上で root で以下のコマンドを実行します。
~]# ipsec showhostkey --left
ipsec showhostkey nss directory showhostkey: /etc/ipsec.d
# rsakey AQO+NIez4
leftrsasigkey=0sAQO+NIez4bxcib5FPjT3jF3S6Mrz9NACaD5B4wPXFuhxQmy6c8GNX1A9yB0vvLWon [...] W8rQIf4NrL6eGd5r9HwIPT7
以下で説明するように、この鍵を設定ファイルに追加する必要があります。
と呼ばれるホスト上で root で以下のコマンドを実行します。
~]# ipsec newhostkey --configdir /etc/ipsec.d \
        --output /etc/ipsec.d/ipsec.secrets --bits 4096
Generated RSA key pair using the NSS database
公開鍵を表示するには、 と呼ばれるホスト上で root で以下のコマンドを実行します。
~]# ipsec showhostkey --right
# rsakey AQO3fwC6n
rightrsasigkey=0sAQO3fwC6nSSGgt64DWiYZzuHbc4 [...] D/v8t5YTQ==
この鍵を設定ファイルに追加する必要があります。
このホスト間のトンネル用に設定ファイルを作成するには、上記の leftrsasigkey=rightrsasigkey= の各行を /etc/ipsec.d/ ディレクトリー内のカスタム設定ファイルに記載します。Openswan がカスタム設定ファイルを読み取るようにするには、root でエディターを実行し、メイン設定ファイルである /etc/ipsec.conf で以下の行の # 文字を削除します。これで、以下の行が有効になります。
include /etc/ipsec.d/*.conf
root でエディターを使用して以下の形式で適切な名前のファイルを作成します。
/etc/ipsec.d/my_host-to-host.conf
以下のようにファイルを編集します。
conn mytunnel
    leftid=@west.example.com
    left=192.1.2.23
    leftrsasigkey=0sAQOrlo+hOafUZDlCQmXFrje/oZm [...] W2n417C/4urYHQkCvuIQ==
    rightid=@east.example.com
    right=192.1.2.45
    rightrsasigkey=0sAQO3fwC6nSSGgt64DWiYZzuHbc4 [...] D/v8t5YTQ==
    authby=rsasig
    # load and initiate automatically
    auto=start
左右両方のホストに同一の設定ファイルを使用することができます。ホストはかを自動検出します。leftrsasigkey の値をのホストから、rightrsasigkey の値をのホストから取得していることを確認してください。
ipsec が起動していることを確認します。
~]# service ipsec start
ipsec_setup: Starting Openswan IPsec U2.6.32/K2.6.32-412.el6.x86_64...
ipsec_setup: /usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled
root で以下のコマンドを実行して、IPsec トンネルを読み込みます。
~]# ipsec auto --add mytunnel
/usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled
左右両方のホストのトンネルを表示するには、root で以下のコマンドを実行します。
~]# ipsec auto --up mytunnel
104 "mytunnel" #1: STATE_MAIN_I1: initiate
003 "mytunnel" #1: received Vendor ID payload [Dead Peer Detection]
106 "mytunnel" #1: STATE_MAIN_I2: sent MI2, expecting MR2
108 "mytunnel" #1: STATE_MAIN_I3: sent MI3, expecting MR3
003 "mytunnel" #1: received Vendor ID payload [CAN-IKEv2]
004 "mytunnel" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_RSA_SIG cipher=aes_128 prf=oakley_sha group=modp2048}
117 "mytunnel" #2: STATE_QUICK_I1: initiate
004 "mytunnel" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP=>0x63ad7e17 <0x4841b647 xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none DPD=none}

2.7.5.1. Openswan を使ったホスト間 VPN の検証

IKE 交渉は、UDP ポート 500 で行われます。IPsec パケットは、Encapsulated Security Payload (ESP) パケットとして現れます。VPN 接続が NAT ルーターを通過する必要がある場合は、ESP パケットはポート 4500 上の UDP パケットにカプセル化されます。
パケットが VPN トンネル経由で送信されていることを確認するには、root で以下の形式のコマンドを実行します。
~]# tcpdump -n -i interface esp and udp port 500 and udp port 4500
00:32:32.632165 IP 192.1.2.45 > 192.1.2.23: ESP(spi=0x63ad7e17,seq=0x1a), length 132
00:32:32.632592 IP 192.1.2.23 > 192.1.2.45: ESP(spi=0x4841b647,seq=0x1a), length 132
00:32:32.632592 IP 192.0.2.254 > 192.0.1.254: ICMP echo reply, id 2489, seq 7, length 64
00:32:33.632221 IP 192.1.2.45 > 192.1.2.23: ESP(spi=0x63ad7e17,seq=0x1b), length 132
00:32:33.632731 IP 192.1.2.23 > 192.1.2.45: ESP(spi=0x4841b647,seq=0x1b), length 132
00:32:33.632731 IP 192.0.2.254 > 192.0.1.254: ICMP echo reply, id 2489, seq 8, length 64
00:32:34.632183 IP 192.1.2.45 > 192.1.2.23: ESP(spi=0x63ad7e17,seq=0x1c), length 132
00:32:34.632607 IP 192.1.2.23 > 192.1.2.45: ESP(spi=0x4841b647,seq=0x1c), length 132
00:32:34.632607 IP 192.0.2.254 > 192.0.1.254: ICMP echo reply, id 2489, seq 9, length 64
00:32:35.632233 IP 192.1.2.45 > 192.1.2.23: ESP(spi=0x63ad7e17,seq=0x1d), length 132
00:32:35.632685 IP 192.1.2.23 > 192.1.2.45: ESP(spi=0x4841b647,seq=0x1d), length 132
00:32:35.632685 IP 192.0.2.254 > 192.0.1.254: ICMP echo reply, id 2489, seq 10, length 64
ここでの interface は、監視するインターフェイスになります。tcpdump での表示を終了するには、Ctrl+C を押します。

注記

tcpdump コマンドと IPsec のインタラクションはやや予想外のものになります。見えるのは暗号化された送信パケットのみで、プレーンテキストの送信パケットは見えません。受信パケットは、暗号化および暗号解読された両方を表示します。可能であれば、tcpdump コマンドはどちらかのエンドポイント上ではなく、2 つのマシン間にあるルーター上で実行してください。

2.7.6. Openswan を使ったサイト間の VPN

Openswan が 2 つのネットワークを結合させるサイト間の IPsec VPN を作成するようにするには、2 つのホスト間に IPsec トンネルを作成します。これらのホストは、1 つ以上のサブネットからのトラフィック通過を許可します。このため、これらはネットワークのリモート箇所にはゲートウェイのようにみられます。サイト間 VPN とホスト間 VPN の唯一の違いは、前者では 1 つ以上のネットワークまたはサブネット (アドレス) の範囲を設定ファイルで指定する必要があるという点です。
サイト間 IPsec VPN を作成するように Openswan を設定するには、まず 「Openswan を使用したホスト間の VPN」 にあるようにホスト間の IPsec VPN を設定し、その設定ファイルを /etc/ipsec.d/my_site-to-site.conf などの適切なファイル名にコピーまたは移動します。root としてエディターを使用して、カスタム設定ファイルである /etc/ipsec.d/my_site-to-site.conf を以下のように編集します。
conn mysubnet
     also=mytunnel
     leftsubnet=192.0.1.0/24
     rightsubnet=192.0.2.0/24

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

conn mytunnel
    auto=start
    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
トンネルを表示するには、Openswan を再起動するか、root で以下のコマンドを実行して手動ですべての接続を読み込み、開始します。
~]# ipsec auto --add mysubnet
/usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled
~]# ipsec auto --add mysubnet6
/usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled
~]# ipsec auto --add mytunnel
/usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled
~]# ipsec auto --up mysubnet
104 "mysubnet" #1: STATE_MAIN_I1: initiate
003 "mysubnet" #1: received Vendor ID payload [Dead Peer Detection]
106 "mysubnet" #1: STATE_MAIN_I2: sent MI2, expecting MR2
108 "mysubnet" #1: STATE_MAIN_I3: sent MI3, expecting MR3
003 "mysubnet" #1: received Vendor ID payload [CAN-IKEv2]
004 "mysubnet" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_RSA_SIG cipher=aes_128 prf=oakley_sha group=modp2048}
117 "mysubnet" #2: STATE_QUICK_I1: initiate
004 "mysubnet" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP=>0x9414a615 <0x1a8eb4ef xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none DPD=none}
~]# ipsec auto --up mysubnet6
117 "mysubnet" #2: STATE_QUICK_I1: initiate
004 "mysubnet" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP=>0x06fe2099 <0x75eaa862 xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none DPD=none}
~]# ipsec auto --up mytunnel
117 "mysubnet" #2: STATE_QUICK_I1: initiate
004 "mysubnet" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP=>0x06fe209a <0x75eaa863 xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none DPD=none}

2.7.6.1. Openswan を使ったサイト間 VPN の検証

パケットが VPN トンネル経由で送信されていることを確認する方法は、「Openswan を使ったホスト間 VPN の検証」 で説明されている手順と同じになります。

2.7.7. Openswan を使ったサイト間の単一トンネル VPN

サイト間のトンネルを構築する際には、ゲートウェイは公開 IP アドレスではなく、内部の IP アドレスを使って相互に通信する必要が多くあります。これは、単一トンネルを使用することで実行できます。ホスト名が west の左のホストの内部 IP アドレスが 192.0.1.254 で、ホスト名が east の右のホストの IP アドレスが 192.0.2.254 の場合、以下の設定で単一トンネルが使用できます。
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

2.7.8. Openswan を使ったサブネット押し出し

IPsec は、ハブおよびスポークのアーキテクチャーで導入されることがよくあります。各リーフノードには、広い範囲の一部である IP 範囲があります。各リーフはハブ経由で相互に通信します。これは、サブネット押し出しと呼ばれます。下記の例では、ヘッドオフィスを 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
    righsubnet=10.0.1.0/24
    rightrsasigkey=0sAXXXX[...]
    #
    auto=start
    authby=rsasigkey

conn branch2
    left=1.2.3.4
    leftid=@headoffice
    leftsubnet=0.0.0.0/0
    leftrsasigkey=0sA[...]
    #
    right=10.11.12.13
    rightid=@branch2
    righsubnet=10.0.2.0/24
    rightrsasigkey=0sAYYYY[...]
    #
    auto=start
    authby=rsasigkey
branch1 オフィスでは、同一の接続を使用します。さらに、パススルー (pass-through) 接続を使用して、ローカル 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
    righsubnet=10.0.1.0/24
    rightrsasigkey=0sAYYYY[...]
    #
    auto=start
    authby=rsasigkey

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

2.7.9. Openswan を使ったロードウォリアーアプリケーション

ロードウォリアーとは、ノート PC などのモバイルクライアントを使用する移動ユーザーのことで、これらのクライアントには動的に IP アドレスが割り当てられます。これは、証明書を使って認証します。
サーバー上で次を行います。
conn roadwarriors
    left=1.2.3.4
    # if access to the LAN is given, enable this
    #leftsubnet=10.10.0.0/16
    leftcert=gw.example.com
    leftid=%fromcert
    right=%any
    # trust our own Certificate Agency
    rightca=%same
    # allow clients to be behind a NAT router
    rightsubnet=vhost:%priv,%no
    authby=rsasigkey
    # load connection, don't initiate
    auto=add
    # kill vanished roadwarriors
    dpddelay=30
    dpdtimeout=120
    dpdaction=%clear
ロードウォリアーのデバイスであるモバイルクライアント上では、上記の接続に多少変更を加えて使用します。
conn roadwarriors
    # pick up our dynamic IP
    left=%defaultroute
    leftcert=myname.example.com
    leftid=%fromcert
    # right can also be a DNS hostname
    right=1.2.3.4
    # if access to the remote LAN is required, enable this
    #rightsubnet=10.10.0.0/16
    # trust our own Certificate Agency
    rightca=%same
    authby=rsasigkey
    # Initiate connection
    auto=start

2.7.10. その他のリソース

以下のソースでは、Openswan および ipsec デーモンに関する追加リソースが提供されています。

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

  • ipsec(8) man ページ — ipsec のコマンドオプションを説明しています。
  • ipsec.conf(5) man ページ — ipsec の設定情報が含まれています。
  • ipsec.secrets(5) man ページ — ipsec.secrets ファイルの形式を説明しています。
  • ipsec_auto(8) man ページ — 鍵の自動交換を使用して確立された Openswan IPsec 接続を操作する auto コマンドラインクライアントの使用方法を説明しています。
  • ipsec_rsasigkey(8) man ページ — RSA 署名鍵の生成に使用するツールを説明しています。
  • openswan-doc パッケージからの /usr/share/doc/openswan-version/README.nssOpenswan pluto デーモンの NSS 暗号化ライブラリーで使用する生 RSA 鍵と証明書の使用に関するコマンドを説明しています。
    yum installopenswan-doc パッケージをインストールすると、追加資料が利用可能になります。

2.7.10.2. 役に立つ Web サイト

http://www.openswan.org
アップストリームプロジェクトの Web サイトです。
http://www.mozilla.org/projects/security/pki/nss/
Network Security Services (NSS) プロジェクトです。

2.8. ファイアウォール

情報セキュリティは、製品ではなくプロセスであると一般的に考えられています。通常、標準的なセキュリティ実装ではある種の専用メカニズムが用いられており、これでアクセス権限の制御や、識別/追跡可能な権限のあるユーザーへのネットワークリソースの制限が行われます。Red Hat Enterprise Linux には、管理者とセキュリティエンジニアを支援する、ネットワークレベルのアクセス制御問題に対処するいくつかのツールが含まれています。
ファイアウォールは、ネットワークセキュリティ実装の中心となるコンポーネントです。ホームユーザー向けの PC 1 台の保護から、重要な企業情報を安全に保護するデータセンターソリューションまでの市場のあらゆるレベルにファイアウォールソリューションを提供しているベンダーがいくつかあります。ファイアウォールには、Cisco、Nokia、Sonicwall などが提供しているファイアウォールアプライアンスなど、スタンドアロンのハードウェアソリューションもあります。また、Checkpoint、McAfee、Symantec などのベンダーが提供する家庭用やビジネス用に開発された専用ソフトウェアのファイアウォールソリューションもあります。
ファイアウォールがハードウェアかソフトウェアであるかに加えて、ファイアウォールの機能方法の違いもソリューションを区別するものとなります。表2.6「ファイアウォールの種類」は、一般的な 3 つのファイアウォールのタイプとその機能について説明しています。

表2.6 ファイアウォールの種類

方法説明利点欠点
NATNetwork Address Translation (NAT) は、プライベート IP サブネットワークを、1 つまたは小規模のパブリック IP アドレスの集合の後ろに置き、すべての要求をいくつかのソースではなく 1 つのソースにマスカレード (変換) します。Linux カーネルには Netfilter カーネルサブシステムによる組み込み NAT 機能があります。
LAN 上のマシンに透過的に設定可能。
多くのマシンとサービスを 1 つ以上の外部 IP アドレスの後方に置いて保護することで、管理業務が簡素化されます。
LAN までの/からのユーザーアクセス制限が、NAT ファイアウォール/ゲートウェイ上のポート開閉により設定できます。
ユーザーがファイアウォールの外側にあるサービスに接続すると悪意あるアクティビティを防ぐことができない。
パケットフィルターパケットフィルタリングファイアウォールは、LAN を通過する各データパケットを読み込みます。ヘッダー情報に基づいてパケットを読み込んでから処理を行い、ファイアウォール管理者により実装されたプログラム可能なルールセットに基づいてパケットをフィルターします。Linux カーネルには Netfilter カーネルサブシステムによる組み込みパケットフィルタリング機能があります。
iptables フロントエンドユーティリティーでカスタマイズ可能。
すべてのネットワーク活動がアプリケーションレベルではなく、ルーターレベルでフィルターされるため、クライアント側でのカスタマイズが不要。
パケットがプロキシ経由で送信されないため、クライアントからリモートホストへのダイレクト接続によりネットワークのパフォーマンスが高速になります。
プロキシファイアウォールのようなコンテンツに対するパケットをフィルターできない。
プロトコル層でパケット処理をするが、アプリケーション層ではパケットをフィルターできない。
IP マスカレードまたはローカルサブネットおよび DMZ ネットワークと使用されている場合、複雑なネットワークアーキテクチャーのためにパケットフィルタリングのルール設定が難しくなる可能性がある。
プロキシプロキシファイアウォールは、LAN クライアントからプロキシマシンへの特定のプロトコルまたは種類の要求をすべてフィルターします。次に、その要求をローカルクライアントに代わってインターネットに送ります。プロキシマシンは、悪意あるリモートユーザーと内部ネットワーククライアントマシン間のバッファとして機能します。
LAN の外側で機能するアプリケーションとプロトコルを管理者が制御できる。
プロキシサーバーの中には、頻繁にアクセスするデータを要求するのにインターネット接続を使うのではなく、ローカルにキャッシュできるものもあります。これにより、帯域の消費量を低減できます。
プロキシサービスはログ記録を取り、厳重に監視することができるので、ネットワーク上のリソース利用を厳しく制御することができる。
プロキシはアプリケーション固有 (HTTP、Telnet など) またはプロトコル制限された場合が多い (多くのプロキシは TCP 接続のサービスでのみ機能)。
アプリケーションサービスはプロキシの後方で実行できないため、アプリケーションサーバーには別の形態のネットワークセキュリティを使用する必要がある。
すべての要求と送信が、クライアントからリモートサービスに直接実行されるのではなく、1 つのソースからやりとりされるため、プロキシがネットワークのボトルネックになる可能性がある。

2.8.1. Netfilter と IPTables

Linux カーネルは、Netfilter と呼ばれる強力なネットワークサブシステムを特長としています。Netfilter サブシステムは、NAT および IP マスカレードのサービスのほかにも、ステートフルまたはステートレスのパケットフィルタリング機能を提供します。また、Netfilter には、高ルーティングや接続状態の高度な管理のために IP ヘッダー情報を分割 (マングル: mangle) する機能もあります。Netfilter は iptables ツールを使って制御されます。

2.8.1.1. IPTables の概要

Netfilter の強力な機能と柔軟性は、iptables 管理ツールを使って実行されます。このコマンドラインツールは、その前身である ipchains (Linux カーネル 2.4 以上で Netfilter/iptables に置き換えられる) の構文と似ています。
iptables は、Netfilter サブシステムを使用してネットワークの接続、検査および処理などを強化します。iptables は、高度なロギング、プレルーティングとポストルーティングの動作、ネットワークアドレス変換およびポート転送機能すべてをオールインワンの 1 つのコマンドラインインターフェースで実現します。
本セクションでは、iptables の概要を説明します。詳細は、「IPTables」を参照してください。

2.8.2. 基本的なファイアウォールの設定

ビルの防火壁 (ファイアウォール) が火が拡散するのを防ぐのと同様に、コンピューターのファイアウォールは悪意のあるソフトウェアがコンピューターに拡散することを防ぐためのものです。また、許可されていないユーザーによるコンピューターへのアクセスの防止にも役立ちます。
デフォルトの Red Hat Enterprise Linux インストールでは、ファイアウォールはコンピューターまたはネットワークと、信頼できないネットワーク (インターネットなど) との間に置かれます。ファイアウォールは、リモートユーザーがコンピューター上でアクセス可能なサービスを決定します。ファイアウォールを適切に設定すると、システムのセキュリティが大幅に向上します。インターネットに接続する Red Hat Enterprise Linux システムすべてに対してファイアウォールを設定することが推奨されます。

2.8.2.1. Firewall Configuration Tool

Red Hat Enterprise Linux インストールの ファイアウォールの設定 画面には、基本的なファイアウォールを有効にするオプションのほかにも、特定のデバイス、受信サービスおよびポートを許可するオプションが提供されています。
この設定は、インストール後に Firewall Configuration Tool を使用して変更することができます。
このアプリケーションを起動するには、パネルから システム管理ファイアーウォール を選択するか、シェルプロンプトに system-config-firewall を入力します。
Firewall Configuration Tool

図2.5 Firewall Configuration Tool

注記

Firewall Configuration Tool では、基本的なファイアウォールのみが設定されます。システムでより複雑なルールが必要となる場合は、iptables の特定ルールの設定方法について 「IPTables」を参照してください。
Red Hat Enterprise Linux 6.5 では、デフォルトの設定が適用できない場合、iptables サービスや ip6tables サービスがフォールバックのファイアウォール設定を提供します。/etc/sysconfig/iptables にあるファイアウォールルールの適用が失敗した場合、フォールバックファイルが存在していればそのファイルが適用されます。このフォールバックファイルの名前は /etc/sysconfig/iptables.fallback となり、/etc/sysconfig/iptables と同じファイル形式になります。フォールバックファイルの適用も失敗する場合は、 それ以上のフォールバックはありません。フォールバックファイルを作成するには、標準のファイアウォール設定ツールを使用し、そのファイルの名前を変更してフォールバックファイルとするか、ファイルをコピーしてフォールバックファイルとします。
ip6tables サービスでは、上記の例で iptables をすべて ip6tables に置き換えます。

警告

すでに (「IPTables」 にあるように) 直接 iptables ユーティリティーを使用してカスタムのパケットフィルタリングルールを設定してある場合は、system-config-firewall ユーティリティーを実行すると、これら既存のカスタムルールが即座に消去されます。

2.8.2.2. ファイアウォールの有効化および無効化

ファイアウォールで以下のいずれかのオプションを選択します。
  • 無効 — ファイアウォールを無効にしてシステムへの完全なアクセスを提供し、セキュリティチェックを行いません。これは、(インターネットではなく) 信頼されたネットワーク上で稼働しているか、iptables コマンドラインツールを使用してカスタム化したファイアウォールを設定する必要がある場合にのみ選択してください。

    警告

    ファイアウォールの設定とカスタマイズされたファイアウォールのルールは /etc/sysconfig/iptables ファイルに保存されます。無効 を選択して OK を選択すると、これらの設定とファイアウォールのルールは失われます。
  • 有効 — このオプションを設定すると、システムは、DNS 応答や DHCP 要求などのアウトバウンド要求への応答ではない受信接続を拒否します。該当マシンで実行されているサービスへのアクセスが必要な場合は、特定のサービスがファイアウォールを通過できるように選択することが可能です。
    使用中のシステムがインターネットに接続されていて、サーバーを実行する予定がない場合、これが最も安全なオプションになります。

2.8.2.3. 信頼できるサービス

信頼できるサービスの一覧にあるオプションを有効にすると、指定されたサービスがファイアウォールを通過できるようになります。
WWW (HTTP)
HTTP プロトコルは、Web ページに対応するために Apache (およびその他の Web サーバー) が使用します。Web サーバーを一般利用可能とする予定であれば、このチェックボックスを選択します。このオプションは、ページをローカルに表示したり、Web ページを開発したりする場合には不要です。このサービスでは、httpd パッケージがインストールされていることが前提になります。
WWW (HTTP) を有効にしても、HTTPS (SSL バージョンの HTTP) 用のポートは開きません。このサービスが必要な場合は、Secure WWW (HTTPS) チェックボックスを選択します。
FTP
FTP プロトコルは、ネットワーク上のマシン間でファイルを転送するために使用されます。FTP サーバーを一般利用可能とする予定であれば、このチェックボックスを選択します。このサービスでは vsftpd パッケージがインストールされていることが前提になります。
SSH
Secure Shell (SSH) は、リモートマシンにログインしてコマンドを実行するためのツールです。SSH を使ったマシンへのリモートアクセスを許可するには、このチェックボックスを選択します。このサービスでは、openssh-server パッケージがインストールされている必要があります。
Telnet
Telnet はリモートマシンにログインするためのプロトコルです。Telnet 通信は暗号化されず、ネットワーク上のなりすましに対するセキュリティ対策は提供されません。着信 Telnet アクセスを許可することは推奨されません。Telnet によるマシンへのリモートアクセスを許可するには、このチェックボックスを選択します。このサービスでは、telnet-server パッケージがインストールされていることが前提になります。
Mail (SMTP)
SMTP は、メール配信のためにリモートホストがマシンに直接接続することを許可するプロトコルです。POP3 や IMAP を使って ISP のサーバーからメールを収集しているか、fetchmail のようなツールを使用している場合には、このサービスを有効にする必要はありません。マシンへのメール配信を許可するには、このチェックボックスを選択します。SMTP サーバーが適切に設定されていないと、リモートマシンがご利用のサーバーを使用してスパムを送る可能性があることに注意してください。
NFS4
Network File System (NFS) は *NIX システムで一般的に使われているファイル共有プロトコルです。このプロトコルのバージョン 4 は、それ以前のバージョンよりも安全です。システムにあるファイルやディレクトリーを他のネットワークユーザーと共有する場合に、このチェックボックスを選択します。
Samba
Samba は Microsoft の専用 SMB ネットワークプロトコルの実装です。ファイル、ディレクトリーまたはローカル接続プリンターを Microsoft Windows マシンと共有する必要がある場合は、このチェックボックスを選択します。

2.8.2.4. 他のポート

Firewall Configuration Tool には、iptables によって信頼される個別 IP ポートを指定するための Other ports (他のポート) セクションがあります。例えば、IRC と Internet printing protocol (IPP) がファイアウォールを通過できるようにするには、Other ports (他のポート) セクションに以下を追加します。
194:tcp,631:tcp

2.8.2.5. 設定の保存

変更を保存するには OK をクリックして、ファイアウォールを有効または無効にします。ファイアウォールを有効にする が選択されている場合、選択されたオプションが iptables コマンドに変換され、 /etc/sysconfig/iptables ファイルに書き込まれます。選択されたオプションの保存後すぐにファイアウォールが有効になるように、iptables サービスも開始されます。ファイアウォールを無効化する が選択されると、 /etc/sysconfig/iptables ファイルが削除され、 iptables サービスは直ちに停止されます。
選択されたオプションは、アプリケーションの次回起動時に設定を復元できるように /etc/sysconfig/system-config-firewall ファイルにも書き込まれます。このファイルは手動では編集しないでください。
ファイアウォールを即座に有効にしても、 iptables サービスはブート時に自動的に開始するようには設定されません。詳細は、「IPTables サービスの有効化」を参照してください。

2.8.2.6. IPTables サービスの有効化

ファイアウォールのルールは、iptables サービスが実行されている場合にのみ有効です。サービスを手動で開始するには、以下のコマンドを root ユーザーとして実行します。
~]# service iptables restart
iptables: Applying firewall rules:                         [  OK  ]
iptables がシステムのブート時に確実に開始されるようにするには、以下のコマンドを使用します。
~]# chkconfig --level 345 iptables on

2.8.3. IPTables の使用

iptables を使用する最初にステップとして、iptables サービスを開始します。iptables サービスを開始するには、以下のコマンドを root ユーザーとして実行します。
~]# service iptables restart
iptables: Applying firewall rules:                         [  OK  ]

注記

iptables サービスのみを使用する場合には、ip6tables をオフにすることができます。ip6tables サービスを無効にする場合には、必ず IPv6 ネットワークも無効にするようにしてください。対応するファイアウォールがない状態でネットワークデバイスを有効にしないでください。
システムのブート時に iptables の起動をデフォルトで強制するには、以下のコマンドを root ユーザーとして実行します。
~]# chkconfig --level 345 iptables on
これにより、システムがランレベル 3、4、または 5 にブートされる際には常に iptables が強制的に起動します。

2.8.3.1. IPTables コマンド構文

以下のサンプルの iptables コマンドは、基本的なコマンド構文を示しています。
iptables -A <chain> -j <target>
-A オプションは、<chain> に追加されるルールを指定します。それぞれのチェーンは 1 つ以上のルールから構成されているため、ルールセットとも呼ばれます。
INPUT、OUTPUT、および FORWARD という 3 つの組み込みチェーンがあります。これらのチェーンは永続するもので、削除することはできません。チェーンはパケットを処理するポイントを指定します。
-j <target> オプションは、ルールのターゲット、つまりパケットがルールに一致した場合に何が実行されるかを指定します。組み込まれたターゲットの例には、ACCEPT、 DROP および REJECT があります。
利用可能なチェーン、オプションおよびターゲットに関する詳細は、 iptables man ページを参照してください。

2.8.3.2. 基本的なファイアウォールポリシー

基本的なファイアウォールポリシーを確立すると、より詳細なユーザー定義ルールを作成する基礎が形成されます。
iptables チェーンは、ファイアウォールのルールセット全体を定義するための、デフォルトポリシーとデフォルトポリシーと連動するルール (ルールなしの場合もあり) で構成されています。
チェーンのデフォルトポリシーは、DROP または ACCEPT のいずれかです。セキュリティ志向の管理者はデフォルトポリシーに DROP を実装するのが一般的であり、またケースバイケースで特定のパケットのみを許可します。例えば、以下のポリシーは、ネットワークゲートウェイですべての着信パケットと発信パケットをブロックします。
~]# iptables -P INPUT DROP
~]# iptables -P OUTPUT DROP
さらに、不注意による内部クライアントのインターネット接続を制限するには、すべての転送パケット(ファイアウォールから宛先ノードにルーティングされるネットワークトラフィック) を拒否することも推奨されます。
~]# iptables -P FORWARD DROP
それぞれのチェーンのデフォルトポリシーを設定した後に、特定のネットワークについてのルールやセキュリティ要件を追加で作成し、保存することができます。
以下のセクションでは、iptables ルールを保存する方法を説明し、iptables ファイアウォールを構築する過程で実装する可能性のあるいくつかのルールの概要を示します。

2.8.3.3. IPTables ルールの保存と復元

iptables への変更は一時的な変更です。システムが再起動するか、または iptables サービスが再起動する場合に、ルールは自動的にフラッシュされ、リセットされます。ルールを保存して iptables サービスの起動時にルールが読み込まれるようにするには、以下のコマンドを root ユーザーとして実行します。
~]# service iptables save
iptables: Saving firewall rules to /etc/sysconfig/iptables:[  OK  ]
ルールはファイル /etc/sysconfig/iptables に保存され、サービスの起動時またはマシンの再起動時に常に適用されます。

2.8.4. 一般的な IPTables によるフィルタリング

リモート攻撃者による LAN へのアクセスを防ぐことは、ネットワークセキュリティの最も重要な側面です。厳しいファイアウォールルールで、悪意のあるリモートユーザーから LAN の完全性を保護する必要があります。
しかし、デフォルトポリシーですべての着信パケット、発信パケットおよび転送パケットをブロックするように設定すると、ファイアウォール/ゲートウェイと内部 LAN ユーザーが相互に通信したり、外部リソースと通信することができなくなります。
ユーザーがネットワーク関連の機能を実行し、ネットワークアプリケーションを使用できるようにするには、管理者は通信用に特定のポートを開く必要があります。
例えば、ファイアウォール上でポート80 へのアクセスを許可するには、以下のルールを追加します。
~]# iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
これにより、標準的なポート 80 を使用して通信する Web サイトをブラウズできるようになります。セキュアな Web サイト (https://www.example.com/など) へのアクセスを許可するには、 以下のようにポート 443 へのアクセスも提供する必要があります。
~]# iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT

重要

iptables ルールセットを作成する際、その順序は重要になります。
例えば、ルールが 192.168.100.0/24 サブネットからのパケットをすべて破棄することを指定しており、192.168.100.13 (破棄したサブネットに含まれる) からのパケットを許可するルールがこれに続く場合、この 2 番目のルールは無視されます。
そのため、192.168.100.13 からのパケットを許可するルールを設定してから、サブネットの残りを破棄するルールを設定する必要があります。
既存のチェーンで特定の位置にルールを挿入するには、-I オプションを使用します。例えば、以下のようになります。
~]# iptables -I INPUT 1 -i lo -p all -j ACCEPT
このルールは、ローカルのループバックデバイスのトラフィックを許可するために INPUT チェーンの最初のルールとして挿入されます。
LAN へのリモートアクセスが必要になることも時にあるでしょう。SSH などのセキュアなサービスを使用して、LAN サービスへの暗号化されたリモート接続を確立することができます。
PPP ベースのリソース (モデムバンクまたは大量の ISP アカウントなど)がある管理者の場合、ダイアルアップアクセスを使用して、ファイアウォールのバリアを安全に回避することができます。モデムは直接接続されているので、これは一般的にはファイアウォール/ゲートウェイの後ろで行われます。
しかし、ブロードバンド接続を使用しているリモートユーザーの場合には、特殊な方法が適用できます。リモート SSH クライアントからの接続を受け入れるように iptables を設定できます。例えば、以下のルールを使用してリモート SSH のアクセスを許可できます。
~]# iptables -A INPUT -p tcp --dport 22 -j ACCEPT
~]# iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT
これらのルールは、インターネットまたはファイアウォール/ゲートウェイに直接接続されている単一 PC などの個別システムへの受信アクセスと送信アクセスを許可します。しかしこれらのルールは、ファイアウォール/ゲートウェイの後ろにあるノードがこれらのサービスにアクセスすることを許可しません。これらのサービスへの LAN アクセスを許可するには、iptables のフィルタリングルールと共に Network Address Translation (NAT) を使用することができます。

2.8.5. FORWARD および NAT ルール

ほとんどの ISP では、取引先の組織に提供する一般に迂回可能な IP アドレスの数は制限しています。
そのため、LAN 上のすべてのノードにパブリック IP アドレスを与えずに、インターネットサービスへのアクセスを共有する代替方法を管理者が見つける必要があります。最も一般的な方法はプライベート IP アドレスの 使用で、LAN 上のすべてのノードが内外のネットワークサービスに適切にアクセスできるようになります。
エッジルーター (ファイアウォールなど) はインターネットからの着信通信を受け取り、パケットを目的の LAN ノードに送ります。同時に、ファイアウォール/ゲートウェイは LAN ノードからの発信要求をリモートインターネットサービスに送ります。
このネットワークトラフィックの転送は時に危険を伴うことがあり、特に最新のクラッキングツールを利用できる場合には危険性が高まります。このツールを使うと、内部 IP アドレスになりすますことができ、リモート攻撃者のマシンを LAN 上のノードとして動作させることができます。
これを防ぐために、iptables はネットワークリソースの変則的使用を防ぐために実装されるルーティングポリシーと転送ポリシーを提供します。
FORWARD チェーンを使うと、管理者は LAN 内でパケットのルーティングを制御できるようになります。例えば、LAN 全体を対象にした転送を許可するには、以下のルールを使用します (ファイアウォール/ゲートウェイに eth1 の内部 IP アドレスが割り当てられていると仮定します)。
~]# iptables -A FORWARD -i eth1 -j ACCEPT
~]# iptables -A FORWARD -o eth1 -j ACCEPT
このルールにより、ファイアウォール/ゲートウェイの外側にあるシステムが内部ネットワークにアクセスできるようになります。また、ゲートウェイは、eth1 デバイスを経由するすべてのパケットを通過させ、パケットを LAN ノードから目的の宛先ノードにルーティングします。

注記

Red Hat Enterprise Linux カーネルにおける IPv4 ポリシーは、IP 転送のサポートをデフォルトで無効にします。これは、Red Hat Enterprise Linux を稼働するマシンが専用のエッジルーターとして機能することを防ぎます。IP 転送を有効にするには、以下のコマンドを root で実行します。
~]# sysctl -w net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1
この設定変更は、現行セッションにおいてのみ有効です。再起動やネットワークサービスの再起動の後には永続しません。IP 転送を永続的に設定するには、以下のように /etc/sysctl.conf ファイルを編集します。
以下の行を見つけます。
net.ipv4.ip_forward = 0
以下のように編集します。
net.ipv4.ip_forward = 1
sysctl.conf ファイルへの変更を有効にするには、以下のコマンドを root ユーザーとして実行します。
~]# sysctl -p /etc/sysctl.conf
net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0[出力は省略されています]

2.8.5.1. ポストルーティングと IP マスカレード

ファイアウォールの内部 IP デバイスを経由して転送されたパケットが受け入れられると、LAN ノードの相互通信が可能になります。ただし、インターネットへの外部通信はできません。
プライベート IP アドレスを持つ LAN ノードに外部のパブリックネットワークとの通信を許可するには、IP マスカレード用にファイアウォールを設定します。IP マスカレードは、LAN ノードからの要求をファイアウォールの外部デバイス (この場合は eth0) の IP アドレスでマスクします。
~]# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
上記のルールでは、NAT パケットのマッチングテーブル (-t nat) を使用して、ファイアウォールの外部ネットワークデバイス (-o eth0) に NAT 用の組み込み POSTROUTING チェーン (-A POSTROUTING) を指定しています。
POSTROUTING は、パケットがファイアウォールの外部デバイスを離れる際にパケットが変更されることを許可します。
-j MASQUERADE のターゲットは、ノードのプライベート IP アドレスを、ファイアウォール/ゲートウェイの外部 IP アドレスでマスクするために指定されます。

2.8.5.2. プレルーティング

内部ネットワーク上にサーバーがあり、このサーバーを外部から利用可能としたい場合、NAT の PREROUTING チェーンの -j DNAT ターゲットを使用して、内部サービスへの接続を要求する着信パケットを転送する宛先 IP アドレスとポートを指定することができます。
例えば、着信 HTTP 要求を 172.31.0.23 の専用 Apache HTTP Server に転送する場合は、以下のコマンドを使用します。
~]# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to 172.31.0.23:80
このルールは、NAT テーブルが組み込み PREROUTING チェーンを使って、リストされている宛先 IP アドレス 172.31.0.23 にのみ着信 HTTP 要求を転送することを指定します。

注記

FORWARD チェーンに DROP のデフォルトポリシーが設定されている場合、宛先の NAT ルーティングが可能になるように、すべての着信 HTTP 要求を転送するルールを追加しなければなりません。これを実行するには、以下のコマンドを root ユーザーとして実行します。
~]# iptables -A FORWARD -i eth0 -p tcp --dport 80 -d 172.31.0.23 -j ACCEPT
このルールは、すべての着信 HTTP 要求を、ファイアウォールから目的の宛先 (ファイアウォールの後ろにある Apache HTTP Server) に転送します。

2.8.5.3. DMZ と IPTables

iptables ルールを作成して、非武装地帯 (DMZ) にある専用の HTTP や FTP サーバーなどの特定マシンにトラフィックを送信できます。DMZ は、インターネットなどの一般のキャリアのネットワーク上でサービスを提供することに特化した特殊なローカルサブネットワークです。
例えば、10.0.4.2 (LAN の 192.168.1.0/24 範囲外) にある専用の HTTP サーバーに着信 HTTP 要求をルーティングするためのルールを設定するため、NAT は PREROUTING テーブルを使って、パケットを適切な宛先に転送します。
~]# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT \
  --to-destination 10.0.4.2:80
このコマンドを使うと、LAN 外からのポート 80 へのすべての HTTP 接続が、内部ネットワークの他の部分から分離されたネットワーク上の HTTP サーバーにルート指定されます。ネットワークセグメントのこの形態は、ネットワーク上のマシンへの HTTP 接続を許可するよりも安全であることが明らかになっています。
HTTP サーバーがセキュアな接続を受け付けるよう設定されている場合、ポート443 も転送する必要があります。

2.8.6. 悪意のあるソフトウェアと偽装された IP アドレス

詳細なルールを作成すると、LAN 内の特定のサブネットまたは特定のノードへのアクセスを制御することができます。また、トロイの木馬、ワーム、およびクライアント/サーバーのウイルスなどの特定の疑わしいアプリケーションやプログラムがサーバーに接触することを制限することもできます。
例えば、一部のトロイの木馬は 31337 から 31340 までのポート (クラッキング用語で elite ポートと呼ばれる) にあるサービスについてネットワークをスキャンします。
これらの非標準的なポート経由で通信することが許可されたサービスはないため、それらをブロックしてしまうことで、ネットワーク上の感染の恐れのあるノードがリモートマスターサーバーと独自に通信するリスクを軽減することができます。
以下のルールは、ポート 31337 を使用しようとするすべての TCP トラフィックを接続します。
~]# iptables -A OUTPUT -o eth0 -p tcp --dport 31337 --sport 31337 -j DROP
~]# iptables -A FORWARD -o eth0 -p tcp --dport 31337 --sport 31337 -j DROP
また、LAN に潜入するためにプライベート IP アドレス範囲になりすましを試みる外部接続をブロックすることもできます。
例えば、LAN が 192.168.1.0/24 範囲を使用している場合、インターネットにつながっているネットワークデバイス (eth0 など) に対し、LAN の IP 範囲にあるアドレスを持つ、そのデバイスへのパケットすべてを破棄するように指示するルールを設計できます。
デフォルトポリシーでは転送パケットを拒否することが推奨されているため、外部につながっているデバイス (eht0) へのいずれの偽装された IP アドレスも自動的に拒否されます。
~]# iptables -A FORWARD -s 192.168.1.0/24 -i eth0 -j DROP

注記

appended ルールを扱う際には、DROPREJECT ターゲットを区別する必要があります。
REJECT ターゲットは、アクセスを拒否し、サービスに接続するユーザーに connection refused エラーを返します。DROP ターゲットは、名前が示すように、警告なしにパケットを破棄します。
管理者は、各自の裁量でこれらのターゲットを使用できます。

2.8.7. IPTables と接続追跡 (Connection Tracking)

サービスへの接続の検査と制限は、接続状態に基づいて行うことができます。iptables 内のモジュールは、接続追跡 (connection tracking) と呼ばれる方法を使用して、着信接続についての情報を保存します。以下の接続状態に基づいてアクセスを許可または拒否することができます。
  • NEW — HTTP 要求などの新規接続を要求するパケット
  • ESTABLISHED — 既存の接続の一部であるパケット
  • RELATED — 新規接続を要求しているが、既存の接続の一部であるパケット。例えば、FTP は接続を確立するためにポート 21 を使用しますが、データは異なるポート (通常はポート 20) で転送されます。
  • INVALID — 接続追跡テーブルの接続の一部ではないパケット
プロトコル自体がステートレスな場合でも (UDP など)、 iptables の接続追跡のステートフルな機能を任意のネットワークプロトコルと共に使用することができます。以下の例は、既存の接続と関連付けられたパケットのみを転送するために接続追跡を使用するルールを示しています。
~]# iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

2.8.8. IPv6

IPv6 と呼ばれる次世代インターネットプロトコルの導入により、IPv4 (または IP) の 32 ビットアドレスの限界を超えるようになりました。IPv6 は 128 ビットアドレスをサポートするため、IPv6 対応のキャリアのネットワークは IPv4 よりも多くのルート可能なアドレスを割り当てることができます。
Red Hat Enterprise Linux は、Netfilter 6 サブシステムと ip6tables コマンドを使用する IPv6 ファイアウォールのルールをサポートしています。Red Hat Enterprise Linux 6 では、IPv4 と IPv6 のサービスがどちらもデフォルトで有効になっています。
ip6tables コマンドの構文は、128 ビットアドレスをサポートする点を別にすれば、すべての点で iptables と同じです。例えば、IPv6 対応のネットワークサーバーで SSH 接続を有効にするには、以下のコマンドを実行します。
~]# ip6tables -A INPUT -i eth0 -p tcp -s 3ffe:ffff:100::1/128 --dport 22 -j ACCEPT
IPv6 ネットワークの詳細については、http://www.ipv6.org/ にある IPv6 情報ページを参照してください。

2.8.9. IPTables

Red Hat Enterprise Linux には、ネットワークパケットフィルタリングの高度なツールが含まれています。パケットフィルタリングとは、ネットワークパケットがカーネル内のネットワークスタックに入る、移動する、または出るときに、これらを制御するプロセスです。カーネルの 2.4 より前のバージョンはパケットフィルタリングに ipchains を使用して、パケットに適用されるルールのリストがフィルタリングプロセスの各ステップで使われていました iptables (netfilter とも呼ばれる) は、カーネル 2.4 から導入されました。これは、ipchains と似ていますが、ネットワークパケットのフィルタリングに利用できる範囲と制御が大幅に拡大されました。
本章は、パケットフィルタリングの基礎に焦点を当て、 iptables コマンドで選択できるさまざまなオプションや、フィルタリングルールがシステム再起動時にどのように保持存されるかを説明します。

重要

カーネル 2.4 以降におけるデフォルトのファイアウォールメカニズムは iptables です。しかし、 ipchains がすでに実行されている場合は iptables を使用できません。 ipchains が起動時に存在していると、カーネルがエラーを起こし、iptables を起動することができません。
ipchains の機能自体には、これらのエラーによる影響はありません。

2.8.9.1. パケットフィルタリング

Linux カーネルは、パケットのフィルタリングに Netfilter 機能を使用します。この機能を使うことで、一部のパケットをシステムから受け取ったり、通過させたりする一方で、他のパケットを停止させます。この機能は Linux カーネルに組み込まれ、以下の 5 つの組み込みテーブルまたはルールリストで構成されています。
  • filter — ネットワークパケットを処理するためのデフォルトテーブルです。
  • nat — 新規の接続を作成するパケット変換に使用され、ネットワークアドレス変換 (NAT: Network Address Translation) で使用されます。
  • mangle — 特定の種類のパケット変換に使用されます。
  • raw — NOTRACK ターゲットと組み合わせた接続追跡の適用除外を設定するために主に使用されます。
  • security — SECMARK や CONNSECMARK ターゲットで有効とされる強制アクセス制御 (MAC) のネットワークルールに使用されます。
各テーブルには、組み込みチェーンがグループ化されており、これらのチェーンは netfilter がパケットに実行するアクションに対応しています。
filter テーブルの組み込みチェーンは以下の通りです。
  • INPUT — ホスト宛のネットワークパケットに適用されます。
  • OUTPUT — ローカルに生成されたネットワークパケットに適用されます。
  • FORWARD — ホスト経由でルーティングされるネットワークパケットに適用されます。
nat テーブルの組み込みチェーンは以下の通りです。
  • PREROUTING — ネットワークパケットが入ってくる際に適用されます。
  • OUTPUT — ローカルで生成されたネットワークパケットが出ていく前に適用されます。
  • POSTROUTING — ネットワークパケットが出ていく前に適用されます。
mangle テーブルの組み込みチェーンは以下の通りです。
  • INPUT — ホスト宛のネットワークパケットに適用されます。
  • OUTPUT — ローカルで生成されたネットワークパケットが出ていく前に適用されます。
  • FORWARD — ホスト経由でルーティングされるネットワークパケットに適用されます。
  • PREROUTING — 着信ネットワークパケットがルーティングされる前に適用されます。
  • POSTROUTING — ネットワークパケットが出ていく前に適用されます。
raw テーブルの組み込みチェーンは以下の通りです。
  • OUTPUT — ローカルで生成されたネットワークパケットが出ていく前に適用されます。
  • PREROUTING — 着信ネットワークパケットがルーティングされる前に適用されます。
security テーブルの組み込みチェーンは以下の通りです。
  • INPUT — ホスト宛のネットワークパケットに適用されます。
  • OUTPUT — ローカルで生成されたネットワークパケットが出ていく前に適用されます。
  • FORWARD — ホスト経由でルーティングされるネットワークパケットに適用されます。
Linux システムが受信する、またはそこから送信されるネットワークパケットはすべて、少なくとも 1 つのテーブルの対象となります。しかし、パケットはチェーンの最後に達する前に各テーブル内の複数のルールに従うことになります。これらルールの構造と目的は異なる場合がありますが、通常、それらのルールは、特定のプロトコルおよびネットワークサービスを使用する際に、特定の IP アドレスまたはアドレスのセットから着信する、またはそこに送信されるパケットを特定することを目的としています。以下の図は、iptables サブシステムがパケットのフローを検査するプロセスの概要を示しています。
IPTables におけるパケットのフィルタリング

図2.6 IPTables におけるパケットのフィルタリング

重要

ファイアウォールのルールは、デフォルトで /etc/sysconfig/iptables または /etc/sysconfig/ip6tables ファイルに保存されます。
Linux システムのブート時に、iptables サービスは DNS 関連サービスの前に起動します。これは、ファイアウォールのルールが数値 IP アドレス (例: 192.168.0.1) のみを参照できることを意味しています。このようなルールにドメイン名 (例: host.example.com) が含まれると、エラーが発生します。
パケットがいずれかのテーブルにある特定のルールにマッチする場合、その宛先に関わらず、ターゲット またはアクションがそれらのパケットに適用されます。マッチしたパケットに対して ACCEPT ターゲットがルールで指定されていると、パケットの残りのルールチェックは省略され、宛先への送信が続行されます。ルールが DROPターゲットを指定していると、パケットのシステムへのアクセスは拒否され、パケットを送ったホストには何も通知されません。ルールが QUEUE ターゲットを指定していると、パケットはユーザースペースに渡されます。ルールがオプションの REJECT ターゲットを指定していると、パケットは破棄されますが、エラーパケットがパケットの送信者に送られます。
すべてのチェーンには、ACCEPTDROPREJECT または QUEUE のデフォルトポリシーが設定されます。チェーン内のいずれのルールもパケットに適用されない場合、パケットはデフォルトポリシーに従って処理されます。
iptables コマンドは前述のテーブルを設定し、必要に応じて新規のテーブルをセットアップします。

注記

デフォルトでは、netfilter モジュールは読み込まれません。このため、ユーザーは /proc/ ディレクトリーでは、これらのモジュールすべては確認できません。使用中のものまたは既に読み込み済みのものだけが表示されます。つまり、netfilter の使用前には、どの機能が利用可能かを確認する方法はないということになります。

2.8.9.2. IPTables のコマンドオプション

パケットのフィルタリングに使用されるルールは、iptables コマンドを使用して作成されます。多くの場合、パケットの以下の要素が条件として使用されます。
  • Packet Type — コマンドがフィルターするパケットの種類を指定します。
  • Packet Source/Destination — パケットの送信元または宛先に基づいてコマンドがフィルターするパケットを指定します。
  • Target — 上記の条件にマッチするパケットに対して取られるアクションを指定します。
上記のパケットの要素に関連する具体的なオプションについての詳細は、「 IPTables マッチオプション」および「ターゲットオプション」を参照してください。
特定の iptables ルールと共に使用されるオプションは、ルールを有効にするためにルール全体の目的と条件に基づいて論理的にグループ化される必要があります。本セクションの残りの部分では、 iptables コマンドで一般的に使われる各種オプションを説明します。
2.8.9.2.1. IPTables コマンドオプションの構造
以下は、多くの iptables コマンドが持つ構造です。
iptables [-t <table-name>] <command> <chain-name> \
  <parameter-1> <option-1> \
  <parameter-n> <option-n>
<table-name> — ルールが適用されるテーブルを指定します。省略時は、 filter テーブルが使用されます。
<command> — ルールの追加または削除などの、実行するアクションを指定します。
<chain-name> — 編集、作成または削除するチェーンを指定します。
<parameter>-<option> のペア — ルールにマッチするパケットをどのように処理するかを指定するパラメーターおよび関連するオプションです。
iptables コマンドの長さと複雑度は、目的によって大きく変わります。
例えば、チェーンからルールを削除するコマンドは非常に短くなります。
iptables -D <chain-name> <line-number>
これとは対照的に、各種の特定のパラメーターとオプションを使って特定のサブネットからパケットをフィルターするルールを追加するコマンドの場合は、かなり長くなる可能性があります。iptables コマンドを構築する際には、一部のパラメーターとオプションにおいて、有効なルールを構築するためにさらなるパラメーターとオプションが必要になることに注意してください。これにより、追加されるパラメーターでさらに多くのパラメーターが必要になるというカスケード効果が生じる可能性があります。追加のオプションセットを必要とするパラメーターとオプションがなくなるまで、ルールは有効になりません。
iptables コマンド構造の完全なリストを表示するには、iptables -h を入力します。
2.8.9.2.2. コマンドオプション
コマンドオプションは、特定のアクションを実行するよう iptables に指示します。 1 つの iptables コマンドあたりコマンドオプション 1 つのみが許可されます。help コマンドを除いて、すべてのコマンドは大文字で書かれます。
iptables コマンドのオプションは以下のようになります。
  • -A — 指定されたチェーンの最後にルールを追加します。以下で説明される -I オプションとは異なり、整数の引数を取りません。常に指定されたチェーンの最後にルールを追加します。
  • -D <integer> | <rule> — 数値 (チェーンにある 5 番目のルールは 5 など) か、またはルールの指定により特定チェーンにあるルールを削除します。ルールを指定する場合は、既存のルールと完全に一致するものでなければなりません。
  • -E — ユーザー定義のチェーンの名前を変更します。ユーザー定義のチェーンはデフォルトの既存チェーン以外のすべてのチェーンです。(ユーザー定義のチェーンを作成する方法についての詳細は、以下の -N オプションを参照してください。) これは表面的な変更であり、テーブルの構造には影響を与えません。

    注記

    デフォルトのチェーンのいずれかの名前を変更しようとする場合、システムは Match not found エラーを報告します。デフォルトのチェーン名を変更することはできません。
  • -F — 選択されたチェーンをフラッシュします。これにより、チェーンにあるすべてのルールが効率的に削除されます。チェーンが指定されていない場合は、このコマンドはすべてのチェーンからすべてのルールをフラッシュします。
  • -h —コマンド構造の一覧、およびコマンドパラメーターとオプションの要約を提供します。
  • -I [<integer>] — ユーザー定義の整数引数で指定される位置に、指定されたチェーンのルールを挿入します。引数が指定されていない場合は、ルールはチェーンの一番上に挿入されます。

    重要

    前述のようにチェーン内のルールの順序は、どのルールがどのパケットに適用されるかを決定します。これは、-A または -I オプションのいずれかを使用してルールを追加する際に覚えておくべき重要な点です。
    これは、整数の引数と共に -I を使用してルールを追加する場合に、特に重要な点になります。ルールをチェーンに追加する際に既存の数値を指定する場合、iptables は既存のルールの (または上) に新しいルールを追加します。
  • -L — コマンドの後ろに指定するチェーン内のすべてのルールを表示します。デフォルトの filter テーブルにあるすべてのチェーンのすべてのルールを表示するには、チェーンまたはテーブルを指定しないでください。それ以外の場合は、以下の構文を使用して、特定のテーブルの指定したチェーン内のルールを表示します。
    iptables -L <chain-name> -t <table-name>
    ルール番号を提供し、より詳細なルールの説明を提供する -L コマンドオプションの追加のオプションについては、「リストのオプション」に説明されています。
  • -N — ユーザー指定の名前を用いて新しいチェーンを作成します。チェーン名は一意である必要があり、そうでない場合はエラーメッセージが表示されます。
  • -P — 指定したチェーンに対するデフォルトのポリシーを設定します。これにより、パケットがルールにマッチせずにチェーン全体をトラバースする際に、パケットは ACCEPT または DROP などの指定されたターゲットに送られます。
  • -R — 指定されたチェーン内のルールを置き換えます。ルールの番号は必ずチェーン名の後ろに指定します。チェーン内の最初のルールはルール番号 1 に対応します。
  • -X — ユーザー指定のチェーンを削除します。組み込みチェーンは削除できません。
  • -Z — テーブルについてのすべてのチェーンのバイトカウンターとパケットカウンターをゼロに設定します。
2.8.9.2.3. IPTables パラメーターのオプション
特定のチェーン内でのルールの追加、削除、挿入また置換に使われるコマンドを含む、特定の iptables コマンドでは、パケットフィルタリングルールを作成するためにさまざまなパラメーターが必要になります。
  • -c — 特定のルールについてのカウンターをリセットします。このパラメーターはどのカウンターをリセットするかを指定するために PKTS および BYTES オプションを受け付けます。
  • -d — ルールにマッチするパケットの宛先ホスト名、IP アドレスまたはネットワークを設定します。ネットワークにマッチする際には、以下の IP アドレス/ネットマスクの形式がサポートされています。
    • N.N.N.N/M.M.M.M — ここでの N.N.N.N は IP アドレスの範囲で、 M.M.M.M はネットマスクです。
    • N.N.N.N/M — ここでの N.N.N.N は IP アドレスの範囲で、 M はビットマスクです。
  • -f — このルールは断片化されたパケットにのみ適用されます。
    このパラメーターの後ろに感嘆符記号 (!) オプションを使用すると、断片化されていないパケットにのみマッチするよう指定できます。

    注記

    断片化されたパケットは IP プロトコルの標準的な一部になっていますが、断片化されたパケットを断片化されていないパケットと区別するのは望ましいことです。
    断片化は、元々は異なるフレームサイズの IP パケットをネットワーク経由で送信できるように設計されましたが、最近では、不正な形式のパケットを使用した DoS 攻撃を生成する目的で使用されることが以前よりも多くなっています。また、IPv6 は断片的を全く許可しないことにも注意してください。
  • -ieth0ppp0 などの入力ネットワークインターフェースを設定します。iptables では、このオプションのパラメーターは filter テーブルと共に使用される場合は INPUT と FORWARD チェーンでのみ使用でき、nat および mangle テーブルと共に使用される場合は PREROUTING チェーンでのみ使用できます。
    このパラメーターは以下の特別なオプションもサポートしています。
    • 感嘆符記号 (!) — 指示文を無効にします。つまり、指定されたインターフェースがこのルールから除外されます。
    • プラス記号 (+) — 指定した文字列にマッチするすべてのインターフェースにマッチさせるように使用するワイルドカード文字です。例えば、パラメーター -i eth+ は、このルールをすべてのイーサネットインターフェースに適用しますが、 ppp0 などのそれ以外のインターフェースには適用されません。
    -i パラメーターが使われていても、インターフェースが指定されていなければ、すべてのインターフェースがこのルールによって影響を受けます。
  • -j —パケットが特定のルールにマッチすると、指定されたターゲットにジャンプします。
    標準的なターゲットは ACCEPTDROPQUEUE、および RETURN です。
    拡張されたオプションは、 Red Hat Enterprise Linux iptables RPM パッケージと共にデフォルトでダウンロードされるモジュールからも選択できます。これらのモジュールで有効なターゲットには、LOGMARK、および REJECT が含まれます。これらのターゲットと他のターゲットについての詳細は、iptables man ページを参照してください。
    また、このオプションを選択すると、現在のチェーン以外のユーザー定義チェーンに特定のルールにマッチするパケットを送ることができ、他のルールをそのパケットに適用できます。
    ターゲットが指定されていないと、パケットはいずれのアクションも取られないままルールを通過していきます。ただし、このルールのカウンターは 1 つ加算されます。
  • -o — ルールについての出力ネットワークインターフェースを設定します。このオプションは、 filter テーブルの OUTPUT および FORWARD チェーン、および natmangle テーブルの POSTROUTING チェーンにのみ有効です。このパラメーターは、入力インターフェースパラメーター (-i) と同じオプションを受け付けます。
  • -p <protocol> — ルールによって影響を受けるプロトコルを設定します。これは icmptcpudp、または all のいずれかであるか、またはこれらの 1 つまたは他のプロトコルを表す数値である場合があります。/etc/protocols ファイルにリストされているすべてのプロトコルを使用できます。
    "all" プロトコルは、ルールがすべてのサポートされたプロトコルに適用されることを意味します。このルールと共にプロトコルがリストされていない場合、"all" にデフォルト設定されます。
  • -s — 宛先 (-d) パラメーターと同じ構文を使用して、特定のパケットの送信元を設定します。
2.8.9.2.4. IPTables マッチオプション
異なるネットワークプロトコルは、そのプロトコルを使って特定パケットにマッチするように設定可能な専用のマッチオプションがあります。しかし、プロトコルは最初に iptables コマンドで指定する必要があります。例えば、-p <protocol-name> は、指定したプロトコルのオプションを有効にします。プロトコル名の代わりにプロトコル ID も使用できることに注意してください。同じ効果を持つ以下の例を参照してください。
~]# iptables -A INPUT -p icmp --icmp-type any -j ACCEPT
~]# iptables -A INPUT -p 5813 --icmp-type any -j ACCEPT
サービス定義は /etc/services ファイル内で提供されています。読みやすくするために、ポート番号よりもサービス名を使用することが推奨されます。

警告

未承認の編集を防ぐために /etc/servicesファイルをセキュアにしてください。このファイルが編集可能だと、クラッカーはこのファイルを使用して、マシン上の本来は閉じているはずのポートを有効にすることができます。このファイルをセキュアにするには、root で以下のコマンドを実行します。
~]# chown root.root /etc/services
~]# chmod 0644 /etc/services
~]# chattr +i /etc/services
これでファイルの名前変更、ファイル削除、またはファイルへのリンク作成を防ぐことができます。
2.8.9.2.4.1. TCP プロトコル
以下のマッチオプションが TCP プロトコル (-p tcp) で利用可能です。
  • --dport — パケットの宛先ポートを設定します。
    このオプションを設定するには、(www や smtp などの) ネットワークサービス名、ポート番号またはポート番号の範囲を使用します。
    ポート番号の範囲を指定するには、2 つの数をコロン (:) で区切ります。例: -p tcp --dport 3000:3200。最大の有効範囲は 0:65535 です。
    該当するネットワークサービスやポートを使用しないすべてのパケットにマッチさせるには、 --dport オプションの後ろに感嘆符記号 (!) を使用します。
    使用するネットワークサービスとポート番号の名前とエイリアスをブラウズするには、/etc/services ファイルを表示します。
    --destination-port マッチオプションは --dport と同義です。
  • --sport--dport と同じオプションを用いてパケットのソースポートを設定します。--source-port マッチオプションは --sport と同義です。
  • --syn — 通信を初期化するために設計されたすべての TCP パケット (一般的に SYN パケット と呼ばれる) に適用されます。データペイロードを運ぶパケットには影響がありません。
    SYN 以外のパケットすべてとマッチさせるには、--syn オプションの前に感嘆符記号 (!) を使用します。
  • --tcp-flags <tested flag list> <set flag list> — ルールにマッチさせるために設定された特定のビット (フラグ) を持つ TCP パケットを許可します。
    --tcp-flags マッチオプションは 2 つのパラメーターを受け取ります。1 つ目のパラメーターはマスクで、パケットで検査されるフラグのコンマ区切りのリストです。2 つ目のパラメーターは、ルールをマッチさせるために設定する必要のあるフラグのコンマ区切りのリストです。
    利用可能なフラグは以下の通りです。
    • ACK
    • FIN
    • PSH
    • RST
    • SYN
    • URG
    • ALL
    • NONE
    例えば、以下の指定を含む iptablesルールは、SYN フラグが設定されていて、ACK と FIN フラグが設定されていない TCP パケットにのみマッチします。
    --tcp-flags ACK,FIN,SYN SYN
    マッチオプションの効果を逆にするには、--tcp-flags の後ろに感嘆符記号 (!) を使用します。
  • --tcp-option — 特定のパケット内で設定可能な TCP 固有のオプションにマッチさせるよう試行します。また、このマッチオプションを逆にするには、このオプションの後ろに感嘆符記号 (!) を使用することができます。
2.8.9.2.4.2. UDP プロトコル
以下のマッチオプションが UDP プロトコル (-p udp) で利用可能です。
  • --dport — サービス名、ポート番号およびポート番号の範囲を使用して、UDP パケットの宛先ポートを指定します。 --destination-port マッチオプションは --dport と同義です。
  • --sport — サービス名、ポート番号およびポート番号の範囲を使用して、UDP パケットの送信元ポートを指定します。 --source-port マッチオプションは --sport と同義です。
--dport および --sport オプションの場合、ポート番号の範囲を指定するには、2 つの数をコロン (:) で区切ります。例: -p tcp --dport 3000:3200。最大の有効範囲は 0:65535 です。
2.8.9.2.4.3. ICMP プロトコル
以下のマッチオプションは、インターネット制御メッセージプロトコル (ICMP)(-p icmp) で利用可能です。
  • --icmp-type —ルールにマッチさせるための ICMP タイプの名前または番号を設定します。iptables -p icmp -h コマンドを入力すると、有効な ICMP 名のリストを取得できます。
2.8.9.2.4.4. 追加のマッチオプションのモジュール
追加のマッチオプションは、iptables コマンドが読み込んだモジュールから利用できます。
マッチオプションのモジュールを使用するには、-m <module-name> を使用して名前でモジュールを読み込みます。ここでの <module-name> は、モジュール名です。
多くのモジュールはデフォルトで利用可能です。追加機能を提供するためにモジュールを作成することもできます。
以下は、最も一般的に使われるモジュール一覧の一部です。
  • limit モジュール — 特定のルールにマッチするパケット数を制限します。
    LOG ターゲットと共に使用される場合、limit モジュールは、マッチする大量のパケットが反復メッセージでシステムログを満たしてしまう状況や、システムリソースを使い切ってしまうことを防ぎます。
    LOG ターゲットについての詳細は、「ターゲットオプション」 を参照してください。
    limit モジュールは以下のオプションを有効にします。
    • --limit<value>/<period> のペアで指定された、特定の期間におけるマッチ件数の最大数を設定します。例えば、--limit 5/hour を使用すると、1 時間に 5 回のルールマッチが許可されます。
      期間は、秒、分、時間または日で指定できます。
      回数および時間の修飾子が使用されていない場合は、デフォルト値の 3/hour になります。
    • --limit-burst — ルールに一度にマッチ可能なパケット数の制限を設定します。
      このオプションは、整数で指定し、--limit オプションと併用する必要があります。
      値が指定されない場合は、デフォルト値の 5 が使用されます。
  • state モジュール — state マッチングを有効にします。
    state モジュールは以下のオプションを有効にします。
    • --state — 以下の接続状態のパケットにマッチします。
      • ESTABLISHED — マッチするパケットが、確立された接続で他のパケットに関連付けられています。クライアントとサーバー間の接続を維持する場合、この状態を受け付ける必要があります。
      • INVALID — マッチするパケットが既知の接続に結び付けられません。
      • NEW — マッチするパケットが新しい接続を作成しているか、または以前に表示されなかった双方向の接続の一部であるかのいずれかです。サービスへの新規接続を許可する場合、この状態を受け付ける必要があります。
      • RELATED — マッチするパケットが、既存の接続に何らかの形で関連している新規接続を開始します。この例は FTP で、FTP は制御トラフィック (ポート21) にある接続を使用し、データ転送 (ポート20) に別の接続を使用します。
      これらの接続状態は、-m state --state INVALID,NEW のように、それぞれをコンマで区切って組み合わせて使用できます。
  • mac モジュール — ハードウェア MAC アドレスのマッチングを有効にします。
    mac モジュールは以下のオプションを有効にします。
    • --mac-source — パケットを送るネットワークインターフェースカードの MAC アドレスにマッチします。ルールから MAC アドレスを除外するには、--mac-source マッチオプションの後ろに感嘆符記号 (!) を置きます。
モジュールで利用可能なマッチオプションについての詳細は、iptables man ページを参照してください。
2.8.9.2.5. ターゲットオプション
パケットが特定のルールにマッチした場合、そのルールは、適切なアクションを決定する多数の異なるターゲットにパケットを送ることができます。各チェーンにはデフォルトのターゲットがあります。デフォルトのターゲットは、チェーン内のいずれのルールもパケットにマッチしない場合や、パケットにマッチするルールがどれもターゲットを指定していない場合に使用されます。
以下は一般的なターゲットです。
  • <user-defined-chain> — テーブル内のユーザー定義のチェーンです。ユーザー定義のチェーン名は一意である必要があります。このターゲットは指定されたチェーンにパケットを渡します。
  • ACCEPT — 宛先または他のチェーンにパケットを送ることを許可します。
  • DROP — 要求側に応答を返すことなくパケットを破棄します。パケットを送ったシステムには、失敗は通知されません。
  • QUEUE — ユーザー空間アプリケーションで処理されるように、パケットはキューに入れられます。
  • RETURN — 現在のチェーン内のルールに対するパケットのチェックを停止します。RETURN ターゲットを持つパケットが、他のチェーンから呼び出されたチェーン内のルールにマッチする場合、パケットは最初のチェーンに戻され、停止したところからルールチェックが再開されます。RETURN ルールが組み込みチェーンで使用されており、かつパケットを直前のチェーンに戻すことができない場合、現在のチェーンのデフォルトターゲットが使用されます。
さらに、拡張を利用して、他のターゲットを指定することもできます。これらの拡張は、ターゲットモジュールまたはマッチオプションモジュールと呼ばれ、そのほとんどは特定のテーブルおよび状況にのみ適用されます。マッチオプションモジュールについての詳細は、「追加のマッチオプションのモジュール」を参照してください。
拡張されたターゲットモジュールは多数存在します。それらのほとんどは特定のテーブルまたは状況のみに適用されます。Red Hat Enterprise Linux にデフォルトで含まれる最も一般的なターゲットモジュールをいくつか紹介します。
  • LOG — このルールにマッチするすべてのパケットのログを記録します。パケットのログはカーネルが記録するので、/etc/syslog.conf ファイルがこれらのログエントリーが書き込まれる場所を決めます。デフォルトでは、ログエントリーは /var/log/messages ファイルに置かれます。
    追加のオプションを LOG ターゲットの後に使用すると、ロギングの方法を指定できます。
    • --log-level — ロギングイベントの優先レベルを設定します。優先レベルの一覧は syslog.conf man ページを参照してください。
    • --log-ip-options — IP パケットのヘッダーに設定されているすべてのオプションをログに記録します。
    • --log-prefix — ログ行が書き込まれる際に、ログ行の前に最大 29文字の文字列を置きます。これはパケットのロギングと共に syslog フィルターを作成する際に役立ちます。

      注記

      このオプションに関する問題のために、上記のオプションでは log-prefix 値に行末のスペースを追加してください。
    • --log-tcp-options — TCP パケットのヘッダーに設定されたオプションをログ記録します。
    • --log-tcp-sequence — パケットの TCP シーケンス番号をログに書き込みます。
  • REJECT — リモートシステムにエラーパケットを送り返して、パケットを破棄します。
    REJECT ターゲットは --reject-with <type> (<type> は拒否のタイプ) を受け付け、エラーパケットがより詳細な情報と送り返されるようにします。メッセージ port-unreachable は、それ以外のオプションが使用されない場合に指定されるデフォルトのエラータイプです。<type> オプションの完全な一覧については、iptables man ページを参照してください。
他のターゲット拡張についての情報も iptables man ページにあります。これには、nat テーブルを使用する IP マスカレードや、mangle テーブルを使用するパケット変更などに役立つ関連情報が含まれます。
2.8.9.2.6. リストのオプション
デフォルトのリストコマンド iptables -L [<chain-name>] は、デフォルトのフィルターテーブルの現在のチェーンに関するごく基本的な概要を提供します。
  • -v — 各チェーンが処理したパケット数やバイト数、各ルールがマッチしたパケット数やバイト数、および特定のルールに適用されるインターフェースなどの、詳細な出力を表示します。
  • -x — 数値をその正確な値で詳述します。負荷の多いシステムでは、特定のチェーンやルールによって処理されたパケット数やバイト数は、キロバイトメガバイト、または ギガバイト に短縮される場合があります。このオプションは、完全な数字が表示されるように強制します。
  • -n — IP アドレスとポート番号を、デフォルトのホスト名やネットワークサービス形式ではなく、数値形式で表示します。
  • --line-numbers — チェーンにおける数値順に続いて各チェーンのルールを表示します。チェーン内の特定のルールを削除したり、チェーン内のルールを挿入する位置を見つける際に、このオプションは有用です。
  • -t <table-name> — テーブル名を指定します。省略すると、デフォルトはフィルターテーブルになります。

2.8.9.3. IPTables ルールの保存

iptables コマンドを使って作成したルールは、メモリーに保存されます。iptables ルールセットを保存する前にシステムを再起動すると、すべてのルールが失われます。netfilter ルールをシステムの再起動後も持続するには、それらのルールを保存する必要があります。netfilter ルールを保存するには、root で以下のコマンドを入力します。
~]# /sbin/service iptables save
iptables: Saving firewall rules to /etc/sysconfig/iptables:[  OK  ]
これは /sbin/iptables-save プログラムを実行し、現在の iptables 設定を /etc/sysconfig/iptables に書き込む iptables init スクリプトを実行します。既存の /etc/sysconfig/iptables ファイルは /etc/sysconfig/iptables.save として保存されます。
次回のシステムブート時に、iptables init スクリプトは /sbin/iptables-restore コマンドを使用して、/etc/sysconfig/iptables に保存されたルールを再び適用します。
新規の iptables ルールを /etc/sysconfig/iptables ファイルに記載する前にテストすることはよいアイデアですが、このファイルの別のシステムのバージョンから iptables ルールをこのファイルにコピーすることもできます。この方法だと、iptables ルールのセットを複数マシンに素早く分配できます。
また、iptables ルールを配布やバックアップまたは他の目的のために別個のファイルに保存することもできます。これを実行するには、root で以下のコマンドを実行します。
iptables-save > <filename>
ここでの <filename> は、ルールセットにユーザーが定義する名前です。

重要

/etc/sysconfig/iptables ファイルを他のマシンに配布している場合、/sbin/service iptables reload または /sbin/service iptables restart と入力すると新しいルールが有効になります。reload コマンドはファイアウォールがない時間帯を作らないので、こちらの方が推奨されます。「IPTables 制御スクリプト」reload コマンドの説明を参照してください。IPv6 の場合は、上記 /sbin/service コマンドの iptablesip6tables に置き換えます。IPv6 および netfilter についての詳細情報は、「IPTables および IPv6」 を参照してください。

注記

iptables 機能を構成するテーブルおよびチェーンの操作に使用される iptables コマンド (/sbin/iptables) と、iptables サービス自体を有効および無効にする iptables サービス (/sbin/service iptables) の違いに注意してください。

2.8.9.4. IPTables 制御スクリプト

Red Hat Enterprise Linux の iptables を制御するには 2 つの基本的な方法があります。
  • Firewall Configuration Tool (system-config-firewall) — 基本的なファイアウォールのルールを作成し、有効化し、保存するためのグラフィカルツールです。詳細は、「基本的なファイアウォールの設定」 を参照してください。
  • /sbin/service iptables <オプション> — intscript を使用する iptables のさまざまな機能を操作するために使われます。以下のオプションが利用可能です。
    • start — ファイアウォールが設定されていると (つまり、/etc/sysconfig/iptables が存在すると)、実行中のすべての iptables は完全に停止した後に、/sbin/iptables-restore コマンドを使用して開始されます。このオプションは、ipchains カーネルモジュールがロードされていない場合にのみ動作します。このモジュールが読み込まれているかを確認するには、root で以下のコマンドを入力します。
      ~]# lsmod | grep ipchains
      このコマンドで何の出力も返されない場合は、モジュールが読み込まれていないことを意味します。必要な場合は、/sbin/rmmod コマンドを使用してモジュールを削除します。
    • stop — ファイアウォールが実行中であれば、メモリーにあるファイアウォールルールがフラッシュされ、すべての iptables モジュールとヘルパーがアンロードされます。
      /etc/sysconfig/iptables-config 設定ファイルにある IPTABLES_SAVE_ON_STOP 指示文がそのデフォルト値から yes に変更されると、現在のルールが /etc/sysconfig/iptables に保存され、既存のルールすべては /etc/sysconfig/iptables.save ファイルに移動します。
      iptables-config ファイルについての詳細は、「IPTables 制御スクリプト設定ファイル」 を参照してください。
    • reload — ファイアウォールが実行されていれば、ファイアウォールルールが設定ファイルからリロードされます。 reload コマンドは以前に使用されたヘルパーをアンロードしませんが、IPTABLES_MODULES (IPv4 の場合) および IP6TABLES_MODULES (IPv6 の場合) に追加された新たなヘルパーを追加します。現行のファイアウォールルールをフラッシュしないので、新規ルールにエラーがあって適用できない場合に以前のルールがまだ残っているという利点があります。
    • restart —ファイアウォールが実行されていると、メモリーにあるファイアウォールルールがフラッシュされ、ファイアウォールが /etc/sysconfig/iptables に設定されていれば、再起動されます。このオプションは、 ipchains カーネルモジュールが読み込まれていない場合にのみ動作します。
      /etc/sysconfig/iptables-config 設定ファイルにある IPTABLES_SAVE_ON_RESTART 指示文がデフォルト値から yes に変更されると、現在のルールが /etc/sysconfig/iptables に保存され、既存のすべてのルールは /etc/sysconfig/iptables.save に移動します。
      iptables-config ファイルについての詳細は、「IPTables 制御スクリプト設定ファイル」 を参照してください。
    • status — ファイアウォールのステータスを表示し、すべてのアクティブなルールを一覧表示します。
      このオプションのデフォルト設定では、各ルールの IP アドレスが表示されます。ドメインやホスト名の情報を表示するには、/etc/sysconfig/iptables-config ファイルを編集して、 IPTABLES_STATUS_NUMERIC の値を no に変更します。iptables-config ファイルについての詳細は、「IPTables 制御スクリプト設定ファイル」を参照してください。
    • panic — すべてのファイアウォールのルールをフラッシュします。設定されたすべてのテーブルのポリシーは DROP に設定されます。
      このオプションは、サーバーが危険にさらされいることが判明した場合に有用です。ネットワークから物理的に切断したり、システムをシャットダウンしたりする代わりに、このオプションを使って、分析や他のフォレンジックのためにマシンを稼動状態に保ったままで、すべてのネットワークトラフィックを停止することができます。
    • saveiptables-save を使用して、ファイアウォールのルールを /etc/sysconfig/iptables に保存します。詳細は、「 IPTables ルールの保存」を参照してください。

注記

IPv6 の netfilter を制御するために同一の initscript コマンドを使用するには、本セクションにある /sbin/service コマンドの iptablesip6tables に置き換えます。IPv6 と netfilter についての詳細情報は、「IPTables および IPv6」 を参照してください。
2.8.9.4.1. IPTables 制御スクリプト設定ファイル
iptables intscript の動作は、/etc/sysconfig/iptables-config 設定ファイルで制御します。以下は、このファイルに含まれる指示文の一覧です。
  • IPTABLES_MODULES — ファイアウォールがアクティブ化された際に読み込む追加 iptables モジュールのスペース区切りのリストを指定します。これらには、接続追跡や NAT ヘルパーなどを含めることができます。
  • IPTABLES_MODULES_UNLOAD — 再起動および停止時にモジュールをアンロードします。この指示文は、以下の値を受け付けます。
    • yes — デフォルト値。ファイアウォールの再起動または停止に必要な正しい状態を達成するには、このオプションを設定する必要があります。
    • no — このオプションは、netfilter モジュールのアンロードに問題がある場合にのみ設定してください。
  • IPTABLES_SAVE_ON_STOP — ファイアウォールが停止する場合に、現在のファイアウォールのルールを /etc/sysconfig/iptables に保存します。この指示文は以下の値を受け付けます。
    • yes — ファイアウォールが停止する際に、既存のルールを /etc/sysconfig/iptables に保存します。以前のバージョンは /etc/sysconfig/iptables.save ファイルに移動されます。
    • no — デフォルト値。ファイアウォールが停止する際に既存のルールを保存しません。
  • IPTABLES_SAVE_ON_RESTART — ファイアウォールが再起動するときに、ファイアウォールの現在のルールを保存します。この指示文は以下の値を受け付けます。
    • yes — ファイアウォールを再起動する際に、既存のルールを /etc/sysconfig/iptables に保存します。以前のバージョンは /etc/sysconfig/iptables.save ファイルに移動されます。
    • no — デフォルト値。ファイアウォールを再起動する際に既存のルールを保存しません。
  • IPTABLES_SAVE_COUNTER — すべてのチェーンとルールにあるすべてのパケットとバイトのカウンターを保存し、復元します。この指示文は以下の値を受け付けます。
    • yes — カウンターの値を保存します。
    • no — デフォルト値。カウンターの値を保存しません。
  • IPTABLES_STATUS_NUMERIC — ドメインまたはホスト名の代わりに数値形式で IP アドレスを出力します。この指示文は以下の値を受け付けます。
    • yes — デフォルト値。status 出力にある IP アドレスのみを返します。
    • no — status 出力にあるドメインまたはホスト名を返します。

2.8.9.5. IPTables および IPv6

iptables-ipv6 パッケージがインストールされている場合、Red Hat Enterprise Linux の netfilter は、次世代の IPv6 インターネットプロトコルをフィルターできます。IPv6 netfilter の操作に使用するコマンドは ip6tables です。
このコマンドの指示文の多くは、 iptables に使用されるものと同じです。ただし、nat テーブルはまだサポートされていません。つまり、現時点ではマスカレードやポート転送のような IPv6 ネットワークアドレス変換のタスクを実行することはできません。
ip6tables についてのルールは /etc/sysconfig/ip6tables ファイルに保存されます。ip6tables initscript が保存した以前のルールは、/etc/sysconfig/ip6tables.save ファイルに保存されます。
ip6tables init スクリプトについての設定オプションは /etc/sysconfig/ip6tables-config に保存されます。また、各指示文の名前は iptables の指示文の名前とは若干異なります。
たとえば、iptables-config の指示文 IPTABLES_MODULES の場合、ip6tables-config ファイル内で同等のものは IP6TABLES_MODULES になります。

2.8.9.6. その他のリソース

本章でカバーできなかったファイアウォールと Linux Netfilter サブシステムの側面がいくつかあります。詳細情報は、以下のリソースを参照してください。
2.8.9.6.1. 有用なファイアウォールの Web サイト
  • http://www.netfilter.org/ — netfilter/iptables プロジェクトのホーム。iptables に関連する情報が含まれます。これには、Linux IP ファイアウォールのメンテナーの Rusty Russell による、特定の問題を扱った FAQ や各種の役に立つガイドが含まれます。このサイトにある HOWTO ドキュメントは、基本的なネットワークの概念や、カーネルパケットフィルタリング、および NAT 設定などのトピックを扱っています。
  • http://www.tldp.org/ — Linux ドキュメンテーションプロジェクトには、ファイアウォールの構築および管理に関する有用なガイドがいくつか含まれます。
  • http://www.iana.org/assignments/port-numbers — Internet Assigned Numbers Authority が割り当てた登録済みまたは共通のサービスポートの公式リストです。
2.8.9.6.2. 関連ドキュメント
  • Red Hat Linux Firewalls、Bill McCarty 著、Red Hat Press — Netfilter および iptables などのオープンソースパケットフィルタリング技術を使用してネットワークやサーバーのファイアウォールを構築するための総合的な参考情報です。これには、ファイアウォールのログの解析、ファイアウォールルールの作成、および各種のグラフィックツールを使用したファイアウォールのカスタマイズなどを扱うトピックが含まれます。
  • Linux Firewalls、Robert Ziegler 著、New Riders Press — 2.2 カーネル ipchains と Netfilter および iptables の両方を使用してファイアウォールを構築する方法についての豊富な情報が含まれます。リモートアクセスの問題や侵入検知システムなどの追加のセキュリティ関連のトピックも扱われます。
2.8.9.6.3. インストールされている IP Tables ドキュメント
  • man iptablesiptables の説明と、ターゲット、オプションおよびマッチ拡張の総合的なリストが含まれます。


[3] 。システム BIOS はメーカーによって異なるため、パスワード保護をサポートしないものもあれば、あるタイプのパスワード保護のみをサポートするものもあります。
[4] GRUB は暗号化されていないパスワードも使用できますが、より高い安全性のために MD5 を使用することが推奨されます。

第3章 暗号化

保護する必要のあるデータには、静止しているデータと移動中のデータの主に 2 種類があります。これらの異なる種類のデータは同じ技術を用いて同じ方法で保護されますが、セキュリティの実装方法は完全に異なる場合があります。同じ情報でもさまざまな時点で静止中になったり移動中になったりする場合があるので、単一のセキュリティ実装で、すべての起こりうる危険を防ぐことはできません。

3.1. 静止しているデータ

静止しているデータとは、ハードディスク、テープ、CD、DVD、ディスクおよびその他のメディアに保存されているデータのことです。この情報に対する最大の脅威は、物理的な盗難です。空港で使用されるノートパソコン、郵便物内の CD および安全でない場所に残されたバックアップテープなどは、盗難によってデータが侵害される可能性のある例です。ただし、それらのメディア上でデータが暗号化されている場合は、データがアクセスされる可能性は低くなります。

3.1.1. ディスク全体の暗号化

ディスク全体の暗号化またはパーティションの暗号化は、データを保護する最良の方法の 1 つです。それぞれのファイルが保護されるだけでなく、これらのファイルの一部を含んでいる可能性のある一時的なストレージも保護されます。ディスク全体の暗号化によってすべてのファイルが保護されるので、保護する部分を選択したりファイルを見落とす可能性について心配する必要がありません。
Red Hat Enterprise Linux 6 は、LUKS 暗号化をネイティブにサポートします。LUKS は、コンピューターがオフの間にデータを保護するように、ハードディスクのパーティションをバルク暗号化します。これにより、攻撃者がコンピューターにシングルユーザーモードを使用してログインしようとしたり、その他の方法でアクセス権を得ようとしたりすることからコンピューターを保護します。
LUKS のようなディスク全体の暗号化ソリューションは、コンピューターがオフの時にのみデータを保護します。コンピューターがオンになり、LUKS がディスクの暗号化を解除すると、ディスクにあるファイルはそれらに普通にアクセスできるすべての人が利用できるようになります。コンピューターがオンの時にファイルを保護するには、ファイルベースの暗号化などの他のソリューションと組み合わせてディスク全体の暗号化を使用します。また、コンピューターから離れる際はロックすることを忘れないようにしてください。コンピューターを数分間使用しないとパスフレーズ付きのスクリーンセーバーがアクティブになるように設定するのも、侵入者を防ぐ上で優れた方法です。LUKS についての詳細は、「LUKS のディスク暗号化」を参照してください。

3.1.2. ファイルベースの暗号化

ファイルベースの暗号化は、CD やフラッシュドライブ、外付けハードドライブなどのモバイルのストレージデバイスにあるファイルのコンテンツを保護するために使用します。ファイルベースの暗号化ソリューションの中には暗号化されたファイルの残りをコンピューターにそのまま残すものがあり、この場合は攻撃者がコンピューターに物理的にアクセスし、これらのファイルを復元する可能性があります。コンピューターにアクセスする可能性のある攻撃者からそれらのファイルのコンテンツを保護するには、ディスク全体の暗号化などの他のソリューションと組み合わせてファイルベースの暗号化を使用してください。

3.1.3. LUKS のディスク暗号化

Linux Unified Key Setup-on-disk-format (または LUKS) を使うと、Linux コンピューター上のパーティションを暗号化できます。これは特に、モバイルコンピューターやリムーバブルメディアを使う際に重要です。LUKS は、複数のユーザーキーを使って、パーティションのバルク暗号化に使用されるマスターキーの暗号化解除をできるようにします。

LUKS の概要

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

3.1.3.1. Red Hat Enterprise Linux での LUKS 実装

Red Hat Enterprise Linux 6 は、LUKS を使ってファイルシステムの暗号化を実行します。デフォルトではインストール時に、ファイルシステムを暗号化するオプションのチェックが外されています。ハードディスクを暗号化するオプションを選択すると、コンピューターを起動するたびにパスフレーズを尋ねられます。このパスフレーズは、パーティションの暗号化を解読するために用いられるバルク暗号化鍵を「ロック解除」します。デフォルトのパーティションテーブルの変更を選択すると、暗号化するパーティションを選択できます。この設定は、パーティションテーブル設定で行われます。
LUKS に使用されるデフォルトの暗号 (cryptsetup --help を参照) は aes-cbc-essiv:sha256 です。インストールプログラムの Anaconda は、デフォルトでは XTS モード (aes-xts-plain64) で AES 暗号を使用することに注意してください。LUKS のデフォルトの鍵のサイズは 256 ビット です。Anaconda (XTS モード) と併用する場合の LUKS のデフォルトの鍵のサイズは 512 ビット です。

警告

デフォルトの暗号化属性を変更すると、システムパフォーマンスに影響を及ぼし、システムを様々なセキュリティリスクにさらす可能性があります。暗号作成に関して十分な知識がなく、使用される暗号法の組み合わせについての機能を理解していない場合は、システムのデフォルトの暗号化属性を変更しないでください。
Red Hat では、デフォルトの暗号の使用を強く推奨しています。デフォルトの暗号以外を使う必要がある場合は、--cipher および --key-size のオプションでパーティションを初期化できます。このコマンドの構文は、以下のようになります。
cryptsetup --verify-passphrase --cipher <cipher>-<mode>-<iv> --key-size <key-size> luksFormat <device>
ここでの <cipher>-<mode>-<iv> は、使用されている暗号法を示す文字列になります。この文字列は、ブロック暗号、ブロック暗号モード、初期ベクトル(IV) の 3 つで構成されます。
ブロック暗号は、データブロック上で作動してバルクデータの暗号化と暗号化解除を可能にする、決定性アルゴリズムです。Red Hat Enterprise Linux で使用可能なブロック暗号は、以下のとおりです。
  • AES — Advanced Encryption Standard (高度暗号化標準) は、128、192、および 256 ビットの暗号化鍵を使用する 128 ビットの対称ブロック暗号です。詳細は、FIPS PUB 197 を参照してください。
  • Twofish — 128 から 256 ビットまでの暗号化鍵で作動する 128 ビットのブロック暗号です。
  • Serpent — 128、192、および 256 ビットの暗号化鍵を使用する 128 ビットのブロック暗号です。
  • cast5 — 40 から 128 ビットまでの暗号化鍵をサポートする 64 ビットの Feistel 暗号です。詳細は、RFC 2144 を参照してください。
  • cast6 — 128、160、192、224、または 256 ビットのいずれかの暗号化鍵を使用する 128 ビットの Feistel 暗号です。詳細は、RFC 2612。を参照してください。
ブロック暗号モードは、データを確実に暗号化または暗号解除するためにバルクデータにブロック暗号を繰り返し適用する方法を記述します。以下のモードが使用できます。
  • CBC — Cipher Block Chaining。詳細は、NIST SP 800-38A。を参照してください。
  • XTS — XEX Tweakable Block Cipher with Ciphertext Stealing。詳細は、 IEEE 1619 または NIST SP 800-38E。を参照してください。
  • CTR — Counter。詳細は、NIST SP 800-38A を参照してください。
  • ECB — Electronic Codebook。詳細は、NIST SP 800-38A を参照してください。
  • CFB — Cipher Feedback。詳細は、NIST SP 800-38A を参照してください。
  • OFB — Output Feedback。詳細は、NIST SP 800-38A を参照してください。
初期ベクトルは、暗号文の無作為化に使用されるデータのブロックです。IV により、同一のプレーンテキストを繰り返し暗号化しても異なる暗号文の出力が保証されます。IV は、同一の暗号鍵と再利用しないでください。CBC モードの暗号では、IV は 予測不可能である必要があります。そうでない場合は、システムは電子透かしに対する特定の攻撃に弱くなってしまいます (詳細は LUKS/cryptsetup FAQ を参照)。Red Hat では、AES と以下の IV を使用することを推奨しています。
  • ESSIV — Encrypted Salt-Sector Initialization Vector - この IV は、CBC モードの暗号に使用してください。デフォルトのハッシュである sha256 を使用すべきです。
  • plain64 (または plain) — IV sector offset - この IV は、XTS モードの暗号に使用してください。
使用される暗号鍵の長さを指定することもできます。鍵のサイズは、使用されるブロック暗号とブロック暗号モードの組み合わせによって異なります。鍵の長さが指定されないと、LUKS は決まった組み合わせでデフォルト値を使用します。たとえば、CBC モードで AES に 128 ビットの鍵を使用することにすると、LUKS は AES-128 実装を使用してパーティションを暗号化します。一方、XTS モードで AES に 512 ビットを指定すると、AES-256 実装が使用されます。XTS モードでは 2 つの鍵が使用されることに注意してください。ひとつ目は調整可能な暗号化に、2 つ目は通常の暗号化用に決められます。

3.1.3.2. 手動によるディレクトリーの暗号化

警告

以下の手順を実行すると、暗号化しているパーティションの既存データがすべて削除されます。すべての情報が失われてしまうので、この手順を開始する前に、外部ソースへのデータのバックアップを必ず行なってください。
  1. root としてシェルプロンプトに以下を入力し、ランレベル 1 に入ります。
    telinit 1
  2. 既存の /home のマウントを解除します。
    umount /home
  3. 直前の手順のコマンドが失敗した場合は、fuser を使用し、/home を独占しているプロセスを見つけてこれらを止めます。
    fuser -mvk /home
  4. /home がもはやマウントされていないことを確認します。
    grep home /proc/mounts
  5. パーティションをランダムなデータで埋めます。
    shred -v --iterations=1 /dev/VG00/LV_home
    このコマンドは、デバイスの連続書き込み速度で実行され、完了までに時間がかかる場合があります。使用デバイスに暗号化されていないデータが残っていないことを確認した上で、デバイスの暗号化されたデータを含む部分を難読化するのは重要なステップです。
  6. パーティションを初期化します。
    cryptsetup --verbose --verify-passphrase luksFormat /dev/VG00/LV_home
  7. 新たに暗号化したデバイスを開きます。
    cryptsetup luksOpen /dev/VG00/LV_home home
  8. デバイスがあることを確認します。
    ls -l /dev/mapper | grep home
  9. ファイルシステムを作成します。
    mkfs.ext3 /dev/mapper/home
  10. ファイルシステムをマウントします。
    mount /dev/mapper/home /home
  11. ファイルシステムが表示されていることを確認します。
    df -h | grep home
  12. 以下を /etc/crypttab ファイルに追加します。
    home /dev/VG00/LV_home none
  13. /etc/fstab ファイルを編集して、/home の古いエントリを削除し、以下の行を追加します。
    /dev/mapper/home /home ext3 defaults 1 2
  14. デフォルトの SELinux セキュリティコンテンツを復元します。
    /sbin/restorecon -v -R /home
  15. マシンを再起動します。
    shutdown -r now
  16. /etc/crypttab にあるエントリにより、コンピューターのブート時に luks パスフレーズが尋ねられます。
  17. root としてログインし、バックアップを復元します。
これですべてのデータ用に暗号化されたパーティションを設定できたので、コンピューターをオフにしている間もデータを安全に保管できます。

3.1.3.3. 既存デバイスへの新規パスフレーズの追加

既存デバイスに新規パスフレーズを追加するには、以下のコマンドを使用します。
cryptsetup luksAddKey <device>
認証のために既存のパスフレーズが尋ねられると、新規パスフレーズの入力を求めるプロンプトが出されます。

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

既存のデバイスからパスフレーズを削除するには、以下のコマンドを使用します。
cryptsetup luksRemoveKey <device>
削除したいパスフレーズについて尋ねれ、認証に必要な残りのパスフレーズを求めるプロンプトが出されます。

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

システムのインストール時に、暗号化されたデバイスを作成することができます。これにより、 暗号化パーティションを含むシステムを簡単に設定することができます。
ブロックデバイスの暗号化を有効にするには、自動パーティション設定を選択している場合は システムの暗号化 チェックボックスに、個別パーティション、ソフトウェア RAID アレイまたは論理ボリュームを作成している場合は 暗号化 チェックボックスにチェックを入れます。パーティション設定が終了したら、暗号化のパスフレーズが尋ねられます。このパスフレーズは暗号化したデバイスにアクセスするために必要になります。LUKS デバイスが事前に存在しており、インストールプロセスの当初にそれらの正しいパスフレーズを指定している場合には、チェックボックスのあるパスフレーズ入力ダイアログが表示されます。このチェックボックスにチェックを入れると、既存の暗号化ブロックデバイスの利用可能なスロットに新規パスフレーズを追加することになります。

注記

自動パーティション設定 画面の システムの暗号化 チェックボックスにチェックを入れた後に カスタムレイアウトの作成 を選択しても、ブロックデバイスは自動的に暗号化されません。

注記

kickstart ファイルを使うと、暗号化した新規ブロックデバイスごとに個別のパスフレーズを設定することができます。また、Anaconda のデフォルトの暗号法である aes-xts-plain64 が適切でない場合、kickstart では別のタイプの暗号法を指定することもできます。暗号化するデバイスの依存関係で、autopartpartpartitionlogvol、および raid 指示文などとともに、--cipher=<cipher-string> を指定することができます。このオプションを有効にするには、--encrypted オプションと合わせて使う必要があります。<cipher-string> の形式および暗号法の組み合わせに関する詳細情報は、「Red Hat Enterprise Linux での LUKS 実装」 を参照してください。kickstart の設定に関する詳細は、Red Hat Enterprise Linux 6 インストールガイド を参照してください。

3.1.3.6. その他のリソース

Red Hat Enterprise Linux における LUKS や暗号化ハードディスクについての詳細は、以下のリンクにアクセスしてください。

3.2. 移動中のデータ

移動中のデータとは、ネットワークで送信中のデータのことです。移動中のデータに対する最大の脅威は傍受と改ざんです。他人に傍受されると、なりすましに使用されたり機密情報へのアクセスを許してしまうため、ユーザー名とパスワードを保護せずにネットワーク上で送信することは決してすべきではありません。ネットワークセッションを暗号化すると、移動中のデータのセキュリティレベルが確実に高めるられます。
移動中のデータは、とりわけ攻撃者に対して脆弱です。攻撃者はコンピューターの近くにいる必要がなく、単に通信パスのどこかにさえいればよいためです。暗号化トンネルを使用すると、通信パスに沿ってデータを保護することができます。

3.2.1. 仮想プライベートネットワーク (VPN)

仮想プライベートネットワーク(VPN) は、すべてのポートを対象に、コンピューター間またはコンピューターのネットワーク間で暗号化されたトンネルを提供します。VPN を設定していると、クライアントからのすべてのネットワークトラフィックは暗号化トンネルを経由してサーバーに転送されます。つまり、クライアントは VPN 経由で接続するサーバーと論理的に同じネットワーク上にあることを意味します。VPN はかなり一般的になっており、そのセットアップと利用は簡単です。

3.2.2. SSH (Secure Shell)

Secure Shell (SSH) は、セキュアなチャネル上で別のシステムと通信するために使用される強力なネットワークプロトコルです。SSH 上の送信は暗号化され、傍受から保護されます。暗号化ログインを使用して、従来のユーザー名とパスワードよりも優れた認証方法を提供することもできます。「暗号化ログイン」 を参照してください。
SSH のアクティベーションはとても簡単です。sshd デーモンを開始すると、システムは接続の受け付けを開始し、接続プロセス時に正しいユーザー名とパスワードが指定されると、システムへのアクセスが許可されます。SSH サービスの標準的な TCP ポートは 22 ですが、設定ファイル /etc/ssh/sshd_config を修正してサービスを再起動すると、これを変更することができます。このファイルには SSH の他の設定オプションも含まれています。
sshd サービスはデフォルトで、ブート時に自動的に開始します。デーモンのステータスを調べるには、root で以下のコマンドを実行します。
~]# service sshd status
sshd サービスを再起動するには、root で以下のコマンドを実行します。
~]# service sshd restart
システムサービスの管理に関する詳細情報は、Red Hat Enterprise Linux 6 導入ガイドサービスとデーモン の章を参照してください。
Secure Shell (SSH) はコンピューター間に暗号化されたトンネルを提供しますが、単一ポートしか使用しません。ポート転送は SSH トンネルで実行可能で、トラフィックはこのトンネルを通過するので暗号化されます。ただし、ポート転送は、VPN (「仮想プライベートネットワーク (VPN)」) ほど流動的ではありません。

3.2.2.1. 暗号化ログイン

SSH は、コンピューターにログインするための暗号化鍵の使用をサポートしています。これはパスワードのみの使用よりもはるかに安全です。この方法を他の認証方法と組み合わせると、マルチファクター認証 (multifactor authentication) と見なすことができます。マルチ認証方法についての詳細は、「複数の認証方法」 を参照してください。
認証における暗号鍵の使用を有効にするには、/etc/ssh/sshd_config ファイルの PubkeyAuthentication 設定指示文を yes に設定する必要があります。これは、デフォルト設定になることに注意してください。PasswordAuthentication 指示文を no に設定すると、ログインでのパスワード使用が無効になります。
SSH 鍵は ssh-keygen コマンドを使って生成できます。引数なしでこれを実行すると、2048 ビットの RSA 鍵のセットが作成されます。デフォルトでは、この鍵は ~/.ssh ディレクトリーに保存されます。-b スイッチを使うと、鍵のビット強度を修正することができます。通常は、2048 ビット鍵で十分な強度が提供されます。SSH 鍵の生成に関する詳細情報は、Red Hat Enterprise Linux 6 導入ガイド鍵ペアの生成 の章を参照してください。
~/.ssh ディレクトリーに、2 つの鍵が見つかるはずです。ssh-keygen コマンドの実行時にデフォルトを受け入れると、生成されるファイル名は id_rsaid_rsa.pub になり、それぞれに秘密鍵と公開鍵が含まれます。秘密鍵はファイルの所有者のみが読み取り可能として、公開されないように常に保護してください。ただし公開鍵は、ログインするシステムに送信する必要があります。ssh-copy-id コマンドを使用すると、サーバーにこの鍵を移動することができます。
~]$ ssh-copy-id -i [user@]server
このコマンドは、server 上の ~/.ssh/authorized_key ファイルに自動で公開鍵を追加します。ユーザーがサーバーへのログインを試みる際には、sshd デーモンがこのファイルをチェックします。
パスワードやその他の認証メカニズムと同様に、SSH 鍵は定期的に変更する必要があります。この際、authorized_key ファイルから使用されていない鍵を必ず消去してください。

3.2.2.2. 複数の認証方法

マルチファクター認証とも呼ばれる複数の認証方式を使用すると、権限のないアクセスに対する保護のレベルが高まります。このため、システムのセキュリティを強化する際には、マルチファクター認証を検討してください。マルチファクター認証を使用するシステムにログインしようとすると、ユーザーは指定されたすべての認証方式で成功しないと、アクセスが認められません。
使用する認証方式を指定するには、/etc/ssh/sshd_config ファイル内の AuthenticationMethods 設定指示文を使用します。この指示文では、必要となる認証方式の複数のリストを定義できることに注意してください。複数を定義する場合は、各方式を少なくとも 1 つのリストで定義する必要があります。各リストは空白で区切ります。リスト内の各認証方式の名前はコンマ区切りとします。例を示します。
AuthenticationMethods publickey,gssapi-with-mic publickey,keyboard-interactive
上記の AuthenticationMethods 指示文を使って設定された sshd デーモンは、ユーザーが publickey 認証の後に gssapi-with-mic または keyboard-interactive 認証でログインを完了した場合にのみ、アクセスを許可します。必要とされる認証方式はそれぞれ、/etc/ssh/sshd_config ファイル内の対応する設定指示文 (PubkeyAuthentication など) で明示的に有効となっている必要があることに注意してください。利用可能な認証方式の全般的なリストは、ssh(1) man ページの AUTHENTICATION セクションを参照してください。

3.2.2.3. SSH の他のセキュア化

プロトコルバージョン
Red Hat Enterprise Linux で提供される SSH プロトコルは SSH-1 と SSH-2 の両バージョンをサポートしますが、可能な場合は常に後者のみを使用してください。SSH-2 バージョンには、旧式の SSH-1 の多くの改善点が含まれており、高度な設定オプションの多くは SSH-2 でのみ使用可能となっています。
SSH プロトコルによる認証と対象となる通信の保護を最大限まで活用するために、ユーザーは SSH-2 を使用することが推奨されます。sshd デーモンがサポートするプロトコルのバージョンは、/etc/ssh/sshd_config ファイル内で Protocol 設定指示文を使って指定できます。デフォルト設定は 2 になります。
鍵のタイプ
ssh-keygen コマンドはデフォルトで SSH-2 RSA 鍵のペアを生成しますが、-t オプションを使うと、DSA または ECDSA 鍵を生成するように指示することもできます。ECDSA (Elliptic Curve Digital Signature Algorithm) は、同じ対称鍵の長さでより優れたパフォーマンスを提供します。また、より短い鍵も生成します。
デフォルト以外のポート
デフォルトでは、sshd デーモンは 22 ネットワークポートをリッスンします。ポートを変更すると、自動ネットワークスキャンをベースとする攻撃に対するシステムの露出を減らすことになるので、曖昧さによってセキュリティが増します。ポートは、/etc/ssh/sshd_config ファイルの Port 指示文で指定できます。デフォルト以外のポート使用を可能にするには、デフォルトの SELinux ポリシーの変更も必要になることに注意してください。これは、root で以下のコマンドを実行して ssh_port_t SELinux タイプを修正することで可能になります。
~]# semanage -a -t ssh_port_t -p tcp port_number
上記のコマンドでは、port_numberPort 指示文で指定する新たなポート番号に置き換えます。
Root 以外のログイン
特定のユースケースで root ユーザーとしてのログインが必要ない場合は、/etc/ssh/sshd_config ファイルで PermitRootLogin 設定指示文を no に設定することを検討してください。root ユーザーとしてのログインの可能性をなくすことで、どのユーザーが通常のユーザーとしてログインした後に root 権限を獲得し、権限のあるコマンドを実行したかを管理者が監査できるようになります。

重要

本セクションでは、SSH 設定のセキュア化における最も一般的な方法にフォーカスしてきました。ただし、ここで提案された方法が網羅的または決定的であるというわけではありません。sshd デーモンの動作修正に利用可能な設定指示文すべてについての説明は sshd_config(5) の man ページを、基本的な SSH の概念については ssh(1) の man ページを参照してください。

3.3. OpenSSL インテル AES-NI エンジン

一部の Intel プロセッサーには、Intel Advanced Encryption Standard (AES) New Instructions (AES-NI) エンジンが実装されています。このエンジンは、ハードウェアの暗号化/暗号化解除を極めて高速に処理することができます。

注記

AES-NI エンジンをサポートする Intel プロセッサーのリストについては、Intel の ARK を参照してください。
検出されたプロセッサーがサポート対象の場合、AES-NI エンジンは自動的に有効になります。プロセッサーがサポート対象可動化を確認するには、以下の手順にしたがってください。
  1. プロセッサーに AES 指示セットがあることを確認します。
    ~]# grep -m1 -o aes /proc/cpuinfo
    aes
  2. root で以下のコマンドを実行し、出力を比較します。後者のコマンドでのパフォーマンスが大幅に優れていれば、AES-NI が有効になっていることを意味します。下記の出力は短縮してあることに注意してください。
    ~]# openssl speed aes-128-cbc
    The 'numbers' are in 1000s of bytes per second processed.
    type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
    aes-128 cbc      99696.17k   107792.98k   109961.22k   110559.91k   110742.19k
    ~]# openssl speed -evp aes-128-cbc
    The 'numbers' are in 1000s of bytes per second processed.
    type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
    aes-128-cbc     800450.23k   873269.82k   896864.85k   903446.19k   902752.94k
OpenSSH の速度をテストするには、以下のようなコマンドを実行することができます。
~]# dd if=/dev/zero count=100 bs=1M | ssh -c aes128-cbc localhost "cat >/dev/null"
root@localhost's password: 
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 4.81868 s, 21.8 MB/s
AES-NI エンジンの詳細については、Intel® Advanced Encryption Standard Instructions (AES-NI) を参照してください。

3.4. 乱数ジェネレーターの使用

簡単に解読されない安全な暗号鍵を生成するには、乱数のソースが必要になります。一般的に、番号がよりランダムであればあるほど、一意の鍵を得られる可能性が高まります。乱数生成のエントロピー は通常、コンピューティング環境の「ノイズ」または 乱数ジェネレーター のハードウェアを使用することで獲得されます。
rng-tools パッケージの一部である rngd デーモンは、エントロピーを引き出すために環境ノイズと乱数ジェネレーターの両方が使えます。このデーモンは、乱数度のソースが提供したデータがランダムかどうかをチェックし、その後にカーネルの乱数エントロピープールに保存します。これが生成した乱数は、/dev/random および /dev/urandom の各キャラクターデバイスから利用できます。
/dev/random/dev/urandom の違いは、前者はブロックデバイスであり、適切な乱数出力の生成にエントロピーが不十分だと判断すると、乱数の提供が停止される一方で、/dev/urandom は非ブロックソースであり、カーネルのエントロピープールを再利用して無制限の仮の乱数を提供できる、という点です。ただし、この場合のエントロピーは低くなります。このため、長期の暗号鍵の作成には、/dev/urandom は使用しないでください。
rng-tools パッケージをインストールするには、root で以下のコマンドを実行します。
~]# yum install rng-tools
rngd デーモンを起動するには、root で以下のコマンドを実行します。
~]# service rngd start
デーモンのステータスを確認するには、以下のコマンドを実行します。
~]# service rngd status
オプションのパラメーターを使って rngd デーモンを起動するには、直接これを実行します。たとえば、乱数入力の代替ソース (/dev/hwrandom 以外) を指定するには、以下のコマンドを実行します。
~]# rngd --rng-device=/dev/hwrng
上記のコマンドは、/dev/hwrng を乱数読み取り先のデバイスとして rngd デーモンを起動します。同様に、-o (または --random-device) オプションを使うと、乱数の出力に (デフォルトの /dev/random ではなく) カーネルデバイスを選択します。利用可能なオプションについては、rngd(8) の man ページを参照してください。
rng-tools パッケージには rngtest ユーティリティーも含まれており、これはデータの乱数度のチェックに使用できます。/dev/random の出力の乱数度をテストするには、以下のように rngtest ツールを使用します。
~]$ cat /dev/random | rngtest -c 1000
rngtest 2
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: 1000
rngtest: FIPS 140-2 failures: 0
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: 1
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=308.697; avg=623.670; max=730.823)Kibits/s
rngtest: FIPS tests speed: (min=51.971; avg=137.737; max=167.311)Mibits/s
rngtest: Program run time: 31461595 microseconds
rngtest ツールの出力で failures の数字が大きいと、テストされたデータの乱数度が不十分で信頼すべきでないことを意味します。rngtest ユーティリティーで利用可能なオプションのリストについては、rngtest(1) の man ページを参照してください。

3.5. GNU Privacy Guard (GPG)

GnuPG (GPG) は、ファイルや電子メールメッセージの署名および暗号化を可能にする PGP のオープンソースバージョンです。これはメッセージやファイルの整合性を維持するのに役立ち、ファイルや電子メールに含まれる情報の機密性も保護します。電子メールの場合、GPG は二重の保護を提供します。メッセージがネットワークを介して送信されると、静止しているデータだけでなく移動中のデータも保護します。これらの概念に関する詳細は、「静止しているデータ」 および 「移動中のデータ」 を参照してください。
GnuPG (GPG) は、ユーザーを識別し、通信 (確認できない人々との通信も含む) を認証するために使われます。GPG は GPG 署名のある電子メールを読む人がその真正性を検証できるようにします。つまり、GPG は、あなたが署名した通信が実際にあなたからのものであることをかなりの精度で確認できるようにします。GPG は、第三者がコードを変更したり、会話を傍受したり、メッセージを改ざんしたりするのを防ぐ助けになるので有用です。

3.5.1. GNOME での GPG 鍵の生成

GNOME で GPG 鍵を作成するには、以下の手順にしたがいます。
  1. Seahorse ユーティリティーをインストールします。これにより GPG 鍵の管理が容易になります。
    ~]# yum install seahorse
  2. 鍵を作成するには、アプリケーションアクセサリメニューから、パスワードと暗号鍵を選択します。これでアプリケーション Seahorse が起動します。
  3. ファイルメニューから新規を選択し、PGP 鍵を選択した後に続行をクリックします。
  4. 氏名、電子メールアドレスおよび自身についての説明のオプションのコメント (例: John C. Smith, jsmith@example.com, Software Engineer) を入力します。生成をクリックします。鍵のパスフレーズを問い合わせるダイアログが表示されます。パスフレーズは強いだけでなく覚えやすいものを選択してください。OK をクリックすると鍵が作成されます。

警告

パスフレーズを忘れると、データの暗号解除ができなくなります。
GPG 鍵 の ID を見つけるには、新規に作成された鍵の横にある 鍵の ID コラムを確認します。多くの場合、鍵 の ID を求められたら、0x6789ABCD などのように鍵のID の前に 0x を付けます。秘密鍵のバックアップを取り、安全な場所に保管してください。

3.5.2. KDE での GPG 鍵の作成

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

警告

パスフレーズを忘れると、データの暗号解除ができなくなります。
GPG 鍵 の ID を見つけるには、新規に作成された鍵の横にある 鍵の ID コラムを確認します。多くの場合、鍵 の ID を求められたら、0x6789ABCD などのように鍵のID の前に 0x を付けます。秘密鍵のバックアップを取り、安全な場所に保管してください。

3.5.3. コマンドラインを用いた GPG 鍵の生成

  1. 次のシェルコマンドを使用します。
    ~]$ gpg2 --gen-key
    このコマンドは、公開鍵と秘密鍵で構成される鍵ペアを生成します。受信側の人々は、ユーザーからの通信の認証や暗号化解除を行うためにこのユーザーの公開鍵を使用します。そのため、とりわけメーリングリストのように、送信者からの認証済みの通信を受け取ることを希望すると思われる人々に向けて、できる限り幅広く公開鍵を配布してください。
  2. 一連のプロンプトにしたがってプロセスを進めます。デフォルト値を割り当てる場合は Enter キーを押します。最初のプロンプトは、使用を希望する鍵の種類を選択するよう尋ねます。
    Please select what kind of key you want:
    (1) RSA and RSA (default)
    (2) DSA and Elgamal
    (3) DSA (sign only)
    (4) RSA (sign only)
    Your selection?
    
    ほとんど多くの場合、デフォルトが適切な選択になります。RSA/RSA 鍵を選択すると、通信に署名するだけでなく、ファイルを暗号化することができます。
  3. 鍵のサイズを選択します。
    RSA keys may be between 1024 and 4096 bits long.
    What keysize do you want? (2048)
    
    ここでも、デフォルトの 2048 はほとんどすべてのユーザーに適しており、これは極めて強いレベルのセキュリティになります。
  4. 鍵の有効期限を選択します。デフォルトの none を使用するのではなく、失効日を選択する方がよいでしょう。例えば、鍵にある電子メールアドレスが無効になると、失効日が設定されているために、他の人々はその公開鍵を使用するのを止めるように通知されます。
    Please specify how long the key should be valid.
    0 = key does not expire
    d = key expires in n days
    w = key expires in n weeks
    m = key expires in n months
    y = key expires in n years
    key is valid for? (0)
    
    例えば、1y の値を入力すると、鍵の有効期間は 1 年間になります (鍵の生成後にこの失効日を変更することができます。)
  5. gpg2 プログラムが署名情報を尋ねる前に、以下のプロンプトが表示されます。
    Is this correct (y/N)?
    プロセスを終了するには y を入力します。
  6. GPG 鍵用に氏名と電子メールアドレスを入力します。このプロセスは、ユーザーを個人として認証するためのものです。このため、本当の名前を入力してください。偽の電子メールアドレスを選択すると、他の人があなたの公開鍵を見つけにくくなります。これにより、通信の認証が困難になります。例えば、メーリングリストの自己紹介にこの GPG 鍵を使用する場合、そのリストで使用している電子メールアドレスを入力します。
    コメントフィールドには、エイリアスやその他の情報を記載します。(一部の人は、目的別に複数の鍵を使用しており、「オフィス」または「オープンソースプロジェクト」などのコメントを付けてそれぞれの鍵を識別しています。)
  7. すべてのエントリが正しければ、確認プロンプトで O と入力して続行するか、または問題がある場合はそれを修正するために他のオプションを使用します。最後に、秘密鍵のパスフレーズを入力します。gpg2 プログラムは、入力エラーがないことを確認するためにパスフレーズを 2 回入力するように指示します。
  8. 最後に、gpg2 はランダムなデータを生成して鍵を可能な限り一意なものにします。このプロセスをスピードアップするには、この手順の実行中にマウスを動かし、ランダムなキーを入力するか、またはシステム上で他のタスクを実行します。この手順が完了すると、鍵が完成して使用可能な状態になります。
    	  pub  1024D/1B2AFA1C 2005-03-31 John Q. Doe <jqdoe@example.com>
    	  Key fingerprint = 117C FE83 22EA B843 3E86  6486 4320 545E 1B2A FA1C
    	  sub  1024g/CEA4B22E 2005-03-31 [expires: 2006-03-31]
    
  9. 鍵のフィンガープリントは、あなたの鍵の「署名」の短縮版です。これを使って、他の人々があなたの実際の公開鍵を (改ざんされない状態で) 受け取ったことを確認することができます。このフィンガープリントを書き留めておく必要はありません。フィンガープリントを表示するには、以下のコマンドをあなたの電子メールアドレスに置き換えて使用します。
    ~]$ gpg2 --fingerprint jqdoe@example.com
    「GPG 鍵 の ID」は、公開鍵を識別する 16 進法の 8 文字で構成されます。上記の例では、GPG 鍵 ID は 1B2AFA1C です。多くの場合、鍵 ID を求められる際には、0x6789ABCD などのように、鍵 ID の前に 0x を付けます。

警告

パスフレーズを忘れると、鍵を使うことができなくなり、その鍵で暗号化されたすべてのデータが失われます。

3.6. stunnel の使用

stunnel プログラムは、クライアントとサーバー間の暗号化ラッパーです。設定ファイルで指定されたポートをリッスンし、クライアントとの通信を暗号化し、通常のポートでリッスンしているオリジナルのデーモンにデータを転送します。こうすることで、それ自体で暗号化をサポートしていないサービスをセキュアにすることができます。また、SSL バージョン 2 や 3 など、POODLE SSL 脆弱性 (CVE-2014-3566) の影響を受け、安全上に理由から使用を避けたい暗号化サービスのセキュリティを改善することもできます。詳細は、https://access.redhat.com/solutions/1234773 を参照してください。(Red Hat Enterprise Linux 6.6 以前の) 2.4.39 以前の OpenLDAP および CUPS は、自身の設定で SSL を無効にする方法がないコンポーネントの例です。

3.6.1. stunnel のインストール

stunnel パッケージをインストールするには、root で以下のコマンドを実行します。
~]# yum install stunnel

3.6.2. stunnel を TLS ラッパーとして設定する

stunnel の設定は、以下の手順にしたがいます。
  1. stunnel とどのサービスを使うにしても、有効な証明書が必要になります。適切な証明書がない場合は、認証機関 に申し込むか、自己署名の証明書を自身で作成することもできます。

    警告

    実稼働環境で稼働しているサーバーには、常に認証機関で署名された証明書を使用してください。自己署名証明書は、テスト目的またはプライベートネットワークのみで使用することをお勧めします
    stunnel 用に自己署名証明書を作成するには、root/etc/pki/tls/certs/ ディレクトリーに移動し、以下のコマンドを実行します。
    certs]# make stunnel.pem
    すべての質問に回答して、プロセスを完了します。
  2. 証明書ができたら、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 — 変更後の root ディレクトリーです。ここでは、stunnel プロセスがより安全に実行できます。
    • setuid, setgidstunnel プロセスを実行するユーザーおよびグループ。nobody は制限されたシステムアカウントになります。
    • pidstunnel がプロセス ID を保存するファイルで、chroot に相対的になります。
    • socket — ローカルおよびリモートのソケットオプション。このケースでは、ネーグルのアルゴリズムを無効にして、ネットワーク遅延を改善します。
    • [service_name] — サービ定義の開始点。この下に続く行で使用されるオプションは、該当サービのみに適用されます。この上にあるオプションは、 stunnel でグローバルに適用されます。
    • accept — リッスンするポートです。
    • connect — 接続先のポートです。このポートは、セキュアにしているサービスが使用するものである必要があります。
    • TIMEOUTclose — クライアントから close_notify 警告が出されるまでの待ち時間です。これが 0 の場合は、stunnel はまったく待機しません。
    • options — OpenSSL ライブラリーのオプション。

    例3.1 OpenLDAP のセキュア化

    2.4.39 以前の OpenLDAP で stunnel を TLS ラッパーとして設定するには、以下の値を使用します。
    [openldap]
    accept = 636
    connect = 389
    636 は、セキュアな LDAP の標準ポートです。389 は、OpenLDAP デーモンがリッスンするポートです。

    例3.2 CUPS のセキュア化

    同様に、CUPS 用に stunnel を TLS ラッパーとして設定するには、以下の値を使用します。
    [cups]
    accept = 632
    connect = 631
    632 の代わりに使用されていないポートを使うこともできます。631CUPS が通常使用するポートです。
  3. chroot ディレクトリーを作成し、setuid オプションで指定されているユーザーにこのディレクトリーへの書き込みアクセスを与えます。これを行うには、root で以下のコマンドを実行します。
    ~]# mkdir /var/run/stunnel
    ~]# chown nobody:nobody /var/run/stunnel
    これで、stunnel が PID ファイルを作成できるようになります。
  4. 使用中のシステムでファイアウォールが新たなポートへのアクセスを許可しない設定となっている場合は、この設定を許可するように変更します。詳細は、「ファイアウォール」「他のポート」 を参照してください。
  5. 設定ファイルと chroot ディレクトリーを作成し、指定されたポートがアクセス可能なことを確認したら、stunnel を開始することができます。

3.6.3. stunnel の起動、停止、再起動

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

3.7. TLS 設定の強化

TLS (トランスポート層セキュリティ) は、ネットワーク通信をセキュアにするために使用する暗号化プロトコルです。優先する鍵交換プロトコル認証方法、および暗号化アルゴリズムを設定することでシステムのセキュリティ設定を強化する際には、サポートするクライアントの範囲が広ければ広いほど、セキュリティのレベルが低くなることを認識しておく必要があります。反対に、セキュリティ設定を厳密にすると、クライアントとの互換性が制限され、システムからロックアウトされるユーザーが出てくる可能性もあります。可能な限り厳密な設定を目指し、互換性のために必要な場合にのみ、これを緩めるようにしてください。
Red Hat Enterprise Linux に含まれるライブラリーが提供するデフォルト設定は、ほとんどの導入において十分に安全なものです。TLS 実装は、可能な場合はセキュアなアルゴリズムを使用する一方で、レガシークライアントまたはサーバーとの接続を妨げません。セキュアなアルゴリズムやプロトコルをサポートしていないレガシーのクライアントやサーバーの接続が期待できない場合やそれらの接続が許可されない場合に、厳密なセキュリティ要件の環境で本セクションで説明されている強化設定を適用してください。

3.7.1. 有効にするアルゴリズムの選択

いくつかのコンポーネントを選択して設定する必要があります。以下で説明するものはすべて、その設定結果 (つまり、クライアントにおけるサポートレベル) やシステム上でソリューションが持つコンピューターのデマンドに直接影響します。

プロトコルのバージョン

最新バージョンの TLS は、すぐれたセキュリティメカニズムを提供します。古いバージョンの TLS (さらに SSL) のサポートを含める切実な理由がなければ、最新バージョンの TLS のみを使ってシステムが接続するようにしてください。
SSL のバージョン 2 または 3 を使った処理を許可しないでください。これらのバージョンには、セキュリティに関する重大な脆弱性があります。TLS のバージョン 1.0 以上を使った処理のみを許可してください。現行の TLS バージョン 1.2 を常に優先するようにしてください。

注記

TLS の全バージョンのセキュリティは現在、TLS 拡張機能、特定の暗号 (下記参照)、および他の回避策に依存していることに注意してください。TLS の接続ピアはすべてセキュアな再交渉記号 (RFC 5746) を実装する必要があり、圧縮をサポートしていない必要があります。また、CBC モードの暗号 (Lucky Thirteen 攻撃) に対するタイミング攻撃を緩和する方法を実装する必要があります。TLS v1.0 クライアントはさらに、レコード分割 (BEAST 攻撃に対する回避策) を実装する必要があります。TLS v1.2 は、AES-GCMAES-CCM、または Camellia-GCM といった既知の問題のない 認証付き暗号 (Authenticated Encryption with Associated Data : AEAD) モードの暗号をサポートしています。ここに記載された緩和策はすべて、Red Hat Enterprise Linux に含まれる暗号ライブラリーに実装されています。
プロトコルのバージョンおよび推奨される使用方法についての概要は、表3.1「プロトコルのバージョン」 を参照してください。

表3.1 プロトコルのバージョン

プロトコルのバージョン推奨される使用方法
SSL v2
使用しないでください。重大なセキュリティ上の脆弱性があります。
SSL v3
使用しないでください。重大なセキュリティ上の脆弱性があります。
TLS v1.0
必要な場合は、相互運用性目的で使用します。相互運用性を保証する方法では緩和できない既知の問題があります。このため、緩和策はデフォルトでは有効になっていません。最新の暗号化スイートには対応していません。
TLS v1.1
必要な場合は、相互運用性目的で使用します。既知の問題はありませんが、Red Hat Enterprise Linux の TLS 実装すべてに含まれるプロトコル修正に依存します。最新の暗号化スイートには対応していません。
TLS v1.2
推奨されるバージョンです。最新の AEAD 暗号化スイートに対応しています。
Red Hat Enterprise Linux のコンポーネントのなかには、TLS v1.1v1.2 に対応しているのに TLS v1.0 を使用する設定になっているものもあります。これは、最新バージョンの TLS に対応していない可能性のある外部サービスとの最高レベルの相互運用性を達成する目的でこのようになっています。相互運用性の要件に対応して、利用可能な最高レベルの TLS バージョンを有効にしてください。

重要

SSL v3 の使用は推奨されません。これはセキュアではなく一般の使用には適していませんが、SSL v3 をどうしても有効にする必要がある場合は、「stunnel の使用」 を参照してください。暗号化に対応していない、または旧式でセキュアでない暗号化モードの使用しかできないサービスを使用する場合でも、stunnel を使用して安全に通信を暗号化する方法が説明されています。
128 ビット未満のセキュリティしか提供しない暗号化スイートは直ちに不安というわけではありませんが、これらは短期間の使用に考慮すべきではありません。128 ビット以上のセキュリティを使用するアルゴリズムは少なくとも数年間は解読不可能であることが期待されているので、強く推奨されます。3DES 暗号は 168 ビットの使用を提供しますが、実際に提供されているのは 112 ビットのセキュリティであることに注意してください。
(perfect) forward secrecy (PFS) をサポートしている暗号化スイートを常に優先させてください。PFS は、サーバー鍵が漏れたとしても、暗号化されたデータの秘密性は確保されます。これにより、すばやい RSA 鍵の交換がなくなる一方、ECDHE および DHE の使用が可能になります。これら 2 つのうちでは、ECDHE の方がより速いため、優先される選択肢となります。
また、ECDSA 証明書を使って ECDHE 鍵交換を使用する際は、純粋な RSA 鍵交換よりも速くなります。レガシークライアント用のサポートを提供するには、サーバー上に証明書と鍵のペアを 2 つインストールします。ひとつは ECDSA 鍵 (新規クライアント用) で、もうひとつは RSA 鍵 (レガシークライアント用) です。

公開鍵の長さ

RSA 鍵を使用する際は常に、少なくとも SHA-256 で署名された 最低 3072 ビットの鍵の長さを優先させます。これは、真の 128 ビットのセキュリティでは十分な大きさです。

警告

システムのセキュリティ強度は、チェーンの中の最も弱いリンクが示すものと同じであるということを念頭に置いてください。たとえば、強力な暗号化だけではすぐれたセキュリティは保証されません。鍵と証明書も同様に重要で、認証機関 (CA) が鍵の署名に使用するハッシュ機能と鍵もまた重要になります。

3.7.2. TLS 実装の使用

Red Hat Enterprise Linux には、完全機能の TLS 実装が同梱されています。本セクションでは、OpenSSL および GnuTLS の設定を説明します。個別アプリケーションでの TLS サポートの設定方法については、「特定アプリケーションの設定」 を参照してください。
利用可能な TLS 実装は、各種の 暗号化スイートをサポートします。これらのスイートは、TLS でセキュア化された通信の確立および使用時に一緒に送られる全要素を定義します。
「有効にするアルゴリズムの選択」 で示された推奨事項と検討するとともに、各種の実装で含まれているツールを使って、ご自分のユースケースにとって最善のセキュリティを提供する暗号化スイートを一覧表示、指定してください。そこでできた暗号化スイートを使うと、各アプリケーションが接続を処理してセキュア化することができます。

重要

使用する TLS 実装またはその実装を利用するアプリケーションが更新またはアップグレードされた後は、必ず使用中の設定をチェックしてください。新しいバージョンは、ユーザーが有効化を希望せずかつ使用中の設定が無効にしない新たな暗号化スイートを導入する場合があります。

3.7.2.1. OpenSSL での暗号化スイートの使用

OpenSSL は、SSL および TLS プロトコルをサポートするツールキットおよび暗号化ライブラリーです。Red Hat Enterprise Linux では、設定ファイルは /etc/pki/tls/openssl.cnf にあります。その形式は、config(1) で確認できます。
インストール済みの OpenSSL でサポートされている暗号化スイートすべてを一覧表示するには、以下のように openssl コマンドで ciphers サブコマンドを実行します。
~]$ openssl ciphers -v 'ALL:COMPLEMENTOFALL'
(OpenSSL ドキュメンテーションでは cipher strings および keywords と呼ばれる) 他のパラメーターを ciphers コマンドに渡して出力を絞ります。特別なキーワードを使うと、特定の条件を満たすスイートのみを一覧表示することができます。たとえば、HIGH グループに属するスイートのみを一覧表示するには、以下のコマンドを実行します。
~]$ openssl ciphers -v 'HIGH'
利用可能なキーワードおよび暗号化文字列の一覧は、ciphers(1) の man ページを参照してください。
「有効にするアルゴリズムの選択」 の推奨事項を満たす暗号化スイートを一覧表示するには、以下のようなコマンドを実行します。
~]$ openssl ciphers -v 'kEECDH+aECDSA+AES:kEECDH+AES+aRSA:kEDH+aRSA+AES' | column -t
ECDHE-ECDSA-AES256-GCM-SHA384  TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AESGCM(256)  Mac=AEAD
ECDHE-ECDSA-AES256-SHA384      TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AES(256)     Mac=SHA384
ECDHE-ECDSA-AES256-SHA         SSLv3    Kx=ECDH  Au=ECDSA  Enc=AES(256)     Mac=SHA1
ECDHE-ECDSA-AES128-GCM-SHA256  TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AESGCM(128)  Mac=AEAD
ECDHE-ECDSA-AES128-SHA256      TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AES(128)     Mac=SHA256
ECDHE-ECDSA-AES128-SHA         SSLv3    Kx=ECDH  Au=ECDSA  Enc=AES(128)     Mac=SHA1
ECDHE-RSA-AES256-GCM-SHA384    TLSv1.2  Kx=ECDH  Au=RSA    Enc=AESGCM(256)  Mac=AEAD
ECDHE-RSA-AES256-SHA384        TLSv1.2  Kx=ECDH  Au=RSA    Enc=AES(256)     Mac=SHA384
ECDHE-RSA-AES256-SHA           SSLv3    Kx=ECDH  Au=RSA    Enc=AES(256)     Mac=SHA1
ECDHE-RSA-AES128-GCM-SHA256    TLSv1.2  Kx=ECDH  Au=RSA    Enc=AESGCM(128)  Mac=AEAD
ECDHE-RSA-AES128-SHA256        TLSv1.2  Kx=ECDH  Au=RSA    Enc=AES(128)     Mac=SHA256
ECDHE-RSA-AES128-SHA           SSLv3    Kx=ECDH  Au=RSA    Enc=AES(128)     Mac=SHA1
DHE-RSA-AES256-GCM-SHA384      TLSv1.2  Kx=DH    Au=RSA    Enc=AESGCM(256)  Mac=AEAD
DHE-RSA-AES256-SHA256          TLSv1.2  Kx=DH    Au=RSA    Enc=AES(256)     Mac=SHA256
DHE-RSA-AES256-SHA             SSLv3    Kx=DH    Au=RSA    Enc=AES(256)     Mac=SHA1
DHE-RSA-AES128-GCM-SHA256      TLSv1.2  Kx=DH    Au=RSA    Enc=AESGCM(128)  Mac=AEAD
DHE-RSA-AES128-SHA256          TLSv1.2  Kx=DH    Au=RSA    Enc=AES(128)     Mac=SHA256
DHE-RSA-AES128-SHA             SSLv3    Kx=DH    Au=RSA    Enc=AES(128)     Mac=SHA1
上記のコマンドはセキュアでない暗号をすべて省略し、ephemeral elliptic curve Diffie-Hellman 鍵交換と ECDSA 暗号を優先します。また、RSA 鍵交換も省略します (perfect forward secrecy が保証されます)。
これはやや厳密な設定であることに注意してください。現実には条件を多少緩和して、より広い範囲のクライアントとの互換性を可能にする必要があるかもしれません。

3.7.2.2. GnuTLS での暗号化スイートの使用

GnuTLS は、SSL および TLS の各プロトコルとそれに関連する技術を実装する通信ライブラリーです。

注記

Red Hat Enterprise Linux 上の GnuTLS は、ほとんどのユースケースに十分なセキュリティをもたらす、最適なデフォルト設定値を提供します。特別なセキュリティ要件がない限り、提供されたデフォルト値の使用が推奨されます。
gnutls-cli コマンドを -l (または --list) オプションと実行すると、サポート対象の暗号化スイートすべてが一覧表示されます。
~]$ gnutls-cli -l
-l オプションで表示された暗号化スイート一覧を絞り込むには、ひとつ以上のパラメーター (GnuTLS ドキュメンテーションでは priority strings および keywords と呼ばれる) を --priority オプションに渡します。利用可能な priority strings の全一覧は、http://www.gnutls.org/manual/gnutls.html#Priority-Strings にある GnuTLS ドキュメンテーションを参照してください。たとえば、少なくとも 128 ビットのセキュリティを提供する暗号化スイート一覧を表示するには、以下のコマンドを実行します。
~]$ gnutls-cli --priority SECURE128 -l
「有効にするアルゴリズムの選択」 の推奨事項を満たす暗号化スイートを一覧表示するには、以下のようなコマンドを実行します。
~]$ gnutls-cli --priority SECURE256:+SECURE128:-VERS-TLS-ALL:+VERS-TLS1.2:-RSA:-DHE-DSS:-CAMELLIA-128-CBC:-CAMELLIA-256-CBC -l
Cipher suites for SECURE256:+SECURE128:-VERS-TLS-ALL:+VERS-TLS1.2:-RSA:-DHE-DSS:-CAMELLIA-128-CBC:-CAMELLIA-256-CBC
TLS_ECDHE_ECDSA_AES_256_GCM_SHA384                      0xc0, 0x2c      TLS1.2
TLS_ECDHE_ECDSA_AES_256_CBC_SHA384                      0xc0, 0x24      TLS1.2
TLS_ECDHE_ECDSA_AES_256_CBC_SHA1                        0xc0, 0x0a      SSL3.0
TLS_ECDHE_ECDSA_AES_128_GCM_SHA256                      0xc0, 0x2b      TLS1.2
TLS_ECDHE_ECDSA_AES_128_CBC_SHA256                      0xc0, 0x23      TLS1.2
TLS_ECDHE_ECDSA_AES_128_CBC_SHA1                        0xc0, 0x09      SSL3.0
TLS_ECDHE_RSA_AES_256_GCM_SHA384                        0xc0, 0x30      TLS1.2
TLS_ECDHE_RSA_AES_256_CBC_SHA1                          0xc0, 0x14      SSL3.0
TLS_ECDHE_RSA_AES_128_GCM_SHA256                        0xc0, 0x2f      TLS1.2
TLS_ECDHE_RSA_AES_128_CBC_SHA256                        0xc0, 0x27      TLS1.2
TLS_ECDHE_RSA_AES_128_CBC_SHA1                          0xc0, 0x13      SSL3.0
TLS_DHE_RSA_AES_256_CBC_SHA256                          0x00, 0x6b      TLS1.2
TLS_DHE_RSA_AES_256_CBC_SHA1                            0x00, 0x39      SSL3.0
TLS_DHE_RSA_AES_128_GCM_SHA256                          0x00, 0x9e      TLS1.2
TLS_DHE_RSA_AES_128_CBC_SHA256                          0x00, 0x67      TLS1.2
TLS_DHE_RSA_AES_128_CBC_SHA1                            0x00, 0x33      SSL3.0

Certificate types: CTYPE-X.509
Protocols: VERS-TLS1.2
Compression: COMP-NULL
Elliptic curves: CURVE-SECP384R1, CURVE-SECP521R1, CURVE-SECP256R1
PK-signatures: SIGN-RSA-SHA384, SIGN-ECDSA-SHA384, SIGN-RSA-SHA512, SIGN-ECDSA-SHA512, SIGN-RSA-SHA256, SIGN-DSA-SHA256, SIGN-ECDSA-SHA256
上記のコマンドは、出力を 128 ビット以上のセキュリティがある暗号に絞り込み、より強力なものを優先しています。また、RSA 鍵交換と DSS 認証を禁止しています。
これはやや厳密な設定であることに注意してください。現実には条件を多少緩和して、より広い範囲のクライアントとの互換性を可能にする必要があるかもしれません。

3.7.3. 特定アプリケーションの設定

アプリケーションはそれぞれ、TLS 用に個別の設定メカニズムを提供します。本セクションでは、最も一般的に使用されているサーバーアプリケーションが使用する TLS 関連の設定ファイルについて説明し、よくある説明例を示します。
いずれの設定を選択しても、サーバーアプリケーションが サーバー側の暗号命令 を強制し、使用される暗号化スイートが必ずユーザー設定の命令で決定されるようにしてください。

3.7.3.1. Apache HTTP サーバーの設定

Apache HTTP Server は、TLSOpenSSLNSS の両方のライブラリーを使用することができます。選択した TLS ライブラリーによって、mod_sslmod_nss のモジュールをインストールする必要があります (その名前の付いたパッケージが提供)。たとえば、OpenSSL mod_ssl モジュールを提供するパッケージをインストールするには、root で以下のコマンドを実行します。
~]# yum install mod_ssl
mod_ssl パッケージは /etc/httpd/conf.d/ssl.conf 設定ファイルをインストールし、これを使うと Apache HTTP ServerTLS 関連の設定を修正できます。同様に、mod_nss パッケージは /etc/httpd/conf.d/nss.conf 設定ファイルをインストールします。
httpd-manual パッケージをインストールして Apache HTTP Server の完全なドキュメンテーションを取得します。これには、TLS 設定が含まれます。/etc/httpd/conf.d/ssl.conf 設定ファイルで利用可能な指示文の詳細は、/usr/share/httpd/manual/mod/mod_ssl.html で説明されています。各種設定の例は、/usr/share/httpd/manual/ssl/ssl_howto.html で確認できます。
/etc/httpd/conf.d/ssl.conf 設定ファイルの設定を修正する場合は、少なくとも下記の 3 つの指示文を確認してください。
SSLProtocol
許可する TLS (または SSL) のバージョンを指定する指示文です。
SSLCipherSuite
優先する暗号化スイートを指定する、もしくは許可しないスイートを無効にする指示文です。
SSLHonorCipherOrder
コメントを解除して、この指示文を on に設定すると、接続先のクライアントが指定された暗号化の命令に従います。
例を示します。
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite HIGH:!aNULL:!MD5
SSLHonorCipherOrder on
上記の設定は最小限のものであり、「有効にするアルゴリズムの選択」 にある推奨事項にしたがうことでさらに強化できることに注意してください。
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 を参照してください。

3.7.4. その他の情報

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

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

  • config(1)/etc/ssl/openssl.conf 設定ファイルの形式を説明しています。
  • ciphers(1) — 利用可能な OpenSSL キーワードおよび暗号化文字列の一覧が含まれています。
  • /usr/share/httpd/manual/mod/mod_ssl.htmlApache HTTP Server 用に mod_ssl が使用する /etc/httpd/conf.d/ssl.conf 設定ファイルで利用可能な指示文を詳細に説明しています。
  • /usr/share/httpd/manual/ssl/ssl_howto.htmlApache HTTP Server 用に mod_ssl が使用する /etc/httpd/conf.d/ssl.conf 設定ファイルでの現実的な設定例が含まれています。

オンラインのドキュメント

第4章 情報セキュリティの一般原則

以下の一般原則は、優れたセキュリティプラクティスの概要を示すものです。
  • 中間者攻撃や盗聴を防ぐために、ネットワークで転送されるすべてのデータを暗号化します。パスワードなどの認証情報を暗号化することは重要です。
  • インストールされているソフトウェアと実行するサービスの量を最小限にします。
  • セキュリティを強化するソフトウェアとツールを使用します。たとえば、強制アクセス制御 (MAC) 用の Security-Enhanced Linux (SELinux)、パケットフィルタリング (ファイアウォール) 用の Netfilter iptables、およびファイル暗号化用の GNU Privacy Guard (GPG) などがあります。
  • 可能な場合は、1 つの攻撃されたサービスが他のサービスの攻撃に使用されるリスクを最小限にするために、それぞれのネットワークサービスを別個のシステムで実行します。
  • ユーザーアカウントのメンテナンスを行います。 強力なパスワードポリシーを作成し、これを適用します。使用されていないユーザーアカウントを削除します。
  • システムとアプリケーションのログのレビューを定期的に行います。デフォルトでは、セキュリティ関連のシステムログは /var/log/secure/var/log/audit/audit.log に書き込まれます。専用のログサーバーにログを送ると、攻撃者がローカルのログを簡単に修正して検知を逃れようとするのを防ぐことができます。
  • 本当に必要な場合を除いて、root ユーザーとしてログインしないようにします。管理者は root としてコマンドを実行するために随時 sudo を使用することが推奨されます。sudo を実行できるユーザーは、/etc/sudoers で指定されています。/etc/sudoers の編集は visudo ユーティリティを使用します。

第5章 セキュアなインストール

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

5.1. ディスクパーティション

Red Hat では、/boot、/、/home、/tmp、および /var/tmp のそれぞれに個別のパーティションを作成することを推奨しています。root パーティション (/) が破損すると、ユーザーのデータは完全に失われてしまいます。個別のパーティションを使うことで、データ損失に対する保護が少しは高まります。また、このパーティションを頻繁にバックアップすることもできます。各パーティションの目的はそれぞれに異なり、これについて説明していきます。
/boot - このパーティションは、ブート時にシステムによって読み込まれる最初のパーティションです。システムを Red Hat Enterprise Linux にブートするために使われるブートローダーとカーネルイメージはこのパーティションに保存されます。このパーティションは暗号化すべきではありません。このパーティションが / に含まれていて、そのパーティションが暗号化されているかまたは他の理由で利用不可能になる場合、システムをブートすることができなくなります。
/home - ユーザーデータ (/home) が別個のパーティションではなく / に保存されていると、このパーティションが一杯になり、オペレーティングシステムが不安定になる可能性があります。さらに、システムを次のバージョンの Red Hat Enterprise Linux にアップグレードする際には、/home パーティションでデータを保存できると、このデータはインストール時に上書きされないので、アップグレードが非常に簡単になります。
/tmp および /var/tmp - /tmp と /var/tmp ディレクトリーはどちらも長期保存の必要がないデータを保存するために使われます。しかし、これらのディレクトリーのいずれかが多くのデータであふれると、ストレージスペースがすべて消費されてしまう可能性があります。こうした状態が発生して、かつこれらのディレクトリーが / に保管されていると、システムが不安定になり、クラッシュする可能性があります。そのため、これらのディレクトリーを個別のパーティションに移動するとよいでしょう。

5.2. LUKS パーティション暗号化の利用

インストールのプロセス中には、パーティションを暗号化するオプションがユーザーに示されます。ユーザーは、パスフレーズを提供する必要があります。これは、パーティションのデータを保護するために使われるバルク暗号鍵を解除する鍵として使用されます。

第6章 ソフトウェアのメンテナンス

ソフトウェアのメンテナンスは、セキュアなシステムを維持するために非常に重要です。攻撃者が既知のホールを使用してシステムに侵入することを防ぐためには、ソフトウェアのパッチが利用可能になり次第すぐに適用することが必須になります。

6.1. 最小限のソフトウェアインストール

コンピューター上の各ソフトウェアには脆弱性が潜んでいる可能性があるので、実際に使用するパッケージのみをインストールすることが推奨されます。インストールを DVD から行う場合は、インストールしたいパッケージのみを選択するようにします。他のパッケージが必要になる場合は、いつでも後でシステムに追加することができます。
最小限のインストールについての詳細は、Red Hat Enterprise Linux 6 インストールガイドパッケージグループの選択のセクションを参照してください。最小限のインストールは、--nobase オプションを使用して kickstart ファイルから実行することもできます。詳細については、Red Hat Enterprise Linux 6 インストールガイドパッケージの選択 のセクションを参照してください。

6.2. セキュリティ更新の計画と設定

すべてのソフトウェアにはバグが含まれます。これらのバグはシステムを悪意のあるユーザーにさらす脆弱性をもたらす可能性があります。パッチを当てていないシステムは、コンピューターへの侵入を招く一般的な原因となります。脆弱性の悪用を防ぐには、セキュリティパッチをタイミングよくインストールする計画が必要です。
家庭用ユーザーにとって、セキュリティ更新はできる限り早くインストールする必要があります。セキュリティ更新を自動インストールの設定にすると、更新時期を覚えておくことが不要になりますが、システムの設定や他のソフトウェアとの競合の発生リスクの可能性が若干残ります。
ビジネスユーザーや上級の家庭用ユーザーの場合、セキュリティ更新のインストールに向けて、そのテストとスケジューリングを行う必要があります。パッチのリリースからシステムへのインストールまでの間にシステムを保護するには、新たな制御が必要になります。これらの制御は脆弱性の種類によって異なりますが、ファイアウォールの追加ルールや、外部ファイアウォールの使用、またはソフトウェア設定の変更などがこれらに含まれることがあります。

6.3. 自動更新の調整

Red Hat Enterprise Linux は日次ベースですべての更新を適用するように設定されています。システムからの更新のインストール方法を変更したい場合は、ソフトウェア更新の詳細設定から変更する必要があります。スケジュールや適用する更新の種類、または利用可能な更新の通知方法などを変更することができます。
GNOME では、システム設定ソフトウェア更新 の順に選択して更新を制御できます。 KDE では、アプリケーション設定ソフトウェアの更新の順に選択します。

6.4. 一般的なリポジトリからの署名パッケージのインストール

ソフトウェアパッケージはリポジトリで公開されます。一般的なリポジトリは、すべてパッケージの署名をサポートしています。パッケージの署名では、リポジトリから公開されているパッケージが署名時から変更されていないことを証明するために、公開鍵の技術が使用されます。これにより、パッケージの作成からダウンロードまでの間に悪意を持って改ざんされた可能性のあるソフトウェアをインストールしてしまうことから保護されます。
多数のリポジトリを使用したり、信頼できないリポジトリまたは署名のないパッケージを含むリポジトリを使用すると、悪意のあるコードや脆弱性のあるコードをシステムに取り込むリスクが高まります。リポジトリを yum またはソフトウェア更新に追加する際は注意してください。

第7章 システム監査

Linux Audit システムは、システム上のセキュリティ関連情報を追跡する方法を提供します。事前設定ルールに基づき、Audit はシステム上で発生しているイベントについての情報をできるだけ多く記録するためのログエントリーを生成します。この情報は、セキュリティポリシーの違反者と違反者によるアクションを判断する上でミッションクリティカルな環境で必須のものです。Audit は新たなセキュリティをシステムに追加するわけではありません。システム上で使われているセキュリティポリシーの侵害を発見するために使用されます。これらの侵害は、SELinux などの追加のセキュリティ対策でさらに防ぐことができます。
Audit がログファイルに記録できる情報のいくつかを、以下のリストで要約しています。
  • イベントの日付と時間、タイプ、結果。
  • サブジェクトとオブジェクトの機密性のラベル。
  • イベントを開始したユーザーの ID とイベントの関連性。
  • Audit 設定の全修正および Audit ログファイルへのアクセス試行。
  • SSH、Kerberos、およびその他の認証メカニズムのすべての使用。
  • /etc/passwd のような、信頼できるデータベースへの変更。
  • システムとの情報のインポートおよびエクスポートの試行。
  • ユーザー ID、サブジェクトおよびオブジェクトラベル、その他の属性に基づく include または exclude イベント。
Audit システムの使用は、多くのセキュリティ関連の証明書における要件でもあります。Audit は、以下の証明書またはコンプライアンスガイドの要件に合致するかそれらを超えるように設計されています。
  • Controlled Access Protection Profile (CAPP)
  • Labeled Security Protection Profile (LSPP)
  • Rule Set Base Access Control (RSBAC)
  • NISPOM (National Industrial Security Program Operating Manual)
  • Federal Information Security Management Act (FISMA)
  • Payment Card Industry — Data Security Standard (PCI-DSS)
  • セキュリティ技術実装ガイド (STIG: Security Technical Implementation Guide)
Audit は以下でも認定されています。
  • National Information Assurance Partnership (NIAP) および Best Security Industries (BSI) による評価。
  • Red Hat Enterprise Linux 5 上での LSPP/CAPP/RSBAC/EAL4+ の認定。
  • Red Hat Enterprise Linux 6 上での Operating System Protection Profile / Evaluation Assurance Level 4+ (OSPP/EAL4+) の認定。

使用例

ファイルアクセスの監視
Audit は、ファイルやディレクトリーがアクセス、修正、実行されたか、またはファイル属性が変更されたかを追跡することができます。これはたとえば、重要なファイルへのアクセスを検出し、これらのファイルが破損した場合に監査証跡を入手可能とする際に便利なものです。
システムコールの監視
Audit は、特定のシステムコールが使用されるたびにログエントリーを生成するように設定できます。これを使用すると、settimeofdayclock_adjtime、その他の時間関連のシステムコールを監視することで、システム時間への変更を追跡できます。
ユーザーが実行したコマンドの記録
Audit はファイルが実行されたかどうかを追跡できるので、特定のコマンドの実行を毎回記録するようにいくつものルールを定義することができます。たとえば、/bin ディレクトリー内の実行可能ファイルすべてについてルールを定義することができます。その結果できるログエントリーをユーザー ID で検索すると、ユーザーごとに実行されたコマンドの監査証跡を生成することができます。
セキュリティイベントの記録
pam_faillock 認証モジュールは、失敗したログイン試行を記録することができます。Audit で失敗したログイン試行も記録するように設定すると、ログインを試みたユーザーについての追加情報が提供されます。
イベントの検索
Audit は ausearch ユーティリティーを提供します。これを使うと、ログエントリーをフィルターにかけ、いくつもの条件に基づく完全な監査証跡を提供することができます。
サマリーレポートの実行
aureport ユーティリティーを使うと、記録されたイベントのデイリーレポートを生成することができます。システム管理者は、このレポートを分析し、疑わしいアクティビティーをさらに調べることができます。
ネットワークアクセスの監視
iptablesebtables ユーティリティーは Audit イベントを開始するように設定でき、これでシステム管理者はネットワークアクセスを監視できるようになります。

注記

システムのパフォーマンスは、Audit が収集する情報量によって影響される可能性があります。

7.1. Audit システムのアーキテクチャー

Audit システムは、ユーザースペースアプリケーションおよびユーティリティーと、カーネル側のシステムコール処理という 2 つの主要パートで構成されます。カーネルコンポーネントは、ユーザースペースアプリケーションからシステムコールを受け、これを usertask、または exit のいずれかのフィルターで振り分けます。システムコールがフィルターのどれかを通過すると、exclude フィルターに掛けられます。このフィルターは Audit ルール設定に基づいて、システムコールを Audit デーモンに送信してさらに処理します。図7.1「Audit システムのアーキテクチャー」 では、このプロセスを示しています。
Audit システムのアーキテクチャー

図7.1 Audit システムのアーキテクチャー

ユーザースペースの Audit デーモンはカーネルから情報を収集し、ログファイルにログファイルエントリーを作成します。他のユーザースペースユーティリティーは、Audit デーモン、カーネル Audit コンポーネント、または Audit ログファイルと対話します。
  • audisp — Audit ディスパッチャーデーモンは Audit デーモンと対話し、イベントを他のアプリケーションに送信してさらに処理します。このデーモンの目的は、プラグインメカニズムを提供して、リアルタイムの分析プログラムが Audit イベントと対話できるようにすることです。
  • auditctl — Audit 制御ユーティリティーはカーネル Audit コンポーネントと対話し、イベント生成プロセスの多くの設定やパラメーターを制御します。
  • 残りの Audit ユーティリティーは Audit ログファイルのコンテンツを入力として受け取り、ユーザーの要件に基づいて出力を生成します。たとえば、aureport ユーティリティーは記録された全イベントのレポートを生成します。

7.2. audit パッケージのインストール

Audit システムを使用するには、audit パッケージがシステムにインストールされている必要があります。audit パッケージ (audit および audit-libs) は、デフォルトで Red Hat Enterprise Linux 6 にインストールされています。これらのパッケージがインストールされていない場合は、root で以下のコマンド実行してインストールします。
~]# yum install audit

7.3. audit サービスの設定

Audit デーモンは、/etc/audit/auditd.conf 設定ファイルで設定できます。このファイルは、Audit デーモンの動作を修正する設定パラメーターで構成されています。空の行やハッシュ記号 (#) の後に続くテキストは無視されます。設定パラメーターの全一覧とそれらの説明は、audit.conf(5) man ページで確認できます。

7.3.1. CAPP 環境用の auditd 設定

デフォルトの auditd 設定は、ほとんどの環境で適切なものです。ただし、使用中の環境が、Common Criteria 認証の一部である Controlled Access Protection Profile (CAPP) で設定された基準に適合する必要がある場合は、以下のように Audit デーモンを設定する必要があります。
  • Audit ログファイルを格納するディレクトリー (通常 /var/log/audit/) を、別個のパーティションに置きます。これにより、他のプロセスがこのディレクトリーのスペースを使うことを防ぎます。また、Audit デーモン用に残りのスペースがどれだけあるか、正確に分かるようになります。
  • 単一 Audit ログファイルの最大サイズを指定する max_log_file パラメーターは、Audit ログファイルを格納するパーティション上で利用可能なスペースを最大活用するように設定する必要があります。
  • max_log_file_action パラメーターは、max_log_file で設定された上限に達した際に取られるアクションを決定します。これは、keep_logs に設定して、Audit ログファイルが上書きされないようにすべきです。
  • space_left パラメーターは、ここで指定した値にディスク上の残りの空きスペースが達すると、space_left_action パラメーターで定義したアクションが起動します。space_left で指定するディスクの残り空きスペースの値は大きなものに設定し、これがなくなる前に管理者が対応してスペースを利用可能にできるようにすべきです。space_left の値は、Audit ログファイルが生成されるレートによって異なります。
  • space_left_action パラメーターは、email または exec に設定して適切な通知方法にすることが推奨されます。
  • admin_space_left パラメーターは、ここで指定した値にディスク上の残りの空きスペースが達すると、admin_space_left_action パラメーターで定義したアクションが起動します。admin_space_left の値は大きなものに設定し、管理者が実行するアクションをログ記録できるようにする必要があります。
  • admin_space_left_actionsingle に設定して、システムをシングルユーザーモードにし、管理者がディスクスペースを解放できるようにする必要があります。
  • disk_full_action パラメーターは、Audit ログファイルを格納するパーティションに空きスペースが無くなった場合に起動するアクションを指定します。このパラメーターは、halt または single のどちらかに設定する必要があります。これにより、Audit がイベントをログ記録できなくなった際に、システムがシャットダウンするか、シングルユーザーモードで稼働するようになります。
  • disk_error_action は、Audit ログファイルがあるパーティションでエラーが検出された場合に起動するアクションを指定します。このパラメーターは、ハードウェアの機能不全処理に関するローカルのセキュリティポリシーによって、syslogsinglehalt のいずれかに設定する必要があります。
  • flush 設定パラメーターは、sync または data に設定します。これにより、すべての Audit イベントデータがディスク上のログファイルと完全に同期されます。
残りの設定オプションは、ローカルのセキュリティポリシーにあわせて設定します。

7.4. audit サービスの起動

auditd を適切に設定したら、サービスを起動して Audit 情報を収集し、ログファイルに保存します。root で以下のコマンドを実行して auditd を起動します。
~]# service auditd start
オプションでは、root で以下のコマンドを実行すると、auditd がブート時に起動するように設定できます。
~]# chkconfig auditd on
auditd では、service auditd action コマンドを使用して、他のアクションが実行できます。ここでの action は、以下のいずれかになります。
  • stopauditd を停止します。
  • restartauditd を再起動します。
  • reload または force-reloadauditd の設定を /etc/audit/auditd.conf ファイルから再読み込みします。
  • rotate/var/log/audit/ ディレクトリー内のログファイルを回転させます。
  • resume — Audit イベントのログが一旦停止された後、再開します。たとえば、Audit ログファイルがあるディスクパーティションの未使用スペースが十分でない場合などです。
  • condrestart または try-restartauditd がすでに実行中の場合にのみ、これを再起動します。
  • status — 実行中の auditd のステータスを表示します。

7.5. Audit ルールの定義

Audit システムは、ログファイルにキャプチャーされるものを定義するルールセットで作動します。指定可能な Audit ルールには、以下の 3 つのタイプがあります。
  • 制御ルール — Audit システムの動作と設定のいくつかの修正が可能になります。
  • ファイルシステムルール — ファイルウォッチとも呼ばれ、特定のファイルまたはディレクトリーへのアクセスの監査が可能になります。
  • システムコールルール — 特定のプログラムが実行するシステムコールのログ記録が可能になります。
Audit ルールは、auditctl ユーティリティーのコマンドラインで指定するか (このルールは再起動後は維持されません)、/etc/audit/audit.rules ファイルに書き込んで指定することができます。以下の 2 つのセクションでは、Audit ルール定義における両方のアプローチをまとめています。

7.5.1. auditctl ユーティリティーを使った Audit ルールの定義

注記

Audit サービスおよび Audit ログファイルと対話するすべてのコマンドは、root 権限が必要になります。これらのコマンドは、必ず root ユーザーとして実行してください。
auditctl コマンドを使うと、Audit システムの基本的な機能を制御し、どの Audit イベントをログ記録するかを決定するルールが定義できます。

制御ルールの定義

以下の制御ルールを使うと、Audit システムの動作が修正できます。
-b
カーネルにおける 既存のAudit バッファの最大値を設定します。例を示します。
~]# auditctl -b 8192
-f
重大なエラーが検出された際に実行されるアクションを設定します。例を示します。
~]# auditctl -f 2
上記の設定では、重大なエラーが発生した際にカーネルパニックが起動されます。
-e
Audit システムを有効または無効にする、もしくは設定をロックします。例を示します。
~]# auditctl -e 2
上記のコマンドは、Audit 設定をロックします。
-r
1 秒あたりに生成されるメッセージ数を設定します。例を示します。
~]# auditctl -r 0
上記の設定では、生成されるメッセージ数は制限されません。
-s
Audit システムのステータスをレポートします。例を示します。
~]# auditctl -s
AUDIT_STATUS: enabled=1 flag=2 pid=0 rate_limit=0 backlog_limit=8192 lost=259 backlog=0
-l
読み込まれている Audit ルールすべてを一覧表示します。例を示します。
~]# auditctl -l
LIST_RULES: exit,always watch=/etc/localtime perm=wa key=time-change
LIST_RULES: exit,always watch=/etc/group perm=wa key=identity
LIST_RULES: exit,always watch=/etc/passwd perm=wa key=identity
LIST_RULES: exit,always watch=/etc/gshadow perm=wa key=identity
⋮
-D
読み込まれている Audit ルールすべてを削除します。例を示します。
~]# auditctl -D
No rules

ファイルシステムルールの定義

ファイルシステムのルールを定義するには、以下の構文を使用します。
auditctl -w path_to_file -p permissions -k key_name
ここでは、
  • path_to_file は、監査対象のファイルもしくはディレクトリーになります。
  • permissions は、ログ記録されるパーミッションになります。
    • r — ファイルまたはディレクトリーの読み取りアクセスです。
    • w — ファイルまたはディレクトリーの書き込みアクセスです。
    • x — ファイルまたはディレクトリーの実行アクセスです。
    • a — ファイルまたはディレクトリーの属性を変更します。
  • key_name は、どのルールまたはルールセットが特定のログエントリーを生成したかを特定する際に役立つオプションの文字列です。

例7.1 ファイルシステムルール

/etc/passwd ファイルへのすべての書き込みアクセスとこのファイルのすべての属性変更をログ記録するルールを定義するには、以下のコマンドを実行します。
~]# auditctl -w /etc/passwd -p wa -k passwd_changes
-k オプションに続く文字列は任意のものであることに注意してください。
/etc/selinux/ ディレクトリー内の全ファイルへのすべての書き込みアクセスとこれらファイルのすべての属性変更をログ記録するルールを定義するには、以下のコマンドを実行します。
~]# auditctl -w /etc/selinux/ -p wa -k selinux_changes
Linux カーネルにモジュールを挿入する /sbin/insmod コマンドの実行をログ記録するルールを定義するには、以下のコマンドを実行します。
~]# auditctl -w /sbin/insmod -p x -k module_insertion

システムコールルールの定義

システムコールのルールを定義するには、以下の構文を使用します。
auditctl -a action,filter -S system_call -F field=value -k key_name
ここでは、
  • action および filter は、特定のイベントがいつログ記録されるかを指定します。action は、always または never になります。filter は、イベントにどのカーネルルール適合のフィルターを適用するかを指定します。ルール適合フィルターは、taskexituserexclude のいずれかになります。これらフィルターの詳細については、「Audit システムのアーキテクチャー」 の最初の部分を参照してください。
  • system_call は、名前でシステムコールを指定します。システムコールの全一覧は、/usr/include/asm/unistd_64.h ファイルで確認できます。複数のシステムコールをひとつのグループにまとめて、-S オプションの後にそれらを指定することも可能です。
  • field=value では、指定されたアーキテクチャー、グループ ID、プロセス ID、その他に基づいて、ルールがイベントに合致するようさらに修正する追加オプションを指定します。利用可能なフィールドのタイプおよびそれらの値の全一覧は、auditctl(8) man ページで確認できます。
  • key_name は、どのルールまたはルールセットが特定のログエントリーを生成したかを特定する際に役立つオプションの文字列です。

例7.2 システムコールのルール

システムが 64 ビットアーキテクチャーを使用していて、プログラムが adjtimex または settimeofday システムコールを使用するたびにログエントリーを作成するルールを定義するには、以下のコマンドを実行します。
~]# auditctl -a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time_change
ユーザー ID が 500 以上 (-F auid!=4294967295 オプションを使用すると、ログイン UID が設定されていないユーザーが除外されます) のシステムユーザーがファイルを削除またはファイルの名前を変更するたびにログエントリーを作成するルールを定義するには、以下のコマンドを実行します。
~]# auditctl -a always,exit -S unlink -S unlinkat -S rename -S renameat -F auid>=500 -F auid!=4294967295 -k delete
システムコールルールの構文を使って、ファイルシステムのルールを定義することもできます。以下のコマンドでは、-w /etc/shadow -p wa ファイルシステムルールに似たシステムコールのルールが作成されます。
~]# auditctl -a always,exit -F path=/etc/shadow -F perm=wa

7.5.2. 永続的な Audit ルールの定義と /etc/audit/audit.rules ファイルでの制御

再起動後も維持される Audit ルールを定義するには、そのルールを /etc/audit/audit.rules ファイルに含める必要があります。このファイルは、同じ auditctl コマンドライン構文を使ってルールを指定します。空の行やハッシュ記号 (#) に続くテキストは無視されます。
auditctl コマンドで -R オプションを使うと、指定されたファイルからルールを読み取ることもできます。例を示します。
~]# auditctl -R /usr/share/doc/audit-version/stig.rules

制御ルールの定義

ファイルに含めることができるのは、-b-D-e-f、および -r の制御ルールのみで、これらは Audit の動作を修正します。これらのオプションに関する詳細は、7.5.1項「制御ルールの定義」 を参照してください。

例7.3 audit.rules での制御ルール

# Delete all previous rules
-D

# Set buffer size
-b 8192

# Make the configuration immutable -- reboot is required to change audit rules
-e 2

# Panic when a failure occurs
-f 2

# Generate at most 100 audit messages per second
-r 100

ファイルシステムおよびシステムコールのルールの定義

ファイルシステムおよびシステムコールのルールは、auditctl 構文を使って定義します。auditctl ユーティリティーを使った Audit ルールの定義」 の例は、以下のルールファイルのようになります。

例7.4 audit.rules でのファイルシステムおよびシステムコールのルール

-w /etc/passwd -p wa -k passwd_changes
-w /etc/selinux/ -p wa -k selinux_changes
-w /sbin/insmod -p x -k module_insertion

-a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time_change
-a always,exit -S unlink -S unlinkat -S rename -S renameat -F auid>=500 -F auid!=4294967295 -k delete

事前設定ルールのファイル

/usr/share/doc/audit-version/ ディレクトリーでは、audit パッケージが各種の証明書基準にしたがって事前設定ルールのファイル一式を提供しています。
  • nispom.rules — NISPOM (National Industrial Security Program Operating Manual) の第 8 章で指定されている要件に合致する、Audit ルール設定です。
  • capp.rules — Common Criteria 認証の一部である Controlled Access Protection Profile (CAPP) が設定している要件に合致する、Audit ルール設定です。
  • lspp.rules — Common Criteria 認証の一部である Labeled Security Protection Profile (LSPP) が設定している要件に合致する、Audit ルール設定です。
  • stig.rules — セキュリティ技術実装ガイド (STIG: Security Technical Implementation Guide) で設定している要件に合致する、Audit ルール設定です。
これらの設定ファイルを使用するには、オリジナルの /etc/audit/audit.rules ファイルのバックアップを作成し、選択する設定ファイルをこの /etc/audit/audit.rules にコピーします。
~]# cp /etc/audit/audit.rules /etc/audit/audit.rules_backup
~]# cp /usr/share/doc/audit-version/stig.rules /etc/audit/audit.rules

7.6. Audit ログファイルについて

デフォルトでは、Audit システムはログエントリーを /var/log/audit/audit.log ファイルに保存します。ログローテーションが有効になっていれば、ローテーションされた audit.log ファイルは同じディレクトリーに保存されます。
下記の Audit ルールは、/etc/ssh/sshd_config ファイルの読み取りまたは修正の試行をすべてログ記録します。
-w /etc/ssh/sshd_config -p warx -k sshd_config
auditd デーモンが実行中の場合、以下のコマンドが Audit ログファイルに新規イベントを作成します。
~]# cat /etc/ssh/sshd_config
このイベントは audit.log ファイル内で以下のように見えます。
type=SYSCALL msg=audit(1364481363.243:24287): arch=c000003e syscall=2 success=no exit=-13 a0=7fffd19c5592 a1=0 a2=7fffd19c4b50 a3=a items=1 ppid=2686 pid=3538 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts0 ses=1 comm="cat" exe="/bin/cat" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="sshd_config"
type=CWD msg=audit(1364481363.243:24287):  cwd="/home/shadowman"
type=PATH msg=audit(1364481363.243:24287): item=0 name="/etc/ssh/sshd_config" inode=409248 dev=fd:00 mode=0100600 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0
上記のイベントは、3 つの記録 (それぞれ type= キーワードで開始) で構成されており、これらは同じタイムスタンプとシリアル番号を共有しています。各記録は、いくつかの name=value のペアで構成されており、これらは空白またはコンマ区切りとなっています。以下で上記のイベントを詳しく分析します。

最初の記録

type=SYSCALL
type フィールドには、記録のタイプが記載されます。この例では、この記録がカーネルへのシステムコールで開始されたことを SYSCALL の値が示しています。
タイプの値およびそれらの説明に関する全一覧は、「Audit 記録のタイプ」 を参照してください。
msg=audit(1364481363.243:24287):
msg フィールドでは以下を記録しています。
  • audit(time_stamp:ID) の形式で、記録のタイムスタンプと一意の ID。複数の記録は、それらが同一の Audit イベントの一部として生成されている場合は、同じタイムスタンプと ID を共有できます。
  • 各種のイベント固有の name=value ペア。これは、カーネルもしくはユーザースペースアプリケーションが提供します。
arch=c000003e
arch フィールドには、システムの CPU アーキテクチャーについての情報が含まれます。c000003e という値は、十六進法でエンコードされています。ausearch コマンドで Audit 記録を検索する際は、-i または --interpret オプションを使うと自動的に十六進法の値がヒューマンリーダブルなものに変換されます。c000003e の値は、x86_64 として解釈されます。
syscall=2
syscall フィールドは、カーネルに送信されたシステムコールのタイプを記録します。2 という値は、/usr/include/asm/unistd_64.h ファイル内の ヒューマンリーダブルに相当するものにマッチします。このケースでは、2open システムコールになります。ausyscall ユーティリティーを使うと、システムコール番号をヒューマンリーダブルなものに変換できることに注意してください。ausyscall --dump コマンドを実行すると、システムコールすべてとそれらの番号一覧が表示されます。詳細情報は、ausyscall(8) man ページを参照してください。
success=no
success フィールドは、その特定のイベントで記録されたシステムコールが成功したかどうかを記録します。このケースでは、コールは成功しませんでした。
exit=-13
exit フィールドには、システムコールが返した終了コードを指定する値が含まれています。この値は、システムコールによって異なります。以下のコマンドを使うと、この値をヒューマンリーダブルなものに変換できます。 ausearch --interpret --exit -13 (Audit ログに終了コード -13 で失敗したイベントが含まれていることが前提)。
a0=7fffd19c5592, a1=0, a2=7fffd19c5592, a3=a
a0 から a3 までのフィールドは、このイベントにおけるシステムコールの最初の 4 つの引数を十六進法で記録します。これらの引数は、使用されているシステムコールによって異なります。ausearch ユーティリティーでこれらを変換できます。
items=1
items フィールドには、イベントのパス記録の数が含まれています。
ppid=2686
ppid フィールドは、親プロセス ID (PPID) を記録します。このケースでは、2686bash プロセスの PPID でした。
pid=3538
pid フィールドは、プロセス ID (PID) を記録します。このケースでは、3538 は、cat プロセスの PID でした。
auid=500
auid は、loginuid である Audit ユーザー ID を記録します。この ID は、ログイン時にユーザーに割り当てられ、ユーザーの ID が変更された後でもすべてのプロセスに引き継がれます (たとえば、su - john コマンドでユーザーアカウントを切り替えた場合)。
uid=500
uid フィールドは、分析されているプロセスを開始したユーザーのユーザー ID を記録します。ユーザー ID は、以下のコマンドでユーザー名に変換できます。ausearch -i --uid UID。このケースでは、500shadowman のユーザー ID です。
gid=500
gid フィールドは、分析されているプロセスを開始したユーザーのグループ ID を記録します。
euid=500
euid フィールドは、分析されているプロセスを開始したユーザーの実効ユーザー ID を記録します。
suid=500
suid フィールドは、分析されているプロセスを開始したユーザーのセットユーザー ID を記録します。
fsuid=500
fsuid フィールドは、分析されているプロセスを開始したユーザーのファイルシステムユーザー ID を記録します。
egid=500
egid フィールドは、分析されているプロセスを開始したユーザーの実効グループ ID を記録します。
sgid=500
sgid フィールドは、分析されているプロセスを開始したユーザーのセットグループ ID を記録します。
fsgid=500
fsgid フィールドは、分析されているプロセスを開始したユーザーのファイルシステムグループ ID を記録します。
tty=pts0
tty フィールドは、分析されているプロセスが開始されたターミナルを記録します。
ses=1
ses フィールドは、分析されているプロセスが開始されたセッションのセッション ID を記録します。
comm="cat"
comm フィールドは、分析されているプロセスを開始するために使用されたコマンドのコマンドライン名を記録します。このケースでは、cat コマンドを使ってこの Audit イベントが開始されました。
exe="/bin/cat"
exe フィールドは、分析されているプロセスを開始するために使用された実行可能ファイルへのパスを記録します。
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
subj フィールドは、分析されているプロセスの実行時にラベル付けされた SELinux コンテンツを記録します。
key="sshd_config"
key フィールドは、Audit ログでこのイベントを生成したルールに関連付けられている管理者による定義の文字列を記録します。

2 番目の記録

type=CWD
2 番目の記録では、type フィールドの値は、現在の作業ディレクトリーである CWD になります。このタイプは、最初の記録で指定されているシステムコールを開始したプロセスが実行されている作業ディレクトリーの記録に使われます。
この記録の目的は、相対パスが関連する PATH 記録に保存された場合に、現行プロセスの位置を記録することにあります。この方法により、このプロセスの絶対パスが再構築可能になります。
msg=audit(1364481363.243:24287)
msg フィールドは、最初の記録と同じタイムスタンプと ID の値になります。
cwd="/home/shadowman"
cwd フィールドは、システムコールが開始されたディレクトリーへのパスになります。

3 番目の記録

type=PATH
3 番目の記録では、type フィールドの値は PATH になります。Audit イベントには、システムコールに引数として渡されたすべてのパスに PATH タイプの記録が含まれます。この Audit イベントでは、1 つのパス (/etc/ssh/sshd_config) のみが引数として使われています。
msg=audit(1364481363.243:24287):
msg フィールドは、最初と 2 番目の記録と同じタイムスタンプと ID の値になります。
item=0
item フィールドは、SYSCALL タイプの記録で参照されたアイテム総数のうち、どのアイテムが現行の記録かを示します。この数字はゼロベースで、0 は最初のアイテムであることを示します。
name="/etc/ssh/sshd_config"
name フィールドは、システムコールに引数として渡されたファイルまたはディレクトリーへの完全パスを記録します。このケースでは、/etc/ssh/sshd_config ファイルとなります。
inode=409248
inode フィールドには、このイベントで記録されたファイルまたはディレクトリーに関連する inode 番号が含まれます。以下のコマンドを実行すると、409248 inode 番目に関連するファイルまたはディレクトリーが表示されます。
~]# find / -inum 409248 -print
/etc/ssh/sshd_config
dev=fd:00
dev フィールドは、このイベントで記録されたファイルまたはディレクトリーを含むデバイスのマイナーおよびメジャー ID を示します。このケースでは、値は /dev/fd/0 デバイスを示しています。
mode=0100600
mode フィールドは、ファイルまたはディレクトリーパーミッションを数字表記でエンコードされた形で記録します。このケースでは、0100600-rw------- に変換可能です。つまり、root ユーザーにのみ、/etc/ssh/sshd_config ファイルへの読み取りおよび書き込みパーミッションがあることをなります。
ouid=0
ouid フィールドは、オブジェクトの所有者のユーザー ID を記録します。
ogid=0
ogid フィールドは、オブジェクトの所有者のグループ ID を記録します。
rdev=00:00
rdev フィールドには、特定なファイルにのみ使われる、記録されたデバイス識別子が含まれます。このケースでは、記録されたファイルは通常のファイルなので、使われていません。
obj=system_u:object_r:etc_t:s0
obj フィールドは、実行時に記録されたファイルまたはディレクトリーにラベル付けされる SELinux コンテキストを記録します。
上記で分析された Audit イベントには、イベントに含まれる可能性のあるフィールドのサブセットのみが含まれています。イベントフィールドおよびそれらの説明の全一覧は、「Audit イベントフィールド」 を参照してください。イベントのタイプおよびそれらの説明の全一覧は、「Audit 記録のタイプ」 を参照してください。

例7.5 追加の audit.log イベント

以下の Audit イベントでは、auditd デーモンが正常にスタートしたことを記録しています。ver フィールドでは、開始された Audit デーモンのバージョンを示しています。
type=DAEMON_START msg=audit(1363713609.192:5426): auditd start, ver=2.2 format=raw kernel=2.6.32-358.2.1.el6.x86_64 auid=500 pid=4979 subj=unconfined_u:system_r:auditd_t:s0 res=success
以下の Audit イベントでは、UID が 500 のユーザーが root ユーザーとしてログインを試み、失敗したことを記録しています。
type=USER_AUTH msg=audit(1364475353.159:24270): user pid=3280 uid=500 auid=500 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct="root" exe="/bin/su" hostname=? addr=? terminal=pts/0 res=failed'

7.7. Audit ログファイルの検索

ausearch ユーティリティーを使うと、Audit ログファイル内で特定のイベントを検索できます。デフォルトでは、ausearch/var/log/audit/audit.log ファイルを検索します。ausearch options -if file_name コマンドを使うと、別のファイルを指定できます。ausearch コマンドで複数のオプションを渡すと、AND 演算子の使用に相当します。

例7.6 ausearch を使った Audit ログファイルの検索

失敗したログイン試行を /var/log/audit/audit.log ファイル内で検索するには、以下のコマンドを実行します。
~]# ausearch --message USER_LOGIN --success no --interpret
すべてのアカウント、グループ、役割変更を検索するには、以下のコマンドを実行します。
~]# ausearch -m ADD_USER -m DEL_USER -m ADD_GROUP -m USER_CHAUTHTOK -m DEL_GROUP -m CHGRP_ID -m ROLE_ASSIGN -m ROLE_REMOVE -i
特定のユーザーがそのユーザーのログイン ID (auid) を使って実行したログインのアクションをすべて検索するには、以下のコマンドを実行します。
~]# ausearch -ua 500 -i
昨日から現在までに失敗したすべてのシステムコールを検索するには、以下のコマンドを実行します。
~]# ausearch --start yesterday --end now -m SYSCALL -sv no -i
ausearch オプションの全一覧は、ausearch(8) man ページを参照してください。

7.8. Audit レポートの作成

aureport ユーティリティーを使うと、Audit ログファイルに記録されたイベントについてのサマリーとレポートが生成できます。デフォルトでは、レポート作成のために /var/log/audit/ 内のすべての audit.log ファイルがクエリされます。aureport options -if file_name コマンドを使うと、レポート作成に別のファイルをクエリするよう指定できます。

例7.7 aureport を使った Audit レポートの生成

今日を除いた過去 3 日間にログ記録されたイベントのレポートを生成するには、以下のコマンドを実行します。
~]# aureport --start 04/08/2013 00:00:00 --end 04/11/2013 00:00:00
実行可能ファイルのイベントすべてについてのレポートを生成するには、以下のコマンドを実行します。
~]# aureport -x
上記の実行可能ファイルのレポートのサマリーを生成するには、以下のコマンドを実行します。
~]# aureport -x --summary
全ユーザーの失敗したイベントのレポートサマリーを生成するには、以下のコマンドを実行します。
~]# aureport -u --failed --summary -i
システムユーザーごとのすべてのログイン試行失敗のレポートサマリーを生成するには、以下のコマンドを実行します。
~]# aureport --login --summary -i
ユーザー 500 のすべてのファイルアクセスイベントを検索する ausearch クエリからレポートを生成するには、以下のコマンドを実行します。
~]# ausearch --start today --loginuid 500 --raw | aureport -f --summary
クエリされたすべての Audit ファイルおよびそれらに含まれるイベントの時間帯についてのレポートを生成するには、以下のコマンドを実行します。
~]# aureport -t
aureport オプションの全一覧は、aureport(8) man ページを参照してください。

7.9. Audit 用の PAM 設定

7.9.1. pam_tty_audit の設定

Red Hat Enterprise Linux の監査システムは、pam_tty_audit PAM モジュールを使って、ユーザーが指定した TTY 入力の監査を有効/無効にします。監査対象のユーザーがログインすると、pam_tty_audit はユーザーが /var/log/audit/audit.log ファイルに行ったキー入力をそのまま記録します。このモジュールは auditd デーモンと動作するので、pam_tty_audit を設定する前にこれを有効にしてください。詳細情報は、audit サービスの起動」 を参照してください。
TTY 監査でユーザー名を指定したい場合は、以下の形式で disable および enable オプションを使って、/etc/pam.d/system-auth/etc/pam.d/password-auth の各ファイルを修正します。
 session required pam_tty_audit.so disable=username,username2 enable=username 
オプションでは、ユーザー名はコンマ区切りにします。disable または enable のオプションは、同一のユーザー名に合致するもので反対のオプションを上書きします。TTY 監査が有効になっていると、そのユーザーが開始したプロセスすべてので引き継がれます。特に、あるユーザーが再起動したデーモンは TTY 監査が有効になったままになり、他のユーザーの監査が明示的に無効にされない限り、他のユーザーによる TTY 入力も監査されます。このため、PAM を使用するほとんどのデーモンでは、disable=* を最初のオプションとして使用することが推奨されます。

重要

デフォルトでは、TTY がパスワード入力モードになっている時には、pam_tty_audit はキー入力をログ記録 しません。ログ記録は、以下の方法で他のオプションと一緒に log_passwd オプションを追加することで、再度有効にできます。
 session required pam_tty_audit.so disable=username,username2 enable=username log_passwd 
このモジュールを有効にすると、auditd デーモンが入力を /var/log/audit/audit.log ファイルに書き込みます。TTY 監査では最初にキー入力がバッファに保存され、定期的に記録が書き込まれるか、監査対象のユーザーがログアウトした後に書き込まれるので、入力が直ちにログ記録されるわけではないことに注意してください。audit.log ファイルには、バックスペースや削除、リターンキー、コントロールキーなど、指定されたユーザーによる すべての キー入力が含まれます。audit.log のコンテンツはヒューマンリーダブルですが、aureport ユーティリティーを使うと読みやすい形式の TTY レポートが提供されます。root で以下のコマンドを実行します。
~]# aureport --tty
以下の例では、すべてのターミナルにわたる root ユーザーのアクションを追跡するように pam_tty_audit を設定し、その後に入力を見直します。

例7.8 root のアクションをログ記録する pam_tty_audit の設定

以下の行を /etc/pam.d/system-auth および /etc/pam.d/password-auth の各ファイルの session セクションに加えます。
session    required     pam_tty_audit.so disable=* enable=root
aureport --tty コマンドを使ってログを確認します。root ユーザーが 11 時ごろに TTY コンソールにログインし、pwd コマンドを発行し、その後にそれを削除して代わりに ls を発行していると、レポートは以下のようになります。
~]# aureport --tty -ts today | tail			
40. 08/28/2014 11:00:27 901 0 ? 76 bash "pwd",<backspace>,<backspace><backspace>,"ls",<ret>
41. 08/28/2014 11:00:29 903 0 ? 76 bash <^D>
詳細情報は、pam_tty_audit(8) man ページを参照してください。

7.10. その他のリソース

Audit システムについての詳細情報は、以下のリソースを参照してください。

オンラインのリソース

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

audit パッケージが提供するドキュメンテーションは、/usr/share/doc/audit-version/ ディレクトリーにあります。

man ページ

  • audispd.conf(5)
  • auditd.conf(5)
  • ausearch-expression(5)
  • audit.rules(7)
  • audispd(8)
  • auditctl(8)
  • auditd(8)
  • aulast(8)
  • aulastlog(8)
  • aureport(8)
  • ausearch(8)
  • ausyscall(8)
  • autrace(8)
  • auvirt(8)

第8章 コンプライアンスおよび OpenSCAP を使った脆弱性のスキャン

8.1. Red Hat Enterprise Linux におけるセキュリティコンプライアンス

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

Red Hat Enterprise Linux 7 でサポートされているセキュリティコンプライアンスツール

  • OpenSCAPoscap コマンドラインユーティリティーは、ローカルシステムの上で設計スキャンと脆弱性スキャンを実行するように設計されています。これにより、セキュリティコンプライアンスのコンテンツを確認し、スキャンと評価に基づいてレポートとガイドを生成します。
  • Script Check Engine (SCE) — SCE は SCAP プロトコルの拡張機能で、コンテンツ作成者が Bash や Python、Ruby といったスクリプト言語を使ってセキュリティコンテンツを書けるようになります。SCE 拡張機能は、openscap-engine-sce パッケージで提供されます。
  • SCAP Security Guide (SSG)scap-security-guide パッケージは、Linux システム用の最新セキュリティポリシーのコレクションを提供します。
複数のリモートのシステムで自動コンプライアンス監査を実行する必要がある場合は、Red Hat Satellite 用の OpenSCAP ソリューションを利用することができます。詳細は、「Red Hat Satellite での OpenSCAP の使用」 および 「その他のリソース」 を参照してください。

注記

Red Hat は、Red Hat Enterprise Linux 6 ディストリビューションではデフォルトでコンプライアンスポリシーを提供していないことに注意してください。この理由については、「コンプライアンスポリシーの定義」 で説明されています。

8.2. コンプライアンスポリシーの定義

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

SCAP コンポーネント

  • 言語 — このグループは、コンプライアンスポリシーを表現する標準的な語彙および慣習を定義する SCAP 言語で構成されます。
    • eXtensible Configuration Checklist Description Format (XCCDF) — セキュリティガイダンスを表示、組織、および管理するための言語です。
    • Open Vulnerability and Assessment Language (OVAL) — スキャンされたシステムの状態について論理的アサーションを実行するための言語です。
    • Open Checklist Interactive Language (OCIL) — ユーザーにクエリを行い、その質問に対するユーザーの返答を解釈するための標準的な方法を提供する言語です。
    • Asset Identification (AI) — セキュリティアセットを特定するためのデータモデル、方法、およびガイダンスを提供する言語です。
    • Asset Reporting Format (ARF) — 収集されたセキュリティアセットおよびアセットとセキュリティレポートとの関係についての情報の送信形式を表示する言語です。
  • 列挙 — このグループには、命名形式および興味のある特定のセキュリティ関連の分野からのアイテムの公式一覧または辞書を定義する、SCAP 基準が含まれています。
    • Common Configuration Enumeration (CCE) — アプリケーションおよびオペレーティングシステム用のセキュリティ関連設定要素の列挙です。
    • Common Platform Enumeration (CPE) — 情報技術 (IT) システム、プラットホーム、およびソフトウェアパッケージの特定に使用される構造化命名スキームです。
    • Common Vulnerabilities and Exposures (CVE) — 周知のソフトウェア脆弱性および露出のコレクションへの参照方法です。
  • メトリクス — このグループは、セキュリティリスクを特定、評価するフレームワークで構成されています。
    • Common Configuration Scoring System (CCSS) — セキュリティ関連の設定要素を評価し、それらをスコアに割り当ててユーザーが適切な応答ステップの優先度を決定できるようにする、メトリクスシステムです。
    • Common Vulnerability Scoring System (CVSS) — ソフトウェアの脆弱性を評価し、それらをスコアに割り当ててユーザーがセキュリティリスクの優先度を決定できるようにするメトリクスシステムです。
  • 整合性 — SCAP コンポーネントとスキャンの結果の整合性を維持するための SCAP 仕様です。
    • Trust Model for Security Automation Data (TMSAD) — セキュリティ自動化ドメイン内の XML ファイルのコンテンツにおいて、署名、ハッシュ、鍵情報、および ID 情報を表示するための既存の仕様の使い方を説明した推奨事項です。
各 SCAP コンポーネントには、XML ベースのドキュメント形式とその XML ネームスペースがあります。SCAP で表示されているコンプライアンスポリシーは、単一の OVAL 定義 XML ファイル、データストリームファイル、単一 zip アーカイブ、またはポリシーチェックリストを表示する XCCDF ファイルを含む別個の XML ファイルセットのいずれかになります。

8.2.1. XCCDF ファイル形式

XCCDF 言語は、情報交換、ドキュメント生成、組織および状況に応じた調整、自動コンプライアンステスト、およびコンプライアンススコアリングをサポートするように設計されています。この言語は主に記述的で、セキュリティスキャンを実行するコマンドは含まれていません。しかし XCCDF ドキュメントは他の SCAP コンポーネントを参照できるため、関連する評価ドキュメント (OVAL, OCIL) を除くすべてのターゲットプラットホームのなかで移植可能なコンプライアンスポリシーの作成に使用することができます。
コンプライアンスポリシーを表示する一般的な方法は XML ファイルセットで、このうちのひとつが XCCDF チェックリストになります。この XCCDF は通常、評価リソース、複数の OVAL、OCIL および Script Check Engine (SCE) ファイルを参照しています。さらに、このファイルセットには、CPE 辞書ファイルとこの辞書用のオブジェクトを定義する OVAL ファイルを含めることができます。
XCCDF は XML ベースの言語であることから、非常に多くの XML 要素と属性を定義、使用します。以下では、主要な XCCDF 要素を簡単に説明しています。XCCDF の詳細については、NIST Interagency Report 7275 Revision 4 を参照してください。

XCCDF ドキュメントの主要 XML 要素

  • <xccdf:Benchmark> — XCCDF ドキュメント全体を囲むルート要素です。これには、タイトル、説明、作者一覧、最新の修正日、チェックリスト受け付けのステータスなどのチェックリストのメタデータが含まれる場合があります。
  • <xccdf:Rule> — チェックリスト要件を表示し、その説明を保持する重要な要素です。これには、特定のルールのコンプライアンスを確認または強制したり、ルール自体を修正するアクションを定義する、子要素が含まれる場合があります。
  • <xccdf:Value> — ベンチマーク内の他の XCCDF 要素の属性を表示するために使用される重要な要素です。
  • <xccdf:Group> — この要素は、XCCDF ドキュメントを組織化して、要件と同じコンテキストまたはタイプのグループや構造体を含みます。これは、<xccdf:Rule><xccdf:Value>、および <xccdf:Group> 要素を収集することでなされます。
  • <xccdf:Profile> — この要素は、XCCDF ベンチマークの名前付き調整に使われます。ベンチマークがいくつかの異なるテーラリングを持つことが可能になります。<xccdf:Profile> は、<xccdf:select><xccdf:refine-rule> などのいくつかのセレクター要素を使って、どの要素が実行中に修正されたり処理されたりするかを決定します。
  • <xccdf:Tailoring> — この要素では、ベンチマーク外のベンチマークプロファイルの定義が可能になります。これは、コンプライアンスポリシーの手動のテーラリングでは、妥当なものになる場合があります。
  • <xccdf:TestResult> — この要素は、ターゲットシステム上の特定のベンチマークのスキャン結果を保持する役割を果たします。各 <xccdf:TestResult> は、特定のスキャンのコンプライアンスポリシーを定義する際に使用されたプロファイルを参照するようにしてください。また、スキャンに関連するターゲットシステムについての重要情報も含めるようにしてください。
  • <xccdf:rule-result><xccdf:TestResult> の子要素で、ベンチマークからターゲットシステムに特定のルールを適用した結果を保持するために使用されます。
  • <xccdf:fix><xccdf:Rule> の子要素で、特定のルールに従っていないターゲットシステムの改善に使われます。これにターゲットシステム上で実行するコマンドまたはスクリプトを含めると、システムをルールにしたがわせることができます。
  • <xccdf:check><xccdf:Rule> の子要素で、特定ルールの評価方法を定義する外部ソースを参照します。
  • <xccdf:select> — ポリシーから特定のルールまたはルールのグループを除外もしくは含めるために使われるセレクター要素です。
  • <xccdf:set-value><xccdf:Value> 要素の属性を変更せずに、この要素で指定された現在の値の上書きに使われるセレクター要素です。
  • <xccdf:refine-value> — ポリシーテーラリング中に特定の <xccdf:Value> 要素の制限を指定するために使われるセレクター要素です。
  • <xccdf:refine-rule> — このセレクター要素は、選択されたルールの属性の上書きを可能にします。

例8.1 XCCDF ドキュメントの例


        
<?xml version="1.0" encoding="UTF-8"?>
<Benchmark xmlns="http://checklists.nist.gov/xccdf/1.2"
    id="xccdf_com.example.www_benchmark_test">
  <status>incomplete</status>
  <version>0.1</version>
  <Profile id="xccdf_com.example.www_profile_1">
    <title>Profile title is compulsory</title>
    <select idref="xccdf_com.example.www_group_1" 
        selected="true"/>
    <select idref="xccdf_com.example.www_rule_1" 
        selected="true"/>
    <refine-value idref="xccdf_com.example.www_value_1"
        selector="telnet service"/>
  </Profile>
  <Group id="xccdf_com.example.www_group_1">
    <Value id="xccdf_com.example.www_value_1">
      <value selector="telnet_service">telnet-server</value>
      <value selector="dhcp_servide">dhcpd</value>
      <value selector="ftp_service">tftpd</value>
    </Value>
    <Rule id="xccdf_com.example.www_rule_1">
      <title>The telnet-server Package Shall Not Be Installed </title>
      <rationale>
        Removing the telnet-server package decreases the risk
        of the telnet service’s accidental (or intentional) activation
      </rationale>
      <fix platform="cpe:/o:redhat:enterprise_linux:6" 
          reboot="false" 
          disruption="low" 
          system="urn:xccdf:fix:script:sh">
        yum -y remove 
        <sub idref="xccdf_com.example.www_value_1"/>
      </fix>
      <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
        <check-export value-id="xccdf_com.example.www_value_1" 
            export-name="oval:com.example.www:var:1"/>
        <check-content-ref href="examplary.oval.xml" 
            name="oval:com.example.www:def:1"/>
      </check>
      <check system="http://open-scap.org/page/SCE">
        <check-import import-name="stdout"/>
        <check-content-ref href="telnet_server.sh"/>
      </check>
    </Rule>
  </Group>
</Benchmark>        
        

8.2.2. OVAL ファイル形式

Open Vulnerability Assessment Language (OVAL) は、SCAP の必須かつ最も古いコンポーネントです。OVAL 標準の主なゴールは、セキュリティ製品の間で相互運用性を確保することです。これは、以下の 3 つのドメインの標準化でなされます。
  1. ターゲットシステム設定の表示。
  2. ターゲットシステムが特定のマシン状態にあるかを分析。
  3. 指定されたマシン状態と観察されたマシン状態の比較結果のレポーティング。
他のツールやカスタム化されたスクリプトとは異なり、OVAL 言語は宣言型でリソースの望ましい状態を記述します。OVAL 言語コードはスキャナーと呼ばれる OVAL インタープリターツールを用いて実行されますが、直接実行されることは決してありません。OVAL が宣言型であるために、評価されるシステムの状態が偶然に修正されることはありません。セキュリティスキャナーは可能な限り高い権限で実行されることが多いので、これは重要な点になります。
OVAL 仕様はコメントと貢献を公開で受け付けています。また、多くの IT 企業が米連邦政府の援助を受けた NPO である MITRE Corporation と協力しています。OVAL 仕様は継続的に発展しており、バージョン番号で改訂版を区別しています。最新バージョンは 2012 年にリリースされた 5.10.1 になります。
他のすべての SCAP コンポーネントと同様に、OVAL は XML に基づいています。OVAL 標準は、いくつかのドキュメント形式を定義します。これらはそれぞれ異なる種類の情報を含み、異なる目的に使われます。

OVAL ドキュメント形式

  • OVAL Definitions 形式は、最も一般的な OVAL ファイル形式で、システムスキャンに直接使用されます。OVAL Definitions のドキュメントは、ターゲットシステムの望ましい状態を記述します。
  • OVAL Variables 形式は、OVAL Definitions ドキュメントの修正に使用される変数を定義します。OVAL Variables ドキュメントは通常、OVAL Definitions ドキュメントと一緒に使われ、ランタイム時にターゲットシステムのセキュリティコンテンツを調整します。
  • OVAL System Characteristics 形式は、評価対象のシステムについての情報を保持します。OVAL System Characteristics ドキュメントは通常、実際のシステムの状態と、OVAL Definitions ドキュメントが定義する期待された状態を比較するために使用されます。
  • OVAL Results は、最も包括的な OVAL 形式で、システム評価の結果を報告するために使われます。OVAL Results ドキュメントには通常、評価された OVAL 定義のコピー、バインドされた OVAL 変数、OVAL システムの特徴、システムの特徴と定義の比較に基づいて計算されたテスト結果が含まれます。
  • OVAL Directives 形式は、特定の詳細を除外または含めることで、OVAL Result ドキュメントの長さを調整するために使われます。
  • OVAL Common Model 形式には、いくつかの他の OVAL スキームに使用される構造体と列挙の定義が含まれます。これは、OVAL 定義を再利用して、複数のドキュメントでの重複を防ぐために使われます。
OVAL Definitions ドキュメントは、設定要件一式で構成されます。各要件は、definitionstestsobjectsstates、および variables の 5 つの基本的なセクションで構成されます。definitions セクション内における要素は、特定の定義を満たすためにどのテストが実行されるかを記述します。test 要素は、objects と states をリンクさせます。システム評価中に、ある object 要素が示す評価システムのリリースが特定の state 要素に対応すると、テストが成功したとみなされます。variables セクションでは、states セクションからの要素の調整に使用される可能性のある外部の変数を定義します。これらのセクションに加えて、OVAL Definitions ドキュメントには通常、generator および signature の各セクションも含まれています。generator セクションには、ドキュメントの出所についての情報とそのコンテンツに関連する様々な追加情報が含まれます。
OVAL ドキュメントの基本的セクションからの各要素は、以下の形式の識別子で明確に特定されます。
oval:namespace:type:ID
ここでの namespace は、識別子を定義するネームスペースです。type は、definitions 要素の場合は def、tests 要素の場合は tst、objects 要素の場合は obj、states 要素の場合は ste、variables 要素の場合は var になります。ID は、識別子の整数値になります。

例8.2 OVAL Definitions ドキュメントの例


          
<?xml version="1.0" encoding="utf-8"?>
<oval_definitions
    xmlns:lin-def="http://oval.mitre.org/XMLSchema/oval-definitions-5#linux"
    xmlns:oval="http://oval.mitre.org/XMLSchema/oval-common-5"
    xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <generator>
    <oval:product_name>vim</oval:product_name>
    <oval:schema_version>5.10.1</oval:schema_version>
    <oval:timestamp>2012-11-22T15:00:00+01:00</oval:timestamp>
  </generator>
  <definitions>
    <definition class="inventory" 
        id="oval:org.open-scap.cpe.rhel:def:6" 
        version="1">
      <metadata>
        <title>Red Hat Enterprise Linux 6</title>
        <affected family="unix">
          <platform>Red Hat Enterprise Linux 6</platform>
        </affected>
        <reference ref_id="cpe:/o:redhat:enterprise_linux:6" 
            source="CPE"/>
        <description>
          The operating system installed on the system is Red Hat Enterprise Linux 6
        </description>
      </metadata>
      <criteria>
        <criterion comment="Red Hat Enterprise Linux 6 is installed" 
            test_ref="oval:org.open-scap.cpe.rhel:tst:6"/>
      </criteria>
    </definition>
  </definitions>
  <tests>
    <lin-def:rpminfo_test check_existence="at_least_one_exists" 
        id="oval:org.open-scap.cpe.rhel:tst:6" 
        version="1" 
        check="at least one" 
        comment="redhat-release is version 6">
      <lin-def:object object_ref="oval:org.open-scap.cpe.redhat-release:obj:1"/>
      <lin-def:state state_ref="oval:org.open-scap.cpe.rhel:ste:6"/>
    </lin-def:rpminfo_test>
  </tests>
  <objects>
    <lin-def:rpmverifyfile_object id="oval:org.open-scap.cpe.redhat-release:obj:1" 
        version="1">
      <!-- This object represents rpm package which owns /etc/redhat-release file -->
      <lin-def:behaviors nolinkto='true' 
          nomd5='true' 
          nosize='true' 
          nouser='true' 
          nogroup='true' 
          nomtime='true' 
          nomode='true' 
          nordev='true' 
          noconfigfiles='true' 
          noghostfiles='true' />
      <lin-def:name operation="pattern match"/>
      <lin-def:epoch operation="pattern match"/>
      <lin-def:version operation="pattern match"/>
      <lin-def:release operation="pattern match"/>
      <lin-def:arch operation="pattern match"/>
      <lin-def:filepath>/etc/redhat-release</lin-def:filepath>
    </lin-def:rpmverifyfile_object>
  </objects>
  <states>
    <lin-def:rpminfo_state id="oval:org.open-scap.cpe.rhel:ste:6" 
        version="1">
      <lin-def:name operation="pattern match">^redhat-release</lin-def:name>
      <lin-def:version operation="pattern match">^6[^\d]</lin-def:version>
    </lin-def:rpminfo_state>
  </states>
</oval_definitions>
          

8.2.3. データストリームの形式

SCAP データストリームは、SCAP バージョン 1.2 から使用されているファイル形式で、XCCDF や OVAL、その他のコンポーネントファイルなど、XCCDF チェックリストで表示されているコンプライアンスポリシーの定義に使用可能なもののバンドルを表します。また、特定のデータストリームを SCAP コンポーネントにしたがってファイルに分割することを可能にするインデックスとカタログも含まれています
データストリームは XML 形式を使用し、これはコンテンツのテーブルで形成されたヘッダーと <ds:component> 要素の一覧で構成されています。これらの要素にはそれぞれ、XCCDF や OVAL、CPE などの SCAP コンポーネントが含まれます。データストリームファイルには同じタイプの複数のコンポーネントが含まれている場合があり、組織で必要とされるセキュリティポリシーすべてがカバーされます。

例8.3 データストリームヘッダーの例


        
<ds:data-stream-collection xmlns:ds="http://scap.nist.gov/schema/scap/source/1.2" 
    xmlns:xlink="http://www.w3.org/1999/xlink" 
    xmlns:cat="urn:oasis:names:tc:entity:xmlns:xml:catalog" 
    id="scap_org.open-scap_collection_from_xccdf_ssg-rhel6-xccdf-1.2.xml"
    schematron-version="1.0">
  <ds:data-stream id="scap_org.open-scap_datastream_from_xccdf_ssg-rhel6-xccdf-1.2.xml" 
      scap-version="1.2" use-case="OTHER">
  <ds:dictionaries>
    <ds:component-ref id="scap_org.open-scap_cref_output--ssg-rhel6-cpe-dictionary.xml" 
        xlink:href="#scap_org.open-scap_comp_output--ssg-rhel6-cpe-dictionary.xml">
      <cat:catalog>
        <cat:uri name="ssg-rhel6-cpe-oval.xml" 
            uri="#scap_org.open-scap_cref_output--ssg-rhel6-cpe-oval.xml"/>
      </cat:catalog>
    </ds:component-ref>
  </ds:dictionaries>
  <ds:checklists>
    <ds:component-ref id="scap_org.open-scap_cref_ssg-rhel6-xccdf-1.2.xml" 
        xlink:href="#scap_org.open-scap_comp_ssg-rhel6-xccdf-1.2.xml">
      <cat:catalog>
        <cat:uri name="ssg-rhel6-oval.xml" 
            uri="#scap_org.open-scap_cref_ssg-rhel6-oval.xml"/>
      </cat:catalog>
    </ds:component-ref>
  </ds:checklists>
  <ds:checks>
    <ds:component-ref id="scap_org.open-scap_cref_ssg-rhel6-oval.xml" 
        xlink:href="#scap_org.open-scap_comp_ssg-rhel6-oval.xml"/>
    <ds:component-ref id="scap_org.open-scap_cref_output--ssg-rhel6-cpe-oval.xml" 
        xlink:href="#scap_org.open-scap_comp_output--ssg-rhel6-cpe-oval.xml"/>
    <ds:component-ref id="scap_org.open-scap_cref_output--ssg-rhel6-oval.xml" 
        xlink:href="#scap_org.open-scap_comp_output--ssg-rhel6-oval.xml"/>
  </ds:checks>
</ds:data-stream>
<ds:component id="scap_org.open-scap_comp_ssg-rhel6-oval.xml"
    timestamp="2014-03-14T16:21:59">
  <oval_definitions xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5" 
      xmlns:oval="http://oval.mitre.org/XMLSchema/oval-common-5" 
      xmlns:ind="http://oval.mitre.org/XMLSchema/oval-definitions-5#independent" 
      xmlns:unix="http://oval.mitre.org/XMLSchema/oval-definitions-5#unix" 
      xmlns:linux="http://oval.mitre.org/XMLSchema/oval-definitions-5#linux" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
      xsi:schemaLocation="http://oval.mitre.org/XMLSchema/oval-common-5 
      oval-common-schema.xsd 
          http://oval.mitre.org/XMLSchema/oval-definitions-5 
      oval-definitions-schema.xsd
          http://oval.mitre.org/XMLSchema/oval-definitions-5#independent 
      independent-definitions-schema.xsd
          http://oval.mitre.org/XMLSchema/oval-definitions-5#unix 
      unix-definitions-schema.xsd
          http://oval.mitre.org/XMLSchema/oval-definitions-5#linux 
      linux-definitions-schema.xsd">
        

8.3. oscap の使用

oscap コマンドラインユーティリティーを使うと、ローカルシステムのスキャン、セキュリティコンプライアンスコンテンツの確認、これらのスキャンおよび評価を基にしたレポートとガイドの生成ができます。このユーティリティーは OpenSCAP ライブラリーへのフロントエンドとしてのサービスを提供し、その機能を処理する SCAP コンテンツのタイプに基づいてモジュール (サブコマンド) にグループ化します。
以下のセクションでは oscap のインストール方法、最も一般的な操作の実行方法、これらのタスクの関連する例の表示方法を説明します。特定のサブコマンドの詳細を確認するには、oscap コマンドの --help オプションを使用してください。
oscap [options] module module_operation [module_operation_options_and_arguments] --help
ここでの module は、処理されている SCAP コンテンツのタイプになります。また、module_operation は、SCAP コンテンツにおける特定の操作のサブコマンドになります。

例8.4 特定の oscap 操作に関するヘルプ

~]$ oscap ds sds-split --help
oscap -> ds -> sds-split

Split given SourceDataStream into separate files

Usage: oscap [options] ds sds-split [options] SDS TARGET_DIRECTORY

SDS - Source data stream that will be split into multiple files.
TARGET_DIRECTORY - Directory of the resulting files.

Options:
   --datastream-id <id>          - ID of the datastream in the collection to use.
   --xccdf-id <id>               - ID of XCCDF in the datastream that should be evaluated.
oscap の全機能を学習し、オプションの完全一覧を確認するには、oscap(8) man ページを参照してください。

8.3.1. oscap のインストール

システムに oscap をインストールするには、root で以下のコマンドを実行します。
~]# yum install openscap-utils
このコマンドにより、ユーティリティー自体を提供する openscap パッケージを含む、oscap が正常に機能するために必要な全パッケージがインストールされます。
独自のセキュリティコンテンツを書き込みたい場合は、Script Check Engine (SCE) を提供する openscap-engine-sce パッケージをインストールします。SCE は SCAP プロトコルの拡張機能で、コンテンツ作者は Bash、Python、Ruby などのスクリプト言語を使って独自のセキュリティコンテンツを記述することができます。openscap-engine-sce パッケージは openscap-utils パッケージと同じ方法でインストールできますが、Red Hat Enterprise Linux 用のオプションパッケージがあるリポジトリーまたはチャンネルにアクセスする必要があります。Red Hat Subscription Management にシステムが登録されている場合は、Red Hat Enterprise Linux 6 導入ガイドの Yum の章で説明してある rhel-6-variant-optional-rpms リポジトリーを有効にします。ここでの variant は、serverworkstation などの Red Hat Enterprise Linux のバリアントになります。システムが RHN Classic に登録されている場合は、https://access.redhat.com/site/solutions/9907 の説明にあるようにシステムを rhel-architecture-variant-6-optional チャンネルにサブスクライブさせます。
オプションとして、oscap のインストール後に使用する oscap のバージョンの機能やこのバージョンがサポートする仕様、特定の oscap ファイルの保存場所、使用可能な SCAP オブジェクトの種類、他の役立つ情報をチェックできます。これらの情報を表示するには、以下のコマンドを実行します。
~]$ oscap -V
OpenSCAP command line tool (oscap) 1.0.8
Copyright 2009--2014 Red Hat Inc., Durham, North Carolina.

==== Supported specifications ====
XCCDF Version: 1.2
OVAL Version: 5.10.1
CPE Version: 2.3
CVSS Version: 2.0
CVE Version: 2.0
Asset Identification Version: 1.1
Asset Reporting Format Version: 1.1

==== Capabilities added by auto-loaded plugins ====
SCE Version: 1.0 (from libopenscap_sce.so.8)

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

==== Inbuilt CPE names ====
Red Hat Enterprise Linux - cpe:/o:redhat:enterprise_linux
Red Hat Enterprise Linux 5 - cpe:/o:redhat:enterprise_linux:5
Red Hat Enterprise Linux 6 - cpe:/o:redhat:enterprise_linux:6
Red Hat Enterprise Linux 7 - cpe:/o:redhat:enterprise_linux:7
Fedora 16 - cpe:/o:fedoraproject:fedora:16
Fedora 17 - cpe:/o:fedoraproject:fedora:17
Fedora 18 - cpe:/o:fedoraproject:fedora:18
Fedora 19 - cpe:/o:fedoraproject:fedora:19
Fedora 20 - cpe:/o:fedoraproject:fedora:20
Fedora 21 - cpe:/o:fedoraproject:fedora:21
Red Hat Enterprise Linux Optional Productivity Applications - cpe:/a:redhat:rhel_productivity
Red Hat Enterprise Linux Optional Productivity Applications 5 - cpe:/a:redhat:rhel_productivity:5

==== Supported OVAL objects and associated OpenSCAP probes ====
system_info                  probe_system_info           
family                       probe_family                
filehash                     probe_filehash              
environmentvariable          probe_environmentvariable   
textfilecontent54            probe_textfilecontent54     
textfilecontent              probe_textfilecontent       
variable                     probe_variable              
xmlfilecontent               probe_xmlfilecontent        
environmentvariable58        probe_environmentvariable58 
filehash58                   probe_filehash58            
inetlisteningservers         probe_inetlisteningservers  
rpminfo                      probe_rpminfo               
partition                    probe_partition             
iflisteners                  probe_iflisteners           
rpmverify                    probe_rpmverify             
rpmverifyfile                probe_rpmverifyfile         
rpmverifypackage             probe_rpmverifypackage      
selinuxboolean               probe_selinuxboolean        
selinuxsecuritycontext       probe_selinuxsecuritycontext
file                         probe_file                  
interface                    probe_interface             
password                     probe_password              
process                      probe_process               
runlevel                     probe_runlevel              
shadow                       probe_shadow                
uname                        probe_uname                 
xinetd                       probe_xinetd                
sysctl                       probe_sysctl                
process58                    probe_process58             
fileextendedattribute        probe_fileextendedattribute 
routingtable                 probe_routingtable
oscap ユーティリティーを効果的に使い始める前に、システムにいくつかのセキュリティコンテンツをインストールもしくはインポートする必要があります。SCAP コンテンツはそれぞれのウェブサイトからダウンロードするか、RPM ファイルもしくはパッケージとして指定されている場合は、Yum パッケージマネジャーを使って指定された場所もしくは既知のリポジトリーからインストールすることができます。
たとえば、Linux システム用の最新のセキュリティポリシー一式を含む SCAP Security Guide (SSG) パッケージをインストールするには、以下のコマンドを実行します。
~]# yum install scap-security-guide
システムに scap-security-guide パッケージをインストールした後は、特に指定されていなければ、SSG セキュリティコンテンツは /usr/share/xml/scap/ssg/content/ ディレクトリーにあり、他のセキュリティコンプライアンス作業に進むことができます。
個別のニーズに合致する可能性のある既存の SCAP コンテンツの他のソースが必要な場合は、「その他のリソース」 を参照してください。
システムに SCAP コンテンツをインストールした後は、コンテンツへのパスを指定することで oscap はコンテンツを処理できます。oscap ユーティリティーは SCAP バージョン 1.2 をサポートしており、SCAP バージョン 1.1 および 1.0 とも後方互換性があるので、特別な要件を必要とせずに以前のバージョンの SCAP コンテンツを処理できます。

8.3.2. SCAP コンテンツの表示

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

例8.5 SCAP コンテンツについて情報を表示する

~]$ oscap info /usr/share/xml/scap/ssg/content/ssg-rhel6-ds.xml
Document type: Source Data Stream
Imported: 2014-08-28T15:41:34

Stream: scap_org.open-scap_datastream_from_xccdf_ssg-rhel6-xccdf-1.2.xml
Generated: (null)
Version: 1.2
Checklists:
        Ref-Id: scap_org.open-scap_cref_ssg-rhel6-xccdf-1.2.xml
                Profiles:
                        xccdf_org.ssgproject.content_profile_test
                        xccdf_org.ssgproject.content_profile_CS2
                        xccdf_org.ssgproject.content_profile_common
                        xccdf_org.ssgproject.content_profile_server
                        xccdf_org.ssgproject.content_profile_stig-rhel6-server-upstream
                        xccdf_org.ssgproject.content_profile_usgcb-rhel6-server
                        xccdf_org.ssgproject.content_profile_rht-ccp
                        xccdf_org.ssgproject.content_profile_CSCF-RHEL6-MLS
                        xccdf_org.ssgproject.content_profile_C2S
                Referenced check files:
                        ssg-rhel6-oval.xml
                                system: http://oval.mitre.org/XMLSchema/oval-definitions-5
Checks:
        Ref-Id: scap_org.open-scap_cref_ssg-rhel6-oval.xml
        Ref-Id: scap_org.open-scap_cref_output--ssg-rhel6-cpe-oval.xml
        Ref-Id: scap_org.open-scap_cref_output--ssg-rhel6-oval.xml
Dictionaries:
        Ref-Id: scap_org.open-scap_cref_output--ssg-rhel6-cpe-dictionary.xml

8.3.3. システムのスキャン

oscap の最も重要な機能は、ローカルシステムの設定および脆弱性スキャンを実行することです。以下はコマンドの一般的な構文になります。
oscap [options] module eval [module_operation_options_and_arguments]
oscap ユーティリティーでは、XCCDF (eXtensible Configuration Checklist Description Format) ベンチマークと OVAL (Open Vulnerability and Assessment Language) 定義の両方で表示される SCAP コンテンツに対してシステムのスキャンを行うことができます。セキュリティポリシーは単一の OVAL または XCCDF ファイルの場合もあれば、複数の別個の XML ファイルの場合もあります。後者の場合は、各ファイルが異なるコンポーネントを表します (XCCDF、OVAL、CPE、CVE、その他)。スキャン結果は、標準出力と XML ファイルの両方にプリントすることができます。この結果のファイルは oscap でさらに処理され、ヒューマンリーダブル形式のレポートを生成することができます。以下は、このコマンドの最も一般的な使用例になります。

例8.6 SSG OVAL 定義を使用したシステムのスキャン

すべての定義を評価しながら SSG OVAL 定義ファイルに対してシステムのスキャンを実行するには、以下のコマンドを実行します。
~]$ oscap oval eval --results scan-oval-results.xml /usr/share/xml/scap/ssg/content/ssg-rhel6-ds.xml
スキャン結果は、scan-oval-results.xml ファイルとして現行ディレクトリーに保存されます。

例8.7 SSG OVAL 定義を使用したシステムのスキャン

SSG データストリームファイルで表されるセキュリティポリシーから特定の OVAL 定義を評価するには、以下のコマンドを実行します。
~]$ oscap oval eval --id oval:ssg:def:100 --results scan-oval-results.xml /usr/share/xml/scap/ssg/content/ssg-rhel6-ds.xml
スキャン結果は、scan-oval-results.xml ファイルとして現行ディレクトリーに保存されます。

例8.8 SSG XCCDF ベンチマークを使用したシステムのスキャン

システム上の xccdf_org.ssgproject.content_profile_rht-ccp プロファイルの SSG XCCDF ベンチマークを実行するには、以下のコマンドを実行します。
~]$ oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_rht-ccp --results scan-xccdf-results.xml scan-xccdf-results.xml /usr/share/xml/scap/ssg/content/ssg-rhel6-ds.xml
スキャン結果は、scan-xccdf-results.xml ファイルとして現行ディレクトリーに保存されます。

注記

--profile コマンドラインの引数は、特定の XCCDF またはデータストリームファイルからセキュリティプロファイルを選択します。利用可能なプロファイルの一覧は、oscap info コマンドを実行すると確認できます。--profile コマンドライン引数が省略されると、SCAP 標準で必要とされるデフォルトの XCCDF プロファイルが使用されます。デフォルトの XCCDF プロファイルは適切なセキュリティポリシーである場合もありますが、そうでない場合もあることに注意してください。

8.3.4. レポートおよびガイドの生成

oscap のもうひとつの便利な機能は、ヒューマンリーダブルな形式で SCAP コンテンツを生成することです。oscap ユーティリティーを使うと、XML ファイルを HTML またはプレーンテキスト形式に変換できます。この機能は、セキュリティガイドやチェックリストの生成に使用できます。これらは、セキュアなシステム設定のガイドになるとともに、情報ソースの役割も果たします。システムスキャンの結果も、読みやすい結果レポートに変換することができます。一般的なコマンド構文は以下のようになります。
oscap module generate sub-module [specific_module/sub-module_options_and_arguments] file
ここでの modulexccdf または oval に、sub-module は生成されたドキュメントのタイプに、file は XCCDF または OVAL ファイルになります。
以下でこのコマンドの最も一般的な使用例を示します。

例8.9 チェックリスト付きガイドの生成

チェックリスト付きの SSG ガイドを xccdf_org.ssgproject.content_profile_rht-ccp プロファイル用に作成するには、以下のコマンドを実行します。
~]$ oscap xccdf generate guide --profile xccdf_org.ssgproject.content_profile_rht-ccp /usr/share/xml/scap/ssg/content/ssg-rhel6-ds.xml > ssg-guide-checklist.html
ガイドは、ssg-guide-checklist.html ファイルとして現行ディレクトリーに保存されます。

例8.10 SSG OVAL スキャン結果をレポートに変換する

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

例8.11 SSG XCCDF スキャン結果をレポートに変換する

SSG XCCDF スキャンの結果を HTML ファイルに変換するには、以下のコマンドを実行します。
~]$ oscap xccdf generate report scan-xccdf-results.xml > scan-xccdf-report.html
結果レポートは ssg-scan-xccdf-report.html ファイルとして現行ディレクトリーに保存されます。別の方法では、--report コマンドライン引数を使用すると、スキャン時にこのレポートが生成できます。
~]$ oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_rht-ccp --resultsscan-xccdf-results.xml --report scan-xccdf-report.html /usr/share/xml/scap/ssg/content/ssg-rhel6-ds.xml

8.3.5. SCAP コンテンツの検証

システム上でセキュリティポリシーを使い始める前に、ポリシーを検証してポリシー内の構文エラーやセマンティックエラーを避けるようにしてください。oscap ユーティリティーを使うと、SCAP XML スキーマに対してセキュリティコンテンツを検証することができます。検証結果は、標準エラーストリーム (stderr) にプリントされます。このような検証コマンドの一般的な構文は以下のようになります。
oscap module validate [module_options_and_arguments] file
ここでの file は、検証されているファイルへの完全パスになります。唯一の例外はデータストリームモジュール (ds) で、これは validate ではなく sds-validate 演算を使用します。以下の例で示されているように、特定のデータストリーム内の SCAP コンポーネントは自動的に検証され、各コンポーネントは別個に指定されないことに注意してください。
~]$ oscap ds sds-validate /usr/share/xml/scap/ssg/content/ssg-rhel6-ds.xml
OVAL 仕様のような特定の SCAP コンテンツの場合、スキマトロン検証も実行できます。スキマトロン検証は標準の検証よりも遅いものの、より深い分析を提供するのでより多くのエラーを検出できます。以下の SSG 例では、このコマンドの通常の使用方法を示しています。
~]$ oscap oval validate --schematron /usr/share/xml/scap/ssg/content/ssg-rhel6-ds.xml

8.4. Red Hat Satellite での OpenSCAP の使用

複数の Red Hat Enterprise Linux システムを稼働している際には、すべてのシステムがセキュリティポリシーにしたがっており、リモートの 1 カ所からスキャンと評価を実行することが重要になります。これは、Satellite クライアントに spacewalk-oscap パッケージがインストールされている Red Hat Satellite 5.5 以降を使用することで達成できます。このパッケージは、Red Hat Network Tools チャンネルから入手できます。
このソリューションは、2 つの方法でのセキュリティコンプライアンススキャンの実行、表示、およびスキャン結果のさらなる処理をサポートしています。OpenSCAP Satellite Web Interface を使うか Satellite API からコマンドとスクリプトを実行することができます。このソリューションのセキュリティコンプライアンス、要件、機能に関する詳細情報は、Red Hat Satellite 5.6 ユーザーガイド を参照してください。

8.5. 実用的な使用例

本セクションでは、Red Hat 製品用に提供されている特定のセキュリティコンテンツの実用的な使用例を紹介します。

8.5.1. Red Hat 製品のセキュリティ脆弱性の監査

Red Hat は自社製品用に継続的に OVAL 定義を提供しています。これらの定義により、インストール済みソフトウェアにおける脆弱性の完全自動化された監査が可能になります。このプロジェクトに関する詳細情報は、http://www.redhat.com/security/data/metrics/ を参照してください。これらの定義をダウンロードするには、以下のコマンドを実行します。
~]$ wget http://www.redhat.com/security/data/oval/com.redhat.rhsa-all.xml
Red Hat Satellite 5 のユーザーには、パッチ定義の XCCDF の部分が便利かもしれません。これらの定義をダウンロードするには、以下のコマンドを実行します。
~]$ wget http://www.redhat.com/security/data/metrics/com.redhat.rhsa-all.xccdf.xml
システムにインストール済みのソフトウェアに関するセキュリティ脆弱性を監査するには、以下のコマンドを実行します。
~]$ oscap oval eval --results rhsa-results-oval.xml --report oval-report.html com.redhat.rhsa-all.xml
oscap ユーティリティーは、National Vulnerability Database にリンクしている CVE に Red Hat Security Advisories をマッピングします。そして、どのセキュリティアドバイザリーが適用されていないかを報告します。

注記

これらの OVAL 定義は、Red Hat がリリースしているソフトウェアや更新のみをカバーしていることに注意してください。サードパーティーのソフトウェアのパッチステータスを検出するには、追加の定義を提供する必要があります。

8.5.2. SCAP セキュリティガイドを使ったシステム設定の監査

SCAP Security Guide (SSG) プロジェクトのパッケージである scap-security-guide には、Linux システム用の最新のセキュリティポリシー一式が含まれています。scap-security-guide の一部は、Red Hat Enterprise Linux 6 設定のガイドにもなっています。scap-security-guide で利用可能なセキュリティコンテンツを確認するには、oscap info モジュールを使用します。
~]$ oscap info /usr/share/xml/scap/ssg/content/ssg-rhel6-ds.xml
このコマンドの出力は SSG ドキュメントの概要で、利用可能な設定プロファイルが含まれています。ご使用のシステム設定を監査するには、適切なプロファイルを選択して適切な評価コマンドを実行します。たとえば、以下のコマンドは、Red Hat Certified Cloud Providers 用のドラフト SCAP プロファイルに対し特定のシステムを評価するために使われます。
~]$ oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_rht-ccp --results ssg-rhel6-xccdf-result.xml --report ssg-rhel6-report.html /usr/share/xml/scap/ssg/content/ssg-rhel6-ds.xml

8.6. その他のリソース

関心のある様々なセキュリティコンプライアンスの分野に関する詳細情報は、以下のリソースを参照してください。

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

  • oscap(8) — oscap コマンドラインユーティリティーの man ページでは、利用可能なオプション全一覧とその使用方法が説明されています。
  • Guide to the Secure Configuration of Red Hat Enterprise Linux 6 — /usr/share/doc/scap-security-guide-0.1.18/ ディレクトリーにある HTML ドキュメントです。XCCDF チェックリストという形式でシステムのセキュリティ設定の詳細なガイドを提供しています。

オンラインのドキュメント

  • The OpenSCAP project page — OpenSCAP プロジェクトのホームページでは、oscap ユーティリティーと SCAP に関連する他のコンポーネントおよびプロジェクトの詳細情報が提供されています。
  • The SCAP Workbench project page — SCAP Workbench プロジェクトのホームページでは、scap-workbench アプリケーションの詳細情報が提供されています。
  • The SCAP Security Guide (SSG) project page — SSG プロジェクトのホームページでは、Red Hat Enterprise Linux 向けの最新セキュリティコンテンツが提供されています。
  • National Institute of Standards and Technology (NIST) SCAP page — このページには SCAP 関連の大量の資料があります。SCAP の出版物や仕様、SCAP 検出プログラムもあります。
  • National Vulnerability Database (NVD) — このページは、SCAP コンテンツおよび他の SCAP 標準ベースの脆弱性管理データの最大のリポジトリーです。
  • Red Hat OVAL content repository — Red Hat Enterprise Linux システム向けの OVAL 定義を含むリポジトリーです。
  • MITRE CVE — これは、MITRE corporationが提供する既知のセキュリティ脆弱性に関するデータベースです。
  • MITRE OVAL — このページは、MITRE corporation が提供する OVAL 関連のプロジェクトを紹介しています。OVAL 関連の他の情報に加え、OVAL 言語の最新バージョンや 2 万 2 千を越える OVAL 定義を数える巨大な OVAL コンテンツのリポジトリーがあります。
  • Red Hat Satellite 5.6 ユーザーガイド — 本書では、OpenSCAP を使って複数のシステム上でシステムセキュリティを維持する方法が説明されています。

第9章 米連邦政府の標準および規制

9.1. はじめに

どの組織も、米連邦政府または業界のセキュリティ仕様、標準および規制の遵守に取り組むことで一定のセキュリティレベルを維持することができます。本章では、これらの標準および規制のいくつかについて説明します。

9.2. 連邦情報処理標準 (FIPS: Federal Information Processing Standard)

連邦情報処理標準 (FIPS) のパブリケーションである 140-2 は、暗号モジュールの品質を検証するために連邦政府と業界の作業部会によって開発されたコンピューターセキュリティ標準です。FIPS のパブリケーション (140-2 を含む) は以下の URL にあります。http://csrc.nist.gov/publications/PubsFIPS.html。本書の作成時点で 140-3 のパブリケーションは草稿状態にあるため、これが完成版の標準として使用できない可能性があることに注意してください。FIPS 標準は、さまざまな業界や暗号モジュールの各種の実装およびさまざな組織規模や要件に対応すべく、4 つのセキュリティレベルを規定しています。これらのレベルについては、以下で説明します。
  • レベル 1 – セキュリティレベル 1 はセキュリティの最も低いレベルです。暗号モジュールについての基本的なセキュリティ要件が規定されます (例: 1 つ以上の承認済みのアルゴリズムか、承認済みのセキュリティ機能を使用するものとする)。セキュリティレベル 1 の暗号モジュールでは、本番稼働レベルのコンポーネントの基本要件を超える具体的な物理セキュリティのメカニズムは必要とされません。セキュリティレベル 1 の暗号モジュールの例には、パソコン (PC) 用の暗号化ボードがあります。
  • レベル 2 – セキュリティレベル 2 は、セキュリティレベル 1 の暗号モジュールについての物理セキュリティのメカニズムを強化します。レベル 2 では、耐タンパー性のあるコーティングまたはシールを使用することや、モジュールの除去可能なカバーやドアにこじあけ耐性のある錠をかけることをはじめとする物理的改ざんの痕跡を残すという要件が加わります。耐タンパー性のあるコーティングやシールは暗号モジュールに付けられ、コーティングやシールを破らない限り、モジュール内のテキスト形式の暗号鍵とクリティカルセキュリティパラメーター (CSP) に物理的にアクセスできないようにします。耐テンパー性のあるシールまたはこじあけ耐性のある錠をカバーまたはドアに取り付けて、許可されない物理的なアクセスからモジュールを保護します。
  • レベル 3 – セキュリティレベル 2 で要求される改ざん跡を残す物理セキュリティのメカニズムに加えて、セキュリティレベル 3 は、暗号モジュール内で保持される CSP に侵入者がアクセスすることを防ぐことを目的とします。セキュリティレベル 3 で要求される物理セキュリティのメカニズムは、物理的なアクセスの試行や暗号モジュールの使用または変更を高い確率で検出し、これらに対応することを意図しています。この物理セキュリティのメカニズムには、頑丈な囲い (enclosure) の使用、および暗号モジュールの除去可能なカバー/ドアが開かれたときにテキスト形式の CSP をすべてゼロ化するタンパー検出/タンパー応答を持つ回路の使用が含まれることがあります。
  • レベル 4 – セキュリティレベル 4 は、この標準で定義される最も高いセキュリティレベルです。このセキュリティレベルでは、すべての許可されていない物理的なアクセスを検出し、これに応答することを目的として、物理セキュリティのメカニズムが暗号モジュール全体に保護用の遮蔽 (envelope) を提供します。 あらゆる方向からの暗号モジュールの囲いへの侵入が非常に高い確率で検出され、その結果、テキスト形式のすべての CSP が即座にゼロ化されます。セキュリティレベル 4 の暗号モジュールは、物理的に保護されていない環境下での使用に役立ちます。
FIPS 標準の上記の各レベルや他の仕様についての詳細は、FIPS 140-2 標準の全体 (http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf を参照してください。

9.2.1. FIPS モードの有効化

Red Hat Enterprise Linux 6 を連邦情報処理標準 (FIPS) パブリケーション 140-2 準拠とするには、いくつかの変更を加えて認定済み暗号モジュールを使用することが必要です。お使いのシステム (カーネルおよびユーザースペース) を FIPS モードに切り替えるには、以下のステップを実行します。
  1. モジュール内の整合性検証の適切な実行にあたり、prelink を無効にする必要があります。/etc/sysconfig/prelink 設定ファイルで PRELINKING=no を設定してください。既存の事前リンク (prelinking) がある場合は、 prelink -u -a コマンドを使用してすべてのシステムファイル上でこれを元に戻す必要があります。
  2. 次に、dracut-fips パッケージをインストールします。
    ~]# yum install dracut-fips

    注記

    FIPS 整合性の検証は、システムが FIPS モードで稼働中かどうかにかかわらず、dracut-fips パッケージがシステム上にあれば実行されます。ただし、dracut-fips パッケージがあったとしても、システムもしくは共有ライブラリーが FIPS モードでなければ、整合性の検証結果は無視 (またはログ記録されるだけ) されます。
  3. initramfs ファイルを再作成します。
    ~]# dracut -f

    警告

    この操作により、既存の initramfs ファイルが上書きされます。
  4. 以下のオプションを追加して、/boot/grub/grub.conf ファイルにある現在のカーネルのカーネルコマンドラインを変更します。
    fips=1

    注記

    /boot または /boot/efi が別のパーティションにある場合、カーネルパラメーターの boot=</boot または /boot/efi のパーティション> のカーネルパラメーター をカーネルコマンドラインに追加する必要があります。パーティションは、それぞれ df /boot または df /boot/efi コマンドでそれぞれ識別されます。以下は例になります。
    ~]$ df /boot
    Filesystem           1K-blocks      Used Available Use% Mounted on
    /dev/sda1               495844     53780    416464  12% /boot
    上記の例では、/boot パーティションは /dev/sda1 にあります。従って、以下の文字列をカーネルコマンドラインに追加する必要があります。
    boot=/dev/sda1
  5. システムを再起動します。

注記

暗号とメッセージ認証コード (MACs) は、デフォルトで /etc/ssh/sshd_config ファイル内で FIPS モードに設定されています。sshd_config に他の暗号と MACs が含まれている場合は、FIPS モードでサポートされているアルゴリズムのみを使用するように修正します。以下がその例になります。
Protocol 2
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
Macs hmac-sha1,hmac-sha2-256,hmac-sha2-512
FIPS へのより厳格なコンプライアンスが求められる場合は、システムのインストール時に fips=1 カーネルオプションをカーネルコマンドラインに追加する必要があります。これにより、FIPS で承認されているアルゴリズムを使って鍵を生成し、継続的なモニタリングテストを実施することができます。また、ユーザーは、インストールプロセス時にマウスを動かすか、またはマウスを使用できない場合は多数のキー入力を行うことにより、システムに十分なエントロピーを確保する必要があります。推奨されるキー入力の回数は 256 回以上です。 255 回以下の場合は、一意でない鍵が生成される可能性があります。

警告

Red Hat Enterprise Linux 上で FIPS モードを有効にする上記の手順は、Network Security Services (NSS) の FIPS 状態に影響を及ぼさないので、NSS を使用するアプリケーションにも影響がありません。必要な場合は、以下のコマンドを使って NSS アプリケーションを FIPS モードに切り替えることができます。
~]# modutil -fips true -dbdir dir
ここでの dir は、アプリケーションに使用する NSS データベースを指定するディレクトリーです。複数の NSS アプリケーションがこのデータベースを使用している場合は、これらアプリケーションのすべてが FIPS モードに切り替えられます。NSS FIPS モードを有効にするには、アプリケーションを再起動する必要があります。

9.3. NISPOM (National Industrial Security Program Operating Manual)

National Industrial Security Program (NISP) の 構成要素の 1 つである NISPOM (DoD 5220.22-M とも呼ばれる) は、すべての政府指定業者向けに、秘密情報 (classified information) に関する一連の手順と要件を規定しています。現行の NISPOM は、2006 年 2 月 28 日付けのもので、2013 年 3 月 28 日からのメジャーな変更が組み込まれています。NISPOM 文書は以下の URL からダウンロードできます。http://www.nispom.org/NISPOM-download.html

9.4. PCI DSS (Payment Card Industry Data Security Standard)

(ソース: https://www.pcisecuritystandards.org/about/index.shtml) PCI Security Standards Council は、2006 年に発足したグローバル規模の開かれた協議会であり、データセキュリティスタンダード (DSS: Data Security Standard) を含む PCI セキュリティ基準の開発、管理、教育および普及に関する討議の場を提供しています。
PCI DSS 標準は、https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml からダウンロードできます。

9.5. セキュリティ技術導入ガイド (Security Technical Implementation Guide)

セキュリティ技術導入ガイド (STIG: Security Technical Implementation Guide) は、ソフトウェアとハードウェアの標準化された安全なインストールと保守についての方法論です。
STIG についての詳細は、以下の URL を参照してください。http://iase.disa.mil/stigs/index.html

第10章 参考資料

以下に挙げるものは、本ガイドのスコープ外である SELinux および Red Hat Enterprise Linux 関連の追加情報の参照先です。SELinux は急速に開発されているため、記述の一部は Red Hat Enterprise Linux の特定リリースにのみ適用されることに注意してください。

書籍

SELinux by Example
Mayer, MacMillan, and Caplan
Prentice Hall, 2007

チュートリアルとヘルプ

Tutorials and talks from Russell Coker
Generic Writing SELinux policy HOWTO
Red Hat ナレッジベース

一般的な情報

NSA SELinux メイン Web サイト
NSA SELinux FAQ
SELinux NSA's Open Source Security Enhanced Linux (日本語訳: SELinux システム管理-セキュア OS の基礎と運用)

技術

An Overview of Object Classes and Permissions
Integrating Flexible Support for Security Policies into the Linux Operating System (a history of Flask implementation in Linux)
Implementing SELinux as a Linux Security Module
A Security Policy Configuration for the Security-Enhanced Linux

コミュニティー

SELinux コミュニティページ
IRC
irc.freenode.net, #selinux, #fedora-selinux, #security

暗号の標準

A.1. 同期式の暗号

A.1.1. 高度暗号化標準 (AES)

高度暗号化標準 (AES: Advanced Encryption Standard) は米国政府によって採用された暗号化標準です。この標準は、元は Rijndael として公開された大規模なコレクションの中から採用された、3 つのブロック暗号 AES-128、AES-192 および AES-256 から構成されています。それぞれの AES 暗号は、キーのサイズがそれぞれ 128、192 および 256 ビット の 128 ビットのブロックサイズを持ちます。AES 暗号の分析は詳細に行われており、現在ではその前身であるデータ暗号化標準 (DES: Data Encryption Standard) と同様に世界中で使用されています。[5]

A.1.1.1. AES の歴史

AES は、標準化プロセス開始から 5 年後の 2001年11月26日に、U.S. FIPS PUB 197 (FIPS 197) として National Institute of Standards and Technology (NIST) により発表されました。この 5 年間に 15 の競合するデザインが提出され、それぞれの評価が行われた結果、Rijndael が最適な標準として選択されました。これは多くの異なる暗号化パッケージで利用できます。AES は、最高機密情報に関して NSA が初めて認定した、一般にアクセス可能でオープンな暗号です。
Rijndael は 2 人のベルギー人の暗号学者 Joan Daemon と Vincent Rijmen により開発され、彼らにより AES の選定プロセスに提出されました。Rijndael はこれら 2 人の発明家の名前の混成語です。[6]

A.1.2. データ暗号化標準 (DES)

データ暗号化標準 (DES: Data Encryption Standard) は、1976 年に National Bureau of Standards によって米国の公式な連邦情報処理標準 (FIPS: Federal Information Processing Standard) として選択されたブロック暗号 (共有秘密暗号の形式の1つ) であり、その後国際的に広く利用されるようになりました。この暗号は 56 ビットキーを使用した対称鍵アルゴリズムに基づいています。このアルゴリズムは当初、秘密の設計要素、比較的に短い鍵の長さ、および National Security Agency (NSA) のバックドアに関する疑惑とともに議論の的になりました。その後、DES は徹底的な学術的検証を受け、現代のブロック暗号とその暗号解析の理解の進展に貢献しています。[7]

A.1.2.1. DES の歴史

現在、DES のセキュリティは多くのアプリケーションに対して不十分であると考えられています。この主な原因は、56 ビットキーが小さすぎることにあります。1999年1月に、distributed.net と Electronic Frontier Foundation は共同で DES 鍵を 22 時間 15 分で解読しました。また、実際の実装については実現不可能であるものの、暗号に理論上の弱点があることを示唆するいくつかの解析結果があります。こうした理論上の弱点があるにも関わらず、アルゴリズムは 3-DES の形式ではほとんど安全であると考えられています。近年、この暗号は高度暗号化標準 (AES) に置き換えられています。[8]
一部の文献では、標準としての DES と、DEA (Data Encryption Algorithm) と呼ばれる DES アルゴリズムを区別しています。[9] 

A.2. 公開鍵暗号

公開鍵暗号は、多くの暗号アルゴリズムと暗号化システムで採用されている暗号化のアプローチです。その際立った特徴は、対称鍵アルゴリズムの代わりか、または対称鍵と共に非対称鍵アルゴリズムを使用する点にあります。公開鍵/秘密鍵の暗号化技術を使用することで、以前には知られていなかった通信を保護し、メッセージを認証する数多くの方法を実用化できるようになりました。また、対称鍵アルゴリズムを使用する際に必要とされていた1つまたは複数の秘密鍵のセキュアな初期交換が不要になりました。さらに、公開鍵暗号を使って電子署名を作成することもできるようになりました。[10]
公開鍵暗号は、基本的な技術であり世界中で幅広く使用されています。また、トランスポート層セキュリティ (TLS) (SSL の後継)、PGP および GPG などのインターネット標準の土台となるアプローチです。[11] 
公開鍵暗号で使用される特徴的な技術は、非対称の鍵アルゴリズムの使用です。このアルゴリズムでは、メッセージを暗号化するために使われる鍵がメッセージを復号するために使用される鍵と同じではありません。各ユーザーは、暗号鍵と秘密鍵のペアを持ちます。公開鍵が広く配布される可能性があるのに対して、秘密鍵は秘密の状態にされます。メッセージは受信者の公開鍵で暗号化され、対応する秘密鍵でのみ暗号化解除することができます。これらの鍵は数学的に関連付けることができますが、(現在または将来において) 秘密鍵を公開鍵から導き出すことはできません。このアルゴリズムの発見は、1970 年代中盤に始まった暗号の使用に変革をもたらすものとなりました。[12]
これとは対照的に、数千年間にわたって使用されてきた各種の対称鍵暗号のアルゴリズムでは、暗号化と復号のために単一の秘密鍵が使用され、この鍵は送信者と受信者によって共有されます (この秘密鍵は共有されるものの、秘密の状態にしておく必要があります)。対称的な暗号化スキームを使用するには、送信者と受信者の両方が前もって鍵を安全に共有しておく必要があります。[13] 
対称鍵アルゴリズムの方の計算集約度が低くなることがほぼ通例であるため、鍵交換アルゴリズムを用いて鍵を交換してから、その鍵と対称鍵アルゴリズムを用いてデータを転送することが一般に行われています。例えば、PGP および各種スキームの SSL/TLS ファミリーがこれを実行するため、それらはハイブリッド暗号システムと呼ばれています。[14] 

A.2.1. Diffie-Hellman

Diffie–Hellman 鍵交換 (D–H) は、相互を認識していない 2 当事者間で、保護されていない通信チャネルを通して共有秘密鍵を共同で確立できるようにする暗号化プロトコルです。確立される鍵は、対称鍵暗号を用いて後続の通信を暗号化するために使用されます。[15]

A.2.1.1. Diffie-Hellman の歴史

このスキーマは 1976 年に Whitfield Diffie と Martin Hellman によって初めて公開されました。しかしながら後に、GCHQ の British signals intelligence agency 内の Malcolm J. Williamson が数年早くこれを単独で発明しており、かつ機密扱いにされていたことが明らかになりました。2002 年に Hellman は、Ralph Merkle の公開鍵暗号の発明に対する貢献を認めてこのアルゴリズムを Diffie–Hellman–Merkle 鍵交換と呼ぶことを提案しました(Hellman, 2002)。[16]
Diffie–Hellman 鍵合意はそれ自体が匿名の (認証されない) 鍵合意プロトコルであるにも関わらず、さまざまな認証されたプロトコルに対する基礎を提供し、トランスポート層セキュリティの超短期モード (暗号スイートに応じて EDH または DHE と呼ばれる) において PFS (Perfect Forward Secrecy) を提供するために使用されます。[17]
U.S. Patent 4,200,770 (現在は期間が満了している) は、アルゴリズムを説明しており、発明者は Hellman、Diffie および Merkle であるとしています。[18]

A.2.2. RSA

暗号学において、RSA (初めて公に説明した Rivest、Shamir および Adleman の頭文字を表す) は公開鍵暗号のアルゴリズムです。これは、暗号と署名のどちらにも適しているとされる最初のアルゴリズムであり、当初の公開鍵暗号における主要な優位性の 1 つとなってきました。RSA は、電子商取引のプロトコルで広く使用されており、十分な長さの鍵と最新の実装が使用されていることからセキュアであると考えられています。

A.2.3. DSA

電子署名アルゴリズム (DSA: Digital Signature Algorithm) は電子署名の標準であり、電子署名における米連邦政府の標準です。DSA は署名のみに使用されるアルゴリズムであり、暗号アルゴリズムではありません。[19]

A.2.4. SSL/TLS

トランスポート層セキュリティ (TLS: Transport Layer Security) とその前身である Secure Socket Layer (SSL) は、インターネットなどのネットワーク上の通信に対してセキュリティを提供する暗号プロトコルです。TLS と SSL は、エンドツーエンドでトランスポート層におけるネットワーク接続のセグメントを暗号化します。
このプロトコルのいくつかのバージョンは、ウェブ閲覧、電子メール、インターネット FAX、インスタントメッセージおよび voice-over-IP (VoIP) などのアプリケーションで広く使われています。[20]

A.2.5. Cramer-Shoup 暗号システム

Cramer–Shoup システムは非対称暗号アルゴリズムであり、標準的な暗号推測に基づく適応的選択暗号文攻撃に対してセキュアであることが証明された初の効率的なスキームです。そのセキュリティは、決定 Diffie–Hellman 仮定の計算的な難解さに基づいています(これは一般的な想定で、実証されている訳ではありません)。これは 1998年に Ronald Cramer と Victor Shoup により開発された ElGamal 暗号の拡張です。極めて順応性のある ElGamal と比べて、Cramer–Shoup には高度な攻撃者に対してさえも頑強性を確保するために追加の要素が加わります。この頑強性は、衝突耐性のあるハッシュ機能と追加の計算の使用によって実現され、これにより ElGamal の2倍の暗号文が生成されます。[21]

A.2.6. ElGamal 暗号

暗号学において、ElGamal 暗号システムは Diffie-Hellman 鍵合意に基づく公開鍵暗号の非対称鍵暗号アルゴリズムです。1985年に Taher Elgamal がこれを発表しました。Elgamal 暗号は、GNU Privacy Guard フリーソフトウェアや最近のバージョンの PGP および他の暗号システムで使用されています。[22]


[5] "Advanced Encryption Standard" Wikipedia 2009年11月14日http://en.wikipedia.org/wiki/Advanced_Encryption_Standard
[6] "Advanced Encryption Standard" Wikipedia 2009年11月14日 http://en.wikipedia.org/wiki/Advanced_Encryption_Standard
[7] "Data Encryption Standard." Wikipedia. 2009年11月14日 http://en.wikipedia.org/wiki/Data_Encryption_Standard
[8] "Data Encryption Standard" Wikipedia 2009年11月14日 http://en.wikipedia.org/wiki/Data_Encryption_Standard
[9] "Data Encryption Standard" Wikipedia 2009年11月14日 http://en.wikipedia.org/wiki/Data_Encryption_Standard
[10] "Public-key Encryption" Wikipedia 2009年11月14日 http://en.wikipedia.org/wiki/Public-key_cryptography
[11] "Public-key Encryption." Wikipedia 2009 年 11 月 14 日 http://en.wikipedia.org/wiki/Public-key_cryptography
[12] "Public-key Encryption." Wikipedia. 2009 年 11 月 14 日 http://en.wikipedia.org/wiki/Public-key_cryptography
[13] "Public-key Encryption." Wikipedia 2009 年 11 月 14 日 http://en.wikipedia.org/wiki/Public-key_cryptography
[14] "Public-key Encryption." Wikipedia 2009 年 11 月 14 日 http://en.wikipedia.org/wiki/Public-key_cryptography
[15] "Diffie-Hellman." Wikipedia 2009 年 11 月 14 日 http://en.wikipedia.org/wiki/Diffie-Hellman
[16] "Diffie-Hellman." Wikipedia 2009 年 11 月 14 日 http://en.wikipedia.org/wiki/Diffie-Hellman
[17] "Diffie-Hellman." Wikipedia2009 年 11 月 14 日 http://en.wikipedia.org/wiki/Diffie-Hellman
[18] "Diffie-Hellman." Wikipedia. 2009 年 11 月 14 日 http://en.wikipedia.org/wiki/Diffie-Hellman
[20] "TLS/SSL." Wikipedia 2010 年 2 月 24 日 http://en.wikipedia.org/wiki/Transport_Layer_Security
[21] "Cramer-Shoup cryptosystem." Wikipedia 2010 年 2 月 24 日 http://en.wikipedia.org/wiki/Cramer–Shoup_cryptosystem
[22] "ElGamal encryption" Wikipedia 2010 年 2 月 24 日 http://en.wikipedia.org/wiki/ElGamal_encryption

Audit システムのリファレンス

B.1. Audit イベントフィールド

表B.1「イベントフィールド」 では、現在サポートされている Audit イベントフィールドを一覧表示しています。イベントフィールドとは、Audit ログファイルで等号記号の前にある値です。

表B.1 イベントフィールド

イベントフィールド説明
a0a1a2a3システムコールの最初の 4 つの引数を十六進法で記録します。
acctユーザーのアカウント名を記録します。
addrIPv4 または IPv6 アドレスを記録します。このフィールドは通常、hostname フィールドの後に来て、ホスト名が解決するアドレスを含みます。
archシステムの CPU アーキテクチャーについての情報を十六進法にエンコードして記録します。
auidAudit ユーザー ID を記録します。この ID は、ログイン時にユーザーに割り当てられ、ユーザーの ID が変更された後でもすべてのプロセスに引き継がれます (たとえば、su - john コマンドでユーザーアカウントを切り替えた場合)。
capability特定の Linux 機能の設定に使用されたビット数を記録します。Linux 機能については、capabilities(7) man ページを参照してください。
cap_fi引き継いだファイルのシステムベースの機能設定に関連したデータを記録します。
cap_fp許可されたファイルのシステムベースの機能設定に関連したデータを記録します。
cap_pe効果的なプロセスベースの機能設定に関連したデータを記録します。
cap_pi継承されたプロセスベースの機能設定に関連したデータを記録します。
cap_pp許可されたプロセスベースの機能設定に関連したデータを記録します。
cgroupAudit イベント生成時のプロセスが含まれる cgroup へのパスを記録します。
cmd実行されたコマンドライン全体を記録します。これは、exe フィールドがたとえば /bin/bash を記録するようなシェルインタープリターの場合に便利です。シェルインタープリターと cmd フィールドは、helloworld.sh --help のような実行されたコマンドラインの残りの部分を記録するからです。
comm実行されたコマンドを記録します。これは、exe フィールドがたとえば /bin/bash を記録するようなシェルインタープリターの場合に便利です。シェルインタープリターと comm フィールドは、helloworld.sh のような実行されたスクリプト名を記録するからです。
cwdシステムコールが開始されたディレクトリーへのパスを記録します。
dataTTY 記録に関連するデータを記録します。
devイベントで記録されたファイルまたはディレクトリーを含むデバイスのマイナーおよびメジャー ID を記録します。
devmajorメジャーデバイス ID を記録します。
devminorマイナーデバイス ID を記録します。
egid分析されているプロセスを開始したユーザーの実効グループ ID を記録します。
euid分析されているプロセスを開始したユーザーの実効ユーザー ID を記録します。
exe分析されているプロセスを開始するために使用された実行可能ファイルへのパスを記録します。
exitシステムコールが返した終了コードを記録します。この値は、システムコールによって異なります。以下のコマンドを使うと、この値をヒューマンリーダブルなものに変換できます。ausearch --interpret --exit exit_code
familyIPv4 または IPv6 の使用されたアドレスプロトコルのタイプを記録します。
filetypeファイルのタイプを記録します。
flagsファイルシステム名のフラグを記録します。
fsgid分析されているプロセスを開始したユーザーのファイルシステムグループ ID を記録します。
fsuid分析されているプロセスを開始したユーザーのファイルシステムユーザー ID を記録します。
gidグループ ID を記録します。
hostnameホスト名を記録します。
icmptype受信した Internet Control Message Protocol (ICMP) パッケージのタイプを記録します。このフィールドを含む Audit メッセージは通常、iptables が生成します。
id変更されたアカウントのユーザー ID を記録します。
inodeAudit イベントで記録されたファイルまたはディレクトリーに関連する inode 番号を記録します。
inode_gidinode の所有のグループ ID を記録します。
inode_uidinode の所有のユーザー ID を記録します。
itemsこの記録にアタッチされたパス記録の数を記録します。
keyAudit ログで特定のイベントを生成したルールに関連付けられているユーザー定義の文字列を記録します。
listAudit ルールリストの ID を記録します。以下が既知の ID リストになります。
  • 0 — user
  • 1 — task
  • 4 — exit
  • 5 — exclude
modeファイルまたはディレクトリーのパーミッションを数字表記にエンコードして記録します。
msg記録のタイムスタンプと一意の ID、または各種のイベント固有の <name>=<value> ペアを記録します。これらは、カーネルもしくはユーザースペースアプリケーションが提供します。
msgtypeユーザーベースの AVC 拒否の場合に返されたメッセージのタイプを記録します。このメッセージタイプは、D-Bus で決定されます。
nameシステムコールに引数として渡されたファイルまたはディレクトリーへの完全パスを記録します。
new-disk仮想マシンに割り当てられた新規ディスクリソースの名前を記録します。
new-mem仮想マシンに割り当てられた新規メモリーリソースの容量を記録します。
new-vcpu仮想マシンに割り当てられた新規の仮想 CPU リソースの数を記録します。
new-net仮想マシンに割り当てられた新規ネットワークインターフェイスのリソースの MAC アドレスを記録します。
new_gidユーザーに割り当てられたグループ ID を記録します。
oauidシステムにアクセスするためにログインし (su を使用してのログインなどではなく)、ターゲットプロセスを開始したユーザーのユーザー ID を記録します。このフィールドは、タイプ OBJ_PID の記録専用になります。
ocommターゲットプロセスの開始に使用されたコマンドを記録します。このフィールドは、タイプ OBJ_PID の記録専用になります。
opidターゲットプロセスのプロセス ID を記録します。このフィールドは、タイプ OBJ_PID の記録専用になります。
osesターゲットプロセスのセッション ID を記録します。このフィールドは、タイプ OBJ_PID の記録専用になります。
ouidターゲットプロセスの実際のユーザー ID を記録します。
objオブジェクトの SELinux コンテキストを記録します。オブジェクトは、ファイルやディレクトリー、またはサブジェクトのアクションを受信するものになります。
obj_gidオブジェクトのグループ ID を記録します。
obj_lev_highオブジェクトの高い SELinux レベルを記録します。
obj_lev_lowオブジェクトの低い SELinux レベルを記録します。
obj_roleオブジェクトの SELinux の役割を記録します。
obj_uidオブジェクトの UID を記録します。
obj_userオブジェクトに関連付けられたユーザーを記録します。
ogidオブジェクトの所有者のグループ ID を記録します。
old-disk新規ディスクリソースが仮想マシンに割り当てられた際の古いディスクリソース名を記録します。
old-mem新しいメモリー容量が仮想マシンに割り当てられた際の古いメモリーリソースの容量を記録します。
old-vcpu新規の仮想 CPU が仮想マシンに割り当てられた際の古い仮想 CPU リソースの数を記録します。
old-net新規ネットワークインターフェイスが仮想マシンに割り当てられた際の古いネットワークインターフェイスリソースの MAC アドレスを記録します。
old_promネットワークの無作為フラグの以前の値を記録します。
ouidターゲットプロセスを開始したユーザーの実際のユーザー ID を記録します。
pathAVC 関連の Audi イベントでシステムコールに引数として渡されたファイルまたはディレクトリーへの完全パスを記録します。
permイベント生成に使用されたファイルパーミッション (つまり、読み取り、書き込み、実行、または属性変更) を記録します。
pid
pid フィールドのセマンティックは、このフィールドの値の発生元によって異なります。
ユーザースペースから生成されたフィールドの場合、このフィールドはプロセス ID になります。
カーネルが生成したフィールドの場合、このフィールドはスレッド ID になります。スレッド ID は単一スレッドプロセスの場合、プロセス ID と同じになります。このスレッド ID の値は、ユーザースペースで使用される pthread_t ID の値とは異なることに注意してください。詳細は、gettid(2) man ページを参照してください。
ppid親プロセス ID (PID) を記録します。
promネットワークの無作為フラグを記録します。
proto使用されたネットワークプロトコルを記録します。このフィールドは、iptables で生成された Audit イベントに固有のものになります。
resAudit イベントを開始した操作結果を記録します。
resultAudit イベントを開始した操作結果を記録します。
saddrソケットアドレスを記録します。
sauid送信者の Audit ログインユーザー ID を記録します。この ID は、元の auid を送信しているユーザーをカーネルが判別できないため、D-Bus が提供します。
ses分析されているプロセスが開始されたセッションのセッション ID を記録します。
sgid分析されているプロセスを開始したユーザーのセットグループ ID を記録します。
sigプログラムを異常終了させたシグナル数を記録します。これは通常、システム侵入を知らせるものです。
subjサブジェクトの SELinux コンテキストを記録します。サブジェクトは、プロセスやユーザー、またはオブジェクトに対して動作を行なっているものになります。
subj_clrサブジェクトの SELinux クリアランスを記録します。
subj_roleサブジェクトの SELinux の役割を記録します。
subj_senサブジェクトの SELinux の秘密度を記録します。
subj_userサブジェクトに関連付けられたユーザーを記録します。
successシステムコールが成功したか、失敗したかを記録します。
suid分析されているプロセスを開始したユーザーのセットユーザー ID を記録します。
syscallカーネルに送信されたシステムコールのタイプを記録します。
terminalターミナル名 (/dev/ なしで) を記録します。
tty制御ターミナルの名前を記録します。プロセスに制御ターミナルがない場合は、(none) の値を使います。
uid分析されているプロセスを開始したユーザーの実際のユーザー ID を記録します。
vmAudit イベントが始まった仮想マシン名を記録します。

B.2. Audit 記録のタイプ

表B.2「記録のタイプ」 では、現在サポートされている Audit 記録のタイプを一覧表示しています。イベントのタイプは、すべての Audit 記録の最初にある type= フィールドで指定されています。

表B.2 記録のタイプ

イベントタイプ説明
ADD_GROUPユーザースペースグループが追加されると開始します。
ADD_USERユーザースペースユーザーのアカウントが追加されると開始します。
ANOM_ABEND[a]プロセスが異常終了すると開始します (コアダンプを引き起こすシグナルが有効になっていれば、このシグナルを伴います)。
ANOM_ACCESS_FS[a]ファイルまたはディレクトリーアクセスが異常終了すると開始します。
ANOM_ADD_ACCT[a]ユーザースペースアカウントの追加が異常終了すると開始します。
ANOM_AMTU_FAIL[a]Abstract Machine Test Utility (AMTU) の失敗が検出されると開始します。
ANOM_CRYPTO_FAIL[a]暗号化システムの失敗が検出されると開始します。
ANOM_DEL_ACCT[a]ユーザースペースアカウントの削除が異常終了すると開始します。
ANOM_EXEC[a]ファイル実行が異常終了すると開始します。
ANOM_LOGIN_ACCT[a]アカウントのログイン試行が異常終了すると開始します。
ANOM_LOGIN_FAILURES[a]ログイン試行が失敗の制限数に達すると開始します。
ANOM_LOGIN_LOCATION[a]許可されていない場所からログイン試行が行われると開始します。
ANOM_LOGIN_SESSIONS[a]ログイン試行が同時セッションの最大数に達すると開始します。
ANOM_LOGIN_TIME[a]ログイン試行が pam_time などによって妨げられる場合に開始します。
ANOM_MAX_DAC