Hello. Welcome to this
demonstration on Virtual Cloud Network, or VCN, Security Lists in Oracle Cloud Infrastructure.
The Security List is a collection of rules applied to the subnets of a VCN
for controlling ingress and egress traffic to and from any virtual network interface cards,
or VNICs, attached to the subnet. It acts a type of virtual
firewall for the VNIC. All VNICs attached to the subnet
have the same rules applied to their traffic. The rules in the list identify types of traffic
connections based on protocols, IP addresses and ports.
Once traffic has been identified using the parameters of a rule, it can be allowed.
If no rule exists to identify traffic, then the traffic is dropped.
A security list and its rules is a resource that belongs to a VCN and is applied to its subnets.
There is a default Security List created for every new VCN.
This default list has rules to allow ingress SSH connections and limited ICMP ping tests,
as well as a allowing all egress traffic. Additional rules need to be created to support
any other connections types that are needed. In addition to the Default Security List,
you can create additional Security Lists and apply them as needed to subnets.
Security List rules are either stateful or stateless, and ingress or egress network
connection traffic is examined against these rules to identify matches.
Now we will look at a VCN, and its default Security List.
On our web console to look at a security list, we navigate with the menu to Networking,
then Virtual Cloud Networks. We click on the VCN named VCN-192.
The VCN details page defaults to display the list of subnets.
Under Resources, we select Security Lists. We see the default security list that was
automatically created for the VCN. Remember, you can create more security
lists if you wish, and traffic on the subnets will be examined against the rules in all of them.
We click on its name to see its details. Here you see the default ingress rules.
The first rule allows SSH connections on port 22 from anywhere.
The second rule enables instances to receive Path MTU Discovery fragmentation messages.
The third rule makes it easy for instances to receive connectivity error messages from other
instances within the VCN. As this is a working subnet,
scrolling down we see there have been a number of additional ingress rules added over time.
Clicking on Egress Rules, we see there is one default egress rule,
allowing all traffic out of the subnet. This rule allows instances to initiate
network communication for any port and protocol to any IP address.
Returning to the ingress rules list, lets add a rule to the default list to permit
incoming traffic on port 443 to satisfy HTTPS requests of a secure web server.
Click on Add Ingress Rule opens the rule dialog.
By default all rules are stateful, we can choose to make a rule stateless by
selecting the checkbox. Stateful rules are used to
support bi-directional communication. They make use of connection tracking,
which enables an automatic response to a request in either direction.
For example, when an instance receives a request, the response back out is automatically allowed
regardless of any egress rules set. And when an instance sends a request,
the response back to the instance is allowed regardless of any ingress rules set.
TCP and UDP protocol connection tracking is based on identifying the protocol,
IP addresses and ports. All other protocols are
tracked only by protocol and IP address. A stateless rule applies to only one direction,
ingress or egress. A stateless ingress rule
requires a supporting egress rule if the communication is bi-directional.
If traffic matches both a stateless and stateful rule,
the stateless rule will manage the traffic.
Back in our dialog we leave the checkbox unchecked, so we are creating a stateful rule.
We leave the Source type as CIDR, so we will identify to allow IP address from a
source CIDR block range of 192.168.0.0/16. We keep the source protocol identified as TCP,
and we don't care about the source port - that's the port of host making the request.
We identify the destination port the traffic is going to as 443, which is a
port configured for HTTPS connections. We can also input multiple ports,
and ranges of ports in the field, but we just want one for this rule.
In the same dialog we can create multiple rules by clicking on Another Ingress Rule,
but we dont need that. We add a description so we
know what the rule is for in the list of rules, here I type it is a HTTPS rule.
And then click Add Ingress Rules to add the rule to the list.
All new rules get added to the bottom of the list, and as there are many rules already,
we scroll down and click on the arrow for the second page.
Here we see our new rule. Remember, if there is no rule for
traffic we want to allow, then we need to create a rule for it, otherwise it will be dropped.
But we can create wide ranging rules which cover a range of traffic types.
You can edit the security list rule if you need to make changes.
Click on the three dots menu beside the rule.
Here we have the options to Edit or Remove the rule.
Clicking on Edit opens the rule dialog again for us to make modifications.
We dont need to change anything so we click cancel to close it.
Oracle provides an extensive number of resources which you can use to learn
more about this subject and others. Use the links here to find more content
about this video, as well as Oracle Linux and using Linux on Oracle Cloud Infrastructure.
Thats the end of the video. Thanks for watching.