- Video Walkthrough
- Instructions for finding your AMI
- Deploying the AMI
- Accessing the CLI and UI
- Locking Down the Proxy (Security Considerations)
- Reference Architectures
With version 7.8 Web Gateway is now deployable in Amazon Web Services (AWS), allowing for greater flexibility in managing your infrastructure around the globe.
Note: It is no longer required to email the Web Gateway Beta DL for getting access to the Amazon Machine Image (AMI), see steps below.
Instructions for finding your AMI
To get your the 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.
Deploying the AMI
Once you have the AMI ID, you can proceed to deploying your AWS 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 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.
Accessing the CLI and UI
After completing the instance deployment it's important to gain access to the command line and the UI for familiarity.
Logging 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".
To access the AWS Web Gateway's command line, we can use the .pem file created in the key pair step. No modification required, use the following command:
ssh -i "YOUR-KEY.pem" firstname.lastname@example.org
To access the AWS 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, PuttyGen can be used 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.compute.amazonaws.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>McAfee = #i-123123123123McAfee. The UI password can also be found when logging in via SSH in the banner.
Locking 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 define what IPs are to be trusted with the X-Forwarded-For header.. The X-Forwarded-For header is read by the MWG 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 (in some form) is a must for a cloud based proxy. Without it, the AWS Web Gateway can be abused as an open proxy. For the example rules we're using MCP and Kerberos for authentication. When pairing these two forms of authentication together, there is extra flexibility and security. MCP 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 MCP and Kerberos for AWS
- McAfee Client Proxy provides authentication information using a symmetric encryption method. Both MCP and MWG hold the key in order to authenticate each other. MCP also provides intelligent redirection in case the proxy is unavailable, it can failover to other services like the Web Gateway Cloud Service.
- 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 Web Gateway's keytab is used to validate the ticket information. See here for an awesome setup tool.
Proxy Port must be Protected!
AWS to rule them all
AWS is used to replace existing on-premise infrastructure. Traffic is coming from known or unknown IPs. Unknown IPs are forced to authenticate with MCP or Kerberos.
AWS to supplement remote offices
AWS is used for remote offices and remote users without on-premise appliances. Alleviating the need to rack and stack appliances for locations with limited space. Policy is synced between the on-premise Web Gateway and the AWS Web Gateway.
A Hybrid Approach
A combination of AWS and the McAfee Cloud is used for maximum protection and performance. The AWS Web Gateway may be used for handling some traffic, or simply to manage the flexible security policy in Web Gateway Cloud Service. The Web Gateway Cloud Service is then used to handle the bulk of the traffic.
Cloud Based Content and Policy Enforcement
Web Gateway is deployed to enforce security policy for on-premise and cloud based applications. Using Web Gateway as an ICAP service, security policy can be built to dissect, scan, and remediate possible threats.
To start, some features have been disabled in the AWS 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