VM-SERIES FOR AWS HYBRID CLOUD DEPLOYMENT GUIDELINES

Transcription

1 SERIES FOR AWS HYBRID CLOUD DEPLOYMENT GUIDELINES 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 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 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. Palo Alto Networks for AWS Hybrid Cloud Deployment Guidelines White Paper

2 Table of Contents 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 for AWS 5 for AWS Licensing 5 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 for AWS 7 Hybrid Cloud Topology Overview 7 VPC Subnets and the Internet Gateway 8 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 for AWS 15 How Auto Scaling the for AWS Works 16 Scaling the with ECMP 17 Scaling Security Using On-Premises Load Balancing 18 Additional for AWS Deployment Scenarios 18 Internet-Facing Use Case 18 Scalable Internet-Facing Use Case 18 GlobalProtect Remote Access Use Case 19 for AWS GovCloud 19 Try the Firewall 19 Conclusion 19 Palo Alto Networks Securely Enabling a Hybrid Cloud in Microsoft White Paper 2

3 The Business Case for AWS Customers 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 Responsibility AWS 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. Customer Content Platform, applications, identity & access management Operating system, networks and firewall configuration Encryption key management Client & server encryption Network traffic protection Customers are responsible for their security IN the cloud AWS Foundation Services Compute Storage Database Networking AWS Global Infrastructure Compute Availability zones Regions Edge locations AWS looks after the security OF the platform htt co sh ty Image 1: AWS Shared Responsibility Model diagram Palo Alto Networks for AWS Hybrid Cloud Deployment Guidelines White Paper 3

4 Security Challenges in AWS Many 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 boltedon 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 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 Firewall In 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 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 for AWS Hybrid Cloud Deployment Guidelines White Paper 4

5 for AWS Whereas Security Groups and a WAF provide some initial filtering or highly customized web-application security, the Palo Alto Networks for AWS allows you to protect your AWS deployment from cyberattacks delivered by all types of applications, across all ports. The 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: z DB1 Web1 AZ1b 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. for AWS Licensing The 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 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: 300 firewall license, Threat Prevention subscription (inclusive of IPS, AV, and malware prevention), and Premium Support. Bundle 2 contents: 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 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 is now available as a BYOL here (login required). 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 are listed below. AWS Instances: The 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, 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. Palo Alto Networks for AWS Hybrid Cloud Deployment Guidelines White Paper 5

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 Worlds A 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 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 firewall is recommended, including when Direct Connect is used. More information about this service can be found at: Private Data Center Public Cloud Web1 DB1 z DB1 Web1 AZ1b IPsec VPN 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 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 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. Palo Alto Networks for AWS Hybrid Cloud Deployment Guidelines White Paper 6

7 Hybrid Cloud Benefits The 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 Transparency An 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 endto-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 firewalls in the VPC(s). These routes can then be dynamically shared with your onpremises 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 Security One of the other key benefits that the provides is feature consistency with respect to our appliancebased 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 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 for AWS Hybrid Cloud Deployment Guidelines White Paper 7

8 Building a Secure Hybrid Cloud with the for AWS The remainder of this paper illustrates specific considerations for building a secure hybrid cloud on AWS with the. We recommend that you use this document in conjunction with the for AWS technical documentation. Hybrid Cloud Topology Overview When 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. Panorama DC-FW1 DC-FW2 VM VM IPsec VPN VM VM Web1-01 Web1-02 Web1-03 Web2-01 Web2-02 AZ1c AZ1b Web2-03 Private Data Center Image 3: Detailed hybrid cloud topology within AWS In our hybrid cloud topology, shown in image 3, each AZ gets one 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 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 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. VPC Subnets and the Internet Gateway An Amazon VPC connects to the internet using an internet 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 External Subnet2 External Subnet1 Internal Subnet2 Internal Subnet1 Web1-01 Web1-02 Web1-03 Web2-01 Web2-02 Web2-03 AZ1c AZ1b Palo Alto Networks for AWS Hybrid Cloud Deployment Guidelines White Paper 8

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 for AWS Integration At this point, you have established your subnets and can now deploy the 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 in a multi-subnet Amazon VPC. Once the 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 firewalls. Palo Alto Networks for AWS Hybrid Cloud Deployment Guidelines White Paper 9

10 Establishing Your IPsec VPN Connections The, 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 firewalls and any standards-based VPN device, including another Palo Alto Networks firewall. The steps for creating a site-to-site VPN in the 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 firewall VPN configurations and status in AWS. Image 7: VPN configuration screen images from the management interface Palo Alto Networks for AWS Hybrid Cloud Deployment Guidelines White Paper 10

11 Here are sample CLI commands showing IKE gateway and IPsec association status. 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 Phase IKE-GW-1 Init Main PSK/ DH2/A128/SHA1 Nov.06 15:06:07 Nov.06 23:06:07 v 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 IKE-GW-1 Init ESP/ DH2/tunl/SHA1 DC D5F2 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) tunnel1(ike-gw-1) ESP/A128/SHA1 DC D5F2 1627/0 Show IPSec SA: Total 1 tunnels found. 1 ipsec sa found. Ensuring All Traffic Flows Through the Firewall There 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 Propagation Once 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. Panorama DC-FW1 DC-FW2 IPSec VPN z DB1 Web1 AZ1b VM VM VM VM Image 8: Two-tiered, hybrid cloud topology Palo Alto Networks for AWS Hybrid Cloud Deployment Guidelines White Paper 11

