In OCI we create VCN for instances, load balancers, and other resources to connect to each other and the internet. In a VCN we create two subnets, public subnet & private subnet, which is for security and traffic management. Private backend servers are deployed in a private subnet to ensure they cannot be directly routed to the internet. However, we also cannot access them directly because when an instance is created in a private subnet, it is assigned only a private IP. To log in to an instance, we require both a public IP and a private key. In networking we have a concept of Jump Server/Bastion server which is a secure instance in which administrator login first, and then make a secondary connection to that private backend server. We create Bastion server in public subnet which provide us with private ip & public ip due to which we can successfully login.

Security List

By default OCI's network security operates on a strict default deny model, which simply means we cannot send or receive traffic using a compute instance and this is also true for local routing (instance to instance) as well as external routing (internet).

• examples of local routing

  • instances in same subnet (private/public)
  • instances in different subnets in same VCN (private subnet & public subnet)
  • instances in different VCN

Security List acts as a virtual firewall for an instance that controls incoming (ingress) and outgoing (egress) traffic for all VNICs within an associated subnet. We create security list on the subnet level, due to which every instance associated with that subnet inherit that security list. However, the actual packet filtering and enforcement happen at the individual VNIC level; hence, the instance is completely isolated from everything including other instances in its own subnet, unless a Security List explicitly permits the traffic.

Parameters of Security List

1. Direction of traffic

   • Ingress Rule: This rule defines what external traffic is allowed to enter the instances in the subnet.

   • Egress Rule: This rule defines what internal traffic is allowed to leave the instances in the subnet.

2. Statefulness

   • Stateful (Default): The virtual firewall uses connection tracking and due to the connection tracking OCI automatically allows the return traffic.

   • Stateless: The virtual firewall does not track connections; hence, instances do not expect return traffic. Stateless rules process faster and are used for high-volume endpoints like Load Balancers to prevent exhausting connection-tracking memory.

3. Addressing

   • Source CIDR: It is used in Ingress rules, it specifies the IP address range where the traffic is originating from (e.g., 0.0.0.0/0 for the whole internet, or 10.0.1.0/24 for a specific internal subnet).

   • Destination CIDR: It is used in Egress rules, it specifies the IP address range where the traffic is allowed to go.

4. Protocols and Ports

   • IP Protocol: It is the transport mechanism used for transmission of data between servers and between server and end-user. The most common protocols are Transmission Contol Protocol (TCP), User Datagram Protocol (UDP), and Internet Control Message Protocol (ICMP).

   • Destination Port Range: The specific port of the receiving side on which the traffic is trying to reach (e.g., 22 for SSH, and 443 for HTTPS)

   • Source Port Range: The specific port of the end user's device where the traffic is originating from. We almost always leave it blank (set to All)

   • ICMP Type and Code: While using the ICMP protocol, ports do not apply, instead we specify the type of diagnostic message (e.g., 0, 3, 5)

---

Connection Tracking: The virtual firewall maintains a dynamic ledger in its memory called a state table. When a user's browser sends a request to our server at a particular port, the firewall checks subnet's security list and if it finds an ingress rule associated with that port then it allows the traffic to enter the server and parallelly firewall writes down the state of that connection in its memory where it records user's IP address, server's IP address, the protocol, and the specific port. When the server processes the request and sends back the response it first hit the firewall, and firewall does not even look at the egress rules instead it check the state table and dynamically allows the traffic to leave the server and finally the end-user's browser receives the response. Once the conversation is finished (the connection closes) or times out, the firewall deletes that entry from its memory.

---