Firewalls with Ubuntu on OCI

Phil Wilkins
Oracle Developers
Published in
3 min readDec 13, 2023

--

Photo by Compare Fibre on Unsplash

When it comes to Linux, it is pretty common for developer machines to have a relatively minimal level of security settings — particularly if you build your own VMs using VirtualBox of WSL2 (Windows Subsystem for Linux). This is great for velocity when testing, coding, and demoing solutions. But it can trip you up when you switch to an out-of-the-box environment that comes with increased security configuration.

Oracle’s Cloud VMs come with a range of choices beyond just Oracle Linux (such as developer favorites like Ubuntu and Centos, newer arrivals such as Alma and Rocky Linux, as well as established workhorses such as RedHat Enterprise Linux). The base images used on Oracle Cloud are sensibly configured to be more secure than a developer environment — although further hardening could be applied once the workload to be run is known.

In the process of quickly putting together a demo, I elected to use Ubuntu on OCI, as that’s the Linux favor I use with my VMs and WSL2. Of course, the extra hardening caught me out. The following details the tweaks I made to make it easy to use for running demos and proof of concept tasks. Note that we don’t recommend doing this for any environment that needs to be continuously running or hold sensitive data.

The most significant change is the use of the Uncomplicated Firewall (ufw), which was deployed with security rules for both inbound and outbound traffic. It is the application of outbound controls that threw me a curve ball (outbound rules are good practice as they reduce the chance of the node accidentally or deliberately being used to disrupt other VMs within the network).

Changing Firewall

I’m no Linux expert and wanted to focus on my demo and the functionality it is intended to illustrate, so I needed to overcome ufw and introduce a firewall configuration that had just enough security i.e., control inbound traffic in a manner that was easy for someone who doesn’t specialize in Linux OS hardening. So we switched to Firewalld, particularly given that ufw didn’t seem to be respecting my attempts at configuration.

Removing ufw

Digging into the issue, we found references to this blog from Martin Bach. The crux of the issue is that ufw doesn’t play nice with IPTable configuration restrictions. To stop ufw we used the command:

sudo ufw disable

sudo apt-get remove ufw

Removing ufw should also see a little bit of space being released from the machine.

To add Firewalld

To introduce the Firewalld, which does work with ip-tables as mentioned in Martin’s blog we used the commands:

sudo apt install firewalld

To then enable the incoming port, we wanted to accept traffic on:

sudo firewall-cmd — zone=public — permanent — add-port=9090/tcp

sudo firewall-cmd –reload

This meant that the firewall would allow the ingress of network traffic on port 9090, which, as it happens, I was using for Fluent Bit forward traffic.

Setting up other configs

A habit I have developed for putting together demos is to bundle any changes to PATH, establishing environment variables, aliases, file permissions, etc., to incorporate the commands into a single shell script — which typically has a name along the lines of xyz-demo-setup.sh. Then, I add a single entry into my shell’s profile file that uses the source command. This can include comments/notes about one-off tasks. The result is:

  • One place to see what I need to do/what was done to setup a demo.
  • Rather than accumulating lots of environment images and associated key files, I create a VM and then work from that script. So I can kill off environments
  • Resetting or trying changes just involves sourcing the script again — rather than needing to do something more substantial.

Again — not good for a more serious environment, but quick and easy, and you know what has been changed from a base environment.

Conclusion

The takeaways from this have been:

  • Don’t use Uncomplicated FireWall (ufw) on OCI.
  • Don’t assume the same OS will have the same conveniences and configurations as the ones you might be used to.
  • Keeping notes as comments in a setup script helps keep everything in one place and is easier to refer back to.

--

--

Phil Wilkins
Oracle Developers

Techie, author, blogger, https://blog.mp3monster.org -- my blog covering tech https://cloud-native.info I work for Oracle, but all opinions are my own.