PreEmptive Analytics Workbench User Guide

Remote Access Security

The recommended installation of the Workbench does not provide remote access to the Workbench Portal. (Users must use Remote Desktop into the host, then access the Portal through a local browser.) This is to provide a "secure by default" installation, so that any data already on the host, or already streaming live into the host, is not exposed (e.g. on the internet).

It also does not provide any encryption (i.e. SSL) for data coming into the host, e.g. from an upstream Data Hub.

This is the simplest and most-secure way to install, but it is not as convenient as having remote access. If you wish to expose the Portal and the endpoint to remote users, this section will help you do so.

It may help if you look at the default install diagram for reference.

Before you begin

Exposing the Workbench to the network requires careful consideration of the security and usability issues that are relevant for your company, your country/region, your end users, and your Workbench users. Depending on your situation, it may be appropriate to grant remote access - or it may require tightening down every aspect of the deployed configuration. This section will cover some standard scenarios, but it is up to you to decide whether these are appropriate for you, and/or to alter these instructions to follow your company policies.

There are three things that are commonly altered about the default installation:

  1. Grant remote access to the portal. This will allow users to access the portal without having to use e.g. Remote Desktop first, e.g. directly from the browser on their computer. For servers inside a corporate network, joined to a Windows domain, this may be all that is necessary. For all other servers, we recommend also implementing the remaining steps below.
    • Note: the default installation of the Workbench portal uses port 88 rather than the normal HTTP port (80). You might want to change this, to allow easier access through firewalls. Typically, though, the Data Hub endpoint is installed on port 80, so you'll need to change the Data Hub endpoint to use another port first.
  2. Require authentication for portal access. This will force users to log in to the portal before they can see data. This is typically done as part of granting remote access to the portal, to ensure that only authorized users have access. Note that this does not encrypt the data over the wire, nor does it protect the user's credentials from sniffing (unless the server and user are both joined to the same Windows domain).
  3. Require encryption (SSL) for all data transfer. This will require the Data Hub endpoint and the Workbench portal to use SSL, providing wire-level encryption for data and for user credentials.

To allow access from remote hosts (unsecured)

For any remote access to be possible, the IIS configuration must be changed. Performing this step will expose the Portal (and related web services) to the network, so you may wish to turn on authentication and encryption (see the sections below) before performing these steps. If you do not need authentication and encryption, this section can be performed on its own.

To configure IIS:

  1. Open the IIS manager (inetmgr.exe)
  2. Select the server node, then Sites, then PreEmptive Analytics Workbench Portal (or the name you chose during installation)
  3. Right-click and choose Edit Bindings...
  4. Edit the site binding, changing the IP address to All Unassigned
  5. Press OK, then Close

These changes take effect immediately, no restart is required.

You may also need to open a port on your firewall. If you use Windows Firewall:

  1. Open Windows Firewall with Advanced Security (in the Start Menu, under Programs -> Administrative Tools)
  2. Select Inbound Rules, then click New Rule...
  3. Select Port, then click Next
  4. Enter 88 (or the port you chose during installation) into the field for Specific local ports
  5. Continue pressing Next until you reach the last page
  6. Enter a name for the firewall rule (i.e. PreEmptive Analytics Workbench)
  7. Press Finish

Remember to test that you can access the Portal remotely, at e.g. http://YOUR_SERVER:88/

To require authentication from remote users

We recommend using the built-in Windows Authentication feature of IIS to manage users and authentication. If the server is joined to a Windows domain, IIS will grant any domain users access to the Portal. If the server is not joined to the domain, then any Windows user configured on the server host will be granted access to the Portal.

Note: Windows Authentication does not provide a reliably-secure level of encryption for credential exchange. If both the server host and client host are joined to the same domain and are on the same network, then the authentication will use Kerberos, which is sufficient for most purposes. If either host is not on the domain, however, the authentication will fall back to NTLM, which is not sufficient for most purposes. If you are concerned about the security of user authentication credentials and/or of data transmitted to the clients, we recommend that you also configure strong encryption.

Warning: If authentication falls back to NTLM (see previous note), and if the users are behind a proxy that maintains and shares TCP connections, authenticated connections can be shared by multiple users, even unauthenticated ones. For this reason, please configure your proxy to not share TCP connections among clients for this server, or choose an alternate method of authentication.

