Securing Networking: VCN, Load Balancers, and DNS

Security Recommendations

The Networking service has a collection of features for enforcing network access control and securing VCN traffic. These features are listed in the following table.

Oracle recommends that you periodically monitor Oracle Cloud Infrastructure Audit logs to review changes to VCN network security groups, security lists, route table rules, and VCN gateways.

Network Segmentation: VCN Subnets

• Formulate a tiered subnet strategy for the VCN, to control network access. A common design pattern is to have the following subnet tiers:

  1. DMZ subnet for load balancers
  2. Public subnet for externally accessible hosts such as NAT instances, intrusion detection (IDS) instances, and web application servers
  3. Private subnet for internal hosts such as databases

  No special routing is required for the instances in the different subnets to communicate. However, you can control the types of traffic between the different tiers by using the VCN's network security groups or security lists.

• Instances in the private subnet only have private IP addresses and can be reached only by other instances in the VCN. Oracle recommends that you place security-sensitive hosts (DB systems, for example) in a private subnet, and use security rules to control the type of connectivity to hosts in a public subnet. In addition to VCN security rules, configure host-based firewalls such as iptables, firewalld for network access control, as a defense-in-depth mechanism.
• You can add a service gateway to your VCN to enable DB systems in the private subnet to directly back up to Object Storage without the traffic traversing the internet. You must set up the routing and security rules to enable that traffic. For more information for bare metal or virtual machine DB systems, see Configure the Network. For more information for Exadata DB systems, see Network Setup for Exadata Cloud Service Instances.

Network Access Control: VCN Security Rules

• Use your VCN's security rules to restrict network access to instances. A security rule is stateful by default, but can also be configured to be stateless. A common practice is to use stateless rules for high-performance applications. In a case where network traffic matches both stateful and stateless security lists, the stateless rule takes precedence. For more information about configuring VCN security rules, see Security Rules.
• To prevent unauthorized access or attacks on Compute instances, Oracle recommends that you use a VCN security rule to allow SSH or RDP access only from authorized CIDR blocks rather than leave them open to the internet (0.0.0.0/0). For additional security, you can temporarily enable SSH (port 22) or RDP (port 3389) access on an as-needed basis using the VCN API UpdateNetworkSecurityGroupSecurityRules (if you're using network security groups) or UpdateSecurityList (if you're using security lists). For more information about enabling RDP access, see To enable RDP access in Creating an Instance. For performing instance health checks, Oracle recommends that you configure VCN security rules to allow ICMP pings. For more information, see Rules to Enable Ping.
• Bastions are logical entities that provide secured, public access to target resources in the cloud that you cannot otherwise reach from the internet. Bastions reside in a public subnet and establish the network infrastructure needed to connect a user to a target resource in a private subnet.
• VCN network security groups (NSGs) and security lists enable security-critical network access control to compute instances, and it is important to prevent any unintended or unauthorized changes to NSGs and security lists. To prevent unauthorized changes, Oracle recommends that you use IAM policies to allow only network administrators to make NSG and security list changes.

Secure Connectivity: VCN Gateways and FastConnect Peering

• VCN gateways provide external connectivity (internet, on-premises, or peered VCN) to VCN hosts. See the table earlier in this topic for a list of the type of gateways. Oracle recommends that you use an IAM policy to allow only network administrators to create or modify VCN gateways.

• Carefully consider allowing internet access to any instances. For example, you don't want to accidentally allow internet access to sensitive database instances. In order for an instance in a VCN to be publicly accessible from the internet, you must configure the following VCN options:

  • The instance must be in a VCN public subnet.
  • The VCN containing the instance must have an internet gateway enabled and configured to be the routing target for outbound traffic.
  • The instance must have a public IP address assigned to it.
  • The VCN security list for the instance's subnet must be configured to allow inbound traffic from 0.0.0.0/0. Or if you're using network security groups (NSG), the instance must be in an NSG that allows that traffic.
• VPN IPSec provides connectivity between a customer's on-premises network and VCN. You can create two IPSec tunnels for high availability. For more information about creating VPN tunnels to connect VCN DRG to customer CPEs, see Site-to-Site VPN.
• FastConnect peering allows you to connect your on-premises network to your VCN with a private circuit so that the traffic does not traverse the public internet. You can set up private peering (to connect to private IP addresses), or public peering (to connect to Oracle Cloud Infrastructure public endpoints, such as for Object Storage). For more information about FastConnect peering options, see FastConnect.

Virtual Security Appliances in a VCN

• The Networking service lets you implement network security functions such as intrusion detection, application-level firewalls, and NAT (although you can instead use a NAT gateway with your VCN). You can do this by routing all the subnet traffic to a network security host, using route table rules that use a local VCN private IP address as a target. For more information, see Using a Private IP as a Route Target. For high availability, you can assign the gateway security host a secondary private IP address, which you can move to a VNIC on a standby host in case of primary host failure. Full network packet capture or network flow logs can be captured on the NAT instances using tcpdump, and the logs can be uploaded periodically to an Object Storage bucket.

• Virtual security appliances can be run as virtual machines (VMs) on a bring-your-own-hypervisor (BYOH) model on a bare metal instance. Virtual security appliance VMs running on the BYOH bare metal instance each have their own secondary VNIC, giving direct connectivity to other instances and services in the VNIC's VCN. For information about enabling BYOH on a bare metal instance using an open-source KVM hypervisor, see Bringing Your Own Hypervisor Guest OS.
• Virtual security appliances can also be installed on compute virtual machines (VMs) where VMDK or QCOW2 images of security appliances can be imported using the bring your own image (BYOI) feature. However, due to infrastructure dependencies, the BYOI feature might not work for some appliances, in which case the BYOH model would be another option to use. For more information about importing appliance images into Oracle Cloud Infrastructure, see Bring Your Own Image (BYOI).

Load Balancers

• Oracle Cloud Infrastructure load balancers enable end-to-end TLS connections between a client's applications and a customer's VCN. The TLS connection can be terminated at an HTTP load balancer, or on a back-end server by using a TCP load balancer. The load balancers use TLS1.2 by default. For information about configuring an HTTPS listener, see Listeners for Load Balancers. You can also upload your own TLS certificates. For more information see SSL Certificates for Load Balancers.
• You can configure network access to load balancers by using VCN network security groups or security lists. This method provides similar functionality to traditional load balancer firewalls. For public load balancers, Oracle recommends that you use a regional public subnet (for example, DMZ subnet) for instantiating the load balancers in a highly available configuration across two different availability domains. You can configure the load balancer firewall rules by setting up the load balancer's network security groups or the subnet's security lists. For more information about creating load balancer security lists, see Update Load Balancer Security Lists and Allow Internet Traffic to the Listener. Similarly, you must configure the VCN network security groups or security lists for the backend servers to limit traffic only from the public load balancers. For more information about configuring backend server security lists, see Update Rules to Limit Traffic to Backend Servers.

DNS Zones and Records

DNS zones and records are critical for accessibility of web properties. Incorrect updates or unauthorized deletions could result in outage of services, accessed through the DNS names. Oracle recommends that you limit IAM users who can modify DNS zones and records.

DNS Traffic Management Steering Policies

Incorrect updates or unauthorized deletions to DNS traffic management steering policies could result in outage of services due to traffic misdirection or failover failure. Oracle recommends that you limit IAM users who can modify DNS traffic management steering policies.