Securing networks

Procedure

1. Generate an ECDSA key pair:

   $ 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]-----+

   You can also generate an RSA key pair by using the ssh-keygen command without any parameter or an Ed25519 key pair by entering the ssh-keygen -t ed25519 command. Note that the Ed25519 algorithm is not FIPS-140-compliant, and OpenSSH does not work with Ed25519 keys in FIPS mode.

2. Copy the public key to a remote machine:

   $ 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.

   Replace <username>@<ssh-server-example.com> with your credentials.

   If you do not use the ssh-agent program in your session, the previous command copies the most recently modified ~/.ssh/id*.pub public key if it is not yet installed. To specify another public-key file or to prioritize keys in files over keys cached in memory by ssh-agent, use the ssh-copy-id command with the -i option.

Procedure

1. Open the /etc/ssh/sshd_config configuration in a text editor, for example:

   # vi /etc/ssh/sshd_config

2. Change the PasswordAuthentication option to no:

   PasswordAuthentication no

3. On a system other than a new default installation, check that the PubkeyAuthentication parameter is either not set or set to yes.

4. Set the KbdInteractiveAuthentication directive to no.

   Note that the corresponding entry is commented out in the configuration file and the default value is yes.

5. To use key-based authentication with NFS-mounted home directories, enable the use_nfs_home_dirs SELinux boolean:

   # setsebool -P use_nfs_home_dirs 1

6. If you are connected remotely, not using console or out-of-band access, test the key-based login process before disabling password authentication.

7. Reload the sshd daemon to apply the changes:

   # systemctl reload sshd

Procedure

1. Add the command for automatically starting ssh-agent in your session to the ~/.bashrc file:

   1. Open ~/.bashrc in a text editor of your choice, for example:

      $ vi ~/.bashrc

   2. Add the following line to the file:

      eval $(ssh-agent)

   3. Save the changes, and quit the editor.

2. Add the following line to the ~/.ssh/config file:

   AddKeysToAgent yes

   With this option and ssh-agent started in your session, the agent prompts for a password only for the first time when you connect to a host.

Procedure

1. List all keys provided by the OpenSC PKCS #11 module including their PKCS #11 URIs and save the output to the keys.pub file:

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

2. Transfer the public key to the remote server. Use the ssh-copy-id command with the keys.pub file created in the previous step:

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

3. Connect to <ssh-server-example.com> by using the ECDSA key. You can use just a subset of the URI, which uniquely references your key, for example:

   $ 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] $

   Because OpenSSH uses the p11-kit-proxy wrapper and the OpenSC PKCS #11 module is registered to the p11-kit tool, you can simplify the previous command:

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

   If you skip the id= part of a PKCS #11 URI, OpenSSH loads all keys that are available in the proxy module. This can reduce the amount of typing required:

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

4. Optional: You can use the same URI string in the ~/.ssh/config file to make the configuration permanent:

   $ 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] $

   The ssh client utility now automatically uses this URI and the key from the smart card.

Procedure

1. If you connect through a jump server or more intermediary servers once, use the ssh -J command and specify the jump servers directly, for example:

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

   Change the host name-only notation in the previous command if the user names or SSH ports on the jump servers differ from the names and ports on the remote server, for example:

   $ 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. If you connect to a remote server through jump servers regularly, store the jump-server configuration in your SSH configuration file:

   1. Define the jump host by editing the ~/.ssh/config file on your local system, for example:

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

      • The Host parameter defines a name or alias for the host you can use in ssh commands. The value can match the real host name, but can also be any string.
      • The HostName parameter sets the actual host name or IP address of the jump host.

   2. Add the remote server jump configuration with the ProxyJump directive to ~/.ssh/config file on your local system, for example:

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

   3. Use your local system to connect to the remote server through the jump server:

      $ ssh <remote-server-1>

      This command is equivalent to the ssh -J jump-server1 remote-server command if you omit the previous configuration steps.

