Introduction

Many Oracle E-business Suite customers have chosen Oracle Cloud Infrastructure (OCI) for their production deployments and the number of deployments are growing day by day. EBS customers choose Oracle Cloud Infrastructure for deployment of their demanding enterprise applications, because of the performance, scalability, security and high availability of the environment.

In many of these deployments, customers have requirement to expose some application modules for suppliers and partners. There may also be a requirement for certain end users to connect from outside the corporate firewall. To meet these requirements, it becomes necessary to expose certain application endpoints to internet via demilitarized zone (DMZ). With DMZ deployment, it also becomes necessary to ensure that application is protected against web exploits like SQL injection etc. These web exploits if not handled, could compromise security and impact application availability.

Oracle Cloud Infrastructure Web Application Firewall (WAF) helps you make your endpoints more secure by monitoring and filtering out potentially malicious traffic. It is a cloud-based, Payment Card Industry (PCI) compliant, global security service that protects applications from malicious and unwanted internet traffic. 

This blog post shows an example of how you can use OCI WAF with Oracle E-Business Suite to secure your external internet facing endpoints from internet threats.

EBS Deployment Architecture with WAF

The diagram below shows architecture for Oracle E-Business Suite deployment on OCI with internal as well as external (internet-facing) endpoints. The external endpoints are protected by OCI WAF.

The EBS application nodes have been divided into internal and external nodes.

Internal nodes are the ones which have been deployed to serve internal users. These nodes have been deployed in a private subnet, and a private load balancer has been created to distribute traffic from internal users to these application nodes. The backend set of private load balancer contain just internal application nodes. These application nodes can run Forms, Reports and any other configured services. The private IP of load balancer is configured in on-premise DNS server to access the application URL. SSL certificates (optional) can be loaded into the load balancer to ensure that application is accessible over https from all internal locations.

External application tier contain 2 nodes which have been created in a separate subnet. One of the node has isupplier module configured and other one has irecruitment module configured. For high availability, it is also possible to configure multiple nodes for each module.A public load balancer has been created to send external traffic to the external application nodes.  To ensure that request for irecruitment is sent to irecruitment application node and for isupplier sent to isupplier application node, OCI Load balancer is configured with 2 listeners - one for isupplier module and other for recruitment module.

Each listener runs on the same port 80/443 but have different hostnames and serve different backend sets. Two hostnames – isup and irec have been created and configured with respective listeners. 

The external traffic hitting public load balancer on port 80/443 is directed to respective backend sets identified by hostname set for each listener.

WAF Configuration

OCI WAF has been configured with public load balancer as origin to protect external application endpoints. Any traffic hitting the application URL ( isup.testerp.ml or irec.testerp.ml) will be directed to WAF and WAF will direct this traffic to public load balancer. The load balancer then directs it to appropriate backend set.

Here are the high level steps for configuring WAF.

1) Create WAF Policy

We start by creating a policy to route application traffic through WAF and defining WAF origin. An origin is an endpoint (typically an IP address) of the application protected by the WAF. An origin in our case is Oracle Cloud Infrastructure load balancer public IP address.

As per our architecture, we need to protect 2 endpoints – one for isupplier and other for irecruitment, so 2 such WAF policies are required to be created.

We have 2 WAF policies created to protect our 2 endpoints. The URI is the public IP address of the load balancer.

Each WAF policy provides a CNAME target. The CNAME target is a WAF endpoint.

2) Create CNAME record for WAF CNAME target

The next step is to create a CNAME record for this CNAME target in DNS zone. This is required to route requests from clients to WAF.

For DNS zones managed on OCI, this can be done by choosing DNS zone management under Networking in OCI console.

For our architecture, the DNS record needs to be created for both isup and irec. The graphic above shows CNAME DNS record creation in OCI DNS,

In case DNS resides outside OCI, same has to be done in outside DNS.

After adding CNAME record in OCI DNS, an nslookup to CNAME alias will show DNS redirection to  WAF (CNAME) target.

When traffic hits the application URL, the CNAME record in DNS directs the traffic to CNAME target (OCI WAF).

3) Test Application URL

The application URL isup.testerp.ml and irec.testerp.ml can now be opened in browser. To confirm that our traffic is flowing through WAF, check the http response headers in web browser. This shows traffic is flowing through WAF.

To ensure that Load Balancer receives traffic only from WAF servers, the WAF server IP ranges are the only ones whitelisted for Load Balancer ingress traffic.

For SSL based endpoints, SSL certificates are required to be loaded in WAF.

4) Apply WAF protection rules

The next step is to add required protection rules for the policy.

Protection rules match web traffic to rule conditions and determine the action to be taken when the conditions are met. There are predefined protection rules that can be enabled for passive detection.

The protection rules can be enabled from OCI WAF Console. A common example of protection rule can be to protect application endpoint for Cross-Site Scripting (XSS) and SQL injection attempts. This can be achieved by enabling corresponding rules.

To enable a rule for WAF policy, check the rule and choose the action – Detect/Block/Off. After enabling the rules, the enabled rules are required to be published to WAF servers. This can be done using “Publish All” option under Unpublished changes. It takes few minutes to publish the changes.

Once rule is enabled,  you can test whether enabled rule is doing its job.

With Cross-Site Scripting (XSS) attempt enabled, if you try to open the protected endpoint, the attempt is detected by WAF and logged into WAF logs.

The WAF logs show that the event has been detected. Like this, you can enable multiple rules as per security requirements.

OCI WAF also provides a set of recommendations for rules. These recommendations can be enabled by checking  the recommended rules in OCI WAF console and publishing them. It is always recommended to validate the recommendations before enabling.

Summary

With OCI WAF service, the external internet facing endpoints for Oracle E-Business Suite application can be protected from web exploits. The post also provides an architectural pattern for deployment  of Oracle E-Business Suite with WAF on Oracle Cloud Infrastructure (OCI). 

Hopefully this is a good starting point to protect your EBS application on Oracle Cloud Infrastructure using Web Application Firewall (WAF). In case you want to know more about OCI WAF capabilities, check official documentation  https://docs.cloud.oracle.com/iaas/Content/WAF/Concepts/overview.htm