2. Network Security¶

SystemLink connects test systems to a central server to aggregate data for monitoring and analysis. SystemLink uses industry standard tools and best practices to ensure the SystemLink server and test systems utilize secure networking techniques.

Refer to Workspaces and Role-based Access Control for details secure user interactions with SystemLink resources. Refer to Single Sign-on with OpenID Connect and Sign on with LDAP for details on securely authenticating with SystemLink.

2.1 Summary of SystemLink Network Security Best Practices¶

• Use firewalls to restrict open ports to only those needed by your environment.

  • Do not expose Salt ports on the SystemLink server to the public internet.

• Configure NI Web Server to use HTTPS.

• Disable Cross Origin Resource Sharing.

• Use LDAPS for communication between your SystemLink server and LDAP server.

• Use HTTPS for communication between your SystemLink server and OpenID Connect provider.

• If using a remotely connected MongoDB instances, configure this instance to use TLS communication.

• Disable AMQP for client access.

• Use a network load balancer to mitigate against Denial of Service (DoS) threats.

2.2 Network diagram¶

• SystemLink Application Server:

  • This Windows server hosts NI Web Server, the various SystemLink web services, SystemLink web applications, and a Salt master.
  • In the single-box setup, MongoDB and SystemLink file service storage are hosted on the application server.
  • Refer to Sizing a SystemLink Server for details on server system requirements.
  • Securing desktop access to the application server is outside the scope of this document. Configure server access according to the IT policies of your site.

• SystemLink Web Application

  • The SystemLink web application is the primary way users interact with SystemLink.
  • NI recommends HTTPS for all production environments.
  • Refer to 2.3 NI Web Server for details on configuring encrypted communication.

• Targets

  • Targets are Windows and Linux RT systems whose software and configuration are managed by SystemLink.
  • Software configuration occurs via the SaltStack Transport Protocol.
    • Refer to 2.4 Target to SystemLink Communication for details regarding how SystemLink encrypts this communication.
  • File, tag, test, and asset data are published to the SystemLink application server over HTTPS.

• MongoDB

  • MongoDB is the primary database used by SystemLink's web services.
  • The MongoDB wire protocol is used to communicate with the MongoDB instance.
  • Refer to 2.5 TLS for Remote MongoDB Instances for details on enabling TLS communication.

• File Service Storage

  • The SystemLink file service can be configured to store files on either Network Attached Storage (NAS) or AWS S3.
  • NAS uses the SMB protocol.
    • The SMB protocol can be configured to use AES encryption. Refer to SMB security enhancements for details and steps to secure this transport.
  • AWS S3 uses HTTPS. Refer to the SystemLink manual for steps to enable S3 file storage.

• DataFinder (not shown)

  • DataFinder enables indexing and searching for files stored on network drives.
  • DataFinder's network communication cannot be secured with TLS.

• Identity Provider

  • Active Directory, LDAP, and OpenID Connect are supported identity providers.
    • Local Windows accounts may also be used (not shown).
    • Active Directory uses the Active Directory protocol.
    • LDAP uses the ldap or the ldaps protocols.
  • Refer to Sign-on with LDAP. and Single Sign-on with OpenID Connect for details on setting up these identity providers.

• NI VLM

  • NI Volume License Manager (VLM) is used to enforce SystemLink node licenses.
  • NI VLM uses TCP and does not support encrypted communication.
  • Refer to Licensing SystemLink Products for details on using VLM with SystemLink.

2.3 NI Web Server¶

NI Web Server is based on Apache httpd and includes the NI Web Server Configuration utility to guide the selection of secure presets as well as a GUI for setting underlying Apache httpd configurations.

2.3.1 HTTPS in NI Web Server¶

NI Web Server supports TLS 1.3.

NI Web Server Configuration supports creating self-signed certificates, certificate signing requests (CSR), and installing certificates generated by a certificate authority. The DNS settings for the server can affect the operability of these certificates. Refer to 2.3.2 DNS Configuration for details. NI recommends including the fully qualified domain (FQDN) name for your SystemLink Server in either the common name or subject alternative name of your certificate.

When you have received a certificate from an certificate signing authority, you can use NI Web Server Configuration to install the certificate.

1. Open NI Web Sever Configuration and navigate to the HTTPS tab.

2. Click the Use a certificate from a signing authority radio button.

3. Expand the Install an already signed certificate section.

