Search

Security Best Practices

Version 23.4.8839

Security Best Practices

This page provides information on security-related features available in CData Arc and describes the best practices we recommend you follow. Security topics are divided broadly into two categories:

  • Securing the infrastructure upon which Arc operates
  • Securing data in Arc

Both of these sections describe relevant security concepts and contain subsections with our best practice recommendations.

Securing the CData Arc Infrastructure

Many security settings are managed by the server configuration files. When you use the embedded web server included with Arc, the server configuration files are found in the following locations:

  • .NET Edition—the Web.Config file in the www folder of the Arc installation directory (by default, C:\Program Files\CData\CData Arc)

  • Java Edition—the arc.properties file in the Arc installation directory

When deploying Arc to an external server, you should use the configuration file for that external server instead.

Enabling TLS/SSL for Inbound Traffic

CData strongly recommends that you enable TLS/SSL on your server. TLS/SSL uses public-key/private-key cryptography to encrypt communication channels between a client and server. This encryption protects the confidentiality, authenticity, and integrity of data in Arc. In addition, through the use of digital certificates, TLS offers facilities for client/server identity confirmation.

Enabling inbound TLS/SSL can be divided into two categories:

  • TLS for the host web server, which relates to HTTP traffic, including protocols (such as AS2 and AS4) that use HTTP underneath. Since the web server that hosts Arc is used to handle these requests, TLS must be enabled at the web server level.
  • TLS for all other servers, which relates to non-HTTP traffic, such as FTP and OFTP. Since the servers handling these inbound connections are not the same as the web server hosting Arc, you must enable these options for the appropriate protocol in the Arc interface on the tabs on the Profiles page.

TLS/SSL for the Web Server

TLS/SSL for Other Servers

Use the Profiles page to enable TLS/SSL for the following servers:

Each server has a tab on the Profiles page where you can enable or disable TLS/SSL.

Configuring Firewalls and Using a DMZ

In order for Arc to send and receive messages, it needs to be free from firewall interference on the relevant sending and receiving ports. The best option is to whitelist specific IPs within the firewall to ensure that traffic only comes from expected sources. In cases where this is not possible, the firewall must be opened on critical ports where Arc listens for inbound messages. Arc protects configuration resources behind a login portal.

By default, the Arc web server listens on port 8001. You can configure ports for non-web protocols directly in the application. For example, you can configure the OFTP server listening port in the OFTP server tab on the Profiles page.

DMZ

The .NET edition of Arc includes support for establishing a reverse SSH tunnel to host Arc in a demilitarized zone (DMZ) to avoid opening the firewall on a private network directly. See DMZ Gateway for more information on cloud hosting.

Separating Public Endpoints from the Web Interface

By default, Arc uses the same web server port to host both the admin console (where Arc is configured and managed) and the public receiving endpoints that remote partners use to send data to the application. The admin console is protected by credentials to ensure that remote partners cannot gain access. However, hosting the public receiving endpoints on a separate port ensures that network/firewall rules can be used to add a layer of redundancy and enhance security. See Separate API Endpoints for more information on hosting public receiving endpoints on a separate network port.

Hardening Server Security Settings

You can increase the security of your Arc server by setting the ScriptingEngineHardeningLevel configuration parameter in the Arc configuration files. By default, this parameter is set to 0, which does not block any operations. You can set it to a value between 0 and 3, where each higher value increases security by disabling certain operations. The following table shows which operations are disabled at each hardening level:

Level Disabled Operations
0 All operations are allowed. This is the default.
1 The most vulnerable operations are disabled. This includes any operations that allow the user to interact with the host system in an arbitrary way.
2 In addition to the operations disallowed in level 1, this level disables operations for creating new users, accessing files on disk in a non-arbitrary way, and introducing recurring tasks.
3 In addition to the operations disallowed in levels 1 and 2, this level disables operations for obtaining sensitive information from the server or performing arbitrary http requests.