Procedure

1. Generate a private key for your CA. For example, the following command creates a 256-bit Elliptic Curve Digital Signature Algorithm (ECDSA) key:

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

   The time for the key-generation process depends on the hardware and entropy of the host, the selected algorithm, and the length of the key.

2. Create a certificate signed using the private key generated in the previous command:

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

   The generated ca.crt file is a self-signed CA certificate that you can use to sign other certificates for ten years. In the case of a private CA, you can replace <Example CA> with any string as the common name (CN).

3. Set secure permissions on the private key of your CA, for example:

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

Verification

1. Create a certificate signing request (CSR), and use your CA to sign the request. The CA must successfully create a certificate based on the CSR, for example:

   $ 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

   See Section 2.5, “Using a private CA to issue certificates for CSRs with OpenSSL” for more information.

2. Display the basic information about your self-signed 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. Verify the consistency of the private key:

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

Procedure

1. Generate a private key on your server system, for example:

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

2. Optional: Use a text editor of your choice to prepare a configuration file that simplifies creating your CSR, for example:

   $ 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>

   The extendedKeyUsage = serverAuth option limits the use of a certificate.

3. Create a CSR using the private key you created previously:

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

   If you omit the -config option, the req utility prompts you for additional information, for example:

   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>

Verification

1. After you obtain the requested certificate from the CA, check that the human-readable parts of the certificate match your requirements, for example:

   $ 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
   …

Procedure

1. Generate a private key on your client system, for example:

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

2. Optional: Use a text editor of your choice to prepare a configuration file that simplifies creating your CSR, for example:

   $ 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>

   The extendedKeyUsage = clientAuth option limits the use of a certificate.

3. Create a CSR using the private key you created previously:

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

   If you omit the -config option, the req utility prompts you for additional information, for example:

   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>

Verification

1. Check that the human-readable parts of the certificate match your requirements, for example:

   $ 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
   …

Procedure

1. Optional: Use a text editor of your choice to prepare an OpenSSL configuration file for adding extensions to certificates, for example:

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

2. Use the x509 utility to create a certificate based on a CSR, for example:

   $ 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

Procedure

1. Generate a private key for your CA. For example, the following command creates a 256-bit ECDSA (Elliptic Curve Digital Signature Algorithm) key:

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

   The time for the key-generation process depends on the hardware and entropy of the host, the selected algorithm, and the length of the key.

2. Create a template file for a certificate.

   1. Create a file with a text editor of your choice, for example:

      $ vi <ca.cfg>

   2. Edit the file to include the necessary certification details:

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

3. Create a certificate signed using the private key generated in step 1:

   The generated <ca.crt> file is a self-signed CA certificate that you can use to sign other certificates for one year. <ca.crt> file is the public key (certificate). The loaded file <ca.key> is the private key. You should keep this file in safe location.

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

4. Set secure permissions on the private key of your CA, for example:

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

Verification

1. Display the basic information about your self-signed 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. Create a certificate signing request (CSR), and use your CA to sign the request. The CA must successfully create a certificate based on the CSR, for example:

   1. Generate a private key for your CA:

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

   2. Open a new configuration file in a text editor of your choice, for example:

      $ vi <example-server.cfg>

   3. Edit the file to include the necessary certification details:

      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. Generate a request with the previously created private key:

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

   5. Generate the certificate and sign it with the private key of the CA:

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

      Additional resources

      • certtool(1) and trust(1) man pages on your system

Procedure

1. Generate a private key on your server system, for example:

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

2. Optional: Use a text editor of your choice to prepare a configuration file that simplifies creating your CSR, for example:

   $ 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. Create a CSR using the private key you created previously:

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

   If you omit the --template option, the certool utility prompts you for additional information, for example:

   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>

Verification

1. After you obtain the requested certificate from the CA, check that the human-readable parts of the certificate match your requirements, for example:

   $ 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
   …

