Protect your Google Cloud Instances with Firewall Rules

Moving from on-prem to the cloud can bring a slew of practical features for your company and applications. Yet one of the largest challenges (and certainly the most hair-raising) is how this movement can potentially expose your systems to new vulnerabilities. Without taking the right precautions, you run the risk of exposing your system in very problematic ways. As such, once you establish hybrid connectivity to Google Cloud, it’s imperative to control traffic in and out of your instances on GCP by creating Firewall Rules. This is extremely important for a number of reasons:

1. They allow you to isolate your internal network and instances from unwanted access.
2. They allow you to monitor inbound and outbound activity coming from your network for suspicious activity, blocking items that are considered dangerous based on a set of security rules.
3. They establish the first line of defense against attacks, viruses, and malware, and helps create a secure network. So let’s take a look at firewalls more closely.

Don’t let the firewall be the choke point

In traditional on-prem systems, multiple servers on a single internal network are supported through the use of a cluster of firewalls, coupled with a load balancer. A large drawback of this traditional architecture is that it does not scale well. In an on-prem environment, a “firewall” is generally a dedicated piece of hardware that has an upper limit in terms of capacity, and this makes the firewall a choke point. To support dynamic scaling, you’ll need to habitually run down to the server room, and replace that hardware with ones that can handle increased load. Of course, this creates its own challenge — when the traffic goes back to normal, you’ve now got a big piece of expensive hardware going unused.

Google’s distributed firewall

This is where Google Cloud Platform’s Distributed Firewalls can make a difference. Google’s global network has a federation of firewalls that can operate and scale as your systems need them — so you only end up paying for what you use, rather than making commitments for long-term expectations. This gives you the same power of your on-site perimeter network (which blocks all incoming traffic by default), but allows you to scale without lifting a finger. Now here’s the important part — Each VPC network functions as a distributed firewall. A distributed firewall means that by default, it will handle filtering traffic. But like all default things, you’ll need to adjust it to handle your access needs, like applying firewall rules to tagged instances. In the above example, when a request comes in from a compute engine system (labeled with red tag), it hits the applicable firewall rule, before being allowed to communicate with blue tag. While firewall rules are defined at the network level, connections are allowed or denied on a per-instance basis. You can think of the GCP firewall rules as existing not only between your instances and other networks, but between individual instances within the same network.

In Google Cloud, a firewall rule is made up of 4 things:

• An action: either to allow or deny traffic. That is, a rule can either allow incoming (ingress) or outgoing (egress) traffic, but not both simultaneously.
• The type of protocol to which it applies, such as TCP, UDP, ICMP, and IPIP.
• Either a source or a destination for which the rule applies. This cannot be both, as it depends on the direction of the firewall you create. For example, for ingress rules, you would specify the source, which can be IP ranges, tags, or service accounts (or a combination). You wouldn’t specify a destination, because the rule is already being applied to a specific VM’s inbound traffic. Conversely, for egress rules, you wouldn’t specify the source, because the rule is already being applied to that source VM’s outbound traffic.
• The ports to which the rule applies. You can specify the ports on ingress or egress rules. For example, allowing ingress TCP traffic on port 22 to allow for SSH access. You can also deny a VM’s egress TCP traffic on all ports for all destination VMs in an IP range.

Each of these parameters means that firewall rules can help control traffic to and from your Google Cloud VMs accordingly.

Firewall rule set up

Your Wish Is Your Command

As with most networking capabilities on Google Cloud Platform, you can create and modify Firewall Rules using the Google Cloud SDK or Cloud Shell in the console itself. In this example, we create a firewall rule to allow all IPs in subnet1 (10.240.10.0/24) to access TCP port 80 on instances tagged with webserver.

gcloud compute firewall-rules create vm1-allow-ingress-tcp-port80-from-subnet1 \
    --network my-network \
    --action allow \
    --direction ingress \
    --rules tcp:80 \
    --source-ranges 10.240.10.0/24 \
    --priority 50 \
    --target-tags webserver

You can also simply inspect a firewall rule to see its name, applicable network, and components, including whether the rule is enabled or disabled.

gcloud compute firewall-rules describe [FIREWALL_RULE_NAME]

Firewall rules logging

Now that you’re protecting your environment with firewall rules, how do you determine if a rule is designed to deny traffic and functioning as intended? Logging is extremely useful to monitor and ensure your rules are being applied. They’re also useful if you need to determine how many connections are affected by a given firewall rule. Luckily, the Logs section of the GCP Console lets you view firewall rule logs.

Firewalls are an extremely important part of your on-prem to cloud transition. They are the basis at which traffic can flow to and from individual Google Cloud instances, but also to and from your on-premise network to your cloud network. If you want to learn about more complex use cases, check out the documentation. But to get you moving on your migration to Google Cloud, stay tuned for the next article on configuring IPs.

Now what?

1. Deep dive on Firewall rules here.
2. Subscribe to the GCP Youtube channel and follow my video series Networking End-to-End.
3. Check out Networking 103 where I discuss firewall rules with Networking Specialist, Binal Shah.
4. Want more content? Follow me on Twitter @swongful.
5. And check out the Google’s Cloud events near you.

Stay tuned for more on this series and thanks for joining me on this wild ride to demystify cloud networking.