Security Rules

About VNICs and Parent Resources

A VNIC is a Networking service component that enables a networked resource such as a compute instance to connect to a Virtual Cloud Network (VCN). The VNIC determines how the instance connects with endpoints inside and outside the VCN. Each VNIC resides in a subnet in a VCN.

When you create a compute instance, a VNIC is automatically created for the instance in the instance's subnet. The instance is considered to be the parent resource for the VNIC. You can add more (secondary) VNICs to a compute instance. For this reason, an instance's VNICs are displayed prominently as part of a compute instance's related resources in the Console.

There are other types of parent resources that you can create that also result in a VNIC automatically being created. For example: when you create a load balancer, the Load Balancer service automatically creates VNICs for balancing traffic across the backend set. Also, when you create a DB system, the Database service automatically creates VNICs as DB system nodes. Those services create and manage those VNICs for you. For this reason, those VNICs are not readily apparent in the Console the same way VNICs are for compute instances.

To use an NSG, you put VNICs of your choice into the group. However, you typically work with the parent resource when you add a VNIC to the group, not the VNIC itself. For example, when you create a compute instance, you can optionally specify an NSG for the instance. Although you conceptually put the instance in the group, you're actually putting the instance's primary VNIC in the network security group. The group's security rules apply to that VNIC, not the instance. Also, if you add a secondary VNIC to the instance, you can optionally specify an NSG for that VNIC, and the rules apply to that VNIC, not the instance. Note that all the VNICs in a given NSG must be in the VCN that the NSG belongs to.

Likewise, when you put a load balancer in a network security group, you conceptually put the load balancer in the group. But you're actually putting VNICs managed by the Load Balancer service into the network security group.

You manage the VNIC membership of an NSG at the parent resource, and not at the NSG itself. In other words, to add a parent resource to an NSG, you execute the action on the parent resource (by specifying which NSGs the parent resource should be added to). You do not execute the action on the NSG (by specifying which VNICs or parent resources should be added to the NSG). Similarly, to remove a VNIC from an NSG, you execute that action by updating the parent resource, not the NSG. For example, to add an existing compute instance's VNIC to an NSG, you update that VNIC's properties and specify the NSG. For example, with the REST API, you call UpdateVnic. In the Console, you view the instance and then the VNIC of interest, and then edit the VNIC's properties there.

For a list of parent resources that support the use of NSGs, see Support for Network Security Groups.

Network Security Group as Source or Destination of a Rule

There's an important difference in how you can write security rules for NSGs compared to security lists.

When writing rules for an NSG, you can specify an NSG as the source of traffic (for ingress rules) or the traffic's destination (for egress rules). Contrast this with security list rules, where you specify a CIDR as the source or destination.

The ability to specify an NSG means that you can easily write rules to control traffic between two different NSGs. The NSGs must be in the same VCN.

Also, if you want to control traffic between VNICs in a specific NSG, you can write rules that specify the rule's own NSG as the source (for ingress rules) or destination (for egress rules).

For more information, see Overview of Network Security Groups.

REST API Differences

There are a few basic differences in the REST API model for NSGs compared to security lists. For more information, see Using the API.

Default Rules

Your VCN automatically comes with a default security list that contains several default security rules to help you get started using the Networking service. When you create a subnet, the default security list is associated with the subnet unless you specify a custom security list that you've already created in the VCN.

For comparison, the VCN does NOT have a default network security group.

Limits

The two features have different limits. See Service Limits for a list of applicable limits and instructions for requesting a limit increase.

Use Network Security Groups

Oracle recommends using NSGs for components that all have the same security posture. For example, in a multi-tier architecture, you would have a separate NSG for each tier. A given tier's VNICs would all belong to that tier's NSG. Within a given tier, you might have a particular subset of the tier's VNICs that have additional, special security requirements. Therefore you would create another NSG for those additional rules, and place that subset of VNICs into both the tier's NSG and the additional NSG.

Oracle also recommends using NSGs because Oracle will prioritize NSGs over security lists when implementing future enhancements.