Procedure

1. Generate a private key on your client system, for example:

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

2. Optional: Use a text editor of your choice to prepare a configuration file that simplifies creating your CSR, for example:

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

3. Create a CSR using the private key you created previously:

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

   If you omit the --template option, the certtool utility prompts you for additional information, for example:

   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>

Verification

1. Check that the human-readable parts of the certificate match your requirements, for example:

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

Procedure

1. Optional: Use a text editor of your choice to prepare an GnuTLS configuration file for adding extensions to certificates, for example:

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

2. Use the certtool utility to create a certificate based on a CSR, for example:

   $ 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>

Procedure

1. To add a certificate in the simple PEM or DER file formats to the list of CAs trusted on the system, copy the certificate file to the /usr/share/pki/ca-trust-source/anchors/ or /etc/pki/ca-trust/source/anchors/ directory, for example:

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

2. To update the system-wide trust store configuration, use the update-ca-trust command:

   # update-ca-trust extract

Procedure

1. Install the libreswan packages:

   # dnf install libreswan

2. If you are re-installing Libreswan, remove its old database files and create a new database:

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

3. Start the ipsec service, and enable the service to be started automatically on boot:

   # systemctl enable ipsec --now

4. Configure the firewall to allow 500 and 4500/UDP ports for the IKE, ESP, and AH protocols by adding the ipsec service:

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

Procedure

1. Generate a raw RSA key pair on each host:

   # ipsec newhostkey

2. The previous step returned the generated key’s ckaid. Use that ckaid with the following command on left, for example:

   # ipsec showhostkey --left --ckaid 2d3ea57b61c9419dfd6cf43a1eb6cb306c0e857d

   The output of the previous command generated the leftrsasigkey= line required for the configuration. Do the same on the second host (right):

   # ipsec showhostkey --right --ckaid a9e1f6ce9ecd3608c24e8f701318383f41798f03

3. In the /etc/ipsec.d/ directory, create a new my_host-to-host.conf file. Write the RSA host keys from the output of the ipsec showhostkey commands in the previous step to the new file. For example:

   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. After importing keys, restart the ipsec service:

   # systemctl restart ipsec

5. Load the connection:

   # ipsec auto --add mytunnel

6. Establish the tunnel:

   # ipsec auto --up mytunnel

7. To automatically start the tunnel when the ipsec service is started, add the following line to the connection definition:

   auto=start

Procedure

1. Copy the file with the configuration of your host-to-host VPN to a new file, for example:

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

2. Add the subnet configuration to the file created in the previous step, for example:

   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

Procedure

1. On each node, import PKCS #12 files. This step requires the password used to generate the PKCS #12 files:

   # ipsec import nodeXXX.p12

2. Create the following three connection definitions for the IPsec required (private), IPsec optional (private-or-clear), and No IPsec (clear) profiles:

   # 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

Verification

1. Open an IPsec tunnel by using the ping command:

   # ping <nodeYYY>

2. Display the NSS database with the imported certification:

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

3. See which tunnels are open on the node:

   # 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'

Procedure

1. Install the libreswan packages:

   # dnf install libreswan

2. If you are re-installing Libreswan, remove its old NSS database:

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

3. Start the ipsec service, and enable the service to be started automatically on boot:

   # systemctl enable ipsec --now

4. Configure the firewall to allow 500 and 4500 UDP ports for the IKE, ESP, and AH protocols by adding the ipsec service:

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

5. Switch the system to FIPS mode:

   # fips-mode-setup --enable

6. Restart your system to allow the kernel to switch to FIPS mode:

   # reboot

Verification

1. Confirm Libreswan is running in FIPS mode:

   # ipsec whack --fipsstatus
   000 FIPS mode enabled

2. Alternatively, check entries for the ipsec unit in the systemd journal:

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

3. To see the available algorithms in FIPS mode:

   # 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. To query disabled algorithms in FIPS mode:

   # 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. To list all allowed algorithms and ciphers in FIPS mode:

   # 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

