手順

1. 現行セッションで sshd デーモンを開始し、ブート時に自動的に起動するように設定します。

   # systemctl start sshd
   # systemctl enable sshd

2. デフォルトの0.0.0.0 (IPv4) または :: とは異なるアドレスを指定するには、以下を行います。(IPv6) /etc/ssh/sshd_config 設定ファイルの ListenAddress ディレクティブ、および低速な動的ネットワーク設定を使用するには、network-online.target ターゲットユニットの依存関係をsshd.service ユニットファイルに追加します。これを行うには、以下の内容で /etc/systemd/system/sshd.service.d/local.conf ファイルを作成します。

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

3. /etc/ssh/sshd_config 設定ファイルの OpenSSH サーバーの設定がシナリオの要件を満たしているかどうかを確認します。

4. 必要に応じて、/etc/issue ファイルを編集して、クライアント認証を行う前に OpenSSH サーバーに表示される welcome メッセージを変更します。以下に例を示します。

   Welcome to ssh-server.example.com
   Warning: By accessing this server, you agree to the referenced terms and conditions.

   Banner オプションが /etc/ssh/sshd_config でコメントアウトされておらず、その値に /etc/issue が含まれていることを確認します。

   # less /etc/ssh/sshd_config | grep Banner
   Banner /etc/issue

   ログインに成功すると表示されるメッセージを変更するには、サーバーの /etc/motd ファイルを編集する必要があります。詳細は、pam_motd の man ページを参照してください。

5. systemd 設定を再読み込みし、sshd を再起動して変更を適用します。

   # systemctl daemon-reload
   # systemctl restart sshd

検証

1. sshd デーモンが実行していることを確認します。

   # systemctl status sshd
   ● sshd.service - OpenSSH server daemon
      Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
      Active: active (running) since Mon 2019-11-18 14:59:58 CET; 6min ago
        Docs: man:sshd(8)
              man:sshd_config(5)
    Main PID: 1149 (sshd)
       Tasks: 1 (limit: 11491)
      Memory: 1.9M
      CGroup: /system.slice/sshd.service
              └─1149 /usr/sbin/sshd -D -oCiphers=aes128-ctr,aes256-ctr,aes128-cbc,aes256-cbc -oMACs=hmac-sha2-256,>
   
   Nov 18 14:59:58 ssh-server-example.com systemd[1]: Starting OpenSSH server daemon...
   Nov 18 14:59:58 ssh-server-example.com sshd[1149]: Server listening on 0.0.0.0 port 22.
   Nov 18 14:59:58 ssh-server-example.com sshd[1149]: Server listening on :: port 22.
   Nov 18 14:59:58 ssh-server-example.com systemd[1]: Started OpenSSH server daemon.

2. SSH クライアントを使用して SSH サーバーに接続します。

   # ssh user@ssh-server-example.com
   ECDSA key fingerprint is SHA256:dXbaS0RG/UzlTTku8GtXSz0S1++lPegSy31v3L/FAEc.
   Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
   Warning: Permanently added 'ssh-server-example.com' (ECDSA) to the list of known hosts.
   
   user@ssh-server-example.com's password:

手順

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

   # vi /etc/ssh/sshd_config

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

   PasswordAuthentication no

   新しいデフォルトインストール以外のシステムで PubkeyAuthentication no が設定されていないことと、KbdInteractiveAuthentication ディレクティブが no に設定されていることを確認します。リモートで接続している場合は、コンソールもしくは帯域外アクセスを使用せず、パスワード認証を無効にする前に、鍵ベースのログインプロセスをテストします。

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

   # setsebool -P use_nfs_home_dirs 1

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

   # systemctl reload sshd

手順

1. SSH プロトコルのバージョン 2 用の ECDSA 鍵ペアを生成するには、次のコマンドを実行します。

   $ ssh-keygen -t ecdsa
   Generating public/private ecdsa key pair.
   Enter file in which to save the key (/home/joesec/.ssh/id_ecdsa):
   Enter passphrase (empty for no passphrase):
   Enter same passphrase again:
   Your identification has been saved in /home/joesec/.ssh/id_ecdsa.
   Your public key has been saved in /home/joesec/.ssh/id_ecdsa.pub.
   The key fingerprint is:
   SHA256:Q/x+qms4j7PCQ0qFd09iZEFHA+SqwBKRNaU72oZfaCI joesec@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 コマンドまたは Ed25519 鍵ペアに -t rsa オプションを指定して RSA 鍵ペアを生成するには、ssh-keygen -t ed25519 コマンドを実行します。

