Are GCP Default Firewall Rules A Security Concern?

Is the default network with the default firewall rules a security concern in Google Cloud Platform?

When creating a new project, GCP will automatically create a default network with a few default firewall rules. By default, these rules are quite lenient and it is advised to not use them in production. The GCP CIS Benchmarks even go as far as advising to delete the default network. In this post, we’ll go over what the rules are, how we can improve them, and how we can create even better ones.

Default Firewall Rules

By default, GCP adds four firewall rules to the default network. On top of the 2 implied firewall rules. (Four if IPv6 is enabled.)

The 2 implied rules are “Allow all egress” and “Deny all egress”. They both have a target of 0.0.0.0 and a priority of 65535. They are implied on all networks and you can’t see, delete or edit them. These rules are the ones GCP will default back to if no other firewall rules are present. They allow any instance to send traffic to any destination but block all incoming requests to them. If you also have IPv6 enabled, 2 extra rules will be implied for the IPv6 range allowing all outgoing traffic and blocking all incoming requests.

Next to these implied rules, the default network will also have 4 firewall rules:

The default-allow-internal rule allows all incoming connections to the instance from any other instance within the same VPC network.

The other 3 rules allow you to use different protocols from your local computer to interact with the Compute Engine instance. default-allow-ssh lets you connect any instance with tools that use the SSH, SFTP or SCP protocol, default-allow-rdp allows you to connect to any instance with Microsoft’s Remote Desktop Protocol and default-allow-icmp allows you to use network tools like ping.

Why You Shouldn’t Use The Default Rules

The firewall rules allow you to spin up a VM and hit the ground running quickly without having to worry about networking and other configurations. However, this means that the rules are very lenient. With the current set-up, every machine connected to the internet is allowed to make SSH, RDP and ping requests to your machine. It doesn’t mean that everyone can use your machine, but everyone can have a try at breaking in.

In the case of the default-allow-ssh rule, your instance is still protected with an ssh key. Password authentication is turned off by default. So in order for an attacker to gain access to your machine, they will have to get their hands on your SSH private key and crack its password. Since your private key shouldn’t leave your machine, the chances of this happening are quite slim. Another attack vector could be exploiting a vulnerability within the SSH agent program running on the server. However, this is one of the most used programs in the world, so if any vulnerability would be discovered, it will be patched quickly. Make sure to turn on automatic security patches on your VM.

The default-allow-rdp rule is less secure by default. RDP on a Windows Server uses password authentication. Since the default settings expose the RDP port to the internet, everyone can try to crack it. It’s recommended to use a very strong password. Or use other hardening techniques we discuss further in this blog post.

default-allow-icmp can be handy for troubleshooting. Can I connect to my VM? Is my VM online? ICMP can also be used by bad actors to map out your network infrastructure, perform a Ping Flood (a kind of Denial of Service attack) or for ICMP tunnelling.

Implementing Better Rules

As you can see, these rules aren’t the most secure. If you want to improve your security posture, the easiest thing you can do is delete the rules you don’t need. Don’t need to SSH to your instance? Remove the default-allow-ssh rule. Do the same for the others. Don’t need it? Remove it!

Now that we removed the rules we don’t need, it’s time to review the rules we’re still using. For internal traffic, it’s better to restrict the routes and protocols to the ones you need instead of using the default-allow-internal that allows all kinds of traffic to anywhere. For example, if one instance is hosting your PostgreSQL database on port 5432 and it should only be accessed by your backend that is running on another VM. You can set create a firewall rule that allows TCP:5432 with as source range the IP address from your backend VM.

For rules that allow traffic from outside of GCP like default-allow-rdp, it’s recommended to restrict the source ranges. 0.0.0.0/0 allows traffic from anywhere. It’s better to change this to your IP address or the actual range you expect traffic to come from. You can also combine rules with the same source range but different ports and protocols to make it more manageable.

If you want to play it safe and not rely on someone restricting the firewall rules to have a better security posture, you can delete the default network and start from scratch, only adding what you need. You can also enable an organization policy constraints/compute.skipDefaultNetworkCreation, this will prevent a default network from being created when a new project is created.

Firewall Rules Best Practices

• Implement the principle of least privilege. Block all traffic by default and only allow the specific traffic you need. This includes limiting the rule to just the protocols and ports you need. And restrict the source ranges to where you expect the traffic to come from. Try not to use a source range of 0.0.0.0/0 (Allows traffic from everywhere)
• For "allow" rules, restrict them to specific VMs by specifying the service account of the VMs.
• Associate VM instances with the tags and use that in the target instead of all instances
• Use hierarchical firewall policy rules to block traffic that should never be allowed at an organization or folder level.
• If you need to create rules based on IP addresses, try to minimize the number of rules. It's easier to track one rule that allows traffic to a range of 16 VMs than it is to track 16 separate rules.
• Combine multiple ports in a single rule for matching source and destination. This allows for easier managing of firewall rules.
• Turn on Firewall Rules Logging and use Firewall Insights to verify that firewall rules are being used in the intended way. Firewall Rules Logging can incur costs, so you might want to consider using it selectively.
• Review firewall rules periodically