Use the following sections to set the hardening level for your installation.

.NET

Use a text editor to open the Web.Config file in the www folder of the installation directory. At the bottom, inside the <appSettings> tag, add the following line and set value to your desired level:

<appSettings>
     <add key="ScriptingEngineHardeningLevel" value="0"/>
</appSettings>

Java

Use a text editor to open the arc.properties file in the installation directory. Add a line for the following property, and set the number to your desired level:

cdata.initParameters=ScriptingEngineHardeningLevel:0

Interaction with External Malware and Antivirus File Scanners

Arc expects to have exclusive access to the contents of the Application Directory for the duration of file processing. The application uses time-sensitive resources such as resource locks in the application directory to ensure that multiple threads do not process the same files. It scans files in the Input tabs of connectors to apply metadata to messages, and when it moves files between connectors it immediately moves files between connector directories to ensure rapid processing across multiple steps in a flow.

Processes that scan files and file handles can impact the performance in Arc and cause unexpected behaviors in the application, including interruptions in file automation, failure to log traffic, failure to move messages between connectors, degradation of processing performance, and so on.

CData recommends that you do not point file scanning utilities to the Arc Application Directory or any of its subdirectories. If you need to perform virus or malware scanning on files that arrive on the local system, we recommend that you use the File connector to move files to a path on a disk outside of the Application Directory. That location can then be used as a staging folder for file scanning.

Use the File Connector to Continue Processing Scanned Files

When you receive files from a folder on disk that is shared with another process, you can use the File connector to set a Receiving Delay to configure the time (in seconds) that the connector waits before receiving and processing incoming files. The default interval is 5 seconds. Increase that value to allow more time for the file scanner to complete.

Securing Data in CData Arc

The following sections relate to the security of data in Arc, including the messages/data that flow through the application and the flow configurations themselves.

Enabling TLS/SSL for Outbound Traffic

Arc automatically parses whether to negotiate TLS/SSL based on the target URL of outbound connections. For example, if an outbound AS2 connection is targeting an https URL, Arc negotiates TLS.

TLS/SSL is strongly recommended for transferring data over protocols that do not include built-in encryption mechanisms. This means that web traffic should be sent to https endpoints, FTP traffic should be directed to ftps endpoints, and so on. Other than correctly configuring the target URL, no additional steps are necessary to ensure Arc negotiates TLS/SSL encryption.

Validating TLS/SSL Server Certificates and SSH Keys

When making an outbound connection to a TLS/SSL or SSH server, the connector establishing the connection (for example, REST, AS2, or SFTP) attempts to validate the certificate or key provided by the server. If a server certificate/key is not configured in the connector settings, Arc uses the validation process present in the underlying system (the OS or JRE) to determine if the server’s certificate is trusted.

You can configure connectors with a specific TLS/SSL certificate or SSH key thumbprint to override the underlying system behavior. When making an outbound connection, if the server’s certificate matches the certificate configured in the connector, the connector trusts the server. This option provides the highest level of security.

Connectors implicitly trust the server’s identity when you set the TLS Server Certificate field to Any Certificate. You should only do this when there is no concern about server impersonation attacks.

Managing Users and Admins and Accessing the API

Arc maintains a set of username and password credentials for users who are authorized to log in to the Arc web interface and use the application. For more information on users and roles, including the Admin role, see User Management and Roles.

Users with the Admin role are allowed to access and change passwords of other users. The credentials for the Admin user created when Arc is first launched should be securely stored in an external location to ensure that this account is both secure and recoverable.

Admin API

Users can perform all application management tasks via calls to the Admin API, so securing access to this API is just as important as securing access to the web interface. When an Arc user is created, you can generate an auth token that allows this user access to the API (with restrictions according to that user’s role in the application). For more information on using an auth token to access the Admin API, see API Authentication.

Note: A user’s auth token is not displayed after it is created, so it should be stored securely in an external location.