Procedure

1. Enable password protection for the NSS database for Libreswan:

   # 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. Create the /etc/ipsec.d/nsspassword file that containins the password you have set in the previous step, for example:

   # cat /etc/ipsec.d/nsspassword
   NSS Certificate DB:_<password>_

   The nsspassword file use the following syntax:

   <token_1>:<password1>
   <token_2>:<password2>

   The default NSS software token is NSS Certificate DB. If your system is running in FIPS mode, the name of the token is NSS FIPS 140-2 Certificate DB.

3. Depending on your scenario, either start or restart the ipsec service after you finish the nsspassword file:

   # systemctl restart ipsec

Verification

1. Check that the ipsec service is running after you have added a non-empty password to its NSS database:

   # 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)...

Procedure

1. Add the following option to the /etc/ipsec.conf file in the config setup section:

   listen-tcp=yes

2. To use TCP encapsulation as a fallback option when the first attempt over UDP fails, add the following two options to the client’s connection definition:

   enable-tcp=fallback
   tcp-remoteport=4500

   Alternatively, if you know that UDP is permanently blocked, use the following options in the client’s connection configuration:

   enable-tcp=yes
   tcp-remoteport=4500

Procedure

1. Edit the Libreswan configuration file in the /etc/ipsec.d/ directory of the connection that should use automatic detection of ESP hardware offload support.
2. Ensure the nic-offload parameter is not set in the connection’s settings.

3. If you removed nic-offload, restart the ipsec service:

   # systemctl restart ipsec

Verification

1. Display the tx_ipsec and rx_ipsec counters of the Ethernet device the IPsec connection uses:

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

2. Send traffic through the IPsec tunnel. For example, ping a remote IP address:

   # ping -c 5 remote_ip_address

3. Display the tx_ipsec and rx_ipsec counters of the Ethernet device again:

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

   If the counter values have increased, ESP hardware offload works.

Procedure

1. Enable ESP hardware offload support on the network bond:

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

   This command enables ESP hardware offload support on the bond0 connection.

2. Reactivate the bond0 connection:

   # nmcli connection up bond0

3. Edit the Libreswan configuration file in the /etc/ipsec.d/ directory of the connection that should use ESP hardware offload, and append the nic-offload=yes statement to the connection entry:

   conn example
       ...
       nic-offload=yes

4. Restart the ipsec service:

   # systemctl restart ipsec

1. Display the active port of the bond:

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

2. Display the tx_ipsec and rx_ipsec counters of the active port:

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

3. Send traffic through the IPsec tunnel. For example, ping a remote IP address:

   # ping -c 5 remote_ip_address

4. Display the tx_ipsec and rx_ipsec counters of the active port again:

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

   If the counter values have increased, ESP hardware offload works.

1. Reload the vpn.example.com connection:

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

2. Next, initiate the VPN connection:

   # ipsec auto --up vpn.example.com

Procedure

1. Press the Super key, type Settings, and press Enter to open the control-center application.
2. Select the Network entry on the left.
3. Click the + icon.
4. Select VPN.

