Do host firewalls matter in cloud deployments?

Cloud deployments enable incredible amounts of network flexibility for any workload. Companies build, connect, and configure networks at a rapid pace via convenient application programming interfaces (APIs). However, these easily configurable interconnections lead to situations where dangerous network paths remain open due to misconfiguration or complexity.

Someone asked me recently if host firewalls still matter in cloud deployments. In short: they do still matter. Host firewalls, such as iptables or nftables, play a key role in a defense-in-depth strategy, and they often close gaps in critical network infrastructure. Red Hat Enterprise Linux (RHEL) includes firewalld, a firewall management framework, that delivers reasonable defaults and makes rule management easy.

This post covers some potential scenarios where a host firewall could reduce risk in a cloud deployment.

Protection from configuration changes

Network configurations in clouds evolve rapidly. A series of API calls have replaced trips to the datacenter with a network architect. Developers now wield the power to change systems outside the application itself, including the networking stack.

More changes often lead to misconfigurations, especially for organizations that lack a robust testing strategy for their workloads. These could include:

• Removing rules temporarily to diagnose a problem and forgetting to reset them.

• Migrating to another region or zone with different network security capabilities.

• Old versions of network configuration applied through a continuous integration/continuous delivery (CI/CD) system.

A basic set of firewall rules reduces the risk from these changes. Start by taking an inventory of the applications running on the system and identifying which should be exposed. Adjust the firewall rules down to only those services. Further tighten down the rules by identifying which external systems must access the service and limit access to those networks.

Work around cloud provider feature gaps

Each cloud provider provides different capabilities in its networking stack. Some allow for extremely granular control on each instance and each network segment. Some support IPv4 only, while others support dual-stack networks. These varying capabilities lead to challenges in multicloud deployments, but host firewalls fill in these gaps.

Most Linux instances will set up a link local address for basic IPv6 connectivity even if the underlying network is IPv4 only. This opens up a new, often overlooked, network path. The cloud provider may offer network security solutions that only operate with IPv4 addresses and this leaves IPv6 connectivity wide open for an attacker.

The firewalld manager provides a method for dealing with IPv4 and IPv6 consistently on each system. Opening and closing ports happens on both stacks at the same time without ensuring the same changes are made via iptables and ip6tables. 

Avoid lateral movement from a successful attack

Experienced information security professionals always say “it’s not a matter of ‘if’, but ‘when’” an attack will succeed in your deployment. Once an attacker gets inside, you want to limit lateral movement. For example, if an attacker gains access to a monitoring system, how do you prevent them from moving to other instances in your deployment? What if they acquired your API keys for your cloud provider?

Host firewalls help here by providing that extra layer of defense. An attacker could use stolen API credentials to remove security restrictions on the network, but if your instance already has limited access defined in the host firewall, their ability to move is greatly reduced.

If an attacker tries to move laterally in your environment and you can’t defend against it well, at least make it noisy when they try to move around. Turn your attacker into a bull in a china shop with logging on your host firewalls. 

Add rules to log any traffic that is not explicitly allowed. Feed those logs into an alerting or monitoring system and identify attacker movement quickly. Enable this in firewalld by changing the LogDenied parameter in /etc/firewalld/firewalld.conf.

Egress traffic also sheds light on a potential compromise. Consider a database server that should never access something outside your deployment. Limit egress traffic via the cloud provider’s network configuration and add host firewall logging for outbound traffic on the database instance. If something suddenly tries to make plenty of outbound connections, you know about the problem quickly.

Summary

Host firewalls provide a valuable layer of a strong defense-in-depth strategy. Using firewalld in RHEL allows administrators to quickly configure a host firewall that consistently handles dual-stack networks, allows for detailed traffic logs, and closes gaps in cloud provider network implementations. RHEL System Roles allow you to consistently apply firewall configuration across your entire fleet.

Need to take a few steps back to determine whether you should migrate applications to the cloud? Read our tips on how to decide.