Palo Alto Networks | VM-Series for AWS Hybrid Cloud Deployment Guidelines White Paper

Cloud-first development initiatives, the need to deliver your applications and services to an exploding number of mobile devices, and the ongoing need to accomplish more with less is driving a data center transformation that increasingly includes the public cloud. Commonly referred to as a hybrid data center, this approach integrates your existing data center with Amazon Web Services (AWS) to address your growing data center demands and provide you with the added benefits of agility, scalability and global reach. Hybrid deployments are one of the most common AWS scenarios, as they extend your on- premises data center (physical, virtualized, or both) onto AWS through either an IPsec VPN or AWS Direct Connect.

From a security perspective, moving your applications and data to AWS does not necessarily eliminate customers’ responsibilities for protection of their data and applications. Regardless of their location – public cloud, private cloud, or physical data center – applications and data are an attacker’s target, and protecting them on AWS requires organizations to take appropriate steps to protect their AWS deployment from cyberattacks.

The VM-Series for AWS allows you to securely move your applications and data onto AWS, beginning first with a hybrid approach, then expanding security coverage to include segmentation policies, much like the security techniques used on your physical network. This document complements the VM-Series technical documentation with some added guidelines and recommendations that address common questions, which arise during hybrid use case deployments. For completeness, this document has been written using a two-tiered application environment (web server and database) that is secured by the VM- Series.

VM-SERIES FOR AWS HYBRID CLOUD DEPLOYMENT GUIDELINES

Palo Alto Networks | Securely Enabling a Hybrid Cloud in Microsoft White Paper 2

Table of ContentsVM-Series for AWS Hybrid Cloud Deployment Guidelines 1

Executive Summary 1

The Business Case for AWS 3

AWS Infrastructure Security Considerations 3

Security as a Shared Responsibility 3

Security Challenges in AWS 4

Security Groups, WAFs or Next-Generation Firewall? 4

VM-Series for AWS 5

VM-Series for AWS Licensing 5

VM-Series for AWS Sizing Considerations 5

The Hybrid Cloud: The Best of Both Worlds 6

Hybrid Cloud Benefits 6

Public/Private Cloud Transparency 7

Uniform Security 7

Building a Secure Hybrid Cloud with the VM-Series for AWS 7

Hybrid Cloud Topology Overview 7

VPC Subnets and the Internet Gateway 8

VM-Series for AWS Integration 10

Establishing Your IPsec VPN Connections 10

Ensuring All Traffic Flows Through the Firewall 11

Hybrid Cloud Route Propagation 11

Preventing Firewall Bypass 13

Scaling Your AWS Deployment 15

Auto Scaling the VM-Series for AWS 15

How Auto Scaling the VM-Series for AWS Works 16

Scaling the VM-Series with ECMP 17

Scaling Security Using On-Premises Load Balancing 18

Additional VM-Series for AWS Deployment Scenarios 18

Internet-Facing Use Case 18

Scalable Internet-Facing Use Case 18

GlobalProtect Remote Access Use Case 19

VM-Series for AWS GovCloud 19

Try the VM-Series Firewall 19

Conclusion 19

Palo Alto Networks | VM-Series for AWS Hybrid Cloud Deployment Guidelines White Paper 3

The Business Case for AWSCustomers have become much more comfortable with the prospect of using public cloud services, such as AWS, to augment their existing, private/on-premises data centers. In many cases, the public cloud initiatives start small, with new application development projects often termed either “cloud-first” or “cloud-native,” the latter being more common. For new projects, the on-demand nature of AWS allows you to easily create separate development, testing, and production environments for your new application. Using AWS for new application development projects also allows you to take into consideration new development techniques that are more component-based than previously used techniques. Additional use cases for AWS include disaster recovery, (big) data storage and analytics, product demonstration environments, and remote access for employees.

AWS Infrastructure Security Considerations Moving your applications and data into AWS is no different than establishing a new, on-premises network in that you are starting with a blank slate, and you are defining the necessary IT infrastructure elements, including security, that are needed. When looking to the public cloud, there are two aspects of security to consider – that of the infrastructure itself, which is the responsibility of AWS, and that of protecting your applications and data on AWS.

Security as a Shared ResponsibilityAWS is very clear about where the security responsibilities lie, as shown in Image 1 below. AWS takes care of the physical security aspects as well as the underlying infrastructure. From the AWS website:

When evaluating the security of a cloud solution, it is important for customers to understand and distinguish between:

• Security measures that the cloud service provider (AWS) implements and operates – “security of the cloud”

• Security measures that the customer implements and operates, related to the security of customer content and applications that make use of AWS services – “security in the cloud”

While AWS manages security of the cloud, security in the cloud is the responsibility of the customer. Customers retain control of what security they choose to implement to protect their own content, platform, applications, systems and networks, no differently than they would for applications in an on-site data center. Learn more about the AWS Shared Responsibility Model.

Image 1: AWS Shared Responsibility Model diagram

Customer Content

Platform, applications, identity & access management

Operating system, networks and firewall configuration

Encryption keymanagement

Client & serverencryption

Network trafficprotection

AWS Foundation Services

ComputeAWS GlobalInfrastructure

Compute Storage Database Networking

Availability zones

RegionsEdge

locations

AWS looks after thesecurity OF theplatform

Customers areresponsible for their security IN the cloud

http://aws.amazon.com/compliance/shared-responsibili-ty-model/.

Palo Alto Networks | VM-Series for AWS Hybrid Cloud Deployment Guidelines White Paper 4

