OCI offers a very robust and high-performance network firewall that's integrated into the very core of the Virtual Cloud Network (VCN). For some customers, this is sufficient, while other customers need more from their cloud security than is provided natively with the OCI VCN. Some environments need application-level inspection (such as URL filtering, malware inspection, etc.) while others just need the ability to view traffic flows for traffic traversing their cloud environment. Regardless of the need, for demands that exceed the traditional stateful (and stateless) layer-3/layer-4 filtering that's provided within the OCI VCN, it can be advantageous to use a 3rd-party (non-Oracle) security (firewall, WAF, IPS, etc.) solution to meet these needs.
Disclaimer: Oracle is not pushing any one single vendor's solution. The names used in this document are the property of their respective owners and are used simply as examples. You make your own decision when it comes time to decide what's best for your cloud security!
With the disclaimer out of the way, let's talk about some of the potential solutions for use in OCI.
As with many solutions, there are both open-source (iptables, pfSense, VyOS, etc.) as well as commercial solutions that might be potential options. When working with the open-source solutions, typically we'll either need to build a custom image in OCI (see https://docs.cloud.oracle.com/iaas/Content/Compute/References/customimagesemulationmode.htm in the OCI documentation on how to create a custom OCI image) or installing the application (via Yum/Apt package installation on or compiling on the compute instance itself). I'm not going to delve into this further in this article, but as with most open-source, this is a do-it-yourself project. Many open-source projects have pretty detailed and thorough walk-throughs and tutorials, though I would still anticipate some elbow grease needed (even if following a great how-to guide).
When looking at commercial solutions that are available, there are several different commercial security and/or firewall offerings (as of when this was written) in the OCI marketplace:
The above list might not be exhaustive, but shows some supported commercial vendors on OCI (though not necessarily all). Don't see your favorite security vendor in the above list I've compiled? Please visit the OCI Cloud Marketplace and perform a quick search for your vendor of choice. You might find them! If not, don't despair - I'd recommend that you engage your security vendor and your Oracle team to see if it's possible to implement a solution for you in OCI.
Once you've selected a winner for helping to increase the security of your OCI environment, what's next? Cloud networking is not completely synonymous with traditional on-premise/data center networking. There are different caveats that we must be aware of and plan accordingly. With this in mind, there are a couple of potentially recommended topologies that are often seen as design patterns for any sort of 3rd-party security solution. Let's cover those briefly, then in future articles, we'll dive into greater detail around the specifics of each of these.
The first scenario is the simpler of the two, utilizing a single VCN:
Scenario 1 - using a single VCN
The second scenario uses two VCNs (a DMZ VCN and a VCN used for internal resources):
Scenario 2 - using two VCNs
Notice that in both of the above scenarios, the security appliance is used to protect the perimeter of the VCN (not the interior or intra-VCN traffic). Let's talk about why...
This is a common request. Having a firewall as the default gateway (only way in and out of a VLAN) in a traditional data center is a common architectural design pattern. This type of design allows for having a firewall effectively embedded within an environment, not only protecting the perimeter, but really every network segment that is connected via the firewall.
This is not possible in OCI, as it's impossible to create route table rules for CIDRs that fall within the VCN CIDR. Here's what happens when you try to add a route rule (let's say for 10.0.2.0/24) for a CIDR that is within the VCN CIDR (in this example, the VCN CIDR is 10.0.0.0/22):
Example screenshot of trying to add an invalid route in OCI
Now some of us don't like taking no for an answer, so we'll try to come up with alternative solutions to integrate firewalls into internal OCI architecture. We might envision a potential scenario where we deploy a firewall vNIC into each subnet within our VCN, then telling each instance to use the private IP of a firewall vNIC as the default gateway (instead of the subnet's default gateway that's automatically provisioned for the subnet). Here's what this might look like:
Using a firewall as a default gateway
Will this work? Maybe...
If the OCI environment is completely self-contained (no external access to/from the Internet or any network), then this (in theory) might work to some degree:
Traffic in the same VCN (with a firewall)
The above example has several constraints and considerations:
The above fictitious scenario, while it might work in theory, isn't practical, because clouds exist to provide value... a completely self-contained cloud provides little to no value. When we introduce an Internet Gateway (IGW), Dynamic Routing Gateway (DRG), Local Peering Gateway (LPG) or other cloud-native networking objects, this whole "let's use my firewall as the default gateway" scenario breaks in a bad way. A picture is worth a thousand words, so take a look at the following to see some potential issues:
Potential asymmetrical flows in OCI with a firewall
This wouldn't work so well for most environments, due to several issues. The first is that in this scenario, Web-Srvr doesn't have a public IP address, so the minute egress traffic tries to go out via the IGW, it won't have a public IP that it can NAT Web-Srvr's private IP to. The second issue is that the return traffic will completely bypass the firewall. This is because we cannot modify the routing table (routing policy) of built-in OCI networking components, therefore these components (IGW, DRG, LPG, etc.) assume that the VCN should be used for any and every IP address that falls within the VCN CIDR should be routed to the traditional VCN routing components. The end result is that we end up with asymmetrical traffic flows (which most any stateful firewall will not like or permit).
This results in things breaking in new and exciting ways within the OCI environment. To summarize all of this: use 3rd-party security solutions to protect the perimeter of VCNs, not the interior.
If you have a few public-facing applications, the single VCN might be sufficient. If you have a lot of different applications that are available to the public, then the DMZ VCN design might be an optimal solution. There are more trade-offs (such as the complexity that goes along with multiple VCNs) to consider, but these will be saved for upcoming articles that dive deeper into each of these designs.
On a side note, if you start with the single VCN approach, it might be possible to migrate to the two VCN approach in the future. This kind of migration would be disruptive (the public IP address will change, etc.). If you start down the easier/simpler path and find that you've outgrown it, you do have options!
Stay tuned for additional articles that will dive into each of the two suggested scenarios above, allowing us to better cover the intricacies of each solution.