Server Hardening

Version:
2022.3
Last modified: December 10, 2022

Server hardening is the practice of changing the server configuration at the network, OS and application layers to minimize its attack surface and maximize resistance to penetration attempts. Follow these recommendations to secure the network and OS:  

  • Install the latest version and patch of Server.
  • Configure Server for HTTPS operation using a CA-signed X.509 (TLS/SSL) certificate.  See Configure Server SSL/TLS for more info. 
  • Harden and secure the operating system and database. 

Go to User and Group Management help page for more info. 

Follow these recommendations to secure the application:

  • Review the Web Application Configuration Hardening Procedures below and apply any that are relevant to your environment and organizational policies.
  • Review the Server Administration Hardening Procedures below and apply any that are relevant to your environment and organizational policies.

Anonymous and Guest Accounts 

You can handle anonymous and guest accounts through Admin settings. We recommend that you follow these directions: 

  • Disable user registration. Either enable access via Windows Authentication (IWA) or create accounts as an Admin.  
  • Consider whether unregistered users will be able to run Public Gallery workflows. 

Go to User and Group Management help page for more info. 

Server Administration Hardening Procedures

These settings control the behavior of various aspects of Server's functionality related to permissions and other options that can affect the application's overall security posture.

Set the Gallery Default Run Mode

The Gallery Run Mode setting can provide enhanced security controls over workflow execution of potentially malicious actions. By default, the Gallery Run Mode is set to Unrestricted, which means there are no restrictions, and that any workflow can execute. Configuring this setting to Semi-safe or Safe will further protect the Server environment by preventing workflows from reading or writing data to a location that is not within the workflow staging directory or executing workflows containing restricted tools. This is a global setting that applies to the entire Server environment, but administrators can override it with exceptions at the individual workflow level. Go to the Server UI help page to learn more about the Gallery Run Mode. 

User Settings

There are several settings under the Settings page, which is accessible to users logged-in to Server with Admin privileges (Profile > Admin). In the section User Settings:

  • Set the Default Role dropdown to 'No Access' to prevent users who can login by virtue of an external authentication system (SAML SSO or Integrated Windows Authentication) from having any default view or run access within Server. (Users must be given explicit permissions using criteria beyond mere presence in the external authentication domain.)
  • Disable the Users Can Register toggle to prevent unregistered users from signing up for new accounts (only for Built-In authentication; Server cannot add accounts to an external authentication system.)
  • Disable the Unregistered Users Can Run Public Workflows on the Homepage toggle to prevent anonymous clients from executing workflows published to the homepage.
Security Settings

Login Timeout

As of 22.1 you can configure login attempt timeouts by setting the Enforce Login Attempt Timeout switch (Admin > Settings > Configuration > Security Settings > Enforce Login Attempt Timeout)

User Rights Assignment

User rights assignment process is handled by each customer’s administration team.  

Roles include Viewer, Artisan, and Curator. Go to the User Roles and Permissions help page to learn more about the roles and permissions.  

Security between Server and Persistence Layer (MongoDB) 

Connections between Server and MongoDB are secured by the following measures: 

  • Connections go through the Mongo client driver (by default, this does not encrypt its traffic).
  • Enterprise Mongo supports TLS/SSL (see https://docs.mongodb.com/v3.0/core/security-transport-encryption/) but these connections are not supported in the Embedded MongoDB option which ships with Server.
  • If encrypted database connections are required, consider switching to User-Managed Mongo with an Enterprise Mongo installation, or the MongoDB Atlas SaaS.
    You may also be able to install SSH connection forwarding or a VPN connection between the Alteryx server components and database server; doing so is beyond the scope of this guide.

POODLE Attacks 

Alteryx Designer and Server have supported TLS 1.2 since the 11.5 release. Ensure vulnerable protocols are disabled in Schannel if POODLE Attacks are a concern.

Web Application Configuration Hardening Procedures

These settings affect how the Server's front-end GUI interacts with HTTP/S clients on the wire. 

Enable Server TLS/SSL

The default installation of Server uses HTTP (unencrypted) to simplify installation and configuration. We recommend deploying X.509 certificates and enabling Server SSL/TLS (HTTPS) to encrypt the communication between clients and the Server. This affirms the Server’s identity and safeguards the integrity and confidentiality of user sessions. You will need to create an X.509 certificate request (specifying any FQDN-style hostnames clients will use to browse your Server) and have that request signed by a Certificate Authority trusted by your organization. Go to Configure Server SSL/TLS for steps to do so.

Restrict what values clients can send in the 'Host' HTTP request header

The 'Host' HTTP request header is sent by an HTTP client and contains the internet hostname and port number to which the client originally attempted connection.

If you are logged into Server as an admin, you can specify the hosts you want to allow Server to serve in the Allowed Hosts field, found in  Admin > Settings > Configuration, under the Security section.

Use this as a security measure to prevent HTTP host header attacks. Enter fully qualified domain names (host.domain) 1 per line. Go to the Alteryx Server Settings help page for more information.

Set or customize HTTP response headers sent by Server

HTTP response headers are sent by Server when responding to requests. You can set custom headers or change Server's default values for existing headers by adding stanzas to the <httpHeaders> section of %ProgramFiles%\Alteryx\bin\server\config\alteryx.config.

Below is the set of headers used internally to harden Server for periodic penetration testing (part of our SDLC.) They may not be compatible with all clients. Depending on your organization's needs and policies you may want to update or tailor some values for your environment.

<httpHeaders>
    <header name="Cache-Control" value="no-store; max-age=0" />
    <header name="Strict-Transport-Security" value="max-age=31536000; 
includeSubDomains" />
    <header name="X-Content-Type-Options" value="nosniff" />
    <header name="Content-Security-Policy" value="default-src 'self'; 
img-src 'self' data:; font-src 'self' data:; script-src 'self' 'unsafe-eval' 'unsafe-inline'; 
style-src 'self' 'unsafe-inline'; frame-ancestors 'self'; form-action 'self'" />
    <header name="Access-Control-Allow-Origin" value="https://server.domain.tld" />
    <header name="Vary" value="Origin" />
    <header name="Referrer-Policy" value="no-referrer; strict-origin-when-cross-origin" />
</httpHeaders>

 

Was This Page Helpful?

Running into problems or issues with your Alteryx product? Visit the Alteryx Community or contact support. Can't submit this form? Email us.