Security Challenges in AWSMany existing third-party public cloud security solutions exhibit weaknesses similar to those found when they are deployed on the physical network – they make their initial, positive control network access decisions based on port, using stateful inspection; then they make a series of sequential, negative control decisions using bolted-on application control or IPS feature sets. There are several problems with this approach:

• Ports first or ports only limits visibility and control. Using TCP and UDP ports to block certain traffic can be an effective means of limiting traffic access, but enabling an application based on ports is problematic. Solutions that focus on ports first have a limited ability to see all traffic on all ports, which means that applications running on multiple ports, or those that hop ports as an accessibility feature, may not be identified. For example, Microsoft Lync®, Microsoft Active Directory®, and Microsoft SharePoint® use a wide range of contiguous ports, including ports 80 and 443, to function properly. This means you need to first open all those ports, exposing those same ports to other applications or cyberthreats. Only then can you try to exert application control.

• They lack any concept of unknown traffic. Unknown traffic epitomizes the 80-20 rule – it is high-risk, yet it is a small amount of traffic on every network. Unknown traffic is found on every port and can be a custom application, an unidentified commercial application, or a threat. Blocking it all, a common recommendation, may cripple your business. Allowing it all is perilous. You need to be able to systematically manage unknown traffic down to a low-risk percentage using native policy management tools, thereby reducing your security risks. Systematically managing unknown traffic means being able to find it quickly, analyze it to determine the next steps, and then take those next steps accordingly.

• Multiple policies, no policy reconciliation tools. The sequential traffic analysis (stateful inspection, application control, IPS, AV, etc.) performed by existing solutions requires a corresponding security policy or profile, oftentimes using multiple management tools. The result is that your security policies become convoluted as you build and manage a firewall policy with source, destination, user, port and action, and an application control policy with similar rules, in addition to other threat prevention rules. This reliance on multiple security policies that mix positive (firewall) and negative (e.g., application control, IPS, AV) control models without any policy reconciliation tools introduces potential security holes by missed or unidentified traffic.

• Cumbersome security policy update process. Finally, existing security solutions in the data center do not address the dynamic nature of your cloud environment and cannot adequately track policies to virtual machine additions, removals or changes.

Security Groups, WAFs or Next-Generation FirewallIn addition to third-party security offerings, AWS provides a range of native security services that can help customers protect their applications and data, including Security Groups, Access Control Lists (ACL) and a Web Application Firewall. It is important to understand what these services provide, where they may fit in your security infrastructure, and how they are different from the VM-Series for AWS.

• Security Groups and ACLs are port and IP-based controls that provide filtering capabilities within your AWS deployment. Security groups are port-based access control lists and as such are unable to identify and control traffic at the application level. This means that you will not know the identity of the applications being allowed by a Security Group; you will only see the port and associated TCP or UDP service. In addition, security groups do not support any advanced threat prevention features.

• Web Application Firewalls (WAFs) are focused solely on protecting HTTP or HTTPS applications, typically those that are public-facing and ignoring any other traffic. Each WAF implementation will be customized for the application(s) being protected. A WAF is very effective at protecting a customized, public-facing web application that contains a series of form fills, such as a retail order form. WAFs are not designed to protect applications like Microsoft SharePoint® or Microsoft Active Directory®, nor are they an effective means of identifying and controlling remote management/access tools, such as SSH or Microsoft RDP. Unless you have a public-facing web application, you may not need a WAF. However, many customers prefer to implement a network firewall – be it physical or virtualized – as a complement to a WAF, because they need to see, control and protect all traffic traversing the deployment.

Both Security Groups and Web Application Firewalls will help you protect your network, but it is important to understand their key characteristics when moving your application workloads to AWS.  

Palo Alto Networks | VM-Series for AWS Hybrid Cloud Deployment Guidelines White Paper 5

VM-Series for AWS Whereas Security Groups and a WAF provide some initial filtering or highly customized web-application security, the Palo Alto Networks® VM-Series for AWS allows you to protect your AWS deployment from cyberattacks delivered by all types of applications, across all ports. The VM-Series for AWS natively analyzes all traffic in a single pass to determine the application identity, content within, and user identity. These core business elements can then be used as integral components of your AWS security policy, allowing you to:

• Identify what’s traversing your AWS deployment. With knowledge comes power. Identifying the applications in use in your AWS deployment, regardless of port, gives you unmatched visibility into your AWS environment. Armed with this knowledge, you can make more-informed security policy decisions.

• Enable applications and your users. Using the application as the basis for your AWS security policy allows you to create application whitelisting and segmentation policies that leverage the deny-all-else premise that a firewall is based upon; allow the applications you want in use, and then deny all others.

• Prevent advanced cyberattacks. In order to further protect your AWS environment, you can deploy application-specific threat prevention policies that will block both known and unknown malware.

• Prevent the spread of malware within your AWS deployment. As in your private data center, the public cloud often has application tiers with some traffic contained entirely within the cloud. Without visibility and control over this east-west traffic, malware can quickly spread from an initial attack vector to other resources within the cloud.

VM-Series for AWS LicensingThe VM-Series can be licensed using a consumption-based model, or as a traditional, bring-your-own-license model.

• Consumption-based licensing: This licensing model allows you to purchase the VM-Series next-generation firewall, select Subscriptions and Premium Support as a bundle directly through your AWS Management Console on either an hourly or annual payment structure.

◦ Bundle 1 contents: VM-300 firewall license, Threat Prevention subscription (inclusive of IPS, AV, and malware prevention), and Premium Support.