Get Familiar with the Default Security List Rules

Your VCN automatically comes with a default security list that contains several default security rules to help you get started using the Networking service. Those rules exist because they enable basic connectivity. Even if you choose not to use security lists or the default security list, get familiar with the rules so you better understand the types of traffic that your networked cloud resources require. You might want to use those rules in your NSGs or any custom security lists that you set up.

The default security list does not include rules to enable ping. If you need to use ping, see Rules to Enable Ping.

Don't Delete Default Security Rules Indiscriminately

Your VCN might have subnets that use the default security list by default. Do not delete any of the list's default security rules unless you've first confirmed that resources in your VCN do not require them. Otherwise, you might disrupt your VCN's connectivity.

Confirm That Your OS Firewall Rules Align with Your Security Rules

sudo firewall-cmd --zone=public --permanent --add-port=1521/tcp
								
sudo firewall-cmd --reload

Use VNIC Metrics to Troubleshoot Packets Dropped Because of Security Rules

The Networking service offers metrics for VNICs, which show the levels of VNIC traffic (packets and bytes). Two of the metrics are for ingress and egress packets that violate security rules and are therefore dropped. You can use these metrics to help you troubleshoot issues related to security rules and whether your VNICs are receiving the desired traffic.

Stateful Rules

Marking a security rule as stateful indicates that you want to use connection tracking for any traffic that matches that rule. This means that when an instance receives traffic matching the stateful ingress rule, the response is tracked and automatically allowed back to the originating host, regardless of any egress rules applicable to the instance. And when an instance sends traffic that matches a stateful egress rule, the incoming response is automatically allowed, regardless of any ingress rules.

For example, you could have a stateful ingress security rule for an instance (Instance A) that needs to receive and respond to HTTP traffic from Host B. Host B could be any host, whether an instance or not. Instance A and Host B are communicating because the stateful ingress rule allows traffic from any source IP address (0.0.0.0/0) to destination port 80 only (TCP protocol). No egress rule is required to allow the response traffic since responses are automatically tracked and allowed.

Stateless Rules

The next figure shows Instance A and Host B as before, but now with stateless security rules. As with the stateful rule in the preceding section, the stateless ingress rule allows traffic from all IP addresses and any ports, on destination port 80 only (using the TCP protocol). To allow the response traffic, there needs to be a corresponding stateless egress rule that allows traffic to any destination IP address (0.0.0.0/0) and any ports, from source port 80 only (using the TCP protocol).

If Instance A needs instead to initiate HTTP traffic and get the response, then a different set of stateless rules are required. As the next figure shows, the egress rule would have source port = all and destination port = 80 (HTTP). The ingress rule would then have source port 80 and destination port = all.

If you were to use port binding on Instance A to specify exactly which port the HTTP traffic would come from, you could specify that as the source port in the egress rule and the destination port in the ingress rule.

Connection Tracking Details for Stateful Rules

Oracle uses connection tracking to allow responses for traffic that matches stateful rules (see Stateful Versus Stateless Rules). Each instance has a maximum number of concurrent connections that can be tracked, based on the instance's shape.

To determine response traffic for TCP, UDP, and ICMP, Oracle performs connection tracking on these items for the packet:

• Protocol
• Source and destination IP addresses
• Source and destination ports (for TCP and UDP only)

Tracked connections are maintained as long as traffic is received for the connection. If a connection idles long enough, it will timeout and be removed. Once removed, responses for a stateful security rule will be dropped. The following table shows the default idle timeouts:

Enabling Path MTU Discovery Messages for Stateless Rules

If you decide to use stateless security rules to allow traffic to/from endpoints outside the VCN, it's important to add a security rule that allows ingress ICMP traffic type 3 code 4 from source 0.0.0.0/0 and any source port. This rule enables your instances to receive Path MTU Discovery fragmentation messages. This rule is critical for establishing a connection to your instances. Without it, you can experience connectivity issues. For more information, see Hanging Connection.