潜在的な侵入者は、ネットワークトラフィックの中断、傍受、経路変更を可能にする様々なツールを自由に駆使して、システムに侵入します。一般的には、これらの脅威は以下のとおり分類できます。

いずれの手法でも、潜在的な機密情報を傍受することが可能です。その傍受が悪意のある理由で行われる場合には、悲惨な結果をもたらしかねません。リモートシェルログインとファイルコピー用に SSH を使用すると、こうしたセキュリティー脅威を大幅に軽減することができます。これは、SSH クライアントとサーバーがデジタル署名を使用してそれぞれの ID を確認するためです。さらに、クライアントシステムとサーバーシステムとの間の全通信は暗号化されます。各パケットはローカルシステムとリモートシステムのみに知られている鍵を使用して暗号化されるため、通信のいずれか一方の ID をスプーフィングする試みは成功しません。

SSH プロトコルは以下のような保護手段を提供します。

さらに、SSH プロトコルは以下のようなオプションも提供します。

現在、SSH には、バージョン 1 と、新しいバージョンのバージョン 2 があります。Red Hat Enterprise Linux 8 の OpenSSH スイートでは、SSH バージョン 2 を使用します。バージョン 2 は、バージョン 1 で既知の不正使用に対し、脆弱性のない拡張された鍵交換アルゴリズムを使用します。Red Hat Enterprise Linux 8 では、OpenSSH スイートはバージョン 1 の接続には対応していません。

以下に挙げる一連のイベントは、2 つのホスト間で行われる SSH 通信の整合性を保護するのに役立ちます。

OpenSSH スイートは、設定ファイルのセットを 2 つ使用します。クライアントプログラム (つまり ssh、scp、および sftp) の設定ファイルと、サーバー (sshd デーモン) の設定ファイルです。

システム全体の SSH 設定情報が /etc/ssh/ ディレクトリーに保存されます。ユーザー固有の SSH 設定情報は、ユーザーのホームディレクトリーの ~/.ssh/ に保存されます。

SSH 設定ファイルに使用できる各種ディレクティブの情報は、man ページの ssh_config(5) および sshd_config(5) を参照してください。

OpenSSH サーバーを実行するには、openssh-server パッケージをインストールします。現行セッションで sshd デーモンを起動するには、以下を行います。

# systemctl start sshd.service

現行セッションで sshd デーモンを設定するには、以下を行います。

# systemctl stop sshd.service

システムの起動時にデーモンを自動的に起動するには、以下を行います。

# systemctl enable sshd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/sshd.service to /usr/lib/systemd/system/sshd.service.

sshd デーモンは network.target ターゲットユニットに依存しますが、静的設定のネットワークインターフェースやデフォルトの ListenAddress 0.0.0.0 オプションの場合はこれで十分です。ListenAddress ディレクティブで別のアドレスを指定し、より遅い動的ネットワーク設定を使用するには、network-online.target ターゲットユニットの依存関係を sshd.service ユニットファイルに追加します。これを行うには、/etc/systemd/system/sshd.service.d/local.conf ファイルを以下のオプションで作成します。

  [Unit]
  Wants=network-online.target
  After=network-online.target

この後、以下のコマンドで systemd マネージャー設定をリロードします。

# systemctl daemon-reload

システムを再インストールすると、新しい識別鍵のセットが作成される点に注意してください。そのため、再インストールの前にいずれかの OpenSSH ツールを使用してシステムに接続したことがあるクライアントには、以下のようなメッセージが表示されます。

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.

これを防ぐには、/etc/ssh/ ディレクトリーから関連ファイルをバックアップしておきます。ファイルの一覧は 表1.1「システム全体の設定ファイル」 を参照してください。これで、システムの再インストール時にファイルを復元できます。

# systemctl mask sshd-keygen@rsa.service
# systemctl enable sshd-keygen@dsa.service

SSH を本当の意味で有効なものにするためには、セキュリティー保護されていない接続プロトコルは使用しないことをお勧めします。このような接続プロトコルを使用すると、ユーザーのパスワード自体は SSH を使用した 1 回のセッションで保護されても、その後に Telnet を使用してログインした時に傍受されてしまうためです。無効にするサービスには、telnet、rsh、rlogin、vsftpd などがあります。

以下の手順に従って、SSH プロトコルのバージョン 2 用の RSA 鍵ペアを生成します。

SSH プロトコルのバージョン 2 用の ECDSA 鍵ペアを生成するには、以下のステップに従います。

最新バージョンの TLS は、最高のセキュリティーメカニズムを提供します。古いバージョンの TLS をサポートするような特別な事情がない限り、システムが少なくとも TLS バージョン 1.2 を使用して接続をネゴシエートできるようにしてください。RHEL 8 が TLS バージョン 1.3 に対応しているにもかかわらず、RHEL 8 コンポーネントがこのプロトコルのすべての機能をサポートしているわけではないことに注意してください。たとえば、現時点では、Apache または Nginx の Web サーバーは、接続レイテンシーを短縮する 0-RTT (Zero Round Trip Time) 機能に完全に対応していません。