◦ Bundle 2 contents: VM-300 firewall license, Threat Prevention (inclusive of IPS, AV, and Malware prevention), WildFire™ threat intelligence service, URL Filtering, GlobalProtect™ network security client for endpoints, and URL Filtering subscriptions, along with Premium Support.

• Bring-your-own-license: Any one of the VM-Series firewall models, along with associated subscriptions and support, are purchased via normal Palo Alto Networks channels and then deployed through your AWS Management Console using an authorization code. For AWS GovCloud (U.S.) users, the VM-Series is now available as a BYOL here (login required).

VM-Series for AWS Sizing Considerations Establishing an AWS presence entails many of the same steps used to build out an on-premises IT infrastructure. Common steps will include determining the size and volume of computing resources needed, network requirements, and software licensing options. Some of the key sizing and implementation considerations for the VM-Series are listed below.

• AWS Instances: The VM-Series for AWS can be deployed in a range of AWS instances from small c3 to the c4.4xlarge. To confirm the latest list of available AWS Instances for the VM-Series, please check our AWS Marketplace listing here.

• Elastic Network Interface Support: AWS instances support up to 8 Elastic Network Interfaces (ENI). The first ENI is always dedicated for management use while the remaining ENIs are used for data. Go here to confirm ENI support per AWS Instance.

• Interface modes: Only L3 is supported due to the AWS infrastructure requirements. TAP, L2, and virtual wire interfaces are not supported.

• https://console.ama-zonaws-us-gov.com/ec2/home?re-gion=us-gov-west-1#LaunchInstance-Wizard:ami=ami-bc9c21dd

z

AZ1

b

Web1

DB1

C4

VM-SeriesDB1

Web1

Palo Alto Networks | VM-Series for AWS Hybrid Cloud Deployment Guidelines White Paper 6

• CPU, Memory and Storage: All instance types support 2, 4 or 8 vCPUs, and they all require at least 4GB of memory and 40GB of EBS-optimized volume storage.

The Hybrid Cloud: The Best of Both WorldsA hybrid cloud combines your existing data center (private cloud) resources, over which you have complete control, with ready-made IT infrastructure resources (e.g., compute, networking, storage, applications, and services) found in IaaS or public cloud offerings such as AWS. The private cloud component is one or more of your data centers that you have complete control over while the public cloud component is IaaS-based and allows you to spin up fully configured computing environments on an as needed basis.

Establishing a Connection to AWS: IPsec VPN or AWS Direct Connect?The connection between your private and AWS Cloud workloads should be one or more IPsec VPNs across the internet, or you can use the AWS Direct Connect service. The AWS Direct Connect service provides a mechanism for customers to establish a dedicated network from their private cloud or on-premises data center to AWS. This provides dedicated connectivity with the performance levels granted by the customer’s service provider. The dedicated connection terminates on customer managed hardware located in an AWS Direct Connect location. From that point, one or more 802.1q VLANs are used to complete the connection into the customer VPCs.

Many AWS customers prefer the entire connection be IPsec encrypted all the way into the VPC – even when Direct Connect is used. This provides an extra layer of security for their network traffic. In this scenario, the hybrid cloud solution looks no different from the perspective of the VM-Series firewall than if the internet was used instead of Direct Connect. In either case, the solution is the same including routing, redundancy, managed scale, etc. For maximum security and flexibility in a hybrid cloud architecture, IPsec tunnels terminating on the VM-Series firewall is recommended, including when Direct Connect is used. More information about this service can be found at: https://aws.amazon.com/directconnect/.

Image 2: Hybrid cloud topology

Image 2 depicts a simplified version of a hybrid cloud topology. It includes an Amazon Virtual Private Cloud (Amazon VPC) on the right side, which is a logically separated set of resources dedicated to one customer but running on a shared infrastructure. An introduction to the Amazon VPC can be found at https://aws.amazon.com/vpc/. On the left side of the image is your existing private data center with redundant connectivity to the Amazon VPC. In this example, an existing two-tiered application is running in the private cloud and the database and web tiers have scaled (“bursted”) into the public cloud. The VM-Series in the VPC is securing the traffic in and out of the VPC, as well as east-west traffic within the VPC, just as the physical firewall in the private data center is doing.

• https://github.com/ Palo-AltoNetworks/aws/tree/master/global-

Private Data Center Public Cloud

Web1

DB1

IPsec VPN

z

AZ1

b Web1

DB1

C4

VM-SeriesDB1

Web1

Palo Alto Networks | VM-Series for AWS Hybrid Cloud Deployment Guidelines White Paper 7

Hybrid Cloud BenefitsThe primary goals of a hybrid cloud is to leverage the bursting and scaling capabilities of the public cloud while seamlessly integrating with the private cloud. This allows you to take an existing, physical data center and expand on demand into a public cloud while taking advantage of the flexibility and global scalability that AWS provides. For example, businesses with highly variable computing requirements, such as an online retailer, might require extra resources during the holidays. Or a finance company may need extra capacity at the end of each quarter and fiscal year. Without the public cloud, you might need to invest in hardware that is only used temporarily and then sits idle during off-peak times.

An increasingly common hybrid cloud scenario is to use it as a means of managing separate application development, testing, and production environments. As your application moves through the process, resources can be commissioned/decommissioned quickly and efficiently. Not only do you eliminate the need to invest in hardware for a short-term project, you can easily segregate the VPC from the internal network from a security standpoint while still allowing seamless traffic flow from a routing perspective. The development/testing VPC looks like an extension of your own data center but still has an easy point of demarcation for the purpose of security policy enforcement.

