Also read AWS NACLs versus Security Groups and Service Accounts as an intelligent firewall option on GCP.

The default NACLs on an AWS VPC allow ALL traffic (both inbound and outbound). Custom NACLs, in sharp contrast, DENY all inbound and outbound traffic.

You have to use NACLs to DENY ranges of IP addresses (Security groups cannot do that). SGs are setup to NOT ALLOW any traffic. You start setting up by ALLOWING specific traffic using SGs.

Geo Distributed End Users and Admins?

Since NACLs can be used to DENY address ranges, the question becomes - does your subnet (your public subnet) -  require that traffic from all over the world (all IP ranges) be allowed?

If all you have is a bastion host in your public subnet, and the intent is to only let corporate desktops into the bastion host, then your default NACL is way too permissive. You need to have an ALLOW rule that specifies JUST the CIDR block of your on premises network space.

Using NACLs in conjunction with Security Groups

Configure a NACL to handle the brunt of the INGRESS into a subnet

  1. Allow inbound HTTP and HTTPS traffic from any IP address
  2. Deny all other inbound traffic
  3. Allow all outbound traffic
  4. Allow inbound SSH access (port 22) from one IP address—yours—and allow outbound access on any port to the same IP address.

Configure a SG to:

  1. Allow inbound traffic from itself, enabling communication between resources.
  2. Allow traffic into and out of a different security group, which enables instances within different subnets to talk to each other.

What about an AWS hosted web app that can be used by users all around the world?

Instead of hosting such an app directly on the public subnet, you would essentially host it in a private subnet and let in traffic via an API Gateway.

This will allow all HTTP and HTTPS traffic into the API Gateway public endpoint.

You cannot apply a NACL here - as it is not part of the VPC (if the API Gateway had a private endpoint, it would be part of the VPC address space and it could have a NACL applied to it).

So how do you protect the API Gateway public endpoint? You would need an appliance - a FW appliance or a service like Google Cloud Armor - or AWS WAF to front end it.

IAM and API Gateway - Restricting WHO gets to call API Methods

You could enforce authentication at the API Gateway public endpoint - that is tied to AWS IAM. You could also enforce RESOURCE LEVEL policies that could only allow traffic from other AWS resources or IAM users.

What about GCP?

GCP's default VPC has default Firewall rules. And guess what? The Default Firewall rules allow all ingress SSH and RDP traffic from ALL IPs (0.0.0.0/0).  This is a little better than AWS's default NACLs which allow ALL ingress traffic (all ports, not just RDP and SSH).

In addition, traffic BETWEEN VMs is always allowed - on all ports.

So - the recommendations are again, the same as for AWS.

  1. Allow HTTP and HTTPs INGRESS traffic from all sources.
  2. Allow RDP and SSH from a limited set of addresses.
  3. Allow all  outbound traffic.
  4. DENY all other INBOUND traffic.

Alternatives to using Firewall Rules in GCP?

  1. Cloud Armor - It is simpler to protect backend resources - including Compute Engine, App Engine or API Gateway hosted APIs using Cloud Armor. One can also enforce authentication at the App Engine / API Gateway public endpoint.
  2. One could also use a TAG (e.g. a tag called FRONTEND ) to restrict traffic to a private subnet (called backend) by applying the FRONTEND tag to all instances that need access to the private subnet. In GCP, FW Rules can serve as the AWS SGs and NACLs - all at once.

Summary 

  • GCP - Unlike NACLs on AWS, GCP has full blown DENY FW rules - and one could use the same rules to DENY CIDR blocks inbound into a given VPC.
  • AWS -  NACLs should be used to lock down the ranges that can get to your PUBLIC subnets in AWS.  In addition, for truly geographically available apps, where the end user can come from anywhere (e.g. mobile apps), you should use an API gateway on AWS (also called an API Gateway on GCP).




Need a Cloud Security Specialist?
Anuj has successfully delivered over a dozen deployments on each of the public clouds (AWS/GCP/Azure) including several DevSecOps engagements. Set up a time with Anuj Varma.