Security Suite

Overview #

Edgio’s platform is built to ensure your website and applications remain open for business by keeping you protected against a wide range of security risks without sacrificing performance.

A fully PCI-compliant solution, Edgio Security protects your business against a variety of common exploits like SQL injections, cross-site scripting (XSS), PHP injections, bot attacks, DDoS attacks, and other common vulnerabilities.

This guide shows you how to keep your site and platform secure using Edgio.

DDoS (Distributed Denial of Service) #

Edgio Enterprise customers enjoy always-on DDoS protection inside of our high-bandwidth, globally distributed network. Our solution offers basic protection against common layer 3 and 4 attacks in real-time so you never have to sacrifice performance for protection.

WAF (Web Application Firewall) #

WAF Overview #

WAF is a web application firewall that helps protect your web applications and APIs against common web exploits an attacker may use to compromise your security, overwhelm resources, and affect the availability of your application.

Utilizing the Edgio WAF allows you to monitor, filter, and block HTTP traffic against common vulnerabilities such as cross-site scripting (XSS) or SQL injection before they reach your origin.

The WAF includes Managed Rule Groups, managed by Edgio, that can be configured in either a flagging or blocking mode. You can enable all of the rules within these groups or configure each independent rule within the group based on your needs.

Managed Rule Groups #

Edgio Managed Rules #

​​The Edgio Managed rule group contains rules that are generally applicable to web applications. This provides protection against exploitation of a wide range of vulnerabilities, including high risk and commonly occurring vulnerabilities described in OWASP® publications such as OWASP Top 10.

Edgio Managed Rule Group Descriptions

Admin Page Protection Rule #

The Admin protection rule group contains rules that allow you to block external access to exposed administrative pages. This might be useful if you run third-party software or want to reduce the risk of a malicious actor gaining administrative access to your application.

Admin Page Protection Rule Description

Bad Input Rules #

The Bad Input rule group contains rules to block request patterns that are known to be invalid and are associated with exploitation or the discovery of Common Vulnerabilities and Exposures (CVEs). This can help reduce the risk of a known malicious actor discovering a vulnerable application.

Bad Input Rule Descriptions

PHP Application Rules #

The PHP application rule group contains rules that block request patterns associated with the exploitation of vulnerabilities specific to the use of the PHP programming language. This includes the injection of unsafe PHP functions into requests.

PHP Application Rule Descriptions

SQL Database Rules #

The SQL database rule group contains rules to block request patterns associated with exploitation of SQL databases, like SQL injection attacks. This can help prevent remote injection of unauthorized queries. Evaluate this rule group for use if your application interfaces with an SQL database.

SQL Database Rule Descriptions

Add Rule Groups to a WAF #

1. Log in to the Edgio console.
2. Click SECURITY from the top banner to launch the WAF Security Rules page.
3. Select WAF-1 or WAF-2 from the first dropdown and the configuration version from the second.
4. Click EDIT to set your security rules.

5. Select the Set all rules to … dropdown. Hover over the dropdown for the rule group’s description.
6. Choose the action for the group: Off, Flag, or Block.
7. When you’ve made all your changes, click ACTIVATE. You will see a popup confirming your rule changes.
8. Click ACTIVATE to confirm the rule changes or CANCEL to continue editing. When your changes have deployed, the version will update with the next incremental number.

Add Single Rules to a WAF #

1. Log in to the Edgio console.
2. Click SECURITY from the top banner to launch the WAF Security Rules page.
3. Select WAF-1 or WAF-2 from the first dropdown and the configuration version from the second.
4. Click EDIT to set your security rules.

5. If collapsed, expand the Rule Group dropdown using the arrow to its left. You can hover over the rule name or the Flag/Block dropdown to view the rule’s description.
6. Click the Flag/Block dropdown.
7. Select the action for the rules you want to change: Off, Flag, or Block.
8. When you’ve made all your changes, click ACTIVATE. You will see a popup confirming your rule changes.
9. Click ACTIVATE to confirm the rule changes or CANCEL to continue editing. When your changes have deployed, the version will update with the next incremental number.

Apply a WAF to Your Environment #

Prerequisite: Configured WAF rules and/or rule groups.

Once you’ve configured the WAF rules you want to use, you need to apply them to the corresponding environments you want to deploy them on. Rules are NOT applied to traffic until you take this step to apply them.

Follow these steps to add a WAF to an environment:

1. Log in to the Edgio console and select your site.
2. Click the ENVIRONMENTS tab.
3. Choose an environment from the list.

4. Select CONFIGURATION from the top navigation.
5. Click EDIT.
6. Scroll down to the Security section.
7. From the dropdown, select an active WAF to add.
8. Click the ACTIVATE button from either the top or the bottom of the page.

Bot Detection #

Detect Bots with Managed Rules #

The Edgio Bot protection contains rules to block and manage requests from bots. You are charged additional fees when you use this product.

