セキュリティーガイド
RHEL サーバーとワークステーションをセキュアにする概念と手法
概要
第1章 セキュリティーの概要
注記
/lib
ディレクトリーにあるファイルにも言及しています。64 ビットのシステムを使用している場合は、それらのファイルの一部は /lib64
にある可能性があります。
1.1. コンピューターセキュリティーとは
1.1.1. セキュリティーの標準化
- 機密性 — 機密情報は、事前に定義された個人に対してのみ利用可能とする必要があります。情報の許可されていない送信や使用は、制限する必要があります。例えば、情報に機密性があれば、権限のない個人が ID 盗難やクレジット詐欺などの悪意のある目的で顧客情報や財務情報を入手できません。
- 保全性 — 情報は、不完全または不正確になるように改ざんすべきではありません。承認されていないユーザーは、機密情報を変更したり破壊する機能を使用できないように制限される必要があります。
- 可用性 — 情報は、認証されたユーザーが必要な時にいつでもアクセスできる必要があります。可用性は、情報が合意された頻度とタイミングで入手できることを保証します。これは、パーセンテージで測定されることが多く、ネットワークサービスプロバイダーやその企業顧客が使用するサービスレベルアグリーメント (SLA) で正式に合意されます。
1.1.2. 暗号化ソフトウェアおよび認定
1.2. セキュリティーコントロール
- 物理的
- 技術的
- 管理的
1.2.1. 物理的コントロール
- 有線監視カメラ
- 動作/温度感知アラームシステム
- 警備員
- 写真付き身分証明書
- 施錠された、デッドボルト付きのスチールドア
- バイオメトリクス (指紋、声、顔、虹彩、筆跡、および本人確認を行うためのその他の自動認識方法が含まれます)
1.2.2. 技術的コントロール
- 暗号化
- スマートカード
- ネットワーク認証
- アクセス制御リスト (ACL: Access control lists)
- ファイル完全性監査ソフトウェア
1.2.3. 管理者コントロール
- トレーニングおよび認識の向上
- 災害準備および復旧計画
- 人員採用と分離の戦略
- 人員登録とアカウンティング
1.3. 脆弱性のアセスメント
- 技術の設定、監視、および保守を行うスタッフの専門知識
- サービスとカーネルのパッチ、および更新を迅速かつ効率的に行う能力
- ネットワーク上での警戒を常に怠らない担当者の能力
1.3.1. アセスメントとテストの定義
警告
- 情報セキュリティーに事前にフォーカスできる
- クラッカーが発見する前に潜在的な不正使用を発見できる
- システムを最新の状態に維持し、パッチを適用できる
- スタッフの成長と専門知識の開発を促す
- 経済的な損失とマイナスの評判を緩和する
1.3.2. 方法論の確立
- https://www.owasp.org/ — 『The Open Web Application Security Project』
1.3.3. 脆弱性アセスメントのツール
README
ファイルや man ページも確認してください。さらに、インターネットからツールについての記事やステップバイステップのガイドまたはツール固有のメーリングリストなどの詳細情報を入手してください。
1.3.3.1. Nmap を使用したホストのスキャン
root
で yum install nmap
コマンドを実行します。
1.3.3.1.1. 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
1.3.3.2. Nessus
注記
1.3.3.3. OpenVAS
1.3.3.4. Nikto
1.4. セキュリティーへの脅威
1.4.1. ネットワークセキュリティーへの脅威
セキュリティーが十分ではないアーキテクチャー
ブロードキャストネットワーク
集中化サーバー
1.4.2. サーバーセキュリティーへの脅威
未使用のサービスと開かれたポート
パッチが適用されないサービス
管理における不注意
本質的に安全ではないサービス
1.4.3. ワークステーションおよび家庭用 PC のセキュリティーに対する脅威
不適切なパスワード
脆弱なクライアントアプリケーション
1.5. 一般的な不正使用と攻撃
表1.1 一般的な不正使用
不正使用 | 説明 | 注意事項 |
---|---|---|
空またはデフォルトのパスワード | 管理パスワードを空白のままにしたり、製品ベンダーが設定したデフォルトパスワードをそのまま使用します。ルーターやファイアウォールなどのハードウェアで最もよく見られますが、Linux で実行するサービスにはデフォルトの管理者パスワードが入っているものがあります(ただし Red Hat Enterprise Linux 7 はパスワードなしで出荷されます)。 |
ルーター、ファイアウォール、VPN および Network Attached Storage (NAS) アプライアンスなどのネットワークハードウェアに一般的に関連するものです。
多数のレガシーオペレーティングシステム、特にサービスをバンドルしたオペレーティングシステム (UNIX や Windows など) によくあります。
管理者が急いで特権ユーザーアカウントを作成したためにパスワードが空白のままになっていることがありますが、これは、このアカウントを発見した悪意のあるユーザーにとっては、絶好のエントリーポイントとなります。
|
デフォルトの共有鍵 | セキュアなサービスでは、開発や評価テスト用にデフォルトのセキュリティー鍵がパッケージ化されていることがあります。これらの鍵を変更せずにインターネット上の実稼働環境に置いた場合、同じデフォルトの鍵を持つすべてのユーザーがその共有鍵のリソースや、そこにあるすべての機密情報にアクセスできるようになります。 |
無線アクセスポイントや事前設定済みのセキュアなサーバー機器に最も多く見られます。
|
IP スプーフィング | リモートマシンがローカルネットワーク上でノードとして動作し、サーバーに脆弱性を見つけるとバックドアプログラムまたはトロイの木馬をインストールして、ネットワークリソース全体へのコントロールを得ようとします。 |
スプーフィングは、攻撃者が標的となるシステムへの接続を調整するのに TCP/IP シーケンス番号を予測しなければならないのでかなり難しいことですが、クラッカーの脆弱性の攻撃を支援する利用可能なツールがいくつかあります。
標的となるシステムで実行される、ソースベース認証技術を使用するサービス (
rsh 、 telnet 、FTP その他) によって異なりますが、このようなサービスは、ssh または SSL/TLS で使用される PKI やその他の形式の暗証化認証と比較すると推奨できるものではありません。
|
盗聴 | 2 つのノード間の接続を盗聴することにより、ネットワーク上のアクティブなノード間を行き交うデータを収集します。 |
この種類の攻撃には大抵、Telnet、FTP、HTTP 転送などのプレーンテキストの転送プロトコルが使われます。
リモートの攻撃者がこのような攻撃を仕掛けるには、LAN 上で、攻撃するシステムへのアクセス権が必要になります。通常、クラッカーは、LAN 上にあるシステムを危険にさらすためにアクティブ攻撃(IP スプーフィングや中間者攻撃など) を仕掛けます。
パスワードのなりすましを防ぐ予防策としては、暗号化鍵交換、ワンタイムパスワードまたは暗号化された認証によるサービス使用が挙げられます。通信中は強力な暗号化を実施することをお勧めします。
|
サービスの脆弱性 | 攻撃者はインターネット上で実行されているサービスの欠陥や抜け穴を見つけます。この脆弱性を利用する攻撃者は、システム全体と格納されているデータを攻撃するだけでなく、ネットワーク上の他のシステムも攻撃する可能性があります。 |
CGI などの HTTP ベースのサービスは、リモートのコマンド実行やインタラクティブなシェルアクセスに対しても脆弱です。HTTP サービスが「nobody」などの権限のないユーザーとして実行される場合でも、設定ファイルやネットワークマップなどの情報が読み取られる可能性があります。または、攻撃者がサービス拒否攻撃を開始して、システムのリソースを流出させたり、他のユーザーが利用できないようにする可能性もあります。
開発時およびテスト時には気付かない脆弱性がサービスに含まれることがあります。このような脆弱性 (攻撃者が任意の値を使用してアプリケーションのメモリーバッファー領域をあふれさせ、攻撃者が任意のコマンドを実行できるようなインタラクティブなコマンドプロンプトを与えて、サービスをクラッシュさせるバッファーオーバーフローなど)は完全な管理コントロールを攻撃者に与えるものとなる可能性があります。
管理者は、サービスが root ユーザーとして実行されないようにし、ベンダーまたは CERT や CVE などのセキュリティー組織からのアプリケーション用のパッチやエラータ更新がないか常に注意する必要があります。
|
アプリケーションの脆弱性 | 攻撃者はデスクトップやワークステーションのアプリケーション(電子メールクライアントなど)に欠陥を見つけ出し、任意のコードを実行したり、将来のシステム侵害のためにトロイの木馬を移植したり、システムを破壊したりします。攻撃を受けたワークステーションがネットワークの残りの部分に対して管理特権を持っている場合は、さらなる不正使用が起こる可能性があります。 |
ワークステーションとデスクトップは、ユーザーが侵害を防いだり検知するための専門知識や経験を持たないため、不正使用の対象になりやすくなります。認証されていないソフトウェアをインストールしたり、要求していないメールの添付ファイルを開く際には、それに伴うリスクについて個々に通知することが必須です。
電子メールクライアントソフトウェアが添付ファイルを自動的に開いたり、実行したりしないようにするといった、予防手段を取ることが可能です。さらに、Red Hat Network や他のシステム管理サービスなどからワークステーションのソフトウェアを自動更新することにより、マルチシートのセキュリティーデプロイメントの負担を軽減できます。
|
サービス拒否攻撃 (DoS: Denial of Service) | 単独の攻撃者または攻撃者のグループは、目標のホスト(サーバー、ルーター、ワークステーションのいずれか)に認証されていないパケットを送ることにより、組織のネットワークまたはサーバーのリソースに対して攻撃を仕掛けます。これにより、正当なユーザーはリソースを使用できなくなります。 |
2000 年に発生した米国内での DoS で最も多く報告されたケースとして、通信量の非常に多い民間および政府サイトのいくつかが利用不可能になりました。 ゾンビ (zombie) やリダイレクトされたブロードキャストノードとして動作する、高帯域幅接続を有する複数の攻撃対象のシステムを使って、調整された ping フラッド攻撃が行われたためです。
通常ソースパケットは、攻撃の本当のもとを調査するのが難しくなるよう、偽装 (または再ブロードキャスト)されています。
iptables を使用したイングレスフィルタリング (IETF rfc2267) や snort などのネットワーク侵入検知システムにおける進歩は、管理者が分散型サービス拒否攻撃を追跡し、これを防止するのに役立っています。
|
第2章 インストール時におけるセキュリティーのヒント
2.1. BIOS のセキュア化
2.1.1. BIOS パスワード
- BIOS 設定の変更を防止する — 侵入者が BIOS にアクセスした場合、CD-ROM やフラッシュドライブから起動するように設定できます。このようにすると、侵入者がレスキューモードやシングルユーザーモードに入ることが可能になり、システム上で任意のプロセスを開始したり、機密性の高いデータをコピーできるようになってしまいます。
- システムの起動を防止する — BIOS の中には起動プロセスをパスワードで保護できるものもあります。これを有効にすると、攻撃者は BIOS がブートローダーを開始する前にパスワード入力を求められます。
2.1.1.1. 非 BIOS ベースのシステム
2.2. ディスクのパーティション設定
/boot
、/
、/home
/tmp
、および /var/tmp/
の各ディレクトリーに個別のパーティションを作成することを推奨しています。各パーティションの目的は異なります。以下でこれらのパーティションについて説明します。
/boot
- このパーティションは、ブート時にシステムが最初に読み込むパーティションです。システムを Red Hat Enterprise Linux 7 にブートするために使われるブートローダーとカーネルイメージはこのパーティションに保存されます。このパーティションは暗号化すべきではありません。このパーティションが / に含まれていて、そのパーティションが暗号化されているかまたは他の理由で利用できなくなると、システムをブートすることができなくなります。
/home
- ユーザーデータ (
/home
) が別個のパーティションではなく/
に保存されていると、このパーティションが一杯になり、オペレーティングシステムが不安定になる可能性があります。また、システムを次のバージョンの Red Hat Enterprise Linux 7 にアップグレードする際には、/home
パーティションでデータを保存できると、このデータはインストール時に上書きされないので、アップグレードが非常に簡単になります。root パーティション (/
) が破損すると、ユーザーのデータは完全に失われてしまいます。個別のパーティションを使うことで、データ損失に対する保護が少しは高まります。また、このパーティションを頻繁にバックアップする対象とすることも可能です。 /tmp
および/var/tmp/
/tmp
ディレクトリーおよび/var/tmp/
ディレクトリーは、どちらも長期保存の必要がないデータを保存するために使われます。しかし、これらのディレクトリーのいずれかでデータがあふれると、ストレージスペースがすべて消費されてしまう可能性があります。こうした状態が発生し、かつこれらのディレクトリーが/
に保管されていると、システムが不安定になり、クラッシュする可能性があります。そのため、これらのディレクトリーは個別のパーティションに移動することが推奨されます。
注記
2.3. 必要なパッケージの最小限のインストール
2.4. インストールプロセス時のネットワーク接続の制限
2.5. インストール後の手順
- システムを更新します。root で以下のコマンドを実行します。
~]#
yum update
- ファイアウォールサービスの
firewalld
は Red Hat Enterprise Linux のインストールで自動的に有効になっていますが、kickstart 設定などで明示的に無効となっている場合もあります。このような場合は、ファイアウォールを再度有効にすることが推奨されます。firewalld
を開始するには、root で以下のコマンドを実行します。~]#
systemctl start firewalld
~]#systemctl enable firewalld
- セキュリティーを強化するために、不要なサービスは無効にしてください。たとえば、使用中のコンピューターにプリンターがインストールされていなければ、以下のコマンドを使って
cups
サービスを無効にします。~]#
systemctl disable cups
アクティブなサービスを確認するには、次のコマンドを実行します。~]$
systemctl list-units | grep service
2.6. 関連情報
第3章 システムを最新の状態に保つ
3.1. インストール済みソフトウェアのメンテナンス
3.1.1. セキュリティーの更新の立案と設定
3.1.1.1. Yum のセキュリティー機能の使用
root
で以下のコマンドを実行します。
~]# yum check-update --security
Loaded plugins: langpacks, product-id, subscription-manager
rhel-7-workstation-rpms/x86_64 | 3.4 kB 00:00:00
No packages needed for security; 0 packages available
~]# yum update --security
updateinfo
サブコマンドを使うと、リポジトリーが提供する利用可能な更新についての情報を表示したり、それについてアクションを取ることができます。この updateinfo
サブコマンド自体は、多くのコマンドを受け付け、この中にはセキュリティー関連の使用も含まれます。これらのコマンドの概要については、表3.1「yum updateinfo で使用可能なセキュリティー関連のコマンド」 を参照してください。
表3.1 yum updateinfo で使用可能なセキュリティー関連のコマンド
コマンド | 説明 | |
---|---|---|
advisory [advisories] | 1 つ以上のアドバイザリーについての情報を表示します。advisories をアドバイザリー番号または番号に置き換えます。 | |
cves | CVE (Common Vulnerabilities and Exposures) に関連する情報のサブセットを表示します。 | |
security または sec | セキュリティー関連の情報をすべて表示します。 | |
severity [severity_level] or sev [severity_level] | 提供された severity_level のセキュリティー関連パッケージについての情報を表示します。 |
3.1.2. パッケージの更新とインストール
3.1.2.1. 署名パッケージの検証
/etc/yum.conf
設定ファイル内で gpgcheck
設定ディレクティブが 1
に設定されていることを確認してください。
rpmkeys --checksig package_file.rpm
3.1.2.2. 署名パッケージのインストール
root
で yum install
コマンドを実行します。
yum install package_file.rpm
.rpm
パッケージがインストールされます。
yum install *.rpm
重要
3.1.3. インストールされた更新による変更の適用
注記
- アプリケーション
- ユーザースペースのアプリケーションとは、ユーザーが開始できるすべてのプログラムのことです。通常このようなアプリケーションは、ユーザー、スクリプトまたは自動化されたタスクユーティリティがそれらを起動する場合にのみ使用されるものです。ユーザースペースのアプリケーションが更新されると、システムにあるアプリケーションのすべてのインスタンスが停止し、更新バージョンを使用するためにプログラムが再起動されます。
- カーネル
- カーネルは、Red Hat Enterprise Linux 7 オペレーティングシステムの中心的なソフトウェアコンポーネントです。カーネルはメモリー、プロセッサーおよび周辺機器へのアクセスを管理し、すべてのタスクをスケジュールします。カーネルは中心的な役割を担うので、カーネルの再起動にはコンピューターの再起動が伴います。つまりカーネルの更新バージョンは、システムの再起動後に初めて使用できるようになります。
- KVM
- qemu-kvm および libvirt のパッケージが更新されると、すべてのゲスト仮想マシンを停止して、関連の仮想化モジュールをリロードし (またはホストシステムを再起動し)、仮想マシンを再起動する必要があります。
kvm
、kvm-intel
、またはkvm-amd
のどのモジュールがロードされているかを確認するには、lsmod
コマンドを使用します。その後にmodprobe -r
コマンドを使用してロードされているモジュールを削除し、modprobe -a
コマンドで影響を受けたモジュールをリロードします。以下に例を示します。~]#
lsmod | grep kvm
kvm_intel 143031 0 kvm 460181 1 kvm_intel ~]#modprobe -r kvm-intel
~]#modprobe -r kvm
~]#modprobe -a kvm kvm-intel
- 共有ライブラリ
- 共有ライブラリは、
glibc
のように、多くのアプリケーションやサービスにより使用されるコードの集合です。通常、共有ライブラリを使用しているアプリケーションは、アプリケーションが初期化される際に共有コードを読み込みます。そのため、更新されたライブラリを使用しているすべてのアプリケーションは、まず停止してから再起動する必要があります。特定ライブラリにリンクしている実行中のアプリケーションを判別するには、以下の例のようにlsof
コマンドを使用します。lsof library
たとえば、libwrap.so.0
ライブラリーにリンクしている実行中のアプリケーションを判別するには、以下を入力します。~]#
lsof /lib64/libwrap.so.0
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME pulseaudi 12363 test mem REG 253,0 42520 34121785 /usr/lib64/libwrap.so.0.7.6 gnome-set 12365 test mem REG 253,0 42520 34121785 /usr/lib64/libwrap.so.0.7.6 gnome-she 12454 test mem REG 253,0 42520 34121785 /usr/lib64/libwrap.so.0.7.6このコマンドは、ホストのアクセス制御にTCP
Wrapper を使用する実行中のプログラムの一覧を返します。そのため tcp_wrappers パッケージが更新されると、リストにあるすべてのプログラムは停止してから再起動する必要があります。 - systemd サービス
- systemd サービスは、通常ブートプロセス中に開始される永続的なサーバープログラムです。systemd サービスの例としては、
sshd
やvsftpd
などがあります。通常、これらのプログラムはマシンが起動している限りはメモリ内に残るので、パッケージのアップグレード後には、更新された systemd サービスは停止してから再起動する必要があります。これは、root
でsystemctl
コマンドを使用すると実行できます。systemctl restart service_name
service_name をsshd
などの再起動するサービスの名前に置き換えます。 - 他のソフトウェア
- 以下のアプリケーションの更新は、リンク先のリソースで示された指示にしたがってください。
- Red Hat Directory Server — https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/ で該当する Red Hat Directory Server バージョンの 『Release Notes』 を参照してください。
- Red Hat Enterprise Virtualization Manager — https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization/ で該当する Red Hat Enterprise Virtualization のバージョンの 『インストールガイド』 を参照してください。
3.2. Red Hat カスタマーポータルの使用
3.2.1. カスタマーポータルでセキュリティー更新を見る
3.2.3. 問題の影響度の分類について
3.3. 関連情報
インストールされているドキュメント
- yum(8) - Yum パッケージマネジャーの man ページでは、Yum を使用してシステムにパッケージをインストール、更新、削除する方法を説明しています。
- rpmkeys(8) -
rpmkeys
ユーティリティーの man ページでは、このプログラムを使用してダウンロードされたパッケージの信頼性を検証する方法を説明しています。
オンラインのドキュメント
- Red Hat Enterprise Linux 7 システム管理者ガイド — Red Hat Enterprise Linux 7 の 『システム管理者ガイド』 では、
Yum
およびrpm
コマンドを使って Red Hat Enterprise Linux 7 システム上でパッケージをインストール、更新、削除する方法について説明しています。 - Red Hat Enterprise Linux 7 SELinux User's and Administrator's Guide — Red Hat Enterprise Linux 7 の 『SELinux User's and Administrator's Guide』 では、SELinux mandatory access control メカニズムの設定について説明しています。
Red Hat カスタマーポータル
- Red Hat カスタマーポータル、セキュリティー — カスタマーポータルの セキュリティー セクションには、Red Hat CVE データベースや Red Hat 製品セキュリティーの連絡先など、最も重要なリソースへのリンクが含まれています。
- Red Hat セキュリティーブログ — Red Hat セキュリティー専門家による最新のセキュリティー関連問題に関する記事。
関連項目
- 2章インストール時におけるセキュリティーのヒントでは、追加のセキュリティー設定を後で簡単に実装できるようにシステムを安全に一から設定する方法について説明しています。
- 「GPG 鍵の作成」 では、個人の GPG 鍵セットを作成し、通信を認証する方法について説明しています。
第4章 ツールとサービスを使用したシステム強化
4.1. デスクトップのセキュリティー
4.1.1. パスワードのセキュリティー
/etc/passwd
ファイルに一方向のハッシュとして保存されます。この場合、システムはオフラインのパスワードクラッキング攻撃に脆弱なものとなってしまいます。侵入者が通常のユーザーとしてマシンにアクセスすると、/etc/passwd
ファイルを侵入者自身のマシンにコピーして、パスワードクラッキングプログラムをいくつでも実行できるようになります。このファイルに安全でないパスワードがあれば、パスワードクラッカーがこれを見つけるのは時間の問題となります。
/etc/shadow
ファイルに保存することで、このタイプの攻撃を排除します。このファイルは、root ユーザーのみが読み取り可能なためです。
注記
4.1.1.1. 強固なパスワードの作成
randomword1 randomword2 randomword3 randomword4
1!
" を追加します。このような修正は、パスフレーズの安全性を大幅に高めるもの ではない ことに注意してください。
/dev/urandom
から引き出されます。指定可能な最小ビット数は 56 で、これはブルートフォース攻撃が滅多に仕掛けられないシステムやサービスのパスワードには十分なものです。攻撃者がパスワードハッシュファイルに直接アクセスできないアプリケーションであれば、64 ビットで十分です。攻撃者がパスワードハッシュへの直接アクセスを取得する可能性がある場合やパスワードが暗号鍵として使用される場合は、80 ビットや 128 ビットを使用する必要があります。無効なエントロピービット数を指定すると、pwmake はデフォルトのビット数を使用します。128 ビットのパッケージを作成するには、以下のコマンドを実行します。
pwmake 128
- 辞書の 1 単語を使用する。外国語の 1 単語を使用する。反転した単語を使用する。数字のみを使用する。
- パスワードまたはパスフレーズを 10 文字未満にする。
- キーボードのレイアウトにおけるキーの配列を使用する。
- パスフレーズを書き留める。
- 誕生日や記念日、家族の名前、ペットの名前などの個人情報をパスフレーズに使用する。
- 複数のマシンで同じパスワードまたはパスフレーズを使用する。
4.1.1.2. 強固なパスワードの強制
passwd
コマンドラインユーティリティーを使用することができます。これは PAM (Pluggable Authentication Modules) を認識し、パスワードが短すぎないか、短くない場合は簡単にクラックされないかを確認します。この確認は、pam_pwquality.so
PAM モジュールが実行します。
注記
pam_pwquality
PAM モジュールが pam_cracklib
の代わりとなっています。後者は、Red Hat Enterprise Linux 6 でパスワードの品質確認にデフォルトのモジュールとして使われていました。新たなモジュールは、pam_cracklib
と同じバックエンドを使用します。
pam_pwquality
モジュールは、ルールセットに対してパスワードの強度を確認するために使用されます。確認の手順は 2 段階になります。まず、該当パスワードが辞書にあるかどうかをチェックします。辞書にない場合は、さらにいくつかのチェックを行います。pam_pwquality
は /etc/pam.d/passwd
ファイルの password
コンポーネント内に他の PAM モジュールと並んでいます。ルールのカスタムセットは、/etc/security/pwquality.conf
設定ファイル内で指定されます。これらのチェック項目の完全一覧については、pwquality.conf (8)
man ページを参照してください。
例4.1 pwquality.conf
内でのパスワード強度チェックの設定
pam_quality
の使用を有効にするには、以下の行を /etc/pam.d/passwd
ファイルのpassword
スタックに追加します。
password required pam_pwquality.so retry=3
/etc/security/pwquality.conf
ファイルに追加します。
minlen = 8 minclass = 4
/etc/security/pwquality.conf
に追加します。
maxsequence = 3 maxrepeat = 3
abcd
などの単純なシーケンスの 3 文字を超える文字と、1111
などの 3 文字を超える同一連続文字を含めることができません。
注記
4.1.1.3. パスワードエージングの設定
chage
コマンドを使用します。
重要
chage
コマンドの -M
オプションでは、パスワードが有効となる最長日数を指定します。例えば、ユーザーのパスワードが 90 日間で期限切れとなるように設定するには、以下のコマンドを実行します。
chage
-M 90
username
-M
オプションの後に -1
の値を指定します。
chage
コマンドで使用可能なオプションの詳細情報については、以下の表を参照してください。
表4.1 chage のコマンドラインオプション
オプション | 説明 |
---|---|
-d days | 1970 年 1 月 1 日から最後にパスワードを変更した日までの日数を指定します。 |
-E date | アカウントがロックされる日付を YYYY-MM-DD の形式で指定します。日付の代わりに、 1970 年 1 月 1 日からの日数を指定することも可能です。 |
-I days | パスワードが失効してからアカウントがロックされるまでのアクティブでない日数を指定します。値を 0 とすると、パスワード失効後にアカウントはロックされません。 |
-l | 現在のアカウントエージングの設定を一覧表示します。 |
-m days | パスワード変更が必要となる間隔の最短日数を指定します。値を 0 とすると、パスワードは失効しません。 |
-M days | パスワードの有効最長日数を指定します。このオプションで指定した日数と -d オプションで指定した日数の合計が、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]:
- 初期パスワードを設定します。デフォルトのパスワードを割り当てるには、シェルプロンプトで、
root
権限で以下のコマンドを実行します。passwd
username警告
passwd
ユーティリティーには、null パスワードを設定するオプションがあります。null パスワードの使用は便利ですが、安全性は極めて低くなります。これは、いかなる第三者でも、セキュアでないユーザー名を使用して最初にシステムにログインし、アクセスできるためです。可能な場合は、null パスワードは使用しないでください。null パスワードを使用する必要がある場合は、null パスワードでアカウントのロック解除を行う前に、ユーザーがログインできる状態にあることを常に確かめてください。 - パスワードを直ちに強制的に失効させるには、
root
として以下のコマンドを実行します。chage
-d
0
usernameこのコマンドは、パスワードが最後に変更された日付の値を 1970 年 1 月 1 日に設定します。パスワードエージングのポリシーが設定されていても、この値はパスワードを直ちに強制的に期限切れにします。
4.1.2. アカウントのロック
pam_faillock
PAM モジュールを使うとシステム管理者は特定回数のログイン失敗の後にユーザーアカウントをロックアウトすることができます。ユーザーログインの試行回数を制限する主な目的はセキュリティー措置であり、ユーザーアカウントのパスワード獲得を目的とする総当たり攻撃を防ぐためのものです。
pam_faillock
モジュールを使うと、ログイン失敗はユーザーごとに /var/run/faillock
ディレクトリー内の個別ファイルに保存されます。
注記
even_deny_root
オプションが使用されている場合、この順番が変更されると root
アカウントを含むすべてのユーザーアカウントがロックされます。
- root 以外のユーザーがログインに 3 回失敗した後にロックアウトし、その 10 分後にこのユーザーのロックアウトを解除するようにするには、2 つの行を
/etc/pam.d/system-auth
および/etc/pam.d/password-auth
の各ファイルのauth
セクションに追加します。編集後に、両方のファイルのauth
セクション全体は以下のようになります。1 auth required pam_env.so 2 auth required pam_faillock.so preauth silent audit deny=3 unlock_time=600 3 auth sufficient pam_unix.so nullok try_first_pass 4 auth [default=die] pam_faillock.so authfail audit deny=3 unlock_time=600 5 auth requisite pam_succeed_if.so uid >= 1000 quiet_success 6 auth required pam_deny.so
行番号 2 および 4 が追加されました。 - 以下の行を上記の手順の両ファイルの
account
セクションに追加します。account required pam_faillock.so
- アカウントのロックアウトを root ユーザーにも適用するには、
/etc/pam.d/system-auth
および/etc/pam.d/password-auth
の各ファイルのpam_faillock
エントリーにeven_deny_root
オプションを追加します。auth required pam_faillock.so preauth silent audit deny=3 even_deny_root unlock_time=600 auth sufficient pam_unix.so nullok try_first_pass auth [default=die] pam_faillock.so authfail audit deny=3 even_deny_root unlock_time=600 account required pam_faillock.so
john
がログインに 3 回失敗した後に再度ログインしようとすると、このユーザーのアカウントはこの 4 回目のログイン試行でロックされます。
~]$ su - john
Account locked due to 3 failed logins
su: incorrect password
/etc/pam.d/system-auth
および /etc/pam.d/password-auth
の各ファイルで pam_faillock
が最初に呼び出される行のすぐ上に追加します。また、user1
、user2
、および user3
を実際のユーザー名で置き換えます。
auth [success=1 default=ignore] pam_succeed_if.so user in user1:user2:user3
root
で以下のコマンドを実行します。
~]$ faillock
john:
When Type Source Valid
2013-03-05 11:44:14 TTY pts/0 V
root
で以下のコマンドを実行します。
faillock
--user <username> --reset
重要
cron
ジョブを実行すると、cron
ジョブを実行しているそのユーザーの pam_faillock
の失敗カウンターがリセットされます。したがって、cron
に pam_faillock
を設定しないでください。詳細は「Running cronjobs resets the faillock for the user that is running the cronjob」を参照してください。
authconfig でのカスタム設定の保持
system-auth
および password-auth
の各ファイルは authconfig ユーティリティーからの設定で上書きされます。これを避けるには、設定ファイルの代わりにシンボリックリンクを作成します。このリンクを authconfig が認識し、上書きが避けられます。設定ファイル内のカスタム設定と authconfig を同時に使うには、以下の手順でアカウントロックを設定します。
system-auth
およびpassword-auth
ファイルがすでにsystem-auth-ac
およびpassword-auth-ac
を参照しているシンボリックリンクであるかどうかを確認します (これはシステムデフォルト)。~]#
ls -l /etc/pam.d/{password,system}-auth
出力が以下のような内容である場合、シンボリックリンクは問題なく設定されているため、手順 3 に進むことができます。lrwxrwxrwx. 1 root root 16 24. Feb 09.29 /etc/pam.d/password-auth -> password-auth-ac lrwxrwxrwx. 1 root root 28 24. Feb 09.29 /etc/pam.d/system-auth -> system-auth-ac
system-auth
およびpassword-auth
ファイルがシンボリックリンクでない場合は、次の手順に進んでください。- 設定ファイルの名前を変更します。
~]#
mv /etc/pam.d/system-auth /etc/pam.d/system-auth-ac
~]#mv /etc/pam.d/password-auth /etc/pam.d/password-auth-ac
- カスタマー設定を含む設定ファイルを作成します。
~]#
vi /etc/pam.d/system-auth-local
/etc/pam.d/system-auth-local
ファイルに以下の行を記載します。auth required pam_faillock.so preauth silent audit deny=3 unlock_time=600 auth include system-auth-ac auth [default=die] pam_faillock.so authfail silent audit deny=3 unlock_time=600 account required pam_faillock.so account include system-auth-ac password include system-auth-ac session include system-auth-ac
~]#
vi /etc/pam.d/password-auth-local
/etc/pam.d/password-auth-local
ファイルに以下の行を記載します。auth required pam_faillock.so preauth silent audit deny=3 unlock_time=600 auth include password-auth-ac auth [default=die] pam_faillock.so authfail silent audit deny=3 unlock_time=600 account required pam_faillock.so account include password-auth-ac password include password-auth-ac session include password-auth-ac
- 以下のシンボリックリンクを作成します。
~]#
ln -sf /etc/pam.d/system-auth-local /etc/pam.d/system-auth
~]#ln -sf /etc/pam.d/password-auth-local /etc/pam.d/password-auth
pam_faillock
設定オプションの情報は、man ページの pam_faillock(8) を参照してください。
nullok
オプションの削除
nullok
オプションは、/etc/shadow
ファイルのパスワードフィールドが空の場合に、パスワードを空にしてログインできるようにするもので、デフォルトで有効になっています。nullok
オプションを無効にするには、/etc/pam.d/
ディレクトリーの設定ファイル (/etc/pam.d/system-auth
、/etc/pam.d/password-auth
など) から、文字列 nullok
を削除します。
nullok
option allow users to login without entering a password?」を参照してください。
4.1.3. セッションのロック
注記
4.1.3.1. vlock を使った仮想コンソールのロック
vlock
というユーティリティーを使って実行できます。このユーティリティーをインストールするには、以下のコマンドを root で実行します。
~]# yum install vlock
vlock
コマンドを使えば、コンソールセッションはすべてロックできます。このコマンドでは、アクティブな仮想コンソールをロックしますが、他のセッションへのアクセスは可能です。ワークステーション上のすべての仮想コンソールへのアクセスを防止するには、以下のコマンドを実行します。
vlock
-a
vlock
がアクティブなコンソールをロックし、-a
オプションが他の仮想コンソールへのスイッチを防ぎます。
vlock(1)
を参照してください。
4.1.4. リムーバブルメディアの読み取り専用マウントの強制
udev
ルールを使用してリムーバブルメディアを検出し、blockdev ユーティリティーを使用してリムーバブルメディアを読み取り専用でマウントするよう設定できます。物理メディアの読み取り専用マウントの強制に必要な作業はこれだけです。
blockdev を使用したリムーバブルメディアの読み取り専用マウントの強制
/etc/udev/rules.d/
ディレクトリー内に新しい udev
設定ファイル (80-readonly-removables.rules
など) を以下の内容で作成します。
SUBSYSTEM=="block",ATTRS{removable}=="1",RUN{program}="/sbin/blockdev --setro %N"
udev
ルールにより、blockdev
ユーティリティーを使用して、新しく接続されたすべてのリムーバブルブロック (ストレージ) デバイスが自動的に読み取り専用で設定されます。
新しい udev 設定の適用
udev
ルールを適用する必要があります。udev
サービスは設定ファイルの変更を自動的に検出しますが、新しい設定は既存のデバイスに適用されません。新しく接続されたデバイスのみが新しい設定の影響を受けます。したがって、新しい設定をリムーバブルディスクに適用するには、接続されたすべてのリムーバブルメディアをアンマウントし、取り外す必要があります。
udev
を設定するには、root
で以下のコマンドを実行します。
~#
udevadm trigger
udev
によってすべてのルールを強制的に再適用しても、すでにマウントされているストレージデバイスは影響を受けません。
udev
によってすべてのルールを強制的にリロードするには (何らかの理由で新しいルールが自動的に検出されない場合)、以下のコマンドを使用します。
~#
udevadm control --reload
4.2. Root アクセスの制御
root
ユーザーとして、または sudo
や su
などの setuid プログラムで有効な root
権限を取得して一部のタスクを実行する必要があります。setuid プログラムは、プログラムを実行しているユーザーではなく、プログラムの所有者のユーザー ID (UID) で実行されるプログラムです。これらのプログラムは、以下の例のように、ロング形式のリストの所有者セクションにある s
で示されます。
~]$ ls -l /bin/su
-rwsr-xr-x. 1 root root 34904 Mar 10 2011 /bin/su
注記
s
は大文字または小文字の場合があります。大文字の場合は、基になるパーミッションビットが設定されていないことを示します。
pam_console.so
と呼ばれる PAM モジュールを使うと、再起動やリムーバブルメディアのマウントなど通常は root ユーザーにのみ許可されているアクティビティーを、物理コンソールに最初にログインしたユーザーが実行できるようになります。しかし、ネットワーク設定の変更、新たなマウスの設定、ネットワークデバイスのマウントといったシステム管理者の他の重要なタスクは、管理者権限なしでは実行できません。したがって、システム管理者はネットワーク上のユーザーにどの程度のアクセスを許可するかを判断する必要があります。
4.2.1. Root アクセスの拒否
root
でログインすることに管理者が不安を感じる場合、root パスワードは秘密にし、ランレベル 1 へのアクセスやシングルユーザーモードへのアクセスをブートローダーパスワード保護で拒否してください (このトピックに関する詳細については 「ブートローダーのセキュア化」 を参照)。
root
ログインを拒否できます。
- Root シェルの変更
- ユーザーが直接
root
としてログインしないように、システム管理者は/etc/passwd
ファイルでroot
アカウントのシェルを/sbin/nologin
に設定できます。表4.2 Root シェルの無効化
影響あり 影響なし root
シェルへのアクセスを阻止し、そのようなアクセス試行をログに記録します。以下のプログラムはroot
アカウントにアクセスできません。login
gdm
kdm
xdm
su
ssh
scp
sftp
FTP クライアント、メールクライアント、多くの setuid プログラムなどのシェルを必要としないプログラム。以下のプログラムはroot
アカウントにアクセスできません。sudo
- FTP クライアント
- Email クライアント
- どのコンソールデバイス (tty) からの root アクセスも無効にする
root
アカウントへのアクセスをさらに制限するために、管理者は/etc/securetty
ファイルを編集して、コンソールでのroot
ログインを無効にできます。このファイルには、root
ユーザーがログイン可能なすべてのデバイスが一覧表示されます。このファイル自体がない場合、root
ユーザーはシステム上のどんな通信デバイス (コンソールか raw ネットワークインターフェースかに関係なく) からでもログインできます。この状態は危険です。ユーザーは Telnet 経由でroot
としてマシンにログインでき、プレーンテキストのパスワードがネットワーク上で送信されてしまうからです。デフォルトでは、Red Hat Enterprise Linux 7 の/etc/securetty
ファイルでは、root
ユーザが物理的に接続されたコンソールからログインすることだけを許可しています。root
ユーザーによるログインを防ぐには、root
でシェルプロンプトから以下のコマンドを入力して、このファイルの内容を削除します。echo > /etc/securetty
KDM、GDM、XDM のログインマネージャーでのsecuretty
サポートを有効にするには、以下の行を追加します。auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so
追加対象のファイルは以下のとおりです。/etc/pam.d/gdm
/etc/pam.d/gdm-autologin
/etc/pam.d/gdm-fingerprint
/etc/pam.d/gdm-password
/etc/pam.d/gdm-smartcard
/etc/pam.d/kdm
/etc/pam.d/kdm-np
/etc/pam.d/xdm
警告
/etc/securetty
ファイルを空白にしても、root
ユーザーがリモートでツールの OpenSSH スイートを使用してログインすることは止められません。これは、認証が終わるまでコンソールが開かれないためです。表4.3 Root ログインの無効化
影響あり 影響なし コンソールまたはネットワーク経由でのroot
アカウントへのアクセスを阻止します。以下のプログラムはroot
アカウントにアクセスできません。login
gdm
kdm
xdm
- tty を開くその他のネットワークサービス
root
としてログインしないが、setuid または別のメカニズムで管理タスクを実行するプログラム。以下のプログラムはroot
アカウントにアクセスできません。su
sudo
ssh
scp
sftp
- Root SSH ログインを無効にする
- SSH プロトコル経由での
root
ログインを防ぐには、SSH デーモンの設定ファイルである/etc/ssh/sshd_config
を編集し、#PermitRootLogin yes
の行を以下のように変更します。PermitRootLogin no
表4.4 Root SSH ログインの無効化
影響あり 影響なし ツールの OpenSSH スイート経由でのroot
アクセスを防ぎます。以下のプログラムはroot
アカウントにアクセスできません。ssh
scp
sftp
ツールの OpenSSH スイートの一部ではないプログラム - PAM を使用してサービスへの root アクセスを制限する
- PAM (
/lib/security/pam_listfile.so
モジュール経由) を使用すると、特定アカウントを柔軟に拒否できます。管理者はこのモジュールを使用してログインが許可されないユーザーリストを参照できます。システムサービスへのroot
アクセスを制限するには、/etc/pam.d/
ディレクトリー内の対象サービスのファイルを編集し、認証にpam_listfile.so
モジュールが必要となるようにします。以下の例では、/etc/pam.d/vsftpd
PAM 設定ファイルのvsftpd
FTP サーバーにこのモジュールを使用しています (一行目の末にある\
の文字は、ディレクティブが一行の場合は必要ありません)。auth required /lib/security/pam_listfile.so item=user \ sense=deny file=/etc/vsftpd.ftpusers onerr=succeed
これにより、PAM が/etc/vsftpd.ftpusers
ファイルを見て、リストに載っているユーザーにサービスへのアクセスを拒否するように指示します。管理者はこのファイル名を変更し、各サービスごとに別個のリストを維持したり、複数サービスへのアクセスを拒否する集中リストを使用したりすることができます。管理者が複数サービスへのアクセスを拒否したい場合、メールクライアントでは/etc/pam.d/pop
や/etc/pam.d/imap
ファイルに、SSH クライアントでは/etc/pam.d/ssh
ファイルのような PAM 設定ファイルに同様の行を追加することができます。PAM についての詳細情報は、『The Linux-PAM System Administrator's Guide』 を参照してください。/usr/share/doc/pam-<version>/html/
ディレクトリーにあります。表4.5 PAM を使った root の無効化
影響あり 影響なし PAM 対応のネットワークサービスへのroot
アクセスを防ぎます。以下のサービスはroot
アカウントにアクセスできません。login
gdm
kdm
xdm
ssh
scp
sftp
- FTP クライアント
- Email クライアント
- すべての PAM 対応サービス
PAM 非対応のプログラムおよびサービス
4.2.2. Root アクセスの許可
root
アクセスを許可することは問題ではありません。ユーザーに root
アクセスを許可すれば、デバイスの追加やネットワークインターフェースの設定などの重要性の低いアクティビティーを個別のユーザーが行うことができるので、システム管理者はネットワークセキュリティーや他の重要な問題に専念できます。
root
アクセスを許可すると、以下のような問題が発生することがあります。
- マシンの誤った設定 —
root
アクセスを持つユーザーは自身のマシンを間違って設定する可能性があり、この問題を解決するには助けを必要とします。ひどい場合には、知らないうちにセキュリティーホールを開いてしまう可能性もあります。 - 安全でないサービスの実行 —
root
アクセスを持つユーザーは、FTP や Telnet といった安全でないサービスを自身のマシン上で実行して、ユーザー名やパスワードを危険にさらす可能性があります。これらのサービスは、ユーザー名やパスワードをプレーンテキストでネットワーク上で送信します。 - Email の添付ファイルを root として実行 — 滅多にないことですが、Linux に影響を及ぼす Email ウイルスも存在します。悪意のあるプログラムは、
root
ユーザーとして実行された場合に脅威となります。 - 監査証跡がそのままになる — 多くの場合、
root
アカウントは複数のユーザーが共有し、複数のシステム管理者がシステムのメインテナンスをできるようになっているため、ある時点でこのうちのどのユーザーがroot
だったかを見分けることは不可能です。別のログインを使用すると、ユーザーがログインしたアカウントとセッション追跡目的の一意の番号がタスク構造に組み込まれ、ユーザーが開始する各プロセスによって継承されます。同時ログインを使用すると、一意の番号は特定ログインのアクションの追跡に使用できます。アクションが監査イベントを生成する際には、ログインアカウントとその一意の番号に関連付けられているセッションとともに記録されます。これらのログインとセッションを表示するには、aulast
コマンドを使用します。aulast
コマンドの--proof
オプションを使うと、特定のセッションで生成された監査可能なイベントを切り離す特定のausearch
クエリーの提示が可能になります。監査システムの詳細については、6章システム監査を参照してください。
4.2.3. Root アクセスの制限
root
ユーザーへのアクセスを完全に拒否するのではなく、su
や sudo
となどの setuid プログラム経由でのアクセスのみを許可したい場合もあります。su
および sudo
の詳細は、Red Hat Enterprise Linux 7 システム管理者のガイドの章 権限の取得 と、man ページの su(1)
および sudo(8)
を参照してください。
4.2.4. 自動ログアウトの有効化
root
としてログインしている場合に、このセッションを無人状態にしておくと、重大なセキュリティーリスクをもたらす恐れがあります。このリスクを軽減するために、一定期間が経過してからアイドル状態のユーザーを自動的にログアウトするようにシステムを設定することができます。
root
として/etc/profile
ファイルの先頭に以下の行を追加して、このファイルの処理が中断されないようにします。trap "" 1 2 3 15
root
として、/etc/profile
ファイルに以下の行を挿入して、120 秒後に自動的にログアウトされるようにします。export TMOUT=120 readonly TMOUT
TMOUT
変数は、指定した期間 (秒) に活動がない場合にはシェルを中断します (上記の例では120
)。特定のインストールのニーズに応じて時間制限を変更してください。
4.2.5. ブートローダーのセキュア化
- シングルユーザーモードへのアクセスを防ぐ — 攻撃者がシングルユーザーモードでシステムを起動できると、攻撃者は
root
パスワードを求められずに自動的にroot
としてログインします。警告
/etc/sysconfig/init
ファイルでSINGLE
パラメーターを編集してシングルユーザーモードへのアクセスを保護する方法は推奨されません。攻撃者は、GRUB 2 のカーネルコマンドライン上で (init=
を使用して) カスタム初期コマンドを特定することでパスワードを迂回できます。Red Hat Enterprise Linux 7 システム管理者のガイドの パスワードによる GRUB 2 の保護 の章にあるように、GRUB 2 ブートローダーをパスワードで保護することが推奨されます。 - GRUB 2 コンソールへのアクセスを防ぐ — マシンがブートローダーに GRUB 2 を使用している場合、攻撃者は GRUB 2 エディターインターフェースを使って設定を変更したり、
cat
コマンドを使用して情報収集ができるようになります。 - 安全でないオペレーティングシステムへのアクセスを防ぐ — デュアルブートシステムの場合、攻撃者はアクセス制御やファイルパーミッションを無視する (例えば、DOS などの) OS を起動時に選択できます。
4.2.5.1. インタラクティブスタートアップの無効化
root
として /etc/sysconfig/init
ファイルの PROMPT
パラメーターを以下のように無効にします。
PROMPT=no
4.2.6. ハードリンクおよびシンボリックリンクの保護
- ユーザーがリンク先のファイルを所有します。
- ユーザーがリンク先のファイルへの読み取りアクセスおよび書き込みアクセスをすでに持っています。
- シンボリックリンクを実行するプロセスはシンボリックリンクの所有者です。
- ディレクトリーの所有者はシンボリックリンクの所有者と同じです。
/usr/lib/sysctl.d/50-default.conf
ファイルの以下のオプションで制御されます。
fs.protected_hardlinks = 1 fs.protected_symlinks = 1
51-no-protect-links.conf
などの名前の新しい設定ファイルを以下の内容で /etc/sysctl.d/
ディレクトリーに作成します。
fs.protected_hardlinks = 0 fs.protected_symlinks = 0
注記
.conf
にし、デフォルトのシステムファイルの後にその設定ファイルを読み取る必要があります (ファイルは辞書の順序で読み取られるため、ファイル名の最初の番号が大きいファイルに含まれる設定が優先されます)。
sysctl
メカニズムを使用した起動時のカーネルパラメーターの設定に関する詳細は、man ページの sysctl.d(5) を参照してください。
4.3. サービスのセキュア化
4.3.1. サービスへのリスク
- サービス拒否攻撃 (DoS) — サービス拒否攻撃は、サービスに対して要求を大量に送信することでシステムがすべての要求をログ記録・応答しようとし、使用不可能になります。
- 分散型サービス拒否攻撃 (DDoS) — これは DoS 攻撃の一種で、複数の脆弱なマシンを使用し (通常、数千以上)、サービスに対して一斉攻撃を仕掛けます。大量の要求が送信され、サービスを使用不可能にしてしまいます。
- スクリプトの脆弱性への攻撃 — Web サーバーが通常行うように、サーバー全体のアクションにサーバーがスクリプトを使用している場合、攻撃者は誤って書かれたスクリプトを狙うことができます。このスクリプトの脆弱性に対する攻撃により、バッファがオーバーフロー状態になるか、攻撃者がシステム上のファイルを変更できる可能性があります。
- バッファーオーバーフロー攻撃 — ポート 1〜1023 でリッスンするサービスを起動するには、管理権限を使用するか、
CAP_NET_BIND_SERVICE
機能を設定する必要があります。プロセスがポートにバインドされ、そのポートでリッスンしている場合は、権限または機能が破棄されることがよくあります。権限または機能が破棄されず、アプリケーションに利用可能なバッファーオーバーフローがある場合、攻撃者はデーモンを実行中のユーザーとしてシステムにアクセスすることができます。利用可能なバッファーオーバーフローが存在するため、クラッカーは自動ツールを使って脆弱性のあるシステムを特定でき、アクセスを確保した後に自動ルートキットを使ってシステムへのアクセスを維持します。
注記
重要
4.3.2. サービスの特定および設定
cups
— Red Hat Enterprise Linux 7 のデフォルトのプリントサーバーcups-lpd
— 代替プリントサーバーxinetd
—gssftp
やtelnet
などの下位サーバーへの接続を管理するスーパーサーバーsshd
— Telnet の安全な代替となる OpenSSH サーバー
cups
を無効にします。同じことは portreserve
についても言えます。NFSv3 ボリュームをマウントしていなかったり、NIS (ypbind
サービス) を使用しないのであれば、rpcbind
を無効にすべきです。ブート時にどのネットワークサービスが開始可能になっているかを確認するだけでは、十分ではありません。どのポートがオープンでリッスンしているかを確認することが推奨されます。詳細情報は、「リッスンしているポートの確認」 を参照してください。
4.3.3. 安全でないサービス
- 暗号化されていないネットワークでユーザー名やパスワードを送信する — Telnet や FTP など多くの古いプロトコルは認証セッションを暗号化しないので、できるだけ避けてください。
- 暗号化されていないネットワークで機密性の高いデータを送信する — Telnet や FTP、HTTP、SMTP など多くのプロトコルでは暗号化されていないネットワークでデータを送信します。また、NFS や SMB などの多くのネットワークファイルシステムでも暗号化されていないネットワークで情報を送信します。これらのプロトコルを使用する際に送信するデータの種類を制限することは、ユーザーの責任になります。
rlogin
、rsh
、telnet
、vsftpd
などがあります。
rlogin
、rsh
、telnet
) はすべて避けて、SSH
を使用するようにしてください。sshd
に関する詳細については、「SSH のセキュア化」を参照してください。
FTP
は、システムのセキュリティーにとってリモートシェルほど危険ではありませんが、問題を回避するには FTP
サーバーを慎重に設定し、監視する必要があります。FTP
サーバーのセキュア化に関する詳細については、「FTP のセキュア化」を参照してください。
auth
nfs-server
smb
およびnbm
(Samba)yppasswdd
ypserv
ypxfrd
4.3.4. rpcbind のセキュア化
rpcbind
サービスは、NIS やNFS などの RPC サービス用の動的なポート割り当てデーモンです。この認証メカニズムは脆弱なもので、制御対象のサービスに幅広いポートを割り当てる機能があります。このため、セキュア化は困難になります。
注記
rpcbind
を必要としなくなったので、portmap のセキュア化が影響するのは NFSv2 と NFSv3 のみです。NFSv2 もしくは NFSv3 サーバーの導入を計画する場合は、rpcbind
が必要となり、以下のセクションが適用されます。
4.3.4.1. TCP Wrapper による rpcbind の保護
rpcbind
サービスにアクセスするネットワークやホストを制限することが重要です。
4.3.4.2. firewalld による rpcbind の保護
rpcbind
サービスへのアクセスをさらに制限するには、サーバーに firewalld
ルールを追加し、特定ネットワークへのアクセスを制限するとよいでしょう。
firewalld
リッチ言語コマンドの 2 つの例です。最初のコマンドは 192.168.0.0/24 ネットワークからポート 111 (rpcbind
サービスが使用) への TCP 接続を許可します。2 つ目のコマンドは、ローカルホストからの同一ポートへの接続を許可します。他のパケットはすべて遮断されます。
~]#firewall-cmd --add-rich-rule='rule family="ipv4" port port="111" protocol="tcp" source address="192.168.0.0/24" invert="True" drop'
~]#firewall-cmd --add-rich-rule='rule family="ipv4" port port="111" protocol="tcp" source address="127.0.0.1" accept'
~]# firewall-cmd --add-rich-rule='rule family="ipv4" port port="111" protocol="udp" source address="192.168.0.0/24" invert="True" drop'
注記
4.3.5. rpc.mountd のセキュア化
rpc.mountd
デーモンは、NFS バージョン 2 (『RFC 1904』) と NFS バージョン 3 (『RFC 1813』) で使用されているプロトコルである NFS MOUNT プロトコルのサーバーサイドを実装します。
4.3.5.1. TCP Wrappers による rpc.mountd の保護
rpc.mountd
には認証が組み込まれていないため、TCP Wrapper を使用して rpc.mountd
サービスにアクセスするネットワークやホストを制限することが重要です。
IP
アドレス のみ を使用してください。ホスト名は DNS
ポイズニングやその他の方法で改ざんできるため、使用しないでください。
4.3.5.2. firewalld による rpc.mountd の保護
rpc.mountd
サービスへのアクセスをさらに制限するには、サーバーに firewalld
リッチ言語ルールを追加し、特定のネットワークへのアクセスを制限します。
firewalld
リッチ言語コマンドの 2 つの例です。最初のコマンドでは、192.168.0.0/24
ネットワークからの mountd
接続を許可します。2 つ目のコマンドでは、ローカルホストからの mountd
接続を許可します。他のパケットはすべて遮断されます。
~]#firewall-cmd --add-rich-rule 'rule family="ipv4" source NOT address="192.168.0.0/24" service name="mountd" drop'
~]#firewall-cmd --add-rich-rule 'rule family="ipv4" source address="127.0.0.1" service name="mountd" accept'
注記
4.3.6. NIS のセキュア化
ypserv
と呼ばれる RPC サービスの一つで、rpcbind
および他の関連サービスと一緒に使用することで、ドメイン内にあると主張するすべてのコンピューターに、ユーザー名、パスワード、その他の機密性のある情報のマップを配布します。
/usr/sbin/rpc.yppasswdd
—yppasswdd
サービスとも呼ばれます。このデーモンを使用することで、ユーザーは NIS パスワードを変更できます。/usr/sbin/rpc.ypxfrd
—ypxfrd
サービスとも呼ばれます。このデーモンは、ネットワーク上での NIS マップ転送を担当します。/usr/sbin/ypserv
— これは NIS サーバーデーモンです。
rpcbind
サービスのセキュア化を図ることが推奨されます。その後に、以下のようなネットワークプラニングの問題などに対処してください。
4.3.6.1. ネットワークの注意深いプラニング
4.3.6.2. パスワードのような NIS ドメイン名およびホスト名を使用する
/etc/passwd
マップを公開します。
ypcat
-d
<NIS_domain>-h
<DNS_hostname>passwd
/etc/shadow
ファイルを入手することが可能です。
ypcat
-d
<NIS_domain>-h
<DNS_hostname>shadow
注記
/etc/shadow
ファイルは NIS マップ内に保存されません。
o7hfawtgmhwg.domain.com
) にします。同様に、異なる ランダムな NIS ドメイン名を作成します。これにより、攻撃者は NIS サーバーへのアクセスが非常に困難になります。
4.3.6.3. /var/yp/securenets
ファイルを編集する
/var/yp/securenets
ファイルが空白もしくは存在しない場合 (デフォルトインストールの後の場合のように)、NIS はすべてのネットワークをリッスンします。最初にすることのひとつは、ネットマスクとネットワークのペアをファイルに置くことで、これにより ypserv
は適正なネットワークからの要求のみに応答するようになります。
/var/yp/securenets
ファイルからのエントリのサンプルです。
255.255.255.0 192.168.0.0
警告
/var/yp/securenets
ファイルを作成せずに NIS サーバーを初回起動することは、絶対にしないでください。
4.3.6.4. 静的ポートの割り当てとリッチ言語ルールの使用
rpc.yppasswdd
を除いて特定のポートの割り当てが可能です。このデーモンを使うと、ユーザーは自身のログインパスワードを変更できるようになります。rpc.ypxfrd
と ypserv
の 2 つの NIS サーバーデーモンにポートを割り当てると、NIS サーバーデーモンをさらに侵入者から保護するためのファイアウォールルールが作成できます。
/etc/sysconfig/network
に追加します。
YPSERV_ARGS="-p 834" YPXFRD_ARGS="-p 835"
firewalld
ルールを使用して、これらのポートでサーバーがリッスンするネットワークを強制できます。
~]#firewall-cmd --add-rich-rule='rule family="ipv4" source address="192.168.0.0/24" invert="True" port port="834-835" protocol="tcp" drop'
~]#firewall-cmd --add-rich-rule='rule family="ipv4" source address="192.168.0.0/24" invert="True" port port="834-835" protocol="udp" drop'
192.168.0.0/24
ネットワークからの要求であれば、サーバーはポート 834 および 835 への接続のみを許可することになります。最初のルールは TCP
のもので、2 つ目は UDP
になります。
注記
4.3.6.5. Kerberos 認証を使用する
/etc/shadow
マップからのパスワードハッシュがネットワーク上で送信されるということです。侵入者が NIS ドメインへアクセスしてネットワークトラフィックを傍受した場合、ユーザー名とパスワードハッシュを取得できることになります。さらに時間があれば、攻撃者はパスワードクラッキングプログラムで脆弱なパスワードを推測し、ネットワーク上の有効なアカウントへのアクセスを取得できるようになります。
4.3.7. NFS のセキュア化
重要
RPCSEC_GSS
カーネルモジュールの一部として Kerberos ユーザーおよびグループ認証をサポートしています。Red Hat Enterprise Linux 7 では rpcbind
を使用する NFSv3 がサポートされているので、rpcbind
に関する情報も引き続き含まれています。
4.3.7.1. ネットワークの注意深いプラニング
4.3.7.2. NFS マウントオプションのセキュア化
/etc/fstab
ファイル内での mount
コマンド使用については、Red Hat Enterprise Linux 7 ストレージ管理ガイドの mount コマンドの使い方 の章で説明されています。セクション管理の観点からは、NFS マウントオプションは /etc/nfsmount.conf
でも指定可能であることは注目に値します。これを使うと、カスタムのデフォルトオプションを設定することが可能です。
4.3.7.2.1. NFS サーバーのレビュー
警告
exports(5)
man ページのサブツリーチェックのセクションを参照)。
ro
オプションを使用してファイルシステムを読み取り専用としてエクスポートしてください。rw
オプションの使用は、明確に必要な場合のみとしてください。詳細は exports(5)
man ページを参照してください。書き込みアクセスを許可すると、シンボリックリンク攻撃などのリスクが高まります。これには、/tmp
や /usr/tmp
などの一時ディレクトリーが含まれます。
rw
オプションでマウントする必要がある場合は、リスク低減のためにできる限り全ユーザー書き込み可能としないようにします。アプリケーションのなかにはパスワードをクリアテキストで保存したり暗号化が弱いものもあるので、ホームディレクトリーのエクスポートもリスクとみなされます。このリスクは、アプリケーションコードがレビューされ、改善されることで軽減されてきています。SSH キーにパスワードを設定しないユーザーもいるので、ホームディレクトリーがリスクをもたらすことになります。パスワードや Kerberos の使用を強制することで、このリスクは緩和されます。
showmount -e
コマンドを使用して、サーバーが何をエクスポートしているかを確認します。特に必要でないものはエクスポートしないでください。
no_root_squash
オプションは使用しないでください。また、既存のインストールのレビューを行い、これが使用されていないことを確認してください。詳細は 「no_root_squash オプションは使用しないでください」 を参照してください。
secure
オプションはサーバー側のエクスポートオプションで、「予約済み」 ポートへのエクスポートを制限する際に使用します。デフォルトでは、サーバーは 「予約済み」 ポート (ポート番号 1024 未満のもの) からのクライアント通信のみを許可します。これは、クライアントが通常これらのポートの使用を許可するのは 「信頼できる」 コード (カーネル内の NFS クライアントなど) のみだったためです。しかし、多くのネットワークではクライアント上で root になるのは難しいことではないので、予約済みポートからの通信が権限を伴うものであると仮定するのは安全ではありません。このため、予約済みポートへの制限は限定的な価値しかありません。Kerberos やファイアウォール、エクスポートを特定のクライアントに制限するという方法を信頼する方がより安全です。
4.3.7.2.2. NFS クライアントのレビュー
nosuid
オプションを使用します。nosuid
オプションは set-user-identifier
または set-group-identifier
ビットを無効にします。これにより、リモートユーザーが setuid プログラムを実行してより高い権限を取得することを防ぎます。このオプションは、クライアントおよびサーバー側で使用してください。
noexec
オプションはクライアント上のすべての実行可能ファイルを無効にします。共有しているファイルシステムにあるファイルをユーザーが不注意で実行しないようにこのオプションを使用します。nosuid
および noexec
オプションは、ほとんどのファイルシステムの標準オプションです。
nodev
オプションを使うと、クライアントが 「device-files」 をハードウェアデバイスとして処理することを防ぎます。
resvport
オプションはクライアント側のマウントオプションで、secure
はこれに対応するサーバー側のエクスポートオプションです (上記の説明を参照)。これは「予約済みポート」への通信を制限します。予約済みまたは「よく知られた」ポートは、root ユーザーなどの権限のあるユーザーやプロセス用に確保されています。このオプションを設定すると、クライアントが予約済みソースのポートを使ってサーバーと通信するようになります。
sec=krb5
krb5i
を、プライバシー保護には krb5p
を使用して Kerberos によるマウントをサポートします。これらは sec=krb5
でのマウント時に使用されますが、NFS サーバー上での設定が必要です。詳細はエクスポートに関する man ページ (man 5 exports
) を参照してください。
man 5 nfs
) には 「SECURITY CONSIDERATIONS」 セクションがあり、ここでは NFSv4 のセキュリティー強化の説明と NFS の特定のマウントオプションすべてが含まれています。
重要
4.3.7.3. 構文エラーに注意
/etc/exports
ファイルを参照して、エクスポートするファイルシステムとこれらのディレクトリーをエクスポートするホストを決定します。このファイルを編集する際は、無関係な領域を追加しないように注意してください。
/etc/exports
ファイル内の以下の行は読み取り/書き込みパーミッションでディレクトリー /tmp/nfs/
をホスト bob.example.com
と共有します。
/tmp/nfs/ bob.example.com(rw)
/etc/exports
ファイルは同じディレクトリーを読み取り専用パーミッションでホスト bob.example.com
と共有し、ホスト名の後ろに一文字分の空白があるため、読み取り/書き込みパーミッションで 外部 と共有します。
/tmp/nfs/ bob.example.com (rw)
showmount
コマンドを使って何が共有されているかを検証するのは、設定済み NFS 共有をチェックするよい方法です。
showmount
-e
<hostname>
4.3.7.4. no_root_squash オプションは使用しないでください
nfsnobody
ユーザーに変更します。これにより、root で作成された全ファイルの所有者は nfsnobody
に変更されます。この変更で setuid ビットが設定されたプログラムのアップロードが防止されます。
no_root_squash
を使用すると、リモートの root ユーザーは共有ファイルシステム上のどのファイルも変更できるようになり、トロイの木馬に感染したアプリケーションを他のユーザーが間違って実行できる状態にしてしまいます。
4.3.7.5. NFS ファイアウォールの設定
NFSv3 用のポート設定
rpcbind
サービスが動的に割り当てますが、ファイアウォールルールの作成時に問題を起こす恐れがあります。このプロセスを簡素化するには、/etc/sysconfig/nfs ファイルで、使用するポートを特定します。
MOUNTD_PORT
- mountd (rpc.mountd) 用の TCP ポートおよび UDP ポートSTATD_PORT
- status (rpc.statd) 用の TCP ポートおよび UDP ポート
/etc/modprobe.d/lockd.conf
ファイルの NFS ロックマネージャー (nlockmgr) に対して TCP ポートおよび UDP ポートを設定します。
nlm_tcpport
- nlockmgr (rpc.lockd) の TCP ポートnlm_udpport
- nlockmgr (rpc.lockd) の UDP ポート
/etc/modprobe.d/lockd.conf
を参照してください。
rpcinfo -p
コマンドを実行し、どのポートと RPC プログラムが使用されているかを確認します。
4.3.7.6. Red Hat identity Management でのセキュアな NFS
4.3.8. HTTP サーバーのセキュリティー保護
4.3.8.1. Apache HTTP サーバーのセキュリティー保護
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
モジュールを削除することが有益です。これを行うには、/etc/httpd/conf.modules.d
ディレクトリーで設定ファイルを変更します。たとえば、プロキシーモジュールを削除するためには、以下のコマンドを実行します。
echo '# All proxy modules disabled' > /etc/httpd/conf.modules.d/00-proxy.conf
/etc/httpd/conf.d/
ディレクトリーにもモジュールの読み込みに使われる設定ファイルが含まれていることに注意してください。
httpd および SELinux
4.3.8.2. NGINX のセキュリティー保護
server
セクションで行います。
バージョン文字列の無効化
server_tokens off;
nginx
だけが報告されます。
$ curl -sI http://localhost | grep Server Server: nginx
追加のセキュリティー関連ヘッダーの追加
add_header X-Frame-Options SAMEORIGIN;
- このオプションは、クリックジャック攻撃を効果的に軽減する、NGINX が処理するコンテンツを構成するドメイン外のページを拒否します。add_header X-Content-Type-Options nosniff;
- このオプションは、特定の古いブラウザーでの MIME タイプのスニッフィングを防ぎます。add_header X-XSS-Protection "1; mode=block";
- このオプションは、XSS (Cross-Site Scripting) フィルタリングを有効にします。これにより、NGINX の応答に潜在的に悪意のあるコンテンツをブラウザーが表示しないようにします。
潜在的に有害なHTTPメソッドの無効化
# Allow GET, PUT, POST; return "405 Method Not Allowed" for all others. if ( $request_method !~ ^(GET|PUT|POST)$ ) { return 405; }
SSL の設定
4.3.9. FTP のセキュア化
- Red Hat Content Accelerator (
tux
) — FTP 機能のあるカーネル空間の Web サーバーです。 vsftpd
— スタンドアロンでセキュリティー重視の FTP サービス実装です。
vsftpd
FTP サービス設定のためのものです。
4.3.9.1. FTP グリーティングバナー
vsftpd
のグリーティングバナーを変更するには、以下のディレクティブを /etc/vsftpd/vsftpd.conf
ファイルに追加します。
ftpd_banner=<insert_greeting_here>
/etc/banners/
という新規ディレクトリーにすべてのバナーを格納します。この例では、FTP 接続のバナーファイルは、/etc/banners/ftp.msg
となります。以下はこのファイルのサンプルになります。
######### Hello, all activity on ftp.example.com is logged. #########
注記
220
で始める必要はありません。
vsftpd
でこのバナーを参照するようにするには、以下のディレクティブを /etc/vsftpd/vsftpd.conf
ファイルに追加します。
banner_file=/etc/banners/ftp.msg
4.3.9.2. 匿名のアクセス
/var/ftp/
ディレクトリーが存在すると、匿名アカウントがアクティベートされます。
vsftpd
パッケージをインストールすることです。このパッケージは、匿名ユーザー向けのディレクトリーツリーを確立し、匿名ユーザーによる読み取り専用のパーミッションをディレクトリーに設定します。
警告
4.3.9.2.1. 匿名のアップロード
/var/ftp/pub/
内に書き込み専用のディレクトリーを作成することが推奨されます。これを行うには、以下のコマンドを root で実行します。
~]# mkdir /var/ftp/pub/upload
~]# chmod 730 /var/ftp/pub/upload
~]# ls -ld /var/ftp/pub/upload
drwx-wx---. 2 root ftp 4096 Nov 14 22:57 /var/ftp/pub/upload
vsftpd
で、以下の行を /etc/vsftpd/vsftpd.conf
ファイルに追加します。
anon_upload_enable=YES
4.3.9.3. ユーザーアカウント
vsftpd
のすべてのユーザーアカウントを無効にするには、以下のディレクティブを /etc/vsftpd/vsftpd.conf
に追加します。
local_enable=NO
4.3.9.3.1. ユーザーアカウントの制限
sudo
権限を持つユーザーなど、特定のアカウントや特定のアカウントグループの FTP アクセスを無効にする最も簡単な方法は、「Root アクセスの拒否」 にあるように PAM リストファイルを使用することです。vsftpd
の PAM 設定ファイルは、/etc/pam.d/vsftpd
です。
vsftpd
で特定のユーザーアカウントを無効にするには、ユーザー名を /etc/vsftpd/ftpusers
に追加します。
4.3.9.4. TCP Wrapper を使用してアクセスを制御する
4.3.10. Postfix のセキュア化
4.3.10.1. サービス拒否攻撃を制限する
/etc/postfix/main.cf
ファイル内のディレクティブに制限を設定すると、このような攻撃の有効性が制限されます。既存のディレクティブの値を変更するか、以下の形式で希望する値の必要なディレクティブを追加することもできます。
<directive> = <value>サービス拒否攻撃の制限に使用できるディレクティブを以下に示します。
smtpd_client_connection_rate_limit
— 一定の時間単位内 (下記を参照) にクライアントが当該サーバーに接続を試みることができる最大回数。デフォルト値は 0 で、この場合クライアントは Postfix が受付可能な回数内で時間単位当たり何回でも接続を試みることができます。デフォルトでは、信頼できるネットワーク内のクライアントは除外されます。anvil_rate_time_unit
— この時間単位は割合制限の計算に使用されます。デフォルト値は 60 秒です。smtpd_client_event_limit_exceptions
— 接続および割合制限のコマンドから除外されるクライアントです。デフォルトでは、信頼できるネットワーク内のクライアントは除外されます。smtpd_client_message_rate_limit
— 時間単位内でクライアントが要求可能な最大メッセージ配信数です (Postfix が実際にこの数のメッセージを受け付けるかどうかは別問題です)。default_process_limit
— あるサービスを提供する Postfix の子プロセスの最大デフォルト数です。この制限は、master.cf
ファイル内の特定サービスによって無効にされる場合があります。デフォルト値は 100 です。queue_minfree
— メール受信に必要なキューファイルシステム内での空き領域の最低バイト数です。これは現在、Postfix SMTP サーバーがメールを受信するかどうかを判断するために使用しています。デフォルトでは、Postfix SMTP サーバーは、空き領域が message_size_limit の 1.5 倍未満であればMAIL FROM
コマンドを拒否します。空き領域の最低限度をより大きくするように指定するには、queue_minfree の値が少なくとも message_size_limit の 1.5 倍になるように指定します。デフォルトの queue_minfree 値は 0 です。header_size_limit
— メッセージヘッダー保存に使用するメモリの最大バイト数です。ヘッダーサイズがこの制限を超える場合は、超過分が廃棄されます。デフォルト値は 102400 です。message_size_limit
— メッセージの最大バイト数で、これにはエンベロープ情報も含まれます。デフォルト値は 10240000 です。
4.3.10.2. NFS と Postfix
/var/spool/postfix/
を NFS 共有ボリュームに配置しないでください。NFSv2 と NFSv3 ではユーザー ID とグループ ID の制御を維持しないので、2 人以上のユーザーが同一 UID を持つ可能性があり、それぞれがお互いのメールを受信、閲覧してしまう可能性があります。
注記
SECRPC_GSS
カーネルモジュールが UID ベースの認証を使用しないためです。ただし、それでも NFS 共有ボリュームにメールスプールディレクトリーを 置かない 方がよいと考えられます。
4.3.10.3. メール専用ユーザー
/etc/passwd
ファイル内のすべてのユーザーシェルを /sbin/nologin
に設定します (root ユーザーは例外とする場合もある)。
4.3.10.4. Postfix ネットワークリスニングの無効化
/etc/postfix/main.cf
ファイルを表示すると確認できます。
/etc/postfix/main.cf
ファイルを閲覧して、以下の inet_interfaces
行のみが表示されることを確認してください。
inet_interfaces = localhost
inet_interfaces = all
と設定します。
4.3.10.5. Postfix が SASL を使用する設定
SASL
実装を使用できます。SMTP 認証は、Simple Mail Transfer Protocol
の拡張機能です。これを有効にすると、SMTP
クライアントはサーバーとクライアントとの両方でサポートされ、受け入れられている認証方法を使って SMTP
サーバーを認証しなくてはなりません。本セクションでは、Dovecot SASL
実装を利用するように Postfix を設定する方法を説明します。
POP
/IMAP
サーバーをインストールして、Dovecot SASL
実装を使用するシステム上で利用可能とするには、root
で以下のコマンドを実行します。
~]# yum install dovecot
SMTP
サーバーは、UNIX ドメインソケット か TCP ソケット のいずれかを使って Dovecot SASL
実装と通信します。後者の方法は、Postfix と Dovecot アプリケーションが別個のマシンで実行中の場合にのみ、必要となります。UNIX ドメインソケットの方がよりすぐれたプライバシーを提供するので、本ガイドではこちらを推奨しています。
SASL
実装を使用するように指示するには、両方のアプリケーションで多くの設定変更が必要になります。以下の手順にしたがってください。
Dovecot のセットアップ
- Dovecot のメインの設定ファイルである
/etc/dovecot/conf.d/10-master.conf
に以下の行を含めます (デフォルトの設定ファイルには、ほとんどの関連セクションがすでに記載されており、これらの行はコメント解除するだけです)。service auth { unix_listener /var/spool/postfix/private/auth { mode = 0660 user = postfix group = postfix } }
上記の例では、Postfix と Dovecot の通信に UNIX ドメインソケットを使用することを仮定しています。また、PostfixSMTP
サーバーの設定はデフォルトとしています。この設定では、メールキューが/var/spool/postfix/
ディレクトリーに配置され、アプリケーションはpostfix
のユーザーおよびグループで実行されることになります。この方法では、読み取りおよび書き込み許可は、postfix
ユーザーおよびグループに限定されます。別の方法では、以下の設定を使用すると Dovecot はTCP
経由で Postfix 認証要求をリッスンするようになります。service auth { inet_listener { port = 12345 } }
上記の例では、12345
を、実際に使用するポート番号に置き換えます。 /etc/dovecot/conf.d/10-auth.conf
設定ファイルを編集して、Dovecot が PostfixSMTP
サーバーにplain
およびlogin
の認証メカニズムを提供するようにします。auth_mechanisms = plain login
Postfix のセットアップ
/etc/postfix/main.cf
を修正するだけです。以下の設定ディレクティブを追加もしくは編集します。
- Postfix
SMTP
サーバーの SMTP 認証を有効にします。smtpd_sasl_auth_enable = yes
- Postfix が SMTP 認証に Dovecot
SASL
実装を使用するように指示します。smtpd_sasl_type = dovecot
- Postfix キューディレクトリーの認証相対パスを提供します (相対パスを使用することで、Postfix サーバーが chroot で稼働しているかどうかにかかわらず、この設定が確実に機能するようになります)。
smtpd_sasl_path = private/auth
この手順では、Postfix と Dovecot 間の通信に UNIX ドメインソケットを使用することを前提します。通信にTCP
ソケットを使用する場合で、Postfix が別のマシンにある Dovecot を探すように設定するには、以下のような設定値を使用します。smtpd_sasl_path = inet:127.0.0.1:12345
上記の例では、127.0.0.1
を Dovecot マシンのIP
アドレスに、12345
を Dovecot の/etc/dovecot/conf.d/10-master.conf
設定ファイルで指定されているポート番号に置き換えます。 - Postfix
SMTP
サーバーがクライアントに対して利用可能とするSASL
メカニズムを指定します。暗号化セッションと非暗号化セッションでは、異なるメカニズムを設定できることに注意してください。smtpd_sasl_security_options = noanonymous, noplaintext smtpd_sasl_tls_security_options = noanonymous
上記の例では、非暗号化セッション中は匿名認証が許可されず、暗号化されていないユーザー名やパスワードを送信するメカニズムも許可されません。(TLS
を使用した) 暗号化セッションでは、匿名でない認証メカニズムのみが許可されます。許可されるSASL
メカニズムを制限する対応ポリシー全一覧は、http://www.postfix.org/SASL_README.html#smtpd_sasl_security_options を参照してください。
関連情報
SASL
による Postfix SMTP 認証の設定に便利な追加情報が提供されています。
- http://wiki2.dovecot.org/HowTo/PostfixAndDovecotSASL — SMTP 認証に Dovecot
SASL
実装を使用するための Postfix の設定方法が説明されています。 - http://www.postfix.org/SASL_README.html#server_sasl — SMTP 認証に Dovecot または Cyrus
SASL
実装を使用するための Postfix の設定方法が説明されています。
4.3.11. SSH のセキュア化
SSH
上の送信は暗号化され、傍受から保護されます。暗号化ログインを使用して、従来のユーザー名とパスワードよりも優れた認証方法を提供することもできます。SSH
プロトコルと Red Hat Enterprise Linux 7 における SSH
サービスの使用方法についての一般的な情報は、Red Hat Enterprise Linux 7 システム管理者のガイドの OpenSSH の章を参照してください。
重要
SSH
設定のセキュア化における最も一般的な方法にフォーカスしてきました。ただし、ここで提案された方法が網羅的または決定的であるというわけではありません。sshd
デーモンの動作修正に利用可能な設定ディレクティブすべてについての説明は sshd_config(5)
の man ページを、基本的な SSH
の概念については ssh(1)
の man ページを参照してください。
4.3.11.1. 暗号化ログイン
SSH
は、コンピューターにログインするための暗号化鍵の使用をサポートしています。これはパスワードのみの使用よりもはるかに安全です。この方法を他の認証方法と組み合わせると、マルチファクター認証 (multifactor authentication) と見なすことができます。マルチ認証方法についての詳細は、「複数の認証方法」 を参照してください。
/etc/ssh/sshd_config
ファイルの PubkeyAuthentication
設定ディレクティブを yes
に設定する必要があります。これがデフォルト設定であることに注意してください。PasswordAuthentication
ディレクティブを no
に設定すると、ログインでのパスワード使用が無効になります。
SSH
鍵は ssh-keygen
コマンドを使用して生成できます。引数なしでこれを実行すると、2048 ビットの RSA 鍵のセットが作成されます。デフォルトでは、この鍵は ~/.ssh/
ディレクトリーに保存されます。-b
スイッチを使用すると、鍵のビット強度を修正できます。通常は、2048 ビット鍵で十分な強度が提供されます。鍵のペアの生成に関する詳細情報は、『Red Hat Enterprise Linux 7 システム管理者のガイド』の 「OpenSSH の設定」の章を参照してください。
~/.ssh/
ディレクトリーに、2 つの鍵が見つかるはずです。ssh-keygen
コマンドの実行時にデフォルトを受け入れると、生成されるファイル名は id_rsa
と id_rsa.pub
になり、それぞれに秘密鍵と公開鍵が含まれます。秘密鍵はファイルの所有者のみが読み取り可能として、公開されないように常に保護してください。ただし公開鍵は、ログインするシステムに送信する必要があります。ssh-copy-id
コマンドを使用すると、サーバーにこの鍵を移動することができます。
~]$ ssh-copy-id -i [user@]server
~/.ssh/authorized_keys
ファイルに公開鍵が自動的に追加されます。このファイルは、ユーザーがサーバーへのログインを試みる際に sshd
デーモンによってチェックされます。
SSH
鍵は定期的に変更する必要があります。その際、authorized_keys
ファイルから使用されていない鍵を必ず削除してください。
4.3.11.2. 複数の認証方法
/etc/ssh/sshd_config
ファイル内の AuthenticationMethods
設定ディレクティブを使用します。このディレクティブでは、必要となる認証方式の複数のリストを定義できることに注意してください。複数を定義する場合は、各方式を少なくとも 1 つのリストで定義する必要があります。各リストは空白で区切ります。リスト内の各認証方式の名前はコンマ区切りとします。例を示します。
AuthenticationMethods publickey,gssapi-with-mic publickey,keyboard-interactive
AuthenticationMethods
ディレクティブを使って設定された sshd
デーモンは、ユーザーが publickey
認証の後に gssapi-with-mic
または keyboard-interactive
認証でログインを完了した場合にのみ、アクセスを許可します。必要とされる認証方式はそれぞれ、/etc/ssh/sshd_config
ファイル内の対応する設定ディレクティブ (PubkeyAuthentication
など) で明示的に有効となっている必要があることに注意してください。利用可能な認証方式の全般的なリストは、ssh(1)
man ページの 『AUTHENTICATION』 セクションを参照してください。
4.3.11.3. SSH の他のセキュア化
プロトコルのバージョン
SSH
プロトコルは、SSH クライアントに対しては SSH-1 と SSH-2 の両バージョンを引き続ぎサポートしますが、可能な場合は常に後者のみを使用してください。SSH-2 バージョンには、旧式の SSH-1 の多くの改善点が含まれており、高度な設定オプションの多くは SSH-2 でのみ使用可能となっています。
SSH
プロトコルによる認証と対象となる通信の保護を最大限まで活用するために、SSH-2 を使用することを推奨します。sshd
デーモンがサポートするプロトコルのバージョンは、/etc/ssh/sshd_config
ファイル内で Protocol
設定ディレクティブを使用して指定できます。デフォルト設定は 2
になります。SSH-2 バージョンは、Red Hat Enterprise Linux 7 の SSH サーバーでサポートされる唯一のバージョンであることに注意してください。
鍵のタイプ
ssh-keygen
コマンドはデフォルトで SSH-2 RSA 鍵のペアを生成しますが、-t
オプションを使うと、DSA または ECDSA 鍵を生成するように指示することもできます。ECDSA (Elliptic Curve Digital Signature Algorithm) は、同じ対称鍵の長さでより優れたパフォーマンスを提供します。また、より短い鍵も生成します。
デフォルト以外のポート
sshd
デーモンは TCP ポート 22
をリッスンします。ポートを変更すると、自動ネットワークスキャンに基づく攻撃に対するシステムの露出が減り、セキュリティーが強化されます。ポートは、/etc/ssh/sshd_config
設定ファイルの Port
ディレクティブで指定できます。デフォルト以外のポート使用を可能にするには、デフォルトの SELinux ポリシーの変更も必要になることに注意してください。これは、root
で以下のコマンドを実行して ssh_port_t
SELinux タイプを修正することで可能になります。
~]# semanage -a -t ssh_port_t -p tcp port_number
Port
ディレクティブで指定する新たなポート番号に置き換えます。
Root 以外のログイン
root
ユーザーとしてのログインが必要ない場合は、/etc/ssh/sshd_config
ファイルで PermitRootLogin
設定ディレクティブを no
に設定することを検討してください。root
ユーザーとしてのログインの可能性をなくすことで、どのユーザーが通常のユーザーとしてログインした後に root
権限を獲得し、権限のあるコマンドを実行したかを管理者が監査できるようになります。
X セキュリティー拡張機能の使用
/etc/ssh/ssh_config
ファイルの ForwardX11Trusted
オプションが yes
に設定されています。ssh -X remote_machine
(信頼されていないホスト) コマンドおよび ssh -Y remote_machine
(信頼されているホスト) コマンドには違いがありません。
警告
4.3.12. PostgreSQL のセキュリティー確保
postgresql-server
パッケージが提供します。インストールされていない場合は、以下のコマンドを root ユーザーとして実行してインストールしてください。
~]# yum install postgresql-server
-D
オプションで指定することができます。以下に例を示します。
~]$ initdb -D
/home/postgresql/db1
initdb
コマンドでは、ディレクトリーが存在しない場合にはそのディレクトリーの作成が試行されます。今回の例では、/home/postgresql/db1 という名前を使用します。/home/postgresql/db1 ディレクトリーには、データベースに保存するデータすべてと、クライアント認証の設定ファイルが含まれます。
~]$cat
pg_hba.conf
# PostgreSQL Client Authentication Configuration File # This file controls: which hosts are allowed to connect, how clients # are authenticated, which PostgreSQL user names they can use, which # databases they can access. Records take one of these forms: # # local DATABASE USER METHOD [OPTIONS] # host DATABASE USER ADDRESS METHOD [OPTIONS] # hostssl DATABASE USER ADDRESS METHOD [OPTIONS] # hostnossl DATABASE USER ADDRESS METHOD [OPTIONS]
pg_hba.conf
ファイルに以下の行を追加すると、認証済みのローカルユーザーが自分のユーザー名を使用してどのデータベースにもアクセスできるようになります。
local all all trust
pg_hba.conf
ファイルからこの行を削除してください。
4.3.13. Docker のセキュリティー確保
4.3.14. DDoS 攻撃に対する memcached の保護
memcached の脆弱性
memcached の強化
- LAN にファイアウォールを設定してください。memcached サーバーへのアクセスをローカルネットワークに制限する必要がある場合は、memcached で使用されるポートへの外部トラフィックを許可しないでください。たとえば、デフォルトで memcached が使用するポート 11211 を、許可ポートのリストから削除します。
~]#
firewall-cmd --remove-port=11211/udp
~]#firewall-cmd --runtime-to-permanent
firewalld
コマンドを使用して、特性の IP 範囲でポート 11211 を使用できるようにする方法は「ゾーンを使用し、ソースに従って着信トラフィックの管理」を参照してください。 - クライアントで実際にこのプロトコルが必要な場合を除いて、
/etc/sysconfig/memcached
ファイルのOPTIONS
変数に-U 0 -p 11211
を追加して UDP を無効にします。OPTIONS="-U 0 -p 11211"
- アプリケーションと同じマシン上で memcached サーバーを 1 台のみ使用している場合は、localhost トラフィックのみをリッスンするように memcached を設定してください。
/etc/sysconfig/memcached
のOPTIONS
に-l 127.0.0.1,::1
を追加します。OPTIONS="-l 127.0.0.1,::1"
- 認証を変更することが可能な場合は、SASL (Simple Authentication and Security Layer) 認証を有効にします。
/etc/sasl2/memcached.conf
ファイルで、以下のように修正または追加します。sasldb_path: /path.to/memcached.sasldb
- SASL データベースにアカウントを追加します。
~]#
saslpasswd2 -a memcached -c cacheuser -f /path.to/memcached.sasldb
- データベースが memcached ユーザーおよびグループからアクセス可能であることを確認してください。
~]#
chown memcached:memcached /path.to/memcached.sasldb
/etc/sysconfig/memcached
のOPTIONS
に-S
を追加して、memcached で SASL サポートを有効にします。OPTIONS="-S"
- memcached サーバーを再起動して、変更を適用します。
- SASL データベースに作成したユーザー名とパスワードを、アプリケーションの memcached クライアント構成に追加します。
- memcached のクライアントとサーバーとの間の通信を stunnel で暗号化します。memcached は TLS をサポートしていないため、回避策として、memcached プロトコル上で TLS を提供する、stunnel などのプロキシーを使用します。stunnel を、PSK (Pre Shared Keys) を使用するように設定することも、ユーザー証明書を使用するように設定することもできます。証明書を使用すると、認証されたユーザーだけが memcached サーバーにアクセスでき、トラフィックは暗号化されます。
重要
トンネルを使用して memcached にアクセスする場合は、サービスが localhost のみをリッスンしているか、ファイアウォールによってネットワークから memcached ポートへのアクセスが妨げられていることを確認してください。詳細は「stunnel の使用」を参照してください。
4.4. ネットワークアクセスのセキュア化
4.4.1. TCP Wrapperおよび xinetd によるサービスのセキュア化
4.4.1.1. TCP Wrapper と接続バナー
banner
オプションを使用します。
vsftpd
にバナーを導入します。最初にバナーファイルを作成します。これはシステム上のどこでも構いませんが、デーモンと同じ名前にする必要があります。たとえば、ファイル名 /etc/banners/vsftpd
には以下の行が含まれます。
220-Hello, %c 220-All activity on ftp.example.com is logged. 220-Inappropriate use will result in your access privileges being removed.
%c
トークンは、ユーザー名およびホスト名、またはユーザー名および IP アドレスなどの幅広いクライアント情報を提供し、接続をより脅威的なものにします。
/etc/hosts.allow
ファイルに追加します。
vsftpd : ALL : banners /etc/banners/
4.4.1.2. TCP Wrapper と攻撃警告
spawn
ディレクティブを使ってそのホストまたはネットワークからのその後の攻撃について管理者に警告することができます。
/etc/hosts.deny
ファイルに以下の行を挿入すると、そのネットワークからの接続の試みが拒否され、特別ファイルにログ記録されます。
ALL : 206.182.68.0 : spawn /bin/echo `date` %c %d >> /var/log/intruder_alert
%d
トークンは、攻撃者がアクセスを試みるサービス名を提供します。
spawn
ディレクティブを /etc/hosts.allow
ファイル内に置きます。
注記
spawn
ディレクティブはどんなシェルコマンドも実行するので、特定のクライアントがサーバーに接続しようとする際に、管理者に通知したり一連のコマンドを実行したりする特別スクリプトを作成するとよいでしょう。
4.4.1.3. TCP Wrapper とロギングの強化
severity
オプションを使うと該当サービスに対するログレベルを高めることができます。
info
の代わりに emerg
フラグをログファイルに置いて接続を拒否します。
/etc/hosts.deny
に挿入します。
in.telnetd : ALL : severity emerg
authpriv
ロギング機能を使用しますが、優先順位をデフォルト値の info
から emerg
に引き上げ、ログメッセージを直接コンソールに投稿します。
4.4.2. リッスンしているポートの確認
開いているポートスキャンに対する netstat 使用
root
で以下のコマンドを実行し、ネットワークから接続をリッスンするポートを確認します。
~]# netstat -pan -A inet,inet6 | grep -v ESTABLISHED
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 1/systemd
tcp 0 0 192.168.124.1:53 0.0.0.0:* LISTEN 1829/dnsmasq
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1176/sshd
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 1177/cupsd
tcp6 0 0 :::111 :::* LISTEN 1/systemd
tcp6 0 0 ::1:25 :::* LISTEN 1664/master
sctp 0.0.0.0:2500 LISTEN 20985/sctp_darn
udp 0 0 192.168.124.1:53 0.0.0.0:* 1829/dnsmasq
udp 0 0 0.0.0.0:67 0.0.0.0:* 977/dhclient
...
netstat
コマンドの -l
オプションを使用して、リッスンしているサーバーのみを表示します。
~]# netstat -tlnw
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
tcp 0 0 192.168.124.1:53 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN
tcp6 0 0 :::111 :::* LISTEN
tcp6 0 0 :::22 :::* LISTEN
tcp6 0 0 ::1:631 :::* LISTEN
tcp6 0 0 ::1:25 :::* LISTEN
raw6 0 0 :::58 :::* 7
開いているポートスキャンに対する ss の使用
~]# ss -tlw
etid State Recv-Q Send-Q Local Address:Port Peer Address:Port
udp UNCONN 0 0 :::ipv6-icmp :::*
tcp LISTEN 0 128 *:sunrpc *:*
tcp LISTEN 0 5 192.168.124.1:domain *:*
tcp LISTEN 0 128 *:ssh *:*
tcp LISTEN 0 128 127.0.0.1:ipp *:*
tcp LISTEN 0 100 127.0.0.1:smtp *:*
tcp LISTEN 0 128 :::sunrpc :::*
tcp LISTEN 0 128 :::ssh :::*
tcp LISTEN 0 128 ::1:ipp :::*
tcp LISTEN 0 100 ::1:smtp :::*
~]# ss -plno -A tcp,udp,sctp
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
udp UNCONN 0 0 192.168.124.1:53 *:* users:(("dnsmasq",pid=1829,fd=5))
udp UNCONN 0 0 *%virbr0:67 *:* users:(("dnsmasq",pid=1829,fd=3))
udp UNCONN 0 0 *:68 *:* users:(("dhclient",pid=977,fd=6))
...
tcp LISTEN 0 5 192.168.124.1:53 *:* users:(("dnsmasq",pid=1829,fd=6))
tcp LISTEN 0 128 *:22 *:* users:(("sshd",pid=1176,fd=3))
tcp LISTEN 0 128 127.0.0.1:631 *:* users:(("cupsd",pid=1177,fd=12))
tcp LISTEN 0 100 127.0.0.1:25 *:* users:(("master",pid=1664,fd=13))
...
sctp LISTEN 0 5 *:2500 *:* users:(("sctp_darn",pid=20985,fd=3))
UNCONN
は、UDP をリッスンしているモードでポートを表示します。
-6
オプションを使用します。
~]# nmap -sT -O 192.168.122.65
Starting Nmap 6.40 ( http://nmap.org ) at 2017-03-27 09:30 CEST
Nmap scan report for 192.168.122.65
Host is up (0.00032s latency).
Not shown: 998 closed ports
PORT STATE SERVICE
22/tcp open ssh
111/tcp open rpcbind
Device type: general purpose
Running: Linux 3.X
OS CPE: cpe:/o:linux:linux_kernel:3
OS details: Linux 3.7 - 3.9
Network Distance: 0 hops
OS detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 1.79 seconds
(-sS)
がオプションでない場合に、TCP SYN スキャン (-sT)
はデフォルトの TCP スキャンのタイプとなります。-O
オプションは、ホストのオペレーティングシステムを検出します。
netstat および ss を使用して、SCTP のオープンポートに対してスキャン
root
で以下のコマンドを実行します。
~]# netstat -plnS
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
sctp 127.0.0.1:250 LISTEN 4125/sctp_darn
sctp 0 0 127.0.0.1:260 127.0.0.1:250 CLOSE 4250/sctp_darn
sctp 0 0 127.0.0.1:250 127.0.0.1:260 LISTEN 4125/sctp_darn
~]# netstat -nl -A inet,inet6 | grep 2500
sctp 0.0.0.0:2500 LISTEN
~]# ss -an | grep 2500
sctp LISTEN 0 5 *:2500 *:*
4.4.3. ソースルーティングの無効化
accept_source_route
オプションを使用すると、ネットワークインターフェースが 厳密なソースルーティング (SSR) もしくは 緩やかなソースルーティング (LSR) オプションセットのあるパケットを受け付けるようになります。ソースルーティングパケットの許可は sysctl 設定で制御します。以下のコマンドを root で実行し、SSR または LSR オプションセットのあるパケットを遮断します。
~]# /sbin/sysctl -w net.ipv4.conf.all.accept_source_route=0
~]# /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
~]# /sbin/sysctl -w net.ipv4.conf.all.accept_redirects=0
~]# /sbin/sysctl -w net.ipv6.conf.all.accept_redirects=0
~]# /sbin/sysctl -w net.ipv4.conf.all.secure_redirects=0
~]# /sbin/sysctl -w net.ipv4.conf.all.send_redirects=0
重要
0
に設定します。新しいインターフェースを追加するたびに、ICMP リクエストの送信を自動的に無効にするには、以下のコマンドを実行します。
~]# /sbin/sysctl -w net.ipv4.conf.default.send_redirects=0
注記
/etc/sysctl.conf
ファイルを修正します。たとえば、すべてのインターフェースで IPv4 ICMP リダイレクトパケットの許可を無効にするには、root
権限でエディターを実行して /etc/sysctl.conf
ファイルを開きます。追加する行は net.ipv4.conf.all.send_redirects=0のようになります。
sysctl(8)
を参照してください。ソースベースのルーティングおよびそのバリエーションに関連するインターネットオプションの説明については、RFC791 を参照してください。
警告
4.4.3.1. 逆方向パス転送
IP
アドレスをスプーフィングすることを防ぎ、DDoS 攻撃の機会を減らすためです。
注記
警告
-
rp_filter
- 逆方向パス転送は
rp_filter
ディレクティブで有効にします。sysctl
ユーティリティーを使用すると、稼働中のシステムに変更を加えることができます。永続的な変更は、/etc/sysctl.conf
ファイルに行を追加して行えます。rp_filter
オプションは、カーネルが 3 つのいずれかのモードから選択することを指示するために使用されます。一時的なグローバル変更を行うには、root
で以下のコマンドを入力します。sysctl -w net.ipv4.conf.default.rp_filter=integer sysctl -w net.ipv4.conf.all.rp_filter=integer
ここで、integer は、以下のいずれかになります。0
— ソース確認なし1
— RFC 3704 で定義された厳密なモード。2
— RFC 3704 で定義された緩慢なモード。
この設定は、以下のようにnet.ipv4.conf.interface.rp_filter
コマンドを使用してネットワークインターフェースごとに上書きできます。sysctl -w net.ipv4.conf.interface.rp_filter=integer
注記
これらの設定を再起動しても保持するには、/etc/sysctl.conf
ファイルを変更します。たとえば、すべてのインターフェースのモードを変更するには、root
ユーザーとして実行しているエディターで/etc/sysctl.conf
ファイルを開き、以下のような行を追加します。net.ipv4.conf.all.rp_filter=2
-
IPv6_rpfilter
IPv6
プロトコルの場合は、firewalld デーモンはデフォルトで逆方向パス転送が適用されます。この設定は、/etc/firewalld/firewalld.conf
ファイルで確認できます。IPv6_rpfilter
オプションを設定すると firewalld の動作を変更することができます。逆方向パス転送のカスタム設定が必要な場合には、ip6tables -t raw -I PREROUTING -m rpfilter --invert -j DROP
のようにip6tables
コマンドを使用することで firewalld なし で実行できます。このルールは、すべてのトラフィックに適用されるように、特にステートフルの一致ルールの前で raw/PREROUTING チェーンの開始部分の近くに挿入する必要があります。iptables
およびip6tables
サービスに関する詳しい情報は「iptables
を使用して IP セットの設定および制御」を参照してください。
パケット転送の有効化
root
でログインし、/etc/sysctl.conf
ファイルの net.ipv4.ip_forward = 0
を読み込む行を以下のように設定します。
net.ipv4.ip_forward = 1
/etc/sysctl.conf
ファイルから変更をロードするには、以下のコマンドを実行します。
/sbin/sysctl -p
root
で以下のコマンドを実行します。
/sbin/sysctl net.ipv4.ip_forward
1
を返す場合は、IP 転送が有効になっています。0
を返す場合は、以下のコマンドを実行して手動で有効にできます。
/sbin/sysctl -w net.ipv4.ip_forward=1
4.4.3.2. その他のリソース
- インストール済みドキュメンテーション
/usr/share/doc/kernel-doc-version/Documentation/networking/ip-sysctl.txt
- このファイルには、このディレクトリーで使用可能なファイルおよびオプションの完全な一覧が含まれています。初めてカーネルドキュメンテーションにアクセスする場合は、root
で以下のコマンドを実行します。~]#
yum install kernel-doc
- オンラインドキュメンテーションIngress Filtering for Multihomed Networks の説明については、RFC 3704 を参照してください。
4.5. DNSSEC を使った DNS トラフィックのセキュア化
4.5.1. DNSSEC の概要
DNS
クライアントが DNS
ネームサーバーからの応答の整合性を認証、検査して、応答元を検証し、転送中に不正に変更されなかったかどうかを判別できるようにします。
4.5.2. DNSSEC について
HTTPS
を使った安全な接続機能を提供しています。しかし、IP アドレスを直接入力していなければ、HTTPS
ウェブサーバーに接続する前に DNS
ルックアップが実行される必要があります。この DNS
ルックアップは安全に実行されず、認証がないことから 中間者攻撃の対象となります。つまり、ある DNS
ネームサーバーから送信されたようにみえる応答が本物で、不正に変更されていないことに DNS
クライアントは確信を持てません。さらに重要なのは、再帰問い合わせネームサーバーは、他のネームサーバーから得られる記録が本物かどうかを判断できません。DNS
プロトコルは、クライアントが中間者攻撃の対象とならないようなメカニズムを提供していませんでした。DNSSEC は、DNS
を使用したドメインネームを解決する際の認証および完全性のチェックの欠如に対処するために導入されました。DNSSEC は、機密性の問題には対処しません。
DNS
リソース記録のデジタル署名と、DNS
リゾルバーが信頼の階層チェーンを構築できる方法での公開鍵の配布が行われます。すべての DNS
リソースレコードのデジタル署名は、デジタル署名のリソース記録 (RRSIG) として生成され、ゾーンに追加されます。ゾーンの公開鍵は、DNSKEY リソースレコードとして追加されます。階層チェーンを構築するために、DNSKEY のハッシュが Delegation of Signing (DS) リソースレコードとして親ゾーンに公開されます。存在しない証拠を活用するため、NextSECure (NSEC) および NSEC3 リソースレコードが使用されます。DNSSEC 署名ゾーンでは、各 リソースレコードセット (RRset) に対応する RRSIG リソースレコードがあります。子ゾーンへの委任用に使用されるレコード (NS および glue レコード) には署名されないことに注意してください。それらのレコードは子ゾーンに表示され、そこで署名されます。
.com
の DS レコードを署名しているとします。root ゾーンは .com
ネームサーバーの NS および glue レコードも処理します。リゾルバーはこの委任を追いかけ、これらの委任されたネームサーバーを使用して .com
の DNSKEY レコードを問い合わせます。獲得された DNSKEY レコードのハッシュは、root ゾーンの DS レコードとマッチするはずです。マッチする場合、リゾルバーは獲得された .com
の DNSKEY を信頼します。.com
ゾーンでは、RRSIG レコードは .com
DNSKEY が作成します。このプロセスは、redhat.com
などの .com
内の委任で同様に繰り返されます。この方法を使用することで、検証を行う DNS
リゾルバーは 1 つの root 鍵での設定のみが必要で、多くの DNSKEY を通常の操作中に世界中から収集します。暗号検査が失敗すると、リゾルバーはアプリケーションに SERVFAIL を返します。
DNS
応答を検出するとアプリケーションに SERVFAIL エラーを返します。DNSSEC は、DNS
サーバー間 (権威と再帰) でデータの整合性を保護しますが、アプリケーションとリゾルバー間のセキュリティーは提供しません。このため、アプリケーションにリゾルバーへの安全なトランスポートが提供されることが重要になります。一番簡単な方法は、DNSSEC 対応リゾルバーを localhost
上で稼働して /etc/resolv.conf
内の 127.0.0.1
を使用することです。代わりに、リモートの DNS
サーバーに VPN 接続することもできます。
ホットスポットの問題について
DNS
を乗っ取る傾向があります。VPN に接続するユーザーは、企業ネットワークの外に存在しないリソースを見つけるために、「内部のみ」の DNS
サーバーを使用することがよくあります。これには、ソフトウェアによる追加処理が必要になります。たとえば、dnssec-trigger を使って、ホットスポットが DNS
クエリーを乗っ取っているかを検出し、unbound
は プロキシネームサーバーとして DNSSEC クエリーを処理するように動作することが可能です。
DNSSEC 対応のリカーシブリゾルバー
unbound
を使用することができます。両方ともデフォルトで DNSSEC を有効にし、DNSSEC root キーで設定されています。サーバー上で DNSSEC を有効にするにはどちらでも可能ですが、ノートパソコンなどのモバイルデバイスでは、unbound
が推奨されます。これは、dnssec-trigger 使用時にはホットスポット、Libreswan 使用時には VPN に必要となる DNSSEC 上書きの再構成をローカルユーザーが動的に行えるようになるためです。unbound
デーモンはさらに、etc/unbound/*.d/
ディレクトリーにリスト化されている DNSSEC 例外の実装もサポートします。これは、サーバーとモバイルデバイスの両方で役立ちます。
4.5.3. Dnssec-trigger について
unbound
が/etc/resolv.conf
にインストールされ設定ができたら、アプリケーションからのすべての DNS
クエリーは unbound
によって処理されます。dnssec-trigger が unbound
リゾルバーを再構成するのは、そうするようにトリガーされた場合のみです。これは主に、異なる Wi-Fi ネットワークに接続するノートパソコンのような、ローミングを行うクライアントマシンに当てはまります。プロセスは以下のようになります。
- 新規
DNS
サーバーがDHCP
経由で獲得されると、NetworkManager が dnssec-trigger を「開始」します。 - Dnssec-trigger がサーバーに対して多くのテストを実行し、サーバーが DNSSEC を適切にサポートしているかどうかを判断します。
- サポートしている場合は、dnssec-trigger が
unbound
を再構成して、そのDNS
サーバーをすべてのクエリーに対するフォワーダーとして使用します。 - テストが失敗した場合は、dnssec-trigger は新規
DNS
サーバーを無視して利用可能なフォールバックの方法をいくつか試行します。 - 無制限ポート 53 (
UDP
およびTCP
) が利用可能だと判断されたら、フォワーダーを使用せずにunbound
が完全なリカーシブDNS
サーバーになるように指示します。 - たとえば、ポート 53 が ネットワークの
DNS
サーバー自体以外にはファイアウォールでブロックされているなどしてこれが可能でない場合は、ポート 80 へはDNS
を、ポート 443 へはTLS
カプセル化されたDNS
の使用を試みます。ポート 80 および 443 でDNS
を稼働しているサーバーは、/etc/dnssec-trigger/dnssec-trigger.conf
で設定できます。デフォルトの設定ファイルでは、コメントアウトされた例が利用可能になっています。 - これらのフォールバックの方法も失敗する場合は、dnssec-trigger は DNSSEC を完全に迂回してセキュアでない状態で機能するか、「cache only」 モードで実行します。後者の場合、新規の
DNS
クエリーは試行されませんが、キャッシュにすでにあるものについてはすべて応答します。
dnssec-trigger
デーモンは 10 分ごとに DNSSEC リゾルバーをプローブし続けます。dnssec-trigger グラフィカルユーティリティーの使用に関する情報は、「Dnssec-trigger の使用」 を参照してください。
4.5.4. VPN が提供されるドメインサーバーおよびネームサーバー
unbound
、dnssec-trigger、および NetworkManager の組み合わせは、VPN ソフトウェアが提供するドメインとネームサーバーを適切にサポートできるということです。VPN トンネルができれば、ローカルの unbound
キャッシュは、受け取られたドメインネームのエントリーについてフラッシュされるので、そのドメインネーム内のネームに関するクエリーは VPN 経由で届いた内部ネームサーバーから新たにフェッチされます。VPN トンネルが終了すると、unbound
キャッシュが再度フラッシュされ、ドメインへのクエリーが以前に獲得されたプライベート IP アドレスではなく、公開 IP アドレスを返すようにします。詳細は 「接続によって提供されるドメイン用の DNSSEC 検証の設定」 を参照してください。
4.5.5. 推奨される命名プラクティス
host.example.com
のように DNS
内のマシンに使用されている 完全修飾ドメインネーム (FQDN) に合致することを推奨しています。
。yourcompany
など)をパブリックレジスタに追加することがあります。したがって、Red&Hatは、プライベートネットワーク上でも、自分に委任されていないドメイン名を使用しないことを強くお勧めします。これは、ネットワーク構成によってドメイン名の解決方法が異なる可能性があるためです。その結果、ネットワークリソースが利用できなくなる可能性があります。自分に委任されていないドメイン名を使用すると、DNSSEC検証を有効にするためにドメイン名の衝突に手動の設定が必要になるため、DNSSECの展開と維持がより困難になります。この問題の詳細については、ドメイン名の衝突に関するICANNのよくある質問を参照してください。ICANN (The Internet Corporation for Assigned Names and Numbers) は、(.yourcompany
などの) トップレベルの未登録ドメインを公開登録簿に追加することがあります。このため、Red Hat では、プライベートネットワーク上であっても委任されていないドメイン名を使用しないことを強く推奨しています。これは、ネットワーク設定によっては異なる解決をしてしまうドメインネームになってしまう可能性があるからです。その結果、ネットワークリソースは利用不可能になってしまいます。また、委任されていないドメイン名を使うと、DNSSEC の実装および維持がより困難になります。これは、ドメインネームが競合すると DNSSEC 検証に手動の設定が必要となるからです。この問題に関する詳細情報は、「Name Collision Resources and Information」を参照してください。
4.5.6. トラストアンカーについて
DNS
ネームとそのネームに関連づけられた公開鍵 (または公開鍵のハッシュ) で構成されます。ベース 64 のエンコード化された鍵として表示されます。これは、DNS
レコードの検証と認証に使用可能な公開鍵を含む情報の交換方法という意味で、証明書と同様のものになります。RFC 4033 では、設定済みの DNSKEY RR または DNSKEY RR の DS RR ハッシュとしてトラストアンカーを定義しています。有効なセキュリティー対応のリゾルバーは、この公開鍵またはハッシュを、署名済みの DNS の応答に対して認証チェーンを構築するための開始点として使用します。一般的に、有効なリゾルバーはトラストアンカーの初期値をセキュアまたは信頼できる手段で DNS プロトコルの外部から取得する必要があります。トラストアンカーがあると、リゾルバーは、トラストアンカーが指定するゾーンは署名されているはずとの扱いをすると意味合いがあります。
4.5.7. DNSSEC のインストール
4.5.7.1. unbound のインストール
DNS
を検証するためには、DNS
リゾルバー unbound
(または bind
) をインストールする必要があります。モバイルデバイスでは、dnssec-trigger のインストールのみが必要です。サーバーには unbound
で十分ですが、サーバーの場所 (LAN もしくはインターネット) によってはローカルドメイン用の転送設定が必要となる場合もあります。dnssec-trigger は現在、グローバルの公開 DNS ゾーンのみで機能します。NetworkManager、dhclient、および VPN アプリケーションは自動でドメイン一覧 (およびネームサーバー一覧も) を収集することが多くありますが、dnssec-trigger や unbound ではこれは行われません。
unbound
をインストールするには、root
ユーザーで以下のコマンドを実行します。
~]# yum install unbound
4.5.7.2. unbound の稼働確認
unbound
デーモンが稼働しているかどうかを確認するには、以下のコマンドを実行します。
~]$ systemctl status unbound
unbound.service - Unbound recursive Domain Name Server
Loaded: loaded (/usr/lib/systemd/system/unbound.service; disabled)
Active: active (running) since Wed 2013-03-13 01:19:30 CET; 6h ago
unbound
サービスが稼働していないと systemctl status
コマンドは unbound
を Active: inactive (dead)
とレポートします。
4.5.7.3. unbound の起動
unbound
デーモンを起動するには、root
ユーザーで以下のコマンドを実行します。
~]# systemctl start unbound
systemctl enable
コマンドを実行すると unbound
がシステム起動時に毎回起動します。
~]# systemctl enable unbound
unbound
デーモンは、以下のディレクトリーを使用してローカルデータの設定または上書きを可能にします。
/etc/unbound/conf.d
ディレクトリーは、特定のドメインネーム用の設定追加に使用されます。ドメインネームのクエリーを特定のDNS
サーバーにリダイレクトするために使用されます。企業 WAN 内にのみ存在するサブドメインに多く使用されます。/etc/unbound/keys.d
ディレクトリーは、特定のドメインネーム用のトラストアンカーの追加に使用されます。これは、内部のみのネームが DNSSEC 署名されているものの、トラストのパスを構築するための DS レコードが公開で存在しない場合に必要になります。別のユースケースは、企業 WAN 外で公開で入手可能なネームではない別の DNSKEY を使って署名された、内部バージョンのドメインの場合になります。/etc/unbound/local.d
ディレクトリーは、ローカルで優先させる特定のDNS
データを追加するために使用されます。このデータを使用すると、ブラックリストを構築したり、手動で特定の DNS を優先させたりできます。このデータはunbound
によってクライアントに返されますが、DNSSEC 署名としてマークされません。
unbound.conf(5)
man ページを参照してください。
4.5.7.4. Dnssec-trigger のインストール
dnssec-triggerd
デーモンとして稼働します。dnssec-trigger をインストールするには、root
ユーザーで以下のコマンドを実行します。
~]# yum install dnssec-trigger
4.5.7.5. Dnssec-trigger デーモンの稼働確認
dnssec-triggerd
が稼働しているかどうかを確認するには、以下のコマンドを実行します。
~]$ systemctl status dnssec-triggerd
systemctl status dnssec-triggerd.service
dnssec-triggerd.service - Reconfigure local DNS(SEC) resolver on network change
Loaded: loaded (/usr/lib/systemd/system/dnssec-triggerd.service; enabled)
Active: active (running) since Wed 2013-03-13 06:10:44 CET; 1h 41min ago
systemctl status
コマンドは、dnssec-triggerd
デーモンが稼働していなければ Active: inactive (dead)
とレポートします。dnssec-triggerd
を現行セッションで起動するには、root
ユーザーで以下のコマンドを実行します。
~]# systemctl start dnssec-triggerd
systemctl enable
コマンドを実行すると dnssec-triggerd
がシステム起動時に毎回起動します。
~]# systemctl enable dnssec-triggerd
4.5.8. Dnssec-trigger の使用
DNSSEC
と入力して Enter を押します。船の錨に似たアイコンが画面下部のメッセージトレイに追加されます。画面右下の青く丸い通知アイコンを押してこれを表示させます。錨アイコンを右クリックすると、ポップアップメニューが表示されます。
resolv.conf
は 127.0.0.1
をポイントします。Hotspot Sign-On パネルの をクリックすると、これが変更されます。DNS
サーバーが NetworkManager からクエリーを受け、resolv.conf
に置かれます。これで Hotspot のサインオンページで認証が可能になります。錨アイコンは赤い大きな感嘆符を表示して、DNS
クエリーが安全でない状態で行われていることを警告します。認証が行われると、dnssec-trigger は自動的にこれを検出し、セキュアモードに戻します。ただし、場合によってはこれができず、ユーザーが手動で Reprobe を選択する必要があることもあります。
resolv.conf
ファイルへの変更を unbound
に知らせます。
4.5.9. DNSSEC における dig の使用
DNS
ユーティリティーは旧式なので使用しないでください。
+dnssec
オプションをコマンドに追加します。
~]$ dig +dnssec whitehouse.gov
; <<>> DiG 9.9.3-rl.13207.22-P2-RedHat-9.9.3-4.P2.el7 <<>> +dnssec whitehouse.gov
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21388
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;whitehouse.gov. IN A
;; ANSWER SECTION:
whitehouse.gov. 20 IN A 72.246.36.110
whitehouse.gov. 20 IN RRSIG A 7 2 20 20130825124016 20130822114016 8399 whitehouse.gov. BB8VHWEkIaKpaLprt3hq1GkjDROvkmjYTBxiGhuki/BJn3PoIGyrftxR HH0377I0Lsybj/uZv5hL4UwWd/lw6Gn8GPikqhztAkgMxddMQ2IARP6p wbMOKbSUuV6NGUT1WWwpbi+LelFMqQcAq3Se66iyH0Jem7HtgPEUE1Zc 3oI=
;; Query time: 227 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Aug 22 22:01:52 EDT 2013
;; MSG SIZE rcvd: 233
A レコードに加えて RRSIG レコードが返されます。これには DNSSEC 署名と署名の取得および失効時間が含まれています。unbound
サーバーは、上部の flags:
セクションで ad
を返して、データが DNSSEC 認証されていることを示しています。
dig
は SERVFAIL エラーを返します。
~]$ dig badsign-a.test.dnssec-tools.org
; <<>> DiG 9.9.3-rl.156.01-P1-RedHat-9.9.3-3.P1.el7 <<>> badsign-a.test.dnssec-tools.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 1010
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;badsign-a.test.dnssec-tools.org. IN A
;; Query time: 1284 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Aug 22 22:04:52 EDT 2013
;; MSG SIZE rcvd: 60]
dig
コマンドに +cd
オプションを指定して DNSSEC 検査を無効にすることができます。
~]$ dig +cd +dnssec badsign-a.test.dnssec-tools.org
; <<>> DiG 9.9.3-rl.156.01-P1-RedHat-9.9.3-3.P1.el7 <<>> +cd +dnssec badsign-a.test.dnssec-tools.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26065
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;badsign-a.test.dnssec-tools.org. IN A
;; ANSWER SECTION:
badsign-a.test.dnssec-tools.org. 49 IN A 75.119.216.33
badsign-a.test.dnssec-tools.org. 49 IN RRSIG A 5 4 86400 20130919183720 20130820173720 19442 test.dnssec-tools.org. E572dLKMvYB4cgTRyAHIKKEvdOP7tockQb7hXFNZKVbfXbZJOIDREJrr zCgAfJ2hykfY0yJHAlnuQvM0s6xOnNBSvc2xLIybJdfTaN6kSR0YFdYZ n2NpPctn2kUBn5UR1BJRin3Gqy20LZlZx2KD7cZBtieMsU/IunyhCSc0 kYw=
;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Aug 22 22:06:31 EDT 2013
;; MSG SIZE rcvd: 257
systemctl status unbound
の出力で表示され、unbound
デーモンがこれらのエラーを syslog に以下のように記録します。 Aug 22 22:04:52 laptop unbound: [3065:0] info: validation failure badsign-a.test.dnssec-tools.org. A IN
unbound-host
を使用した例です。
~]$ unbound-host -C /etc/unbound/unbound.conf -v whitehouse.gov
whitehouse.gov has address 184.25.196.110 (secure)
whitehouse.gov has IPv6 address 2600:1417:11:2:8800::fc4 (secure)
whitehouse.gov has IPv6 address 2600:1417:11:2:8000::fc4 (secure)
whitehouse.gov mail is handled by 105 mail1.eop.gov. (secure)
whitehouse.gov mail is handled by 110 mail5.eop.gov. (secure)
whitehouse.gov mail is handled by 105 mail4.eop.gov. (secure)
whitehouse.gov mail is handled by 110 mail6.eop.gov. (secure)
whitehouse.gov mail is handled by 105 mail2.eop.gov. (secure)
whitehouse.gov mail is handled by 105 mail3.eop.gov. (secure)
4.5.10. Dnssec-trigger 用のホットスポット検出インフラストラクチャーの設定
- インターネット上で公開されているマシン上にウェブサーバーを設定します。Red Hat Enterprise Linux 7 システム管理者のガイドの Web サーバー の章を参照してください。
- サーバーが稼働したら、既知のコンテンツがある静的ページを公開します。このページは、有効な HTML ページである必要はありません。たとえば、
hotspot.txt
という名前のプレーンテキストファイルでOK
という文字列の内容だけでも構いません。サーバーがexample.com
にあり、そのサーバーのサブディレクトリーdocument_root/static/
にhotspot.txt
ファイルを公開したとすると、この静的ページのアドレスは、example.com/static/hotspot.txt
になります。Red Hat Enterprise Linux 7 システム管理者のガイドの Web サーバー の章にあるDocumentRoot
ディレクティブを参照してください。 - 以下の行を
/etc/dnssec-trigger/dnssec-trigger.conf
ファイルに追加します。url: "http://example.com/static/hotspot.txt OK"
このコマンドは、HTTP
(ポート 80) 経由でプローブされる URL を追加します。最初の部分は解決される URL とダウンロードするページで、後の部分はダウンロードした web ページに含まれることになる文字列です。
dnssec-trigger.conf(8)
を参照してください。
4.5.11. 接続によって提供されるドメイン用の DNSSEC 検証の設定
unbound
に追加します。デフォルトでは、unbound
に追加されるすべての転送ゾーンは DNSSEC で検証されます。
/etc/dnssec.conf
にある validate_connection_provided_zones
変数を変更します。root
ユーザーでファイルを開き、以下のように行を編集します。validate_connection_provided_zones=noこの変更は既存の転送ゾーンではなく、将来の転送ゾーンにのみ有効になります。このため、現在提供されているドメインについて DNSSEC を無効にするには、再接続が必要になります。
4.5.11.1. Wi-Fi が提供するドメイン用の DNSSEC 検証の設定
/etc/dnssec.conf
にある add_wifi_provided_zones
変数を変更します。 root
ユーザーでファイルを開き、以下のように行を編集します。add_wifi_provided_zones=yesこの変更は既存の転送ゾーンではなく、将来の転送ゾーンにのみ有効になります。このため、現在 Wi-Fi が提供するドメインについて DNSSEC を有効にするには、Wi-Fi の再接続 (再起動) が必要になります。
警告
unbound
に追加することを オン にすると、セキュリティー面で以下のような影響があります。
- Wi-Fi アクセスポイントは意図的に、
DHCP
経由でドメインを提供することが可能です。このドメインは認証されていないもので、ユーザーの全DNS
クエリーをこのアクセスポイントのDNS
サーバーにルーティングしてしまいます。 - 転送ゾーンの DNSSEC 検証を オフ にすると、Wi-Fi 提供の
DNS
サーバーは、ユーザーが知らない間に提供されたドメインからドメインネームのIP
アドレスのなりすましができるようになります。
4.5.12. その他のリソース
4.5.12.1. インストールされているドキュメント
dnssec-trigger(8)
man ページ —dnssec-triggerd
、dnssec-trigger-control および dnssec-trigger-panel のコマンドオプションについて説明しています。dnssec-trigger.conf(8)
man ページ —dnssec-triggerd
の設定オプションについて説明しています。unbound(8)
man ページ —unbound
、DNS
検証リゾルバーのコマンドオプションについて説明しています。unbound.conf(5)
man ページ —unbound
の設定方法に関する情報が含まれています。resolv.conf(5)
man ページ — リゾルバールーチンが読み取る情報が含まれています。
4.5.12.2. オンラインのドキュメント
- http://tools.ietf.org/html/rfc4033
- RFC 4033 DNS Security Introduction and Requirements.
- http://www.dnssec.net/
- DNSSEC リソースに関する多くのリンクがあるウェブサイトです。
- http://www.dnssec-deployment.org/
- 米国土安全保障省が後援する DNSSEC Deployment Initiative です。DNSSEC に関する多くの情報と DNSSEC 導入に関する問題を話し合うメーリングリストが含まれています。
- http://www.internetsociety.org/deploy360/dnssec/community/
- Internet Society の 「Deploy 360」 イニシアチブで、DNSSEC 導入の活性化と調整を図ります。世界中のコミュニティーと DNSSEC アクティビティーを探す便利なリソースになります。
- http://www.unbound.net/
unbound
DNS
サービスに関する全般的な情報が含まれています。- http://www.nlnetlabs.nl/projects/dnssec-trigger/
- dnssec-trigger に関する全般的な情報が含まれています。
4.6. Libreswan を使用した仮想プライベートネットワーク (VPN) のセキュリティー保護
IPsec
プロトコルを使用して設定できます。Libreswan は、Openswan アプリケーションの延長で、Openswan ドキュメント内の多くの例は Libreswan と交換可能なものです。NetworkManager IPsec
プラグインは、NetworkManager-libreswan と呼ばれます。GNOME Shell のユーザーは、NetworkManager-libreswan-gnome パッケージをインストールしてください。これには、依存関係として NetworkManager-libreswan が含まれています。NetworkManager-libreswan-gnome パッケージは、Optional チャンネルからのみ入手可能です。『Enabling Supplementary and Optional Repositories』 を参照してください。
IPsec
プロトコルは、Internet Key Exchange (IKE) プロトコルを使用して設定されます。IPsec および IKE は交換可能です。IPsec VPN は、IKE VPN、IKEv2 VPN、XAUTH VPN、Cisco VPN、または IKE/IPsec VPN とも呼ばれます。Level 2 Tunneling Protocol (L2TP) も使用する IPsec VPN のバリアントは、通常 L2TP/IPsec VPN と呼ばれます。これは、Optional チャンネルの xl2tpd アプリケーションを必要とします。
IKE
実装です。IKE
バージョン 1 および 2 は、ユーザーレベルデーモンとして実装されます。IKE プロトコルそのものは暗号化されています。IPsec
プロトコルは Linux カーネルにより実装されており、Libreswan は、VPN トンネル設定の追加または削除を行うようにカーネルを設定します。
IKE
プロトコルは、UDP ポート 500 および 4500 を使用します。IPsec
プロトコルは、プロトコル番号 50 の Encapsulated Security Payload (ESP) とプロトコル番号 51 の Authenticated Header (AH) の、2 つの異なるプロトコルから構成されます。AH
プロトコルの使用は推奨されません。AH
を使用している場合は、null 暗号化を使用して ESP
に移動することが推奨されます。
IPsec
プロトコルには、動作のモードが 2 つ (トンネルモード
(デフォルト) および トランスポートモード
) があります。カーネルを、IKE がない IPsec を持つカーネルを設定することができます。これは、Manual Keying
と呼ばれます。ただし、ip xfrm
コマンドは、セキュリティー上の理由から使用しないことが強く推奨されます。netlink を使用して Linux カーネルを使用する Libreswan インターフェースにおいては、パケットの暗号化および複号は Linux カーネルで発生します。
重要
IKE
/IPsec
VPN は、Red Hat Enterprise Linux 7 で使用することが推奨される唯一の VPN テクノロジーです。その他の VPN テクノロジーを使用するリスクを理解せずに使用しないでください。
4.6.1. Libreswan のインストール
root
で以下のコマンドを実行します。
~]# yum install libreswan
~]$ yum info libreswan
~]#systemctl stop ipsec
~]#rm /etc/ipsec.d/*db
root
で以下のコマンドを実行します。
~]# ipsec initnss
Initializing NSS database
~]# certutil -N -d sql:/etc/ipsec.d
Enter a password which will be used to encrypt your keys.
The password should be at least 8 characters long,
and should contain at least one non-alphabetic character.
Enter new password:
Re-enter password:
ipsec
デーモンを起動するには、root
で以下のコマンドを実行します。
~]# systemctl start ipsec
~]$ systemctl status ipsec
* ipsec.service - Internet Key Exchange (IKE) Protocol Daemon for IPsec
Loaded: loaded (/usr/lib/systemd/system/ipsec.service; disabled; vendor preset: disabled)
Active: active (running) since Sun 2018-03-18 18:44:43 EDT; 3s ago
Docs: man:ipsec(8)
man:pluto(8)
man:ipsec.conf(5)
Process: 20358 ExecStopPost=/usr/sbin/ipsec --stopnflog (code=exited, status=0/SUCCESS)
Process: 20355 ExecStopPost=/sbin/ip xfrm state flush (code=exited, status=0/SUCCESS)
Process: 20352 ExecStopPost=/sbin/ip xfrm policy flush (code=exited, status=0/SUCCESS)
Process: 20347 ExecStop=/usr/libexec/ipsec/whack --shutdown (code=exited, status=0/SUCCESS)
Process: 20634 ExecStartPre=/usr/sbin/ipsec --checknflog (code=exited, status=0/SUCCESS)
Process: 20631 ExecStartPre=/usr/sbin/ipsec --checknss (code=exited, status=0/SUCCESS)
Process: 20369 ExecStartPre=/usr/libexec/ipsec/_stackmanager start (code=exited, status=0/SUCCESS)
Process: 20366 ExecStartPre=/usr/libexec/ipsec/addconn --config /etc/ipsec.conf --checkconfig (code=exited, status=0/SUCCESS)
Main PID: 20646 (pluto)
Status: "Startup completed."
CGroup: /system.slice/ipsec.service
└─20646 /usr/libexec/ipsec/pluto --leak-detective --config /etc/ipsec.conf --nofork
root
で以下のコマンドを実行します。
~]# systemctl enable ipsec
ipsec
サービスを許可するように設定します。ファイアウォールおよび特定サービスの通過を許可することに関する詳細情報は、5章ファイアウォールの使用 を参照してください。Libreswan の使用には、以下のパケットがファイアウォールを通過できるようにしておく必要があります。
Internet Key Exchange
(IKE) プロトコルに対するUDP
ポート 500 および 4500Encapsulated Security Payload
(ESP)IPsec
パケット用に プロトコル 50Authenticated Header
(AH)IPsec
パケット用にプロトコル 51 (一般的でない)
IPsec
VPN を設定する例を 3 つ紹介します。1 つ目は、2 つのホストを接続してセキュアな通信ができるようにします。2 つ目は、2 つのサイトを接続して 1 つのネットワークを形成します。3 つ目は、このコンテキストでは ロードウォリアー と呼ばれるリモートユーザーをサポートします。
4.6.2. Libreswan を使用して VPN 設定の作成
- Pre-Shared Keys (PSK) は、最も簡単な認証メソッドです。PSK は、20 文字以上のランダムな文字からなります。FIPS モードで、PSK が、使用するインテグリティーアルゴリズムによる最低強化要件に従う必要があります。ランダムな 64 文字より短い PSK を使用しないことが推奨されます。
- 生 RSA 鍵は、静的なホスト間またはサブネット間で一般的に使用される
IPsec
設定です。ホストは、それぞれの公開 RSA 鍵で手動で設定されます。この方法は、12 以上のホストで相互にIPsec
トンネルを設定する必要がある場合には、うまく拡張できません。 - X.509 証明書は、共通の
IPsec
ゲートウェイに接続する必要のあるホストが多数ある大型の導入案件でよく使用されます。ホストまたはユーザーの RSA 証明書の署名には、中央の 認証機関 (CA) が使用されます。この中央 CA は、個別ホストまたはユーザーの取り消しを含む信頼の中継を担当します。 - NULL 認証は、認証なしでメッシュ暗号を取得するために使用されます。受動的攻撃は保護しますが、能動的攻撃は保護しません。ただし、
IKEv2
は、非対称の認証方法を許可しますが、NULL 認証をインターネット規模の日和見 IPsec に対しても使用できます。ここでは、クライアントはサーバーを認証しますが、サーバーはクライアントを認証しません。このモデルは、TLS
を使用して Web サイトを保護する (https:// websites としても知られています) のに似ています。
4.6.3. Libreswan を使用したホスト間の VPN の作成
IPsec
VPN を作成するように設定するには、両方のホスト上 (「左」 および 「右」) で root
として以下のコマンドを実行し、新たな生 RSA 鍵のペアを作成します。
~]# ipsec newhostkey --output /etc/ipsec.d/hostkey.secrets
Generated RSA key pair with CKAID 14936e48e756eb107fa1438e25a345b46d80433f was stored in the NSS database
root
で以下のコマンドを実行します。
~]# ipsec showhostkey --left --ckaid 14936e48e756eb107fa1438e25a345b46d80433f
# rsakey AQPFKElpV
leftrsasigkey=0sAQPFKElpV2GdCF0Ux9Kqhcap53Kaa+uCgduoT2I3x6LkRK8N+GiVGkRH4Xg+WMrzRb94kDDD8m/BO/Md+A30u0NjDk724jWuUU215rnpwvbdAob8pxYc4ReSgjQ/DkqQvsemoeF4kimMU1OBPNU7lBw4hTBFzu+iVUYMELwQSXpremLXHBNIamUbe5R1+ibgxO19l/PAbZwxyGX/ueBMBvSQ+H0UqdGKbq7UgSEQTFa4/gqdYZDDzx55tpZk2Z3es+EWdURwJOgGiiiIFuBagasHFpeu9Teb1VzRyytnyNiJCBVhWVqsB4h6eaQ9RpAMmqBdBeNHfXwb6/hg+JIKJgjidXvGtgWBYNDpG40fEFh9USaFlSdiHO+dmGyZQ74Rg9sWLtiVdlH1YEBUtQb8f8FVry9wSn6AZqPlpGgUdtkTYUCaaifsYH4hoIA0nku4Fy/Ugej89ZdrSN7Lt+igns4FysMmBOl9Wi9+LWnfl+dm4Nc6UNgLE8kZc+8vMJGkLi4SYjk2/MFYgqGX/COxSCPBFUZFiNK7Wda0kWea/FqE1heem7rvKAPIiqMymjSmytZI9hhkCD16pCdgrO3fJXsfAUChYYSPyPQClkavvBL/wNK9zlaOwssTaKTj4Xn90SrZaxTEjpqUeQ==
~]# ipsec showhostkey --list
< 1 > RSA keyid: AQPFKElpV ckaid: 14936e48e756eb107fa1438e25a345b46d80433f
/etc/ipsec.d/*.db
に置かれた 「NSS database」 に保存されます。
leftrsasigkey=
行および rightrsasigkey=
行を、/etc/ipsec.d/
ディレクトリーに保存されているカスタムの設定ファイルに追加されます。
root
でエディターを使用して以下の形式で適切な名前のファイルを作成します。
/etc/ipsec.d/my_host-to-host.conf
conn mytunnel leftid=@west.example.com left=192.1.2.23 leftrsasigkey=0sAQOrlo+hOafUZDlCQmXFrje/oZm [...] W2n417C/4urYHQkCvuIQ== rightid=@east.example.com right=192.1.2.45 rightrsasigkey=0sAQO3fwC6nSSGgt64DWiYZzuHbc4 [...] D/v8t5YTQ== authby=rsasig # load and initiate automatically auto=start
IP
アドレスが事前に分からない場合は、モバイルクライアントで %defaultroute
を IP
アドレスとして使用します。これにより、自動的に動的 IP
アドレスを選択します。モバイルホストから接続を受け付ける静的サーバーホストの場合は、%any
をその IP
アドレスに対して使用してモバイルホストを指定します。
leftrsasigkey
の値は 「left」 ホストから、そして rightrsasigkey
値は 「right」 ホストから取得していることを確認します。leftckaid
および rightckaid
を使用する場合も同様です。
ipsec
を再起動し、新しい設定を読み込んでいることを確認します。システムの起動時に設定している場合は、トンネルが確立されていることを確認するには、以下のコマンドを実行します。
~]# systemctl restart ipsec
auto=start
オプションを使用している場合は、数秒以内に IPsec
トンネルを確立する必要があります。root
で以下のコマンドを実行して、トンネルを手動でロードおよび起動できます。
~]#ipsec auto --add mytunnel
~]#ipsec auto --up mytunnel
4.6.3.1. Libreswan を使用したホスト間の VPN の検証
IKE
ネゴシエーションが、UDP
ポート 500 および 4500 で行われます。IPsec
パケットは、Encapsulated Security Payload
(ESP) パケットとして現れます。ESP
プロトコルにはポートがありません。VPN 接続が NAT ルーターを通過する必要がある場合に、ESP
パケットは、ポート 4500 の UDP
パケットにカプセル化されます。
root
で以下の形式のコマンドを実行します。
~]# tcpdump -n -i interface esp or udp port 500 or udp port 4500
00:32:32.632165 IP 192.1.2.45 > 192.1.2.23: ESP(spi=0x63ad7e17,seq=0x1a), length 132
00:32:32.632592 IP 192.1.2.23 > 192.1.2.45: ESP(spi=0x4841b647,seq=0x1a), length 132
00:32:32.632592 IP 192.0.2.254 > 192.0.1.254: ICMP echo reply, id 2489, seq 7, length 64
00:32:33.632221 IP 192.1.2.45 > 192.1.2.23: ESP(spi=0x63ad7e17,seq=0x1b), length 132
00:32:33.632731 IP 192.1.2.23 > 192.1.2.45: ESP(spi=0x4841b647,seq=0x1b), length 132
00:32:33.632731 IP 192.0.2.254 > 192.0.1.254: ICMP echo reply, id 2489, seq 8, length 64
00:32:34.632183 IP 192.1.2.45 > 192.1.2.23: ESP(spi=0x63ad7e17,seq=0x1c), length 132
00:32:34.632607 IP 192.1.2.23 > 192.1.2.45: ESP(spi=0x4841b647,seq=0x1c), length 132
00:32:34.632607 IP 192.0.2.254 > 192.0.1.254: ICMP echo reply, id 2489, seq 9, length 64
00:32:35.632233 IP 192.1.2.45 > 192.1.2.23: ESP(spi=0x63ad7e17,seq=0x1d), length 132
00:32:35.632685 IP 192.1.2.23 > 192.1.2.45: ESP(spi=0x4841b647,seq=0x1d), length 132
00:32:35.632685 IP 192.0.2.254 > 192.0.1.254: ICMP echo reply, id 2489, seq 10, length 64
注記
IPsec
のインタラクションはやや予想外のものになります。見えるのは暗号化された送信パケットのみで、プレーンテキストの送信パケットは見えません。受信パケットは、暗号化および暗号解読された両方を表示します。可能であれば、tcpdump コマンドはどちらかのエンドポイント上ではなく、2 台のマシン間にあるルーター上で実行してください。VTI (Virtual Tunnel Interface) を使用している場合は、物理インターフェースの tcpdump が ESP
パケットを表示しますが、VTI インターフェースの tcpdump はクリアテキストトラフィックを表示します。
root
として以下のコマンドを実行します。
~]# ipsec whack --trafficstatus
006 #2: "mytunnel", type=ESP, add_time=1234567890, inBytes=336, outBytes=336, id='@east'
4.6.4. Libreswan を使用したサイト間の VPN の設定
IPsec
VPN を作成するようにするには、エンドポイントとなる 2 つのホスト間に IPsec
トンネルを作成します。これらのホストは、1 つ以上のサブネットからのトラフィック通過を許可するよう設定します。このため、これらはネットワークのリモート部分にはゲートウェイのように見えます。サイト間 VPN とホスト間 VPN の唯一の違いは、前者では 1 つ以上のネットワークまたはサブネットを設定ファイルで指定する必要があるという点です。
IPsec
VPN を作成するように Libreswan を設定するには、まず 「Libreswan を使用したホスト間の VPN の作成」 にあるようにホスト間の IPsec
VPN を設定し、その設定ファイルを /etc/ipsec.d/my_site-to-site.conf
などの適切なファイル名にコピーまたは移動します。root
権限でエディターを使用して、カスタム設定ファイルである /etc/ipsec.d/my_site-to-site.conf
を以下のように編集します。
conn mysubnet also=mytunnel leftsubnet=192.0.1.0/24 rightsubnet=192.0.2.0/24 auto=start conn mysubnet6 also=mytunnel connaddrfamily=ipv6 leftsubnet=2001:db8:0:1::/64 rightsubnet=2001:db8:0:2::/64 auto=start conn mytunnel leftid=@west.example.com left=192.1.2.23 leftrsasigkey=0sAQOrlo+hOafUZDlCQmXFrje/oZm [...] W2n417C/4urYHQkCvuIQ== rightid=@east.example.com right=192.1.2.45 rightrsasigkey=0sAQO3fwC6nSSGgt64DWiYZzuHbc4 [...] D/v8t5YTQ== authby=rsasig
root
で以下のコマンドを実行して手動ですべての接続を読み込み、開始します。
~]# ipsec auto --add mysubnet
~]# ipsec auto --add mysubnet6
~]# ipsec auto --up mysubnet
104 "mysubnet" #1: STATE_MAIN_I1: initiate
003 "mysubnet" #1: received Vendor ID payload [Dead Peer Detection]
003 "mytunnel" #1: received Vendor ID payload [FRAGMENTATION]
106 "mysubnet" #1: STATE_MAIN_I2: sent MI2, expecting MR2
108 "mysubnet" #1: STATE_MAIN_I3: sent MI3, expecting MR3
003 "mysubnet" #1: received Vendor ID payload [CAN-IKEv2]
004 "mysubnet" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_RSA_SIG cipher=aes_128 prf=oakley_sha group=modp2048}
117 "mysubnet" #2: STATE_QUICK_I1: initiate
004 "mysubnet" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP=>0x9414a615 <0x1a8eb4ef xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none DPD=none}
~]# ipsec auto --up mysubnet6
003 "mytunnel" #1: received Vendor ID payload [FRAGMENTATION]
117 "mysubnet" #2: STATE_QUICK_I1: initiate
004 "mysubnet" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP=>0x06fe2099 <0x75eaa862 xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none DPD=none}
4.6.4.1. Libreswan を使用するサイト間の VPN の検証
4.6.5. Libreswan を使用するサイト間のシングルトンネル VPN の設定
IP
アドレスではなく、内部の IP
アドレスを使用して相互に通信する必要が多くあります。これは、1 つのトンネルを使用することで実行できます。ホスト名が west
の左のホストの内部 IP
アドレスが 192.0.1.254
で、ホスト名が east
の右のホストの IP
アドレスが 192.0.2.254
の場合、以下の設定を、1 つのトンネルを使用して両方のサーバーで /etc/ipsec.d/myvpn.conf
ファイルに保存できます。
conn mysubnet leftid=@west.example.com leftrsasigkey=0sAQOrlo+hOafUZDlCQmXFrje/oZm [...] W2n417C/4urYHQkCvuIQ== left=192.1.2.23 leftsourceip=192.0.1.254 leftsubnet=192.0.1.0/24 rightid=@east.example.com rightrsasigkey=0sAQO3fwC6nSSGgt64DWiYZzuHbc4 [...] D/v8t5YTQ== right=192.1.2.45 rightsourceip=192.0.2.254 rightsubnet=192.0.2.0/24 auto=start authby=rsasig
4.6.6. Libreswan を使用したサブネット押し出しの設定
IPsec
は、ハブおよびスポークのアーキテクチャーにデプロイされることがよくあります。各リーフノードは、広い範囲の一部である IP
範囲があります。ハブを通して互いに通信します。これは サブネットの押出 と呼ばれます。
例4.2 サブネット押出の簡易設定
10.0.0.0/8
を設定し、より小さい /24
サブネットを使用する支店を 2 つ設定します。
conn branch1 left=1.2.3.4 leftid=@headoffice leftsubnet=0.0.0.0/0 leftrsasigkey=0sA[...] # right=5.6.7.8 rightid=@branch1 rightsubnet=10.0.1.0/24 rightrsasigkey=0sAXXXX[...] # auto=start authby=rsasig conn branch2 left=1.2.3.4 leftid=@headoffice leftsubnet=0.0.0.0/0 leftrsasigkey=0sA[...] # right=10.11.12.13 rightid=@branch2 rightsubnet=10.0.2.0/24 rightrsasigkey=0sAYYYY[...] # auto=start authby=rsasig
conn branch1 left=1.2.3.4 leftid=@headoffice leftsubnet=0.0.0.0/0 leftrsasigkey=0sA[...] # right=10.11.12.13 rightid=@branch2 rightsubnet=10.0.1.0/24 rightrsasigkey=0sAYYYY[...] # auto=start authby=rsasig conn passthrough left=1.2.3.4 right=0.0.0.0 leftsubnet=10.0.1.0/24 rightsubnet=10.0.1.0/24 authby=never type=passthrough auto=route
4.6.7. IKEv2 リモートアクセスの VPN Libreswan の設定
IP
アドレスを動的に割り当てられるモバイルクライアントを持ち運ぶユーザーのことで、認証は、証明書を使用して行います。以前の IKEv1 XAUTH プロトコルを使用する必要がないように、以下の例では IKEv2 が使用されています。
conn roadwarriors ikev2=insist # Support (roaming) MOBIKE clients (RFC 4555) mobike=yes fragmentation=yes left=1.2.3.4 # if access to the LAN is given, enable this, otherwise use 0.0.0.0/0 # leftsubnet=10.10.0.0/16 leftsubnet=0.0.0.0/0 leftcert=vpn-server.example.com leftid=%fromcert leftxauthserver=yes leftmodecfgserver=yes right=%any # trust our own Certificate Agency rightca=%same # pick an IP address pool to assign to remote users # 100.64.0.0/16 prevents RFC1918 clashes when remote users are behind NAT rightaddresspool=100.64.13.100-100.64.13.254 # if you want remote clients to use some local DNS zones and servers modecfgdns="1.2.3.4, 5.6.7.8" modecfgdomains="internal.company.com, corp" rightxauthclient=yes rightmodecfgclient=yes authby=rsasig # optionally, run the client X.509 ID through pam to allow/deny client # pam-authorize=yes # load connection, don't initiate auto=add # kill vanished roadwarriors dpddelay=1m dpdtimeout=5m dpdaction=%clear
leftcert=vpn-server.example.com
- このオプションは、証明書のインポートに使用された平易な名前またはニックネームを参照する証明書を指定します。通常、名前は
.p12
ファイルの形式で PKCS #12 証明書バンドルの一部として生成されます。詳細は、pkcs12(1)
およびpk12util(1)
の man ページを参照してください。
conn to-vpn-server ikev2=insist # pick up our dynamic IP left=%defaultroute leftsubnet=0.0.0.0/0 leftcert=myname.example.com leftid=%fromcert leftmodecfgclient=yes # right can also be a DNS hostname right=1.2.3.4 # if access to the remote LAN is required, enable this, otherwise use 0.0.0.0/0 # rightsubnet=10.10.0.0/16 rightsubnet=0.0.0.0/0 # trust our own Certificate Agency rightca=%same authby=rsasig # allow narrowing to the server’s suggested assigned IP and remote subnet narrowing=yes # Support (roaming) MOBIKE clients (RFC 4555) mobike=yes # Initiate connection auto=start
auto=start
- このオプションを使用すると、ユーザーが
ipsec
システムサービスを起動するたびに VPN に接続できます。後で接続を確立する場合は、これをauto=add
に置き換えてください。
4.6.8. X.509 を使用した IKEv1 リモートアクセスの VPN Libreswan および XAUTH の設定
IPsec
拡張機能を使用して、ローミング VPN クライアントに対してネイティブに IP
アドレスと DNS 情報を割り当てる方法を提供します。拡張アプリケーション (XAUTH) は、PSK または X.509 証明書を使用してデプロイできます。X.509 を使用してデプロイの方がより安全です。クライアントの証明書は、証明書失効リストまたは Online Certificate Status Protocol (OCSP) で失効させることができます。X.509 証明書を使用すると、個別のクライアントはサーバーを偽装することができません。グループパスワードとも呼ばれる PSK を使用すると、これは理論上は可能になります。
xauthby=pam
- これにより、
/etc/pam.d/pluto
の設定を使用してユーザーを認証します。プラグ可能な認証モジュール (PAM) は、それ自体でさまざまなバックエンドを使用するように設定できます。システムアカウントの user-password スキーム、LDAP ディレクトリー、RADIUS サーバー、またはカスタムパスワード認証モジュールを使用できます。詳細は、PAM (プラグ可能な認証モジュール) の使用 の章を参照してください。 xauthby=file
- これは、設定ファイル
/etc/ipsec.d/passwd
(/etc/ipsec.d/nsspassword
と混同しないこと) を使用します。このファイルの形式は Apache.htpasswd
ファイルと同様のもので、Apachehtpasswd
コマンドはこのファイルのエントリー作成に使用できます。ただし、ユーザー名とパスワードの後に、使用するIPsec
接続の接続名が 3 番目のコラムに必要になります。たとえば、conn remoteusers
を使用してリモートユーザーに VPN を提供する場合、パスワードファイルのエントリーは以下のようになります。user1:$apr1$MIwQ3DHb$1I69LzTnZhnCT2DPQmAOK.:remoteusers
注記
htpasswd
コマンドを使用している場合に、各行で user:password 部分の後に手動で追加する必要があります。 xauthby=alwaysok
- サーバーは常に、XAUTH ユーザーとパスワードの組み合わせが適切であるように装います。サーバーはユーザー名とパスワードを無視しますが、クライアントはこれらを指定する必要があります。これは、ユーザーが X.509 証明書で既に特定されている場合、もしくは XAUTH バックエンドが不要な VPN をテストしている場合にのみ使用します。
conn xauth-rsa ikev2=never auto=add authby=rsasig pfs=no rekey=no left=ServerIP leftcert=vpn.example.com #leftid=%fromcert leftid=vpn.example.com leftsendcert=always leftsubnet=0.0.0.0/0 rightaddresspool=10.234.123.2-10.234.123.254 right=%any rightrsasigkey=%cert modecfgdns=1.2.3.4,8.8.8.8 modecfgdomains=example.com modecfgbanner="Authorized access is allowed" leftxauthserver=yes rightxauthclient=yes leftmodecfgserver=yes rightmodecfgclient=yes modecfgpull=yes xauthby=pam dpddelay=30 dpdtimeout=120 dpdaction=clear ike_frag=yes # for walled-garden on xauth failure # xauthfail=soft # leftupdown=/custom/_updown
xauthfail
を hard ではなく soft に設定すると認証失敗は無視され、VPN はユーザーが適切に認証したかのように設定されます。カスタムのアップダウンスクリプトを使用すると、環境変数 XAUTH_FAILED
をチェックできます。このようなユーザーは、たとえば iptables DNAT を使用して 「walled garden」 にリダイレクトすることが可能です。リダイレクト先では管理者への問い合わせ、サービスの有料サブスクリプションの更新などができます。
modecfgdomain
値および DNS エントリーを使用して、指定したネームサーバーに指定したドメインに対するクエリーをリダイレクトします。これにより、ローミングユーザーが、内部 DNS 名を使用し内部のみのリソースにアクセスできます。IKEv2 は、modecfgdomains
および modecfgdns
を使用してドメイン名およびネームサーバー IP アドレスのコンマ区切りリストをサポートしますが、IKEv1 プロトコルは 1 つのドメイン名だけをサポートし、libreswan はネームサーバーの IP アドレスを 2 つまでしかサポートしません。オプションで、VPM クライアントにバナーテキストを送信するには、modecfgbanner
オプションを使用します。
leftsubnet
が 0.0.0.0/0
でない場合は、分割トンネリング設定要求が自動的にクライアントに送信されます。たとえば、leftsubnet=10.0.0.0/8
を使用すると、VPN クライアントは 10.0.0.0/8
のトラフィックのみを VPN 経由で送信します。
xauthby=file
- 管理者はパスワードを生成し、
/etc/ipsec.d/passwd
ファイルに保存します。 xauthby=pam
- パスワードは、
/etc/pam.d/pluto
ファイルの PAM 設定で指定された場所で取得されます。 xauthby=alwaysok
- パスワードはチェックされず、常に受け入れられます。テスト目的や、xauth のみのクライアントの互換性を確保する場合は、このオプションを使用します。
関連情報
4.6.9. 量子コンピューターに対する保護の使用
ppk=yes
を追加します。PPK を要求するには、ppk=insist
を追加します。次に、各クライアントには、帯域幅 (および望ましくは量子安全) に通信する秘密値を持つ PPK ID が付与されます。PPK はランダム性で非常に強く、辞書の用語は選択されません。PPK ID および PPK データそのものは、以下のように ipsec.secrets
に保存されています。
@west @east : PPKS "user1" "thestringismeanttobearandomstr"
PPKS
オプションは、静的 PPK を参照します。動的 PPK に基づいてワンタイムパットを使用する実験的機能です。各接続で、ワンタイムパッドの新しい部分を PPK として使用します。これを使用すると、ファイル内の動的 PPK では、再利用しないようにゼロで上書きされます。ワンタイムパットマテリアルが残っていないと、接続に失敗します。詳細は man ページの ipsec.secrets(5)
を参照してください。
警告
4.6.10. 関連情報
ipsec
デーモンに関する追加リソースを提供します。
4.6.10.1. インストールされているドキュメント
ipsec(8)
の man ページ -ipsec
のコマンドオプションを説明しています。ipsec.conf(5)
の man ページ -ipsec
の設定情報が含まれています。ipsec.secrets(5)
の man ページ -ipsec.secrets
ファイルの形式を説明しています。ipsec_auto(8)
の man ページ - 鍵の自動交換を使用して確立された LibreswanIPsec
接続を操作する auto コマンドラインクライアントの使用方法を説明しています。ipsec_rsasigkey(8)
man ページ - RSA 署名鍵の生成に使用するツールを説明しています。/usr/share/doc/libreswan-version/
4.6.10.2. オンラインのドキュメント
- https://libreswan.org
- アップストリームプロジェクトの Web サイトです。
- https://libreswan.org/wiki
- Libreswan プロジェクトの Wiki です。
- https://libreswan.org/man/
- Libreswan に関する全 man ページ
- NIST Special Publication 800-77: Guide to IPsec VPNs
- IPsec に基づくセキュリティーサービスの実装に関する組織への実用的なガイダンス。
4.7. OpenSSL の使用
list-standard-commands
、list-message-digest-commands
、および list-cipher-commands
はそれぞれ、すべての標準コマンド一覧、メッセージダイジェストコマンド一覧、暗号コマンド一覧を出力します。これは、現行の openssl ユーティリティーで利用可能なものです。
list-cipher-algorithms
および list-message-digest-algorithms
は、すべての暗号およびメッセージダイジェストネームを一覧表示します。擬似コマンド list-public-key-algorithms
は、対応するすべての公開鍵アルゴリズムを一覧表示します。たとえば、対応するすべての公開鍵アルゴリズムを一覧表示するには、以下のコマンドを実行します。
~]$ openssl list-public-key-algorithms
4.7.1. 暗号鍵の作成および管理
~]$ openssl genpkey -algorithm
RSA -out
privkey.pem
rsa_keygen_bits:numbits
— 生成される鍵のビット数です。指定されない場合は、1024
が使われます。rsa_keygen_pubexp:value
— RSA 公開指数の値です。これは大きな十進数か、0x
で始まる場合は十六進数にすることができます。デフォルト値は65537
です。
3
を使用して 2048 ビットの RSA 秘密鍵を作成するには、以下のコマンドを実行します。
~]$ openssl genpkey -algorithm
RSA -out
privkey.pem -pkeyopt
rsa_keygen_bits:2048 \ -pkeyopt
rsa_keygen_pubexp:3
~]$ openssl genpkey -algorithm
RSA -out
privkey.pem -aes-128-cbc
-pass
pass:hello
4.7.2. 証明書の生成
4.7.2.1. 証明書署名要求の作成
~]$ openssl req -new
-key
privkey.pem -out
cert.csr
cert.csr
と呼ばれる X.509 証明書が作成されます。PEM という名前は、「Privacy Enhancement for Internet Electronic Mail」 に由来し、RFC 1424 で説明されています。別の DER 形式で証明書ファイルを生成するには、-outform
DER
コマンドオプションを使用します。
- 2 文字の国コード
- 州または県の名前
- 市または自治体
- 組織の名前
- 組織内の部署名
- ユーザー名もしくはシステムのホスト名
- Email アドレス
/etc/pki/tls/openssl.cnf
ファイル内にあります。詳細は、man ページの openssl.cnf(5)
を参照してください。
4.7.2.2. 自己署名証明書の作成
366
日間有効の自己署名証明書を生成するには、以下の形式でコマンドを実行します。
~]$ openssl req -new
-x509
-key
privkey.pem -out
selfcert.pem -days
366
4.7.2.3. Makefile を使った証明書の作成
/etc/pki/tls/certs
ディレクトリーには Makefile
が格納されており、これに make
コマンドを使用すると証明書が作成できます。使用方法を確認するには、以下のコマンドを実行します。
~]$ make -f /etc/pki/tls/certs/Makefile
または、ディレクトリーに移動して以下のように make
コマンドを実行することもできます。
~]$cd /etc/pki/tls/certs/
~]$make
4.7.3. 証明書の検証
~]$ openssl verify cert1.pem cert2.pem
cert.pem
にあり、信頼していない中間証明書が untrusted.pem
内で直接連結している必要があります。信頼できるルート CA 証明書は、/etc/pki/tls/certs/ca-bundle.crt
または cacert.pem
ファイルでリスト表示されているデフォルトの CA 内にある必要があります。この状態でチェーンを検証するには、以下の形式のコマンドを実行します。
~]$ openssl verify -untrusted
untrusted.pem -CAfile
cacert.pem cert.pem
重要
4.7.4. ファイルの暗号化および暗号化解除
pkeyutl
または enc
組み込みコマンドを使用できます。pkeyutl
では、暗号化および復号化を実行するために RSA
鍵が使用されますが、enc
では、シンメトリックアルゴリズムが使用されます。
RSA 鍵の使用
plaintext
を暗号化するには、以下のコマンドを実行します。
~]$ openssl pkeyutl -in
plaintext -out
cyphertext -inkey
privkey.pem
-keyform DER
オプションを使用して、DER 鍵形式を指定します。
-engine
オプションを以下のように使用します。
~]$ openssl pkeyutl -in
plaintext -out
cyphertext -inkey
privkey.pem -engine id
~]$ openssl engine -t
~]$ openssl pkeyutl -sign
-in
plaintext -out
sigtext -inkey
privkey.pem
~]$ openssl pkeyutl -verifyrecover
-in
sig -inkey
key.pem
~]$ openssl pkeyutl -verify
-in
file -sigfile sig -inkey
key.pem
シンメトリックアルゴリズムの使用
-l
などの未サポートのオプションを使用して enc
コマンドを実行します。
~]$
openssl enc -l
aes-128-cbc
アルゴリズムを使用するには、以下の構文を使用します。
openssl enc -aes-128-cbc
aes-128-cbc
アルゴリズムを使用して plaintext
という名前のファイルを暗号化するには、以下のコマンドを実行します。
~]$
openssl enc -aes-128-cbc -in plaintext -out plaintext.aes-128-cbc
-d
オプションを使用します。
~]$
openssl enc -aes-128-cbc -d -in plaintext.aes-128-cbc -out plaintext
重要
enc
コマンドは AEAD
暗号を適切にサポートしないため、ecb
モードは安全と見なされません。最良の結果を得るために、cbc
、cfb
、ofb
、または ctr
以外のモードを使用しないでください。
4.7.5. メッセージダイジェストの生成
dgst
コマンドは、十六進数形式で提供されたファイルのメッセージダイジェストを作成します。このコマンドは、デジタル署名および検証にも使用できます。メッセージダイジェストコマンドの形式は以下のとおりです。
openssl dgst algorithm-out
filename-sign
private-key
md5|md4|md2|sha1|sha|mdc2|ripemd160|dss1
のいずれかになります。本書執筆時点では、SHA1 アルゴリズムが推奨されます。DSA を使用した署名もしくは検証が必要な場合は、-rand
オプションで指定したランダムなデータを含むファイルとともに dss1
オプションを使用する必要があります。
~]$ openssl dgst sha1 -out
digest-file
~]$ openssl dgst sha1 -out
digest-file -sign
privkey.pem
4.7.6. パスワードハッシュの生成
passwd
コマンドは、パスワードのハッシュを計算します。コマンドラインでパスワードのハッシュを計算するには、以下のコマンドを実行します。
~]$ openssl passwd password
-crypt
アルゴリズムが使用されます。
1
に基づく MD5 を使用して、標準入力からパスワードのハッシュを計算するには、以下のコマンドを実行します。
~]$ openssl passwd -1
password
-apr1
オプションが BSD アルゴリズムの Apache バリアントを指定します。
xx
を使用してファイルに保存されているパスワードのハッシュを計算するには、以下のコマンドを実行します。
~]$ openssl passwd -salt
xx
-in
password-file
-out
オプションはありません。-table
は、パスワードハッシュの表とそれに対応するクリアテキストのパスワードを生成します。
4.7.7. ランダムデータの生成
~]$ openssl rand -out
rand-file -rand
seed-file
:
区切りのリストを使用して指定できます。
4.7.8. システムのベンチマーキング
~]$ openssl speed algorithm
openssl speed
と入力してタブを押します。
4.7.9. OpenSSL の設定
/etc/pki/tls/openssl.cnf
があり、OpenSSL ライブラリーがこれを読み込みます。各アプリケーション用の個別の設定ファイルを用いることもできます。設定ファイルには、[ section_name ]
のようにセクション名が付いた多くのセクションが含まれています。最初の [ section_name ]
までの部分は、デフォルトセクションと呼ばれることに注意してください。OpenSSL が設定ファイル内で名前を検索する際には、最初に名前の付いたセクションが検索されます。別の設定ファイルがコマンド内のオプションで指定されていなければ、OpenSSL コマンドはすべて、マスター OpenSSL 設定ファイルを使用します。設定ファイルの詳細は、config(5)
man ページで説明されています。
4.8. stunnel の使用
4.8.1. stunnel のインストール
root
で以下のコマンドを実行します。
~]# yum install stunnel
4.8.2. stunnel の TLS ラッパーとしての設定
- stunnel とどのサービスを使うにしても、有効な証明書が必要になります。適切な証明書がない場合は、認証機関 に申し込むか、自己署名の証明書を自身で作成することもできます。
警告
実稼働環境で稼働しているサーバーには、常に認証機関で署名された証明書を使用してください。自己署名証明書は、テスト目的またはプライベートネットワークのみで使用することをお勧めします認証局が提供する証明書についての詳細情報は、「証明書署名要求の作成」 を参照してください。stunnel 用に自己署名証明書を作成するには、root
で/etc/pki/tls/certs/
ディレクトリーに移動し、以下のコマンドを実行します。certs]#
make stunnel.pem
すべての質問に回答して、プロセスを完了します。 - 証明書ができたら、stunnel 用の設定ファイルを作成します。これはテキストファイルで、各行でオプションまたはサービス定義の開始を指定します。また、コメントや空の行使って、読みやすくすることもできます。コメントはセミコロンで開始します。stunnel RPM パッケージには
/etc/stunnel/
ディレクトリーが含まれ、設定ファイルはここで保存します。stunnel ではファイル名で特定の形式や拡張子は必要ありませんが、/etc/stunnel/stunnel.conf
としてください。以下のコンテンツでは、stunnel を TLS ラッパーとして設定します。cert = /etc/pki/tls/certs/stunnel.pem ; Allow only TLS, thus avoiding SSL sslVersion = TLSv1 chroot = /var/run/stunnel setuid = nobody setgid = nobody pid = /stunnel.pid socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 [service_name] accept = port connect = port TIMEOUTclose = 0
別の方法では、sslVersion = TLSv1
の行を以下の行で置き換えると SSL を避けられます。options = NO_SSLv2 options = NO_SSLv3
オプションの目的は、以下のとおりです。cert
— 証明書へのパスです。sslVersion
— SSL のバージョンです。SSL と TLS は別個の暗号化プロトコルですが、ここではTLS
が使えることに注意してください。chroot
— 変更後の root ディレクトリーです。ここでは、stunnel プロセスがより安全に実行できます。setuid
,setgid
— stunnel プロセスを実行するユーザーおよびグループ。nobody
は制限されたシステムアカウントになります。pid
— stunnel がプロセス ID を保存するファイルで、chroot
に相対的になります。socket
— ローカルおよびリモートのソケットオプション。このケースでは、ネーグルのアルゴリズムを無効にして、ネットワーク遅延を改善します。[service_name]
— サービ定義の開始点。この下に続く行で使用されるオプションは、該当サービスのみに適用されます。この上にあるオプションは、 stunnel でグローバルに適用されます。accept
— リッスンするポートです。connect
— 接続先のポートです。このポートは、セキュアにしているサービスが使用するものである必要があります。TIMEOUTclose
— クライアントから close_notify 警告が出されるまでの待ち時間です。これが0
の場合は、stunnel はまったく待機しません。options
— OpenSSL ライブラリーのオプション。
例4.3 CUPS のセキュア化
CUPS 用に stunnel を TLS ラッパーとして設定するには、以下の値を使用します。[cups] accept = 632 connect = 631
632
の代わりに使用されていないポートを使うこともできます。631
は CUPS が通常使用するポートです。 chroot
ディレクトリーを作成し、setuid
オプションで指定されているユーザーにこのディレクトリーへの書き込みアクセスを与えます。これを行うには、root
で以下のコマンドを実行します。~]#
mkdir /var/run/stunnel
~]#chown nobody:nobody /var/run/stunnel
これで、stunnel が PID ファイルを作成できるようになります。- 使用中のシステムでファイアウォールが新たなポートへのアクセスを許可しない設定となっている場合は、この設定を許可するように変更します。詳細は、「GUI を使用してポートを開く」 を参照してください。
- 設定ファイルと
chroot
ディレクトリーを作成し、指定されたポートがアクセス可能なことを確認したら、stunnel を開始することができます。
4.8.3. stunnel の起動、停止、再起動
root
で以下のコマンドを実行します。
~]# stunnel /etc/stunnel/stunnel.conf
/var/log/secure
を使用します。
root
で以下のコマンドを実行してプロセスを強制終了させます。
~]# kill `cat /var/run/stunnel/stunnel.pid`
4.9. 暗号化
4.9.1. LUKS のディスク暗号化の使用
LUKS の概要
- LUKS の機能
- LUKS はブロックデバイス全体を暗号化するため、脱着可能なストレージメディアやノート PC のディスクドライブといった、モバイルデバイスのコンテンツ保護に適しています。
- 暗号化されたブロックデバイスにあるのは任意のコンテンツです。これは、
スワップ
デバイスの暗号化に役立ちます。また、とりわけデータストレージ用にフォーマットしたブロックデバイスを使用する特定のデータベースに関しても有用です。 - LUKS は既存のデバイスマッパーカーネルサブシステムを使用します。
- LUKS はパラフレーズの強化を提供し、辞書攻撃から保護します。
- LUKS デバイスには複数のキースロットが含まれ、ユーザーはこれを使ってバックアップキーやパスフレーズを追加できます。
- LUKS でできないこと:
- LUKS は、多くのユーザー (9 人以上) が同一デバイスに対して個別のアクセスキーを持つことが必要となるシナリオには適していません。
- LUKS は、ファイルレベルの暗号化を必要とするアプリケーションには適していません。
重要
4.9.1.1. Red Hat Enterprise Linux における LUKS の実装
cryptsetup --help
を参照) は aes-cbc-essiv:sha256 (ESSIV - Encrypted Salt-Sector Initialization Vector) です。インストールプログラムのAnaconda は、デフォルトでは XTS モード (aes-xts-plain64) を使用することに注意してください。LUKS のデフォルトの鍵のサイズは 256 ビット です。Anaconda(XTS モード) と併用する場合の LUKS のデフォルトの鍵のサイズは 512 ビット です。利用可能な暗号は以下の通りです。
- AES - Advanced Encryption Standard (高度暗号化標準): FIPS PUB 197
- Twofish (128 ビットブロック暗号)
- Serpent
- cast5 -RFC 2144
- cast6 - RFC 2612
4.9.1.2. 手動でのディレクトリーの暗号化
警告
- root としてシェルプロンプトに以下を入力し、ランレベル 1 に入ります。
telinit 1
- 既存の
/home
のマウントを解除します。umount /home
- 直前の手順のコマンドが失敗した場合は、
fuser
を使用し、/home
を独占しているプロセスを見つけてこれらを止めます。fuser -mvk /home
/home
がもはやマウントされていないことを確認します。grep home /proc/mounts
- パーティションをランダムなデータで埋めます。
shred -v --iterations=1 /dev/VG00/LV_home
このコマンドは、デバイスの連続書き込み速度で実行され、完了までに時間がかかる場合があります。使用デバイスに暗号化されていないデータが残っていないことを確認した上で、デバイスの暗号化されたデータを含む部分を難読化するのは重要なステップです。 - パーティションを初期化します。
cryptsetup --verbose --verify-passphrase luksFormat /dev/VG00/LV_home
- 新たに暗号化したデバイスを開きます。
cryptsetup luksOpen /dev/VG00/LV_home home
- デバイスがあることを確認します。
ls -l /dev/mapper | grep home
- ファイルシステムを作成します。
mkfs.ext3 /dev/mapper/home
- ファイルシステムをマウントします。
mount /dev/mapper/home /home
- ファイルシステムが表示されていることを確認します。
df -h | grep home
- 以下を
/etc/crypttab
ファイルに追加します。home /dev/VG00/LV_home none
/etc/fstab
ファイルを編集して、/home
の古いエントリを削除し、以下の行を追加します。/dev/mapper/home /home ext3 defaults 1 2
- デフォルトの SELinux セキュリティーコンテンツを復元します。
/sbin/restorecon -v -R /home
- マシンを再起動します。
shutdown -r now
/etc/crypttab
にあるエントリにより、コンピューターのブート時にluks
パスフレーズが尋ねられます。- root としてログインし、バックアップを復元します。
4.9.1.3. 既存デバイスへの新規パスフレーズの追加
cryptsetup luksAddKey device
4.9.1.4. 既存のデバイスからのパスフレーズ削除
cryptsetup luksRemoveKey device
4.9.1.5. Anaconda での暗号化したブロックデバイスの作成
注記
注記
kickstart
を使用すると、新たに暗号化されたブロックデバイスのパスフレーズを個別に設定することができます。
4.9.1.6. 関連情報
4.9.2. GPG 鍵の作成
4.9.2.1. GNOME での GPG 鍵の生成
- Seahorse ユーティリティーをインストールします。これにより GPG 鍵の管理が容易になります。
~]#
yum install seahorse
- 鍵を作成するには、Seahorse が起動します。→ メニューから、 を選択します。これでアプリケーション
- PGP 鍵を選択した後に をクリックします。メニューから を選択し、
- 氏名、電子メールアドレスおよび自身についての説明のオプションのコメント (例: John C. Smith,
jsmith@example.com
, Software Engineer) を入力します。 をクリックします。鍵のパスフレーズを問い合わせるダイアログが表示されます。パスフレーズは強固なだけでなく覚えやすいものを選択してください。 をクリックすると鍵が作成されます。
警告
0x6789ABCD
などのように鍵の ID の前に 0x
を付けます。秘密鍵のバックアップを取り、安全な場所に保管してください。
4.9.2.2. KDE での GPG 鍵の作成
- メインメニューからKGpg プログラムを起動します。これまで KGpg を使用したことがなければ、プログラムが独自の GPG 鍵ペアを生成するプロセスを詳しく説明します。→ → を選択して
- ダイアログボックスで、新しい鍵ペアを生成するよう求められます。名前、電子メールアドレス、およびオプションのコメントを入力します。鍵の長さ (ビット数) とアルゴリズムに加え、鍵の有効期限も選択できます。
- 次のダイアログでパスフレーズを入力します。この時点で、鍵が KGpg のメインウィンドウに表示されます。
警告
0x6789ABCD
などのように鍵の ID の前に 0x
を付けます。秘密鍵のバックアップを取り、安全な場所に保管してください。
4.9.2.3. コマンドラインを用いた GPG 鍵の生成
- 次のシェルコマンドを使用します。
~]$
gpg2 --gen-key
このコマンドにより、ペアとなる公開鍵と秘密鍵が生成されます。生成した公開鍵は、情報を受け取る側が認証に使用し、通信を復号します。公開鍵はできるだけ幅広く (特にメーリングリストなど、発信先のユーザーが、受信する通信が認証済みであることを希望する場合に) 配布します。 - 一連のプロンプトにしたがってプロセスを進めます。デフォルト値を割り当てる場合は Enter キーを押します。最初のプロンプトは、使用を希望する鍵の種類を選択するよう尋ねます。
Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) Your selection?
ほとんど多くの場合、デフォルトが適切な選択になります。RSA/RSA 鍵を選択すると、通信に署名するだけでなく、ファイルを暗号化することができます。 - 鍵のサイズを選択します。
RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048)
ここでも、デフォルトの 2048 はほとんどすべてのユーザーに適しており、これは極めて強いレベルのセキュリティーになります。 - 鍵の有効期限を選択します。デフォルトの
none
を使用するのではなく、失効日を選択する方がよいでしょう。例えば、鍵にある電子メールアドレスが無効になると、失効日が設定されているために、他の人々はその公開鍵を使用するのを止めるように通知されます。Please specify how long the key should be valid. 0 = key does not expire d = key expires in n days w = key expires in n weeks m = key expires in n months y = key expires in n years key is valid for? (0)
例えば、1y の値を入力すると、鍵の有効期間は 1 年間になります (鍵の生成後にこの失効日を変更することができます)。 - gpg2 プログラムが署名情報を尋ねる前に、以下のプロンプトが表示されます。
Is this correct (y/N)?
y
を入力してプロセスを終了します。 - GPG 鍵用に氏名と電子メールアドレスを入力します。このプロセスは、ユーザーを個人として認証するためのものです。このため、本当の名前を入力してください。偽の電子メールアドレスを選択すると、他の人があなたの公開鍵を見つけにくくなります。これにより、通信の認証が困難になります。例えば、メーリングリストの自己紹介にこの GPG 鍵を使用する場合、そのリストで使用している電子メールアドレスを入力します。コメントフィールドには、エイリアスやその他の情報を記載します。(一部の人は、目的別に複数の鍵を使用しており、「オフィス」または「オープンソースプロジェクト」などのコメントを付けてそれぞれの鍵を識別しています。)
- すべてのエントリーが正しければ、確認プロンプトで
O
と入力して続行するか、または問題がある場合はそれを修正するために他のオプションを使用します。最後に、秘密鍵のパスフレーズを入力します。gpg2 プログラムは、入力エラーがないことを確認するためにパスフレーズを 2 回入力するように指示します。 - 最後に、 gpg2 はランダムなデータを生成して鍵を可能な限り一意なものにします。このプロセスを短縮するには、この手順の実行中にマウスを動かし、ランダムなキーを入力するか、またはシステム上で他のタスクを実行します。この手順が完了すると、鍵が完成して使用可能な状態になります。
pub 1024D/1B2AFA1C 2005-03-31 John Q. Doe <jqdoe@example.com> Key fingerprint = 117C FE83 22EA B843 3E86 6486 4320 545E 1B2A FA1C sub 1024g/CEA4B22E 2005-03-31 [expires: 2006-03-31]
- 鍵のフィンガープリントは、鍵の「署名」の短縮版です。これを使って、他の人々が実際の公開鍵を (改ざんされない状態で) 受け取ったことを確認することができます。このフィンガープリントを書き留めておく必要はありません。フィンガープリントを表示するには、以下のコマンドをあなたの電子メールアドレスに置き換えて使用します。
~]$
gpg2 --fingerprint jqdoe@example.com
「GPG 鍵 の ID」は、公開鍵を識別する 16 進法の 8 文字で構成されます。上記の例では、GPG 鍵 ID は1B2AFA1C
です。多くの場合、鍵 ID を求められる際には、0x6789ABCD
などのように、鍵 ID の前に0x
を付けます。
警告
4.9.2.4. 公開鍵の暗号化について
4.9.3. 公開鍵暗号化における openCryptoki の使用
4.9.3.1. openCryptoki のインストールとサービスの起動
root
で実行します。
~]# yum install opencryptoki
pkcsslotd
デーモンを実行する必要があります。root
で以下のコマンドを実行すると、現行セッションでこのデーモンが起動します。
~]# systemctl start pkcsslotd
~]# systemctl enable pkcsslotd
4.9.3.2. openCryptoki の設定と使用
pkcsslotd
デーモンは起動後に /etc/opencryptoki/opencryptoki.conf
設定ファイルを読み込みます。このファイルは、システムと機能するように設定されたトークンとそのスロットについての情報を収集するために使用されます。
pkcsslotd
デーモンの動作を修正するには、pkcsconf
ユーティリティーを使用します。このツールを使うと、デーモンの状態の表示と設定に加え、現在設定されているスロットとトークンの一覧表示と修正がでいます。たとえば、トークンについての情報を表示するには、以下のコマンドを実行します。(pkcsslotd
デーモンと通信する必要のある root 以外のユーザーは、pkcs11
システムグループに属している必要があることに注意してください)
~]$ pkcsconf -t
pkcsconf
ツールで利用可能な引数の一覧は、man ページの pkcsconf(1) を参照してください。
警告
pkcs11
グループには、完全に信頼できるユーザーのみを割り当ててください。このグループのメンバーは、openCryptoki サービスの他のユーザーが設定済み PKCS#11 トークンへアクセスできなくすることができます。またこのグループのメンバーは、openCryptoki の他のユーザーの権限で任意のコードを実行することができます。
4.9.4. OpenSSH に認証情報を提供するスマートカードの使用
~/.ssh/authorized_keys
ファイルに保存して、クライアント上で opensc パッケージで提供される PKCS#11
ライブラリーをインストールします。PKCS#11
は Public-Key Cryptography Standard のことで、トークンと呼ばれる暗号化デバイスにアプリケーションプログラミングインターフェース (API) を定義します。root
で以下のコマンドを実行してください。
~]#
yum install opensc
4.9.4.1. カードからの公開鍵の取得
ssh-keygen
コマンドを使用します。-D
ディレクティブで共有ライブラリー (以下の例では OpenSC) を指定します。
~]$
ssh-keygen -D /usr/lib64/pkcs11/opensc-pkcs11.so
ssh-rsa AAAAB3NzaC1yc[...]+g4Mb9
4.9.4.2. サーバーへの公開鍵の保存
smartcard.pub
) にキーを保存して、ssh-copy-id
コマンドを使用してください。
~]$
ssh-copy-id -f -i smartcard.pub user@hostname
user@hostname's password: Number of key(s) added: 1 Now try logging into the machine, with: "ssh user@hostname" and check to make sure that only the key(s) you wanted were added.
SSH_COPY_ID_LEGACY=1
環境変数または -f
オプションを使用する必要があります。
4.9.4.3. スマートカード上の鍵を使用したサーバーの認証
[localhost ~]$
ssh -I /usr/lib64/pkcs11/opensc-pkcs11.so hostname
Enter PIN for 'Test (UserPIN)':[hostname ~]$
~/.ssh/config
ファイルに PKCS#11
ライブラリーへのパスを保存します。
Host hostname PKCS11Provider /usr/lib64/pkcs11/opensc-pkcs11.so
ssh
コマンドを実行して接続します。
[localhost ~]$
ssh hostname
Enter PIN for 'Test (UserPIN)':[hostname ~]$
4.9.4.4. PIN でのログインを自動化するための ssh-agent
の使用
ssh-agent
を使用するように、環境変数を設定します。通常のセッションでは ssh-agent
はすでに実行されているので、多くの場合、この手順を省略できます。以下のコマンドを使用して、認証エージェントに接続できるかどうかを確認してください。
~]$
ssh-add -l
Could not open a connection to your authentication agent.~]$
eval `ssh-agent`
~]$
ssh-add -s /usr/lib64/pkcs11/opensc-pkcs11.so
Enter PIN for 'Test (UserPIN)': Card added: /usr/lib64/pkcs11/opensc-pkcs11.so
ssh-agent
からカードを削除するには、以下のコマンドを実行します。
~]$
ssh-add -e /usr/lib64/pkcs11/opensc-pkcs11.so
Card removed: /usr/lib64/pkcs11/opensc-pkcs11.so
注記
/etc/opensc-x86_64.conf
ファイルの pin_cache_ignore_user_consent = true;
オプションの前に付いている # 文字を削除してください。
4.9.4.5. 関連情報
PKCS#11
セキュリティートークンを管理および使用する pkcs11-tool ユーティリティーの詳細は、man ページの pkcs11-tool(1)
を参照してください。
4.9.5. 信頼できる鍵および暗号化された鍵
RSA
鍵を使ってこの鍵を保護します。
AES
暗号化を使用するので、TPM を必要とせず、信頼できる鍵よりもスピーディーになります。暗号化された鍵は、カーネル生成の任意の数を使って作成され、ユーザースペースブロブにエクスポートされる際に マスターキー で暗号化されます。このマスターキーは、信頼できる鍵かユーザーキーとすることができます。後者の場合、暗号化された鍵の安全性は、ユーザーキーによる暗号化と同等のものでしかないという欠点があります。
4.9.5.1. 鍵を使った作業
root
ユーザーで以下のコマンドを実行して、これらモジュールの両方を同時に読み込みます。
~]# modprobe trusted encrypted-keys
注記
tpm_setactive
コマンドを使用するとできます。また、TrouSers アプリケーション (trousers パッケージ) のインストールと、TrouSers スイートの一部である tcsd
デーモンが稼働して TPM と通信している必要もあります。
keyctl
コマンドを実行します。
keyctl add trusted name "new keylength [options]" keyring
~]$ keyctl add trusted kmk "new 32" @u
642500861
kmk
と呼ばれる 32 バイト (256 ビット) の長さの信頼できる鍵が作成され、ユーザーキーリング (@u
) に置かれます。この鍵は、32 から 128 バイト (256 から 1024 ビット) の長さになります。show
サブコマンドを使ってカーネルキーリングの現在の構成を一覧表示します。
~]$ keyctl show
Session Keyring
-3 --alswrv 500 500 keyring: _ses
97833714 --alswrv 500 -1 \_ keyring: _uid.1000
642500861 --alswrv 500 500 \_ trusted: kmk
print
サブコマンドは、暗号化された鍵を標準出力に出します。この鍵をユーザースペースのブロブにエクスポートするには、以下のように pipe
サブコマンドを使用します。
~]$ keyctl pipe 642500861 > kmk.blob
add
コマンドでブロブを引数として使用します。
~]$ keyctl add trusted kmk "load `cat kmk.blob`" @u
268728824
~]$ keyctl add encrypted name "new [format] key-type:master-key-name keylength" keyring
~]$ keyctl add encrypted encr-key "new trusted:kmk 32" @u
159771175
~]$ keyctl add user kmk-user "`dd if=/dev/urandom bs=1 count=32 2>/dev/null`" @u
427069434
~]$ keyctl add encrypted encr-key "new user:kmk-user 32" @u
1012412758
list
サブコマンドを使うと、指定されたカーネルキーリング内のすべての鍵を一覧表示できます。
~]$ keyctl list @u
2 keys in keyring:
427069434: --alswrv 1000 1000 user: kmk-user
1012412758: --alswrv 1000 1000 encrypted: encr-key
重要
4.9.5.2. 関連情報
インストールされているドキュメント
- keyctl(1) - keyctl ユーティリティーおよびそのサブコマンドの使用方法を説明しています。
オンラインのドキュメント
- Red Hat Enterprise Linux 7 SELinux User's and Administrator's Guide — Red Hat Enterprise Linux 7 の 『SELinux User's and Administrator's Guide』 では、SELinux の原則と、SELinux を設定して Apache HTTP Server などのさまざまなサービスで使用する方法が詳細に説明されています。
- https://www.kernel.org/doc/Documentation/security/keys-trusted-encrypted.txt — Linux カーネルの信頼できる鍵および暗号化された鍵に関する機能についての公式ドキュメントです。
関連項目
- 「高度暗号化標準 — AES」 では、
Advanced Encryption Standard
(高度暗号化標準) について簡単に説明しています。 - 「公開鍵暗号」 では、公開鍵の暗号化のアプローチとそこで使用される様々な暗号化プロトコルについて説明しています。
4.9.6. 乱数ジェネレーターの使用
rngd
デーモンは、エントロピーを引き出すために環境ノイズと乱数ジェネレーターの両方が使えます。このデーモンは、乱数度のソースが提供したデータがランダムかどうかをチェックし、その後にカーネルの乱数エントロピープールに保存します。これが生成した乱数は、/dev/random
および /dev/urandom
の各キャラクターデバイスから利用できます。
/dev/random
と /dev/urandom
の違いは、前者はブロックデバイスであり、適切な乱数出力の生成にエントロピーが不十分だと判断すると、乱数の提供が停止される一方で、/dev/urandom
は非ブロックソースであり、カーネルのエントロピープールを再利用して無制限の仮の乱数を提供できる、という点です。ただし、この場合のエントロピーは低くなります。このため、長期の暗号鍵の作成には、/dev/urandom
は使用しないでください。
root
で以下のコマンドを実行します。
~]# yum install rng-tools
rngd
デーモンを起動するには、root
で以下のコマンドを実行します。
~]# systemctl start rngd
~]# systemctl status rngd
rngd
デーモンを起動するには、直接これを実行します。たとえば、乱数入力の代替ソース (/dev/hwrandom
以外) を指定するには、以下のコマンドを実行します。
~]# rngd --rng-device=/dev/hwrng
/dev/hwrng
を乱数読み取り先のデバイスとして rngd
デーモンを起動します。同様に、-o
(または --random-device
) オプションを使用すると、乱数の出力に (デフォルトの /dev/random
ではなく) カーネルデバイスを選択します。利用可能なオプションは、man ページの rngd(8) を参照してください。
root
として実行します。
~]# rngd -vf
Unable to open file: /dev/tpm0
Available entropy sources:
DRNG
注記
rngd -v
コマンドを実行すると、そのプロセスはバックグラウンドで実行します。-b
、--background
オプション (デーモンになります) はデフォルトで適用されます。
~]$ cat /proc/cpuinfo | grep rdrand
注記
/dev/random
の出力の乱数度をテストするには、以下のように rngtest ツールを使用します。
~]$ cat /dev/random | rngtest -c 1000
rngtest 5
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 998
rngtest: FIPS 140-2 failures: 2
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 2
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=1.171; avg=8.453; max=11.374)Mibits/s
rngtest: FIPS tests speed: (min=15.545; avg=143.126; max=157.632)Mibits/s
rngtest: Program run time: 2390520 microseconds
/dev/random
経由で) フィードし、QEMU は、ゲストが要求したエントロピーのソースとして /dev/random
を使用します。

図4.1 virtio RNG デバイス
重要
4.10. ポリシーベースの複号を使用して暗号化ボリュームの自動アンロックの設定
4.10.1. NBDE (Network-Bound Disk Encryption)

図4.2 Clevis および Tang を使用する NBDE (Network-Bound Disk Encryption)
/tmp
、/var
、/usr/local/
ディレクトリーを持ち、ネットワーク接続が確立される前に開始する必要のあるファイルシステムを含むすべての LUKS 暗号化デバイスは、root ボリューム として考慮されます。また、ネットワークが起動する前にサービス実行で使用されるすべてのマウントポイント (/var/log/
、var/log/audit/
、/opt
) も、root デバイスに切り替えた後にすぐにマウントする必要があります。root ボリュームは /etc/fstab
ファイルに _netdev
オプションを指定しなくても識別できます。
4.10.2. 暗号化クライアント (Clevis) のインストール
root
で以下のコマンドを実行します。
~]# yum install clevis
clevis decrypt
コマンドを実行して、暗号文 (JWE) を提供します。
~]$ clevis decrypt < JWE > PLAINTEXT
~]$clevis
Usage: clevis COMMAND [OPTIONS] clevis decrypt Decrypts using the policy defined at encryption time clevis encrypt http Encrypts using a REST HTTP escrow server policy clevis encrypt sss Encrypts using a Shamir's Secret Sharing policy clevis encrypt tang Encrypts using a Tang binding server policy clevis encrypt tpm2 Encrypts using a TPM2.0 chip binding policy ~]$clevis decrypt
Usage: clevis decrypt < JWE > PLAINTEXT Decrypts using the policy defined at encryption time ~]$clevis encrypt tang
Usage: clevis encrypt tang CONFIG < PLAINTEXT > JWE Encrypts using a Tang binding server policy This command uses the following configuration properties: url: <string> The base URL of the Tang server (REQUIRED) thp: <string> The thumbprint of a trusted signing key adv: <string> A filename containing a trusted advertisement adv: <object> A trusted advertisement (raw JSON) Obtaining the thumbprint of a trusted signing key is easy. If you have access to the Tang server's database directory, simply do: $ jose jwk thp -i $DBDIR/$SIG.jwk Alternatively, if you have certainty that your network connection is not compromised (not likely), you can download the advertisement yourself using: $ curl -f $URL/adv > adv.jws
4.10.3. SELinux を Enforcing モードした Tang サーバーのデプロイメント
tangd_port_t
SELinux タイプを利用できます。Tang サーバーは、SELinux Enforcing モードで制限のあるサービスとしてデプロイできます。
前提条件
- policycoreutils-python-utils パッケージおよび依存関係がインストールされている。
手順
- tang パッケージおよびその依存関係をインストールするには、
root
で以下のコマンドを実行します。~]#
yum install tang
- 7500/tcp などの使用してないポートを選択し、tangd サービスがそのポートにバインドできるようにします。
~]#
semanage port -a -t tangd_port_t -p tcp 7500
1 つのサービスに使用できるポートは 1 つのみです。つまり、すでに使用しているポートを使用しようとすると、ValueError: Port already defined
エラーメッセージが表示されます。 - ファイアウォールのポートを開きます。
~]#
firewall-cmd --add-port=7500/tcp
~]#firewall-cmd --runtime-to-permanent
- systemd を使用して
tangd
サービスを有効にします。~]#
systemctl enable tangd.socket
Created symlink from /etc/systemd/system/multi-user.target.wants/tangd.socket to /usr/lib/systemd/system/tangd.socket. - 上書きファイルを作成します。
~]#
systemctl edit tangd.socket
- 以下のエディター画面で、
/etc/systemd/system/tangd.socket.d/
ディレクトリーで空のoverride.conf
ファイルが開きます。このファイルで、Tang サーバーのデフォルトポートを 80 から、以前取得した番号に変更します。[Socket] ListenStream= ListenStream=7500
ファイルを保存してエディターを終了します。 - 変更した設定を再読み込みして、
tangd
サービスを起動します。~]#
systemctl daemon-reload
- 設定が機能していることを確認します。
~]#
systemctl show tangd.socket -p Listen
Listen=[::]:7500 (Stream) tangd
サービスを起動します。~]#
systemctl start tangd.socket
tangd
は、systemd
ソケットアクティベーションメカニズムを使用しているため、最初に接続するとすぐにサーバーが起動します。最初の起動時に、新しい一組の暗号鍵が自動的に生成されます。
jose
ユーティリティーを使用します。詳細は、jose -h
コマンドを実行するか、man ページの jose(1)
を参照してください。
例4.4 Tang 鍵の変更
/var/db/tang
) に新しい鍵を生成するところから始めます。たとえば、以下のコマンドを使用して、新しい署名を作成し、鍵を交換します。
~]#DB=/var/db/tang
~]#jose jwk gen -i '{"alg":"ES512"}' -o $DB/new_sig.jwk
~]#jose jwk gen -i '{"alg":"ECMR"}' -o $DB/new_exc.jwk
.
を付けます。以下の例のファイル名は、鍵データベースディレクトリーに実在する固有のファイル名とは異なります。
~]#mv $DB/old_sig.jwk $DB/.old_sig.jwk
~]#mv $DB/old_exc.jwk $DB/.old_exc.jwk
警告
4.10.3.1. 高可用性システムのデプロイメント
- クライアントの冗長性 (推奨)クライアントは、複数の Tang サーバーにバインドする機能を使用して設定する必要があります。この手順では、各 Tang サーバーには独自の鍵があり、クライアントは、このサーバーのサブセットに接続することで複号できるようになります。Clevis では、以前からこのワークフローを
sss
プラグインによりサポートしています。この設定の詳細は、以下の man ページを参照してください。tang(8)
の高可用性 (High Availability) セクションclevis(1)
のシャミアの秘密共有 (Shamir's Secret Sharing) セクションclevis-encrypt-sss(1)
Red Hat では、高可用性デプロイメントにこの方法を使用することを推奨します。 - 鍵共有冗長性のために、Tang のインスタンスは複数デプロイできます。2 つ目以降のインスタンスを設定するには、tang パッケージをインストールし、SHH で
rsync
を使用して、重要なディレクトリーを新しいホストにコピーします。鍵を共有すると、重大な不正アクセスのリスクを増やし、別の自動化インフラストラクチャーが必要となるため、Red Hat はこの方法を推奨しません。
4.10.4. Tang を使用する NBDE システムへの暗号化クライアントのデプロイメント
前提条件
- Clevis フレームワークがインストールされている。「暗号化クライアント (Clevis) のインストール」 を参照してください。
- Tang サーバーが利用可能である。「SELinux を Enforcing モードした Tang サーバーのデプロイメント」 を参照してください。
手順
clevis encrypt tang
サブコマンドを使用します。
~]$ clevis encrypt tang '{"url":"http://tang.srv"}' < PLAINTEXT > JWE
The advertisement contains the following signing keys:
_OsIk0T-E2l6qjfdDiwVmidoZjA
Do you wish to trust these keys? [ynYN] y
clevis decrypt
コマンドを実行して、暗号文 (JWE) を提供します。
~]$ clevis decrypt < JWE > PLAINTEXT
clevis-encrypt-tang(1)
か、組み込みの CLI ヘルプを参照してください。
~]$clevis
Usage: clevis COMMAND [OPTIONS] clevis decrypt Decrypts using the policy defined at encryption time clevis encrypt http Encrypts using a REST HTTP escrow server policy clevis encrypt sss Encrypts using a Shamir's Secret Sharing policy clevis encrypt tang Encrypts using a Tang binding server policy clevis encrypt tang Encrypts using a Tang binding server policy clevis luks bind Binds a LUKSv1 device using the specified policy clevis luks unlock Unlocks a LUKSv1 volume ~]$clevis decrypt
Usage: clevis decrypt < JWE > PLAINTEXT Decrypts using the policy defined at encryption time ~]$clevis encrypt tang
Usage: clevis encrypt tang CONFIG < PLAINTEXT > JWE Encrypts using a Tang binding server policy This command uses the following configuration properties: url: <string> The base URL of the Tang server (REQUIRED) thp: <string> The thumbprint of a trusted signing key adv: <string> A filename containing a trusted advertisement adv: <object> A trusted advertisement (raw JSON) Obtaining the thumbprint of a trusted signing key is easy. If you have access to the Tang server's database directory, simply do: $ jose jwk thp -i $DBDIR/$SIG.jwk Alternatively, if you have certainty that your network connection is not compromised (not likely), you can download the advertisement yourself using: $ curl -f $URL/adv > adv.jws
4.10.5. TPM 2.0 ポリシーを使用した暗号化クライアントのデプロイメント
clevis encrypt tpm2
サブコマンドを使用します。
~]$ clevis encrypt tpm2 '{}' < PLAINTEXT > JWE
~]$ clevis encrypt tpm2 '{"hash":"sha1","key":"rsa"}' < PLAINTEXT > JWE
~]$ clevis decrypt < JWE > PLAINTEXT
~]$ clevis encrypt tpm2 '{"pcr_bank":"sha1","pcr_ids":"0,1"}' < PLAINTEXT > JWE
clevis-encrypt-tpm2(1)
を参照してください。
4.10.6. root ボリュームの手動登録の設定
clevis luks bind
コマンドを使用して Tang サーバーにボリュームをバインドします。
~]# yum install clevis-luks
~]# clevis luks bind -d /dev/sda tang '{"url":"http://tang.srv"}'
The advertisement contains the following signing keys:
_OsIk0T-E2l6qjfdDiwVmidoZjA
Do you wish to trust these keys? [ynYN] y
You are about to initialize a LUKS device for metadata storage.
Attempting to initialize it may result in data loss if data was
already written into the LUKS header gap in a different format.
A backup is advised before initialization is performed.
Do you wish to initialize /dev/sda? [yn] y
Enter existing LUKS password:
- LUKS マスター鍵と同じエントロピーを使用して、新しい鍵を作成します。
- Clevis で新しい鍵を暗号化します。
- LUKSMeta を使用して LUKS ヘッダーに Clevis JWE オブジェクトを保存します。
- LUKS を使用するために新しい鍵を有効にします。
clevis-luks-bind(1)
を参照してください。
注記
clevis luks bind
コマンドは、そのスロットを 1 つ取ります。
luksmeta show
コマンドを使用します。
~]# luksmeta show -d /dev/sda
0 active empty
1 active cb6e8904-81ff-40da-a84a-07ab9ab5715e
2 inactive empty
3 inactive empty
4 inactive empty
5 inactive empty
6 inactive empty
7 inactive empty
~]#yum install clevis-dracut
~]#dracut -f --regenerate-all
重要
~]# dracut -f --regenerate-all --kernel-cmdline "ip=192.0.2.10 netmask=255.255.255.0 gateway=192.0.2.1 nameserver=192.0.2.45"
/etc/dracut.conf.d/
ディレクトリーに .conf ファイルを作成します。
~]# cat /etc/dracut.conf.d/static_ip.conf
kernel_cmdline="ip=10.0.0.103 netmask=255.255.252.0 gateway=10.0.0.1 nameserver=10.0.0.1"
~]# dracut -f --regenerate-all
dracut.cmdline(7)
を参照してください。
4.10.7. キックスタートを使用した自動登録の設定
- LUKS 暗号化が、
/boot
以外のすべてのマウントポイントに対して有効にしたディスクを分割するようにキックスタートに指示します。このパスワードは、登録プロセスのこの手順に一時的なものです。part /boot --fstype="xfs" --ondisk=vda --size=256 part / --fstype="xfs" --ondisk=vda --grow --encrypted --passphrase=temppass
OSPP 対応システムには、以下のようなより複雑な設定が必要なことに注意してください。part /boot --fstype="xfs" --ondisk=vda --size=256 part / --fstype="xfs" --ondisk=vda --size=2048 --encrypted --passphrase=temppass part /var --fstype="xfs" --ondisk=vda --size=1024 --encrypted --passphrase=temppass part /tmp --fstype="xfs" --ondisk=vda --size=1024 --encrypted --passphrase=temppass part /home --fstype="xfs" --ondisk=vda --size=2048 --grow --encrypted --passphrase=temppass part /var/log --fstype="xfs" --ondisk=vda --size=1024 --encrypted --passphrase=temppass part /var/log/audit --fstype="xfs" --ondisk=vda --size=1024 --encrypted --passphrase=temppass
- 関連する Clevis パッケージを
%packages
セクションに追加して、インストールします。%packages clevis-dracut %end
clevis luks bind
を呼び出して、%post
セクションのバインディングを実行します。その後、一時パスワードを削除します。%post clevis luks bind -f -k- -d /dev/vda2 \ tang '{"url":"http://tang.srv","thp":"_OsIk0T-E2l6qjfdDiwVmidoZjA"}' \ <<< "temppass" cryptsetup luksRemoveKey /dev/vda2 <<< "temppass" %end
上記の例では、Tang サーバーをバインディング設定の一部として Tang サーバーで信頼するサムプリントを指定して、バインディングを完全に非対話にできます。Tang サーバーの代わりに TPM 2.0 ポリシーを使用する場合は、類似の手順を使用できます。
4.10.8. リムーバブルストレージデバイスの自動アンロックの設定
~]# yum install clevis-udisks2
clevis luks bind
コマンドを使用したバインディング手順を実行します。以下に例を示します。
~]# clevis luks bind -d /dev/sdb1 tang '{"url":"http://tang.srv"}'
clevis luks unlock
コマンドでアンロックできます。
~]# clevis luks unlock -d /dev/sdb1
4.10.9. 起動時に非 root ボリュームの自動アンロックの設定
- clevis-systemd パッケージをインストールします。
~]#
yum install clevis-systemd
- Clevis のアンロックサービスを有効にします。
~]#
systemctl enable clevis-luks-askpass.path
Created symlink from /etc/systemd/system/remote-fs.target.wants/clevis-luks-askpass.path to /usr/lib/systemd/system/clevis-luks-askpass.path. - 「root ボリュームの手動登録の設定」 の説明通りに
clevis luks bind
コマンドを使用してバインド手順を実行します。 - システムの起動時に暗号化したブロックデバイスを設定するには、
_netdev
オプションに相当する行を/etc/crypttab
設定ファイルに追加します。詳細は man ページのcrypttab(5)
を参照してください。 /etc/fstab
ファイルでアクセス可能なファイルシステムの一覧にボリュームを追加します。また、この設定ファイルで_netdev
オプションを使用します。詳細は man ページのfstab(5)
を参照してください。
4.10.10. NBDE ネットワークで仮想マシンのデプロイメント
clevis luks bind
コマンドは、LUKS マスターキーを変更しません。これは、仮想マシンまたはクラウド環境で使用するためにLUKS で暗号化したイメージを作成する場合に、このイメージを実行するすべてのインスタンスがマスター鍵を共有することを意味します。これはセキュリティーに関して大きな問題があるため、常に回避する必要があります。
4.10.11. NBDE を使用してクラウド環境に自動的に登録可能な VM イメージの構築
重要
4.10.12. 関連情報
tang(8)
clevis(1)
jose(1)
clevis-luks-unlockers(1)
tang-nagios(1)
4.11. AIDE との整合性の確認
4.11.1. AIDE のインストール
root
で以下のコマンドを実行します。
~]# yum install aide
root
として入力します。
~]# aide --init
AIDE, version 0.15.1
### AIDE database at /var/lib/aide/aide.db.new.gz initialized.
注記
aide --init
コマンドは、/etc/aide.conf
ファイルで定義するディレクトリーとファイルのセットだけを確認します。ディレクトリーまたはファイルを AIDE データベースに追加し、監視パラメーターを変更するには、/etc/aide.conf
を変更します。
.new
を削除します。
~]# mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
/etc/aide.conf
ファイルで DBDIR
値を変更します。追加のセキュリティーについては、データベース、設定、/usr/sbin/aide
バイナリーファイルを、読み取り専用メディアなどの安全な場所に保存します。
重要
4.11.2. 整合性確認の実行
root
で以下のコマンドを実行します。
~]# aide --check
AIDE 0.15.1 found differences between database and filesystem!!
Start timestamp: 2017-03-30 14:12:56
Summary:
Total number of files: 147173
Added files: 1
Removed files: 0
Changed files: 2
...
cron
を使用して、毎日 4:05 am に AIDE を実行するようにスケジュールする (『システム管理者のガイド』の 「システムタスクの自動化」 の章を参照) には、以下の行を /etc/crontab
に追加します。
05 4 * * * root /usr/sbin/aide --check
4.11.3. AIDE データベースの更新
~]# aide --update
aide --update
コマンドが /var/lib/aide/aide.db.new.gz
データベースファイルを作成します。整合性の確認にこれを使用するには、ファイル名から従属文字列 .new
を削除します。
4.11.4. 関連情報
- man ページの
aide(1)
- man ページの
aide.conf(5)
4.12. USBGuard の使用
- 動的対話およびポリシー強制に関する IPC (inter-process communication) インターフェースを使用したデーモンコンポーネント
- 実行中の USBGuard インスタンスと対話するコマンドラインインターフェース
- USB デバイス認証ポリシーを記述するルール言語
- 共有ライブラリーに実装したデーモンコンポーネントと対話する C++ API
4.12.1. USBGuard のインストール
root
で以下のコマンドを実行します。
~]# yum install usbguard
root
で以下のコマンドを実行します。
~]# usbguard generate-policy > /etc/usbguard/rules.conf
注記
/etc/usbguard/rules.conf
ファイルを変更します。詳細は、man ページの usbguard-rules.conf(5)
を参照してください。使用例は 「ルール言語を使用した独自ポリシーの作成」 を参照してください。
root
で以下のコマンドを実行します。
~]#systemctl start usbguard.service
~]#systemctl status usbguard
● usbguard.service - USBGuard daemon Loaded: loaded (/usr/lib/systemd/system/usbguard.service; disabled; vendor preset: disabled) Active: active (running) since Tue 2017-06-06 13:29:31 CEST; 9s ago Docs: man:usbguard-daemon(8) Main PID: 4984 (usbguard-daemon) CGroup: /system.slice/usbguard.service └─4984 /usr/sbin/usbguard-daemon -k -c /etc/usbguard/usbguard-daem...
root
で以下のコマンドを実行します。
~]# systemctl enable usbguard.service
Created symlink from /etc/systemd/system/basic.target.wants/usbguard.service to /usr/lib/systemd/system/usbguard.service.
root
で以下のコマンドを実行します。
~]# usbguard list-devices
1: allow id 1d6b:0002 serial "0000:00:06.7" name "EHCI Host Controller" hash "JDOb0BiktYs2ct3mSQKopnOOV2h9MGYADwhT+oUtF2s=" parent-hash "4PHGcaDKWtPjKDwYpIRG722cB9SlGz9l9Iea93+Gt9c=" via-port "usb1" with-interface 09:00:00
...
6: block id 1b1c:1ab1 serial "000024937962" name "Voyager" hash "CrXgiaWIf2bZAU+5WkzOE7y0rdSO82XMzubn7HDb95Q=" parent-hash "JDOb0BiktYs2ct3mSQKopnOOV2h9MGYADwhT+oUtF2s=" via-port "1-3" with-interface 08:06:50
allow-device
オプションを使用します。
~]# usbguard allow-device 6
reject-device
オプションを使用します。デバイスの認証解除だけを行う場合は、usbguard
コマンドに block-device
オプションを付けて使用します。
~]# usbguard block-device 6
- block - 今は、このデバイスとはやりとりしない
- reject - このデバイスが存在していないかのように、無視する
usbguard
コマンドのオプションをすべて表示するには、以下のように、--help
ディレクティブを付けて実行します。
~]$ usbguard --help
4.12.2. ホワイトリストおよびブラックリストの作成
usbguard-daemon.conf
ファイルは、コマンドラインオプションを解析したあと、usbguard
デーモンによりロードされ、デーモンのランタイムパラメーターを設定するために使用されます。デフォルトの設定ファイル (/etc/usbguard/usbguard-daemon.conf
) を上書きするには、-c
コマンドラインオプションを使用します。詳細は、man ページの usbguard-daemon(8)
を参照してください。
usbguard-daemon.conf
ファイルを編集し、以下のオプションを使用します。
USBGuard 設定ファイル
RuleFile=
<path>usbguard
デーモンはこのファイルを使用して、それからポリシールールセットをロードし、IPC インターフェース経由で受け取った新しいルールを記述します。IPCAllowedUsers=
<username> [<username> ...]- このデーモンが IPC 接続を許可するユーザー名の、スペース区切りの一覧。
IPCAllowedGroups=
<groupname> [<groupname> ...]- このデーモンが IPC 接続を許可するグループ名の、スペース区切りの一覧。
IPCAccessControlFiles=
<path>- IPC アクセス制御ファイルを保持するディレクトリーへのパス
ImplicitPolicyTarget=
<target>- ポリシー内のどのルールにも一致しないデバイスを扱う方法。許容される値は allow、block、および reject です。
PresentDevicePolicy=
<policy>- デーモンが起動するときにすでに接続されているデバイスを処理する方法。
- allow - 存在するデバイスをすべて認証する
- block - 存在するデバイスの認証をすべて解除する
- reject - 存在するデバイスをすべて削除する
- keep - 内部ステータスの同期だけを行う
- apply-policy - 存在するすべてのデバイスに対してルールセットを評価する
PresentControllerPolicy=
<policy>- デーモンが起動するときにすでに接続されている USB コントローラーの処理方法
- allow - 存在するデバイスをすべて認証する
- block - 存在するデバイスの認証をすべて解除する
- reject - 存在するデバイスをすべて削除する
- keep - 内部ステータスの同期だけを行う
- apply-policy - 存在するすべてのデバイスに対してルールセットを評価する
例4.5 USBGuard 設定
usbguard
デーモンが、/etc/usbguard/rules.conf
ファイルからルールをロードし、usbguard
グループのユーザーだけが IPC インターフェースを使用できるようにします。
RuleFile=/etc/usbguard/rules.conf IPCAccessControlFiles=/etc/usbguard/IPCAccessControl.d/
usbguard add-user
コマンドまたは usbguard remove-user
コマンドを使用します。詳細は usbguard(1)
を参照してください。この例では、usbguard
グループのユーザーだけが、USB デバイス認証ステータスの修正、USB デバイスの一覧表示、例外イベントのリッスン、および USB 認証ポリシーの一覧表示を可能にするには、root
で以下のコマンドを実行します。
~]# usbguard add-user -g usbguard --devices=modify,list,listen --policy=list --exceptions=listen
重要
root
ユーザーにのみ制限されます。IPCAccessControlFiles
オプション (推奨)、または IPCAllowedUsers
オプションおよび IPCAllowedGroups
オプションを設定して IPC インターフェースへのアクセスを制御することを検討してください。ACL は未設定のままにしないでください。未設定のままにすると IPC インターフェースがすべてのローカルユーザーに公開され、USB デバイスの認証状態を操作し、USBGuard ポリシーを修正できるようになります。
usbguard-daemon.conf(5)
の IPC アクセス制御セクションを参照してください。
4.12.3. ルール言語を使用した独自ポリシーの作成
usbguard
デーモンは、ルールセットが定義するポリシーに基づいて USB デバイスを認証するかどうかを決定します。USB デバイスがシステムに挿入されると、デーモンが既存のルールを順次スキャンし、一致ルールが見つかると、ルールのターゲットに基づいて認証 (allows)、認証解除 (blocks)、または削除 (rejects) します。一致するルールが見つからない場合、決定は暗黙のデフォルトターゲットに基づいています。暗黙のデフォルトは、ユーザーが決定を行うまで、デバイスをブロックします。
rule ::= target device_id device_attributes conditions. target ::= "allow" | "block" | "reject". device_id ::= "*:*" | vendor_id ":*" | vendor_id ":" product_id. device_attributes ::= device_attributes | attribute. device_attributes ::= . conditions ::= conditions | condition. conditions ::= .
usbguard-rules.conf(5)
を参照してください。
例4.6 USBguard のサンプルポリシー
- Allow USB mass storage devices and block everything else
- このポリシーは、大容量のストレージデバイス以外のデバイスをブロックするだけではありません。USB フラッシュディスクで非表示のキーボードインターフェースを持つデバイスがブロックされます。1 つの大容量ストレージインターフェースを持つデバイスだけがオペレーティングシステムと対話できます。ポリシーは、以下のような 1 つのルールで構成されます。
allow with-interface equals { 08:*:* }
ブロックルールがないため、ブロックは暗黙的です。暗黙ブロックは、暗黙的ターゲットがデバイスに対して選択される場合に、USBGuard イベントをリッスンさせるデスクトップアプレットがユーザーに決定を求めることができるため、デスクトップユーザーに便利です。 - 特定の Yubikey デバイスが、特定ポートを経由して接続できるようにします。
- そのポートでその他のすべてのものを拒否します。
allow 1050:0011 name "Yubico Yubikey II" serial "0001234567" via-port "1-2" hash "044b5e168d40ee0245478416caf3d998" reject via-port "1-2"
- インターフェースの疑わしい組み合わせを持つデバイスを拒否します。
- キーボードまたはネットワークインターフェースを実装する USB フラッシュディスクは非常に疑わしくなります。以下のルールセットは、USB フラッシュディスクを許可して、疑わしいインターフェースを追加して、デバイスを明示的に拒否するポリシーを形成します。
allow with-interface equals { 08:*:* } reject with-interface all-of { 08:*:* 03:00:* } reject with-interface all-of { 08:*:* 03:01:* } reject with-interface all-of { 08:*:* e0:*:* } reject with-interface all-of { 08:*:* 02:*:* }
注記
ブラックリストはアプローチとしては間違っており、一連のデバイスをブラックリストに登録して残りを許可するような設定は行わないでください。。上述のポリシーは、ブロックが暗黙的なデフォルトであることを前提としています。「問題のある」ものとみなされる一連のデバイスを拒否するアプローチとは、そのようなデバイスへのシステムの公開をできるだけ制限する方法としては適切な方法となります。 - キーボードのみの USB デバイスを許可
- 以下のルールは、キーボードインターフェースがすでに許可されている USB デバイスがない場合に限り、キーボードのみの USB デバイスを許可します。
allow with-interface one-of { 03:00:01 03:01:01 } if !allowed-matches(with-interface one-of { 03:00:01 03:01:01 })
usbguard generate-policy
コマンドを使用して初期ポリシーを生成したら、/etc/usbguard/rules.conf
を編集して USBGuard ポリシールールをカスタマイズします。
~]$usbguard generate-policy > rules.conf
~]$vim rules.conf
~]# install -m 0600 -o root -g root rules.conf /etc/usbguard/rules.conf
4.12.4. その他のリソース
- man ページの
usbguard(1)
- man ページの
usbguard-rules.conf(5)
- man ページの
usbguard-daemon(8)
- man ページの
usbguard-daemon.conf(5)
4.13. TLS 設定の強化
TLS
(トランスポート層セキュリティー
) は、ネットワーク通信をセキュアにするのに使用する暗号化プロトコルです。優先する 鍵交換プロトコル、認証方法、および 暗号化アルゴリズム を設定してシステムのセキュリティー設定を強化する場合は、サポートするクライアントの範囲が広ければ広いほど、セキュリティーのレベルが低くなることに注意してください。反対に、セキュリティー設定を厳密にすると、クライアントとの互換性が制限され、システムからロックアウトされるユーザーが出てくる可能性もあります。可能な限り厳密な設定を目指し、互換性のために必要な場合にのみ、これを緩めるようにしてください。
TLS
実装は、可能な場合はセキュアなアルゴリズムを使用する一方で、レガシークライアントまたはサーバーとの接続を妨げません。セキュアなアルゴリズムやプロトコルをサポートしていないレガシーのクライアントやサーバーの接続が期待できない場合やそれらの接続が許可されない場合に、厳密なセキュリティー要件の環境で本セクションで説明されている強化設定を適用してください。
4.13.1. 有効にするアルゴリズムの選択
プロトコルのバージョン
TLS
は、すぐれたセキュリティーメカニズムを提供します。古いバージョンの TLS
(さらに SSL
) のサポートを含める切実な理由がなければ、最新バージョンの TLS
のみを使ってシステムが接続するようにしてください。
SSL
のバージョン 2 または 3 を使った処理を許可しないでください。これらのバージョンには、セキュリティーに関する重大な脆弱性があります。TLS
のバージョン 1.0 以上を使った処理のみを許可してください。現行の TLS
バージョン 1.2 を常に優先するようにしてください。
注記
TLS
の全バージョンのセキュリティーは現在、TLS
拡張機能、特定の暗号 (下記参照)、および他の回避策に依存していることに注意してください。TLS
の接続ピアはすべてセキュアな再交渉記号 (RFC 5746) を実装する必要があり、圧縮をサポートしていない必要があります。また、CBC
モードの暗号 (Lucky Thirteen 攻撃) に対するタイミング攻撃を緩和する方法を実装する必要があります。TLS 1.0
クライアントはさらに、レコード分割 (BEAST 攻撃に対する回避策) を実装する必要があります。TLS 1.2
は、AES-GCM
、AES-CCM
、または Camellia-GCM
といった既知の問題のない 認証付き暗号 (Authenticated Encryption with Associated Data : AEAD) モードの暗号をサポートしています。ここに記載された緩和策はすべて、Red Hat Enterprise Linux に含まれる暗号ライブラリーに実装されています。
表4.6 プロトコルのバージョン
プロトコルのバージョン | 推奨される使用方法 |
---|---|
SSL v2 |
使用しないでください。重大なセキュリティー上の脆弱性があります。
|
SSL v3 |
使用しないでください。重大なセキュリティー上の脆弱性があります。
|
TLS 1.0 |
必要な場合は、相互運用性目的で使用します。相互運用性を保証する方法では緩和できない既知の問題があります。このため、緩和策はデフォルトでは有効になっていません。最新の暗号化スイートには対応していません。
|
TLS 1.1 |
必要な場合は、相互運用性目的で使用します。既知の問題はありませんが、Red Hat Enterprise Linux の
TLS 実装すべてに含まれるプロトコル修正に依存します。最新の暗号化スイートには対応していません。
|
TLS 1.2 |
推奨されるバージョンです。最新の
AEAD 暗号化スイートに対応しています。
|
TLS 1.1
や 1.2
に対応しているのに TLS 1.0
を使用する設定になっているものもあります。これは、最新バージョンの TLS
に対応していない可能性のある外部サービスとの最高レベルの相互運用性を達成する目的でこのようになっています。相互運用性の要件に対応して、利用可能な最高レベルの TLS
バージョンを有効にしてください。
重要
SSL v3
の使用は推奨されません。これは安全ではなく一般の使用には適していませんが、SSL v3
をどうしても有効にする必要がある場合は、「stunnel の使用」 を参照してください。暗号化に対応していない、または旧式で安全でない暗号化モードの使用しかできないサービスを使用する場合でも、stunnel を使用して安全に通信を暗号化する方法が説明されています。
暗号化スイート
RC4
や HMAC-MD5
をベースとした暗号化スイートには重大な欠陥があるので、可能な場合はこれらも無効にしてください。いわゆる エクスポート暗号化スイートも同様にしてください。これらは意図的に弱くなっているので、侵入が容易になっています。
3DES
暗号は 168 ビットの使用といわれていますが、実際に提供されているのは 112 ビットのセキュリティーであることに注意してください。
RSA
鍵の交換がなくなる一方、ECDHE
および DHE
の使用が可能になります。これら 2 つのうちでは、ECDHE
の方がより速いため、優先される選択肢となります。
AES-GCM
などの AEAD
暗号はパディングオラクル攻撃 (padding oracle attacks) に対して脆弱ではないため、CBC
モードの暗号よりも優先してください。さらに多くの場合、AES-GCM
は特にハードウェアに AES
用の暗号化アクセラレーターがある場合、CBC
モードの AES
よりも高速です。
ECDSA
証明書を使って ECDHE
鍵交換を使用する際は、純粋な RSA
鍵交換よりも速くなります。レガシークライアント用のサポートを提供するには、サーバー上に証明書と鍵のペアを 2 つインストールします。ひとつは ECDSA
鍵 (新規クライアント用) で、もうひとつは RSA
鍵 (レガシークライアント用) です。
公開鍵の長さ
RSA
鍵を使用する際は常に、少なくとも SHA-256 で署名された 最低 3072 ビットの鍵の長さを優先させます。これは、真の 128 ビットのセキュリティーでは十分な大きさです。
警告
4.13.2. TLS 実装の使用
TLS
実装が同梱されています。本セクションでは、OpenSSL および GnuTLS の設定を説明します。個別アプリケーションでの TLS
サポートの設定方法については、「特定アプリケーションの設定」 を参照してください。
TLS
実装は、各種の 暗号化スイートをサポートします。これらのスイートは、TLS
でセキュア化された通信の確立および使用時に一緒に送られる全要素を定義します。
重要
TLS
実装またはその実装を利用するアプリケーションが更新またはアップグレードされた後は、必ず設定をチェックしてください。新しいバージョンは、ユーザーが有効化を希望せずかつ使用中の設定では無効にされない、新たな暗号化スイートを導入する場合があります。
4.13.2.1. OpenSSL での暗号化スイートの使用
SSL
プロトコルおよび TLS
プロトコルをサポートするツールキットおよび暗号化ライブラリーです。Red Hat Enterprise Linux 7 では、設定ファイルは /etc/pki/tls/openssl.cnf
にあります。その形式は、config(1) で確認できます。「OpenSSL の設定」 も参照してください。
openssl
コマンドで ciphers
サブコマンドを実行します。
~]$ openssl ciphers -v 'ALL:COMPLEMENTOFALL'
ciphers
コマンドに渡して出力を絞ります。特別なキーワードを使うと、特定の条件を満たすスイートのみを一覧表示することができます。たとえば、HIGH
グループに属するスイートのみを一覧表示するには、以下のコマンドを実行します。
~]$ openssl ciphers -v 'HIGH'
~]$ 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 が保証されます)。
4.13.2.2. GnuTLS での暗号化スイートの使用
SSL
および TLS
の各プロトコルとそれに関連する技術を実装する通信ライブラリーです。
注記
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
RSA
鍵交換と DSS
認証を禁止しています。
4.13.3. 特定アプリケーションの設定
TLS
用に個別の設定メカニズムを提供します。本セクションでは、最も一般的に使用されているサーバーアプリケーションが使用する TLS
関連の設定ファイルについて説明し、よくある説明例を示します。
4.13.3.1. Apache HTTP サーバーの設定
TLS
に OpenSSL と NSS の両方のライブラリーを使用できます。選択した TLS
ライブラリーによって、mod_ssl か mod_nss のモジュールをインストールする必要があります (その名前の付いたパッケージが提供)。たとえば、OpenSSL mod_ssl モジュールを提供するパッケージをインストールするには、root で以下のコマンドを実行します。
~]# yum install mod_ssl
/etc/httpd/conf.d/ssl.conf
設定ファイルをインストールし、これを使うと Apache HTTP Server の TLS
関連の設定を修正できます。同様に、mod_nss パッケージは /etc/httpd/conf.d/nss.conf
設定ファイルをインストールします。
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
/etc/httpd/conf.d/nss.conf
設定ファイルを修正します。mod_nss モジュールは mod_ssl から派生しているため、後者と多くの機能を共有しています。設定ファイルの構成だけでなく、利用可能なディレクティブも同様です。mod_nss ディレクティブには、SSL
ではなく NSS
の接頭辞が付くことに注意してください。mod_nss に適用できない mod_ssl 設定ディレクティブの一覧を含む mod_nss についての概要は、https://git.fedorahosted.org/cgit/mod_nss.git/plain/docs/mod_nss.html を参照してください。
4.13.3.2. Dovecot メールサーバーの設定
TLS
を使用するように設定するには、/etc/dovecot/conf.d/10-ssl.conf
設定ファイルを修正します。このファイルで利用可能な基本的な設定ディレクティブの一部は、/usr/share/doc/dovecot-2.2.10/wiki/SSL.DovecotConfiguration.txt
(このヘルプファイルは標準 Dovecot インストールに含まれています) で説明しています。
/etc/dovecot/conf.d/10-ssl.conf
設定ファイルの設定を修正する場合は、少なくとも下記の 3 つのディレクティブを確認してください。
ssl_protocols
- 許可する
TLS
(またはSSL
) のバージョンを指定するディレクティブです。 ssl_cipher_list
- 優先する暗号化スイートを指定する、もしくは許可しないスイートを無効にするディレクティブです。
ssl_prefer_server_ciphers
- コメントを解除して、このディレクティブを
yes
に設定すると、接続先のクライアントが指定された暗号化の命令に従います。
ssl_protocols = !SSLv2 !SSLv3 ssl_cipher_list = HIGH:!aNULL:!MD5 ssl_prefer_server_ciphers = yes
4.13.4. その他の情報
インストールされているドキュメント
- config(1) -
/etc/ssl/openssl.conf
設定ファイルの形式を説明しています。 - ciphers(1) - 利用可能な OpenSSL キーワードおよび暗号化文字列の一覧が含まれています。
/usr/share/httpd/manual/mod/mod_ssl.html
— Apache HTTP Server 用に mod_ssl が使用する/etc/httpd/conf.d/ssl.conf
設定ファイルで利用可能なディレクティブを詳細に説明しています。/usr/share/httpd/manual/ssl/ssl_howto.html
— Apache HTTP Server 用に mod_ssl が使用する/etc/httpd/conf.d/ssl.conf
設定ファイルでの現実的な設定例が含まれています。/usr/share/doc/dovecot-2.2.10/wiki/SSL.DovecotConfiguration.txt
— Dovecot メールサーバーが使用する/etc/dovecot/conf.d/10-ssl.conf
設定ファイルで使用可能な基本的設定ディレクティブについて説明しています。
オンラインのドキュメント
- Red Hat Enterprise Linux 7 SELinux User's and Administrator's Guide — Red Hat Enterprise Linux 7 の 『SELinux User's and Administrator's Guide』 では、SELinux の原則と、SELinux を設定して Apache HTTP Server などのさまざまなサービスで使用する方法が詳細に説明されています。
関連項目
- 「OpenSSL の使用」 では、OpenSSL を使用して鍵を作成、管理し、証明書を生成し、ファイルを暗号化、暗号化解除する方法を説明しています。
4.15. MACsec の使用
MACsec
(Media Access Control Security
(IEEE 802.1AE)) は、LAN におけるすべてのトラフィックを、GCM-AES-128 アルゴリズムで認証します。MACsec
は、IP
だけでなく、ARP (Address Resolution Protocol)、ND (Neighbor Discovery) または DHCP
も保護できます。IPsec
は、ネットワークレイヤー (レイヤー 3)、およびアプリケーションレイヤー (レイヤー 7) の SSL
または TLS
で動作しますが、MACsec
はデータリンクレイヤー (レイヤー 2) で動作します。その他のネットワークレイヤーのセキュリティープロトコルと MACsec
を組み合わせて、これらの規格が提供する複数のセキュリティー機能を活用してください。
MACsec
ネットワーク、ユースケースシナリオ、および設定例のアーキテクチャーの詳細は、「MACsec: a different solution to encrypt network traffic」 を参照してください。
4.16. scrub を使用してデータを安全に削除
scrub
コマンドを使用するには、scrub パッケージをインストールします。
~]# yum install scrub
文字またはブロックデバイス
- ディスク全体に対応する 特定のファイル がスクラブされ、含まれるデータがすべてスクラブされます。これが最も効果的な方法です。
scrub
[オプション] 特定ファイル ファイル
- 通常のファイルがスクラブされ、そのファイルのデータのみが破壊されます。
scrub
[オプション] ファイル ディレクトリー
-X
オプションを使用すると、ディレクトリーが作成され、ファイルシステムが満杯になるまでファイルが追加されます。ファイルシステムが満杯になると、ファイルモードでそのファイルがスクラブされます。スクラブ
-X
[オプション] ディレクトリー
例4.7 Raw デバイスのスクラブ
~]# scrub
/dev/sdf1
scrub: using NNSA NAP-14.1-C patterns
scrub: please verify that device size below is correct!
scrub: scrubbing /dev/sdf1 1995650048 bytes (~1GB)
scrub: random |................................................|
scrub: random |................................................|
scrub: 0x00 |................................................|
scrub: verify |................................................|
例4.8 ファイルのスクラブ
- 1MB ファイルを作成します。
~]$
base64
/dev/urandom | head -c $[ 1024*1024 ] > file.txt - ファイルサイズを表示します。
~]$
ls -lh
total 1.0M -rw-rw-r--. 1 username username 1.0M Sep 8 15:23 file.txt - ファイルの内容を表示します。
~]$
head
file.txt JnNpaTEveB/IYsbM9lhuJdw+0jKhwCIBUsxLXLAyB8uItotUlNHKKUeS/7bCRKDogEP+yJm8VQkL-1
- ファイルをスクラブします。
~]$
scrub
file.txt scrub: using NNSA NAP-14.1-C patterns scrub: scrubbing file.txt 1048576 bytes (~1024KB) scrub: random |................................................| scrub: random |................................................| scrub: 0x00 |................................................| scrub: verify |................................................| - ファイルの中身がスクラブされたことを確認します。
~]$ cat file.txt SCRUBBED!
- ファイルサイズに変更がないことを確認します。
~]$
ls -lh
total 1.0M -rw-rw-r--. 1 username username 1.0M Sep 8 15:24 file.txt
scrub
モード、オプション、方法、および注意事項の詳細は、man ページの scrub(1) を参照してください。
第5章 ファイアウォールの使用
5.1. firewalld
の概要
firewalld
は、D-Bus
インターフェースを使用して、動的にカスタマイズできるホストベースのファイアウォールを提供するファイアウォールサービスデーモンです。ルールが変更するたびに、ファイアウォールデーモンを再起動する必要なくルールの作成、変更、および削除を動的に削除します。
firewalld
は、ゾーン および サービス の概念を使用し、トラフィック管理を簡素化します。ゾーンは、事前定義したルールセットです。ネットワークインターフェースおよびソースはゾーンに割り当てることができます。許可されているトラフィックは、コンピューターが接続されるネットワークと、このネットワークが割り当てられているセキュリティーレベルに従います。ファイアウォールサービスは、特定のサービスに着信トラフィックを許可するのに必要な設定を扱う事前定義のルールで、ゾーンで適用されます。
firewalld
は、明示的に開いていないポートのトラフィックをすべてブロックします。trusted などのゾーンで、デフォルトですべてのトラフィックを許可します。

図5.1 ファイアウォールスタック
5.1.1. ゾーン
firewalld
は、インターフェースに追加する信頼レベルと、そのネットワークのトラフィックに従って、複数のネットワークを複数のゾーンに分類できます。接続は、1 つのゾーンにしか指定できませんが、ゾーンは多くのネットワーク接続に使用できます。
firewalld
に、インターフェースのゾーンを追加します。NetworkManager、firewall-config ツール、または firewall-cmd
コマンドラインツールを使用して、インターフェースにゾーンを割り当てることができます。後ろの 2 つは、適切な NetworkManager 設定ファイルのみを修正します。firewall-cmd
または firewall-config を使用してインターフェースのゾーンを変更すると、要求は NetworkManager に転送され、firewalld
には処理されません。
/usr/lib/firewalld/zones/
ディレクトリーに保存され、利用可能なネットワークインターフェースに即座に適用されます。このファイルは、修正しないと /etc/firewalld/zones/
ディレクトリーにコピーされません。以下のテーブルは、事前定義したゾーンのデフォルト設定を説明します。
block
IPv4
の場合は icmp-host-prohibited メッセージ、そしてIPv6
の場合は icmp6-adm-prohibited メッセージで、すべての着信ネットワーク接続が拒否されます。システム内で開始したネットワーク接続のみが可能です。dmz
- 公開アクセスが可能ではあるものの、内部ネットワークへのアクセスには制限がある非武装地帯にあるコンピューター用。選択した着信接続のみが許可されます。
drop
- 着信ネットワークパケットは、通知なしで遮断されます。発信ネットワーク接続だけが可能です。
external
- マスカレードを特別にルーター用に有効にした外部ネットワーク上での使用向けです。自分のコンピューターを保護するため、ネットワーク上の他のコンピューターを信頼しません。選択された着信接続のみが許可されます。
home
- そのネットワークでその他のコンピューターをほぼ信頼できる自宅での使用。選択した着信接続のみが許可されます。
internal
- そのネットワークでその他のコンピューターをほぼ信頼できる内部ネットワークでの使用。選択した着信接続のみが許可されます。
public
- そのネットワークでその他のコンピューターを信頼できないパブリックエリアでの使用。選択した着信接続のみが許可されます。
trusted
- すべてのネットワーク接続が許可されます。
work
- そのネットワークで、その他のコンピューターをほぼ信頼できる職場での使用。選択した着信接続のみが許可されます。
firewalld
のデフォルトゾーンは public
ゾーンに設定されます。デフォルトゾーンは変更できます。
注記
5.1.2. 事前定義サービス
firewalld.service(5)
で説明しています。サービスは、個々の XML 設定ファイルを使用して指定し、名前は、service-name.xml
のような形式になります。プロトコル名は、firewalld
のサービス名またはアプリケーション名よりも優先されます。
5.1.3. ランタイムおよび永続化設定
firewalld
が実行している間のみ適用されます。firewalld
を再起動すると、その設定は、永続化 の値に戻ります。
--permanent
オプションを使用して適用します。代わりに、firewalld
実行している間は変更を持続させるには、--runtime-to-permanent
firewall-cmd
オプションを実行します。
--permanent
オプションのみを使用して firewalld
が実行している場合にルールを設定するには、firewalld
が再起動するまでは有効になりません。ただし、firewalld
を再起動すると、開いているポートがすべて閉じ、ネットワーキングトラフィックを停止します。
5.1.4. CLI を使用してランタイムおよび永続設定の設定の変更
firewall-cmd
コマンドで --permanent
オプションを使用します。
~]# firewall-cmd --permanent <other options>
- 以下のように、ランタイム設定を変更して、永続化します。
~]#
firewall-cmd <other options>
~]#firewall-cmd --runtime-to-permanent
- 永続的な設定を行い、ランタイムモードで設定を再ロードします。
~]#
firewall-cmd --permanent <other options>
~]#firewall-cmd --reload
注記
--timeout
オプションを使用します。指定した時間が経つと、変更は元に戻ります。このオプションを使用すると、--permanent
オプションを除外します。
SSH
サービスを追加するには、以下のコマンドを実行します。
~]# firewall-cmd --add-service=ssh --timeout 15m
5.2. firewall-config GUI 設定ツールのインストール
root
権限で firewall-config パッケージをインストールします。
~]# yum install firewall-config
Software
タイプを使用して、Software Sources アプリケーションを起動します。右上端で検索ボタンを選択すると表示される検索ボックスに firewall
を入力します。検索結果から アイテムを選択し、 ボタンでクリックします。
firewall-config
コマンドを実行するか、Super キーを押して を入力するか、firewall
を入力して Enter を押します。
5.3. firewalld
の現在のステータスおよび設定の表示
5.3.1. firewalld
の現在のステータスの表示
firewalld
は、デフォルトシステムにインストールされています。firewalld
CLI インターフェースを使用して、サービスが実行していることを確認します。
~]# firewall-cmd --state
systemctl status
サブコマンドを実行します。
~]# systemctl status firewalld
firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor pr
Active: active (running) since Mon 2017-12-18 16:05:15 CET; 50min ago
Docs: man:firewalld(1)
Main PID: 705 (firewalld)
Tasks: 2 (limit: 4915)
CGroup: /system.slice/firewalld.service
└─705 /usr/bin/python3 -Es /usr/sbin/firewalld --nofork --nopid
firewalld
の設定と、ルールの実施方法を確認することが重要です。ファイアウォール設定を表示するには、「現在の firewalld
設定の表示」 を参照してください。
5.3.2. 現在の firewalld
設定の表示
5.3.2.1. GUI を使用して許可されるサービスの表示
firewall
を入力し、Enter を押します。firewall-config ツールが表示されます。 タブの下でサービスの一覧を表示します。
~]$ firewall-config

図5.2 firewall-config のサービスタブ
5.3.2.2. CLI を使用して firewalld
設定の表示
--list-all
オプションは、firewalld
設定の完全概要を表示します。
firewalld
は、ゾーンを使用してトラフィックを管理します。--zone
オプションでゾーンを指定していない場合、コマンドは、アクティブネットワークインターフェース及び接続に割り当てたデフォルトゾーンで有効です。
~]# firewall-cmd --list-all
public
target: default
icmp-block-inversion: no
interfaces:
sources:
services: ssh dhcpv6-client
ports:
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
注記
--zone=zone-name
引数を the firewall-cmd --list-all
コマンドに追加します。
~]# firewall-cmd --list-all --zone=home
home
target: default
icmp-block-inversion: no
interfaces:
sources:
services: ssh mdns samba-client dhcpv6-client
... [output truncated]
firewalld
か、コマンドヘルプを使用してオプションの一覧を表示します。
~]# firewall-cmd --help
Usage: firewall-cmd [OPTIONS...]
General Options
-h, --help Prints a short help text and exists
-V, --version Print the version string of firewalld
-q, --quiet Do not print status messages
Status Options
--state Return and print firewalld state
--reload Reload firewall and keep state information
... [output truncated]
~]# firewall-cmd --list-services
ssh dhcpv6-client
SSH
サービスを許可し、そのサービスに必要なポート (22) を firewalld
で開きます。その後、許可されたサービスを一覧表示すると、一覧は SSH
サービスを表示しますが、開いているポートを一覧表示しても、何も表示されません。したがって、--list-all
オプションを使用して、完全な情報を取得します。
5.4. firewalld
の起動
firewalld
を起動するには、root
で以下のコマンドを実行します。
~]#systemctl unmask firewalld
~]#systemctl start firewalld
firewalld
を自動的に起動するには、root
で以下のコマンドを入力します。
~]# systemctl enable firewalld
5.5. firewalld
の停止
firewalld
を停止するには、root
で以下のコマンドを入力します。
~]# systemctl stop firewalld
firewalld
が起動しないようにするには、以下のコマンドを root
で実行します。
~]# systemctl disable firewalld
firewalld
D-Bus
インターフェースにアクセスすることでは起動せず、その他のサービスが firewalld
を要求する場合でも、以下のコマンドを root
で実行します。
~]# systemctl mask firewalld
5.6. トラフィックの制御
5.6.1. 事前定義サービス
firewall-cmd
、および firewall-offline-cmd
を使用してサービスを追加および削除できます。
/etc/firewalld/services/
ディレクトリーの XML ファイルを編集できます。ユーザーにサービスが追加または変更されていない場合は、対応する XML ファイルは /etc/firewalld/services/
では見つかりません。/usr/lib/firewalld/services/
ディレクトリのファイルは、サービスの追加または変更する場合にテンプレートとして使用できます。
5.6.2. 緊急時に CLI を使用してすべてのトラフィックを無効
~]# firewall-cmd --panic-on
~]# firewall-cmd --panic-off
~]# firewall-cmd --query-panic
5.6.3. CLI を使用して事前定義されたサービスでトラフィックの制御
firewalld
に追加する方法です。これは、必要なすべてのポートを開き、service definition file に従ってその他の設定を変更します。
- サービスが許可されていないことを確認します。
~]#
firewall-cmd --list-services
ssh dhcpv6-client - 事前定義したサービスの一覧を表示します。
~]#
firewall-cmd --get-services
RH-Satellite-6 amanda-client amanda-k5-client bacula bacula-client bitcoin bitcoin-rpc bitcoin-testnet bitcoin-testnet-rpc ceph ceph-mon cfengine condor-collector ctdb dhcp dhcpv6 dhcpv6-client dns docker-registry ... [output truncated] - サービスを、許可されたサービスに追加します。
~]#
firewall-cmd --add-service=<service-name>
- 新しい設定を永続化します。
~]#
firewall-cmd --runtime-to-permanent
5.6.4. GUI を使用した事前定義サービスでトラフィックの制御
IPv4
または IPv6
) へのトラフィックが制限できます。
注記
5.6.5. 新しいサービスの追加
firewall-cmd
、firewall-offline-cmd
を使用するか、/etc/firewalld/services/
にある XML ファイルを編集することで行います。ユーザーがサービスを追加または変更しないと、そのサービスに対応する XML ファイルは /etc/firewalld/services/
作成されません。サービスの追加または変更には、/usr/lib/firewalld/services/
のファイルをテンプレートとして使用してください。
firewall-cmd
を使用してください。firewalld
がアクティブでない場合には firewall-offline-cmd
を使用してください。新規サービスや空のサービスを追加するには以下のコマンドを実行します。
~]$ firewall-cmd --new-service=service-name
~]$ firewall-cmd --new-service-from-file=service-name.xml
--name=service-name
オプションを指定して、サービス名を変更できます。
/etc/firewalld/services/
に作成できます。
root
として、以下のコマンドを実行しサービスを手動でコピーします。
~]# cp /usr/lib/firewalld/services/service-name.xml /etc/firewalld/services/service-name.xml
firewalld
は、/usr/lib/firewalld/services
からファイルを読み込みます。ファイルが /etc/firewalld/services
に追加され有効な場合には、/usr/lib/firewalld/services
にある対応のファイルを上書きします。/etc/firewalld/services
にある対応のファイルが削除されるか、サービスのデフォルトを読みこむように firewalld
に要求が出されるとすぐに、/usr/lib/firewalld/services
の上書きされたファイルが使用されます。これが該当するのは永続環境のみで、ランタイム環境でフォールバックさせるには、再読み込みが必要です。
5.6.6. CLI を使用したポートの制御
httpd
デーモンでは、たとえばポート 80 をリッスンします。ただし、デフォルトでは、システム管理者は、その他の理由によりセキュリティーを強化する別のポートをリッスンするようにデーモンを設定します。
ポートを開く
- 許可されているポートを一覧表示します。
~]#
firewall-cmd --list-ports
- 許可されているポートにポートを追加して、着信トラフィックに対して開きます。
~]#
firewall-cmd --add-port=port-number/port-type
- 新しい設定を永続化します。
~]#
firewall-cmd --runtime-to-permanent
tcp
、udp
、sctp
、または dccp
になります。このタイプは、ネットワーク接続の種類と一致させる必要があります。
ポートを閉じる
firewalld
のポートを閉じます。ポートをそのままにするとセキュリティーリスクが示されるため、使用されなくなったら、不要なポートを閉じることが強く推奨されます。
- 許可されているポートを一覧表示します。
~]#
firewall-cmd --list-ports
[WARNING] ==== This command will only give you a list of ports that have been opened as ports. You will not be able to see any open ports that have been opened as a service. Therefore, you should consider using the --list-all option instead of --list-ports. ==== - 「許可されているポート」からポートを削除し、着信トラフィックに対して閉じます。
~]#
firewall-cmd --remove-port=port-number/port-type
- 新しい設定を永続化します。
~]#
firewall-cmd --runtime-to-permanent
5.6.7. GUI を使用してポートを開く
5.6.8. GUI を使用してプロトコルを使用したトラフィックの制御
5.6.9. GUI を使用してソースポートを開く
5.7. ゾーンの使用
5.7.1. ゾーンの一覧
~]# firewall-cmd --get-zones
firewall-cmd --get-zones
コマンドは、システムで利用可能な全てのゾーンを表示し、特定ゾーンの詳細は表示しません。
~]# firewall-cmd --list-all-zones
~]# firewall-cmd --zone=zone-name --list-all
5.7.2. 特定ゾーンに対する firewalld
設定
--zone=zone-name
オプションを使用します。たとえば、ゾーン public で SSH
サービスを許可します。
~]# firewall-cmd --add-service=ssh --zone=public
5.7.3. デフォルトゾーンの変更
firewalld
サービスを再起動するたびに、firewalld
は、デフォルトゾーンの設定をロードし、それをアクティブにします。
- 現在のデフォルトゾーンを表示します。
~]#
firewall-cmd --get-default-zone
- 新しいデフォルトゾーンを設定します。
~]#
firewall-cmd --set-default-zone zone-name
注記
--permanent
オプションを使用しなくても、設定は永続化します。
5.7.4. ゾーンへのネットワークインターフェースの割り当て
- アクティブゾーン、およびそのゾーンに割り当てられているインターフェースを一覧表示します。
~]#
firewall-cmd --get-active-zones
- 別のゾーンにインターフェースを割り当てます。
~]#
firewall-cmd --zone=zone-name --change-interface=<interface-name>
注記
--permanent
オプションを使用する必要はありません。新しいデフォルトゾーンを設定すると、設定は永続化されます。
5.7.5. ネットワーク接続にデフォルトゾーンの割り当て
/etc/sysconfig/network-scripts/ifcfg-connection-name
ファイルを編集して、この接続にゾーンを割り当てる行を追加します。
ZONE=zone-name
5.7.6. 新しいゾーンの作成
--permanent
オプションが必要となり、このコマンドがなければコマンドが動作しません。
- 新しいゾーンを作成します。
~]#
firewall-cmd --new-zone=zone-name
- 作成したゾーンが永続化設定に追加されたかどうかを確認します。
~]#
firewall-cmd --get-zones
- 新しい設定を永続化します。
~]#
firewall-cmd --runtime-to-permanent
5.7.7. 設定ファイルを使用して新しいゾーンの作成
firewalld
ゾーン設定ファイルは、ゾーンに対する情報を含みます。これは、XML ファイルフォーマットで、ゾーンの説明、サービス、ポート、プロトコル、icmp-block、マスカレード、転送ポート、およびリッチ言語ルールです。ファイル名は zone-name.xml
となります。zone-name の長さは 17 文字に制限されます。ゾーンの設定ファイルは /usr/lib/firewalld/zones/
ディレクトリーおよび /etc/firewalld/zones/
ディレクトリーです。
TCP
プロトコルおよび UDP
プロトコルに、1 つのサービス (SSH
) および 1 つポート範囲を許可する設定を示します。
<?xml version="1.0" encoding="utf-8"?> <zone> <short>My zone</short> <description>Here you can describe the characteristic features of the zone.</description> <service name="ssh"/> <port port="1025-65535" protocol="tcp"/> <port port="1025-65535" protocol="udp"/> </zone>
firewalld.zone
を参照してください。
5.7.8. 着信トラフィックにデフォルトの動作を設定するゾーンターゲットの使用
default
、ACCEPT
、REJECT
、および DROP
の 3 つになります。ターゲットを ACCEPT
に設定すると、特定ルールで無効にした着信パケット以外のパケットをすべて許可します。REJECT
または DROP
にターゲットを設定すると、特定のルールで許可したパケット以外の着信パケットをすべて無効にします。パケットが拒否されると、拒否についてソースマシンに通知しますが、パケットが破棄される時に送られる情報はありません。
- 特定ゾーンに対する情報を一覧表示して、デフォルトゾーンを確認します。
~]$
firewall-cmd --zone=zone-name --list-all
- ゾーンに新しいターゲットを設定します。
~]#
firewall-cmd --zone=zone-name --set-target=<default|ACCEPT|REJECT|DROP>
5.8. ゾーンを使用し、ソースに従って着信トラフィックの管理
5.8.1. ソースの追加
- 現在のゾーンにソースを設定するには、以下のコマンドを実行します。
~]#
firewall-cmd --add-source=<source>
- 特定ゾーンのソース IP アドレスを設定するには、以下のコマンドを実行します。
~]#
firewall-cmd --zone=zone-name --add-source=<source>
信頼される
ゾーンで 192.168.2.15 からのすべての着信トラフィックを許可します。
- 利用可能なゾーンの一覧を表示します。
~]#
firewall-cmd --get-zones
- 永続化モードで、信頼ゾーンにソース IP を追加します。
~]#
firewall-cmd --zone=trusted --add-source=192.168.2.15
- 新しい設定を永続化します。
~]#
firewall-cmd --runtime-to-permanent
5.8.2. ソースの削除
- 必要なゾーンに対して許可されているソースを一覧表示します。
~]#
firewall-cmd --zone=zone-name --list-sources
- ゾーンからソースを永続的に削除します。
~]#
firewall-cmd --zone=zone-name --remove-source=<source>
- 新しい設定を永続化します。
~]#
firewall-cmd --runtime-to-permanent
5.8.3. ソースポートの追加
--add-source-port
オプションを使用してソースポートを指定します。--add-source
オプションと組み合わせて、トラフィックを特定の IP アドレスまたは IP 範囲に制限できます。
~]# firewall-cmd --zone=zone-name --add-source-port=<port-name>/<tcp|udp|sctp|dccp>
5.8.4. ソースポートの削除
~]# firewall-cmd --zone=zone-name --remove-source-port=<port-name>/<tcp|udp|sctp|dccp>
5.8.5. ゾーンおよびソースを使用して特定ドメインのみに対してサービスの許可
- 利用可能なゾーンの一覧を表示します。
~]#
firewall-cmd --get-zones
block dmz drop external home internal public trusted work - ソースを信頼されるゾーンに追加して、ゾーンを経由してソースから発信するトラフィックに転送します。
~]#
firewall-cmd --zone=trusted --add-source=192.168.1.0/24
- 信頼されるゾーン http サービスを追加します。
~]#
firewall-cmd --zone=trusted -add-service=http
- 新しい設定を永続化します。
~]#
firewall-cmd --runtime-to-permanent
- 信頼されるゾーンがアクティブで、サービスが許可されているのを確認します。
~]#
firewall-cmd --zone=trusted --list-all
trusted (active) target: ACCEPT sources: 192.168.1.0/24 services: http
5.8.6. プロトコルに基づいてゾーンが許可したトラフィックの設定
ゾーンへのプロトコルの追加
~]# firewall-cmd --zone=zone-name --add-protocol=port-name/tcp|udp|sctp|dccp|igmp
注記
--add-protocol
オプションで igmp
値を使用します。
ゾーンからプロトコルの削除
~]# firewall-cmd --zone=zone-name --remove-protocol=port-name/tcp|udp|sctp|dccp|igmp
5.9. ポート転送
firewalld
を使用して、システムで特定のポートを到達するための着信トラフィックが、選択した別の内部ポート、または別のマシンの外部ポートに配信されるようにポートのリダイレクトを設定できます。
5.9.1. リダイレクトするポートの追加
~]# firewall-cmd --add-forward-port=port=port-number:proto=tcp|udp|sctp|dccp:toport=port-number
- 転送するポートを追加します。
~]#
firewall-cmd --add-forward-port=port=port-number:proto=tcp|udp:toport=port-number:toaddr=IP/mask
- マスカレードを有効にします。
~]#
firewall-cmd --add-masquerade
例5.1 同一マシンで TCP ポート 80 からポート 88 へのリダイレクト
- TCP トラフィックに対して、ポート 80 からポート 88 へリダイレクトします。
~]#
firewall-cmd --add-forward-port=port=80:proto=tcp:toport=88
- 新しい設定を永続化します。
~]#
firewall-cmd --runtime-to-permanent
- そのポートがリダイレクトされていることを確認します。
~]#
firewall-cmd --list-all
5.9.2. リダイレクトしたポートの削除
~]# firewall-cmd --remove-forward-port=port=port-number:proto=<tcp|udp>:toport=port-number:toaddr=<IP/mask>
- 転送したポートを削除するには、以下を行います。
~]#
firewall-cmd --remove-forward-port=port=port-number:proto=<tcp|udp>:toport=port-number:toaddr=<IP/mask>
- マスカレードを無効にするには、以下のコマンドを実行します。
~]#
firewall-cmd --remove-masquerade
注記
例5.2 同じマシンで TCP ポート 88 に転送されるポート 80 の削除
- リダイレクトしたポートを一覧表示します。
~]#
firewall-cmd --list-forward-ports
port=80:proto=tcp:toport=88:toaddr= - ファイアウォールからリダイレクトしたポートを削除します。
~]#
firewall-cmd --remove-forward-port=port=80:proto=tcp:toport=88:toaddr=
- 新しい設定を永続化します。
~]#
firewall-cmd --runtime-to-permanent
5.10. IP アドレスのマスカレードの設定
external
ゾーンなどで IP マスカレーディングが有効かどうかを確認するには、root
で以下のコマンドを実行します。
~]# firewall-cmd --zone=external --query-masquerade
0
で yes
が出力され、無効の場合は終了ステータスが 1
で no
が出力されます。zone
を省略すると、デフォルトのゾーンが使用されます。
root
で以下のコマンドを発行します。
~]# firewall-cmd --zone=external --add-masquerade
--permanent
オプションを追加してコマンドを繰り返します。
root
で以下のコマンドを発行します。
~]# firewall-cmd --zone=external --remove-masquerade
--permanent
オプションを追加してコマンドを繰り返します。
5.11. ICMP
リクエストの管理
Internet Control Message Protocol
(ICMP
) は、たとえば、要求されているサービスが利用できない接続問題を示すエラーメッセージと運用情報を送信するために、さまざまなネットワークデバイスにより使用されているサポートしているプロトコルです。ICMP
は、システム間でデータを交換するのには使用されていないため、TCP、UDP などの転送プロトコルとは異なります。
ICMP
メッセージ (特に echo-request
および echo-reply
) を使用できます。さまざま不正アクティビティーに関する情報を誤用します。したがって、firewalld
は、ネットワーク情報を保護するために、ICMP
リクエストをブロックできます。
5.11.1. ICMP
リクエストの一覧表示
/usr/lib/firewalld/icmptypes/
ディレクトリーに置いた個々の XML ファイルで ICMP
リクエストを説明しています。このファイルを読み、リクエストの説明を表示します。firewall-cmd
コマンドは、ICMP
リクエストの操作を制御します。
ICMP
タイプを一覧表示するには、以下のコマンドを使用します。
~]# firewall-cmd --get-icmptypes
ICMP
リクエストは IPv4、IPv6、または両方のプロトコルにより使用できます。ICMP
リクエストが使用されているプロトコルを表示するには、以下のコマンドを実行します。
~]# firewall-cmd --info-icmptype=<icmptype>
ICMP
リクエストのステータスは、リクエストが現在ブロックされている場合は yes
、ブロックされていない場合は no
となります。ICMP
リクエストが現在ブロックされているかどうかを確認するには、以下のコマンドを実行します。
~]# firewall-cmd --query-icmp-block=<icmptype>
5.11.2. ICMP
リクエストのブロックまたはブロック解除
ICMP
リクエストをブロックすると、通常通りに情報を提供しません。ただし、ただし、情報が指定されていないことを意味します。クライアントは、特定の ICMP
リクエストがブロックされている (拒否されている) 情報を受け取ります。ICMP
リクエストは、特に IPv6 トラフィックを使用すると、接続問題になることができるため、注意深く検討する必要があります。
ICMP
リクエストが現在ブロックされているかどうかを確認するには、以下を行います。
~]# firewall-cmd --query-icmp-block=<icmptype>
ICMP
リクエストをブロックするには、以下のコマンドを実行します。
~]# firewall-cmd --add-icmp-block=<icmptype>
ICMP
リクエストのブロックを削除するには、以下のコマンドを実行します。
~]# firewall-cmd --remove-icmp-block=<icmptype>
5.11.3. 情報を提供せずに ICMP
リクエストのブロック
ICMP
リクエストをブロックすると、ブロックしていることをクライアントは認識します。ライブの IP アドレスを傍受している潜在的な攻撃者は、IP アドレスがオンラインであることを見ることができます。この情報を完全に非表示にするには、ICMP
リクエストをすべて破棄する必要があります。
ICMP
リクエストをブロックおよび破棄するには、以下を行います。
- ゾーンのターゲットを
DROP
に設定します。~]#
firewall-cmd --set-target=DROP
- 新しい設定を永続化します。
~]#
firewall-cmd --runtime-to-permanent
ICMP
リクエストを含むすべてのトラフィックが破棄されます。
ICMP
リクエストをブロックして破棄し、その他を許可するには、以下を行います。
- ゾーンのターゲットを
DROP
に設定します。~]#
firewall-cmd --set-target=DROP
- ICMP ブロックを反転し、すべての
ICMP
リクエストを一度にブロックします。~]#
firewall-cmd --add-icmp-block-inversion
- 許可する
ICMP
リクエストに ICMP ブロックを追加します。~]#
firewall-cmd --add-icmp-block=<icmptype>
- 新しい設定を永続化します。
~]#
firewall-cmd --runtime-to-permanent
ICMP
リクエストブロックを反転するため、すでにブロックしていないすべてのブロックをブロックします。ブロックされているものはブロックされません。これは、リクエストのブロックを解除する必要がある場合は、ブロックコマンドを使用する必要があることを意味します。
- ゾーンのターゲットを
default
またはACCEPT
に戻すには、以下のコマンドを設定します。~]#
firewall-cmd --set-target=default
ICMP
リクエストに追加したブロックをすべて削除します。~]#
firewall-cmd --remove-icmp-block=<icmptype>
ICMP
ブロック反転を削除します。~]#
firewall-cmd --remove-icmp-block-inversion
- 新しい設定を永続化します。
~]#
firewall-cmd --runtime-to-permanent
5.11.4. GUI を使用して ICMP
フィルターの設定
ICMP
フィルターを有効または無効にするには、firewall-config ツールを起動して、フィルターをかけるメッセージのネットワークゾーンを選択します。ICMP フィルター タブを選択し、フィルターをかける ICMP
メッセージの各タイプのチェックボックスを選択します。フィルターを無効にするには、チェックボックスの選択を外します。これは方向ごとに設定され、デフォルトではすべてが許可されます。
ICMP
タイプを編集するには、firewall-config ツールを起動してから 設定 ラベルのあるメニューで モードを選びます。 ウィンドウの下部に新たなアイコンが表示されます。以下のダイアログで を選択し、マスカレーディングを有効化し、動作している別のマシンに転送します。
ICMP
タイプが受け入れられ、その他はすべて拒否されます。DROP ターゲットを使用するゾーンでは、破棄されます。
5.12. firewalld
を使用した IP セットの設定および制御
firewalld
でサポートする IP セットタイプの一覧を表示するには、root で以下のコマンドを実行します。
~]# firewall-cmd --get-ipset-types
hash:ip hash:ip,mark hash:ip,port hash:ip,port,ip hash:ip,port,net hash:mac hash:net hash:net,iface hash:net,net hash:net,port hash:net,port,net
5.12.1. コマンドラインクライアントを使用して IP セットオプションの設定
firewalld
ゾーンでソースとして使用でき、リッチルールでソースとして使用できます。Red Hat Enterprise Linux 7 では、推奨される方法は、ダイレクトルールで firewalld
を使用して作成した IP セットを使用します。
firewalld
に認識されている IP セットをリストするには、以下のコマンドを root
で実行します。
~]# firewall-cmd --permanent --get-ipsets
root
で実行します。
~]# firewall-cmd --permanent --new-ipset=test --type=hash:net
success
IPv4
の test 名前と、hash:net
タイプで新しい IP セットを作成します。IPv6
で使用するために IP セットを作成するには、--option=family=inet6
オプションを追加します。ランタイム環境で新しい設定を有効にするには、firewalld
を再ロードします。root
で以下のコマンドを実行して、新しい IP セットを一覧表示します。
~]# firewall-cmd --permanent --get-ipsets
test
root
として実行します。
~]# firewall-cmd --permanent --info-ipset=test
test
type: hash:net
options:
entries:
root
で実行します。
~]# firewall-cmd --permanent --ipset=test --add-entry=192.168.0.1 success
root
で実行します。
~]# firewall-cmd --permanent --ipset=test --get-entries
192.168.0.1
~]# cat > iplist.txt <<EOL
192.168.0.2
192.168.0.3
192.168.1.0/24
192.168.2.254
EOL
root
で実行します。
~]# firewall-cmd --permanent --ipset=test --add-entries-from-file=iplist.txt success
root
で以下のコマンドを実行します。
~]# firewall-cmd --permanent --ipset=test --get-entries 192.168.0.1 192.168.0.2 192.168.0.3 192.168.1.0/24 192.168.2.254
root
で実行します。
~]# firewall-cmd --permanent --ipset=test --remove-entries-from-file=iplist.txt
success
~]# firewall-cmd --permanent --ipset=test --get-entries 192.168.0.1
root
で以下のコマンドを実行します。
~]# firewall-cmd --permanent --zone=drop --add-source=ipset:test
success
ipset:
接頭辞は、ソースが IP セットで、IP アドレスまたはアドレス範囲ではない firewalld
を示しています。
--permanent
オプションを使用しないランタイム環境で使用できます。
5.12.2. IP セットのカスタムサービスの設定
firewalld
を開始する前に IP セット構造を作成およびロードするカスタムサービスを設定するには、以下を行います。
root
でエディターを使用して、以下のようにファイルを作成します。~]#
vi /etc/systemd/system/ipset_name.service
[Unit] Description=ipset_name Before=firewalld.service [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/local/bin/ipset_name.sh start ExecStop=/usr/local/bin/ipset_name.sh stop [Install] WantedBy=basic.target- firewalld で IP セットを永続的に使用します。
~]# vi
/etc/firewalld/direct.xml
<?xml version="1.0" encoding="utf-8"?> <direct> <rule ipv="ipv4" table="filter" chain="INPUT" priority="0">-m set --match-set <replaceable>ipset_name</replaceable> src -j DROP</rule> </direct> - 変更を有効にするには、
firewalld
を再ロードする必要があります。~]#
ステータス情報を失わずにファイアウォールを再ロードします (TCP セッションは終了しません) が、再起動時にサービスが中断する可能性があります。firewall-cmd --reload
警告
firewalld
. を介して管理されない IP セットを使用することは推奨しません。このような IP セットを使用すると、そのセットを参照するために永続的なダイレクトルールが必要で、IP セットを作成するためにカスタムサービスを追加する必要があります。このサービスは、firewalld を起動する前に起動する必要があります。先に起動しておかないと、firewalld
が、このセットを使用してダイレクトルールを追加できません。/etc/firewalld/direct.xml
ファイルを使用して、永続的なダイレクトルールを追加できます。
5.13. iptables
を使用して IP セットの設定および制御
firewalld
と iptables (and ip6tables) の本質的な違いは、以下の通りです。
- iptables service は設定を
/etc/sysconfig/iptables
および/etc/sysconfig/ip6tables
に保存しますが、firewalld
は、/usr/lib/firewalld/
および/etc/firewalld/
の様々な XML ファイルに保存します。Red Hat Enterprise Linux ではfirewalld
がデフォルトでインストールされるため、/etc/sysconfig/iptables
ファイルがないことに注意してください。 - iptables service では、変更を行うために古いルールがフラッシュされ、新しいルールが
/etc/sysconfig/iptables
から読み込まれますが、firewalld
ではそのようなすべてのルールの再生が行われることはなく、差異のみが適用されます。このため、firewalld
では既存の接続が中断されることなく実行時に設定変更ができます。
firewalld
の代わりにiptables
および ip6tables
の各サービスを使用するには、まず root
で以下のコマンドを実行して firewalld
を無効にします。
~]#systemctl disable firewalld
~]#systemctl stop firewalld
root
で以下のコマンドを実行して、iptables-services パッケージをインストールします。
~]# yum install iptables-services
iptables-services パッケージには、iptables
と ip6tables
のサービスが含まれます。
iptables
サービスおよび ip6tables
サービスを起動する前に、以下のコマンドを root
で起動します。
~]#システム起動時にサービスの起動を有効にするには、以下のコマンドを入力します。systemctl start iptables
~]#systemctl start ip6tables
~]#systemctl enable iptables
~]#systemctl enable ip6tables
~]#セットは、以下のように作成されます。iptables -A INPUT -s 10.0.0.0/8 -j DROP
~]#iptables -A INPUT -s 172.16.0.0/12 -j DROP
~]#iptables -A INPUT -s 192.168.0.0/16 -j DROP
~]#セットは、以下のように iptables コマンドで参照されます。ipset create my-block-set hash:net
~]#ipset add my-block-set 10.0.0.0/8
~]#ipset add my-block-set 172.16.0.0/12
~]#ipset add my-block-set 192.168.0.0/16
~]# iptables -A INPUT -m set --set my-block-set src -j DROP
セットが複数回使用される場合は、設定時間が短縮されます。セットに多くのエントリーが含まれる場合は、処理時間が短縮されます。
5.14. ダイレクトインターフェースの使用
--direct
オプションを使用すると、ランタイム時にチェーンの追加、削除が可能になります。ここではいくつかの例を紹介していますが、詳細は man ページの firewall-cmd(1)
を参照してください。
--permanent
オプションを追加して firewall-cmd --permanent --direct
コマンドを使用するか、/etc/firewalld/direct.xml
を修正することで、ルールを永続的なものにできます。/etc/firewalld/direct.xml
ファイルの詳細は、man ページ firewalld.direct(5)
を参照してください。
5.14.1. ダイレクトインターフェースを使用するルールの追加
root
で以下のコマンドを実行します。
~]#firewall-cmd --direct --add-rule ipv4 filter IN_public_allow \
0 -m tcp -p tcp --dport 666 -j ACCEPT
--permanent
オプションを追加して設定を永続化します。
5.14.2. ダイレクトインターフェースを使用したルールの削除
root
で以下のコマンドを実行します。
~]#firewall-cmd --direct --remove-rule ipv4 filter IN_public_allow \
0 -m tcp -p tcp --dport 666 -j ACCEPT
--permanent
オプションを追加して設定を永続化します。
5.14.3. ダイレクトインターフェースを使用したルールの一覧表示
root
で以下のコマンドを実行します。
~]# firewall-cmd --direct --get-rules ipv4 filter IN_public_allow
--get-rules
オプション) は、--add-rule
オプションを使用して追加したルールのみを表示します。他の手段で追加した iptables ルールは表示されません。
5.15. 「リッチ言語」構文を使用した複雑なファイアウォールルールの設定
5.15.1. リッチ言語コマンドの形式
root
で実行する必要があります。ルールを追加するコマンド形式は以下のとおりです。
firewall-cmd [--zone=zone] --add-rich-rule='rule' [--timeout=timeval]
s
(秒)、m
(分) または h
(時間) を追加できます。デフォルトは秒です。
firewall-cmd [--zone=zone] --remove-rich-rule='rule'
firewall-cmd [--zone=zone] --query-rich-rule='rule'
0
で yes
が出力され、無効の場合は終了ステータスが 1
で no
が出力されます。ゾーンを省略すると、デフォルトのゾーンが使用されます。
5.15.2. リッチルールの構造について
rule [family="rule family"] [ source [NOT] [address="address"] [mac="mac-address"] [ipset="ipset"] ] [ destination [NOT] address="address" ] [ element ] [ log [prefix="prefix text"] [level="log level"] [limit value="rate/duration"] ] [ audit ] [ action ]
注記
NOT
キーワードを使用しています。ただし、コマンドラインは invert
="true" オプションを使用します。
5.15.3. リッチルールのコマンドオプションについて
family
- ルールのファミリーを指定している場合は、
ipv4
かipv6
になり、ルールをIPv4
またはIPv6
に制限します。ルールのファミリーを使用しないと、ルールがIPv4
とIPv6
の両方に追加されます。ルール内でソースまたは宛先のアドレスを使用している場合は、ルールのファイミリーを提供する必要があります。これは、ポート転送の場合でも同じです。
ソースアドレスおよび宛先のアドレス
source
- ソースのアドレスを指定すると、接続試行の元を指定したソースアドレスに限定できます。ソースアドレスまたはアドレスの範囲は、
IPv4
またはIPv6
のマスクを伴う IP アドレスかネットワーク IP アドレスになります。IPv4
のマスクは、ネットワークマスクまたは単純な番号になります。IPv6
のマスクは単純な番号になります。ホスト名の使用はサポートされていません。NOT
キーワードを追加すると、ソースアドレスコマンドの意味が逆になり、提供されたアドレス以外のものがマッチすることになります。そのルールにfamily
が指定されていない場合は、MAC アドレスと、 を持つ IP セットを、IPv4
およびIPv6
に追加できます。その他の IP は、ルールのfamily
設定に一致させる必要があります。 destination
- 宛先のアドレスを指定すると、ターゲットを指定した宛先アドレスに限定できます。宛先アドレスでは、IP アドレスまたはアドレス範囲のソースアドレスと同様の構文を使用します。ソースアドレスおよび宛先アドレスの使用はオプションで、宛先アドレスをすべての要素とともに使用できるわけではありません。これは、サービスエントリーにおける宛先アドレスの使用などによって異なります。
destination
とaction
は組み合わせることができます。
要素
service
、port
、protocol
、masquerade
、icmp-block
、forward-port
、および source-port
に対して 1 つだけ になります。
service
service
要素は、firewalld が提供したサービスのひとつです。事前定義したサービスの一覧を取得するには、以下のコマンドを実行します。~]$
サービスが宛先アドレスを提供する場合、ルール内の宛先アドレスと競合し、エラーが発生します。内部で宛先アドレスを使用するサービスのほとんどは、マルチキャストを使用するサービスです。コマンドは以下の形式になります。firewall-cmd --get-services
service name=service_name
port
port
要素は、1 つのポート番号またはポート範囲 (5060-5062
など) のいずれかの後にプロトコル (tcp
またはudp
のいずれか) が続きます。コマンドは以下の形式になります。port port=number_or_range protocol=protocol
protocol
protocol
値は、プロトコル ID 番号またはプロトコル名となります。許可されているprotocol
エントリーは/etc/protocols
を参照してください。コマンドは以下の形式になります。protocol value=protocol_name_or_ID
icmp-block
- 1 つ以上の
ICMP
タイプをブロックするには、このコマンドを使用します。ICMP
タイプは、firewalld がサポートするICMP
タイプのひとつになります。サポートされるICMP
タイプの一覧を確認するには、以下のコマンドを実行します。~]$
ここではアクションの特定はできません。firewall-cmd --get-icmptypes
icmp-block
はreject
のアクションを内部で使用します。コマンドは以下の形式になります。icmp-block name=icmptype_name
masquerade
- ルール内の IP マスカレードを有効にします。ソースアドレスを提供するとこのエリアへのマスカレードを制限できますが、宛先アドレスは制限できません。ここではアクションの特定はできません。
forward-port
tcp
またはudp
として指定されたプロトコルのローカルポートから別のローカルポート、別のマシン、または別のマシン上の別のポートにパケットを転送します。port
およびto-port
は、1 つのポート番号もしくはポート範囲のどちらでも構いません。宛先アドレスは、単純な IP アドレスになります。ここではアクションの特定はできません。forward-port
コマンドは、accept
のアクションを内部で使用します。コマンドは以下の形式になります。forward-port port=number_or_range protocol=protocol /
to-port=number_or_range to-addr=address
source-port
- パケットのソースポートに一致します。そのポートは、接続試行の発信元として使用されます。現在のマシンのポートに一致させる場合は、
port
要素を使用します。source-port
要素は、1 つのポート番号またはポート範囲 (たとえば 5060-5062) のいずれかの後にプロトコル (tcp
またはudp
のいずれか) が続きます。コマンドは以下の形式になります。source-port port=number_or_range protocol=protocol
ロギング
log
- syslog などのカーネルロギングでルールへの新たな接続試行を記録します。ログメッセージに接頭辞として追加される接頭辞テキストを定義できます。ログレベルは、
emerg
、alert
、crit
、error
、warning
、notice
、info
、またはdebug
のいずれかになります。ログの使用はオプションです。ログの使用は以下のように制限できます。
rate は正の自然数 [1, ..] で、log [prefix=prefix text] [level=log level] limit value=rate/duration
s
、m
、h
、d
は時間の長さになります。s
は秒数、m
は分数、h
は時間数、d
は日数を表します。制限の最大値は1/d
で、これは 1 日あたり最大 1 ログエントリーになります。 audit
- Audit は、サービス
auditd
に送信された監査記録を使ってロギングの別の方法を提供します。audit タイプはACCEPT
、REJECT
、またはDROP
のいずれかになりますが、これはルールのアクションから自動的に獲得されるので、audit
コマンドの後では指定されません。Audit にはそれ自体のパラメーターはありませんが、オプションで制限を加えることができます。Audit の使用はオプションになります。
アクション
accept|reject|drop|mark
- アクションは、
accept
、reject
、drop
、またはmark
のいずれかに設定できます。このルールには、要素またはソースのいずれかにすることができます。要素と一致する新しい接続は、そのアクションで処理されます。ルールにソースが含まれ、ソースアドレスからのものはすべて指定したアクションで処理されます。accept | reject [type=reject type] | drop | mark set="mark[/mask]"
accept
アクションを使用すると、新たな接続試行がすべて許可されます。reject
を使用するとそれは拒否され、そのソースは拒否メッセージを受け取ります。拒否のタイプは、別の値を使用するように設定できます。drop
を使用すると、すべてのパケットが即座に破棄され、ソースには何も情報が送られません。mark
を使用すると、すべてのパケットには、指定した mark と、オプションの mask でマークされます。
5.15.4. リッチルールログコマンドの使用
deny
チェーンの前に処理されます。ルールまたはルールの一部は、以下のようにルールのアクションに従い、複数のチェーンに置かれます。
zone_log zone_deny zone_allow
reject
ルールおよび drop
ルールはすべて 「zone_deny」 チェーンに置かれ、これは log チェーンの後に解析されます。accept
ルールはすべて 「zone_allow」 チェーンに置かれ、これは deny
チェーンの後に解析されます。ルールに log
と deny
または allow
アクションが含まれる場合、これらのアクションを指定しているルールの一部は、一致するチェーンに置かれます。
5.15.4.1. リッチルールログコマンドの使用例 1
AH
用に新たな IPv4
接続および IPv6
接続を有効にします。
rule protocol value="ah" accept
5.15.4.2. リッチルールログコマンドの使用例 2
FTP
および audit を使用した 1 分あたり 1 件のログ用に新たな IPv4
および IPv6
接続を許可します :
rule service name="ftp" log limit value="1/m" audit accept
5.15.4.3. リッチルールログコマンドの使用例 3
TFTP
と syslog を使用した毎分 1 件のログ用にアドレス 192.168.0.0/24
からの新たな IPv4
接続を許可します。
rule family="ipv4" source address="192.168.0.0/24" service name="tftp" log prefix="tftp" level="info" limit value="1/m" accept
5.15.4.4. リッチルールログコマンドの使用例 4
RADIUS
用の 1:2:3:4:6::
からの新たな IPv6
接続はすべて拒否され、1 分あたり 3 件のログが作成されます。その他のソースからの新たな IPv6
接続は許可されます。
rule family="ipv6" source address="1:2:3:4:6::" service name="radius" log prefix="dns" level="info" limit value="3/m" reject rule family="ipv6" service name="radius" accept
5.15.4.5. リッチルールログコマンドの使用例 5
TCP
を使用してポート 4011 で 1:2:3:4:6::
から受信した IPv6
パケットを、ポート 4012 上の 1::2:3:4:7
に転送します。
rule family="ipv6" source address="1:2:3:4:6::" forward-port to-addr="1::2:3:4:7" to-port="4012" protocol="tcp" port="4011"
5.15.4.6. リッチルールログコマンドの使用例 6
rule family="ipv4" source address="192.168.2.2" accept
firewalld.richlanguage(5)
を参照してください。
5.16. ファイアウォールロックダウンの設定
root
で実行していれば (たとえば libvirt) ファイアウォール設定を変更することができます。この機能を使用すると、管理者はファイアウォール設定をロックして、どのアプリケーションもファイアウォール変更を要求できなくするか、ロックダウンのホワイトリストに追加されたアプリケーションのみがファイアウォール変更を要求できるようにすることが可能になります。ロックダウン設定はデフォルトで無効になっています。これを有効にすると、ローカルのアプリケーションやサービスによるファイアウォールの望ましくない設定変更を確実に防ぐことができます。
5.16.1. コマンドラインクライアントを使用してロックダウンの設定
root
で以下のコマンドを使用します。
~]# firewall-cmd --query-lockdown
ロックダウンが有効な場合は終了ステータスが 0
で yes
が出力され、無効の場合は終了ステータスが 1
で no
が出力されます。
root
で以下のコマンドを実行します。
~]# firewall-cmd --lockdown-on
root
で以下のコマンドを実行します。
~]# firewall-cmd --lockdown-off
5.16.2. コマンドラインクライアントでホワイトリストオプションの設定
~]$ ps -e --context
このコマンドで、実行中のアプリケーションがすべて返されます。grep ツールを使用して、出力から目的のアプリケーションを以下のようにパイプ処理します。
~]$ ps -e --context | grep example_program
root
で以下のコマンドを実行します。
~]# firewall-cmd --list-lockdown-whitelist-commands
root
で以下のコマンドを実行します。
~]# firewall-cmd --add-lockdown-whitelist-command='/usr/bin/python -Es /usr/bin/command'
root
で以下のコマンドを実行します。
~]# firewall-cmd --remove-lockdown-whitelist-command='/usr/bin/python -Es /usr/bin/command'
root
で以下のコマンドを実行します。
~]# firewall-cmd --query-lockdown-whitelist-command='/usr/bin/python -Es /usr/bin/command'
True の場合は終了ステータスが 0
で yes
が出力され、False の場合は終了ステータスが 1
で no
が出力されます。
root
で以下のコマンドを実行します。
~]# firewall-cmd --list-lockdown-whitelist-contexts
root
で以下のコマンドを実行します。
~]# firewall-cmd --add-lockdown-whitelist-context=context
root
で以下のコマンドを実行します。
~]# firewall-cmd --remove-lockdown-whitelist-context=context
root
で以下のコマンドを実行します。
~]# firewall-cmd --query-lockdown-whitelist-context=context
コマンドがある場合は終了ステータスが 0
で yes
が出力され、ない場合は終了ステータスが 1
で no
が出力されます。
root
で以下のコマンドを実行します。
~]# firewall-cmd --list-lockdown-whitelist-uids
root
で以下のコマンドを実行します。
~]# firewall-cmd --add-lockdown-whitelist-uid=uid
root
で以下のコマンドを実行します。
~]# firewall-cmd --remove-lockdown-whitelist-uid=uid
~]$ firewall-cmd --query-lockdown-whitelist-uid=uid
コマンドがある場合は終了ステータスが 0
で yes
が出力され、ない場合は終了ステータスが 1
で no
が出力されます。
root
で以下のコマンドを実行します。
~]# firewall-cmd --list-lockdown-whitelist-users
root
で以下のコマンドを実行します。
~]# firewall-cmd --add-lockdown-whitelist-user=user
root
で以下のコマンドを実行します。
~]# firewall-cmd --remove-lockdown-whitelist-user=user
~]$ firewall-cmd --query-lockdown-whitelist-user=user
コマンドがある場合は終了ステータスが 0
で yes
が出力され、ない場合は終了ステータスが 1
で no
が出力されます。
5.16.3. 設定ファイルを使用したロックダウンホワイトリストオプションの設定
<?xml version="1.0" encoding="utf-8"?> <whitelist> <selinux context="system_u:system_r:NetworkManager_t:s0"/> <selinux context="system_u:system_r:virtd_t:s0-s0:c0.c1023"/> <user id="0"/> </whitelist>
firewall-cmd
ユーティリティーのコマンドと、ユーザー ID が 815
である user のコマンドすべてを有効にしています。
<?xml version="1.0" encoding="utf-8"?> <whitelist> <command name="/usr/bin/python -Es /bin/firewall-cmd*"/> <selinux context="system_u:system_r:NetworkManager_t:s0"/> <user id="815"/> <user name="user"/> </whitelist>上記の例では
user id
と user name
の両方が使用されていますが、実際にはどちらか一方のみのオプションが必要になります。インタープリターは Python なので、コマンドラインに追加されています。または、以下のような明確なコマンドも使用できます。 /usr/bin/python /bin/firewall-cmd --lockdown-on
この例では、--lockdown-on
コマンドのみが許可されます。
注記
/usr/bin/
ディレクトリーに格納されており、/bin/
ディレクトリーは /usr/bin/
ディレクトリーのシンボリックリンクとなります。つまり、root
で firewall-cmd
のパスを実行すると /bin/firewall-cmd
に対して解決しますが、/usr/bin/firewall-cmd
が使用できるようになっています。新たなスクリプトはすべて新しい格納場所を使用する必要がありますが、root
で実行するスクリプトが /bin/firewall-cmd
のパスを使用するようなっているのであれば、通常 root
ユーザー以外のみに使用される /usr/bin/firewall-cmd
パスに加え、このコマンドパスもホワイトリストに加える必要があります。
5.17. 拒否されたパケットに対するロギングの設定
firewalld
で LogDenied
オプションを使用して、拒否したパケットに簡易ロギングメカニズムを追加できます。これらは拒否または破棄されます。ログ設定を変更するには、/etc/firewalld/firewalld.conf
ファイルを変更するか、コマンドラインまたは GUI 設定ツールを使用します。
LogDenied
を有効にすると、デフォルトルールの INPUT、FORWARD、および OUTPUT チェインの reject ルールおよび drop ルールと、ゾーンの最後の reject ルールおよび drop ルールの直前に、ロギングルールが追加されます。ここに設定できる値は、all
、unicast
、broadcast
、multicast
、および off
です。デフォルト設定は off
です。unicast
、broadcast
、multicast
の設定では、リンク層のパケットタイプを一致させるのに pkttype
一致を使用します。all
を使用すると、すべてのパケットがログに記録されます。
LogDenied
設定を一覧表示するには、root
で以下のコマンドを使用します。
~]# firewall-cmd --get-log-denied
off
LogDenied
設定を変更するには、root
で以下のコマンドを実行します。
~]# firewall-cmd --set-log-denied=all
success
firewalld
GUI 設定ツールを使用して LogDenied
設定を変更するには、firewall-config を起動し、Options メニューをクリックし、 を選択します。LogDenied
ウィンドウが表示されます。メニューから LogDenied
設定を選択し、OK をクリックします。
5.18. 関連情報
firewalld
に関する追加リソースが提供されています。
5.18.1. インストールされているドキュメント
firewalld(1)
の man ページ -firewalld
のコマンドオプションについて説明しています。firewalld.conf(5)
の man ページ -firewalld
の設定に関する情報が含まれています。firewall-cmd(1)
の man ページ -firewalld
コマンドラインクライアントのコマンドオプションについて説明しています。firewall-config(1)
の man ページ - firewall-config ツールの設定を説明します。firewall-offline-cmd(1)
の man ページ -firewalld
オフラインのコマンドラインクライアントを説明します。firewalld.icmptype(5)
の man ページ -ICMP
フィルタリングの XML 設定ファイルについて説明しています。firewalld.ipset(5)
の man ページ -firewalld
IP
セットの XML 設定ファイルを説明します。firewalld.service(5)
の man ページ - firewalld service の XML 設定ファイルについて説明しています。firewalld.zone(5)
の man ページ -firewalld
ゾーン設定の XML 設定ファイルについて説明しています。firewalld.direct(5)
の man ページ -firewalld
ダイレクトインターフェース設定ファイルについて説明しています。firewalld.lockdown-whitelist(5)
の man ページ -firewalld
ロックダウンホワイトリストの設定ファイルについて説明しています。firewalld.richlanguage(5)
の man ページ -firewalld
リッチ言語ルール構文を説明します。firewalld.zones(5)
の man ページ - ゾーンの全般的な説明と設定方法が説明されています。firewalld.dbus(5)
の man ページ -firewalld
のD-Bus
インターフェースを説明します。
5.18.2. オンラインのドキュメント
- http://www.firewalld.org/ -
firewalld
ホームページ
第6章 システム監査
- イベントの日時、タイプ、結果
- サブジェクトとオブジェクトの機密性のラベル
- イベントを開始したユーザーの ID とイベントの関連性
- Audit 設定の全修正および Audit ログファイルへのアクセス試行
- SSH、Kerberos、およびその他の認証メカニズムのすべての使用。
/etc/passwd
のような、信頼できるデータベースへの変更。- システムからの情報のインポートおよびシステムへの情報のエクスポートの試行。
- ユーザー ID、サブジェクトおよびオブジェクトラベル、その他の属性に基づく include または exclude イベント
- 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)
- 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 は、特定のシステムコールが使用されるたびにログエントリーを生成するように設定できます。これを使用すると、
settimeofday
やclock_adjtime
、その他の時間関連のシステムコールを監視することで、システム時間への変更を追跡できます。 - ユーザーが実行したコマンドの記録
- Audit はファイルが実行されたかどうかを追跡できるので、特定のコマンドの実行を毎回記録するようにルールを定義することができます。たとえば、
/bin
ディレクトリー内の実行可能ファイルすべてについてルールを定義することができます。その結果できるログエントリーをユーザー ID で検索すると、ユーザーごとに実行されたコマンドの監査証跡を生成することができます。 - システムのパス名実行の記録
- ルールの呼び出し時にパスを inode に変換するファイルアクセスをウォッチする以外に、ルールの呼び出し時に存在しない場合や、ルールの呼び出し後にファイルが置き換えられた場合でも、Audit がパスの実行をウォッチできるようになりました。これにより、ルールは、プログラム実行ファイルをアップグレードした後、またはインストールされる前にも機能を継続できます。
- セキュリティーイベントの記録
pam_faillock
認証モジュールは、失敗したログイン試行を記録することができます。Audit で失敗したログイン試行も記録するように設定すると、ログインを試みたユーザーについての追加情報が提供されます。- イベントの検索
- Audit は ausearch ユーティリティーを提供します。これを使うと、ログエントリーをフィルターにかけ、いくつもの条件に基づく完全な監査証跡を提供することができます。
- サマリーレポートの実行
- aureport ユーティリティーを使うと、記録されたイベントのデイリーレポートを生成することができます。システム管理者は、このレポートを分析し、疑わしいアクティビティーをさらに調べることができます。
- ネットワークアクセスの監視
- iptables と ebtables ユーティリティーは Audit イベントを開始するように設定でき、これでシステム管理者はネットワークアクセスを監視できるようになります。
注記
6.1. Audit システムのアーキテクチャー
- audisp — Audit ディスパッチャーデーモンは Audit デーモンと対話し、イベントを他のアプリケーションに送信してさらに処理します。このデーモンの目的は、プラグインメカニズムを提供して、リアルタイムの分析プログラムが Audit イベントと対話できるようにすることです。
- auditctl — Audit 制御ユーティリティーはカーネル Audit コンポーネントと対話し、ルールを管理するだけでなくイベント生成プロセスの多くの設定やパラメーターも制御します。
- 残りの Audit ユーティリティーは Audit ログファイルのコンテンツを入力として受け取り、ユーザーの要件に基づいて出力を生成します。たとえば、aureport ユーティリティーは記録された全イベントのレポートを生成します。
6.2. audit パッケージのインストール
~]# yum install audit
6.3. audit
サービスの設定
/etc/audit/auditd.conf
ファイルに設定できます。このファイルは、Audit デーモンの挙動を修正する設定パラメーターから構成されます。空の行とハッシュ記号 (#
) に続くテキストは無視されます。詳細は、man ページの auditd.conf(5) を参照してください。
6.3.1. セキュアな環境用の auditd
設定
auditd
設定は多くの環境に適している必要がありますが、環境が、厳格なセキュリティーポリシーに対応する必要がある場合は、/etc/audit/auditd.conf
ファイルの Audit デーモン設定に対して以下の設定が推奨されます。
- log_file
- 各マウントポイントには、Audit ログファイル (通常
/var/log/audit/
) を保持するディレクトリーが必要になります。これにより、このディレクトリーの領域をその他のプロセスが使用しないようにし、Audit デーモンの残りのスペースの正確な検出を提供します。 - max_log_file
- 1 つの Audit ログファイルの最大サイズを指定します。Audit ログファイルを保持するパーティションで利用可能な領域をすべて使用するように設定する必要があります。
- max_log_file_action
max_log_file
に設定した制限に達すると発生するアクションを指定します。Audit ログファイルが上書きされないないようにするには、keep_logs
に設定する必要があります。- space_left
space_left_action
パラメーターに設定したアクションを発生させる、ディスクの空き領域サイズを指定します。この制限に達したときに管理者が十分対応できるだけの時間を設定する必要があります。space_left
値は、Audit ログファイルが生成される速度によって異なります。- space_left_action
space_left_action
パラメーターは、email
またはexec
など、適切な通知方法に設定することが推奨されます。- admin_space_left
admin_space_left_action
パラメーターに設定したアクションが発生するディスクの空き領域の最小サイズ。管理者が実行するアクションのログを記録するのに十分なサイズを残す必要があります。- admin_space_left_action
single
を、システムをシングルユーザーモードにし、監理者がディスク領域を解放できるようにします。- disk_full_action
- Audit ログファイルを保持するパーティションで空き領域がない場合に発生するアクションを指定します。
halt
またはsingle
に設定する必要があります。このように設定すると、Audit がイベントをログに記録できなくなると、システムはシャットダウンまたはシングルユーザーモードで動作します。 - disk_error_action
- Audit ログファイルがあるパーティションでエラーが検出された場合に発生するアクションを指定します。このパラメーターは、ハードウェアの機能不全処理に関するローカルのセキュリティーポリシーによって、
syslog
、single
、halt
のいずれかに設定する必要があります。 - flush
incremental_async
に設定してください。ハードドライブと強制同期する前にディスクに送信できる記録数を決めるfreq
パラメーターと合わせて機能します。freq
パラメーターは、100
に設定してください。これらのパラメーターにより、アクティビティーが集中した場合に高いパフォーマンスを保ちつつ、Audit イベントデータがディスク上のログファイルと確実に同期されるようにします。
6.4. audit
サービスの起動
auditd
を設定すると、サービスが開始して Audit 情報を収集し、ログファイルに保存します。root 権限で以下のコマンドを実行し、auditd
を開始します。
~]# service auditd start
注記
service
コマンドは、auditd
デーモンと正しく対話する唯一の方法です。auid
の値が正しく記録されるように service
コマンドを使用する必要があります。systemctl
コマンドは、enable
と status
の 2 つのアクションにのみ使用できます。
auditd
サービスが開始するように設定するには、以下を実行します。
~]# systemctl enable auditd
auditd
では、service auditd action
コマンドを使用して、他のアクションを実行できます。action は、以下のいずれかになります。
stop
auditd
を停止します。restart
auditd
を再起動します。reload
またはforce-reload
/etc/audit/auditd.conf
ファイルは、auditd の設定を再ロードします。rotate
- ログファイルを
/var/log/audit/
ディレクトリーにローテートします。 resume
- Audit イベントのログが一旦停止した後、再開します。たとえば、Audit ログファイルがあるディスクパーティションの未使用スペースが不足している場合などです。
condrestart
またはtry-restart
- auditd がすでに起動している場合にのみ、これを再起動します。
status
- auditd の稼働状況を表示します。
6.5. Audit ルールの定義
- 制御ルール
- Audit システムの動作と、一部の設定を修正するのを許可します。
- ファイルシステムのルール
- ファイルの監視としても知られており、特定のファイルまたはディレクトリーへのアクセスを監査できます。
- システムコールのルール
- 指定したプログラムが作成するシステムコールのログを許可します。
- auditctl ユーティリティーを使用したコマンドライン。このルールはシステムの再起動後は永続化しません。詳細は 「auditctl で監査ルールの定義」 を参照してください。
/etc/audit/audit.rules
ファイル。詳細は 「永続的な Audit ルールの定義と/etc/audit/audit.rules
ファイルでの制御」 を参照してください。
6.5.1. auditctl で監査ルールの定義
auditctl
コマンドを使うと、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
-w /etc/passwd -p wa -k passwd_changes -w /etc/selinux -p wa -k selinux_changes -w /sbin/insmod -p x -k module_insertion ⋮ -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 は、どのルールまたはルールセットが特定のログエントリーを生成したかを特定する際に役立つオプションの文字列です。
例6.1 ファイルシステムルール
/etc/passwd
ファイルへのすべての書き込みアクセスとこのファイルのすべての属性変更をログ記録するルールを定義するには、以下のコマンドを実行します。
~]# auditctl -w /etc/passwd -p wa -k passwd_changes
-k
オプションに続く文字列は任意のものであることに注意してください。
/etc/selinux/
ディレクトリー内の全ファイルへのすべての書き込みアクセスとこれらファイルのすべての属性変更をログ記録するルールを定義するには、以下のコマンドを実行します。
~]# auditctl -w /etc/selinux/ -p wa -k selinux_changes
/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 は、イベントに適用するカーネルルール適合のフィルターを指定します。ルール適合フィルターは、task
、exit
、user
、exclude
のいずれかになります。これらフィルターの詳細は、「Audit システムのアーキテクチャー」 の冒頭部分を参照してください。 - system_call は、名前でシステムコールを指定します。システムコールの全一覧は、
/usr/include/asm/unistd_64.h
ファイルで確認できます。複数のシステムコールをひとつのグループにまとめて、-S
オプションの後にそれらを指定することも可能です。 - field=value では、指定されたアーキテクチャー、グループ ID、プロセス ID などに基づいて、ルールがイベントに合致するようさらに修正する追加オプションを指定します。利用可能なフィールドのタイプおよびその値の一覧は、man ページの auditctl(8) で確認できます。
- key_name は、どのルールまたはルールセットが特定のログエントリーを生成したかを特定する際に役立つオプションの文字列です。
例6.2 システムコールのルール
adjtimex
または settimeofday
を使用するたびにログエントリーを作成するルールを定義するには、以下のコマンドを実行します。
~]# auditctl -a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time_change
~]# auditctl -a always,exit -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=4294967295 -k delete
-F auid!=4294967295
オプションが、ログイン UID が設定されていないユーザーを除外するために使用されています。
-w /etc/shadow -p wa
ファイルシステムルールに似たシステムコールのルールが作成されます。
~]# auditctl -a always,exit -F path=/etc/shadow -F perm=wa
6.5.2. 実行可能なファイルルールの定義
auditctl -a action,filter [ -F arch=cpu -S system_call] -F exe=path_to_executable_file -k key_name
- action および filter は、特定のイベントがログ記録されるタイミングを指定します。action は、
always
またはnever
になります。filter は、イベントに適用するカーネルルール適合のフィルターを指定します。ルール適合フィルターは、task
、exit
、user
、exclude
のいずれかになります。これらフィルターの詳細は、「Audit システムのアーキテクチャー」 の冒頭部分を参照してください。 - system_call は、名前でシステムコールを指定します。システムコールの全一覧は、
/usr/include/asm/unistd_64.h
ファイルで確認できます。複数のシステムコールをひとつのグループにまとめて、-S
オプションの後にそれらを指定することも可能です。 - path_to_executable_file は、監査する実行可能ファイルへの絶対パスに置き換えてください。
- key_name は、どのルールまたはルールセットが特定のログエントリーを生成したかを特定する際に役立つオプションの文字列です。
例6.3 実行可能なファイルルール
/bin/id
プログラムのすべ手の実行をロギングするルールを定義するには、以下のコマンドを実行します。
~]# auditctl -a always,exit -F exe=/bin/id -F arch=b64 -S execve -k execution_bin_id
6.5.3. 永続的な Audit ルールの定義と /etc/audit/audit.rules
ファイルでの制御
/etc/audit/audit.rules
ファイルにそのルールを直接追加するか、/etc/audit/rules.d/
ディレクトリーに置かれたルールを読み込む augenrules プログラムを使用します。/etc/audit/audit.rules
ファイルは、そのルールを指定するコマンドと同じ auditctl
構文を使用します。空の行と、ハッシュ記号 (#
) に続くテキストは無視されます。
auditctl
コマンドは、以下のように -R
オプションを使用して指定したファイルからルールを読み込むのに使用することもできます。
~]# auditctl -R /usr/share/doc/audit/rules/30-stig.rules
制御ルールの定義
-b
、-D
、-e
、-f
、-r
、--loginuid-immutable
、および --backlog_wait_time
) です。このオプションの詳細は 「制御ルールの定義」 を参照してください。
例6.4 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 # Make login UID immutable once it is set (may break containers) --loginuid-immutable 1
ファイルシステムおよびシステムコールのルールの定義
auditctl
構文を使用して定義されます。「auditctl で監査ルールの定義」 の例は、以下のルールファイルで表示されます。
例6.5 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>=1000 -F auid!=4294967295 -k delete
事前設定ルールのファイル
/usr/share/doc/audit/rules/
ディレクトリーでは、audit パッケージが各種の証明書基準にしたがって事前設定ルールのファイル一式を提供しています。
30-nispom.rules
- NISPOM (National Industrial Security Program Operating Manual) の「Information System Security」の章で指定している要件を満たす Audit ルール設定30-pci-dss-v31.rules
- Payment Card Industry Data Security Standard (PCI DSS) v3.1 で指定されている要件を満たす Audit 設定です。30-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/rules/30-stig.rules /etc/audit/audit.rules
注記
/usr/share/doc/audit/rules/README-rules
ファイルを参照してください。
永続ルールを定義する augenrules の使用
/etc/audit/rules.d/
ディレクトリーに置いたルールを読み込み、そのルールを audit.rules
ファイルにコンパイルします。このスクリプトは、自然のソート順に基づいて特定の順番で .rules
で終わるすべてのファイルを処理します。このディレクトリーのファイルは、以下の意味を持つグループにまとめられます。
- 10 - カーネルおよび auditctl 設定
- 20 - 一般的なルールに該当してしまう可能性もあるが、ユーザー側で独自ルールを作成することも可能
- 30 - 主なルール
- 40 - 任意のルール
- 50 - サーバー固有のルール
- 70 - システムのローカルルール
- 90 - ファイナライズ (不変)
/etc/audit/rules.d/
にコピーされます。たとえば、STIG 設定でシステムを設定するために、10-base-config、30-stig、31-privileged、および 99-finalize のルールをコピーします。
/etc/audit/rules.d/
ディレクトリーにルールを置いたら、--load
ディレクティブに augenrules スクリプトを実行してロードします。
~]# augenrules --load
augenrules --load No rules
enabled 1
failure 1
pid 634
rate_limit 0
backlog_limit 8192
lost 0
backlog 0
enabled 1
failure 1
pid 634
rate_limit 0
backlog_limit 8192
lost 0
backlog 1
audit.rules(8)
and augenrules(8)
を参照してください。
6.6. Audit ログファイルについて
/var/log/audit/audit.log
ファイルに保存します。ログローテーションが有効になっていれば、ローテーションされた audit.log
ファイルは同じディレクトリーに保存されます。
/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=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 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 objtype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 type=PROCTITLE msg=audit(1364481363.243:24287) : proctitle=636174002F6574632F7373682F737368645F636F6E666967
type=
キーワードで始まります。各レコードは、複数の name=value
ペアから成り、各ペアは空白またはコンマで区切られています。以下で、上記のイベントを詳しく解析します。
最初の記録
type=SYSCALL
type
フィールドには、記録のタイプが記載されます。この例では、この記録がカーネルへのシステムコールで開始されたことをSYSCALL
の値が示しています。利用可能なすべてのタイプの値およびそれらの説明に関する一覧は、Audit 記録のタイプ を参照してください。msg=audit(1364481363.243:24287):
msg
フィールドでは以下を記録しています。audit(time_stamp:ID)
の形式で、記録のタイムスタンプと一意の ID。複数の記録は、それらが同一の Audit イベントの一部として生成されている場合は、同じタイムスタンプと ID を共有できます。タイムスタンプは、Unix の時間フォーマット (1970 年 1 月 1 日 00:00:00 UTC からの秒数) を使用しています。- 各種のイベント固有の
name=value
ペア。これは、カーネルもしくはユーザースペースアプリケーションが提供します。
arch=c000003e
arch
フィールドには、システムの CPU アーキテクチャーについての情報が含まれます。c000003e
という値は、十六進法でエンコードされています。ausearch
コマンドで Audit 記録を検索する際は、-i
または--interpret
オプションを使うと自動的に十六進法の値がヒューマンリーダブルなものに変換されます。c000003e
の値は、x86_64
として解釈されます。syscall=2
syscall
フィールドは、カーネルに送信されたシステムコールのタイプを記録します。2
という値は、/usr/include/asm/unistd_64.h
ファイルにある、人間が可読可能なものに相当するものに一致します。このケースでは、2
はオープンな
システムコールになります。ausyscall ユーティリティーを使用すると、システムコール番号を人間が可読可能なものに変換できることに注意してください。ausyscall --dump
コマンドを実行すると、すべてのシステムコールとその番号一覧が表示されます。詳細情報は、man ページの ausyscall(8) を参照してください。success=no
success
フィールドは、その特定のイベントで記録されたシステムコールが成功したかどうかを記録します。このケースでは、コールは成功しませんでした。exit=-13
exit
フィールドには、システムコールが返した終了コードを指定する値が含まれています。この値は、システムコールによって異なります。以下のコマンドを使用すると、この値を人間が可読可能なものに変換できます。~]#
ausearch --interpret --exit -13
この例では、監査ログは、終了コード-13
で失敗したイベントが含まれていることが前提となります。a0=7fffd19c5592
,a1=0
,a2=7fffd19c5592
,a3=a
a0
からa3
までのフィールドは、このイベントにおけるシステムコー