4. Click the folder icon next to Certificate file and browse to your certificate file.

5. Click the folder icon next to Key file and select your key file.

6. Click the Enable HTTP Strict Transport Security checkbox to include the Strict-Transport-Security header in all responses sent by this server. This is strongly recommended but not required.

7. If needed change the HTTPS port from the default, 443.

8. Click Apply and restart.

2.3.1.1 Specifying custom Diffie-Helman parameters¶

The TLS protocol typically uses the Diffie-Hellman key exchange algorithm as part of its connection handshake. The Diffie-Hellman algorithm requires the server to provide a prime number as an input to the algorithm. By default, NI Web Server uses a set of default prime values defined by the Apache Web Server for this purpose. This approach is sufficient for many use cases, but, when additional security is required, a custom value can be provided in place of the defaults.

These instructions use the copy of OpenSSL installed with SystemLink 23.5 or later. A different copy of OpenSSL can be substituted if desired.

1. Open a command prompt on the SystemLink Server machine.

2. Run

   "c:\Program Files\National Instruments\Shared\Skyline\OpenSSL\openssl.exe dhparam -outform PEM -out dhparam.txt <numbits>
   

   The <numbits> value specifies a bit length for the prime. The bit length must be one of 1024, 2048, 3072, 4096, 7680, or 8192 bits. A length of at least 3072 bits is strongly recommended.

3. OpenSSL will run for some time and produce a file called dhparam.txt in the current directory. Open this file in Notepad or another preferred text editor.

4. Run Notepad as an administrator. Open the NI Web Server certificate. This file is located at C:\Program Files\National Instruments\Shared\Web Server\certs\. The actual name of the certificate file will vary per deployment. If there are multiple certificate files in this directory, open C:\Program Files\National Instruments\Shared\Web Server\conf\defines.d\50_httpd-defines.conf and use the file specified by the TLS_CERTIFICATE_PATH variable.

5. Copy the entire contents of dhparam.txt.

6. Scroll to the end of the certificate file.

7. Paste the dhparam contents on the line after the final -----END CERTIFICATE----- line.

8. Save and close the certificate file.

9. Open NI Web Sever Configuration and navigate to the Control tab.

10. Click the Restart button and wait for the server to restart.

2.3.2 DNS Configuration¶

SystemLink and NI Web Server do not ship with a DNS server. NI assumes you will provide a DNS server for your environment. NI Web Server will provide a default for the DNS of your SystemLink server based on Windows OS settings. Other valid DNS names are listed in the Preferred host name for generated URLs and certificates combo box. You may also manually add hostnames as needed. As the name of the combo box implies, this setting must match the host name in your TLS certificates. If you are using OpenID Connect this DNS must also be used in your OpenID Connect redirect URI configuration. If an invalid hostname is provided data from managed targets will not be received by SystemLink.

2.3.3 Cross Origin Resource Sharing and Remote Connections¶

NI recommends disabling Cross Origin Resource Sharing (CORS) in production environments. In practice, CORS may need to be enabled to facilitate workflows for users developing web applications that interact with SystemLink's API. For this scenario, NI recommends setting up a test SystemLink server with CORS enabled.

NI Web Server Configuration exposes settings for choosing a remote connection and automatically sets Windows Firewall rules. This ensures connections may only be established by clients on your preferred network.

Refer to Choosing Remote Settings for details on the various CORS and remote connection settings.

2.4 Target to SystemLink communication¶

Test Systems communicate with SystemLink over HTTP(S) and the SaltStack TCP protocol. Regardless of protocol, All communication is initiated by the test system to the server. Refer to the SystemLink manual for prerequisites and steps to add a Linux RT or Windows target to your SystemLink server.

Data published over HTTPS includes tags, files, assets, and test results. Salt jobs and pillars communicate over the AES encrypted Salt TCP transport. Salt jobs are used for installing software and changing target configuration from SystemLink server. Salt pillars are used to transfer credentials and certificates. The certificates used on the SystemLink server and target nodes are managed by Salt and do not require administrators to explicitly manage these certificates. Refer to SaltStack's documentation for an overview of the Salt TCP Transport.

When a target is approved by SystemLink and becomes a managed node, SystemLink securely transfers configuration, certificates, and credentials needed to authenticate with the SystemLink server's role-based access control system. SystemLink client APIs include an Auto configuration VI that automatically consumes these credentials. This prevents the need to include credentials and other secrets in your test application code.

