appgate® xdp for aws · aws access key with read access to ec2 youll also need an aws access key...

AppGate® XDP for AWS Step-by-Step Setup Guide

Last revised November 22, 2016

AppGate XDP for AWS Step-by-Step Guide Page 1

Welcome & Overview Enterprises continue to rapidly embrace Amazon Web Services (AWS), but securing access to these

cloud-based workloads can be a challenge. AppGate XDP is purpose-built for the AWS environment and

draws on user context to dynamically create a secure, encrypted network ‘segment of one’ that’s

tailored for each user session. It dramatically simplifies the cloud resource user access challenge and

eliminates IP-based over-entitled network access. AppGate XDP provides a means for security teams to

efficiently and effectively control user access to EC2 resources.

AppGate XDP is a distributed network access control system that creates a unique access filter for each

user/device combination. This patent pending access system dynamically matches the context

information from the user and device with the context information it polls in real-time from the cloud

provider. Users, devices and their context can now be matched by the XDP policy engine to allow access

to and only to the desired instances.

With simple policies in place, network access automatically adapts in real-time to changing conditions

on the client as well as on the cloud infrastructure side. Every new instance that will be added or

removed will now automatically be traced and added or removed from the access filter, without the

need of changing the policies. It becomes an automation-driven network access process that can be

audited by simple policies.

Let’s take a look at how we’re going to be setting up the AppGate XDP server (designated by the icon

in the diagram below). AppGate XDP acts as a dynamic network gateway between users and protected

resources running in AWS.

All user traffic is tunneled from their device (via a virtual network adapter, similar to a VPN client), and

passed through the AppGate XDP gateway to the protected resources. Client traffic to the AppGate XDP

gateway is encrypted, so these resources can be securely accessed regardless of location. And the set of

protected resources is dynamically adjusted, automatically responding to changes in the AWS

environment.

As you’ll see, this is much more dynamic and flexible than a firewall – we’ll be setting policies that

control user access based on user attributes, and on server attributes (such as AWS tags).


This Getting Started guide will take you through the steps necessary to set up and configure AppGate

XDP to protect your AWS resources. We also have a video walkthrough of this step-by-step

configuration, available on the AppGate XDP for Amazon Web Services resources page here:

https://www.cryptzone.com/resources/aws-resources

Getting Started There are four steps to getting your AppGate XDP system running, plus some basic pre-requisites:

0. AWS Pre-requisites

1. Create the EC2 AMI instance for the AppGate XDP system

2. Seed the AppGate XDP server from the SSH command time

3. Configure the server through the AppGate XDP administrative GUI

4. Install the client, and test it out!

The Pre-Requisites are noted below – in short, you’ll just need to be set up with a VPC that has an

appropriate subnet, and an available Elastic IP address.

Step 1 is very straightforward, and is something you’ve likely done dozens (if not hundreds) of times.

We’re including this for completeness, and because there are a couple small details that it’s important

to get right, in particular the security group.

Step 2 is also very straightforward – after securely logging in to the server via SSH, you’ll seed the

appliance with some basic configuration details such as the administrative passwords.

Step 3 is where it gets interesting, as you’ll be using the AppGate XDP admin GUI to configure policies,

resources, and users. This is the bulk of the setup work, as we’ll be introducing you to the AppGate XDP

policy and entitlement model.

And Step 4 is where it all comes together, and you can see AppGate XDP in action, dynamically

protecting your AWS resources.

So let’s get started – in about 20 minutes you’ll have the system up and running, and will be playing with

different polices and user access rights!

https://www.cryptzone.com/resources/aws-resources


Pre-Requisites This document assumes that you’re familiar with AWS EC2, and have some experience creating AMIs,

and setting up a VPC, subnet, Internet Gateway, and Router within AWS. If not, or if you need a

refresher, please take a look readily available online resources, such as the AWS documentation here:

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Networking.html

Let’s briefly explain what you’ll need in your environment to set up AppGate XDP to protect your

resources:

VPC You should have a Virtual Private Cloud (VPC) be set up with its own subnet that the AppGate XDP

Gateway is going to protect. This can be an existing VPC, or a new one. In any case, instances running in

this VPC must already be accessible from the internet with an Internet Gateway set up properly.

You probably already have multiple VPC already set up, so just choose one of those to use for testing out