To switch to Windows Authentication, explicitly configure authentication for the PreEmptive Analytics Workbench Portal site, and for each application under that site:

  1. Open the IIS manager (inetmgr.exe)
  2. Enable Windows authentication and disable Anonymous authentication for the portal:
    1. Select the PreEmptive Analytics Workbench Portal site (in the tree)
    2. Double-click on Authentication under IIS
    3. Right-click on Anonymous Authentication and select Disable
    4. If Windows Authentication is not already enabled, right-click on it and select Enable
      • If you do not see Windows Authentication as a choice, you may need to enable the corresponding Windows feature. This is done through the Server Manager (for server OSes) or through the Install Windows Features control panel (client OSes). For server OSes, the feature is: Web Server (IIS) -> Web Server -> Security -> Windows Authentication.
    5. If the server host is not joined to any domain, right-click on Windows Authentication and select "Providers...". Under Enabled Providers, select "Negotiate" and click on "Remove". This will force NTLM authentication and avoid performance issues when using IE11 or lower.
  3. Enable Windows authentication and disable Anonymous authentication for the query service:
    1. Expand the PreEmptive Analytics Workbench Portal site (in the tree)
    2. Select Interaction (in the tree)
    3. Double-click on Authentication under IIS
    4. Right-click on Anonymous Authentication and select Disable
    5. If Windows Authentication is not already enabled, right-click on it and select Enable
    6. If the server host is not joined to any domain, right-click on Windows Authentication and select "Providers...". Confirm that "NTLM" is the only enabled provider. If not, select "Negotiate" under Enabled Providers and click on "Remove". This will force NTLM authentication and avoid performance issues when using IE11 or lower.
  4. Enable Windows authentication and disable Anonymous authentication for the share service:
    1. Expand the PreEmptive Analytics Workbench Portal site (in the tree)
    2. Select FacJSON (in the tree)
    3. Double-click on Authentication under IIS
    4. Right-click on Anonymous Authentication and select Disable
    5. If Windows Authentication is not already enabled, right-click on it and select Enable
    6. If the server host is not joined to any domain, right-click on Windows Authentication and select "Providers...". Confirm that "NTLM" is the only enabled provider. If not, select "Negotiate" under Enabled Providers and click on "Remove". This will force NTLM authentication and avoid performance issues when using IE11 or lower.

Then test access from another machine - it should require credentials. Note: if you access the Portal from the host itself, or from a domain account on another machine, you may not be prompted for credentials; it depends on your browser settings.

Note: access may be denied if the user is due to change their password via Windows. If you are having issues logging in that you can't explain, check that the user account is set to not require password changes, or does not require an immediate change.

SSL for the Portal and Endpoint

This section assumes that you want to:

  • configure the Workbench portal to require SSL, using the default port (443),
  • configure the Data Hub endpoint to require SSL, using an alternate port (413),
  • preserve any authentication changes you made above,
  • and provide a convenient redirect (from port 80) for portal users.

At the end of this process, the configuration will look like this:

SSL Configuration Diagram

You might not have the Repository installed on the same host; it is shown here for reference purposes.

You may wish to compare this to the default install diagram.

Install an SSL certificate

You must obtain and install a valid SSL certificate. Instructions for doing so are typically provided by the issuing certification authority or your internal Operations department. For example, a popular certificate authority provides instructions for generating a certificate signing request and installing an SSL certificate.

Disable Vulnerable SSL Ciphers

We recommend disabling vulnerable SSL ciphers to prevent exploits, including man-in-the-middle attacks. This can be done by running the latest version of this PowerShell script.

Configure the Workbench Portal and Data Hub websites

The approach used here is to configure the Data Hub endpoint and the Workbench portal to use SSL on separate ports. We recommend using the default SSL port of 443 for the Workbench Portal and port 413 for the Hub endpoint, but different port numbers may be used as desired.

  1. Open the IIS manager (inetmgr.exe)
  2. Edit the Data Hub bindings.
    1. Right-click the PreEmptive Analytics Data Hub website and choose Edit Bindings....
    2. Click the Add... button.
    3. In the Add Site Binding dialog, choose https as the Type. Change the port from 443 to 413 (or alternative unused port number). Under SSL certificate, select a valid certificate from the list. Click OK.
    4. Remove the http binding (i.e. port 80 or 88.) Unlike the Workbench Portal, a redirect for this website should not be configured.
    5. Click Close on the Site Bindings dialog.
  3. Edit the Workbench Portal bindings.
    1. Right-click the PreEmptive Analytics Workbench Portal website and choose Edit Bindings....
    2. Click the Add... button.
    3. In the Add Site Binding dialog, choose https as the Type. Under SSL certificate, select a valid certificate from the list. Click OK.
    4. Either remove the http binding (i.e. port 80 or 88) or follow the instructions in the section below to add a redirect from HTTP to HTTPS. If planning to create a redirect, the port used for the http binding should be set to 80.
    5. Click Close on the Site Bindings dialog.
  4. Ensure all ports used in the above bindings are open on the server's firewall.

Note: upstream clients (e.g. a public-facing Data Hub) must be changed to use HTTPS to send data to this host, on the correct port (e.g. 413). Data sent to this host's endpoint via HTTP will fail.

Set HTTPS responses to be non-cacheable

Some browsers, including Internet Explorer, cache content accessed via HTTPS. If sensitive information in application responses is stored in the local cache, then this may be retrieved by other users who have access to the same computer at a future time. This behavior can be disabled by setting response headers.

  1. Open the IIS manager (inetmgr.exe)
  2. With the PreEmptive Analytics Workbench Portal site selected, double-click the HTTP Response Headers icon under IIS.
  3. Use the Add... command in the Actions pane to add each of these headers and the specified value:
    • Cache-Control: no-cache; no-store
    • Expires: 0
    • Pragma: no-cache

Explicitly set the allowed Host headers