Public/Private Cloud TransparencyAn added benefit of a hybrid cloud is, when they are properly designed and implemented, you can expand your network from the private cloud into the public cloud seamlessly. An overlay network using VPNs not only provides privacy over shared networks, but the VPNs also reduce the number of Layer 3 hops on the end-to-end network. This allows you to expand your internal IP address space into the public cloud using widely supported routing protocols.

For example, routes for the directly attached networks on AWS can be redistributed into an OSPF process running on the VM-Series firewalls in the VPC(s). These routes can then be dynamically shared with your on-premises firewalls and routers via OSPF updates. The end result is that routing traffic, for example to a database server, uses the exact same mechanism, regardless if the database subnet is on-site or in the public cloud, or both. This is no different than if the public cloud servers were hosted in the private data center, thus making the connectivity between private and public cloud(s) transparent.

Uniform SecurityOne of the other key benefits that the VM-Series provides is feature consistency with respect to our appliance-based firewalls, allowing you to protect both your public and private cloud environments with a unified set of security policies. All of our firewalls — virtual or physical, private or public cloud – can leverage common PAN-OS® objects and administrative processes, and they can be managed by the same Panorama™ centralized management implementation using different device groups for your public and private firewall rules. This creates many opportunities for improved efficiency using a single pane of glass for all of your firewalls, public and private.

For example, a custom App-ID™ or application group that is created for the private data center firewall(s) can be easily shared with the AWS public cloud VM-Series firewalls. Dynamic block lists can be shared across both environments. Many configuration elements that are universal to all firewalls in an organization can also be configured once and shared to all firewalls, including:

1. DNS servers

2. NTP servers

3. Local admin accounts

4. Syslog servers

5. LDAP/AD authentication profiles

6. Dynamic Address Groups

Panorama can be used for central logging of all firewall events, creating a single pane of glass for monitoring as well. This makes it easier to detect overall trends and threats. For example, in Panorama, a new automated correlation engine can now be used to help your security administrator detect actionable events on your network. This is made even more useful and effective if private and public cloud firewalls all forward events to Panorama centrally. Click for more information on the PAN-OS correlation engine.  

Palo Alto Networks | VM-Series for AWS Hybrid Cloud Deployment Guidelines White Paper 8

Building a Secure Hybrid Cloud with the VM-Series for AWS The remainder of this paper illustrates specific considerations for building a secure hybrid cloud on AWS with the VM-Series. We recommend that you use this document in conjunction with the VM-Series for AWS technical documentation.

Hybrid Cloud Topology OverviewWhen deployed, our hybrid topology will securely connect your data center to your Amazon VPC, which is a logically isolated section(s) of your AWS deployment. Each Amazon VPC has a set of dedicated resources and as such is segregated from other Amazon VPCs, adding a layer of isolation between other applications. For redundancy, AWS recommends that each Amazon VPC have two Availability Zones (AZs), which are physically diverse data centers that provide high availability within your Amazon VPC. Read an introduction to AWS Availability Zones.

Image 3: Detailed hybrid cloud topology within AWS

In our hybrid cloud topology, shown in image 3, each AZ gets one VM-Series firewall. This firewall will be used to secure traffic in and out of the AZ/VPC – commonly referred to as north-south security in a traditional data center. The VM-Series firewall uses a zone based architecture that allows you to logically group interfaces, VLANs, and/or IP addresses into a “Web Zone” and “DB Zone.” Policies between zones allow you to provide inter-application tier security or east-west security as a means of blocking the lateral movement of malware.

For an additional layer of redundancy, two VM-Series firewalls could optionally be deployed in each AZ in an active/passive HA pair. Given the redundancy already provided by the application, having multiple AZs, and potentially multiple Amazon VPCs, using a firewall HA pair in every AZ isn’t required but can be used for even more redundancy. Image 3 displays an example hybrid cloud topology using a private data center connected to an Amazon VPC with AZ redundancy.

AZ1

c A

Z1b

C4

VM-Series

C4

VM-Series

Web1-01

Web1-02

Web1-03

Web2-01

Web2-02

Web2-03

IPsec VPN

Private Data Center

DC-FW1

DC-FW2

VM-Series

Panorama

VMVMVM

VM

AZ1

c A

Z1b

C4

VM-Series

C4

VM-Series

Web1-01

Web1-02

Web1-03

Web2-01

Web2-02

Web2-03

Inte

rnal

Sub

net2

Inte

rnal

Sub

net1

Exte

rnal

Sub

net2

Exte

rnal

Sub

net1

VPC Subnets and the Internet GatewayAn Amazon VPC connects to the internet using an inter-net gateway or IGW. The IGW connects to one or more subnets inside the Amazon VPC. Then route tables are assigned to these subnets to allow traffic between them and the internet via the IGW, as shown in Image 4; the external subnet will need a route for the IGW, whereas the internal subnet will not.

Image 4: Sample topology with internal and external subnets  

Palo Alto Networks | VM-Series for AWS Hybrid Cloud Deployment Guidelines White Paper 9

For maximum flexibility, control, and granularity, AWS recommends unique route tables for each subnet. Image 5 shows an example of a suitable route table for one of the external subnets.

Image 5: External subnet route table within the AWS console

Note the default route in the route table references the IGW for the Amazon VPC. In the case of an internal subnet, an internal route table should be created that does not include the IGW to ensure no routing between the internal subnets and the internet can occur even if the firewall is misconfigured. In Image 6, note that there is no IGW listed in the route table.