2. 公開鍵をリモートマシンにコピーするには、次のコマンドを実行します。

   $ ssh-copy-id joesec@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
   joesec@ssh-server-example.com's password:
   ...
   Number of key(s) added: 1
   
   Now try logging into the machine, with: "ssh 'joesec@ssh-server-example.com'" and check to make sure that only the key(s) you wanted were added.

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

検証

1. パスワードなしで OpenSSH サーバーにログインします。

   $ ssh joesec@ssh-server-example.com
   Welcome message.
   ...
   Last login: Mon Nov 18 18:28:42 2019 from ::1

手順

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

   $ ssh-keygen -D pkcs11: > keys.pub
   $ ssh-keygen -D pkcs11:
   ssh-rsa AAAAB3NzaC1yc2E...KKZMzcQZzx pkcs11:id=%02;object=SIGN%20pubkey;token=SSH%20key;manufacturer=piv_II?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so
   ecdsa-sha2-nistp256 AAA...J0hkYnnsM= pkcs11:id=%01;object=PIV%20AUTH%20pubkey;token=SSH%20key;manufacturer=piv_II?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so

2. リモートサーバー (example.com) でスマートカードを使用した認証を有効にするには、公開鍵をリモートサーバーに転送します。前の手順で作成された keys.pub で ssh-copy-id コマンドを使用します。

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

3. 手順 1 の ssh-keygen -D コマンドの出力にある ECDSA 鍵を使用して example.com に接続するには、鍵を一意に参照する URI のサブセットのみを使用できます。以下に例を示します。

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

4. ~/.ssh/config ファイルで同じ URI 文字列を使用して、設定を永続化できます。

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

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

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

手順

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

   Host jump-server1
     HostName jump1.example.com

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

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

   Host remote-server
     HostName remote1.example.com
     ProxyJump jump-server1

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

   $ ssh remote-server

   このコマンドは、設定手順 1 および 2 を省略したときの ssh -J jump-server1 remote-server コマンドと同じです。

手順

1. オプション: キーを使用してリモートホストに対して認証できることを確認します。

   1. SSH を使用してリモートホストに接続します。

      $ ssh example.user1@198.51.100.1 hostname

   2. 秘密鍵へのアクセス権を付与する鍵の作成時に指定したパスフレーズを入力します。

      $ ssh example.user1@198.51.100.1 hostname
       host.example.com

2. ssh-agent を起動します。

   $ eval $(ssh-agent)
   Agent pid 20062

3. ssh-agent にキーを追加します。

   $ ssh-add ~/.ssh/id_rsa
   Enter passphrase for ~/.ssh/id_rsa:
   Identity added: ~/.ssh/id_rsa (example.user0@198.51.100.12)

手順

1. sshd システムロールの Playbook の例をコピーします。

   # cp /usr/share/doc/rhel-system-roles/sshd/example-root-login-playbook.yml path/custom-playbook.yml

2. 以下の例のように、テキストエディターでコピーした Playbook を開きます。

   # vim path/custom-playbook.yml
   
   ---
   - hosts: all
     tasks:
     - name: Configure sshd to prevent root and password login except from particular subnet
       include_role:
         name: rhel-system-roles.sshd
       vars:
         sshd:
           # root login and password login is enabled only from a particular subnet
           PermitRootLogin: no
           PasswordAuthentication: no
           Match:
           - Condition: "Address 192.0.2.0/24"
             PermitRootLogin: yes
             PasswordAuthentication: yes

   Playbook は、以下のように、マネージドノードを SSH サーバーとして設定します。

   • パスワードと root ユーザーのログインが無効である
   • 192.0.2.0/24 のサブネットからのパスワードおよび root ユーザーのログインのみが有効である

   設定に合わせて変数を変更できます。詳細は、sshd システムロール変数 を参照してください。

3. オプション: Playbook の構文を確認します。

   # ansible-playbook --syntax-check path/custom-playbook.yml

4. インベントリーファイルで Playbook を実行します。

   # ansible-playbook -i inventory_file path/custom-playbook.yml
   
   ...
   
   PLAY RECAP
   **************************************************
   
   localhost : ok=12 changed=2 unreachable=0 failed=0
   skipped=10 rescued=0 ignored=0

検証

1. SSH サーバーにログインします。

   $ ssh user1@10.1.1.1

   詳細は以下のようになります。

   • user1 は、SSH サーバーのユーザーです。
   • 10.1.1.1 は、SSH サーバーの IP アドレスです。

2. SSH サーバーの sshd_config ファイルの内容を確認します。

   $ cat /etc/ssh/sshd_config.d/00-ansible_system_role.conf
   #
   # Ansible managed
   #
   PasswordAuthentication no
   PermitRootLogin no
   Match Address 192.0.2.0/24
     PasswordAuthentication yes
     PermitRootLogin yes