5. Select the Identity menu entry to see the basic configuration options:

   General

   Gateway — The name or IP address of the remote VPN gateway.

   Authentication

   Type

   • IKEv2 (Certificate)- client is authenticated by certificate. It is more secure (default).

   • IKEv1 (XAUTH) - client is authenticated by user name and password, or a pre-shared key (PSK).

     The following configuration settings are available under the Advanced section:

     Figure 5.1. Advanced options of a VPN connection

     
     Warning

     When configuring an IPsec-based VPN connection using the gnome-control-center application, the Advanced dialog displays the configuration, but it does not allow any changes. As a consequence, users cannot change any advanced IPsec options. Use the nm-connection-editor or nmcli tools instead to perform configuration of the advanced properties.

     Identification

   • Domain — If required, enter the Domain Name.

     Security

   • Phase1 Algorithms — corresponds to the ike Libreswan parameter — enter the algorithms to be used to authenticate and set up an encrypted channel.

   • Phase2 Algorithms — corresponds to the esp Libreswan parameter — enter the algorithms to be used for the IPsec negotiations.

     Check the Disable PFS field to turn off Perfect Forward Secrecy (PFS) to ensure compatibility with old servers that do not support PFS.

   • Phase1 Lifetime — corresponds to the ikelifetime Libreswan parameter — how long the key used to encrypt the traffic will be valid.

   • Phase2 Lifetime — corresponds to the salifetime Libreswan parameter — how long a particular instance of a connection should last before expiring.

     Note that the encryption key should be changed from time to time for security reasons.

   • Remote network — corresponds to the rightsubnet Libreswan parameter — the destination private remote network that should be reached through the VPN.

     Check the narrowing field to enable narrowing. Note that it is only effective in IKEv2 negotiation.

   • Enable fragmentation — corresponds to the fragmentation Libreswan parameter — whether or not to allow IKE fragmentation. Valid values are yes (default) or no.
   • Enable Mobike — corresponds to the mobike Libreswan parameter — whether to allow Mobility and Multihoming Protocol (MOBIKE, RFC 4555) to enable a connection to migrate its endpoint without needing to restart the connection from scratch. This is used on mobile devices that switch between wired, wireless, or mobile data connections. The values are no (default) or yes.

6. Select the IPv4 menu entry:

   IPv4 Method

   • Automatic (DHCP) — Choose this option if the network you are connecting to uses a DHCP server to assign dynamic IP addresses.
   • Link-Local Only — Choose this option if the network you are connecting to does not have a DHCP server and you do not want to assign IP addresses manually. Random addresses will be assigned as per RFC 3927 with prefix 169.254/16.
   • Manual — Choose this option if you want to assign IP addresses manually.

   • Disable — IPv4 is disabled for this connection.

     DNS

     In the DNS section, when Automatic is ON, switch it to OFF to enter the IP address of a DNS server you want to use separating the IPs by comma.

     Routes

     Note that in the Routes section, when Automatic is ON, routes from DHCP are used, but you can also add additional static routes. When OFF, only static routes are used.

   • Address — Enter the IP address of a remote network or host.
   • Netmask — The netmask or prefix length of the IP address entered above.
   • Gateway — The IP address of the gateway leading to the remote network or host entered above.

   • Metric — A network cost, a preference value to give to this route. Lower values will be preferred over higher values.

     Use this connection only for resources on its network

     Select this check box to prevent the connection from becoming the default route. Selecting this option means that only traffic specifically destined for routes learned automatically over the connection or entered here manually is routed over the connection.

7. To configure IPv6 settings in a VPN connection, select the IPv6 menu entry:

   IPv6 Method

   • Automatic — Choose this option to use IPv6 Stateless Address AutoConfiguration (SLAAC) to create an automatic, stateless configuration based on the hardware address and Router Advertisements (RA).
   • Automatic, DHCP only — Choose this option to not use RA, but request information from DHCPv6 directly to create a stateful configuration.
   • Link-Local Only — Choose this option if the network you are connecting to does not have a DHCP server and you do not want to assign IP addresses manually. Random addresses will be assigned as per RFC 4862 with prefix FE80::0.
   • Manual — Choose this option if you want to assign IP addresses manually.

   • Disable — IPv6 is disabled for this connection.

     Note that DNS, Routes, Use this connection only for resources on its network are common to IPv4 settings.

8. Once you have finished editing the VPN connection, click the Add button to customize the configuration or the Apply button to save it for the existing one.
9. Switch the profile to ON to active the VPN connection.

Procedure