Image 6: Internal subnet route table within the AWS console

VM-Series for AWS Integration At this point, you have established your subnets and can now deploy the VM-Series firewall and attach it to the subnets using AWS Elastic Network Interfaces, or ENIs. For step-by-step instructions, we recommend you take a look at the documentation on deploying the VM-Series in a multi-subnet Amazon VPC.

Once the VM-Series firewalls are deployed in each AZ, you will need to configure routing for the end-to-end solution. The first step is to configure a default route in the internal Amazon VPC subnet’s route tables pointing to the VM-Series firewalls.

Palo Alto Networks | VM-Series for AWS Hybrid Cloud Deployment Guidelines White Paper 10

Establishing Your IPsec VPN ConnectionsThe VM-Series, and all of our other firewalls, are based on PAN-OS, our security operating system, which supports the standards-based IPsec protocol suite. The public to private cloud VPNs can be established between the VM-Series firewalls and any standards-based VPN device, including another Palo Alto Networks firewall. The steps for creating a site-to-site VPN in the VM-Series with PAN-OS are:

1. Set up the IKE gateway(s).

2. Define the cryptographic profiles.

3. Configure the IPsec tunnel.

See detailed instructions for setting up IPsec VPNs in PAN-OS.

Image 7 shows a series of screenshots of VM-Series firewall VPN configurations and status in AWS.

Image 7: VPN configuration screen images from the VM-Series management interface

Palo Alto Networks | VM-Series for AWS Hybrid Cloud Deployment Guidelines White Paper 11

Here are sample CLI commands showing IKE gateway and IPsec association status.

admin@SVC-VPC-FW1> show vpn ike-sa gateway IKE-GW-1

IKEv1 phase-1 SAs

GwID/client IP Peer-Address Gateway Name Role Mode Algorithm Established Expiration V ST Xt Phase2

-------------- ------------ ------------ ---- ---- --------- ----------- ---------- - -- -- ----

1 1.2.3.4 IKE-GW-1 Init Main PSK/ DH2/A128/SHA1 Nov.06 15:06:07 Nov.06 23:06:07 v1 12 4 1

Show IKEv1 IKE SA: Total 2 gateways found. 1 ike sa found.

IKEv1 phase-2 SAs

GwID/client IP Peer-Address Gateway Name Role Algorithm SPI(in) SPI(out) MsgID ST Xt

-------------- ------------ ------------ ---- --------- ------- -------- ----- -- --

1 1.2.3.4 IKE-GW-1 Init ESP/ DH2/tunl/SHA1 DC730303 8915D5F2 11A66FD4 9 1

Show IKEv1 phase2 SA: Total 2 gateways found. 1 ike sa found.

admin@SVC-VPC-FW1> show vpn ipsec-sa tunnel tunnel1

GwID/client IP TnID Peer-Address Tunnel(Gateway) Algorithm SPI(in) SPI(out) life(Sec/KB)

-------------- ---- ------------ --------------- --------- ------- -------- ------------

1 2 1.2.3.4 tunnel1(IKE-GW-1) ESP/A128/SHA1 DC730303 8915D5F2 1627/0

Show IPSec SA: Total 1 tunnels found. 1 ipsec sa found.

Ensuring All Traffic Flows Through the FirewallThere are two aspects for routing that must be addressed: one is how to propagate routes between the public and private clouds; the other is how to ensure the firewall is always in the routed path of the public cloud traffic, inspecting traffic flowing both north-south and east-west.

Hybrid Cloud Route PropagationOnce the VPNs are up, you will need some method of propagating routes for the public cloud subnets to the private cloud firewalls and routers. Static routes are appropriate for simple topologies. More complex topologies call for dynamic routing, such as OSPF. For the scope of this section, we will highlight a simplified design using static routes. In a production environment, we would require at least two firewalls per availability zone for redundancy with primary and backup routes or ECMP, but this example will use the simplified topology displayed in Image 8.

Image 8: Two-tiered, hybrid cloud topology

IPSec VPN

Private Data Center

DC-FW1

DC-FW2

VM-Series

Panorama

VMVMVM

VM

z

AZ1

b

Web1

DB1

C4

VM-SeriesDB1

Web1

Palo Alto Networks | VM-Series for AWS Hybrid Cloud Deployment Guidelines White Paper 12

There are two subnets in the public cloud attached to the VM-Series firewall. The firewall will have a static route for the private cloud data center pointing to the IPsec tunnel. Routes must also be defined in the private cloud (and typically redistributed into the private data center dynamic routing protocol). In this example, the web and database subnets in the public cloud are using 10.4.3.0/24 and 10.4.5.0/24 respectively. On the private cloud firewalls, we will need to define static routes for these two subnets that point to the tunnel. On the public cloud firewall, we will need to define a static route entry that encompasses the private cloud address space. To simplify the configuration, we will create one 10.0.0.0/8 route on the public cloud pointing to the private cloud address space. This includes the directly attached networks; but directly attached networks take priority, and we can simplify the static route table. The public cloud firewall has a static route pointing to the private cloud over the VPN as shown in Image 9.

Image 9: Private cloud subnet configuration

On the private cloud firewall, there are two static routes pointing to each of the public cloud subnets.

Image 10: Public cloud subnet configuration for web and DB tier

As mentioned above, the private cloud firewall static routes should be redistributed into whatever routing protocol is used in the data center.

With the static routes configured and the appropriate security policy in place, we now have full routing between the public and private cloud.