AppGate XDP.

Keep in mind that we’re going to route all traffic to all instances in the VPC through the AppGate XDP

security appliance, so the VPC should be only be hosting dev or test workloads – access will be

interrupted during this setup process, and will require use of the AppGate XDP client after we’ve got it

set up.

In this setup guide, we’re assuming that you have a subnet setup with a contiguous address space in

which the protected resources will be placed. In our example, we’re using 10.5.0.0/24, as shown below.

What’s important about this is it has an Internet Gateway setup in AWS with a routing table that allows

traffic into it. If you can currently access resources within the VPC, you’re likely already set up this way.

Elastic IP Address Because AppGate XDP is a network security server, the instance requires a fixed IP address. This is

important, since clients will cache the server’s IP address, and its certificate is associate with the IP

address. So, make sure that you have an Elastic IP address available to associate with it, or be prepared

to re-associate one.

AWS Access Key with read access to EC2 You’ll also need an AWS Access Key ID (and Secret Access Key) set up, which has read access rights

within EC2. The following Policy is a good one to assign to the user, if you haven’t already done so, since

the AppGate XDP server only requires read-only access.

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Networking.html


But what about Security Groups? Good question! Of course both the AppGate XDP server and the protected resources will need properly

configured security groups. We’ll create these during the setup process below.

Browser Compatibility: Note: Due to an issue with Internet Explorer’s support for sites using TLS1.2 and SHA-512 hashed

certificates, Internet Explorer is not compatible with the AppGate XDP administrative console. Please use

a supported browser such as Chrome or Firefox for the administrative steps in the Admin GUI

Configuration section below.

Step 1: AMI Creation

In this Step, we’re going to launch the AMI for the AppGate XDP server. The screenshots below follow

the launch process from within the EC2 console, but if you choose to use the 1-Click Launch option, the

configuration settings should be set to the same as below.

1.1 Create the EC2 instance for the AppGate XDP system First, select the appropriate AppGate XDP image in the AWS marketplace, and click Continue to begin

the launch process within the EC2 Console:


1.2 Configure Instance Details Note: The screen shots below are for the Manual Launch option, but the same settings will apply if you

choose to use the 1-Click Launch instead.

Choose the Instance Type.

We recommend using t2.medium for initial testing purposes. Production environments should be sized

according to anticipated user and network load – our default recommended setup is to use the m4.large

instance size. Visit the AppGate XDP community site for further information.

Next, select the correct Network and Subnet as we discussed in the Pre-Requisites section. Also, the

auto-assign of Public IP should be off, since later we’re going to associate this with an Elastic IP address

instead.

Configure Instance Details

http://cryptzone.vbulletin.net/


Leave the Network Interface as the default, with eth0 as the active device.

Leave the Advanced Details blank; we’re not using them.

You can leave the Storage settings as default – 20GB is sufficient unless you’re going to be doing some

significant logging.

Select a descriptive name in the Tag section


1.3 Create a new Security Group for the AppGate XDP Server Now, for an important step – configuring the Security Group for the AppGate XDP server. Recall that

AppGate XDP is a network gateway, which tunnels encrypted client traffic through it to the protected

resources. (We’ll set up the security group for the protected resources in a later step).

The AppGate XDP security group only needs 3 ports open, and 2 of them only need to be accessed by

you as the admin. Take a look at the diagram below.

So we may only need three rules in our security group! Let’s set them up as follows:

Port 443 This is the port that the AppGate XDP gateway uses to tunnel all client traffic through. AppGate XDP

decrypts the traffic, and sends it on to its destination, which is one of the protected resources.

So, port 443 should be open to all IP addresses that your users may be accessing it from. You can start

by opening it for your current IP address (keeping in mind that you may need to expand this list later, for

example if you’re accessing this from home, or from a different location).


The next two ports are used only for administrative access as follows:

Port 444 This port is used for the admin GUI, and needs to be opened to your IP address

Port 22 This port is used one time, for you to SSH into the server to seed it. We need to enable it for now, but

can turn it off after our initial seeding.

So our security group should look as follows (with your IP address instead of mine, obviously):

Then, confirm the launch details, and click the Launch button to create the instance.

Important – choose an existing key pair, or create a new one appropriately. You will need this key pair in