1. Add firewall rules, for example:

   • Limit TCP connection and accept packages only from the 192.168.0.0/24 host via the 111 port:

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

   • Limit TCP connection and accept packages only from local host via the 111 port:

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

   • Limit UDP connection and accept packages only from the 192.168.0.0/24 host via the 111 port:

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

     To make the firewall settings permanent, use the --permanent option when adding firewall rules.

2. Reload the firewall to apply the new rules:

   # firewall-cmd --reload

Procedure

1. Add firewall rules to the server, for example:

   • Accept mountd connections from the 192.168.0.0/24 host:

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

   • Accept mountd connections from the local host:

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

     To make the firewall settings permanent, use the --permanent option when adding firewall rules.

2. Reload the firewall to apply the new rules:

   # firewall-cmd --reload

Procedure

1. Install PostgreSQL:

   # yum install postgresql-server

2. Initialize a database storage area using one of the following options:

   1. Using the initdb utility:

      $ initdb -D /home/postgresql/db1/

      The initdb command with the -D option creates the directory you specify if it does not already exist, for example /home/postgresql/db1/. This directory then contains all the data stored in the database and also the client authentication configuration file.

   2. Using the postgresql-setup script:

      $ postgresql-setup --initdb

      By default, the script uses the /var/lib/pgsql/data/ directory. This script helps system administrators with basic database cluster administration.

3. To allow any authenticated local users to access any database with their usernames, modify the following line in the pg_hba.conf file:

   local   all             all                                     trust

   This can be problematic when you use layered applications that create database users and no local users. If you do not want to explicitly control all user names on the system, remove the local line entry from the pg_hba.conf file.

4. Restart the database to apply the changes:

   # systemctl restart postgresql

   The previous command updates the database and also verifies the syntax of the configuration file.

Procedure

1. On the first host on which you configure MACsec:

   • Create the connectivity association key (CAK) and connectivity-association key name (CKN) for the pre-shared key:

     1. Create a 16-byte hexadecimal CAK:

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

     2. Create a 32-byte hexadecimal CKN:

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

2. On both hosts you want to connect over a MACsec connection:

3. Create the MACsec connection:

   # 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

   Use the CAK and CKN generated in the previous step in the macsec.mka-cak and macsec.mka-ckn parameters. The values must be the same on every host in the MACsec-protected network.

4. Configure the IP settings on the MACsec connection.

   1. Configure the IPv4 settings. For example, to set a static IPv4 address, network mask, default gateway, and DNS server to the macsec0 connection, enter:

      # 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. Configure the IPv6 settings. For example, to set a static IPv6 address, network mask, default gateway, and DNS server to the macsec0 connection, enter:

      # 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. Activate the connection:

   # nmcli connection up macsec0

Verification

1. Verify that the traffic is encrypted:

   # tcpdump -nn -i enp1s0

2. Optional: Display the unencrypted traffic:

   # tcpdump -nn -i macsec0

3. Display MACsec statistics:

   # ip macsec show

4. Display individual counters for each type of protection: integrity-only (encrypt off) and encryption (encrypt on)

   # ip -s macsec show

Procedure

1. On the first host on which you configure MACsec, create the connectivity association key (CAK) and connectivity-association key name (CKN) for the pre-shared key:

   1. Create a 16-byte hexadecimal CAK:

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

   2. Create a 32-byte hexadecimal CKN:

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

