Enabling Network Traffic to Ubuntu Images in Oracle Cloud Infrastructure

July 4, 2022 | 5 minute read
Text Size 100%:

Security plays a very important role in cloud computing, and Oracle Cloud Infrastructure (OCI) is no exception. Rather than allowing traffic to flow freely between network segments, administrators need to make the conscious decision which network traffic to allow. This includes inter-subnet, intra-subnet traffic as well as the correct implementation of the host firewall.

A Small Sample Application

Purely discussing how to change the host-firewall on Ubuntu would have resulted in a lot of missing context. Host firewalls on their own are of little use in cloud deployements, they need to be seen in the wider context of an application. Please consider the following architecture diagram of a basic application provided by Tomcat running on Ubuntu 22.04 in OCI:

Network architecture diagram

In a nutshell, the architecture diagram features

  • a publicly accessible load balancer providing the entry point to the application
  • a Java application running in a couple of highly available Apache Tomcat instances in the private “application” subnet
  • an Autonomous Database in the backend, or "database" subnet

Network Security Considerations

For the above application to work as expected several network and host firewall rules have to be set. For the sake of keeping this article short, only those rules and settings pertaining to the load balancer and Tomcat hosts are discussed. Setting the rules for the database subnet is left as an exercise to the reader.

OCI offers Network Security Groups (NSGs) and Security Lists to manage traffic between subnets.

In addition to network traffic management between subnets another layer of protection exists in the form of host firewalls. By default VM instances are limited by their host firewalls to accepting SSH traffic only.

For network requests to be completed successfully ports need to be opened in a NSG or Security List and additionally on the host.

Security Lists

The application layout isn't very complex, and rather than using NSG the architects decided to use Security Lists instead. They defined 1 Security List per subnet:

  • lb_subnet_sl
  • app_subnet_sl
  • db_subnet_sl

The load balancer subnet's security list (lb_subnet_sl) must define rules for ingress on part 443 (HTTPS). Since Tomcat is behind the load balancer and therefore not publicly accessible the architects decided that TLS termination at the load balancer is sufficient. In other words, traffic between the load balancer and the Tomcat instances is unencrypted. Whilst fine for this little demo application there are good reasons for end-to-end encryption for your entire application. Guidance on whether network traffic should be end-to-end encrypted can be provided by the IT Security department. Getting approval from IT security is an important milestone in any cloud project and must be obtained as part of the go-live process.

Summary of security rules for lb_subnet_sl

  • Ingress: port 443 (HTTPS) open to the consumers of the application
  • Egress: port 8080 to allow (unencrypted) communication with the Tomcat instances in the application subnet

The application subnet's Security List is even simpler: all it has to do is allow incoming traffic from the load balancer. SSH traffic can optionally be allowed as well for troubleshooting and managing the hosts via configuration mangement tools.

Summary of security rules for app_subnet_sl

  • Ingress:
    • port 8080 open to requests from the load balancer subnet
    • optionally port 22 open to the Bastion Service in the same subnet
  • Egress: optionally port 22 allow outbound SSH traffic

After network traffic rules are created for the Virtual Cloud Network (VCN) the next step is to configure the firewall on the Ubuntu hosts.

Host Firewall

Traditionally Ubuntu hosts use the Uncomplicated Firewall (UFW) as a user-friendly interface to manage the iptables configuration. As explained in the OCI Best Practices documenation page the use of UFW is discouraged because it can lead to serious trouble. UFW is therefore disabled by default. This might catch experienced admins by surprise if they try to open ports via UFW but don’t succeed connecting to the application and cause issues along the way.

Rather than using UFW, a more direct manipulation of the iptables configuration is necessary. The easiest way to do so is modifying /etc/iptables/rules.v4. The easiest way is to copy the line allowing SSH access and modify the newly copied line to accept traffic for port 8080:

-A INPUT -p tcp -m state --state NEW -m tcp --dport 8080 -j ACCEPT

Please ensure the previous line allowing SSH access is still in place or you will be locked out of your system. The line that absolutely has to remain intact reads:

-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT

Once the rule is added it can be enabled using the following command:

$ sudo iptables-restore < /etc/iptables/rules.v4

In the case there aren't any further changes to the rules file the INPUT chain is comprised of the following rules after iptables-restore completed:

$ sudo iptables -L INPUT
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
ACCEPT     icmp --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     udp  --  anywhere             anywhere             udp spt:ntp
ACCEPT     tcp  --  anywhere             anywhere             state NEW tcp dpt:ssh
ACCEPT     tcp  --  anywhere             anywhere             state NEW tcp dpt:http-alt
REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited

Note that the last rule rejects any further connection attempts not allowed before. The new rule for Tomcat is listed right after the SSH rule, http-alt maps to port 8080 as you can see in /etc/services.

Summary

Ubuntu images in OCI don't rely on UFW for changing the host firewall configuration. Opening ports requires changing the iptables configuration by editing /etc/iptables/rules.v{4,6}. It is important not to add the new iptables rule at the end of the file or else it will be ignored due to the earlier REJECT rule's higher precendence. The error message returned to the caller ("no route to host") can be misleading.

Martin Bach

Martin is a product manager at Oracle helping customers in Europe and around the world address their IT related problems. He is most interested in cloud technology, DevOps and how these can be used best with Oracle technology.


Previous Post

SSL Connection to Oracle DB using JDBC, TLSv1.2, JKS or Oracle Wallets (12.2 and lower)

Nirmala Sundarappa | 5 min read

Next Post


How to setup auto assignment of Service Request to Queue in Oracle B2B Service

Sreejith Sreekumar | 5 min read