Best practices for CIS setup

Because IBM Cloud® Internet Services is positioned at the edge of your network, you’ll need to take a few steps to guarantee a smooth integration with your CIS services. Consider these recommended best practices for integrating CIS with your origin servers.

You can do these steps either before or after you change your DNS and activate our proxy service. These recommendations allow CIS to connect to your origin servers properly. They’ll help you prevent any issues with API or HTTPS traffic, and help your logs capture the correct IP addresses of your customers, rather than the protective CIS IP addresses.

Here’s what you need to set up:

Restore the originating IPs of your customers
Incorporate CIS IP addresses
Make sure that your security settings don't interfere with API traffic
Configure your security settings as strictly as possible

Best practice 1: Know how to restore the originating IPs of your customers

As a reverse proxy, CIS provides the origination IP in these headers:

CF-Connecting-IP
X-Forwarded-For
True-Client-IP (optional)

You can restore user IP addresses by using various tools for infrastructures such as Apache, Windows IIS, and NGINX.

Best practice 2: Incorporate CIS IP addresses to make integration smoother

Take the following two steps:

Remove any rate limiting of CIS IP addresses
Set up your ACLs to allow only CIS IP addresses and other trusted parties

You can find the updated list of IP ranges for IBM CIS at this location.

Best practice 3: Review your security settings to make sure they don’t interfere with API traffic

IBM CIS usually accelerates API traffic by removing connection overhead. However, the default security stance can interfere with many API calls. It is recommended that you take a few actions to prevent interference with your API traffic after proxying is active.

Turn your security features off selectively by using the Page Rules features.
- Create a Page Rule with the URL pattern of your API, such as api.example.com
- Add the following rule behaviors:
  - Select Security Level to Essentially off
  - Select TLS to Off
  - Select Browser Integrity Check to Off
- Select Provision Resource
Alternatively, you can turn off Web Application Firewall globally from the Security page.

What does the Browser Integrity Check do?

The browser integrity check looks for HTTP headers that are commonly abused by spammers. It denies traffic with those headers access to your page. It also blocks visitors that do not have a user agent, or who add a non-standard user agent (this tactic is commonly used by abuse bots, crawlers, or APIs).

Best practice 4: Configure your security settings as strictly as possible

CIS provides some options for encrypting your traffic. As a reverse proxy, the TLS connection is terminated at Cloudflare and a new TLS connection is opened to your origin servers. For your termination with CIS, you can upload a custom certificate from your account, use a wildcard certificate that is provisioned for you by CIS, or both.

Upload a custom certificate

You can upload your public and private keys when you create an Enterprise domain. If you upload your own certificate, you gain immediate compatibility with encrypted traffic, and you maintain control over your certificate (for example, an Extended Validation (EV) certificate). Remember that you are responsible for managing your certificate if you upload a custom certificate. For example, IBM CIS doesn't track the certificate expiration dates.

Alternatively, use a certificate provisioned by CIS

IBM CIS works with several Certificate Authorities (CAs) to provide domain wildcard certificates for our customers, by default. Manual verification might be required for setting up these certificates, and your support team can help you perform these additional steps.

Change your TLS setting to End-to-End CA Signed

Most of our Enterprise customers use the End-to-End CA Signed security setting. An End-to-End CA Signed setting requires a valid, CA-signed certificate installed on your web server. The certificate's expiration date must be in the future, and it must have a matching hostname or Subject Alternative Name (SAN).