By Matt Keil, Director of Product Marketing, Public Cloud, Palo Alto Networks
Organizations are deploying enterprise-class apps and services that leverage the power, agility, and global footprint of Google Cloud. From a cyber attacker's perspective, your apps and data are a target, regardless of where they are located, which is where the Palo Alto Networks VM-Series next generation firewall can help.
About the VM-Series next generation firewall
Deployed as a virtual machine (VM) within a Google Cloud project, the VM-Series lets you use app-based policies to reduce your threat footprint. You can apply threat and data-theft prevention policies to your allowed traffic to protect your Google Cloud deployment from attackers.
- App visibility and control. The VM-Series uses the app's identity, instead of its ports, to provide you with granular visibility and subsequent policy-based control over your apps deployed in Google Cloud. With the app's identity as the basis for your security policy, you can deploy policies that are consistent with those deployed in your data center.
- Reduce the attack surface, limit data exfiltration. By using the app's identity as a means of enforcing a positive security model, VM-Series complements VPC Service Controls to reduce the attack surface.You can enable only allowed apps and deny access for anything else to align your app usage with your business needs, extending to app functions as needed. In addition to controlling apps, you can enable policies to block or generate alerts on file and data transfers, thereby limiting data exfiltration.
- Prevent known and unknown threats. Applying threat prevention policies to allowed apps can help block known threats, including vulnerability exploits, malware, and malware-generated command-and-control traffic. Unknown and potentially malicious files are analyzed based on hundreds of behaviors. If a file is deemed malicious, a prevention mechanism is delivered in as little as five minutes. Following delivery, the information gained from file analysis is used to continually improve all other prevention capabilities.
You can deploy the VM-Series in a fully automated manner by using Cloud Deployment Manager or third-party tools, such as Terraform and Ansible. After deployment, VM-Series automation features, such as dynamic address groups and exposed APIs, let you dynamically update security policies, ingest third-party threat intelligence, and initiate remediation actions. By automating the deployment and configuration of the VM-Series along with policy updates, you can embed security into the app development workflow.
As you deploy workloads to Google Cloud, Google Cloud firewall rules filter traffic based on port or protocol to control access to the deployed Google Cloud resources. The VM-Series complements Google Cloud firewall rules by classifying traffic based on the app—not the port. This approach helps reduce your threat exposure with app-based policies, while preventing threats and data exfiltration within the allowed app flows.
Protecting apps from inbound threats and outbound data theft
In the use case illustrated in the following diagram, the VM-Series is deployed to protect inbound and outbound (north-south) virtual private cloud (VPC) traffic and is configured to use four network interfaces spanning multiple VPCs:
- The VM-Series management interface is
eth0by default. Security admins can configure and manage the VM-Series firewall by using either SSH for the command-line interface or HTTPS for the web-based management interface. - Public or untrusted interface (internet facing) uses
eth1. - The web server uses
eth2. - The database is configured to use
eth3.
Traffic routing rules are used to direct all traffic inbound and outbound through the VM-Series firewall for security policy enforcement. After you configure the Google Cloud firewall to allow traffic, you can apply the VM-Series security policy to permit and inspect web traffic from the untrusted zone to the web server zone. A destination network address translation (NAT) policy is configured on the VM-Series firewall to send all inbound traffic to the web server. You can create threat prevention profiles that you can then apply to the allowed web server traffic to protect it from inbound malware and app vulnerability exploits, such as Apache Struts server CVE-2017-5638, as well as outbound command and control or data theft from the database server.
For workloads that you configure to reach out to web resources for automatic
updates, you can establish an app-specific policy to allow those servers in web
and database VPCs to only use apt-get to connect to
*.ubuntu.com or *.canonical.com. Any other type of outbound connection from
the web or database VPCs is blocked. This policy ensures that
only approved traffic flows out and there is no exfiltration of
data or command and control traffic.
Preventing east-west threat movement within a Google Cloud project
The deployment architecture defined in the previous diagram is used to protect VM to VM (east-west) traffic, such as traffic flowing between VPCs that might contain different app tiers or different apps entirely. For VM-to-VM protection, traffic routing rules are used to steer traffic through the VM-Series by using a single network interface per VPC. The first step in protecting east-west traffic between VPC is to configure Google Cloud routing and forwarding rules to send all traffic through the VM-Series firewall for specific destinations. This configuration ensures that traffic doesn't bypass, either purposefully or inadvertently, inspection by the VM-Series firewall.
Google Cloud routing rules are used to ensure that traffic destined for
0.0.0.0/0 is forwarded to the VM-Series by using eth2 for the web
VPC or eth3 for the database VPC. App-specific
policies are then used to allow only MySQL traffic to flow between the web
server VPC and the database VPC. As with the
north-south example, you can create and apply threat prevention profiles to the
MySQL app-specific policy to prevent app vulnerabilities, SQL injection attacks,
and malware. This type of app-specific traffic inspection strengthens your
security posture by limiting access based on apps, and simplifies compliance by
separating payment card information (PCI) and personally identifiable
information (PII) from other types of traffic.
Using this example, configuring north-south and east-west security in Google Cloud uses the following Google Cloud routing rules.
| Google Cloud route rule | Source subnet or VPC | Destination | Priority | Next hop |
|---|---|---|---|---|
| East-west | Web
|
Database
|
200
|
Instance name or IP address* of VM-Series in web subnet |
| East-west | Database
|
Web
|
200
|
Instance name or IP address* of VM-Series in database subnet |
| Outbound | Web
|
Internet
|
300
|
Instance name or IP address* of VM-Series in web subnet |
| Outbound | Database
|
Internet
|
300
|
Instance name or IP address* of VM-Series in database subnet |
| * Using an instance name instead of an IP address is recommended for next hop configuration. |
Securing a hybrid architecture between your data center and Google Cloud
A hybrid cloud combines your existing data center resources, over which you have complete control, with ready-made IT infrastructure resources (such as compute, networking, storage, apps, and services) found in infrastructure as a service (IaaS) public cloud offerings, such as Google Cloud.
IPSec VPN or Dedicated Interconnect
The connection between your data center and Google Cloud can be either one or more internet protocol security virtual private network (IPsec VPN) tunnels across the internet, or you can use Dedicated Interconnect. Dedicated Interconnect establishes a private, high performance network connection from the datacenter that terminates on hardware that you manage, located in a Google Cloud co-location facility.
If you prefer—even when Dedicated Interconnect is used—you can encrypt the entire connection by using an IPsec VPN tunnel all the way into the VPC. This provides an extra layer of security for your network traffic. In either scenario, IPsec VPN tunnels over the internet or across Dedicated Interconnect, the VM-Series deployment and configuration are the same. If the IPsec VPN configuration is chosen, the VM-Series standards-based IPsec VPN connectivity support (IKEv1 or IKEv2) lets you configure VM-Series as a VPN termination point. For more security and flexibility in a hybrid cloud architecture, we recommend using IPsec VPN tunnels that terminate on the VM-Series firewall even when Dedicated Interconnect is used.
IPsec VPN to VM-Series in Google Cloud
The following diagram depicts a site-to-site IPsec VPN, originating from an IPsec VPN appliance residing in the data center and terminating on the VM-Series running in Google Cloud. For tunnel redundancy, you can set up a pair of IPSec tunnels from the data center to a pair of VM-Series instances running in Google Cloud. For more information on IPsec VPN configuration, refer to the admin's guide.
IPsec VPN to Cloud VPN gateway
The following diagram depicts a slightly different approach with the IPsec VPN tunnel originating from an appliance in the data center and terminating on the Cloud VPN gateway. For tunnel redundancy, you can create multiple VPN tunnels from a pair or more of on-premises devices to multiple VPN gateways in different regions.
If you want to establish a VPN connection from a Palo Alto Networks PA-3020 to the Google VPN gateway, follow the instructions in the Using Cloud VPN with A Palo Alto Networks firewall guide. Google Cloud traffic routing and forwarding rules are used to send traffic entering and leaving the VPN tunnel to a VM-Series deployed behind the Google Cloud gateway, thereby preventing malware and advanced threats.
Using a shared VPC architecture
If you have deployments with multiple VPCs, you can use a shared VPC architecture that lets VPCs communicate with each other more securely and efficiently by using internal IPs from that network. The shared VPC is housed in a single project, called the host project, and then other projects, called service projects, can use this shared VPC from the host project. This allows large organizations to delegate admin responsibilities, such as creating and managing instances, to Service Project Admins while maintaining centralized control over network resources, such as subnets, routes, and firewalls. You can deploy the VM-Series in a shared VPC architecture, allowing security teams to manage network security in a single place (the host project), while letting individual service projects maintain access control to their instances.
A single service project hosts the web tier of the app stack and is protected by the VM-Series firewalls connected to the shared VPC of the host project. Additional service projects can leverage the same set of VM-Series firewalls in the host project. Traffic is routed from each service project through the VM-Series firewall, where security policies are applied to control traffic, and prevent threats and data theft. Security policies are applied consistently across projects, and as more service projects are added, you can manually scale out the VM-Series firewalls to address increased capacity requirements, as shown in the following diagram.
Conclusion
Security best practices for protecting apps and data, regardless of location, entail limiting your threat exposure by tightly controlling the apps allowed, and then these best practices can help prevent threats and data exfiltration from within the allowed app flows. The VM-Series, combined with VPC Service Control and Google Cloud firewall rules, let you protect enterprise workloads deployed on Google Cloud.
What's next
- Set up the VM-Series firewall on Google Cloud
- Configuring IPsec VPNs on the VM-Series
- Building and managing VM-Series security policies
- Using VM monitoring to automate security policy updates
- Templates and automation resources
- Try out other Google Cloud features for yourself. Have a look at our tutorials.