Origin Management

An origin is an endpoint (typically an IP address) of the application protected by the WAF. An origin can be an Oracle Cloud Infrastructure load balancer public IP address. A load balancer IP address can be used for high availability to an origin. Multiple origins can be defined, but only a single origin can be active for a WAF.

You can set HTTP headers for outbound traffic from the WAF to the origin server. These name value pairs are then available to the application.

Securing Your WAF

To secure your WAF, you must configure your servers to accept traffic from the WAF servers. Configure your origin's ingress rules to only accept connections from the following CIDR ranges:

  • 130.35.0.0/20
  • 130.35.112.0/22
  • 130.35.120.0/21
  • 130.35.128.0/20
  • 130.35.144.0/20
  • 130.35.16.0/20
  • 130.35.176.0/20
  • 130.35.192.0/19
  • 130.35.224.0/22
  • 130.35.232.0/21
  • 130.35.240.0/20
  • 130.35.48.0/20
  • 130.35.64.0/19
  • 130.35.96.0/20
  • 138.1.0.0/20
  • 138.1.104.0/22
  • 138.1.128.0/19
  • 138.1.16.0/20
  • 138.1.160.0/19
  • 138.1.192.0/20
  • 138.1.208.0/20
  • 138.1.224.0/19
  • 138.1.32.0/21
  • 138.1.40.0/21
  • 138.1.48.0/21
  • 138.1.64.0/20
  • 138.1.80.0/20
  • 138.1.96.0/21
  • 147.154.0.0/18
  • 147.154.128.0/18
  • 147.154.192.0/20
  • 147.154.208.0/21
  • 147.154.224.0/19
  • 147.154.64.0/20
  • 147.154.80.0/21
  • 147.154.96.0/19
  • 192.157.18.0/23
  • 192.29.0.0/20
  • 192.29.128.0/21
  • 192.29.144.0/21
  • 192.29.16.0/21
  • 192.29.32.0/21
  • 192.29.48.0/21
  • 192.29.56.0/21
  • 192.29.64.0/20
  • 192.29.96.0/20
  • 192.69.118.0/23
  • 198.181.48.0/21
  • 199.195.6.0/23
  • 205.147.88.0/21

Using the Console

To edit an origin
  1. Open the navigation menu. Under Governance and Administration, go to Security and click Web Application Firewall.
  2. Click the name of the WAF Policy where you want to edit the origin. The WAF Policy overview appears.
  3. Click Settings.
  4. Click the Origin Settings tab.
  5. Click Edit.
  6. In Origin Management Settings, enter the following:
    • Enable Health Checks: Click the check box to enable Health Checks, then enter the following:
      • Request and URL:The type of request and the specific path to visit on the origin when performing the check.
      • Host Header: The value of the host header in the HTTP health check request. If this field is left blank, the policy domain will be used instead.
      • User Agent: The value of the user agent header in the HTTP health check request.
      • Expected Response Code Group: The HTTP response codes that signify the health state.
      • Check Interval (seconds): Interval (in seconds) between health checks to the origin.
      • Response Timeout (seconds):Enter the time to wait for a reply before marking the health check as failed.
      • Healthy Threshold (number of times): Number of successful health checks after which the origin server is marked up.
      • Unhealthy Threshold (number of times): Number of failed health checks after which the origin server is marked down.
      • Enable Response Text Checking: Enable to check for predefined text in addition to the response code.
      • Expected Response Text: Optional. Health checks will search for the given text in a case-sensitive manner within the response body and will fail if the text is not found.
    • Load Balancing Method: Select one of the following methods:
      • IP_HASH: All of the incoming requests from the same client IP address should go to the same content origination server. IP_HASH load balancing method uses origin weights when choosing which origin should the hash be assigned to initially.
      • ROUND_ROBIN: Forwards requests sequentially to the available origin servers. The first request is to the first origin server, the second request is to the next origin server, and so on. After it sends a request to the last origin server, it starts again with the first origin server. When using weights on origins, Weighted Round Robin assigns more requests to origins with a greater weight. Over a period of time, origins will receive a number of requests in proportion to their weight.
      • STICKY_COOKIE: Adds a session cookie to the first response from the origin server and identifies the server that sent the response. The client's next request contains the cookie value, and nginx routes the request to the origin server that responded to the first request. STICKY_COOKIE load balancing method falls back to Round Robin for the first request.
    • Enable Origin Compression: Enable or disable GZIP compression of origin responses.
    • Custom Headers: Optional. Enter the custom HTTP headers to set or override in requests to origin servers.
  7. Click Save Changes.
To edit an origin group
  1. Open the navigation menu. Under Governance and Administration, go to Security and click Web Application Firewall.
  2. Click the name of the WAF Policy you want to edit the origin for. The WAF Policy overview appears.
  3. Click Settings.
  4. Click Origin Groups.
  5. In Origin Groups, enter the following:
    • Name: A unique name for the origin group. Avoid entering confidential information.
    • Default Origin
      • Name:A unique name for the origin. Avoid entering confidential information.
      • URI: The URI of the origin.
      • HTTP Port: The HTTP port on the origin that the web application listens on.
      • HTTPS Port: The HTTPS port on the origin that the web application listens on.
      • Weight: The weight of the origin within the group is used for load balancing purposes. Origins with higher weights will receive larger proportions of client requests.
  6. Click Save Changes.

Using the API

For information about using the API and signing requests, see REST APIs and Security Credentials. For information about SDKs, see Software Development Kits and Command Line Interface.

Each origin has a unique name (key). The name of the origin to be used by the WAF must be referenced in the wafConfig portion of the settings. For example, if you have the following origins in your configuration:

{
   "compartmentId":"ocid1.compartment.oc1..<unique_ID>",
   "lifecycleState":"ACTIVE",
   "displayName":"myWAFprotectedApp",
   "origins":{
      "primaryorigin":{
         "httpPort":80,
         "httpsPort":443,
         "uri":"67.205.161.231",
         "customHeaders":[

         ]
      },
      "secondaryorigin":{
         "httpPort":80,
         "httpsPort":443,
         "uri":"54.175.154.7",
         "customHeaders":[
            {
               "name":"OriginHeader",
               "value":"true"
            },
            {
               "name":"OriginHeader2",
               "value":"true"
            }
         ]
      }
   }
}

Then within the wafConfig, the origin in use would be referenced by name:

"wafConfig":{
   "deviceFingerprintChallenge":{
      "isEnabled":false
   },
   "origin":"secondaryorigin",
   "whitelists":[

   ],

In this example, the WAF is actively using secondaryorigin.