Innovative Software Technology

Enhancing On-Premises Web Application Security with AWS WAF and CloudFront: A Comprehensive Guide

Many organizations operate critical web applications on-premises, even as they embrace cloud services. A common security challenge arises: how to leverage modern, managed Web Application Firewall (WAF) services like AWS WAF without migrating the entire application to the cloud. This article provides a step-by-step guide to integrate AWS WAF with your on-premises web application using Amazon CloudFront, aligning with the security best practices of the AWS Well-Architected Framework.

Table of Contents:

  • Introduction
  • Why Integrate AWS WAF for On-Premises Applications?
  • Proposed Architecture
  • Prerequisites
  • Implementation Steps
    • SSL/TLS Certificate Creation
    • CloudFront Distribution Setup
    • DNS Configuration
    • Restricting On-Premises Access
  • Cost Considerations
  • Lessons Learned
  • Conclusion
  • Next Steps
  • Official Resources

Introduction

AWS WAF is a powerful Layer 7 firewall service designed to protect web applications from common exploits. While it primarily integrates with AWS resources like Application Load Balancers, API Gateway, and CloudFront Distributions, direct association with an EC2 instance or specific IP address isn’t possible. This guide addresses the scenario where an on-premises web application needs WAF protection without a full cloud migration.

The innovative solution involves deploying an AWS WAF-protected CloudFront distribution, using the on-premises server as its origin. This setup requires new SSL/TLS certificates, strategic DNS adjustments, and minor configuration changes to the local application. This approach has proven highly effective, providing robust security for on-premises applications.

Why Integrate AWS WAF for On-Premises Applications?

Protecting on-premises web applications with a WAF traditionally means deploying and managing local WAF solutions. AWS WAF offers a compelling alternative as a fully managed service, shifting the operational burden to Amazon Web Services.

Key Benefits of AWS WAF:
* Fully Managed: AWS handles infrastructure, maintenance, and updates.
* Managed Rules: Pre-configured rule sets protect against common vulnerabilities like those in the OWASP Top 10, SQL injection, and cross-site scripting (XSS). These rules are continuously updated by AWS.
* Custom Rules: Create your own stateful or stateless rules to allow or block specific IP addresses, apply geo-restrictions, use regex patterns, and more.
* Speed of Deployment: Configuring AWS WAF and CloudFront is typically much faster than deploying and managing traditional on-premises WAF hardware or software.
* Enhanced Security & Compliance: Fortify your application’s security posture and meet compliance requirements with a modern, cloud-native firewall.

By integrating AWS WAF, you provide your on-premises web application with advanced protection without the overhead of managing a local WAF infrastructure.

Proposed Architecture

This guide assumes your on-premises server hosts a web application exposed on port 443, secured with an existing SSL/TLS certificate for your primary domain (e.g., www.yourdomain.com), and accessible via a public IP address and a DNS A record.

Our implementation will involve:
* Two SSL/TLS Certificates: One for CloudFront and another for the on-premises server’s new origin domain.
* CloudFront Distribution: Configured with its SSL/TLS certificate, using a new subdomain that points to your on-premises server as its origin.
* DNS Configuration:
* A CNAME record to direct your primary domain (www.yourdomain.com) traffic to CloudFront.
* An A record to direct CloudFront’s origin subdomain (e.g., origin.yourdomain.com) to your on-premises server’s public IP.
* On-Premises Application Configuration: To accept traffic only from CloudFront.

The resulting traffic flow will be:
1. User Access: www.yourdomain.com
2. DNS Resolution: Points to CloudFront’s distribution.
3. CloudFront Distribution: Protects traffic with AWS WAF.
4. CloudFront forwards to Origin: Points to origin.yourdomain.com.
5. DNS Resolution (Origin): Points to your on-premises server’s public IP.
6. On-Premises Server: Receives WAF-inspected traffic.

Prerequisites

To successfully implement this solution, ensure you have the following:

  • AWS Account Access: With IAM permissions for Amazon CloudFront, AWS WAF, Amazon Route 53, and AWS Certificate Manager (ACM).
  • Administrative Access: To your authoritative DNS provider (e.g., Cloudflare, Amazon Route 53).
  • On-Premises Server Access:
    • A web application exposed on port 443 with a public IP address.
    • Permissions to generate and install SSL/TLS certificates issued by a public Certificate Authority (CA) or AWS ACM.
    • Permissions to modify your on-premises web application’s configuration.

