Best practice 1: Secure your origin IP addresses

When a subdomain uses CIS for proxying, all traffic is protected because CIS returns IP addresses that are associated with its proxy network. This ensures that connections are routed through CIS proxies first, which hides the origin IP addresses.

dig nonproxied.theburritobot.com +short
1.2.3.4 (The origin IP address)

$ dig proxied.theburritobot.com +short
104.16.22.6 , 104.16.23.6 (CIS IP addresses)

Best practice 2: Activate your Web Application Firewall safely

Your WAF is available in the Security section. These steps walk through the settings in reverse order to ensure that your WAF is configured as safely as possible before you enable it for your entire domain.

These initial settings can reduce false positives by populating Security Events for further tuning. Your WAF is updated automatically to handle new vulnerabilities as they are identified. For more information, see Using Security events capability.

The following are some examples of the types of attacks that WAF can protect against:

• SQL injection attack
• Cross-site scripting
• Cross-site forgery

CIS provides several preconfigured rulesets within WAF for Layer 7 protection. Each ruleset includes protections to mitigate the most common web application attacks. You can enable or disable these rulesets and override individual rules to meet your security requirements. For optimal protection, enable the CIS Managed Ruleset at the highest priority. You can use the OWASP ruleset for additional coverage, but place it after the CIS Managed Ruleset in your rule execution order.

The OWASP ruleset is prone to false positives and offers only marginal benefits when placed before the CIS Managed Ruleset and WAF attack score. If you enable the OWASP ruleset, monitor traffic and adjust rule settings as needed to prevent false positives. For more information, see WAF actions for details about the ruleset and the behavior of each rule.

For more information, see Web Application Firewall (WAF) concepts.

Best practice 3: Configure WAF Attack Score safely

WAF Attack Score strengthens your security posture by detecting variations of known attacks by using machine learning. It complements WAF managed rules by identifying malicious requests that do not match existing rule signatures.

To configure WAF Attack Score safely, begin with monitoring traffic before you enforce blocking actions. This approach allows you to review scored traffic in Security Events and adjust thresholds to minimize false positives.

For more information, see using WAF Attack Score to cofigure WAF Attack Score in a custom rule.

CIS recommends using WAF managed rules along with WAF Attack Score. Managed rules protect against known attack patterns, while WAF Attack Score detects modified or obfuscated attacks, providing layered and adaptive protection for your domain. For more information, see About WAF Attack Score.

Best practice 4: Configure your TLS settings

Protect your site and control your Transport Layer Security (TLS) settings. Manage the certificates used to secure traffic to your site. IBM CIS functions as a reverse proxy and provides multiple options for encrypting your traffic. As a reverse proxy, TLS connections terminate at CIS data centers, and a new TLS connection is opened to your origin server.

TLS offers six modes of operations that are listed from most secure to least secure:

1. Authenticated origin pull: (Enterprise only)
2. HTTPS only origin pull (Enterprise only)
3. End-to-end CA signed (default and recommended)
4. End-to-end flexible (edge-to-origin certificates can be self-signed)
5. Client-to-edge (edge-to-origin not encrypted, self-signed certificates are not supported)
6. Off (not recommended)

See TLS options for details on the different modes.

With IBM CIS, you can use custom certificates or a wildcard certificate that is provisioned for you by CIS.

Best practice 5: Configure rate limiting

Use rate-limiting rules to protect your site or API from malicious traffic by blocking client IP addresses that match a URL pattern or exceed a defined threshold.

Common use cases for rate limiting include:

• Enforcing granular access control to resources. This process includes access control based on criteria, such as user agent, IP address, referrer, host, country, and world region.
  • Limit by user agent: A common use case is to limit the rate of requests performed by individual user agents.
  • Allow specific IP addresses or ASNs: Another use case when you control access to resources is to exclude or include IP addresses or Autonomous System Numbers (ASNs) from a rate-limiting rule.
  • Limit by referrer: Some applications receive requests that are originated by other sources (for example, used by advertisements that link to third-party pages). You can limit the number of requests that are generated by individual referrer pages to manage quotas or avoid indirect DDoS attacks.
  • Limit by destination host: Create a rate-limiting rule that uses the host as a counting characteristic.
• Protecting against credential stuffing and account takeover attacks.
• Limiting the number of operations performed by individual clients. This action includes preventing scraping by bots, accessing sensitive data, bulk creation of new accounts, and programmatic buying in e-commerce platforms.
  • Prevent content scraping (through query string)
  • Prevent content scraping (through body)
  • Limit requests from bots
• Protecting REST APIs from resource exhaustion (targeted DDoS attacks) and resources from abuse in general.
  • Prevent volumetric attacks
  • Protect resources
• Protecting GraphQL APIs by preventing server overload and limiting the number of operations.
  • Limit the number of operations
  • Prevent server overload