3. 192.0.2.0/24 サブネットから root としてサーバーに接続できることを確認します。

   1. IP アドレスを確認します。

      $ hostname -I
      192.0.2.1

      IP アドレスが 192.0.2.1 - 192.0.2.254 範囲にある場合は、サーバーに接続できます。

   2. root でサーバーに接続します。

      $ ssh root@10.1.1.1

手順

1. 以下の内容を含む新しい playbook.yml ファイルを作成します。

   ---
   - hosts: all
     tasks:
     - name: "Configure ssh clients"
       include_role:
         name: rhel-system-roles.ssh
       vars:
         ssh_user: root
         ssh:
           Compression: true
           GSSAPIAuthentication: no
           ControlMaster: auto
           ControlPath: ~/.ssh/.cm%C
           Host:
             - Condition: example
               Hostname: example.com
               User: user1
         ssh_ForwardX11: no

   この Playbook は、以下の設定を使用して、マネージドノードで root ユーザーの SSH クライアント設定を行います。

   • 圧縮が有効になっている。
   • ControlMaster multiplexing が auto に設定されている。
   • example.com ホストに接続するための example エイリアスが user1 である。
   • ホストエイリアスの example が作成されている。(これはユーザー名が user1 の example.com ホストへの接続を表します。)
   • X11 転送が無効化されている。

   必要に応じて、これらの変数は設定に合わせて変更できます。詳細は、ssh システムロール変数 を参照してください。

2. オプション: Playbook の構文を確認します。

   # ansible-playbook --syntax-check path/custom-playbook.yml

3. インベントリーファイルで Playbook を実行します。

   # ansible-playbook -i inventory_file path/custom-playbook.yml

手順

1. sshd_config_file 変数を含む設定スニペットを Playbook に追加します。

   ---
   - hosts: all
     tasks:
     - name: <Configure sshd to accept some useful environment variables>
       include_role:
         name: rhel-system-roles.sshd
       vars:
         sshd_config_file: /etc/ssh/sshd_config.d/<42-my-application>.conf
         sshd:
           # Environment variables to accept
           AcceptEnv:
             LANG
             LS_COLORS
             EDITOR

   sshd_config_file 変数で、sshd システムロールが設定オプションを書き込む .conf ファイルを定義します。

   設定ファイルが適用される順序を指定するには、2 桁の接頭辞 (例: 42-) を使用します。

   Playbook をインベントリーに適用すると、ロールは sshd_config_file 変数で定義されるファイルに次の設定オプションを追加します。

   # Ansible managed
   #
   AcceptEnv LANG LS_COLORS EDITOR

手順

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

   詳細は、「プライベート CA を使用した OpenSSL での 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

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>

      関連情報

      • certtool(1) および trust(1) の man ページ

手順

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. システムで信頼されている CA のリストに、シンプルな PEM または DER のファイルフォーマットに含まれる証明書を追加するには、/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

手順

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

   # dnf install libreswan

2. Libreswan を再インストールする場合は、古いデータベースファイルを削除し、新しいデータベースを作成します。

   # systemctl stop ipsec
   # rm /var/lib/ipsec/nss/*db
   # ipsec initnss

3. ipsec サービスを開始して有効にし、システムの起動時にサービスを自動的に開始できるようにします。

   # systemctl enable ipsec --now

4. ファイアウォールで、ipsec サービスを追加して、IKE プロトコル、ESP プロトコル、および AH プロトコルの 500/UDP ポートおよび 4500/UDP ポートを許可するように設定します。

   # firewall-cmd --add-service="ipsec"
   # firewall-cmd --runtime-to-permanent

手順

1. 各ホストで Raw RSA 鍵ペアを生成します。

   # ipsec newhostkey

2. 前の手順で生成した鍵の ckaid を返します。左 で次のコマンドを実行して、その ckaid を使用します。以下に例を示します。

   # ipsec showhostkey --left --ckaid 2d3ea57b61c9419dfd6cf43a1eb6cb306c0e857d

   上のコマンドの出力により、設定に必要な leftrsasigkey= 行が生成されます。次のホスト (右) でも同じ操作を行います。

   # ipsec showhostkey --right --ckaid a9e1f6ce9ecd3608c24e8f701318383f41798f03

3. /etc/ipsec.d/ ディレクトリーで、新しい my_host-to-host.conf ファイルを作成します。上の手順の ipsec showhostkey コマンドの出力から、RSA ホストの鍵を新規ファイルに書き込みます。以下に例を示します。

   conn mytunnel
       leftid=@west
       left=192.1.2.23
       leftrsasigkey=0sAQOrlo+hOafUZDlCQmXFrje/oZm [...] W2n417C/4urYHQkCvuIQ==
       rightid=@east
       right=192.1.2.45
       rightrsasigkey=0sAQO3fwC6nSSGgt64DWiYZzuHbc4 [...] D/v8t5YTQ==
       authby=rsasig