Implementation Steps

This section details the step-by-step process to integrate AWS WAF with your on-premises server, ensuring secure traffic routing through AWS.

SSL/TLS Certificate Creation

You need two certificates: one for your on-premises server’s new origin domain and one for CloudFront’s primary domain.

On-Premises Server Certificate

  1. Acquire a Certificate for your Origin Subdomain: Using your preferred public CA (or AWS ACM, if exporting is enabled), obtain an SSL/TLS certificate for a new subdomain, such as origin.yourdomain.com. This domain will be the direct endpoint for CloudFront.
  2. Install on On-Premises Server: Install this new certificate on your on-premises server, ensuring it’s correctly configured for origin.yourdomain.com.
  3. Validate Installation: Use online SSL checkers (e.g., sslshopper.com) to confirm the certificate is valid for origin.yourdomain.com and not expired.

CloudFront Certificate (via AWS Certificate Manager)

  1. Request a Public Certificate: In the AWS Management Console, navigate to AWS Certificate Manager (ACM) and select “Request a certificate” -> “Request a public certificate”.
  2. Specify Domain Names: Enter your primary domain (e.g., www.yourdomain.com).
  3. Choose Validation Method: Select “DNS validation.”
  4. Create DNS Records: ACM will provide CNAME records for validation.
    • If using Route 53 in the same AWS account, click “Create records in Route 53.”
    • If using another DNS provider, manually create the CNAME record with the provided name and value.
  5. Verify Certificate Status: Once the CNAME record propagates, the certificate status in ACM will change from “Pending validation” to “Issued.” This certificate is now ready for use with CloudFront.

CloudFront Distribution Setup

Now, create and configure your CloudFront distribution to use your on-premises server as its origin.

  1. Create a CloudFront Distribution: Go to the Amazon CloudFront console and click “Create a CloudFront distribution.”
  2. Distribution Options:
    • Provide a Distribution name.
    • For Distribution type, select “Single website or app.”
  3. Origin Configuration:
    • For Origin type, select “Other” (since your origin is on-premises).
    • For Custom origin, specify your origin subdomain (e.g., origen.yourdomain.com). Leave “Origin path” empty.
  4. Cache Settings:
    • In Origin settings, use recommended settings or customize as needed.
    • In Cache settings, select “Customize cache settings.” For Origin request policy, choose “AllViewer.” Adjust other parameters if desired.
  5. Enable Security (AWS WAF):
    • Select “Enable security protections.”
    • Activate “SQL protection” and “Rate limiting” if applicable. This automatically creates and associates a basic AWS WAF Web ACL with your CloudFront distribution.
  6. TLS Certificate:
    • If your primary domain is managed by Route 53 in the same account, CloudFront should automatically detect the ACM certificate you created.
    • If not, you will manually add it later in the distribution settings.
  7. Review and Create: Review all details and click “Create distribution.”
  8. Distribution Deployment: CloudFront will begin deploying your distribution (status: “Deploying”). This can take some time.
  9. Manual TLS/Domain Configuration (if needed): If you didn’t specify your custom domain or select the ACM certificate during creation:
    • Once the distribution is created, go to its settings.
    • In the “General” section, click “Edit.”
    • Add your primary domain (e.g., www.yourdomain.com) to “Alternate domain name (CNAME).”
    • Select your previously created ACM certificate under “Custom SSL certificate.”
    • Save changes.
  10. Copy Distribution Domain Name: Once deployed, copy the “Distribution domain name” provided by CloudFront (e.g., d123example.cloudfront.net). You’ll need this for DNS configuration.

DNS Configuration

You’ll create two DNS records: a CNAME for your primary domain and an A record for your origin subdomain.

CNAME Record for Primary Domain

  1. Create a CNAME/Alias Record:
    • If using Route 53 in the same account: Create an Alias record for www.yourdomain.com pointing to your CloudFront distribution.
    • If using another DNS provider: Create a CNAME record for www.yourdomain.com pointing to the Distribution domain name you copied from CloudFront.

A Record for Origin Subdomain

  1. Create an A Record: Create an A record for your origin subdomain (origen.yourdomain.com) pointing directly to the public IP address of your on-premises server.

At this point, www.yourdomain.com will direct traffic through CloudFront and WAF, but origen.yourdomain.com will bypass WAF. The next step is crucial to ensure all traffic is WAF-inspected.

Restricting On-Premises Access

