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

手順

1. ECDSA 鍵ペアを生成します。

   $ ssh-keygen -t ecdsa
   Generating public/private ecdsa key pair.
   Enter file in which to save the key (/home/<username>/.ssh/id_ecdsa):
   Enter passphrase (empty for no passphrase): <password>
   Enter same passphrase again: <password>
   Your identification has been saved in /home/<username>/.ssh/id_ecdsa.
   Your public key has been saved in /home/<username>/.ssh/id_ecdsa.pub.
   The key fingerprint is:
   SHA256:Q/x+qms4j7PCQ0qFd09iZEFHA+SqwBKRNaU72oZfaCI <username>@<localhost.example.com>
   The key's randomart image is:
   +---[ECDSA 256]---+
   |.oo..o=++        |
   |.. o .oo .       |
   |. .. o. o        |
   |....o.+...       |
   |o.oo.o +S .      |
   |.=.+.   .o       |
   |E.*+.  .  . .    |
   |.=..+ +..  o     |
   |  .  oo*+o.      |
   +----[SHA256]-----+

   パラメーターなしで ssh-keygen コマンドを使用して RSA 鍵ペアを生成することも、ssh-keygen -t ed25519 コマンドを入力して Ed25519 鍵ペアを生成することもできます。Ed25519 アルゴリズムは FIPS-140 に準拠しておらず、FIPS モードでは OpenSSH は Ed25519 鍵で機能しないことに注意してください。

2. 公開鍵をリモートマシンにコピーします。

   $ ssh-copy-id <username>@<ssh-server-example.com>
   /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
   <username>@<ssh-server-example.com>'s password:
   …
   Number of key(s) added: 1
   
   Now try logging into the machine, with: "ssh '<username>@<ssh-server-example.com>'" and check to make sure that only the key(s) you wanted were added.

   <username>@<ssh-server-example.com> は、認証情報に置き換えます。

   セッションで ssh-agent プログラムを使用しない場合は、上記のコマンドで、最後に変更した ~/.ssh/id*.pub 公開鍵をコピーします (インストールされていない場合)。別の公開キーファイルを指定したり、ssh-agent により、メモリーにキャッシュされた鍵よりもファイル内の鍵の方が優先順位を高くするには、-i オプションを指定して ssh-copy-id コマンドを使用します。

手順

1. テキストエディターで /etc/ssh/sshd_config 設定を開きます。以下に例を示します。

   # vi /etc/ssh/sshd_config

2. PasswordAuthentication オプションを no に変更します。

   PasswordAuthentication no

3. 新しいデフォルトインストール以外のシステムでは、PubkeyAuthentication パラメーターが設定されていないか、yes に設定されていることを確認します。

4. KbdInteractiveAuthentication ディレクティブを no に設定します。

   設定ファイル内では対応するエントリーがコメントアウトされていること、およびデフォルト値が yes であることに注意してください。

5. NFS がマウントされたホームディレクトリーで鍵ベースの認証を使用するには、SELinux ブール値 use_nfs_home_dirs を有効にします。

   # setsebool -P use_nfs_home_dirs 1

6. リモートで接続している場合は、コンソールもしくは帯域外アクセスを使用せず、パスワード認証を無効にする前に、鍵ベースのログインプロセスをテストします。

7. sshd デーモンを再読み込みし、変更を適用します。

   # systemctl reload sshd

手順

1. セッションで ssh-agent を自動的に起動するためのコマンドを ~/.bashrc ファイルに追加します。

   1. 任意のテキストエディターで ~/.bashrc を開きます。次に例を示します。

      $ vi ~/.bashrc

   2. 以下の行をファイルに追加します。

      eval $(ssh-agent)

   3. 変更を保存し、エディターを終了します。

2. ~/.ssh/config ファイルに次の行を追加します。

   AddKeysToAgent yes

   セッションでこのオプションを使用して ssh-agent が起動されると、エージェントはホストに初めて接続するときにのみパスワードを要求します。

手順

1. PKCS #11 の URI を含む OpenSC PKCS #11 モジュールが提供する鍵のリストを表示し、その出力を keys.pub ファイルに保存します。

   $ ssh-keygen -D pkcs11: > keys.pub

2. 公開鍵をリモートサーバーに転送します。ssh-copy-id コマンドを使用し、前の手順で作成した keys.pub ファイルを指定します。

   $ ssh-copy-id -f -i keys.pub <username@ssh-server-example.com>

3. ECDSA 鍵を使用して <ssh-server-example.com> に接続します。鍵を一意に参照する URI のサブセットのみを使用することもできます。次に例を示します。

   $ ssh -i "pkcs11:id=%01?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so" <ssh-server-example.com>
   Enter PIN for 'SSH key':
   [ssh-server-example.com] $

   OpenSSH は p11-kit-proxy ラッパーを使用し、OpenSC PKCS #11 モジュールが p11-kit ツールに登録されているため、前のコマンドを簡略化できます。

   $ ssh -i "pkcs11:id=%01" <ssh-server-example.com>
   Enter PIN for 'SSH key':
   [ssh-server-example.com] $

   PKCS #11 の URI の id= の部分を飛ばすと、OpenSSH が、プロキシーモジュールで利用可能な鍵をすべて読み込みます。これにより、必要な入力の量を減らすことができます。

   $ ssh -i pkcs11: <ssh-server-example.com>
   Enter PIN for 'SSH key':
   [ssh-server-example.com] $

4. オプション: ~/.ssh/config ファイルで同じ URI 文字列を使用して、設定を永続的にすることができます。

   $ cat ~/.ssh/config
   IdentityFile "pkcs11:id=%01?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so"
   $ ssh <ssh-server-example.com>
   Enter PIN for 'SSH key':
   [ssh-server-example.com] $

   ssh クライアントユーティリティーが、この URI とスマートカードの鍵を自動的に使用するようになります。

手順

1. ジャンプサーバーまたは複数の中間サーバーを経由して一度に接続する場合は、ssh -J コマンドを使用してジャンプサーバーを直接指定します。次に例を示します。

   $ ssh -J <jump-1.example.com>,<jump-2.example.com>,<jump-3.example.com> <target-server-1.example.com>

   ジャンプサーバーのユーザー名または SSH ポートが、リモートサーバーの名前およびポートと異なる場合は、上記のコマンドのホスト名のみの表記を変更します。以下に例を示します。

   $ ssh -J <example.user.1>@<jump-1.example.com>:<75>,<example.user.2>@<jump-2.example.com>:<75>,<example.user.3>@<jump-3.example.com>:<75> <example.user.f>@<target-server-1.example.com>:<220>