4. 鍵をインポートしたら、ipsec サービスを再起動します。

   # systemctl restart ipsec

5. 接続を読み込みます。

   # ipsec auto --add mytunnel

6. トンネルを確立します。

   # ipsec auto --up mytunnel

7. ipsec サービスの開始時に自動的にトンネルを開始するには、以下の行を接続定義に追加します。

   auto=start

手順

1. ホスト間の VPN の設定が含まれるファイルを、新規ファイルにコピーします。以下に例を示します。

   # cp /etc/ipsec.d/my_host-to-host.conf /etc/ipsec.d/my_site-to-site.conf

2. 上の手順で作成したファイルに、サブネット設定を追加します。以下に例を示します。

   conn mysubnet
        also=mytunnel
        leftsubnet=192.0.1.0/24
        rightsubnet=192.0.2.0/24
        auto=start
   
   conn mysubnet6
        also=mytunnel
        leftsubnet=2001:db8:0:1::/64
        rightsubnet=2001:db8:0:2::/64
        auto=start
   
   # the following part of the configuration file is the same for both host-to-host and site-to-site connections:
   
   conn mytunnel
       leftid=@west
       left=192.1.2.23
       leftrsasigkey=0sAQOrlo+hOafUZDlCQmXFrje/oZm [...] W2n417C/4urYHQkCvuIQ==
       rightid=@east
       right=192.1.2.45
       rightrsasigkey=0sAQO3fwC6nSSGgt64DWiYZzuHbc4 [...] D/v8t5YTQ==
       authby=rsasig

手順

1. 各ノードで PKCS #12 ファイルをインポートします。この手順では、PKCS #12 ファイルの生成に使用するパスワードが必要になります。

   # ipsec import nodeXXX.p12

2. IPsec required (private)、IPsec optional (private-or-clear)、および No IPsec (clear) プロファイルに、以下のような 3 つの接続定義を作成します。

   # cat /etc/ipsec.d/mesh.conf
   conn clear
   	auto=ondemand 1
   	type=passthrough
   	authby=never
   	left=%defaultroute
   	right=%group
   
   conn private
   	auto=ondemand
   	type=transport
   	authby=rsasig
   	failureshunt=drop
   	negotiationshunt=drop
   	ikev2=insist
   	left=%defaultroute
   	leftcert=nodeXXXX
   	leftid=%fromcert 2
   	rightid=%fromcert
   	right=%opportunisticgroup
   
   conn private-or-clear
   	auto=ondemand
   	type=transport
   	authby=rsasig
   	failureshunt=passthrough
   	negotiationshunt=passthrough
   	# left
   	left=%defaultroute
   	leftcert=nodeXXXX 3
   	leftid=%fromcert
   	leftrsasigkey=%cert
   	# right
   	rightrsasigkey=%cert
   	rightid=%fromcert
   	right=%opportunisticgroup

1. ping コマンドを使用して IPsec トンネルを開きます。

   # ping <nodeYYY>

2. インポートされた証明書を含む NSS データベースを表示します。

   # certutil -L -d sql:/etc/ipsec.d
   
   Certificate Nickname    Trust Attributes
                           SSL,S/MIME,JAR/XPI
   
   west                    u,u,u
   ca                      CT,,

3. ノードが開いたトンネルを確認します。

   # ipsec trafficstatus
   006 #2: "private#10.15.0.0/16"[1] ...nodeYYY, type=ESP, add_time=1691399301, inBytes=512, outBytes=512, maxBytes=2^63B, id='C=US, ST=NC, O=Example Organization, CN=east'

手順

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

   # dnf install libreswan

2. Libreswan を再インストールする場合は、古い NSS データベースを削除します。

   # systemctl stop ipsec
   
   # rm /var/lib/ipsec/nss/*db

3. ipsec サービスを開始して有効にし、システムの起動時にサービスを自動的に開始できるようにします。

   # systemctl enable ipsec --now

4. ファイアウォールで、ipsec サービスを追加して、IKE プロトコル、ESP プロトコル、および AH プロトコルの 500/UDP ポートおよび 4500/UDP ポートを許可するように設定します。

   # firewall-cmd --add-service="ipsec"
   # firewall-cmd --runtime-to-permanent

5. システムを FIPS モードに切り替えます。

   # fips-mode-setup --enable

6. システムを再起動して、カーネルを FIPS モードに切り替えます。

   # reboot

検証