order to SSH into the newly launched server and configure it.

1.4 Associate the Elastic IP address with the instance While the server is launching, we need to associate an Elastic IP address with it, so that it has a fixed IP

address.

Click on Elastic IPs in the Network & Security section of the AWS console, select the unassociated Elastic

IP address (which was one of the pre-requisites), and associate it with this instance. Your configuration

should look something like the following:


Once the server has launched and initialized, we can proceed to the next step, which is seeding the

server.


Step 2: AppGate XDP Seeding

This step is straightforward, we just need to log in to the server via SSH, and run a simple menu-driven

setup tool.

Once the AWS instance has initialized in the steps above, which will take 1-2 minutes depending on the

instance size you chose, connect to it on the Elastic IP address with SSH, using the key pair you selected

above.

Important: Be sure to login with the username “cz”, which is the username that will match the key pair.

Once connected, you should see the following:

As displayed in the prompt, we’re going to run sudo cz-setup to configure the appliance.

cz-setup is a simple menu-driven configuration tool. While it has many options, we only need to set a

few for our AWS scenario:

Hostname

Enable DHCP for our network adapter

Set passwords for the administrative accounts

o user cz is only used to log in via SSH. Setting this will eliminate the need to use the AWS key pair,

and will enable to run other admin commands via sudo. Note that you won’t need to SSH into

this server very frequently, if at all.

o user admin is the primary administrative login for the AppGate XDP GUI, and you’ll be using this

login a lot.

Let’s get started: run sudo cz-setup to launch the setup tool, and you’ll see the menu-driven

configurator below. Use the up ↑ and down ↓ arrow keys to highlight items, and Enter to select them.


Select “Configure appliance as first Controller”

Then, select “Hostnames”:

For internal hostname, enter the publicly resolvable name assigned by AWS. This will

automatically be copied to the other two hostname rows, as shown below

Hit Esc to return to the top level menu, and then select Network Interfaces

And then Configure eth0:


Confirm that your settings match what’s shown below:

Hit Esc twice to return to the top level menu, and then select DNS Servers, and Add DNS Server.

Enter 8.8.8.8, to use the Google DNS.

\

Hit Esc to return to the main menu, and then select Administrator passwords.

Set passwords for the admin user. Note that you’ll be using the admin login for the GUI console starting

in the next step.


Hit Esc to return to the top-level menu, and then select Apply configuration:

You’ll see a status message like the following while the configuration is applied, which typically takes 1-2

minutes.

Once that completes, you’ll see a confirmation message, which shows the URL for the admin GUI. Make

a note of this URL, or copy & paste it into your browser for our next step.

Then, return to the main menu and select Exit to complete this configuration.


Once you’ve returned to the SSH command line, you can exit from your SSH session, and proceed to the

next step, which uses the AppGate XDP admin GUI. Note: Ignore the text regarding “cz” user in the

window.


Step 3: Admin GUI Configuration Note: Due to an issue with Internet Explorer’s support for sites using TLS1.2 and SHA-512 hashed

certificates, Internet Explorer is not compatible with the AppGate XDP administrative console. Please

use a supported browser such as Chrome or Firefox.

3.1 Logging in as Admin Give the server about 1 minute to apply the configuration in the step above, and then open the URL

noted above – note that the format:

https://ec2-52-22-34-105.compute-1.amazonaws.com:444 uses https, but connects

on port 444. When you open this URL in your browser, you’ll likely see a security warning since the

connection uses HTTPS into an AWS domain, while the server uses a self-signed certificate. You can

safely ignore this warning and proceed to the login page.

Next, you should see the login screen for the admin console. With the Identity Provider on its default

“local” setting, enter the username “admin”, and the admin password you chose above in the SSH

session.

https://ec2-52-22-34-105.compute-1.amazonaws.com:444/


Click Login, and you should be taken to the AppGate XDP dashboard.

Take a moment to look at the interface, and we’ll take you through it one step at a time.

The right-hand side of the dashboard shows the current system status, including the number of

components in the overall AppGate XDP system. The left side of the menu controls the Operations,

which is for management of user access to protected resources, and Configurations, which is for

administrative management of the appliance itself.


You can see that we have one appliance, which currently has 0 Gateways, 1 Controller, and 1 LogServer.

