Deploy to Amazon Web Services (AWS)
With version 7.8 Secure Web Gateway is now deployable in Amazon Web Services (AWS), allowing for greater flexibility in managing your infrastructure around the globe.
Find your AMI
To get the Secure Web Gateway Amazon Machine Image (AMI), login to the Content & Cloud Security Portal, then navigate to Downloads to select the right AMI for you. There is an AMI in each AWS region.
Deploy the AMI
Once you have the AMI ID, you can proceed to deploy your AWS Secure Web Gateway.
- Search for the AMI ID provided by the Beta team, select Private Images in the search.
- Choose your Instance Type
- Single User Testing: m4.large
- Minimum for Production: m4.xlarge
- Recommended for Production: m4.2xlarge
- Configure Instance Details
- Add Storage (minimum of 80 GB)
- Add Tags (optional)
- Configure Security Group
- For testing, it is advisable to allow requests only from your external IP to all ports UI (HTTPS - 4712), Command Line (SSH - 22), and the HTTP Proxy (9090).
- Once testing is completed and the Secure Web Gateway security policy is updated, the HTTP Proxy port can be opened up further to accept traffic from more addresses.
- Create or choose an existing SSH key pair
- If you're creating a new pair, you must download the .pem file and store it safely for later use.
- Launch the Instance
- Wait for the Health Checks to Pass and then it will be reachable via the Command Line and UI.
- Wait for the Health Checks to Pass and then it will be reachable via the Command Line and UI.
Access the CLI and UI
After completing the instance deployment it's important to gain access to the command line and the UI for familiarity.
Log into the CLI
The CLI is reachable on port 22. To access the Command Line we'll need the private key generated in the SSH key pair steps during Instance creation. The default user is "ec2-user".
From Linux
To access the AWS Secure Web Gateway's command line, we can use the .pem file created in the key pair step. No modification is required, use the following command:
ssh -i "YOUR-KEY.pem" ec2-user@ec2-54-193-4-102.us-west-1.compute.amazonaws.com
From Windows
To access the AWS Secure Web Gateway's command line using a tool on Windows, like Putty, we'll need to convert the .pem file to a ppk.
To convert the key, use PuttyGen by clicking Conversions > Import Key, then saving the Private key as a .ppk.
Then in Putty, under SSH configuration > Connection > SSH > Auth, select a Private key file for authentication.
Logging into the UI
The UI is reachable on HTTPS port 4712 (e.g., https://ec2-54-193-4-102.us-west-1.c...naws.com:4712/ ). To access the UI, we'll need the Instance ID, or access to the CLI to retrieve the password. The default user is "admin" and the password is #<AWS InstanceId>... = #i-123123123123.... The UI password can also be found when logging in via SSH in the banner.
Lock Down the Proxy (Security Considerations)
Once you have access to the GUI, the license should be applied and the security policy should be updated. The baseline security policy should include some level of IP filtering and Authentication. Below I will cover the basics.
Security Rules
Security Rules define what IPs are to be trusted with the X-Forwarded-For header. The X-Forwarded-For header is read by the Secure Web Gateway to determine who the originating request was from. The Security Rules only trust the X-Forwarded-For header if it's coming from IPs in the "Allowed Downstream Proxies" list.
Authentication
Authentication (in some form) is a must for a cloud-based proxy. Without it, the AWS Secure Web Gateway can be abused as an open proxy. For the example rules we're using SCP and Kerberos for authentication. When pairing these two forms of authentication together, there is extra flexibility and security. SCP can be used for managed endpoints, whereas Kerberos can be used for all other domain joined machines. Both methods also offer flexibility for user's location -- it doesn't matter where they are so long as they can authenticate.
Benefits of SCP and Kerberos for AWS
- Skyhigh Client Proxy provides authentication information using a symmetric encryption method. Both SCP and Secure Web Gateway hold the key in order to authenticate each other. SCP also provides intelligent redirection in case the proxy is unavailable, it can failover to other services like the Secure Web Gateway Cloud.
- Kerberos provides seamless authentication without the need for a directory connection -- ideal for AWS. When using Kerberos, the client provides an encrypted ticket; this ticket includes the username, groups, among other things. The Secure Web Gateway's key tab is used to validate the ticket information.
Proxy Port must be Protected!
Reference Architectures
AWS to rule them all
AWS is used to replace existing on-prem infrastructure. Traffic is coming from known or unknown IPs. Unknown IPs are forced to authenticate with SCP or Kerberos.
AWS to supplement remote offices
AWS is used for remote offices and remote users without on-prem appliances. Alleviating the need to rack and stack appliances for locations with limited space. Policy is synced between the Secure Web Gateway on-prem and the AWS Secure Web Gateway.
A Hybrid Approach
A combination of AWS and the Skyhigh Security Cloud is used for maximum protection and performance. The AWS Secure Web Gateway may be used for handling some traffic, or simply to manage the flexible security policy in Secure Web Gateway Cloud. The Secure Web Gateway Cloud is then used to handle the bulk of the traffic.
Cloud-Based Content and Policy Enforcement
Secure Web Gateway is deployed to enforce security policy for on-prem and cloud-based applications. Using Secure Web Gateway as an ICAP service, security policy can be built to dissect, scan, and remediate possible threats.
Gotchas
To start, some features have been disabled in the AWS Secure Web Gateway.
- WCCP, Transparent Router, Transparent Bridge, Proxy HA are not available
- Caching is disabled due to high disk IO and disk space requirements
- All other settings may appear as greyed out