旧式で、安全ではない暗号化スイートではなく、最近の、より安全なものを使用してください。eNULL および aNULL 暗号化スイートは暗号化や認証を提供しないため、常に無効にしてください。RC4 や HMAC-MD をベースとした暗号化スイートには深刻な欠陥があるため、可能な場合はこれも無効にしてください。いわゆるエクスポート暗号化スイートも同様です。エクスポート暗号化スイートは意図的に弱くなっているため、侵入が容易になっています。

128 ビット未満のセキュリティーしか提供しない暗号化スイートでは直ちにセキュリティーが保護されなくなるというわけではありませんが、耐用年数が短いため考慮すべきではありません。アルゴリズムが 128 ビット以上のセキュリティーを使用している場合は、少なくとも数年間は解読不可能であることが期待されているため、強く推奨されます。3DES 暗号は 168 ビットを使用していると言われていますが、実際に提供されているのは 112 ビットのセキュリティーであることに注意してください。

サーバーの鍵が危険にさらされた場合でも、暗号化したデータの機密性を保証する (完全な) 前方秘匿性 (PFS) に対応する暗号スイートを常に優先します。ここでは、速い RSA 鍵交換は除外されますが、ECDHE および DHE は使用できます。この 2 つを比べると、ECDHE の方が速いため推奨されます。

AES-GCM などの AEAD は、パディングオラクル攻撃に対して脆弱ではないため、CBC モード暗号よりも優先する必要があります。さらに、多くの場合、特にハードウェアに AES 用の暗号化アクセラレーターがある場合、AES-GCM は CBC モードの AES よりも高速です。

ECDSA 証明書で ECDHE 鍵交換を使用すると、トランザクションは純粋な RSA 鍵交換よりもさらに高速になります。レガシークライアントに対応するため、サーバーには証明書と鍵のペアを 2 つ (新しいクライアント用の ECDSA 鍵と、レガシー用の RSA 鍵) インストールできます。

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

関連資料

Apache HTTP Server は、その TLS のニーズに、OpenSSL ライブラリーおよび NSS ライブラリーの両方を使用できます。

# yum install mod_ssl

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

httpd-manual パッケージをインストールして、TLS 設定を含む Apache HTTP Server の完全ドキュメントを取得します。/etc/httpd/conf.d/ssl.conf 設定ファイルで利用可能なディレクティブの詳細は、/usr/share/httpd/manual/mod/mod_ssl.html を参照してください。各種設定の例は /usr/share/httpd/manual/ssl/ssl_howto.html で確認できます。

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

たとえば、TLS 1.2 プロトコルおよび 1.3 プロトコルだけを使用する場合は、以下を実行します。

SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1

nginx で TLS 1.3 サポートを有効にするには、/etc/nginx/nginx.conf 設定ファイルの server セクションで、ssl_protocols オプションに TLSv1.3 値を追加します。

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    ....
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers
    ....
}

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

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

たとえば、/etc/dovecot/conf.d/10-ssl.conf 内の次の行が、TLS 1.1 以降だけを許可します。

ssl_protocols = !SSLv2 !SSLv3 !TLSv1

関連資料

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

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

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

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

関連資料

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# firewall-cmd --permanent <other options>

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

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

手順

関連資料

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

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

手順

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

# firewall-cmd --panic-off

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

# firewall-cmd --query-panic

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

手順

事前定義したサービスまたはカスタマイズしたサービスを有効または無効にするには、以下を行います。

サービスを編集するには、以下を行います。

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

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

手順

firewalld がアクティブでない場合に、ターミナルで新しいサービスを追加するには、firewall-cmd または firewall-offline-cmd を使用します。

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

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

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

ファイアウォールを経由して特定のポートに向かうトラフィックを許可するには、以下を行います。

特定のプロトコルを使用してファイアウォールを経由したトラフィックを許可するには、以下を行います。

特定ポートからファイアウォールを経由したトラフィックを許可するには、以下を行います。

手順

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

手順

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

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

手順

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

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

手順

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

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

手順

カスタムゾーンを使用するには、新しいゾーンを作成したり、事前定義したゾーンなどを使用したりします。新しいゾーンには --permanent オプションが必要となり、このコマンドがなければコマンドが動作しません。

手順

新しいゾーンを作成するには、以下を行います。

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

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>

そのゾーンの設定を変更するには、セクションを追加または削除して、ポート、転送ポート、サービスなどを追加します。

関連資料

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

手順

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

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

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

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

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

手順

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

手順

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

手順

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

手順

特定のネットワークからのトラフィックを許可してマシンのサービスを使用するには、ゾーンおよびソースを使用します。以下の手順では、その他のトラフィックをブロックしつつ、192.168.1.0/24 からのトラフィックを許可し、HTTP サービスに到達できるようにします。

手順

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

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

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

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

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

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

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

<?xml version="1.0" encoding="utf-8"?>
	<whitelist>
	  <command name="/usr/bin/python3 -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/python3 /bin/firewall-cmd --lockdown-on

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