The Controller is the “brain” for the system, the LogServer handles the logging, while the Gateway

manages all client traffic to protected resources.

To get started, we need to configure a Gateway for the system, which manages a Site, which in turn

protects resources (our AWS servers). As shown below, each Gateway is associated with one Site, and

within each Site are multiple Resources.

The Site is also where the resource name resolution is set up, to enable dynamic detection of newly

created AWS EC2 instances. Next, let’s get started with the Site.

3.2 Create a Site

Under the Configurations menu, select “Sites”, and click

Give it a friendly name like “AWS VPC Site”, and configure the sections as follows:

Network Subnets

Create a new subnet by clicking the + button, and entering the subnet in CIDR notation. It’s very

important that this subnet matches what you’ve already set up for your VPC! (Note that this subnet can

be smaller than your VPC’s subnet, but must be well-formed and have sufficient IP addresses for the

servers you’ll be protecting with AppGate XDP).

User Tunneling

This section should remain as the default, shown below.


Name Resolution

For this section, we’re just setting up an AWS resolver, and not using a DNS or Azure resolver.

Give this a friendly name, and leave the update interval at its default (this is how frequently the AppGate

XDP server calls into AWS to check for server changes).

Enter your AWS Access Key ID, and Secret Access Key, so that the AppGate XDP server can query the

status of your EC2 instances in your VPC. Note that AppGate XDP needs just read-only access, so we

