X

Best Practices from Oracle Development's A‑Team

The Great HTTP(s) Highway

Introduction

 
When designing a secure and robust route to your compute nodes there are many avenues to take depending on your use case.  As I was learning about the many edge resources you can use within Oracle Cloud Infrastructure (OCI) like Load Balancers, Traffic Steering policies, Web Application Firewall (WAF) policies and DNS zones it became apparent as an architect that I needed to understand in more detail how these services worked and when and why should you use these services.  My final use case is to use all the edge services described above to direct traffic to my web site.
 
Within each section below there are links provided that discusses the topics in more detail.  No need to re-invent the wheel here; these articles are written by my colleagues and they are a great resource for understanding how these edge services work.
 
Throughout these sections I will describe and configure how to move my domain (vk.ociateam.com) to some compute nodes within OCI.  My test case will touch upon all the edge services described above.
 
 Let’s discuss each one in more detail.
 
 

Load Balancer

I think it goes without saying that load balancer's are pretty straight forward.  Load balancer's are used where:

  1. Redundancy is important

  2. Increased Scalability 

  3. Reduced Downtime

  4. Increased Performance

  5. Efficiently Manages Failures

Here is a link that shows how to configure an Load Balancer in OCI.

First, I will be constructing two load balancers that will front end two compute nodes; where we will host a simple home page for vk.ociateam.com.  Each load balancer will reside in two different regions; Toronto and Sydney.  

The Architecture in each region:

 

I will evenly distribute the traffic to both servers and test each region.  I can easily test this by refreshing the page and/or shutting down one server.  Each index page will display a unique value for the load balancer and the specific server it connected to.  This will allow me to test the http traffic flow.

Here is what my page looks like:

 

Of course in a production environment I highly recommend that you at least terminate SSL at the Load Balancer.  Check out these great post that explains how to turn on SSL for load balancing and automatic certificate renewal.

 
 

Traffic Steering Policy

Now that my load balancers and compute instances are setup, I will create a new traffic steering policy.  A common use case for traffic steering policies is the fail-over scenario.  You can also read about it here.

I will setup the same fail-over scenario.  In my case I will use the load balancer in Toronto to handle all requests.  If there is any issues with the Toronto load balancer or issues with Instance1 and Instance2, the request will fail-over to Sydney.

Here is my setup:

Here you can see that my answer pool is the load balancers IP address in Toronto which has the highest priority.

The fail-over will not work unless you have the health check also configured:

 
 
 

DNS Zone Management

During the Traffic Steering policy screens above, I added the sub-domain 'vk' as depicted below. You can also leave this blank and attach it after you have created the steering policy. 

If you are using OCI DNS for your domain, when the Traffic Steering policy gets created or when you attache a domain, a DNS 'A' record is created for your domain under the covers.  If your DNS is hosted elsewhere you must ensure that a record is created to direct users to your site location.

 

Within the DNS Zone Management screens , if there had been an DNS entry for vk.ociateam.com then you would have seen a similar record below:

Notice the ‘….occluded by Steering Policy’.  Basically this means that the steering policy will supersede and apply the policy to the request. 

I can now test my domain vk.ociateam.com.  To simulate the fail-over, I will shutdown the two compute nodes in Toronto.  Now I get redirected to the Sydney load balancer:

 

 

Web Application Firewall

Now that I have fail-over to my web site configured, I want to setup a Web Application Firewall (WAF) to block unwanted requests.

Here is a post that describes some of the protection mechanisms you can apply to protect your site.

For my use case I will:

  1. Log each request to get a sense of what traffic my site is receiving and

  2. I will block certain IPs from accessing my web site.  

To set this up, I need to modify how vk.ociateam.com gets accessed.  Now the WAF will be the entry point for vk.ociateam.com; currently that domain is attached to my Traffic Steering Policy.

The first step is to dissociate my domain with the traffic steering policy and assign a new subdomain.  I currently have:

I need to remove vk.ociateam.com from my policy and create a new one.  Let’s call it vkorigin.ociateam.com; here the name doesn’t really matter and it does not have to be in the same DNS domain.  It is just a pointer to another DNS record that will be used in my WAF origin configuration.

Now we will configure the WAF for vk.ociateam.com with an origin of vkorigin.ociateam.com.

 

Once the WAF policy is created you will see a message that will ask you to add the WAF endpoint to your DNS configuration.

 

This is the final step.  Now all traffic to vk.ociateam.com will be directed to the WAF endpoint!

Now lets add some Access Rules.  I added two rules:

1) Block a specific IP address

2) Allow and Log all traffic

 
 

 

The order of the Access Rules is important.  The more stringent rule should be first.

 
Now when I try and access my web site from a blocked IP:
 
 

Securing the network

One last thing and very important; you will need to secure your network so that no request can bypass the WAF.  Here are some steps you will need to take:

1) Your compute nodes should be on a private subnet; Oracle recommends that you create a Bastion host in a public subnet so you can access your compute nodes. 

2) The security list for the compute nodes should have an specific Ingres rule to allow traffic only from the load balancers IP.

3) 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.

Thats it! Good luck!

P.S. The title of my blog post was inspired by the 'Great Highway'.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha