Oracle Cloud Infrastructure Documentation

Security Lists

In addition to using IAM An IAM document that specifies who has what type of access to your resources. It is used in different ways: to mean an individual statement written in the policy language; to mean a collection of statements in a single, named "policy" document (which has an Oracle Cloud ID (OCID) assigned to it); and to mean the overall body of policies your organization uses to control access to resources. to control who can manipulate your VCN (for example, add an internet gateway, change route table rules), you can use security lists to control traffic at the packet level.

Warning

Avoid entering confidential information when assigning descriptions, tags, or friendly names to your cloud resources through the Oracle Cloud Infrastructure Console, API, or CLI.

Overview of Security Lists

A security list provides a virtual firewall for an instance, with ingress and egress rules that specify the types of traffic allowed in and out. Each security list is enforced at the instance level. However, you configure your security lists at the subnet level, which means that all instances in a given subnet are subject to the same set of rules. The security lists apply to a given instance whether it's talking with another instance in the VCN or a host outside the VCN.

Each subnet can have multiple security lists associated with it, and each list can have multiple rules (for the maximum number, see Service Limits). A packet in question is allowed if any rule in any of the lists allows the traffic (or if the traffic is part of an existing connection being tracked). There's a caveat if the lists happen to contain both stateful and stateless rules that cover the same traffic. For more information, see Stateful vs. Stateless Rules.

Important

Your instances running Oracle-provided Linux images or Windows images also have firewall rules that control access to the instance. When troubleshooting access to an instance, make sure both the security lists associated with the instance's subnet and the instance's firewall rules are set correctly. For more information, see Oracle-Provided Images.

If your instance is running Oracle Linux 7, you need to use firewalld to interact with the iptables rules. For your reference, here are commands for opening a port (1521 in this example):

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

Security lists are regional entities. For the limit on the number of security lists you can have in a VCN, see Service Limits.

Note

Security lists are not enforced for traffic involving the 169.254.0.0/16 CIDR block, which includes services such as iSCSI and instance metadata.

Stateful vs. Stateless Rules

When you create a security list rule, you choose whether it's stateful or stateless. The difference is described below. The default is stateful. Stateless rules are recommended if you have a high-volume internet-facing website (for the HTTP/HTTPS traffic).

Stateful Rules

Marking a security list rule as stateful indicates that you want to use connection tracking for any traffic that matches that rule (for instances in the subnet the security list is associated with). 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 more details, see Connection Tracking Details for Stateful Rules.

The figure below illustrates a stateful ingress rule for an instance that needs to receive and respond to HTTP traffic. Instance A and Host B are communicating (Host B could be any host, whether an instance or not). 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.

Stateful ingress rule allowing incoming HTTP traffic and response

Stateless Rules

Marking a security list rule as stateless indicates that you do NOT want to use connection tracking for any traffic that matches that rule (for instances in the subnet the security list is associated with). This means that response traffic is not automatically allowed. To allow the response traffic for a stateless ingress rule, you must create a corresponding stateless egress rule.

The next figure shows Instance A and Host B as before, but now with stateless security list rules. As with the stateful rule above, 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).

Stateless ingress and egress rules allowing incoming HTTP traffic and response

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.

Stateless ingress and egress rules allowing instance to initiate HTTP traffic and get response

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.

Note

If for some reason your security lists contain both stateful and stateless rules, and there's traffic that matches both a stateful and stateless rule in a particular direction (for example, ingress), the stateless rule takes precedence and the connection is not tracked. You would need a corresponding rule in the other direction (for example, egress, either stateless or stateful) in order for the response traffic to be allowed.

Enabling Path MTU Discovery Messages for Stateless Rules

If you decide to use stateless security list rules to allow traffic to/from endpoints outside the VCN, it's important to add a security list 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.

Default Security List

Each cloud network has a default security list. A given subnet automatically has the default security list associated with it if you don't specify one or more other security lists during subnet creation. At any time after you create a subnet, you can change which security lists are associated with it. And you can change the rules in the lists.

Unlike other security lists, the default security list comes with an initial set of stateful rules, which you can change:

  • Stateful ingress: Allow TCP traffic on destination port 22 (SSH) from source 0.0.0.0/0 and any source port. This rule makes it easy for you to create a new cloud network and public subnet, launch a Linux instance, and then immediately connect via SSH to that instance without needing to write any security list rules yourself.

    Important

    The default security list does not include a rule to allow Remote Desktop Protocol (RDP) access. If you're using Windows images, make sure to add a stateful ingress rule for TCP traffic on destination port 3389 from source 0.0.0.0/0 and any source port.

    See To enable RDP access for more information.

  • Stateful ingress: Allow 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.

  • Stateful ingress: Allow ICMP traffic type 3 (all codes) from source = your VCN's CIDR and any source port. This rule makes it easy for your instances to receive connectivity error messages from other instances within the VCN.
  • Stateful egress: Allow all traffic. This allows instances to initiate traffic of any kind to any destination. Notice that this means the instances with public IP addresses can talk to any internet IP address if the VCN has a configured internet gateway. And because stateful security rules use connection tracking, the response traffic is automatically allowed regardless of any ingress rules. For more information, see Connection Tracking Details for Stateful Rules.

The default security list comes with no stateless rules. However, you can add or remove rules from the default security list as you like.

Parts of a Security List Rule

Each security list can contain one or more rules, and each rule allows either ingress or egress traffic. You choose whether the rule is stateful or stateless. For examples of rules, see Stateful vs. Stateless Rules, and see Typical Networking Scenarios. For the limit on the number of rules you can have in a security list, see Service Limits.

Each ingress rule specifies the following:

  • Stateful or stateless: If stateful, connection tracking is used for traffic matching the rule. If stateless, no connection tracking is used. See Stateful vs. Stateless Rules.
  • Source Type: Possible values:
    • CIDR: The typical choice.
    • Service CIDR: Only for traffic coming through a service gateway from a public Oracle Cloud Infrastructure service such as Object Storage.
  • Source CIDR: Only if the Source Type is CIDR. This is a CIDR block where the traffic originates from. Use 0.0.0.0/0 to indicate all IP addresses. The prefix is required (for example, include the /32 if specifying an individual IP address).
  • Source Service: Only if the Source Type is Service CIDR. If you're using the Console, this is simply the service you're interested in. If you're using the API, this is the CIDR label for the service. For example: oci-phx-objectstorage. The string represents the IP address endpoints for a given service in a given region.
  • IP Protocol: Either a single IPv4 protocol or "all" to cover all protocols.
  • Source port: The port where the traffic originates from. For TCP or UDP, you can specify all source ports, or optionally specify a single source port number, or a range.
  • Destination port: The port where the traffic is destined to. For TCP or UDP, you can specify all destination ports, or optionally specify a single destination port number, or a range.
  • ICMP type and code: For ICMP, you can specify all types and codes, or optionally specify a single type with an optional code. If the type has multiple codes, create a separate rule for each code you want to allow.

Each egress rule specifies the following:

  • Stateful or stateless: Whether connection tracking is used for the traffic matching the rule. See Stateful vs. Stateless Rules.
  • Destination Type: Possible values:
    • CIDR: The typical choice.
    • Service CIDR: Only for traffic going through a service gateway to a public Oracle Cloud Infrastructure service such as Object Storage.
  • Destination CIDR: Only if the Destination Type is CIDR.This is the CIDR block where the traffic is destined to. Use 0.0.0.0/0 to indicate all IP addresses. The prefix is required (for example, include the /32 if specifying an individual IP address).
  • Destination Service: Only if the DestinationType is Service CIDR. If you're using the Console, this is simply the service you're interested in. If you're using the API, this is the CIDR label for the service. For example: oci-phx-objectstorage. The string represents the IP address endpoints for a given service in a given region.
  • IP Protocol: Either a single IPv4 protocol or "all" to cover all protocols.
  • Source port: The port where the traffic originates from. For TCP or UDP, you can specify all source ports, or optionally specify a single source port number, or a range.
  • Destination port: The port where the traffic is destined to. For TCP or UDP, you can specify all destination ports, or optionally specify a single destination port number, or a range.
  • ICMP type and code: For ICMP, you can specify all types and codes, or optionally specify a single type with an optional code. If the type has multiple codes, create a separate rule for each code you want to allow.

For instructions on working with security lists and rules, see the sections that follow.

Connection Tracking Details for Stateful Rules

Oracle uses connection tracking to allow responses for traffic that matches stateful rules (see Stateful vs. Stateless Rules). Each instance has a maximum number of concurrent connections that can be tracked, based on the instance's A template that determines the number of CPUs and the amount of memory allocated to a newly created instance..

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)
Note

For other protocols, Oracle tracks only the protocol and IP addresses, and not the ports. This means that when an instance initiates traffic to another host and that traffic is allowed by egress security list rules, any traffic that the instance subsequently receives from that host for a period is considered response traffic and is allowed.

Rules to Handle Fragmented UDP Packets

Instances can send or receive UDP traffic. If a UDP packet is too large for the connection, it is fragmented. However, only the first fragment from the packet contains the protocol and port information. If the security list rules that allow this ingress or egress traffic specify a particular port number (source or destination), the fragments after the first one are dropped. If you expect your instances to send or receive large UDP packets, set both the source and destination ports for the applicable security list rules to ALL (instead of a particular port number).

Required IAM Policy

To use Oracle Cloud Infrastructure, you must be given the required type of access in a An IAM document that specifies who has what type of access to your resources. It is used in different ways: to mean an individual statement written in the policy language; to mean a collection of statements in a single, named "policy" document (which has an Oracle Cloud ID (OCID) assigned to it); and to mean the overall body of policies your organization uses to control access to resources. written by an administrator, whether you're using the Console or the REST API with an SDK, CLI, or other tool. If you try to perform an action and get a message that you don’t have permission or are unauthorized, confirm with your administrator the type of access you've been granted and which A collection of related resources that can be accessed only by certain groups that have been given permission by an administrator in your organization. you should work in.

For administrators: The policy in Let network admins manage a cloud network covers management of all Networking components, including security lists.

If you have security admins who need to manage security lists but not other components in Networking, you could write a more restrictive policy:

Allow group SecListAdmins to manage security-lists in tenancy

Allow group SecListAdmins to manage vcns in tenancy

Both statements are needed because the creation of a security list affects the VCN the security list is in. The second statement also allows the SecListAdmins group to create new VCNs, but not create subnets or manage any other components related to any of those VCNs, except for the security lists. The group also can't delete any existing VCNs that already have subnets in them.

For more information, see IAM Policies for Networking.

Working with Security Lists

When you create a new subnet, you must associate at least one security list with it. It can be either the cloud network's default security list or one or more other security lists that you've created (for the maximum number, see Service Limits). You can change which security lists the subnet uses at any time.

You may optionally assign a friendly name to the security list during creation. It doesn't have to be unique, and you can change it later. Oracle automatically assigns the security list a unique identifier called an Oracle Cloud ID (OCID). For more information, see Resource Identifiers.

For the purposes of access control, you must specify the compartment where you want the security list to reside. Consult an administrator in your organization if you're not sure which compartment to use. For more information, see Access Control.

You can add and remove rules from the security list, but notice that when you update a security list in the API, the new set of rules replaces the entire existing set of rules.

To delete a security list, it must not be associated with a subnet yet. You can't delete a cloud network's default security list.

Tagging Resources

You can apply tags to your resources to help you organize them according to your business needs. You can apply tags at the time you create a resource, or you can update the resource later with the desired tags. For general information about applying tags, see Resource Tags.

Using the Console

To view a cloud network's default security list
To update rules in an existing security list
To create a new security list
To change which security lists a subnet uses
To delete a security list
To manage tags for a security list

Using the API

For information about using the API and signing requests, see REST APIs and Security Credentials. For information about SDKs, see Software Development Kits and Command Line Interface.

To manage a VCN's security lists, use these operations:

This topic has moved. If you are not redirected in 2 seconds, click the following link: Security Lists.