recommend giving it an Access key with limited authorization. (See the AppGate XDP documentation

here https://help.cryptzone.com/adminguide/name-resolvers.html for details and a sample policy).

Make sure that HTTPS Verify Cert and VPC Auto Discovery are checked, and leave the HTTPS Proxy

empty. Click + to create a region, and enter your AWS region in the compact region format such as

us-east-1. Official EC2 region names are shown here:

http://docs.aws.amazon.com/general/latest/gr/rande.html

Click Save Changes to save the Site.

https://help.cryptzone.com/adminguide/name-resolvers.html

http://docs.aws.amazon.com/general/latest/gr/rande.html


3.3 Configure the Site and the Gateway in the Appliance Next up, we set the Appliance to use our newly created Site, and configure the Gateway. In the

“Configurations” menu, select “Appliances”, and then click the one appliance in the list to edit it.

First, in the Site dropdown in the Basic Settings section, select the Site we just created. Leave the rest

of the Basic Settings section unchanged, and proceed to the Gateway below.

Under the Gateway Section, make sure Enabled is checked. Then open the Allow Destinations section

under the User Tunneling (VPN) section. (Leave Weight at 100).

Under Allow Destinations, click + to create a new destination, and enter the subnet as shown.

Important: This subnet must match the subnet defined for the Site above! Note that this uses a slightly

different format (not CIDR), with the netmask entered on a separate line. The NIC should be eth0 (which

should be the only NIC set up for the appliance).

Then click Save Changes to complete this step.


3.4 Create (or Choose) an AWS Instance to Protect Now, select an existing AWS instance, or create a new one to test out access via AppGate XDP. We

recommend using a simple preconfigured web server, such as Tomcat Powered by Bitnami. What’s

important is that the service you choose should have a web server running on port 80, since that’s what

we’ll be configuring our first policy to permit.

You’re familiar with launching EC2 instances, so we’re not going to take you through this step-by-step,

but we are going to point out a few things that are important to set up correctly:

Subnet and VPC

o Make sure that this instance is assigned to the VPC and subnet that we configured AppGate XDP

to protect

o This instance must not be allocated a public IP address

AWS Tag

o We’re going to be using the AWS tag to resolve this instance, so give it the tag

app-type=employee-app as shown below.

Without this tag, our resolver won’t be able to find this resource.

Security Group

We need to make sure that this instance is only accessible from the AppGate XDP server, so while

launching, create a new security group that allows all TCP and ICMP traffic, but only from the private IP

address for the AppGate XDP server. In our example, its 10.5.0.85, but in your case, look at the running

AppGate XDP instance in your EC2 console to find the internal IP address (it’ll be within the managed

subnet address space).

Now, complete the launch process for the resource. It’ll launch and get assigned a private IP address

within the subnet. You won’t be able to access it, since there’s no network route for you yet.

In our next steps we’ll create the policy that will let you access this resource.


3.5 Create an Entitlement Policies and entitlements are the primary tools for provisioning and controlling user access to resources

protected by the Gateways. Entitlements define what network access a user is permitted to have, and

the conditions requried for that access to be allowed. As shown in the diagram below, entitlements are

attached to policies. Policies use filters to control which entitlements are available to which users.

The diagram below shows the policy and entitlement that we’re going to be creating:

The entitlement allows HTTP access to any server in our site that has the tag app-type=employee-app. Our

dynamic AWS resolver will automatically detect new EC2 instances in our VPC, and grant access if they have

this tag.

o In this example, we chose not to associate a Condition, which is an addiitonal restriction that’s checked at

time of access. This can be used to enforce restrictions on network location, time of day, or to apply step-

up authentication. (We’re keeping it simple for this example and not using any of those!)

The Policy binds the entitlement to a filter, which defines the set of users who can access this entitlement. In

our example, we’re going to let any user with a tag employee get access. (The user tag is metadata within the

AppGate XDP system, and is completely separate from the AWS tag used for EC2 instances).

In our example, we need to create an entitlement with the AWS resolver format:


Step 1: Create entitlements to access target resources: AppGate XDP supports IP access (TCP, UDP and ICMP v4 and v6). From the AppGate XDP main Menu, select Entitlements Create Entitlement. Give it a name – in this case we have chosen the name AWS employee app type. Next, we’ll specify the entitlement Action and link the entitlement to a Site. Click the + button under Actions to create a new action

Configure the Action as shown below:

Rule should be Allow

Protocol should be tcp up (meaning that it’s allowing TCP traffic initiated from the client up to the server. Return traffic is automatically allowed)

Port should be 80 for this example, since we’re permitting HTTP traffic

The Host specified as using our dynamic resolver syntax: o aws://tag:app-type=employee-app

Note that each entitlement can include a number of entitlement actions, so you can use entitlements to group actions that relate to a particular site. For this example, let’s just keep it simple with our one port 80 action.

For Site, select the site we created above from the drop-down list:


Conditions: Each entitlement can include one or more conditions to provide real-time control over how the entitlement is used. Conditions are evaluated at the time a user attempts to access a resource. Examples include only allowing access to a service during working hours, or requiring the user to re-enter their password before gaining access to sensitive resources. If no condition is included in the entitlement, the entitlement action is available Always by default. For this example, let’s leave the Conditions blank, so it always applies. Your example should like something like the following:

Click Save Changes, and let’s move on to the next step…creating a User.


3.6 Create a User

In order to create a User, you will need to select Identity Providers then click on MANAGE USERS

The following screen will appear. Click on NEW LOCAL USER.

Once you have clicked on New Local User, add a new user as shown in the next diagram.


Note:

Make note of the username and password, since we’ll be using that to sign in from the AppGate XDP

client in a later step.

The email address is required as a unique identifier, but the AppGate XDP system doesn’t send any

email to the address.

Important: Make sure to add the employee tag to the user! This tag is how the Policy Filter will know to

grant Sally access to our Entitlements. To do this, type “employee” in the field labeled “search for tags”,

and press the Tab key to apply the tag to the user.

Next, we create the filter that picks up this employee tag.


3.7 Create a Filter Before you create a Filter, it’s important to understand what they are. Filters are used by the Controller to assign policies to a user, which in turn grant access entitlements. Once the user has been authenticated, the Controller uses the filters to identify whether a policy is valid for that user. A filter expression might use claims (user attributes) such as username or AD group membership. When

the claims in the filter expression are True, the policy is assigned to the user and the entitlements within

the policy will be included in the user's entitlement set. Now that you know what a Filter is, let’s create

a Filter.

From the main menu, select Filters, then +NEW FILTER.

Name the filter Employee, and click the + to add a new expression. Click on the Choose One dropdown

to display the set of attributes that can be used in the filter. You can see that there’s a rich set to choose

from! For now, just select tags, and then enter employee in the entry field. (This is how the filter will

pick up our newly created user, Sally, to whom we applied the employee tag in an earlier step).

Be sure to Save your changes, before we move to the next step.

3.8 Create a Policy Now we’ll create the policy that allows our employee users to access employee-app entitlements by

clicking on + NEW POLICY.


You will then see the Create Policy form below. In this example, we have named the policy Employee

Access to Employee Apps.

In the Filters section, enter the name of the Employee filter we created above – it’ll appear in the auto-

completion list for you to select.

Likewise, enter the AWS-employee-app-type entitlement. Once your Policy looks like the image below,

save it.


Step 4: Install the Client

The last step is to install the Client.

Recall that the AppGate XDP client installs as a virtual network adapter, which provides remote,

encrypted access to resources. Because it works like a network adapter, it requires local admin privileges

to install.

The client installer is available from either of these 2 methods:

From within the web browser console, at the following URL

o https://<<hostname>>:444/download/

o For example, https://ec2-52-22-34-105.compute-1.amazonaws.com:444/download/

Or, from the Cryptzone website at:

o https://www.cryptzone.com/downloadcenter/appgate-xdp

Client installation is a straightforward process, and is not shown here.

4.1 Log in with the Client The last step in setting up AppGate XDP is to log into the controller.

The first time you’re logging in to the controller, you’ll need to accept its certificate, as shown below.

https://ec2-52-22-34-105.compute-1.amazonaws.com:444/download/

https://www.cryptzone.com/downloadcenter/appgate-xdp


Click OK, and then you’re ready connect!

As shown above, make sure Identity provider is set to local, and enter the username and password for

the user we created above.

Once connected, you should see the client look as follows:

When minimized, the client will show as an AppGate XDP icon the in the taskbar. On Windows, it looks

as follows:

Now, you’re ready to access the protected server through AppGate XDP!


4.2 Test out Access! Go ahead and open the protected resource, using the private IP address. It should work!

You are now using AppGate XDP to protect your AWS resources! With simple policies in place, network

access automatically adapts in real time to changing conditions on the client as well as on the cloud

infrastructure side. You can be assured every new instance that is added or removed will now

automatically be traced and added or removed from the access filter, without the need of changing the

policies. It is now an automation-driven network access process that can be audited by the simple

policies you created. This means less work for you and the right protection for your resources!

What if it Didn’t Work? If you’re unable to load the Tomcat page (or the equivalent in your protected resource):

Double-check that it’s running, and has an IP address in the subnet that the Gateway is protecting

Make sure the Site and Gateway configurations are correct, as shown above

Double-check the security group settings

SSH into the AppGate XDP server again, and try pinging the protected resource (because this isn’t

going through the AppGate XDP Gateway, there’s no need to set up a policy for this entitlement)

Make sure that your resource has the appropriate tag, and that the Entitlement resolver uses the

same tag (app-type=employee-app).

Make sure your user has the tag employee within AppGate XDP, and that your access policy has the

corresponding filter set up.

If you’re still stuck, or have questions or comments, feel free to connect with us on the AppGate XDP for

AWS Community site at: https://cryptzone.vbulletin.net/

https://cryptzone.vbulletin.net/


4.3 Additional Things to Try Now that you’ve gotten AppGate XDP working with your first access policy, have some fun. Here are a

few things to try out:

Add an ICMP entitlement so that our user, Sally, can ping the Tomcat server

Try tagging a few more AWS instances with the app-type=employee-app tag, to see how user access

is automatically assigned

Try creating different Entitlements, Filters, and Policies

Resources and Community Cryptzone has an online AppGate XDP for AWS community here https://cryptzone.vbulletin.net/

We encourage you to register and join the conversation! Here you will find information from other

AppGate XDP for AWS users and the experiences they’ve had getting up and running as well as using it

on a day-to-basis.

In addition to the AppGate XDP for AWS online community, you’ll find additional resources on the

Cryptzone website here: https://www.cryptzone.com/products/secure-access/appgate-xdp/aws

And the AppGate XDP product documentation is available here:

Admin Guide: https://help.cryptzone.com/adminguide/index.html

Client User Guide: https://help.cryptzone.com/userguide/v2.1/

Thank you, and we hope you find AppGate XDP to be a valuable solution to your security challenges.

https://cryptzone.vbulletin.net/

https://www.cryptzone.com/products/secure-access/appgate-xdp/aws

https://help.cryptzone.com/adminguide/index.html



https://help.cryptzone.com/userguide/v2.1/



appgate® xdp for aws · aws access key with read access to ec2 youll also need an aws access key...

Documents