2. ジャンプサーバーを介してリモートサーバーに定期的に接続する場合は、ジャンプサーバーの設定を SSH 設定ファイルに保存します。

   1. ローカルシステムの ~/.ssh/config ファイルを編集してジャンプホストを定義します。以下に例を示します。

      Host <jump-server-1>
        HostName <jump-1.example.com>

      • Host パラメーターは、ssh コマンドで使用できるホストの名前またはエイリアスを定義します。値は実際のホスト名と一致可能ですが、任意の文字列にすることもできます。
      • HostName パラメーターは、ジャンプホストの実際のホスト名または IP アドレスを設定します。

   2. ProxyJump ディレクティブを使用してリモートサーバーのジャンプ設定を、ローカルシステムの ~/.ssh/config ファイルに追加します。以下に例を示します。

      Host <remote-server-1>
        HostName <target-server-1.example.com>
        ProxyJump <jump-server-1>

   3. ローカルシステムを使用して、ジャンプサーバー経由でリモートサーバーに接続します。

      $ ssh <remote-server-1>

      このコマンドは、前の設定ステップを省略したときの ssh -J jump-server1 remote-server コマンドと同じです。

手順

1. CA の秘密鍵を生成します。たとえば、次のコマンドは、256 ビットの楕円曲線デジタル署名アルゴリズム (ECDSA) キーを作成します。

   $ openssl genpkey -algorithm ec -pkeyopt ec_paramgen_curve:P-256 -out <ca.key>

   キー生成プロセスの時間は、ホストのハードウェアとエントロピー、選択したアルゴリズム、およびキーの長さによって異なります。

2. 前のコマンドで生成された秘密鍵を使用して署名された証明書を作成します。

   $ openssl req -key <ca.key> -new -x509 -days 3650 -addext keyUsage=critical,keyCertSign,cRLSign -subj "/CN=<Example_CA>" -out <ca.crt>

   生成された ca.crt ファイルは、10 年間、他の証明書の署名に使用できる自己署名 CA 証明書です。プライベート CA の場合、<example_CA> をコモンネーム (CN) として任意の文字列に置き換えることができます。

3. CA の秘密鍵に安全なアクセス許可を設定します。次に例を示します。

   # chown <root>:<root> <ca.key>
   # chmod 600 <ca.key>

検証

1. 証明書署名要求 (CSR) を作成し、CA を使用して要求に署名します。CA は、CSR に基づいて証明書を正常に作成する必要があります。次に例を示します。

   $ openssl x509 -req -in <client-cert.csr> -CA <ca.crt> -CAkey <ca.key> -CAcreateserial -days 365 -extfile <openssl.cnf> -extensions <client-cert> -out <client-cert.crt>
   Signature ok
   subject=C = US, O = Example Organization, CN = server.example.com
   Getting CA Private Key

   詳細は、「OpenSSL でプライベート CA を使用して CSR の証明書を発行する」 を参照してください。

2. 自己署名 CA に関する基本情報を表示します。

   $ openssl x509 -in <ca.crt> -text -noout
   Certificate:
   …
           X509v3 extensions:
               …
               X509v3 Basic Constraints: critical
                   CA:TRUE
               X509v3 Key Usage: critical
                   Certificate Sign, CRL Sign
   …

3. 秘密鍵の一貫性を確認します。

   $ openssl pkey -check -in <ca.key>
   Key is valid
   -----BEGIN PRIVATE KEY-----
   MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgcagSaTEBn74xZAwO
   18wRpXoCVC9vcPki7WlT+gnmCI+hRANCAARb9NxIvkaVjFhOoZbGp/HtIQxbM78E
   lwbDP0BI624xBJ8gK68ogSaq2x4SdezFdV1gNeKScDcU+Pj2pELldmdF
   -----END PRIVATE KEY-----

手順

1. 以下のようにサーバーシステムで秘密鍵を生成します。

   $ openssl genpkey -algorithm ec -pkeyopt ec_paramgen_curve:P-256 -out <server-private.key>

2. オプション: 次の例のように、選択したテキストエディターを使用して、CSR の作成を簡素化する設定ファイルを準備します。

   $ vim <example_server.cnf>
   [server-cert]
   keyUsage = critical, digitalSignature, keyEncipherment, keyAgreement
   extendedKeyUsage = serverAuth
   subjectAltName = @alt_name
   
   [req]
   distinguished_name = dn
   prompt = no
   
   [dn]
   C = <US>
   O = <Example Organization>
   CN = <server.example.com>
   
   [alt_name]
   DNS.1 = <example.com>
   DNS.2 = <server.example.com>
   IP.1 = <192.168.0.1>
   IP.2 = <::1>
   IP.3 = <127.0.0.1>

   extendedKeyUsage = serverAuth オプションは、証明書の使用を制限します。