1. Libreswan が FIPS モードで実行していることを確認するには、次のコマンドを実行します。

   # ipsec whack --fipsstatus
   000 FIPS mode enabled

2. または、systemd ジャーナルで ipsec ユニットのエントリーを確認します。

   $ journalctl -u ipsec
   ...
   Jan 22 11:26:50 localhost.localdomain pluto[3076]: FIPS Mode: YES

3. FIPS モードで使用可能なアルゴリズムを表示するには、次のコマンドを実行します。

   # ipsec pluto --selftest 2>&1 | head -6
   Initializing NSS using read-write database "sql:/var/lib/ipsec/nss"
   FIPS Mode: YES
   NSS crypto library initialized
   FIPS mode enabled for pluto daemon
   NSS library is running in FIPS mode
   FIPS HMAC integrity support [disabled]

4. FIPS モードで無効化されたアルゴリズムをクエリーするには、次のコマンドを実行します。

   # ipsec pluto --selftest 2>&1 | grep disabled
   Encryption algorithm CAMELLIA_CTR disabled; not FIPS compliant
   Encryption algorithm CAMELLIA_CBC disabled; not FIPS compliant
   Encryption algorithm NULL disabled; not FIPS compliant
   Encryption algorithm CHACHA20_POLY1305 disabled; not FIPS compliant
   Hash algorithm MD5 disabled; not FIPS compliant
   PRF algorithm HMAC_MD5 disabled; not FIPS compliant
   PRF algorithm AES_XCBC disabled; not FIPS compliant
   Integrity algorithm HMAC_MD5_96 disabled; not FIPS compliant
   Integrity algorithm HMAC_SHA2_256_TRUNCBUG disabled; not FIPS compliant
   Integrity algorithm AES_XCBC_96 disabled; not FIPS compliant
   DH algorithm MODP1536 disabled; not FIPS compliant
   DH algorithm DH31 disabled; not FIPS compliant

5. FIPS モードで許可されているすべてのアルゴリズムと暗号のリストを表示するには、次のコマンドを実行します。

   # ipsec pluto --selftest 2>&1 | grep ESP | grep FIPS | sed "s/^.*FIPS//"
   aes_ccm, aes_ccm_c
   aes_ccm_b
   aes_ccm_a
   NSS(CBC)  3des
   NSS(GCM)  aes_gcm, aes_gcm_c
   NSS(GCM)  aes_gcm_b
   NSS(GCM)  aes_gcm_a
   NSS(CTR)  aesctr
   NSS(CBC)  aes
   aes_gmac
   NSS       sha, sha1, sha1_96, hmac_sha1
   NSS       sha512, sha2_512, sha2_512_256, hmac_sha2_512
   NSS       sha384, sha2_384, sha2_384_192, hmac_sha2_384
   NSS       sha2, sha256, sha2_256, sha2_256_128, hmac_sha2_256
   aes_cmac
   null
   NSS(MODP) null, dh0
   NSS(MODP) dh14
   NSS(MODP) dh15
   NSS(MODP) dh16
   NSS(MODP) dh17
   NSS(MODP) dh18
   NSS(ECP)  ecp_256, ecp256
   NSS(ECP)  ecp_384, ecp384
   NSS(ECP)  ecp_521, ecp521

手順

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

   # certutil -N -d sql:/var/lib/ipsec/nss
   Enter Password or Pin for "NSS Certificate DB":
   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:

2. 前の手順で設定したパスワードを追加した /etc/ipsec.d/nsspassword ファイルを作成します。以下に例を示します。

   # cat /etc/ipsec.d/nsspassword
   NSS Certificate DB:MyStrongPasswordHere

   nsspassword ファイルは以下の構文を使用することに注意してください。

   token_1_name:the_password
   token_2_name:the_password

   デフォルトの NSS ソフトウェアトークンは NSS Certificate DB です。システムが FIPS モードで実行し場合は、トークンの名前が NSS FIPS 140-2 Certificate DB になります。

3. 選択したシナリオに応じて、nsspassword ファイルの完了後に ipsec サービスを起動または再起動します。

   # systemctl restart ipsec

検証

