Host-Based Firewalls for Cloud Based Systems

Are host-based firewalls still relevant for Cloud-based systems?

Cloud providers offer many features and components aimed at covering as many use-cases as possible for their clients. Most, if not all of these features are software-defined.

One such feature that is offered by the biggest cloud providers to their clients is a Virtual Firewall. In AWS cloud, this feature is referred to as Security Groups (sg). A security group acts as a virtual firewall for your instance to control inbound and outbound traffic[1].

For example, an administrator could create a security group for web servers at her company and conveniently name it “web-security-group”. This sg would allow ingress traffic for port 80/tcp and 443/tcp (typical web traffic ports). The sg would then be attached to instances that fall in the category of web servers. That’s all there is to it really.

To make this workflow more predictable, cloud providers disable the default vendor distributed host-based firewall. This among other operational needs allows you to for example connect to a freshly built Windows instance over a remote desktop connection. Microsoft distributes Windows systems with a firewall “Windows Firewall” that by default blocks all inbound traffic, including remote desktop. Linux systems, on the other hand, depending on distribution, will ship with iptables a Netfilter configurator.

So back to the question, are host-based firewalls still relevant, especially since cloud providers already offer virtual firewalls, sometimes even easier to configure?

To answer this question, I will introduce the concept of Defense in Depth (DiD). Defence in Depth is the implementation of multiple layers of security controls in a system to provide redundancy in the event a security control fails or a vulnerability is exploited[2]. When implementing this security approach, we assume we are going to get attacked or a security control will fail due to any number of factors like human error, system failure etc. The DiD approach ensures that if one or more of our controls fail, we are not left exposed to other threats.

Going back to the example we used before, we have our security group created and attached to our webservers. Suppose a new webserver running Tomcat server software is added to this group of web servers? Tomcat by default runs on port 8080, so to accommodate Tomcat, another administrator adds port 8080 inbound to our “web-security-group” security group. What the administrator has inadvertently done is allow inbound traffic for port 8080 to reach the other webservers that exist in this group. If this site had followed the DiD approach and enforced host-based firewalls then the security group miss-configuration would have had no immediate impact. Even with the best controls and change management procedures in place, mistakes like these, happen more than you think.

But what about the operational challenges of managing iptables and Windows firewall rulesets? In some environments, engineers are getting crazy just configuring security groups. Well, that’s why we have configuration management systems. These tasks can easily be automated and managed more efficiently using these systems. Both Ansible and Puppet have very mature firewall modules for iptables and Windows firewalls. Am certain other configuration management tools have these modules as well.

In conclusion, yes, host-based firewalls are still relevant and should be considered as an extra layer of security for your cloud-based systems. As we have seen, a well-meaning change can leave your systems exposed to attacks.

References

[1] https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html

[2] https://www.cyber.gov.au/acsc/view-all-content/glossary/defence-depth