To guarantee that your on-premises server only accepts WAF-inspected traffic from CloudFront, you must restrict direct access to the origin subdomain. The recommended method is to use a custom HTTP header.

  1. Add Custom HTTP Header in CloudFront:
    • In the AWS console, select your CloudFront distribution.
    • Go to the “Origins” tab, select your configured origin, and click “Edit.”
    • In the “Settings” section, find “Add custom header.” Click “Add header.”
    • Define a custom HTTP header (e.g., X-Origin-Verify) and assign a secret, non-public value (e.g., your-secret-key-123).
    • Save changes. CloudFront will now include this header in all requests sent to your origin.
  2. Configure On-Premises Server:
    • Modify your on-premises web server or application to only accept requests that contain the specific custom HTTP header with the correct secret value. Requests without this header or with an incorrect value should be rejected.

This final step ensures that your on-premises application is truly protected by AWS WAF, as any direct access attempts to origen.yourdomain.com will be rejected by the server itself.

Cost Considerations

When implementing this solution, consider the following AWS service costs (prices are estimates and subject to change):

  • Amazon CloudFront:
    • Data Transfer Out: Approximately $0.085 per GB for the first tier (USA/Canada/Europe).
    • HTTP/HTTPS Requests: Approximately $0.01 per 10,000 requests.
    • Free Tier: Includes 1 TB data transfer out and 10 million HTTP/HTTPS requests per month.
  • AWS WAF:
    • Web ACL: $5 per month per Web ACL.
    • Rules: $1 per month per rule.
    • Requests Inspected: $0.60 per million requests.
  • Amazon Route 53:
    • Public Hosted Zone: $0.50 per month for the first 25 hosted zones.
    • Additional Records: $0.0015 per month for records above 10,000.
    • Standard DNS Queries: ~$0.40 per million queries.
  • AWS Certificate Manager (ACM):
    • Public Certificates: No additional cost when used with integrated AWS services like CloudFront.

Estimated Monthly Cost Example

Let’s estimate the cost based on these assumptions (us-east-1 region):
* CloudFront Egress: 1,000 GB/month
* CloudFront Requests: 10 million requests/month
* AWS WAF: 1 Web ACL, 1 rule
* Route 53: 1 hosted zone, 2 records (A + CNAME), 100,000 DNS queries
* ACM: 1 FQDN certificate

Calculations:
* CloudFront Data Out: 1,000 GB × $0.085/GB = $85.00
* CloudFront Requests: (10,000,000 / 10,000) × $0.01 = $10.00
* WAF Web ACL: $5.00
* WAF Rules: $1.00
* WAF Requests: 10,000,000 requests × $0.60/million = $6.00
* Route 53 Hosted Zone: $0.50
* Route 53 Records: (2 records, no extra cost over threshold) = $0.00
* Route 53 DNS Queries: (0.1 million × $0.40) ≈ $0.05
* ACM Certificate: $0.00

Total Estimated Monthly Cost: ~ $107.55 USD

Lessons Learned

  • Certificate Specificity: When creating certificates, use the exact Fully Qualified Domain Name (FQDN) needed. Avoid wildcard certificates unless absolutely necessary, as they are typically more expensive and often overkill for specific use cases.
  • Customize WAF Rules: The default WAF protection (OWASP Top 10, SQL injection, rate limiting, Amazon threat intelligence) is a good start. However, customize your Web ACL with additional rules tailored to your application’s unique security requirements.
  • Strict Access Restriction: Crucially, ensure direct access to your on-premises server is blocked for any traffic not originating from CloudFront and carrying the correct custom header. Failure to do so leaves your application vulnerable to direct attacks that bypass WAF.
  • Rotate Secrets: Regularly rotate the secret value of your custom HTTP header (at least annually) as a proactive security measure against potential credential leaks.

Conclusion

Implementing AWS WAF for an on-premises web application via CloudFront offers a straightforward and effective way to enhance security without requiring a full migration to the cloud. This approach allows you to leverage a fully managed, scalable Web Application Firewall, applying both Amazon-managed and custom rules to inspect and filter all incoming traffic. By ensuring only WAF-inspected traffic reaches your on-premises server, you significantly strengthen your application’s security posture.

Next Steps

To further your understanding and evaluate the applicability of this solution, explore the official documentation linked below. I encourage you to implement this guide in your own AWS account and share your experiences and insights!

Official Resources

Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.
You need to agree with the terms to proceed