Google Cloud VPC Firewall Rules

• Firewall rules help define allow or deny connections and apply to both outgoing (egress) and incoming (ingress) traffic in the network.
• Firewall rules control traffic even if it is entirely within the VPC network, including communication among VM instances.
• Firewall rules apply to a given project and network, and connections are allowed or denied on a per-instance basis.
• Every VPC network has two implied firewall rules
  • Implied allow egress rule – allow all egress traffic,
  • Implied deny ingress rule – denies all ingress traffic.
• Implied rules cannot be deleted but have the lowest possible priorities and can be overridden
• Firewall rules only support IPv4 connections
• Firewall rules always allow the following traffic
  • DHCP
  • DNS
  • Instance metadata (169.254.169.254)
  • NTP
• Firewall rules always block the following traffic
  • GRE traffic – Tunneling protocol
  • Protocols other than TCP, UDP, ICMP, and IPIP
  • Egress traffic on TCP port 25 (SMTP)
• VPC firewall rules are stateful
  • GCP associates incoming packets with corresponding outbound packets by using a connection tracking table.
  • When a connection is allowed through the firewall in either direction, return traffic matching this connection is also allowed.
  • Firewall rule cannot be configured to deny associated response traffic.
  • Stateful response to the request is not logged as well
  • Return traffic must match the 5-tuple (source IP, destination IP, source port, destination port, protocol) of the accepted request traffic, but the source and destination addresses and ports are reversed.
    • Google Cloud implements connection tracking regardless of whether the protocol supports connections.
    • A firewall rule’s tracking state is considered active if at least one packet is sent every 10 minutes

Firewall Rule components

• Each firewall rule requires the direction of connection and applies to incoming (ingress) or outgoing (egress) connection, not both
• Each firewall rule’s action is either allow or deny.
• Each firewall rule has a priority defined from 0 to 65535 inclusive defaults to 1000. Lower integers indicate higher priorities.
• A target, which defines the instances to which the rule applies.
  • Ingress (inbound) rule, the target parameter designates the destination VM instances
  • Egress (outbound) rule, the target designates the source instances.
  • supports the following options
    • All instances in the network.
    • Instances by target tags.
    • Instances by target service accounts
• A source for ingress rules or a destination for egress rules.
  • Ingress (inbound) rules
    • target parameter specifies the destination instances for traffic;
    • destination parameter cannot be used
    • source is specified by using the source parameter.
  • Egress (outbound) rules
    • target parameter specifies the source instances for traffic; you
    • source parameter cannot be used
    • destination is specified by using the destination parameter.
  • supports the following options
    • Source IP ranges:
    • Source tags:
    • Source service accounts:
• Firewall rules have enforcement status and are enabled by default. They can be disabled for troubleshooting or for maintenance, instead of having to delete and add them again.

Service Account vs Network Tag Filtering

• Firewall rules support source and target filtering by Service Account and Network Tags
• Service Accounts and Network Tags cannot be mixed and matched in any firewall rule.
• Use service accounts instead of network tags for strict control over how firewall rules are applied to VMs, as network tags can be inferred while using a service account would require access to it as well.
• A network tag is an arbitrary attribute. One or more network tags can be associated with an instance by any IAM member who has permission to edit it. IAM members with the Compute Engine Instance Admin role to a project have this permission. IAM members who can edit an instance can change its network tags, which could change the set of applicable firewall rules for that instance.
• A service account represents an identity associated with an instance. Only one service account can be associated with an instance. Access to the service account can be controlled by controlling the grant of the Service Account User role for other IAM members. For an IAM member to start an instance by using a service account, that member must have the Service Account User role to at least use that service account and appropriate permissions to create instances

Firewall Rules Logging

•  Firewall Rules Logging enables auditing, verifying, and analyzing the effects of the firewall rules.
• Firewall Rules Logging can be enabled individually for each firewall rule whose connections need to log
• Google Cloud creates an entry called a connection record each time the firewall rule allows or denies traffic.
• Each connection record contains the source and destination IP addresses, the protocol and ports, date and time, and a reference to the firewall rule that applied to the traffic.
• Firewall Rules Logging only records TCP and UDP connections.
• Firewall Rules Logging cannot be enabled for the implied deny ingress and implied allow egress rules. Instead, create explicit Allow or Deny rules.

GCP Certification Exam Practice Questions

• Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
• GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
• GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
• Open to further feedback, discussion and correction.

1. Your developers are trying to connect to an Ubuntu server over SSH to diagnose some errors. However, the connection times out.
   Which command should help solve the problem?
   1. gcloud compute firewall-rules create "open-ssh" --network $NETWORK --allow tcp:22
   2. gcloud compute firewall-rules create "open-ssh"
   3. gcloud compute firewall-rules create "open-ssh" --network $NETWORK --deny tcp:22
   4. gcloud compute firewall-rules create "open-ssh" --network $NETWORK --allow tcp:3389
2. You’ve created a new firewall rule to allow incoming traffic on port 22, using a target tag of “dev-ssh”. You tried to connect to one
   of your instances, and you’re still unable to connect. What steps do you need to take to resolve the problem?
   1. Run the gcloud firewall-rules refresh command, as they need to be reloaded
   2. Use source tags in place of the target tags.
   3. Reboot the instances for the firewall rule to take effect.
   4. Apply a network tag of “dev-ssh” to the instance you’re trying to connect into and test again.
3. You have created a firewall with rules that only allow traffic over HTTP, HTTPS, and SSH ports. While testing, you specifically try to reach the server over multiple ports and protocols; however, you do not see any denied connections in the firewall logs. You want to resolve the issue. What should you do?
   1. Enable logging on the default Deny Any Firewall Rule.
   2. Enable logging on the VM Instances that receive traffic.
   3. Create a logging sink forwarding all firewall logs with no filters.
   4. Create an explicit Deny Any rule and enable logging on the new rule.

References

Google_Cloud_Firewall_Rules