3. 前に作成した秘密鍵を使用して CSR を作成します。

   $ openssl req -key <server-private.key> -config <example_server.cnf> -new -out <server-cert.csr>

   -config オプションを省略すると、req ユーティリティーは次のような追加情報の入力を求めます。

   You are about to be asked to enter information that will be incorporated
   into your certificate request.
   What you are about to enter is what is called a Distinguished Name or a DN.
   There are quite a few fields but you can leave some blank
   For some fields there will be a default value,
   If you enter '.', the field will be left blank.
   -----
   Country Name (2 letter code) [XX]: <US>
   State or Province Name (full name) []: <Washington>
   Locality Name (eg, city) [Default City]: <Seattle>
   Organization Name (eg, company) [Default Company Ltd]: <Example Organization>
   Organizational Unit Name (eg, section) []:
   Common Name (eg, your name or your server's hostname) []: <server.example.com>
   Email Address []: <server@example.com>

検証

1. 要求された証明書を CA から取得したら、次の例のように、証明書の中で人間が判読できる部分が要件と一致することを確認します。

   $ openssl x509 -text -noout -in <server-cert.crt>
   Certificate:
   …
           Issuer: CN = Example CA
           Validity
               Not Before: Feb  2 20:27:29 2023 GMT
               Not After : Feb  2 20:27:29 2024 GMT
           Subject: C = US, O = Example Organization, CN = server.example.com
           Subject Public Key Info:
               Public Key Algorithm: id-ecPublicKey
                   Public-Key: (256 bit)
   …
           X509v3 extensions:
               X509v3 Key Usage: critical
                   Digital Signature, Key Encipherment, Key Agreement
               X509v3 Extended Key Usage:
                   TLS Web Server Authentication
               X509v3 Subject Alternative Name:
                   DNS:example.com, DNS:server.example.com, IP Address:192.168.0.1, IP
   …

手順

1. 次の例のように、クライアントシステムで秘密鍵を生成します。

   $ openssl genpkey -algorithm ec -pkeyopt ec_paramgen_curve:P-256 -out <client-private.key>

2. オプション: 次の例のように、選択したテキストエディターを使用して、CSR の作成を簡素化する設定ファイルを準備します。

   $ vim <example_client.cnf>
   [client-cert]
   keyUsage = critical, digitalSignature, keyEncipherment
   extendedKeyUsage = clientAuth
   subjectAltName = @alt_name
   
   [req]
   distinguished_name = dn
   prompt = no
   
   [dn]
   CN = <client.example.com>
   
   [clnt_alt_name]
   email= <client@example.com>

   extendedKeyUsage = clientAuth オプションは、証明書の使用を制限します。

3. 前に作成した秘密鍵を使用して CSR を作成します。

   $ openssl req -key <client-private.key> -config <example_client.cnf> -new -out <client-cert.csr>

   -config オプションを省略すると、req ユーティリティーは次のような追加情報の入力を求めます。

   You are about to be asked to enter information that will be incorporated
   into your certificate request.
   …
   Common Name (eg, your name or your server's hostname) []: <client.example.com>
   Email Address []: <client@example.com>

検証

1. 次の例のように、証明書の中で人間が判読できる部分が要件と一致することを確認します。

   $ openssl x509 -text -noout -in <client-cert.crt>
   Certificate:
   …
               X509v3 Extended Key Usage:
                   TLS Web Client Authentication
               X509v3 Subject Alternative Name:
                   email:client@example.com
   …

手順

1. オプション: 任意のテキストエディターを使用して、証明書に拡張を追加するための OpenSSL 設定ファイルを準備します。次に例を示します。

   $ vim <openssl.cnf>
   [server-cert]
   extendedKeyUsage = serverAuth
   
   [client-cert]
   extendedKeyUsage = clientAuth

   前の例は原則のみを示しており、openssl はすべての拡張を証明書に自動的に追加するわけではないことに注意してください。必要な拡張を CNF ファイルに追加するか、openssl コマンドのパラメーターに追加する必要があります。

2. x509 ユーティリティーを使用して、CSR に基づいて証明書を作成します。次に例を示します。

   $ openssl x509 -req -in <server-cert.csr> -CA <ca.crt> -CAkey <ca.key> -days 365 -extfile <openssl.cnf> -extensions <server-cert> -out <server-cert.crt>
   Signature ok
   subject=C = US, O = Example Organization, CN = server.example.com
   Getting CA Private Key

手順

1. CA の秘密鍵を生成します。たとえば、次のコマンドは、256 ビットの楕円曲線デジタル署名アルゴリズム (ECDSA) キーを作成します。

   $ certtool --generate-privkey --sec-param High --key-type=ecdsa --outfile <ca.key>

   キー生成プロセスの時間は、ホストのハードウェアとエントロピー、選択したアルゴリズム、およびキーの長さによって異なります。

2. 証明書のテンプレートファイルを作成します。

   1. 任意のテキストエディターでファイルを作成します。以下に例を示します。

      $ vi <ca.cfg>

   2. ファイルを編集して、必要な証明書の詳細を含めます。

      organization = "Example Inc."
      state = "Example"
      country = EX
      cn = "Example CA"
      serial = 007
      expiration_days = 365
      ca
      cert_signing_key
      crl_signing_key

3. 手順 1 で生成した秘密鍵を使用して署名された証明書を作成します。

   生成された <ca.crt> ファイルは、1 年間他の証明書に署名するために使用できる自己署名 CA 証明書です。<ca.crt> ファイルは公開鍵 (証明書) です。ロードされたファイル <ca.key> が秘密鍵です。このファイルは安全な場所に保管してください。

   $ certtool --generate-self-signed --load-privkey <ca.key> --template <ca.cfg> --outfile <ca.crt>

4. CA の秘密鍵に安全なアクセス許可を設定します。次に例を示します。

   # chown <root>:<root> <ca.key>
   # chmod 600 <ca.key>

検証

1. 自己署名 CA に関する基本情報を表示します。

   $ certtool --certificate-info --infile <ca.crt>
   Certificate:
   …
       	X509v3 extensions:
           	…
           	X509v3 Basic Constraints: critical
               	CA:TRUE
           	X509v3 Key Usage: critical
               	Certificate Sign, CRL Sign

2. 証明書署名要求 (CSR) を作成し、CA を使用して要求に署名します。CA は、CSR に基づいて証明書を正常に作成する必要があります。次に例を示します。

   1. CA の秘密鍵を生成します。

      $ certtool --generate-privkey --outfile <example-server.key>

   2. 任意のテキストエディターで新しい設定ファイルを開きます。以下に例を示します。

      $ vi <example-server.cfg>

   3. ファイルを編集して、必要な証明書の詳細を含めます。

      signing_key
      encryption_key
      key_agreement
      
      tls_www_server
      
      country = "US"
      organization = "Example Organization"
      cn = "server.example.com"
      
      dns_name = "example.com"
      dns_name = "server.example.com"
      ip_address = "192.168.0.1"
      ip_address = "::1"
      ip_address = "127.0.0.1"

   4. 以前に作成した秘密鍵を使用してリクエストを生成します

      $ certtool --generate-request --load-privkey <example-server.key> --template <example-server.cfg> --outfile <example-server.crq>

   5. 証明書を生成し、CA の秘密鍵で署名します。

      $ certtool --generate-certificate --load-request <example-server.crq> --load-ca-certificate <ca.crt> --load-ca-privkey <ca.key> --outfile <example-server.crt>

手順

1. 以下のようにサーバーシステムで秘密鍵を生成します。

   $ certtool --generate-privkey --sec-param High --outfile <example-server.key>

2. オプション: 次の例のように、選択したテキストエディターを使用して、CSR の作成を簡素化する設定ファイルを準備します。

   $ vim <example_server.cnf>
   signing_key
   encryption_key
   key_agreement
   
   tls_www_server
   
   country = "US"
   organization = "Example Organization"
   cn = "server.example.com"
   
   dns_name = "example.com"
   dns_name = "server.example.com"
   ip_address = "192.168.0.1"
   ip_address = "::1"
   ip_address = "127.0.0.1"

3. 前に作成した秘密鍵を使用して CSR を作成します。

   $ certtool --generate-request --template <example-server.cfg> --load-privkey <example-server.key> --outfile <example-server.crq>

   --template オプションを省略すると、certool ユーティリティーは次のような追加情報の入力を求めます。

   You are about to be asked to enter information that will be incorporated
   into your certificate request.
   What you are about to enter is what is called a Distinguished Name or a DN.
   There are quite a few fields but you can leave some blank
   For some fields there will be a default value,
   If you enter '.', the field will be left blank.
   -----
   Generating a PKCS #10 certificate request...
   Country name (2 chars): <US>
   State or province name: <Washington>
   Locality name: <Seattle>
   Organization name: <Example Organization>
   Organizational unit name:
   Common name: <server.example.com>

検証

1. 要求された証明書を CA から取得したら、次の例のように、証明書の中で人間が判読できる部分が要件と一致することを確認します。

   $ certtool --certificate-info --infile <example-server.crt>
   Certificate:
   …
           Issuer: CN = Example CA
           Validity
               Not Before: Feb  2 20:27:29 2023 GMT
               Not After : Feb  2 20:27:29 2024 GMT
           Subject: C = US, O = Example Organization, CN = server.example.com
           Subject Public Key Info:
               Public Key Algorithm: id-ecPublicKey
                   Public-Key: (256 bit)
   …
           X509v3 extensions:
               X509v3 Key Usage: critical
                   Digital Signature, Key Encipherment, Key Agreement
               X509v3 Extended Key Usage:
                   TLS Web Server Authentication
               X509v3 Subject Alternative Name:
                   DNS:example.com, DNS:server.example.com, IP Address:192.168.0.1, IP
   …

手順

1. 次の例のように、クライアントシステムで秘密鍵を生成します。

   $ certtool --generate-privkey --sec-param High --outfile <example-client.key>

2. オプション: 次の例のように、選択したテキストエディターを使用して、CSR の作成を簡素化する設定ファイルを準備します。

   $ vim <example_client.cnf>
   signing_key
   encryption_key
   
   tls_www_client
   
   cn = "client.example.com"
   email = "client@example.com"

3. 前に作成した秘密鍵を使用して CSR を作成します。

   $ certtool --generate-request --template <example-client.cfg> --load-privkey <example-client.key> --outfile <example-client.crq>

   --template オプションを省略すると、certtool ユーティリティーは次のような追加情報の入力を求めます。

   Generating a PKCS #10 certificate request...
   Country name (2 chars): <US>
   State or province name: <Washington>
   Locality name: <Seattle>
   Organization name: <Example Organization>
   Organizational unit name:
   Common name: <server.example.com>

検証

1. 次の例のように、証明書の中で人間が判読できる部分が要件と一致することを確認します。

   $ certtool --certificate-info --infile <example-client.crt>
   Certificate:
   …
               X509v3 Extended Key Usage:
                   TLS Web Client Authentication
               X509v3 Subject Alternative Name:
                   email:client@example.com
   …

手順

1. オプション: 任意のテキストエディターを使用して、次の例のように、証明書に拡張機能を追加するための GnuTLS 設定ファイルを準備します。

   $ vi <server-extensions.cfg>
   honor_crq_extensions
   ocsp_uri = "http://ocsp.example.com"

2. certtool ユーティリティーを使用して、CSR に基づいて証明書を作成します。次に例を示します。

   $ certtool --generate-certificate --load-request <example-server.crq> --load-ca-privkey <ca.key> --load-ca-certificate <ca.crt> --template <server-extensions.cfg> --outfile <example-server.crt>

手順

1. シンプルな PEM または DER ファイル形式の証明書を、システムで信頼されている CA のリストに追加し、証明書ファイルを /usr/share/pki/ca-trust-source/anchors/ または /etc/pki/ca-trust/source/anchors/ ディレクトリーにコピーします。次に例を示します。

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

2. update-ca-trust コマンドを使用して、システム全体のトラストストア設定を更新します。

   # update-ca-trust extract

手順

1. オプション: %certificate セクションを含むキックスタートファイルを作成します。証明書が tls-ca-bundle.pem という名前のファイルに保存されていることを確認します。

   %certificate --dir /etc/pki/dns/extracted/pem/ --filename tls-ca-bundle.pem
   -----BEGIN CERTIFICATE-----
   <Base64-encoded_certificate_content>
   -----END CERTIFICATE-----
   %end

2. 起動可能なインストールメディアを準備します。カスタムの CA バンドルが必要な場合は、キックスタートファイルを含めます。
3. インストールメディアを起動します。
4. ブートメニューウィンドウから必要なオプションを選択し、e キーを押してブートパラメーターを編集します。

5. eDNS カーネル引数を追加します。

   linux ($root)/vmlinuz-6.12.0-0.el10_0.x86_64 root=/dev/mapper/rhel-root ro crashkernel=2G-64G:256M,64G-:512M resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet emergency ip=dhcp rd.net.dns=dns+tls://<server_ip>#<dns_server_hostname> rd.net.dns-resolve-mode=exclusive rd.net.dns-backend=dnsconfd inst.ks=hd:/dev/sdb1/mykickstart.ks

6. 編集が完了したら、Ctrl+X を押して、指定したオプションを使用してインストールを開始します。

手順

1. 必要に応じて、最小インストールの起動 ISO イメージを使用する場合には、rhsm コマンドを使用してキックスタートファイルにインストールソースを設定します。

   # Register the system and use CDN as the installation source
   rhsm --organization=<org_id> --activation-key=<activation_key>

   注記

   インストールソースを作成して、HTTP、FTP、または NFS で利用できるようにすることもできます。詳細は、ネットワークベースのリポジトリーの準備 を参照してください。

2. オプション: %certificate セクションを含むキックスタートファイルを作成します。証明書が tls-ca-bundle.pem という名前のファイルに保存されていることを確認します。

   %certificate --dir /etc/pki/dns/extracted/pem/ --filename tls-ca-bundle.pem
   -----BEGIN CERTIFICATE-----
   <Base64-encoded_certificate_content>
   -----END CERTIFICATE-----
   %end

3. キックスタートファイルとカーネル引数を ISO に追加します。

   次のスクリプト例は、eDNS が有効なカスタムの起動可能な ISO を作成する方法を示しています。このプロセスを自動化するには、スクリプトファイルを作成する必要があります。

   !/bin/bash set -ex KERNELARGS="" # Enable network KERNELARGS+="ip=dhcp " # Set DoT DNS server KERNELARGS+="rd.net.dns=dns+tls://<server_ip><dns_server_hostname> "
   
   # Set to 'exclusive' to disable fallback to unencrypted DNS. Other values: 'backup', 'prefer'.
   KERNELARGS+="rd.net.dns-resolve-mode=exclusive "
   
   # Set the dnsconfd plugin for NetworkManager
   KERNELARGS+="rd.net.dns-backend=dnsconfd "
   
   # Remove any existing ISO to prevent conflicts with the new build
   rm -f <output_iso_filename>
   
   # Create a new bootable ISO with the Kickstart config file and kernel arguments
   mkksiso --ks <kickstart_file> --cmdline "$KERNELARGS" <input_iso_filename> <output_iso_filename>

4. スクリプトを実行します。

   # sh <script_filename>

5. カスタマイズした ISO ファイルを使用して RHEL をインストールします。

手順

1. /etc/NetworkManager/conf.d/global-dot.conf ファイルで NetworkManager を設定します。

   [main]
   dns=dnsconfd
   
   [global-dns]
   resolve-mode=exclusive
   
   [global-dns-domain-*]
   servers=dns+tls://<server_ip_1><dns_server_hostname_1>,dns+tls://<server_ip_2><dns_server_hostname_2>

2. オプション: アップストリームの DoT サーバーを検証するためにカスタム CA バンドルを使用するには、PEM 形式のファイルを /etc/pki/dns/extracted/pem/tls-ca-bundle.pem ファイルにコピーします。

   注記

   /etc/pki/dns/extracted/pem で証明書を追加または削除したら、変更を適用するために dnsconfd サービスを再起動してください。

3. dnsconfd サービスを有効にします。

   # systemctl enable --now dnsconfd

4. NetworkManager をリロードします。

   # systemctl reload NetworkManager

5. dnsconfd とその設定が含まれるように、すべてのインストール済みカーネルの initramfs を再生成します。

   # for kernel in `rpm -q kernel --qf '%{VERSION}-%{RELEASE}.%{ARCH}\n'`; do
       dracut -f --kver="$kernel"
   done

6. カーネル引数を、現在のカーネルバージョンと新しくインストールされたカーネルバージョンに設定します。

   # grubby --args="rd.net.dns=dns+tls://<server_ip>#<dns_server_hostname> rd.net.dns-resolve-mode=exclusive rd.net.dns-backend=dnsconfd" --update-kernel=ALL

   • IBM Z の場合は、ブートメニューを更新します。

     # zipl

手順

1. Libreswan がまだインストールされていない場合は、次の手順を実行します。

   1. libreswan パッケージをインストールします。

      # dnf install libreswan

   2. ネットワークセキュリティーサービス (NSS) データベースを初期化します。

      # ipsec initnss

      このコマンドにより、/var/lib/ipsec/nss/ ディレクトリーにデータベースが作成されます。

   3. ipsec サービスを有効にして起動します。

      # systemctl enable --now ipsec

   4. ファイアウォールで IPsec ポートとプロトコルを開きます。

      # firewall-cmd --permanent --add-service="ipsec"
      # firewall-cmd --reload

2. RSA 鍵ペアを作成します。

   # ipsec newhostkey

   ipsec ユーティリティーにより、鍵ペアが NSS データベースに保存されます。

3. ピアを指定します。IPsec トンネルでは、一方のホストを left に、もう一方のホストを right に指定する必要があります。これは任意に選択できます。一般的には、ローカルホストを left、リモートホストを right と呼びます。

4. left と right 両方のピアの Certificate Key Attribute ID (CKAID) を表示します。

   # ipsec showhostkey --list
   < 1> RSA keyid: <key_id> ckaid: <ckaid>

   以降のステップで、両方のピアの CKAID が必要になります。

5. 公開鍵を表示します。

   1. left ピアで次のように入力します。

      # ipsec showhostkey --left --ckaid <ckaid_of_left_peer>
      	# rsakey AwEAAdKCx
      	leftrsasigkey=0sAwEAAdKCxpc9db48cehzQiQD...

   2. right ピアで次のように入力します。

      # ipsec showhostkey --right --ckaid <ckaid_of_right_peer>
      	# rsakey AwEAAcNWC
      	rightrsasigkey=0sAwEAAcNWCzZO+PR1j8WbO8X...

   これらのコマンドにより、設定ファイルで使用する必要がある対応するパラメーターとともに、公開鍵が表示されます。

6. /etc/ipsec.d/ ディレクトリーに接続用の .conf ファイルを作成します。たとえば、次の設定で /etc/ipsec.d/host-to-host.conf ファイルを作成します。

   conn <connection_name>
       # General setup and authentication type
       auto=start
       authby=rsasig
   
       # Peer A
       left=<ip_address_or_fqdn_of_left_peer>
       leftid=@peer_a
       leftrsasigkey=<public_key_of_left_peer>
   
       # Peer B
       right=<ip_address_or_fqdn_of_right_peer>
       rightid=@peer_b
       rightrsasigkey=<public_key_of_right_peer>

   注記

   両方のホストで同じ設定ファイルを使用できます。Libreswan は内部情報を使用して、自身が left ホストで動作しているか、right ホストで動作しているかを識別します。ただし、left* パラメーターのすべての値が一方のピアに属し、right* パラメーターの値がもう一方のピアに属することが重要です。

   この例で指定されている設定は次のとおりです。

   conn <connection_name>

   接続名を定義します。名前は任意であり、Libreswan はこれを使用して接続を識別します。この接続のパラメーターは、少なくとも 1 つのスペースまたはタブでインデントする必要があります。

   auto=<type>

   接続の開始方法を制御します。値を start に設定すると、Libreswan はサービスの起動時に自動的に接続をアクティブ化します。

   authby=rsasig

   この接続に対して RSA 署名認証を有効にします。

   left=<ip_address_or_fqdn_of_left_peer> および right=<ip_address_or_fqdn_of_right_peer>

   ピアの IP アドレスまたは DNS 名を定義します。

   leftid=<id> および rightid=<id>

   Internet Key Exchange (IKE) ネゴシエーションプロセス中に各ピアを識別する方法を定義します。これには、完全修飾ドメイン名 (FQDN)、IP アドレス、またはリテラル文字列を使用できます。後者の場合、文字列の前に @ 記号を付けます。

   leftrsasigkey=<public_key> および rightrsasigkey=<public_key>

   ピアの公開鍵を指定します。前のステップで ipsec showhostkey コマンドによって表示された値を使用します。

7. ipsec サービスを再起動します。

   # systemctl restart ipsec

   設定ファイルで auto=start を使用すると、接続が自動的にアクティブになります。他の方法の場合、接続をアクティブ化するために追加の手順が必要です。詳細は、システム上の ipsec.conf(5) man ページを参照してください。

手順

1. Libreswan がまだインストールされていない場合は、次の手順を実行します。

   1. libreswan パッケージをインストールします。

      # dnf install libreswan

   2. ネットワークセキュリティーサービス (NSS) データベースを初期化します。

      # ipsec initnss

      このコマンドにより、/var/lib/ipsec/nss/ ディレクトリーにデータベースが作成されます。

   3. ipsec サービスを有効にして起動します。

      # systemctl enable --now ipsec

   4. ファイアウォールで IPsec ポートとプロトコルを開きます。

      # firewall-cmd --permanent --add-service="ipsec"
      # firewall-cmd --reload

2. RSA 鍵ペアを作成します。

   # ipsec newhostkey

   ipsec ユーティリティーにより、鍵ペアが NSS データベースに保存されます。

3. ピアを指定します。IPsec トンネルでは、一方のホストを left に、もう一方のホストを right に指定する必要があります。これは任意に選択できます。一般的には、ローカルホストを left、リモートホストを right と呼びます。

4. left と right 両方のピアの Certificate Key Attribute ID (CKAID) を表示します。

   # ipsec showhostkey --list
   < 1> RSA keyid: <key_id> ckaid: <ckaid>

   以降のステップで、両方のピアの CKAID が必要になります。

5. 公開鍵を表示します。

   1. left ピアで次のように入力します。

      # ipsec showhostkey --left --ckaid <ckaid_of_left_peer>
      	# rsakey AwEAAdKCx
      	leftrsasigkey=0sAwEAAdKCxpc9db48cehzQiQD...

   2. right ピアで次のように入力します。

      # ipsec showhostkey --right --ckaid <ckaid_of_right_peer>
      	# rsakey AwEAAcNWC
      	rightrsasigkey=0sAwEAAcNWCzZO+PR1j8WbO8X...

   これらのコマンドにより、設定ファイルで使用する必要がある対応するパラメーターとともに、公開鍵が表示されます。

6. /etc/ipsec.d/ ディレクトリーに接続用の .conf ファイルを作成します。たとえば、次の設定で /etc/ipsec.d/site-to-site.conf ファイルを作成します。

   conn <connection_name>
       # General setup and authentication type
       auto=start
       authby=rsasig
   
       # Site A
       left=<ip_address_or_fqdn_of_left_peer>
       leftid=@site_a
       leftrsasigkey=<public_key_of_left_peer>
       leftsubnet=192.0.2.0/24
   
       # Site B
       right=<ip_address_or_fqdn_of_right_peer>
       rightid=@site_b
       rightrsasigkey=<public_key_of_right_peer>
       rightsubnet={198.51.100.0/24, 203.0.113.0/24}

   注記

   両方のゲートウェイデバイスで同じ設定ファイルを使用できます。Libreswan は内部情報を使用して、自身が left ホストで動作しているか、right ホストで動作しているかを識別します。ただし、left* パラメーターのすべての値が一方のピアに属し、right* パラメーターの値がもう一方のピアに属することが重要です。

   この例で指定されている設定は次のとおりです。

   conn <connection_name>

   接続名を定義します。名前は任意であり、Libreswan はこれを使用して接続を識別します。この接続のパラメーターは、少なくとも 1 つのスペースまたはタブでインデントする必要があります。

   auto=<type>

   接続の開始方法を制御します。値を start に設定すると、Libreswan はサービスの起動時に自動的に接続をアクティブ化します。

   authby=rsasig

   この接続に対して RSA 署名認証を有効にします。

   left=<ip_address_or_fqdn_of_left_peer> および right=<ip_address_or_fqdn_of_right_peer>

   ピアの IP アドレスまたは DNS 名を定義します。

   leftid=<id> および rightid=<id>

   Internet Key Exchange (IKE) ネゴシエーションプロセス中に各ピアを識別する方法を定義します。これには、完全修飾ドメイン名 (FQDN)、IP アドレス、またはリテラル文字列を使用できます。後者の場合、文字列の前に @ 記号を付けます。

   leftrsasigkey=<public_key> および rightrsasigkey=<public_key>

   ピアの公開鍵を指定します。前のステップで ipsec showhostkey コマンドによって表示された値を使用します。

   leftsubnet=<subnet> および rightsubnet=<subnet>

   トンネルを介して接続されるサブネットを Classless Inter-Domain Routing (CIDR) 形式で定義します。片側で複数のサブネットをトンネリングする場合は、それらを中括弧で囲み、コンマで区切って指定します。

7. パケット転送を有効にします。

   # echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/95-IPv4-forwarding.conf
   # sysctl -p /etc/sysctl.d/95-IPv4-forwarding.conf

8. ipsec サービスを再起動します。

   # systemctl restart ipsec

   設定ファイルで auto=start を使用すると、接続が自動的にアクティブになります。他の方法の場合、接続をアクティブ化するために追加の手順が必要です。詳細は、システム上の ipsec.conf(5) man ページを参照してください。

検証

1. IPsec ステータスを表示します。

   # ipsec status

   接続が正常に確立されていれば、出力に次の行が含まれています。

   • Internet Key Exchange バージョン 2 (IKEv2) ネゴシエーションのフェーズ 1 が正常に完了しています。

     000 #2: "<connection_name>":500 STATE_V2_ESTABLISHED_IKE_SA (established IKE SA); REKEY in 27935s; REPLACE in 28610s; newest; idle;

     これで、セキュリティーアソシエーション (SA) が、実際のデータ暗号化トンネル (子 SA またはフェーズ 2 SA と呼ばれる) をネゴシエートする準備が整いました。

   • 子 SA が確立されています。

     000 #3: "<connection_name>":500 STATE_V2_ESTABLISHED_CHILD_SA (established Child SA); REKEY in 27671s; REPLACE in 28610s; IKE SA #2; idle;

     これは、データトラフィックが通過する実際のトンネルです。

2. ローカルサブネット内のクライアントから、リモートサブネット内のクライアントに ping を実行します。

手順

1. Libreswan がまだインストールされていない場合は、次の手順を実行します。

   1. libreswan パッケージをインストールします。

      # dnf install libreswan

   2. ネットワークセキュリティーサービス (NSS) データベースを初期化します。

      # ipsec initnss

      このコマンドにより、/var/lib/ipsec/nss/ ディレクトリーにデータベースが作成されます。

   3. ipsec サービスを有効にして起動します。

      # systemctl enable --now ipsec

   4. ファイアウォールで IPsec ポートとプロトコルを開きます。

      # firewall-cmd --permanent --add-service="ipsec"
      # firewall-cmd --reload

2. PKCS #12 ファイルを NSS データベースにインポートします。

   # ipsec import <file>.p12
   Enter password for PKCS12 file: <password>
   pk12util: PKCS12 IMPORT SUCCESSFUL
   correcting trust bits for Example-CA

3. サーバーと CA 証明書のニックネームを表示します。

   # certutil -L -d /var/lib/ipsec/nss/
   Certificate Nickname     Trust Attributes
                            SSL,S/MIME,JAR/XPI
   
   server1                  u,u,u
   Example-CA               CT,,
   ...

   この情報は設定ファイルに必要です。

4. /etc/ipsec.d/ ディレクトリーに接続用の .conf ファイルを作成します。たとえば、次の設定で /etc/ipsec.d/mesh.conf ファイルを作成します。

   1. CRL チェックを有効にするために、config setup セクションを追加します。

      config setup
          crl-strict=yes
          crlcheckinterval=1h

      この例で指定されている設定は次のとおりです。

      crl-strict=yes

      CRL チェックを有効にします。NSS データベース内で CRL が利用できない場合、認証中のピアが拒否されます。

      crlcheckinterval=1h

      指定期間後に、サーバーの証明書に指定された URL から CRL を再取得します。

   2. メッシュ内のメンバー間のトラフィックを強制的に制御するセクションを追加します。

      conn <connection_name>
          # General setup and authentication type
          auto=ondemand
          authby=rsasig
      
          # Local settings settings
          left=%defaultroute
          leftid=%fromcert
          leftcert="<server_certificate_nickname>"
          leftrsasigkey=%cert
          leftsendcert=always
          failureshunt=drop
          type=transport
      
          # Settings related to other peers in the mesh
          right=%opportunisticgroup
          rightid=%fromcert

      この例で指定されている設定は次のとおりです。

      left=%defaultroute

      ipsec サービスの起動時に、デフォルトルートインターフェイスの IP アドレスを動的に設定します。left パラメーターは、ホストの IP アドレスまたは FQDN に設定することもできます。

      leftid=%fromcert および rightid=%fromcert

      証明書の識別名 (DN) フィールドからアイデンティティーを取得するように Libreswan を設定します。

      leftcert="<server_certificate_nickname>"

      NSS データベースで使用されるサーバーの証明書のニックネームを設定します。

      leftrsasigkey=%cert

      証明書に埋め込まれた RSA 公開鍵を使用するように Libreswan を設定します。

      leftsendcert=always

      ピアが CA 証明書に照らして証明書を検証できるように、ピアに証明書を常に送信するように指示します。

      failureshunt=drop

      暗号化を強制し、IPsec ネゴシエーションが失敗した場合はトラフィックを破棄します。これはメッシュのセキュリティーにとって重要です。

      right=%opportunisticgroup

      ポリシーファイルで定義されているリモートピアの動的グループに接続を適用することを指定します。これにより、Libreswan は、そのグループにリストされている各 IP またはサブネットに対して、必要に応じて IPsec トンネルをインスタンス化できるようになります。

   例で使用されているすべてのパラメーターの詳細は、システム上の ipsec.conf(5) man ページを参照してください。

5. Classless Inter-Domain Routing (CIDR) 形式でピアまたはサブネットを指定する /etc/ipsec.d/policies/server-mesh ポリシーファイルを作成します。

   192.0.2.0/24
   198.51.100.0/24

   これらの設定により、これらのサブネット内のホスト間トラフィックが ipsec サービスによって暗号化されます。ホストが IPsec メッシュのメンバーとして設定されていない場合、このホストとメッシュメンバー間の通信が失敗します。

6. ipsec サービスを再起動します。

   # systemctl restart ipsec

7. ポリシーファイルで指定したサブネット内のすべてのホストでこの手順を繰り返します。

検証

1. メッシュ内のホストにトラフィックを送信してトンネルを確立します。たとえば、ホストに ping を実行します。

   # ping -c3 <peer_in_mesh>

2. IPsec ステータスを表示します。

   # ipsec status

   接続が正常に確立されていれば、ピアに関する次の行が出力に含まれています。

   • Internet Key Exchange バージョン 2 (IKEv2) ネゴシエーションのフェーズ 1 が正常に完了しています。

     #1: "<connection_name>#192.0.2.0/24"[1] ...192.0.2.2:500 ESTABLISHED_IKE_SA (established IKE SA); REKEY in 12822s; REPLACE in 13875s; newest; idle;

     これで、セキュリティーアソシエーション (SA) が、実際のデータ暗号化トンネル (子 SA またはフェーズ 2 SA と呼ばれる) をネゴシエートする準備が整いました。

   • 子 SA が確立されています。

     #2: "<connection_name>#192.0.2.0/24"[1] ...192.0.2.2:500 ESTABLISHED_CHILD_SA (established Child SA); REKEY in 13071s; REPLACE in 13875s; newest; eroute owner; IKE SA #1; idle;

     これは、データトラフィックが通過する実際のトンネルです。

3. サービスが CRL をロードし、エントリーを NSS データベースに追加したかどうかを確認します。

   # ipsec auto --listcrls
   000
   000 List of CRLs:
   000
   000 issuer: CN=Example-CA
   000 revoked certs: 1
   000 updates: this Tue Jul 15 10:22:36 2025
   000          next Sun Jan 11 10:22:36 2026
   000
   000 List of CRL fetch requests:
   000
   000 Jul 15 15:13:56 2025, trials: 1
   000        issuer:  'CN=Example-CA'
   000        distPts: 'https://ca.example.com/crl.pem'

手順

1. Libreswan NSS データベースのパスワード保護を有効にします。

   # certutil -W -d /var/lib/ipsec/nss/

2. 現在のパスワードを入力します。

   Enter Password or Pin for "NSS Certificate DB": <password>

   現在データベースがパスワードで保護されていない場合は、Enter を押します。

3. 新しいパスワードを入力します。

   Enter new password: <new_password>
   Re-enter password: <new_password>

4. データベースのロックを解除するために、ipsec サービスに /etc/ipsec.d/nsspassword ファイルが必要です。次の内容のファイルを作成します。

   • ホストが FIPS モードで実行されていない場合:

     NSS Certificate DB:<password>

   • ホストが FIPS モードで実行されている場合:

     NSS FIPS 140-2 Certificate DB:<password>

5. /etc/ipsec.d/nsspassword ファイルにセキュアな権限を設定します。

   # chmod 600 /etc/ipsec.d/nsspassword
   # chown root:root /etc/ipsec.d/nsspassword

6. ipsec サービスを再起動します。

   # systemctl restart ipsec

検証

1. ipsec サービスが実行されていることを確認します。

   # systemctl is-active ipsec

   コマンドで active が返された場合、サービスはパスワードファイルを使用して NSS データベースのロックを正常に解除します。

2. NSS データベースでパスワードを必要とするアクションを実行します。たとえば、秘密鍵を表示します。

   # certutil -K -d /var/lib/ipsec/nss/
   certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key and Certificate Services"
   Enter Password or Pin for "NSS Certificate DB":

   コマンドによってパスワードが要求されることを確認します。

手順

1. /etc/ipsec.conf ファイルを編集し、config setup セクションで次の変更を加えます。

   1. TCP ポートをリッスンするように Libreswan を設定します。

      listen-tcp=yes

   2. デフォルトでは、Libreswan はポート 4500 をリッスンします。別のポートを使用する場合は、次のように入力します。

      tcp-remoteport=<port_number>

   3. UDP が利用できない場合に TCP をフォールバックオプションとして使用するか、TCP を永続的に使用するかを決定します。

      • フォールバックオプションとして使用するには、次のように入力します。

        enable-tcp=fallback
        retransmit-timeout=5s

        デフォルトでは、Libreswan は UDP を使用した接続の試行が失敗した後、TCP 経由の接続を再試行するまで 60 秒間待機します。retransmit-timeout 値を下げると遅延が短縮され、フォールバックプロトコルをより迅速に開始できるようになります。

      • UDP の代わりに永続的に使用するには、次のように入力します。

        enable-tcp=yes

2. ipsec サービスを再起動します。

   # systemctl restart ipsec

3. デフォルトの 4500 以外の TCP ポートを設定した場合は、ファイアウォールでそのポートを開きます。

   # firewall-cmd --permanent --add-port=<tcp_port>/tcp
   # firewall-cmd --reload

4. このゲートウェイを使用する各ピアでこの手順を繰り返します。

手順

1. RHEL システム全体の暗号化ポリシーによって設定されたデフォルトをオーバーライドするには、接続設定に keyexchange、esp、および ike パラメーターを追加し、必要な値に設定します。以下に例を示します。

   conn <connection_name>
       ikev2=no
       ike=aes-sha2,aes-sha1;modp2048
       esp=aes-sha2,aes-sha1
       ...

2. ipsec サービスを再起動します。

   # systemctl restart ipsec

手順

1. 使用するルーティングテーブルを決定します。次の手順ではテーブル 75 を使用します。デフォルトでは、RHEL はテーブル 1 - 254 を使用しないため、それらのテーブルのうちどれでも使用できます。

2. VPN ルートを専用のルーティングテーブルに割り当てるように VPN 接続プロファイルを設定します。

   # nmcli connection modify <vpn_connection_profile> ipv4.route-table 75 ipv6.route-table 75

3. 上記のコマンドで使用したテーブルに低い優先度値を設定します。

   # nmcli connection modify <vpn_connection_profile> ipv4.routing-rules "priority 32345 from all table 75" ipv6.routing-rules "priority 32345 from all table 75"

   優先度の値は 1 - 32766 の範囲で指定できます。値が低いほど、優先度が高くなります。

4. VPN 接続を再接続します。

   # nmcli connection down <vpn_connection_profile>
   # nmcli connection up <vpn_connection_profile>

検証

1. テーブル 75 の IPv4 ルートを表示します。

   # ip route show table 75
   ...
   192.0.2.0/24 via 192.0.2.254 dev vpn_device proto static metric 50
   default dev vpn_device proto static scope link metric 50

   この出力から、リモートネットワークへのルートとデフォルトゲートウェイの両方がルーティングテーブル 75 に割り当てられており、すべてのトラフィックがトンネルを介してルーティングされることを確認できます。VPN 接続プロファイルで ipv4.never-default true を設定すると、デフォルトルートが作成されず、この出力には表示されません。

2. テーブル 75 の IPv6 ルートを表示します。

   # ip -6 route show table 75
   ...
   2001:db8:1::/64 dev vpn_device proto kernel metric 50 pref medium
   default dev vpn_device proto static metric 50 pref medium

   この出力から、リモートネットワークへのルートとデフォルトゲートウェイの両方がルーティングテーブル 75 に割り当てられており、すべてのトラフィックがトンネルを介してルーティングされることを確認できます。VPN 接続プロファイルで ipv6.never-default true を設定すると、デフォルトルートが作成されず、この出力には表示されません。

手順

1. 次に、ファイアウォールルールを追加します。

   • TCP 接続を制限し、111 ポート経由の 192.168.0.0/24 ホストからのパッケージだけを受け入れます。

     # firewall-cmd --add-rich-rule='rule family="ipv4" port port="111" protocol="tcp" source address="192.168.0.0/24" invert="True" drop'

   • TCP 接続を制限し、111 ポート経由のローカルホストからのパッケージだけを受け入れます。

     # firewall-cmd --add-rich-rule='rule family="ipv4" port port="111" protocol="tcp" source address="127.0.0.1" accept'

   • UDP 接続を制限し、111 ポート経由の 192.168.0.0/24 ホストからのパッケージだけを受け入れます。

     # firewall-cmd --permanent --add-rich-rule='rule family="ipv4" port port="111" protocol="udp" source address="192.168.0.0/24" invert="True" drop'

     ファイアウォール設定を永続化するには、ファイアウォールルールを追加するときに --permanent オプションを使用します。

2. ファイアウォールをリロードして、新しいルールを適用します。

   # firewall-cmd --reload

手順

1. 以下のように、サーバーにファイアウォールルールを追加します。

   • 192.168.0.0/24 ホストからの mountd 接続を許可します。

     # firewall-cmd --add-rich-rule 'rule family="ipv4" service name="mountd" source address="192.168.0.0/24" invert="True" drop'

   • ローカルホストからの mountd 接続を受け入れます。

     # firewall-cmd --permanent --add-rich-rule 'rule family="ipv4" source address="127.0.0.1" service name="mountd" accept'

     ファイアウォール設定を永続化するには、ファイアウォールルールを追加するときに --permanent オプションを使用します。

2. ファイアウォールをリロードして、新しいルールを適用します。

   # firewall-cmd --reload

手順

1. PostgreSQL をインストールします。

   # yum install postgresql-server

2. 次のいずれかのオプションを使用して、データベースストレージ領域を初期化します。

   1. initdb ユーティリティーの使用:

      $ initdb -D /home/postgresql/db1/

      -D オプションを指定した initdb コマンドを実行すると、指定したディレクトリーがまだ存在しない場合は作成します (例: /home/postgresql/db1/)。このディレクトリーには、データベースに保存されているすべてのデータと、クライアント認証設定ファイルが含まれています。

   2. postgresql-setup スクリプトの使用:

      $ postgresql-setup --initdb

      デフォルトでは、スクリプトは /var/lib/pgsql/data/ ディレクトリーを使用します。このスクリプトは、基本的なデータベースクラスター管理でシステム管理者を支援します。

3. 認証されたローカルユーザーが自分のユーザー名でデータベースにアクセスできるようにするには、pg_hba.conf ファイルの以下の行を変更します。

   local   all             all                                     trust

   これは、データベースユーザーを作成し、ローカルユーザーを作成しないレイヤー型アプリケーションを使用する場合に、問題となることがあります。システム上のすべてのユーザー名を明示的に制御しない場合は、pg_hba.conf ファイルから local の行を削除してください。

4. データベースを再起動して、変更を適用します。

   # systemctl restart postgresql

   前のコマンドはデータベースを更新し、設定ファイルの構文も検証します。