To protect against DNS rebinding attacks, you can require the Portal application to only accept requests whose Host header contains the complete domain name for the machine.

  1. Open the IIS manager (inetmgr.exe)
  2. Right-click the PreEmptive Analytics Workbench Portal website and choose Edit Bindings....
  3. For each of the bindings:
    1. Select the binding and click Edit....
    2. In the host name field, enter the fully-qualified domain name of the host.
    3. Click OK.
  4. Click Close on the Site Bindings dialog.

Install URL Rewrite 2.0

Further actions in this section require the IIS module, URL Rewrite 2.0.

Note: This solution uses the URL Rewrite 2.0 module, rather than the HTTP Redirect module, because the HTTP Redirect module is too simple to provide the functionality we need. Even though we are using a "rewrite" module, we will actually be using it to do a "redirect".

The URL Rewrite module may already be installed. To check, click on any website (e.g. PreEmptive Analytics Workbench Portal) in IIS Manager and look for URL Rewrite under IIS. If it is there, the module is installed.

If it is not installed, it can be installed from http://www.iis.net/downloads/microsoft/url-rewrite. If IIS Manager is open, it will need to be closed and re-opened before URL Rewrite appears.

Enable HSTS

To protect against downgrade attacks, you can have the Portal application set the Strict-Transport-Security response header when using HTTPS.

  1. Install the URL Rewrite module, if not already done so.
  2. Open the IIS manager (inetmgr.exe)
  3. With the PreEmptive Analytics Workbench Portal site selected, double-click the URL Rewrite icon under IIS.
  4. In the Actions pane, click Add Rule(s).
  5. Under Outbound rules, choose Blank rule and press OK.
  6. Set the fields as follows (unspecified fields should be left at their default values):
    • Name: Add Custom Header for HTTPS
    • Match:
      • Matching Scope: Server Variable
      • Variable Name: RESPONSE_Strict_Transport_Security
      • Pattern: .*
    • Add a Condition:
      • Condition input: {HTTPS}
      • Check if input string: Matches the Pattern
      • Pattern: ^ON$
    • Action:
      • Action Properties
        • Value: max-age=15768000
  7. Click Apply in the Actions pane.

Provide a Workbench Portal redirect from HTTP to HTTPS

Once SSL is enabled, you need to ensure that data can't be sent over the wire unencrypted. The easiest way to do that is to remove the HTTP binding, but that has the side-effect giving an error message to users who try to access the portal without explicitly typing https://. Instead, we can keep the binding but add a redirect rule, so that any attempt to access the portal via HTTP will be redirected to HTTPS.

The following procedure assumes the PreEmptive Analytics Workbench Portal site has an http binding on port 80.

  1. Install the URL Rewrite module, if not already done so.
  2. Open the IIS manager (inetmgr.exe)
  3. With the PreEmptive Analytics Workbench Portal site selected, double-click the URL Rewrite icon under IIS.
  4. In the Actions pane, click Add Rule(s).
  5. Under Inbound rules, choose Blank rule and press OK.
  6. Set the fields as follows (unspecified fields should be left at their default values):
    • Name: HTTP to HTTPS
    • Match URL
      • Pattern: .*
    • Add a Condition:
      • Condition input: {HTTPS}
      • Check if input string: Does Not Match the Pattern
      • Pattern: ^ON$
    • Action:
      • Action type: Redirect
      • Action Properties
        • Redirect URL: https://{HTTP_HOST}{REQUEST_URI}
  7. Click Apply in the Actions pane.

Test the configuration

  1. Ensure an instrumented application can send Analytics messages to the Data Hub endpoint using HTTPS from a remote machine (i.e. to https://<WORKBENCH_HOSTNAME>:413/endpoint). A quick way to test this is to try that URL in a remote browser. You should see:

    • No authentication prompts
    • SSL enabled (i.e. the lock icon in the address bar)
    • No warnings about SSL issues
    • A 405 HTTP response
  2. Ensure an instrumented application can't send Analytics messages to the Data Hub endpoint using HTTP from a remote machine (i.e. to http://<WORKBENCH_HOSTNAME>/endpoint). A quick way to test this is to try that URL in a remote browser. You should just get a 404 error from your browser, saying that the resource was not available.

  3. Ensure the Workbench portal can be accessed using HTTPS from a remote machine (i.e. from https://<WORKBENCH_HOSTNAME>/). You should see the SSL icon, with no warnings, and you should be prompted for credentials.

  4. Ensure the Workbench portal automatically redirects you to an HTTPS connection, if you try accessing it via HTTP (i.e. from http://<WORKBENCH_HOSTNAME>/). You should see the SSL icon, with no warnings, and you should be prompted for credentials.

Note: HTTPS access may not work from the local server, even though it works correctly from a remote host, if you use the fully-qualified domain name while on the server (i.e. to ensure the SSL certificate is valid). This is because of a security restriction in Windows that helps prevent "loopback attacks." You can use localhost as the hostname (and accept the SSL warning) or you can follow either of the suggestions in the linked article.



Workbench Version 1.2.0. Copyright © 2016 PreEmptive Solutions, LLC