The Bot Control product applies labels to a set of verifiable bots that are commonly allowed. The rule group doesn’t block this category of commonly allowed bots.

Bot Control Rule Group: In addition to the WAF rule groups, Edgio offers an additional Managed Rule Group for bots that allows you to take action against common bots that may impact the performance and availability of your web application or APIs.

You can monitor the impact of your bots by flagging each bot type of request gaining insights into SEO bots, scraping bots, advertising bots, malicious user agent bots, and several other categories of bots.

Bot Control Rule Descriptions

Detect Bots with EdgeJS #

General Information #

Edgio examines the user-agent header in an incoming request to determine if it includes a string that indicates if it is a bot, and if so, injects 1 in the x-0-device-is-bot request header, which will be visible to your server code. If the user-agent header does not include any of the strings indicating a bot, a 0 value is injected.

User Agents and Bots #

The following table list the user agents that Edgio examines and describes the corresponding bots.

If the set of bots detected by Edgio is not sufficient for your needs, you can easily add your own bot detection through EdgeJS and its match and setRequestHeader APIs:

1router.match(
2  {
3    headers: {
4      'user-agent': /^regex-for-your-bot-detection$/i,
5    },
6  },
7  ({ setRequestHeader }) => {
8    setRequestHeader('my-bot-detection-is-bot', '1')
9  },
10)
11// ... all your other routes go here and they can match on `my-bot-detection-is-bot: 1`

The above code will match all the routes that even have a user-agent header and then inject the my-bot-detection-is-bot when the value of the user agent header matches the given regex. Once the header has been injected, the later routes can test for it and implement bot handling. Or, you could just let the header be sent upstream for your backend to handle it.

Security Reporting #

1. Log in to the Edgio console and select your site.
2. Click the ENVIRONMENTS tab.
3. Choose an environment.
4. Click the SECURITY tab from the top page navigation.

Security Activity #

Rules Applied #

Rules Section #

Logs #

Here is a sample log file highlighting the WAF data (“waf”:“botLib,flagged”,“wafv”:“WAF-1,2”): the action applied, the mode, the WAF name, and the version number, respectively.

Access Control by IP Address #

Restrict access to your website on a per environment basis through an IP address access control list. This type of access control list determines the set of traffic that will either be automatically allowed or blocked based off the client’s IPv4 address.

Key information:

• This type of access control list only controls access to your site within the current environment. You must define rules for each environment that you would like to secure by IP address.

• Add a rule for each desired IP address or IP block. Specify each desired IP address using standard IPv4 and CIDR notation.

• Specify a subnet by appending a slash (/) and the desired bit-length of the prefix (e.g., 11.22.33.0/22).

• Adding a rule to the Allowed IPs section means that traffic from that IP address or IP block will always be allowed.

  Block all traffic except for the IP addresses and IP blocks defined within the Allowed IPs section by adding a rule to the Blocked IPs section for 0.0.0.0/0.

• Adding a rule to the Blocked IPs means that traffic from that IP address or IP block will always be blocked.

To manage an IP address access control list

1. From the Edgio Developer console, load the desired property.

2. From within the Environments tab, click on the desired environment.

3. From within the Configuration tab, find the Access Control List section and then click Edit ACL.

4. Perform one or more of the following actions:

   • Add Allowed IP(s):
     1. From the Allowed IPs section, click Add rule.
     2. In the IP/CIDR option, type the IPv4 address or IP block that will be allowed access within this environment.
     3. Optional. In the Description option, provide a reason for why this IPv4 address or IP block should always be allowed access.
   • Add Blocked IP(s):
     1. From the Blocked IPs section, click Add rule.
     2. In the IP/CIDR option, type the IPv4 address or IP block that will be always be blocked within this environment.
     3. Optional. In the Description option, provide a reason for why this IPv4 address or IP block should always be blocked.
   • Delete Rule: Click next to the rule that should be deleted.

5. Click Save changes.

Geoblocking #

Restrict access to your website on a per environment basis through a country access control list. This type of access control list restricts traffic to the set of allowed countries.

To manage geoblocking

1. From the Edgio Developer console, load the desired property.

2. From within the Environments tab, click on the desired environment.

3. From within the Configuration tab, find the Geoblocking section and then click Edit Geoblocking.

4. Perform one or more of the following actions:

   • Block: From the Allowed countries list, select one or more countries and then click Block >.
   • Allow: From the Blocked countries list, select one or more countries and then click < Allow.

5. Click Save changes.

Website Security with EdgeJS #

Content Security Policy (CSP) #

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft to site defacement to distribution of malware.

You can easily add CSP headers to your site via a catch-all route near the top of your router.

To enforce a content security policy:

1new Router().match('/:path*', ({ setResponseHeader }) => {
2  setResponseHeader(
3    'Content-Security-Policy',
4    "default-src 'self'; report-uri http://reportcollector.example.com/collector.cgi",
5  )
6})
7// The rest of your router...

