Securing The Network
This section focuses on the mechanisms, tools and guidance to ensure that only permitted traffic is allowed in and out of your VCN’s and subnets within the OCI network.
There are three principal tools used for doing this;
Routing Tables
By default, hosts within different VCN’s are not routable to each other.
To be routable, each VCN must be attached to a Dynamic Router Gateway (DRG). This may be the same DRG or a completely different DRG (even in a separate tenancy). In addition to being attached to DRG’s, the VCN’s and the DRG’s themselves must have routing tables configured appropriately.
A router uses routing tables to forward a network packet to its final destination. Routing tables contain information that specifies where the router should reach out to next for a given destination. The DRG can then pass the packet forward. There may be multiple hops required for a packet to finally reach its destination.
Routing tables need to be configured whenever packets need to leave a VCN or whenever packets need to arrive into a VCN (from elsewhere in OCI, On-premises, or 3rd party clouds).
Routing tables are defined in two places; at the VCN and at the DRG.
Imagine the following simple scenario;
Host 1 wants to send a network packet to Host 2. Each host is in a different subnet and VCN from each other. Each VCN is attached to the same DRG.
The routing path would look something like this;
If Host 1 and Host 2 happen to be in the same VCN, or even the same subnet, there would be no need to use a routing table (hosts within a VCN are automatically routable). But, because Host 2 is in a different VCN to Host 1, Host 1’s VCN needs to know where it should forward the packet to so that it can reach its destination.
The routing table in V1 needs to contain an entry that looks something like this;
| Destination | Target Type | Target |
|---|---|---|
| Subnet 2 | VCN Attachment | VCN 2 |
This specifies that any packet destined for a host in subnet S2 should be forwarded to VCN V2.
There would also need to be corresponding entries in the DRG and VCN routing tables going in the other direction (i.e. Host 2 -> Host 1).
This is a simple scenario. However, the principle is essentially the same for all types of routing. This approach also applies to routing for access to an Internet Gateway, NAT Gateway or Service Gateway.
From this description, you can see that Routing Tables are an essential tool in providing access to network resources and denying access to them. Routing tables must be configured only by authorised network administrators. It is also clear how vital the compartment structure design is in delivering the appropriate level of access and restriction for such critical network administration. For more information on this, please review the Control & Governance section of The Cloud Foundation.
Important:
The greater the degree of separation and segmentation that has been designed into the network topology, the greater the complexity and management overhead of maintaining routing tables.
This is a good illustration of balancing the need for separation and simplicity by grouping closely associated applications and workloads.
Security Lists
Security Lists act as a virtual firewall to allow and deny certain types of traffic to be forwarded to hosts within a subnet. In the absence of a subnet specific Security List, each subnet inherits the default Security List defined at the VCN level.
The default VCN Security List permits the following;
Ingress
- TCP on Port 22 (SSH)
- ICMP traffic type 3 code 4
- ICMP traffic type 3 (all codes) from within the VCN’s CIDR block
Egress
- Allow all traffic
You can see then that even if hosts reside in the same VCN, and by default, are routable to each other, only minimal ingress traffic is allowed by default.
Our recommendation is to place application tiers (database, mid-tier, web) in their own subnets and only open those ports and traffic types that are explicitly needed for the application to function.
Important:
Because all hosts within a subnet are subject to the same Security List rules, subnets must only contain hosts with the same security posture.
Just as for Routing Tables, the administration of Security Lists is a highly privileged role and should be restricted appropriately.
Network Security Groups
Network Security Groups (NSG) offer the same fundamental functionality as Security Lists, except they deliver extra flexibility in when Ingress and Egress rules are applied.
For Security Lists, all of the hosts within a subnet are subject to the same rules. This means that you must, or at least should, define subnet membership according to each subnet host requiring the same security posture.
With NSGs, individual VNICs become the target of the ingress and egress rules rather than whole subnets. This means that you are then free to combine hosts with differing security postures within the same subnet.
In essence, NSG’s separate the VCN’s subnet architecture from the application security requirements.
Membership of an NSG is defined at the resource level (compute instance etc.).
It is possible to specify ingress and egress rules between different NSG’s regardless of which subnet within the VNC they belong. This allows resources of the same type (e.g. mid-tier hosts) to be treated in a consistent manner and means that communication between types (e.g. mid-tier and databases) is also controlled in a consistent manner.
The rules expressed within an NSG are applied in addition to the rules contained within the default subnet Security Lists. Hosts can belong to multiple NSG’s. This can be very useful in allowing you to layer rules on top of each other to provide different levels of consistent security rules. This could be used for instance, where multiple different resources belong to the same subnet. All resources could be subject to a baseline set of rules, whereas a subset could be subject to more significant restrictions.
Tip:
Because of their flexibility, we generally recommend the use of NSGs over Security Lists wherever practicable.