Palo Alto Networks | VM-Series for AWS Hybrid Cloud Deployment Guidelines White Paper 13

ubuntu@web1:~$ ping -c 3 db1

PING db1 (10.4.5.201) 56(84) bytes of data.

64 bytes from db1 (10.4.5.201): icmp_seq=1 ttl=63 time=1.04 ms

64 bytes from db1 (10.4.5.201): icmp_seq=2 ttl=63 time=0.910 ms

64 bytes from db1 (10.4.5.201): icmp_seq=3 ttl=63 time=0.855 ms

--- db1 ping statistics ---

3 packets transmitted, 3 received, 0% packet loss, time 2002ms

rtt min/avg/max/mdev = 0.855/0.937/1.048/0.088 ms

ubuntu@web1:~$ ping -c 3 db2

PING db2 (10.4.4.201) 56(84) bytes of data.

64 bytes from db2 (10.4.4.201): icmp_seq=1 ttl=62 time=21.5 ms

64 bytes from db2 (10.4.4.201): icmp_seq=2 ttl=62 time=21.9 ms

64 bytes from db2 (10.4.4.201): icmp_seq=3 ttl=62 time=21.5 ms

--- db2 ping statistics ---

3 packets transmitted, 3 received, 0% packet loss, time 2002ms

rtt min/avg/max/mdev = 21.500/21.659/21.920/0.186 ms

ubuntu@web1:~$

Preventing Firewall BypassFor AWS, every subnet that is created in a Amazon VPC is automatically and permanently attached to the VPC virtual router. If there is only one internal subnet in the VPC, we simply create a default route in the VPC pointing to the ENI of the internal firewall interface. There is no need to protect against firewall bypass because the only destinations for instances in the VPC are external, and only the firewall has access outside of the VPC.

When there are two or more subnets, we need to ensure the inter-subnet traffic always traverses the firewall. In our example, the web subnet and the database subnet not only attach to our VM-Series, but also attach to the Amazon VPC virtual router. If the web server were to send a packet to the virtual router destined for the database server, the virtual router would forward the packet directly to the database server, and the firewall would never see the packet. This would result in the firewall being bypassed. To prevent this from happening, we create a route in AWS for the protected instances that points to the firewall as the default gateway.

Image 11: AWS console showing VPN test

Palo Alto Networks | VM-Series for AWS Hybrid Cloud Deployment Guidelines White Paper 14

And we let the server instances point to the virtual router of the subnet.

ubuntu@db3:~$ netstat -rn

Kernel IP routing table

Destination Gateway Genmask Flags MSS Window irtt Iface

0.0.0.0 10.4.6.1 0.0.0.0 UG 0 0 0 eth0

10.4.6.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

However, we cannot use this routing method for multiple subnets. We must define a default route on the instances to point to the firewall.

ubuntu@web1:~$ netstat -rn

Kernel IP routing table

Destination Gateway Genmask Flags MSS Window irtt Iface

0.0.0.0 10.4.3.101 0.0.0.0 UG 0 0 0 eth0

10.4.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

We cannot assume that an instance’s internal route table won’t be accidentally or maliciously configured to use the virtual routers instead of the firewall as its default route, resulting in firewall bypass. To add another layer of protection against this scenario, we add a security group that is self-referencing. This will allow all local traffic, but any packets sent to the virtual router that are destined to another subnet (within or outside the Amazon VPC) will be dropped, effectively creating an isolated subnet that only the firewall can connect to other subnets.

In Image 12, we have two subnets, each associated with a unique security group that references itself, plus a rule to allow SSH inbound. All instances in each subnet reference the same security group defined for that subnet.

Image 12: AWS console confirmation of bypass-avoidance configuration

Palo Alto Networks | VM-Series for AWS Hybrid Cloud Deployment Guidelines White Paper 15

We can test our bypass protection by attempting a web to database connection using first the firewall and then the virtual router. This will simulate a compromised web server attempting to bypass the firewall to attack the database. First, we see the firewall being used correctly as the default gateway.

ubuntu@web1:~$ netstat -rn

Kernel IP routing table

Destination Gateway Genmask Flags MSS Window irtt Iface

0.0.0.0 10.4.3.101 0.0.0.0 UG 0 0 0 eth0

10.4.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

ubuntu@web1:~$ ping -c 3 db1

PING db1 (10.4.5.201) 56(84) bytes of data.

64 bytes from db1 (10.4.5.201): icmp_seq=1 ttl=63 time=0.891 ms

64 bytes from db1 (10.4.5.201): icmp_seq=2 ttl=63 time=0.916 ms

64 bytes from db1 (10.4.5.201): icmp_seq=3 ttl=63 time=1.04 ms

--- db1 ping statistics ---

3 packets transmitted, 3 received, 0% packet loss, time 2002ms

rtt min/avg/max/mdev = 0.891/0.951/1.047/0.072 ms

Next, we see the effect of altering the default route to use the virtual router and attempt to bypass the firewall.

ubuntu@web1:~$ sudo route add default gw 10.4.3.1

ubuntu@web1:~$ sudo route del default gw 10.4.3.101

ubuntu@web1:~$ netstat -rn

Kernel IP routing table

Destination Gateway Genmask Flags MSS Window irtt Iface

0.0.0.0 10.4.3.1 0.0.0.0 UG 0 0 0 eth0

10.4.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

ubuntu@web1:~$ ping -c 3 db1

PING db1 (10.4.5.201) 56(84) bytes of data.