2. On both hosts that you want to connect over a MACsec connection, complete the following steps:

   1. Create a YAML file, for example create-macsec-connection.yml, with the following settings:

      ---
      routes:
        config:
        - destination: 0.0.0.0/0
          next-hop-interface: macsec0
          next-hop-address: 192.0.2.2
          table-id: 254
        - destination: 192.0.2.2/32
          next-hop-interface: macsec0
          next-hop-address: 0.0.0.0
          table-id: 254
      dns-resolver:
        config:
          search:
          - example.com
          server:
          - 192.0.2.200
          - 2001:db8:1::ffbb
      interfaces:
      - name: macsec0
        type: macsec
        state: up
        ipv4:
          enabled: true
          address:
          - ip: 192.0.2.1
            prefix-length: 32
        ipv6:
          enabled: true
          address:
          - ip: 2001:db8:1::1
            prefix-length: 64
        macsec:
          encrypt: true
          base-iface: enp0s1
          mka-cak: 50b71a8ef0bd5751ea76de6d6c98c03a
          mka-ckn: f2b4297d39da7330910a74abc0449feb45b5c0b9fc23df1430e1898fcf1c4550
          port: 0
          validation: strict
          send-sci: true

   2. Use the CAK and CKN generated in the previous step in the mka-cak and mka-ckn parameters. The values must be the same on every host in the MACsec-protected network.

   3. Optional: In the same YAML configuration file, you can also configure the following settings:

      • A static IPv4 address - 192.0.2.1 with the /32 subnet mask
      • A static IPv6 address - 2001:db8:1::1 with the /64 subnet mask
      • An IPv4 default gateway - 192.0.2.2
      • An IPv4 DNS server - 192.0.2.200
      • An IPv6 DNS server - 2001:db8:1::ffbb
      • A DNS search domain - example.com

3. Apply the settings to the system:

   # nmstatectl apply create-macsec-connection.yml

Verification

1. Display the current state in YAML format:

   # nmstatectl show macsec0

2. Verify that the traffic is encrypted:

   # tcpdump -nn -i enp0s1

3. Optional: Display the unencrypted traffic:

   # tcpdump -nn -i macsec0

4. Display MACsec statistics:

   # ip macsec show

5. Display individual counters for each type of protection: integrity-only (encrypt off) and encryption (encrypt on)

   # ip -s macsec show

Procedure

1. Set up Dovecot:

   1. Include the following lines in the /etc/dovecot/conf.d/10-master.conf file:

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

      The previous example uses UNIX-domain sockets for communication between Postfix and Dovecot. The example also assumes default Postfix SMTP server settings, which include the mail queue located in the /var/spool/postfix/ directory, and the application running under the postfix user and group.

   2. Optional: Set up Dovecot to listen for Postfix authentication requests through TCP:

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

   3. Specify the method that the email client uses to authenticate with Dovecot by editing the auth_mechanisms parameter in /etc/dovecot/conf.d/10-auth.conf file:

      auth_mechanisms = plain login

      The auth_mechanisms parameter supports different plaintext and non-plaintext authentication methods.

2. Set up Postfix by modifying the /etc/postfix/main.cf file:

   1. Enable SMTP Authentication on the Postfix SMTP server:

      smtpd_sasl_auth_enable = yes

   2. Enable the use of Dovecot SASL implementation for SMTP Authentication:

      smtpd_sasl_type = dovecot

   3. Provide the authentication path relative to the Postfix queue directory. Note that the use of a relative path ensures that the configuration works regardless of whether the Postfix server runs in chroot or not:

      smtpd_sasl_path = private/auth

      This step uses UNIX-domain sockets for communication between Postfix and Dovecot.

      To configure Postfix to look for Dovecot on a different machine in case you use TCP sockets for communication, use configuration values similar to the following:

      smtpd_sasl_path = inet: ip-address : port-number

      In the previous example, replace the ip-address with the IP address of the Dovecot machine and port-number with the port number specified in Dovecot’s /etc/dovecot/conf.d/10-master.conf file.

   4. Specify SASL mechanisms that the Postfix SMTP server makes available to clients. Note that you can specify different mechanisms for encrypted and unencrypted sessions.

      smtpd_sasl_security_options = noanonymous, noplaintext
      smtpd_sasl_tls_security_options = noanonymous

      The previous directives specify that during unencrypted sessions, no anonymous authentication is allowed and no mechanisms that transmit unencrypted user names or passwords are allowed. For encrypted sessions that use TLS, only non-anonymous authentication mechanisms are allowed.