To enable a content security policy in report-only mode:

1new Router().match('/:path*', ({ setResponseHeader }) => {
2  setResponseHeader('Content-Security-Policy-Report-Only', "default-src 'self'")
3})
4// The rest of your router...

Enabling Basic Authentication #

You can add basic authentication to your site using the requireBasicAuth router method. For example, add the following to the top of your router:

1router.requireBasicAuth({
2  username: process.env.BASIC_AUTH_USERNAME,
3  password: process.env.BASIC_AUTH_PASSWORD,
4})

Then, add BASIC_AUTH_USERNAME and BASIC_AUTH_PASSWORD environment variables to each environment that should enforce basic authentication. Any environment without those environment variables will not enforce basic authentication.

Once deployed, the router will return 403 Forbidden for requests that have the incorrect basic authentication token, and 401 Unauthorized for requests that have no basic authentication token.

SSL #

By default Edgio only serves traffic over the https protocol. It automatically redirects http requests to the same URL, including any query strings, on https.

We strongly discourage the use of http protocol, but if you must enable it, then you can do so by adding protocol: 'http' to your route criteria. For example:

1// routes.js
2
3// Respond to Let's Encrypt HTTP-01 challenge.
4router.match(
5  {
6    protocol: 'http',
7    path: '/.well-known/acme-challenge/<your token>',
8  },
9  ({ send }) => {
10    send('<token value>')
11  },
12)

If you want the route to match both http and https protocols you can match on protocol: /^https?$/. If no route is matched on http protocol then Edgio will fallback on its default behavior of automatically redirecting the request to https.

Additionally:

• A request’s protocol can be determined by reading the x-0-protocol request header or the request.secure property.
• During local development all requests will appear secure by default. To test your router for http protocol matching you must either set the local_edgio_emulate_http_protocol cookie to true (if using a browser) or send an x-0-protocol request header set to http.

HTTP/1/2 Version #

The incoming HTTP version is independent of the upstream HTTP version. We support HTTP/1 or HTTP/2 on ingress requests. We prioritize HTTP/2 to origin servers. If the origin server does not support the incoming HTTP version (say version HTTP/2 came in but origin only supports HTTP/1), we will downgrade to successfully complete the request, but the outgoing response will return to HTTP/2.

Secrets #

Rather than putting secret values such as API keys in your code and checking them into source control, you can securely store them in environment variables, then access them in your code from process.env. To configure environment variables, navigate to your environment, click EDIT, then under Environment Variables, click ADD VARIABLE.

As of Edgio CLI version 2.19.0, when you deploy to an environment using a deploy token, for example by running edgio deploy my-team --environment=production --token=(my token) option, all environment variables are pulled down from the Edgio Developer Console and applied to process.env so they can be accessed at build time. This allows you to store all of your build and runtime secrets in a single place, Edgio Developer Console, rather than storing some in your CI system’s secret manager.

Cache Poisoning #

Cache poisoning attack is described by OWASP® as:

The impact of a maliciously constructed response can be magnified if it is cached either by a web cache used by multiple users or even the browser cache of a single user. If a response is cached in a shared web cache, such as those commonly found in proxy servers, then all users of that cache will continue to receive the malicious content until the cache entry is purged.

To guard against this attack you must ensure that all the request parameters that influence the rendering of the content are part of your custom cache key. Edgio will automatically include the host header and URL. Including other request headers and cookies are your responsibility.

For example, if you are rendering content based on a custom language cookie, then you must include it in your custom cache key:

1import { CustomCacheKey } from '@edgio/core/router'
2
3router.get('/some/path/depending/on/language/cookie', ({ cache }) => {
4  cache({
5    key: new CustomCacheKey().addCookie('language'),
6    // Other options...
7  })
8})

FAQs #

What’s the difference between WAF-1 and WAF-2? #

You can configure 2 different WAF instances, allowing you to apply different sets of security rules to different environments.

How do I know which version to use? #

Like all Edgio products, WAF gives you access to all previous and active versions of your configuration so you have historical setups in case you need to roll back the current version.While editing, the version is in a Draft state; once activated, the version is Active.

What is the difference between flagging and blocking a rule or rule group? #

To flag a rule or rule group means to mark it if the rule would have been activated without actually denying the traffic. In contrast, when you block a rule or rule group, traffic is denied on affected routes. You can view both flagged and blocked data in your Edgio console.

What are Edgio Managed Rules and why should I apply this rule group? #

Managed rules block specific known threats. Edgio recommends this rule group for all WAF use cases.

Note: Edgio recommends that all customers activate the Bad Input - Log4J rule group.

Is WAF a PCI-compliant solution? #

Yes. Edgio maintains PCI-DSS Level 1 compliance by undergoing annual audits from approved Visa and MasterCard auditors.

What is the minimum level of encryption for Edgio? #

Edgio enforces a minimum version of TLS 1.2 or higher.