--- db1 ping statistics ---

3 packets transmitted, 0 received, 100% packet loss, time 1999ms

When the packet arrived on the virtual router, the web subnet security group was applied and the packet was allowed outbound; but when the database security group was applied, its inbound policy rejected the packet because it did not come from within the same security group. So the firewall cannot be bypassed by changing the default route, and the security of the Amazon VPC is maintained.

Scaling Your AWS DeploymentAs your AWS traffic and resource demands scale, you may need to add firewalls to provide additional security scale and redundancy. These additional firewalls can be automatically deployed using a combination of bootstrapping and AWS CloudFormation Templates (AWS CFTs). Bootstrapping allows you to create a complete VM-Series firewall configuration including licenses that can be deployed automatically on an as-needed basis using the AWS CloudFormation Templates scripting capabilities. More information on bootstrapping can be found here, while added documentation on AWS CFTs can be found here.

Auto Scaling the VM-Series for AWSThrough integration with AWS services, like Auto Scaling and Elastic Load Balancing (ELB), you can now build a next-generation security infrastructure that will dynamically, yet independently, scale to protect your AWS

Palo Alto Networks | VM-Series for AWS Hybrid Cloud Deployment Guidelines White Paper 16

workloads as their traffic patterns fluctuate. This architecture will allow you to reduce costs by utilizing the firewall capacities intelligently and efficiently, based on user-defined metrics. By scaling the security separate from the application workloads, each firewall can be identically configured and managed centrally, further lowering administrative costs. Auto scaling the VM-Series for AWS utilizes the following AWS services and VM-Series features:

• AWS CloudFormation Templates are used to deploy the entire solution as an all-inclusive package that is easy to roll out.

• AWS Lambda is used for several predefined services, such as: add network interfaces (ENIs) on newly deployed VM-Series instances, monitoring VM-Series traffic metrics, and communicating with Amazon CloudWatch.

• Amazon Simple Storage Service (Amazon S3) is used to store the VM-Series bootstrap configuration and the Lambda services. S3 storage can also be used to store other types of files, such as CloudFormation Templates used for additional automation.

• Amazon CloudWatch monitors your AWS workloads, collecting relevant statistics that can be used in conjunction with the VM-Series metrics to initiate the deployment or removal of a VM-Series Auto Scaling group.

• Bootstrapping (VM-Series) allows you to create a fully configured VM-Series firewall instance. Each bootstrapped firewall can include firewall configuration, security policies, and inclusion in a Panorama™ network security management device group.

• PAN-OS (VM-Series) API pulls user-defined metrics from the VM-Series firewall and uses Lambda to send them to CloudWatch.

How Auto Scaling the VM-Series for AWS WorksUsing an AWS CloudFormation Template, an initial VM-Series firewall is deployed using a bootstrapped image stored in Amazon S3. The AWS CloudFormation Template can also attach the VM-Series firewall to Panorama if it has been deployed.

When predefined traffic web server metrics are observed by Amazon CloudWatch, a scale-out event will deploy added web servers. An AWS Lambda function collects and sends VM-Series traffic metrics to CloudWatch, triggering a VM-Series scale-out event using the bootstrap VM-Series firewall image.

External ELB

Internal ELB

VPC

Web ASG

ASG1 ASG2

AZ2AZ1Region 1

VM-SeriesVM-Series

External ELB

Internal ELB

VPC

Web ASG

VM-Series VM-Series VM-Series

VM-Series VM-Series VM-Series

ASG1 ASG2

AZ2AZ1Region 1

Image 13: Initial AWS Auto Scaling environment

Image 14: Web server traffic demands initiate an Auto Scaling event for the VM-Series

The VM-Series Auto Scaling for AWS solution utilizes native AWS and VM-Series services to dramatically reduce the “friction” commonly associated with deploying and configuring a next-generation firewall on AWS. As your AWS workload traffic increases, demand for security increases as well. Integration with AWS Auto Scaling and Elastic Load Balancing will allow your VM-Series next-generation firewalls to scale automat-ically yet independently of your workloads, ensuring continual protection from cyberattacks.

Palo Alto Networks | VM-Series for AWS Hybrid Cloud Deployment Guidelines White Paper 17

Scaling the VM-Series with ECMPTo provide additional capacity and availability, the traffic should be directed across multiple firewalls. The simplest method of distributing the traffic is to use a routing protocol with equal-cost, multi-path (ECMP) capability. The VM-Series firewalls support ECMP using static routes as well as across both OSPF and BGP. Get more information on our support for ECMP.

Image 15: Sample firewall configuration for ECMP

Image 15 shows a sample firewall configuration for ECMP using static routes and weighted round-robin load balancing.

Image 16 depicts a scaled-up topology using ECMP to share the load across multiple firewalls per AZ. In this case, ECMP only needs to be configured on the private cloud firewalls on the left since SNAT is used on the virtual firewalls in the VPC to ensure symmetric return traffic.

Image 16: Scaling the topology using ECMP

AZ1

c A

Z1b Web1-01

Web1-02

Web1-03

Web2-01

Web2-02

Web2-03C4

VM-Series

C4

VM-Series

C4

VM-Series

C4

VM-Series

Private Data Center

DC-FW1

DC-FW2

VM-Series

Panorama

VMVMVM

VM

Palo Alto Networks | VM-Series for AWS Hybrid Cloud Deployment Guidelines White Paper 18