2.5 TLS for remote MongoDB Instances¶

MongoDB support TLS connections. Refer to the MongoDB manual for details on enabling TLS. NI recommends enabling TLS for remote MongoDB connections.

2.5.1 Connecting to MongoDB Using Self-signed certificates¶

Refer to the MongoDB manual for steps to create and run mongod with a self-signed certificate. The following refers to certificate names created by following MongoDB's documentation.

mongod --tlsMode requireTLS --tlscertificateKeyFile /etc/ssl/test-server1.pem --port 27017 --dbpath /var/lib/mongo --bind_ip_all

net:
    port: 27017
    bindIp: 0.0.0.0
    tls:
        mode: requireTLS
        certificateKeyFile: /etc/ssl/test-server1.pem
systemLog:
    destination: file
    logAppend: true
    path: /var/log/mongodb/mongod.log
storage:
    dbPath: /var/lib/mongo
    journal:
        enabled: true
processManagement:
    fork: true  # fork and run in background
    pidFilePath: /var/run/mongodb/mongod.pid  # location of pidfile
    timeZoneInfo: /usr/share/zoneinfo

2.5.2 Installing MongoDB Self-Signed certificates¶

If you are using a self-signed certificate on your mongod instance you must install the certificate authority (CA) certificate and intermediary certificate into the SystemLink application server.

1. Copy the CA and intermediary .crt files to your SystemLink application server.

2. Double click on the CA certificate and click Install certificate....

   Note

   If you are following the MongoDB manual appendix this file is named mongodb-test-ca.crt.

3. In the Store Location field select the Local Machine radio button and click Next.

4. Select the Place all certificate in the following store radio button.

5. Click Browse, select Trusted Root Certificate Authorities and click OK.

6. Click Next, review the settings, and click Finish to install the certificate.

7. Double click on the intermediary certificate and click Install certificate....

   Note

   If you are following the MongoDB manual appendix this file is named mongodb-test-ia.crt.

8. In the Store Location field select the Local Machine radio button and click Next.

9. Select the Place all certificates in the following store radio button.

10. Click Browse, select Intermediate certificate Authorities and click OK.

11. Click Next, review the settings, and click Finish to install the certificate.

2.6 SSL/TLS for remote PostgreSQL Instances using Client Certificates¶

SystemLink provides limited support connecting to PostgreSQL instances that require client certificate authentication. Refer to the PostgreSQL documentation for details on how to enable TLS and how to require client certificate authentication.

2.6.1 Converting PEM client key and certificate pairs to PFX¶

After enabling client certificate authentication on your PostgreSQL instance, your database provider or administrator should provide you with a client key and a client certificate that has been signed against the PostgreSQL instance's root Certificate Authority certificate. These will often be in the PEM format. These steps will convert these PEM files into a single PFX file that SystemLink supports.

1. Copy the CA certificate, any intermediate certificates, the client key, and the client certificate to your SystemLink application server.

2. Open a command prompt and navigate to "C:\Program Files\National Instruments\Shared\Web Server"

1. If prompted to provide or confirm a password leave the entry blank and press Enter.

2. A PFX file should be produced at your provided output path. You can close the command prompt.

2.6.2 Configuring SystemLink with a PFX client certificate for PostgreSQL¶

1. Double click on the PFX file to launch the installation wizard.

2. In the Store Location field select the Local Machine radio button and click Next.

3. Confirm the file path shown is the path to your PFX file and click Next.

4. Enter the password for the key if it is encrypted in the Password box or leave this box blank if the key is not encrypted.

1. Ensure Include all extended properties and Mark this key as exportable are checked and click Next.

2. Select the Automatically select the certificate store based on the type of certificate radio button and click Next.

3. Review the import summary and click Finish to install the certificate.

4. Add a system-wide environment variable with the key PGSSLCERT and the path to your PFX certificate file as the value.

5. Verify TLS is enabled in your PostgreSQLDatabase section of the NI SystemLink Server Configuration application.

1. Restart SystemLink services via the NI SystemLink Server Configuration application.

2.7 Deprecation of AMQP¶

AMQP as a transport protocol for target-to-server communication is deprecated in favor for HTTP(S). NI recommends disabling AMQP on the server and updating test applications to use the HTTP version of SystemLink APIs.

1. Open NI SystemLink Server Configuration.

2. Go to Security.

3. Uncheck Enable AMQP client access (less secure).