Secure your workloads using Oracle Cloud Infrastructure Network Firewall Service
Oracle Cloud Infrastructure (OCI) offers best-in-class security technology and operational processes to secure its enterprise cloud services. However, security in the cloud is based on a shared responsibility model. Oracle is responsible for the security of the underlying infrastructure, such as data center facilities, hardware, and software to manage cloud operations and services. Customers are responsible for securing their workloads and configuring their services and applications securely to meet their compliance obligations.
The OCI Networking service offers Security Lists and Network Security Groups for virtual cloud networks (VCN) which customers can use to secure their workloads. Many customers also have requirements for Intrusion Prevention Systems, Intrusion Detection, SSL inspection, URL Filtering, traffic inspection and more.
- Stateful network filtering: Create stateful network filtering rules that allow or deny network traffic based on source IP (IPv4 and IPv6), destination IP (IPv4 and IPv6), port, and protocol.
- Custom URL and FQDN filtering: Restrict ingress and egress traffic to a specified list of fully qualified domain names (FQDNs), including wild cards and custom URLs.
- Intrusion Detection and Prevention (IDPS): Monitor your network for malicious activity. Log information, report, or block the activity.
- SSL inspection: Decrypt and inspect TLS-encrypted traffic with Encrypted Server Name Indication (ESNI) support for security vulnerabilities. ESNI is a TLSv1.3 extension that encrypts the Server Name Indication (SNI) in the TLS handshake.
- Logging: Network Firewall is integrated with Oracle Cloud Infrastructure Logging. Enable logs based on your firewall's policy rules.
- Metrics: Network Firewall is integrated with Oracle Cloud Infrastructure Monitoring. Enable alerts based on metrics such as the number of blocked requests using Monitoring service capabilities.
- Intra-VCN subnet traffic inspection: Route traffic between two VCN subnets through a network firewall.
- Inter-VCN traffic inspection: Route traffic between two VCNs through a network firewall.
Architecture
This reference architecture illustrates how organizations can protect workloads deployed in OCI using a Network Firewall and simplify design with Intra Virtual Cloud Network (VCN) routing capabilities. To protect these workloads, Oracle recommends segmenting the network using distributed deployment, where traffic is routed through a Network Firewall and is connected to multiple distinct subnets in a VCN.
You must define a firewall policy before you can deploy an OCI Network Firewall. OCI Network Firewall is a native highly available service within an Availability Domain of a given dedicated Firewall Subnet of VCN. Once deployed, you can use the firewall IP address to route your traffic using VCN route tables. You must route symmetrically to OCI Network Firewall IP Address and apply the required Firewall Policy to support your use-case.
All traffic between VCNs, whether to and from the internet, to and from on-premises, or to the Oracle Services Network can be routed and inspected with Network Firewall that delivers next generation firewall capabilities for organizations of all sizes. Use Network Firewall and its advanced features together with other OCI security services to create a layered network security solution. A Network Firewall is a natively scalable service once you create in the subnet of your choice. The firewall applies business logic to traffic that is specified in an attached Firewall Policy. Routing in the VCN is used to direct network traffic to and from the firewall.
You can deploy Network Firewall as a:
- Distributed Network Firewall Model: OCI Network Firewall is deployed in its dedicated VCN which is recommended.
- Transit Network Firewall Model: OCI Network Firewall is deployed in a Hub VCN and connected to spoke VCNs through dynamic routing gateway.
This architecture outlines how you can deploy Network Firewall in different models, different traffic flows and associated components.
The following diagram illustrates this reference architecture.
oci-network-firewall-arch-oracle.zip
Note:
Each traffic flow ensures that the required Network Firewall Policy is pushed to Network Firewall and route symmetry is used to direct traffic to and from the Network Firewall.North-south inbound internet traffic flow via Internet Gateway through OCI Network Firewall in a secured VCN
Description of the illustration oci-network-firewall-inbound.png
oci-network-firewall-inbound-oracle.zip
North-south outbound internet traffic flow via Internet Gateway through OCI Network Firewall in a secured VCN
Description of the illustration oci-network-firewall-outbound.png
oci-network-firewall-outbound-oracle.zip
North-south outbound internet traffic flow via NAT Gateway and through OCI Network Firewall in a secured VCN
Description of the illustration oci-network-firewall-outbound-nat.png
oci-network-firewall-outbound-nat-oracle.zip
North-south inbound on-premises traffic flow through OCI Network Firewall in a secured VCN
Description of the illustration oci-network-firewall-inbound-prem.png
oci-network-firewall-inbound-prem-oracle.zip
North-south outbound on-premises traffic flow through OCI Network Firewall in a secured VCN
Description of the illustration oci-network-firewall-outbound-prem.png
oci-network-firewall-outbound-prem-oracle.zip
East-west Subnet-A to Subnet-B traffic flow through OCI Network Firewall in a secured VCN
Description of the illustration oci-network-firewall-subnet1.png
oci-network-firewall-subnet-oracle1.zip
East-west Subnet-B to Subnet-A traffic flow through OCI Network Firewall in a secured VCN
Description of the illustration oci-network-firewall-subnet-b.png
oci-network-firewall-subnet-b-oracle.zip
East-west Subnet-A to OCI Services traffic flow through OCI Network Firewall in a secured VCN
Description of the illustration oci-network-firewall-subnet.png
oci-network-firewall-subnet-oracle.zip
Transit OCI Network Firewall deployment architecture
Description of the illustration oci-network-firewall-transit-arch.png
oci-network-firewall-transit-arch-oracle.zip
East-west Spoke Secured-B VCN to Spoke Secured-C VCN traffic flow through OCI Network Firewall in Hub Secured VCN-A
Description of the illustration oci-network-firewall-spoke.png
oci-network-firewall-spoke-oracle.zip
The architecture has the following components:
- Region
An Oracle Cloud Infrastructure region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).
- Compartment
Compartments are cross-region logical partitions within an Oracle Cloud Infrastructure tenancy. Use compartments to organize your resources in Oracle Cloud, control access to the resources, and set usage quotas. To control access to the resources in a given compartment, you define policies that specify who can access the resources and what actions they can perform.
- Availability domains
Availability domains are standalone, independent data centers within a region. The physical resources in each availability domain are isolated from the resources in the other availability domains, which provides fault tolerance. Availability domains don’t share infrastructure such as power or cooling, or the internal availability domain network. So, a failure at one availability domain is unlikely to affect the other availability domains in the region.
- Fault domains
A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain has three fault domains with independent power and hardware. When you distribute resources across multiple fault domains, your applications can tolerate physical server failure, system maintenance, and power failures inside a fault domain.
- Virtual cloud network (VCN) and subnets
A VCN is a customizable, software-defined network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you complete control over your network environment. A VCN can have multiple non-overlapping CIDR blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.
- Security list
For each subnet, you can create security rules that specify the source, destination, and type of traffic that must be allowed in and out of the subnet.
- Network Firewall
A security resource that exists in a subnet of your choice and controls incoming and outgoing network traffic based on a set of security rules. Each firewall is associated with a policy. Traffic is routed to and from the firewall from resources such internet gateway, NAT gateway, service gateway and dynamic routing gateways (DRGs).
- Network Firewall Policy
A firewall policy contains all the configuration rules that control how the firewall inspects, allows, or denies network traffic. Each firewall is associated with a single policy, but a policy can be associated to multiple firewalls. Within a policy, lists and maps are the objects that are used to help you express rules in a clear and concise manner.
- Route tableVirtual route tables contain rules to route traffic from subnets to destinations outside a VCN, typically through gateways. In the Secured VCN, you can have the following route tables:
- Firewall subnet route table in a secured VCN ensures traffic to internet, on-premises, subnets or VCNs reaches the destination, this route table is associated to Network Firewall subnet.
- Internet Gateway route table ensures any inbound traffic from the internet goes through Network Firewall, this route table is associated to the internet gateway.
- NAT Gateway route table ensures any return response from the internet goes through Network Firewall, this route table is associated to the NAT gateway.
- Service Gateway route table ensures any return response from Oracle Services Network communication goes through Network Firewall, this route table is attached to the Service Gateway.
- Each route table ensures you can communicate within a VCN, however if you want to use Network Firewall within subnets in a VCN, ensure that the correct routes are pointing to the Network Firewall IP address.
- The DRG Firewall VCN ingress route table is attached to the Secured VCN attachment to send any incoming traffic from spoke VCNs/on-premises through the dynamic routing gateway to the Network Firewall private IP address.
-
For each spoke attached to the Firewall VCN through dynamic routing gateways, a distinct route table is defined and attached to an associated subnet. This route table forwards all traffic (0.0.0.0/0) from the associated spoke VCN to dynamic routing gateways through the Network Firewall private IP address.
- Private IPs
A private IPv4 address and related information for addressing an instance. Each VNIC has a primary private IP and you can add and remove secondary private IPs. The primary private IP address on an instance is attached during instance launch and does not change during the instance lifetime. Secondary IPs should also belong to the same CIDR of the VNIC’s subnet. The secondary IP is used as a floating IP because it can move between different VNICs on different instances within the same subnet. You can also use it as a different endpoint to host different services.
OCI Network Firewall does not support and require secondary IPs. Use the primary Firewall IP address to route the traffic to Firewall for traffic inspection.
- Public IPsThe networking services define a public IPv4 address chosen by Oracle that is mapped to a private IP.
- Ephemeral: This address is temporary and exists for the lifetime of the instance.
- Reserved: This address persists beyond the lifetime of the instance. It can be unassigned and reassigned to another instance.
- Compute shape
The shape of a compute instance specifies the number of CPUs and amount of memory allocated to the instance. The compute shape also determines the number of VNICs and maximum bandwidth available for the compute instance.
- Virtual network interface card (VNIC)
The services in Oracle Cloud Infrastructure data centers have physical network interface cards (NICs). Virtual machine instances communicate using virtual NICs (VNICs) associated with the physical NICs. Each instance has a primary VNIC that's automatically created and attached during launch and is available during the instance lifetime. DHCP is offered to the primary VNIC only. You can add secondary VNICs after instance launch. You should set static IPs for each interface.
- Internet gateway
The internet gateway allows traffic between the public subnets in a VCN and the public internet.
- NAT gateway
The NAT gateway enables private resources in a VCN to access hosts on the internet, without exposing those resources to incoming internet connections.
- Service gateway
The service gateway provides access from a VCN to other services, such as Oracle Cloud Infrastructure Object Storage. The traffic from the VCN to the Oracle service travels over the Oracle network fabric and never traverses the internet.
- FastConnect
Oracle Cloud Infrastructure FastConnect provides an easy way to create a dedicated, private connection between your data center and Oracle Cloud Infrastructure. FastConnect provides higher-bandwidth options and a more reliable networking experience when compared with internet-based connections.
Recommendations
- VCN
When you create a VCN, determine the number of CIDR blocks required and the size of each block based on the number of resources that you plan to attach to subnets in the VCN. Use CIDR blocks that are within the standard private IP address space.
Select CIDR blocks that don't overlap with any other network (in Oracle Cloud Infrastructure, your on-premises data center, or another cloud provider) to which you intend to set up private connections.
After you create a VCN, you can change, add, and remove its CIDR blocks.
When you design the subnets, consider your traffic flow and security requirements. Attach all the resources within a specific tier or role to the same subnet, which can serve as a security boundary.
- Network Firewall Policies
Refer to the Network Firewall policy documentation in the Explore More section for the most up-to-date information on required security policies, ports, and protocols. Ensure that you've pushed the required policy to Network Firewall.
- Network FirewallRefer to the Network Firewall documentation in the Explore More section to know more about up-to-date-information. Few recommendations are as below:
- As a best practice, do not use the OCI Network Firewall subnet to deploy any other resources since Network Firewall is not able to inspect traffic from sources or destinations within the firewall subnet.
- Deploy distributed deployment architecture and use regional firewall subnets.
- Utilize logging to improve security and view traffic flow.
- You can monitor the health, capacity, and performance of your network firewalls by using metrics, alarms, and notifications.
- For better firewall utilization to ensure it secures all traffic, ensure that you do not add stateful rules to the security list attached to the firewall subnet or include the firewall in a network security group (NSG) containing stateful rules.
- Security list or network security group (NSG) rules associated with the firewall subnet and VNICs are evaluated before the firewall. Be sure that any security list or NSG rules allow the traffic to enter the firewall so that it can be evaluated appropriately.
Considerations
When securing workloads on OCI using Network Firewall, consider the following factors:
- Performance
- Selecting the proper instance size, which is determined by the Compute shape, determines the maximum available throughput, CPU, RAM, and number of interfaces.
- Organizations need to know what types of traffic traverses the environment, determine the appropriate risk levels, and apply proper security controls as needed. Different combinations of enabled security controls impact performance.
- Consider adding dedicated interfaces for FastConnect or VPN services. Consider using large Compute shapes for higher throughput and access to more network interfaces.
- Running performance tests to validate the design can sustain the required performance and throughput.
- Security
- You must route symmetrically to OCI Network Firewall to ensure traffic can reach from source to destination through Network Firewall.
- Security list or network security group (NSG) rules associated with the firewall subnet and VNICs are evaluated before the firewall. Be sure that any security list or NSG rules allow the traffic to enter the firewall so that it can be evaluated appropriately.
- Logging
You can enable logging for your firewalls if the rules in the associated policy support it, and you are subscribed to Oracle Cloud Infrastructure Logging. Logs display log activity and the details of each logged event within a specified time frame. Logs show you when traffic triggers rules and help you improve security.
- Availability
- Deploy your architecture to distinct geographic regions for greatest redundancy.
- Configure site-to-site VPNs with relevant organizational networks for redundant connectivity with on-premises networks.
- Cost
There is a cost per OCI Network Firewall, consider using combined Distributed and Transit firewall model if you have a large number of OCI VCNs. Deploy Network Firewalls only where required.
Deploy
You can deploy the Network Firewall on OCI by using the Console. You can also download the code from GitHub and customize it to suit your specific business requirements to deploy this architecture.
- Go to GitHub.
- Clone or download the repository to your local computer.
- Follow the instructions in the
READMEdocument.