12 There are two subnets in the public cloud attached to the 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 /24 and /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 /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 for AWS Hybrid Cloud Deployment Guidelines White Paper 12

13 ping -c 3 db1 PING db1 ( ) 56(84) bytes of data. 64 bytes from db1 ( ): icmp_seq=1 ttl=63 time=1.04 ms 64 bytes from db1 ( ): icmp_seq=2 ttl=63 time=0.910 ms 64 bytes from db1 ( ): icmp_seq=3 ttl=63 time=0.855 ms --- db1 ping statistics 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 ( ) 56(84) bytes of data. 64 bytes from db2 ( ): icmp_seq=1 ttl=62 time=21.5 ms 64 bytes from db2 ( ): icmp_seq=2 ttl=62 time=21.9 ms 64 bytes from db2 ( ): icmp_seq=3 ttl=62 time=21.5 ms --- db2 ping statistics packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = /21.659/21.920/0.186 ms ubuntu@web1:~$ Preventing Firewall Bypass For 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, 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 for AWS Hybrid Cloud Deployment Guidelines White Paper 13

14 And we let the server instances point to the virtual router of the subnet. netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface UG eth U 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 UG eth U 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 for AWS Hybrid Cloud Deployment Guidelines White Paper 14

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 UG eth U eth0 ubuntu@web1:~$ ping -c 3 db1 PING db1 ( ) 56(84) bytes of data. 64 bytes from db1 ( ): icmp_seq=1 ttl=63 time=0.891 ms 64 bytes from db1 ( ): icmp_seq=2 ttl=63 time=0.916 ms 64 bytes from db1 ( ): icmp_seq=3 ttl=63 time=1.04 ms --- db1 ping statistics 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 ubuntu@web1:~$ sudo route del default gw ubuntu@web1:~$ netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface UG eth U eth0 ubuntu@web1:~$ ping -c 3 db1 PING db1 ( ) 56(84) bytes of data. --- db1 ping statistics 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 Deployment As 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 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 for AWS Through 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 for AWS Hybrid Cloud Deployment Guidelines White Paper 15

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 for AWS utilizes the following AWS services and 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 instances, monitoring traffic metrics, and communicating with Amazon CloudWatch. Amazon Simple Storage Service (Amazon S3) is used to store the 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 metrics to initiate the deployment or removal of a Auto Scaling group. Bootstrapping () allows you to create a fully configured firewall instance. Each bootstrapped firewall can include firewall configuration, security policies, and inclusion in a Panorama network security management device group. PAN-OS () API pulls user-defined metrics from the firewall and uses Lambda to send them to CloudWatch. How Auto Scaling the for AWS Works Using an AWS CloudFormation Template, an initial firewall is deployed using a bootstrapped image stored in Amazon S3. The AWS CloudFormation Template can also attach the firewall to Panorama if it has been deployed. VPC ASG1 External ELB ASG2 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 traffic metrics to CloudWatch, triggering a scale-out event using the bootstrap firewall image. AZ1 Web ASG Region 1 Internal ELB AZ2 Image 13: Initial AWS Auto Scaling environment VPC AZ1 ASG1 Web ASG AZ2 Region 1 External ELB ASG2 Internal ELB Image 14: Web server traffic demands initiate an Auto Scaling event for the The Auto Scaling for AWS solution utilizes native AWS and 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 next-generation firewalls to scale automatically yet independently of your workloads, ensuring continual protection from cyberattacks. Palo Alto Networks for AWS Hybrid Cloud Deployment Guidelines White Paper 16

17 Scaling the with ECMP To 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 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. Panorama DC-FW1 DC-FW2 Web1-01 Web1-02 Web1-03 Web2-01 AZ1c AZ1b Web2-02 VM VM VM VM Web2-03 Private Data Center Image 16: Scaling the topology using ECMP Palo Alto Networks for AWS Hybrid Cloud Deployment Guidelines White Paper 17

18 Scaling Security Using On-Premises Load Balancing Another 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. Panorama DC-FW1 DC-FW2 Web1-01 Web1-02 Web1-03 Web2-01 AZ1c AZ1b Web2-02 Web0-01 Web2-03 Private Data Center 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 for AWS Deployment Scenarios In addition to the hybrid deployment scenario discussed in this paper, the 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 Case An 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 can be deployed as your gateway firewall, securing your applications and data within AWS. For more information on how to implement the as an AWS gateway, please review the technical documentation. h w p w d t v ti a s Scalable Internet-Facing Use Case Getting started with a single instance of the 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 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. Palo Alto Networks for AWS Hybrid Cloud Deployment Guidelines White Paper 18

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 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 in AWS as a remote access solution, please review the GlobalProtect in AWS documentation. for AWS GovCloud For AWS GovCloud users, the can be deployed to protect applications and data from cyberattacks. Using the Bring Your Own License model, the can be deployed in any of the use cases described above. Access the from your AWS GovCloud account. Try the Firewall If you would like to evaluate the 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 Bundle 2 that is comprised of a 300 firewall along with Threat Prevention, WildFire, URL Filtering, GlobalProtect and Premium Support. z DB1 Web1 AZ1b 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. Palo Alto Networks for AWS Hybrid Cloud Deployment Guidelines White Paper 19

20 Conclusion One 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 Great America Parkway Santa Clara, CA Main: Sales: Support: Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto Networks. A list of our trademarks can be found at All other marks mentioned herein may be trademarks of their respective companies. vm-series-for-aws-hybrid-cloud-deployment-guidelines-wp , Amazon Web Services, Inc. or its affiliates. All rights reserved.