Setup CDN and WAF

Introduction

Before beginning the CDN/WAF setup, there is a prerequisite that involves using a dedicated URL for the Jahia contribution interface.

Prerequisite

Contribution domain

Public facing domain(s)

Before initiating the setup, make sure your domains and certificates are already imported in Jahia Cloud.

1. Domain Name: [e.g., mydomain1.com, sub.mydomain2.com]
2. SSL Certificate: Provide the SSL certificate for the domain in PEM format, including wildcard or multi-domain certificates if applicable. Certificate private key and the certificate chain must also be included. 

CDN/WAF Setup Process

To create a CDN, go to the Jahia homepage and click Create CDN. Select your organization from the left sidebar, then follow the setup flow. This will result in the generation of a dedicated CloudFront URL that redirects to your Jahia Cloud environment. The team will upload the SSL certificate and provide you with the CloudFront URL. The URL provided will look like https://xxxxxxxxxx.cloudfront.net

Testing & Validation 

I want to make sure that Cloudfront is configured correctly before moving the DNS for everyone. You simply need to add entries in your host file pointing to xxxxxxxxxx.cloudfront.net (the production CDN endpoint) for mydomain.com. Then, you be able to see hits and misses from CloudFront in the headers when you access the site. 

You can glue together a simple test with multiple commands locally

1. Open a terminal and execute : nslookup xxxxxxxxx.cloudfront.net
2. Pick any of the IP addresses that domain resolves to (there will be several), lets assume 10.10.10.10 was one
3. Edit your /etc/hosts file and add a new line like : 10.10.10.10 mydomain.com
4. Open a browser (Make sure to test all site features) or use the curl command curl -k -v https://mydomain.com/
5. Check for x-amz-cf-id in the response indicating Cloudfront is in use.

DNS Configuration

To complete the setup, you need to create a CNAME in your DNS configuration to redirect mydomain.com to the CloudFront URL xxxxxxxxxx.cloudfront.net. However, note that the contribution domain (edit.mydomain.com) should point directly to the region where your destination environment is hosted; more info here. 

CDN Configuration

In this section, describe how our CloudFront distribution is configured in Jahia Cloud.

Origin Configuration

The CDN does not point directly to a given environment. Instead, it points to the Jahia Cloud load balancers. Then, those load balancers directs traffic to your environments based on what you configured in Jahia Cloud, via the "external domains binding" feature of the "Domains" tab on jahia.cloud.

The CDN origin is configured using a CNAME based on the region where your destination environment is hosted. You can find the complete list of regional CNAMEs here. This helps reflect the fact that your domain configuration points to the Jahia Cloud load balancers, and not directly to a specific environment.

Supported HTTP Methods

The following HTTP methods are allowed:

• GET

• HEAD

• OPTIONS

• PUT

• POST

• PATCH

• DELETE

Origin Policy

All parameters from viewer requests are forwarded to the origin, including:

• Headers: All headers

• Cookies: All cookies

• Query Strings: All query parameters

Cache Policy

Cache Key Settings

• Headers: Not included in the cache key

• Cookies: Not included in the cache key

• Query Strings: Not included in the cache key

Compression

• Gzip: Enabled
• Brotli: Enabled

CDN Configuration Type

Dynamic configuration 

The CDN determines how long assets remain cached based on the HTTP headers sent by Jahia.

Static configuration

TTL (Time-to-Live) Settings

• Minimum TTL: 60 seconds

• Default TTL: 3600 seconds (1 hour)

• Maximum TTL: 3600 seconds (1 hour)

By default, content is cached for up to 1 hour and for no less than 60 seconds.

The following types of assets for a one hour duration. 

• AVI files (*.avi)
• BMP images (*.bmp)
• CSS files (*.css)
• GIF images (*.gif)
• ICO files (*.ico)
• JPG images (*.jpg)
• JPEG images (*.jpeg)
• JavaScript files (*.js)
• MKV files (*.mkv)
• MP3 audio files (*.mp3)
• MP4 video files (*.mp4)
• OGG audio files (*.ogg)
• PDF documents (*.pdf)
• PNG images (*.png)
• SVG images (*.svg)
• Compressed SVG files (SVGZ) (*.svgz)
• WEBM video files (*.webm)
• WEBP images (*.webp)
• WOFF font files (*.woff)
• WOFF2 font files (*.woff2)
• XML files (*.xml)

Cache Invalidation

As a general rule, an asset is invalidated in CloudFront when its URL is updated. This means that CloudFront can invalidate an asset when the URL of the asset changes. 

To ensure that your application's assets are updated correctly when changes are made. You can achieve this by using the "addLastModifiedDateInAssets" property. The 'addLastModifiedDateInAssets' feature is implemented at the static asset filter level, appending the lastModified parameter to the URL of included static assets when enabled. This property allows you to force the CDN to reload assets when they are updated. More info here. 

As part of the new webpack approach in (Jahia 8.2) demonstrated here, [hash] can be added in webconfig output filename as a way to generate a new name whenever bundled content has been changed.

From npm-modules, files are generated with chunk hash filenames, but does not necessarily change whenever content changes. However all static assets also goes through the standard static asset filters and generates a unique compiled js, css etc, so it generates a unique file everytime a new module version is deployed.

WAF Rules

The WAF is administered by Jahia and is providing the needed security for all of our customers. The WAF relies on a set of rules defined by our Cloud and Security team. Here are the list of rules we are using for our WAF, and this applies to all of our customers. 

Rule 1: AWSManagedIPReputationList   

• Blocks IP addresses listed in the AWS Managed IP Reputation List, which includes sources identified as malicious by AWS.

Rule 2: AWSManagedReconnaissanceList

• Block connections from IP addresses that are performing reconnaissance against AWS resources.

Rule 3: BotControl

• The Bot Control managed rule group provides rules that manage requests from bots. Bots can consume excess resources, skew business metrics, cause downtime, and perform malicious activities.

Rule 4: Known Bad Inputs

• Blocks known malicious inputs, such as SQL injection attacks, cross-site scripting (XSS) attacks, and other forms of input-based attacks.

Rule 5: Linux

• Blocks Linux-based attacks and vulnerabilities, including known exploits and suspicious behavior.

Rule 6: Unix

• Blocks Unix-based attacks and vulnerabilities, including known exploits and suspicious behavior.

Rule 7: SQL Injection

• Blocks SQL injection attacks, which can be used to extract sensitive data or take control of a database.

Rule 8: Common

• Provides basic security and protection for the web application, including rules for common web attacks and vulnerabilities.

Rule 9: Rate Limit

• A rate-based rule counts incoming requests and applies rate limiting when requests arrive too quickly. The rule aggregates requests over a 5-minute window, and if the number of requests from the same source IP exceeds 10,000, the IP will be temporarily blocked for one hour.