1. NSS データベースに空でないパスワードを追加した後に、ipsec サービスが実行中であることを確認します。

   # systemctl status ipsec
   ● ipsec.service - Internet Key Exchange (IKE) Protocol Daemon for IPsec
      Loaded: loaded (/usr/lib/systemd/system/ipsec.service; enabled; vendor preset: disable>
      Active: active (running)...

2. 必要に応じて、初期化の成功を示すエントリーが Journal ログに含まれていることを確認します。

   # journalctl -u ipsec
   ...
   pluto[6214]: Initializing NSS using read-write database "sql:/var/lib/ipsec/nss"
   pluto[6214]: NSS Password from file "/etc/ipsec.d/nsspassword" for token "NSS Certificate DB" with length 20 passed to NSS
   pluto[6214]: NSS crypto library initialized
   ...

手順

1. config setup セクションの /etc/ipsec.conf ファイルに以下のオプションを追加します。

   listen-tcp=yes

2. UDP で最初の試行に失敗した場合に TCP カプセル化をフォールバックオプションとして使用するには、クライアントの接続定義に以下の 2 つのオプションを追加します。

   enable-tcp=fallback
   tcp-remoteport=4500

   または、UDP を永続的にブロックしている場合は、クライアントの接続設定で以下のオプションを使用します。

   enable-tcp=yes
   tcp-remoteport=4500

手順

1. ESP ハードウェアオフロードサポートの自動検出を使用する接続の /etc/ipsec.d/ ディレクトリーにある Libreswan 設定ファイルを編集します。
2. 接続の設定で nic-offload パラメーターが設定されていないことを確認します。

3. nic-offload を削除した場合は、ipsec を再起動します。

   # systemctl restart ipsec

1. IPsec 接続が使用するイーサネットデバイスの tx_ipsec および rx_ipsec カウンターを表示します。

   # ethtool -S enp1s0 | egrep "_ipsec"
        tx_ipsec: 10
        rx_ipsec: 10

2. IPsec トンネルを介してトラフィックを送信します。たとえば、リモート IP アドレスに ping します。

   # ping -c 5 remote_ip_address

3. イーサネットデバイスの tx_ipsec および rx_ipsec カウンターを再度表示します。

   # ethtool -S enp1s0 | egrep "_ipsec"
        tx_ipsec: 15
        rx_ipsec: 15

   カウンターの値が増えると、ESP ハードウェアオフロードが動作します。

手順

1. ネットワークボンディングで ESP ハードウェアオフロードのサポートを有効にします。

   # nmcli connection modify bond0 ethtool.feature-esp-hw-offload on

   このコマンドにより、bond0 接続での ESP ハードウェアオフロードのサポートが有効になります。

2. bond0 接続を再度アクティブにします。

   # nmcli connection up bond0

3. ESP ハードウェアオフロードに使用すべき接続の /etc/ipsec.d/ ディレクトリーにある Libreswan 設定ファイルを編集し、nic-offload=yes ステートメントを接続エントリーに追加します。

   conn example
       ...
       nic-offload=yes

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

   # systemctl restart ipsec

検証

1. ボンディングのアクティブなポートを表示します。

   # grep "Currently Active Slave" /proc/net/bonding/bond0
   Currently Active Slave: enp1s0

2. アクティブなポートの tx_ipsec カウンターおよび rx_ipsec カウンターを表示します。

   # ethtool -S enp1s0 | egrep "_ipsec"
        tx_ipsec: 10
        rx_ipsec: 10

3. IPsec トンネルを介してトラフィックを送信します。たとえば、リモート IP アドレスに ping します。

   # ping -c 5 remote_ip_address

4. アクティブなポートの tx_ipsec カウンターおよび rx_ipsec カウンターを再度表示します。

   # ethtool -S enp1s0 | egrep "_ipsec"
        tx_ipsec: 15
        rx_ipsec: 15

   カウンターの値が増えると、ESP ハードウェアオフロードが動作します。

1. vpn.example.com 接続をもう一度読み込みます。

   # ipsec auto --add vpn.example.com
   002 added connection description "vpn.example.com"

2. 次に、VPN 接続を開始します。

   # ipsec auto --up vpn.example.com

手順

1. 以下の内容を含む新しい playbook.yml ファイルを作成します。

   - name: Host to host VPN
     hosts: managed_node1, managed_node2
     roles:
       - rhel-system-roles.vpn
     vars:
       vpn_connections:
         - hosts:
             managed_node1:
             managed_node2:
       vpn_manage_firewall: true
       vpn_manage_selinux: true

   この Playbook は、システムロールによって自動生成されたキーを使用した事前共有キー認証を使用して、managed_node1からmanaged_node2 への接続を設定します。vpn_manage_firewall と vpn_manage_selinux は両方とも true に設定されているため、vpn ロールは firewall ロールと selinux ロールを使用して、vpn ロールが使用するポートを管理します。

2. オプション: ホストの vpn_connections リストに次のセクションを追加して、マネージドホストから、インベントリーファイルに記述されていない外部ホストへの接続を設定します。

       vpn_connections:
         - hosts:
             managed_node1:
             managed_node2:
             external_node:
               hostname: 192.0.2.2

   これは、追加の接続 (managed_node1からexternal_node) へと (managed_node2からexternal_node) を設定します。

   注記

   接続は管理対象ノードでのみ設定され、外部ノードでは設定されません。

3. オプション: vpn_connections 内の追加セクション (コントロールプレーンやデータプレーンなど) を使用して、マネージドノードに複数の VPN 接続を指定できます。

   - name: Multiple VPN
     hosts: managed_node1, managed_node2
     roles:
       - rhel-system-roles.vpn
     vars:
       vpn_connections:
         - name: control_plane_vpn
           hosts:
             managed_node1:
               hostname: 192.0.2.0 # IP for the control plane
             managed_node2:
               hostname: 192.0.2.1
         - name: data_plane_vpn
           hosts:
             managed_node1:
               hostname: 10.0.0.1 # IP for the data plane
             managed_node2:
               hostname: 10.0.0.2

4. オプション: 設定に合わせて変数を変更できます。詳細は、/usr/share/doc/rhel-system-roles/vpn/README.md ファイルを参照してください。

5. オプション: Playbook の構文を確認します。

   # ansible-playbook --syntax-check /path/to/file/playbook.yml -i /path/to/file/inventory_file

6. インベントリーファイルで Playbook を実行します。

   # ansible-playbook -i /path/to/file/inventory_file /path/to/file/playbook.yml

検証

1. マネージドノードで、接続が正常にロードされていることを確認します。

   # ipsec status | grep connection.name

   connection.nameを、このノードからの接続の名前 (たとえば、managed_node1-to-managed_node2) に置き換えます。

   注記

   デフォルトでは、ロールは、各システムの観点から作成する接続ごとにわかりやすい名前を生成します。たとえば、managed_node1 と managed_node2 との間の接続を作成するときに、managed_node1 上のこの接続のわかりやすい名前は managed_node1-to-managed_node2 ですが、managed_node2 では、この接続の名前は managed_node2-to-managed_node1 となります。

2. マネージドノードで、接続が正常に開始されたことを確認します。

   # ipsec trafficstatus | grep connection.name

3. オプション: 接続が正常にロードされない場合は、次のコマンドを入力して手動で接続を追加します。これにより、接続の確立に失敗した理由を示す、より具体的な情報が提供されます。

   # ipsec auto --add connection.name

   注記

   接続のロードおよび開始のプロセスで発生する可能性のあるエラーは、/var/log/pluto.log ファイルに報告されます。これらのログは解析が難しいため、代わりに接続を手動で追加して、標準出力からログメッセージを取得してください。

手順

1. 以下の内容を含む新しい playbook.yml ファイルを作成します。

   - name: Mesh VPN
     hosts: managed_node1, managed_node2, managed_node3
     roles:
       - rhel-system-roles.vpn
     vars:
       vpn_connections:
         - opportunistic: true
           auth_method: cert
           policies:
             - policy: private
               cidr: default
             - policy: private-or-clear
               cidr: 198.51.100.0/24
             - policy: private
               cidr: 192.0.2.0/24
             - policy: clear
               cidr: 192.0.2.7/32
       vpn_manage_firewall: true
       vpn_manage_selinux: true

   注記

   vpn_manage_firewall と vpn_manage_selinux は両方とも true に設定されているため、vpn ロールは firewall ロールと selinux ロールを使用して、vpn ロールが使用するポートを管理します。

2. オプション: 設定に合わせて変数を変更できます。詳細は、/usr/share/doc/rhel-system-roles/vpn/README.md ファイルを参照してください。

3. オプション: Playbook の構文を確認します。

   # ansible-playbook --syntax-check playbook.yml

4. インベントリーファイルで Playbook を実行します。

   # ansible-playbook -i inventory_file /path/to/file/playbook.yml

手順

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

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

手順

1. MACsec を設定する最初のホストで:

   • 事前共有鍵の接続アソシエーション鍵 (CAK) と接続アソシエーション鍵名 (CKN) を作成します。

     1. 16 バイトの 16 進 CAK を作成します。

        # dd if=/dev/urandom count=16 bs=1 2> /dev/null | hexdump -e '1/2 "%04x"'
        50b71a8ef0bd5751ea76de6d6c98c03a

     2. 32 バイトの 16 進 CKN を作成します。

        # dd if=/dev/urandom count=32 bs=1 2> /dev/null | hexdump -e '1/2 "%04x"'
        f2b4297d39da7330910a74abc0449feb45b5c0b9fc23df1430e1898fcf1c4550

2. 両方のホストで、MACsec 接続を介して接続します。

3. MACsec 接続を作成します。

   # nmcli connection add type macsec con-name macsec0 ifname macsec0 connection.autoconnect yes macsec.parent enp1s0 macsec.mode psk macsec.mka-cak 50b71a8ef0bd5751ea76de6d6c98c03a macsec.mka-ckn f2b4297d39da7330910a74abc0449feb45b5c0b9fc23df1430e1898fcf1c4550

   前の手順で生成された CAK および CKN を macsec.mka-cak および macsec.mka-ckn パラメーターで使用します。この値は、MACsec で保護されるネットワーク内のすべてのホストで同じである必要があります。

4. MACsec 接続で IP を設定します。

   1. IPv4 設定を指定します。たとえば、静的 IPv4 アドレス、ネットワークマスク、デフォルトゲートウェイ、および DNS サーバーを macsec0 接続に設定するには、以下のコマンドを実行します。

      # nmcli connection modify macsec0 ipv4.method manual ipv4.addresses '192.0.2.1/24' ipv4.gateway '192.0.2.254' ipv4.dns '192.0.2.253'

   2. IPv6 設定を指定しますたとえば、静的 IPv6 アドレス、ネットワークマスク、デフォルトゲートウェイ、および DNS サーバーを macsec0 接続に設定するには、以下のコマンドを実行します。

      # nmcli connection modify macsec0 ipv6.method manual ipv6.addresses '2001:db8:1::1/32' ipv6.gateway '2001:db8:1::fffe' ipv6.dns '2001:db8:1::fffd'

5. 接続をアクティベートします。

   # nmcli connection up macsec0

検証

1. トラフィックが暗号化されていることを確認します。

   # tcpdump -nn -i enp1s0

2. オプション: 暗号化されていないトラフィックを表示します。

   # tcpdump -nn -i macsec0

3. MACsec の統計を表示します。

   # ip macsec show

4. integrity-only (encrypt off) および encryption (encrypt on) の各タイプの保護に対して個々のカウンターを表示します。

   # ip -s macsec show

手順

1. Dovecot をセットアップします。

   1. /etc/dovecot/conf.d/10-master.conf ファイルに次の行を含めます。

      service auth {
        unix_listener /var/spool/postfix/private/auth {
          mode = 0660
          user = postfix
          group = postfix
        }
      }

      前の例では、Postfix と Dovecot の間の通信に UNIX ドメインソケットを使用しています。また、/var/spool/postfix/ ディレクトリーにあるメールキュー、および postfix ユーザーとグループの下で実行しているアプリケーションを含む Postfix SMTP サーバーのデフォルト設定を想定しています。

   2. オプション: TCP 経由で Postfix 認証リクエストをリッスンするように Dovecot をセットアップします。

      service auth {
        inet_listener {
            port = port-number
        }
      }

   3. /etc/dovecot/conf.d/10-auth.conf ファイルの auth_mechanisms パラメーターを編集して、電子メールクライアントが Dovecot での認証に使用する方法を指定します。

      auth_mechanisms = plain login

      auth_mechanisms パラメーターは、さまざまなプレーンテキストおよび非プレーンテキストの認証方法をサポートしています。

2. /etc/postfix/main.cf ファイルを変更して Postfix をセットアップします。

   1. Postfix SMTP サーバーで SMTP 認証を有効にします。

      smtpd_sasl_auth_enable = yes

   2. SMTP 認証用の Dovecot SASL 実装の使用を有効にします。

      smtpd_sasl_type = dovecot

   3. Postfix キューディレクトリーに相対的な認証パスを指定します。相対パスを使用すると、Postfix サーバーが chroot で実行しているかどうかに関係なく、設定が確実に機能することに注意してください。

      smtpd_sasl_path = private/auth

      この手順では、Postfix と Dovecot の間の通信に UNIX ドメインソケットを使用します。

      通信に TCP ソケットを使用する場合に、別のマシンで Dovecot を探すように Postfix を設定するには、次のような設定値を使用します。

      smtpd_sasl_path = inet: ip-address : port-number

      前の例で、ip-address を Dovecot マシンの IP アドレスに置き換え、port-number を Dovecot の /etc/dovecot/conf.d/10-master.conf ファイルで指定されたポート番号に置き換えます。

   4. Postfix SMTP サーバーがクライアントに提供する SASL メカニズムを指定します。暗号化されたセッションと暗号化されていないセッションに異なるメカニズムを指定できることに注意してください。

      smtpd_sasl_security_options = noanonymous, noplaintext
      smtpd_sasl_tls_security_options = noanonymous

      前のディレクティブは、暗号化されていないセッションでは匿名認証が許可されず、暗号化されていないユーザー名またはパスワードを送信するメカニズムが許可されていないことを指定しています。暗号化セッション (TLS を使用) の場合、非匿名認証メカニズムのみが許可されます。