Scaling Security Using On-Premises Load BalancingAnother option to spread the traffic across multiple firewalls is to use the load balancer located in your data center. The advantage of using a load balancer is it can monitor the health of each path and make more intelligent decisions about where to send new sessions. The load balancer can be located in the private cloud that is configured to include resources in the public cloud as shown in Image 17. This solution has the advantage of having a single location to configure and scale the load balancer. The fact that some balanced instances are in the private cloud and some are in the public cloud is transparent.

Image 17: Static route topology configuration

As you can see, there are still multiple VPNs between the private and public clouds for redundancy. But, rather than use ECMP to distribute the load, you can configure specific static routes on the private cloud firewalls that use one firewall in one AZ for some of the servers, and the other firewall in the same AZ for the other servers. This allows the load balancer to better distribute the traffic load; but, if an Amazon VPC firewall fails, the other routes will kick in to avoid an outage.

Additional VM-Series for AWS Deployment Scenarios In addition to the hybrid deployment scenario discussed in this paper, the VM-Series for AWS can be deployed to address a number of different use cases, each of which takes full advantage of our next-generation firewall and advanced threat prevention features.

Internet-Facing Use CaseAn AWS deployment is not significantly different from building out a new physical data center, complete with a new perimeter firewall. In this use case, the VM-Series can be deployed as your gateway firewall, securing your applications and data within AWS. For more information on how to implement the VM-Series as an AWS gateway, please review the technical documentation.

Scalable Internet-Facing Use Case

Getting started with a single instance of the VM-Series is a common progression for AWS deployments. As your application environment scales, security needs to follow in lockstep. In this use case, we show you how to secure a highly available two-tiered application deployment comprised of a WordPress® web server, MySQL® database along with a DNS-based global load balancing web service, Citrix® NetScaler® load balancers, and several VM-Series firewalls. When complete, we have secured both north-south and east-west traffic flows to the applications in the Amazon VPC. To get started with this use case, please review the Scalable Internet-Facing Architecture documentation.

AZ1

c A

Z1b Web1-01

Web1-02

Web1-03

Web2-01

Web2-02

Web2-03C4

VM-Series

C4

VM-Series

C4

VM-Series

C4

VM-Series

Private Data Center

DC-FW1

DC-FW2 Panorama

Web0-01

https://www.paloaltonet-works.com/documen-tation/71/virtualiza-tion/virtu-alization/set-up-the-

Palo Alto Networks | VM-Series for AWS Hybrid Cloud Deployment Guidelines White Paper 19

GlobalProtect Remote Access Use Case

Securing mobile users from threats and risky applications is often a complex mix of procuring and setting up the security and IT infrastructure, ensuring uptime requirements in multiple locations around the globe, all while staying on budget. The scalability and global presence of the AWS computing infrastructure, combined with the VM-Series and GlobalProtect mobile security service, solves these challenges with a remote access VPN that extends your security policies to all of your remote users, regardless of their location. To see how you can use the VM-Series in AWS as a remote access solution, please review the GlobalProtect in AWS documentation.

VM-Series for AWS GovCloudFor AWS GovCloud users, the VM-Series can be deployed to protect applications and data from cyberattacks. Using the Bring Your Own License model, the VM-Series can be deployed in any of the use cases described above. Access the VM-Series from your AWS GovCloud account.

Try the VM-Series Firewall If you would like to evaluate the VM-Series firewall in your AWS account, we have created a step-by-step AWS CloudFormation Template guide that deploys the two-tiered environment discussed in this paper. The AWS CloudFormation Template deploys a WordPress Server, a relational database and a 15-day, free trial version of the VM-Series Bundle 2 that is comprised of a VM-300 firewall along with Threat Prevention, WildFire, URL Filtering, GlobalProtect and Premium Support.

Image 18: Two-tiered topology deployed by the AWS CloudFormation Template

It is important to note that this AWS CloudFormation Template will deploy new services in your AWS account so please make sure you are comfortable with making changes in that account and that those changes and related AWS charges will not negatively impact any existing workload running in your AWS account. You may want to create a temporary test environment in your AWS account that is NOT used for applications or services in production environment. Download the step-by-step guide.

z A

Z1b

Web1

DB1

C4

VM-SeriesDB1

Web1

4401 Great America ParkwaySanta Clara, CA 95054

Main: +1.408.753.4000Sales: +1.866.320.4788Support: +1.866.898.9087

www.paloaltonetworks.com

© 2016 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto Networks. A list of our trademarks can be found at http://www.paloaltonetworks.com/company/trademarks.html. All other marks mentioned herein may be trademarks of their respective companies. vm-series-for-aws-hybrid-cloud-deployment-guidelines-wp-101916

© 2016, Amazon Web Services, Inc. or its affiliates. All rights reserved.

ConclusionOne of the key value propositions of AWS is the process of automating the deployment of your applications so you can be more agile and more scalable. The resources and implementation steps outlined in this document can help you get started quickly, establishing a baseline AWS environment that you can expand and modify as needed.

About AWS:

For 10 years, Amazon Web Services has been the world’s most comprehensive and broadly adopted cloud platform. AWS offers over 70 fully featured services for compute, storage, databases, analytics, mobile, Internet of Things (IoT) and enterprise applications from 35 Availability Zones (AZs) across 13 geographic regions in the U.S., Australia, Brazil, China, Germany, Ireland, Japan, Korea, Singapore, and India. AWS services are trusted by more than a million active customers around the world – including the fastest growing startups, largest enterprises, and leading government agencies – to power their infrastructure, make them more agile, and lower costs. To learn more about AWS, visit http://aws.amazon.com.