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.
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 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.
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 recommends utilizing this rule group for all WAF use cases.
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.
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.
Edgio recommends enabling the ‘Bad Input - Log4J’ rule on all WAF
applications.
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.
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.
When you’ve made all your changes, click ACTIVATE. You will see a popup confirming your rule changes.
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.
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.
Click the Flag/Block dropdown.
Select the action for the rules you want to change: Off, Flag, or Block.
When you’ve made all your changes, click ACTIVATE. You will see a popup confirming your rule changes.
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.
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:
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.
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.
The following table list the user agents that Edgio examines and describes the corresponding bots.
User Agent
Bot Description
embedly
Embed.ly web crawler bot that performs HTTP requests most often in automatic mode.
facebookexternalhit
Facebook bot that crawls the HTML of social plugins, apps, and websites shared on Facebook. The bot gathers and caches data (title, description, thumbnail image) about the shared content and presents the data as a preview.
flipboard
Flipboard Proxy Service bot that runs in response to a user request for the service to scan a social media feed such as Twitter, and construct a processed feed of items to deliver in real time.
googlepagesspeed
Google bot that assists in ranking search results based on page load speed.
Google web/snippet
Google+ Enterprise bot that extracts high-level data from a URL posted on Google+ Enterprise and presents the data as a snippet of the URL.
headless
Bots, usually scripts, that run on a scheduled basis or are triggered from an external system. Headless bots usually perform activities like sending alerts or daily digest messages. The scripts usually run for a short time, then terminate.
ia_archiver
Amazon Alexa bot that crawls web sites for issues related to Amazon’s Site Audit service.
outbrain
Outbrain Recommendation Platform chat bot.
pinterest
Automated Pinterest bot that creates boards and schedules pins to post to customer accounts.
prerender
Prerender.io hosted service bot that produces an easily crawled version of dynamically rendered pages, allowing indexing by search engines.
preview
Yahoo bot that extracts data (title, description, thumbnail images) from a URL embedded in an email and presents the data as a preview of the URL
qwantify
Web crawler bot that indexes content for the Qwant search engine.
scanner
Bots that analyze how well your website and its security measures respond to various bot threats.
slurp
Yahoo Search bot for crawling and indexing web page information.
spider
General purpose automated bots that crawl the web to index web page information.
tumblr
Tumblr bot that performs automated HTTP requests as a web crawler.
vkshare
VK social network bot that performs automated HTTP requests usually as a web crawler.
w3c_validator
W3C bot that checks Web documents in formats like HTML and XHTML for conformance to W3C Recommendations and other standards.
whatsapp
Whatsapp platform chat bot.
xing-contenttabreceiver
Xing social network crawler bot that indexes content for the Xing social network.
yahoo
Another Yahoo Search robot for crawling and indexing web page information.
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:
JavaScript
1router.match(
2{
3headers:{
4'user-agent':/^regex-for-your-bot-detection$/i,
5},
6},
7({ setRequestHeader })=>{
8setRequestHeader('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.
Click inside the graph to list the names of the rules that have been applied to your Bot Control or Edgio Managed rules. Click Back to Rule Sets to return to the previous view.
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.
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
From the Edgio Developer console, load the desired property.
From within the Environments tab, click on the desired environment.
From within the Configuration tab, find the Access Control List section and then click Edit ACL.
Perform one or more of the following actions:
Add Allowed IP(s):
From the Allowed IPs section, click Add rule.
In the IP/CIDR option, type the IPv4 address or IP block that will be allowed access within this environment.
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):
From the Blocked IPs section, click Add rule.
In the IP/CIDR option, type the IPv4 address or IP block that will be always be blocked within this environment.
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.
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.
An access control list takes precedence over geoblocking. For example, a request from a blocked country is allowed when the client’s IP address satisfies a rule defined within the Allowed IPs section.
To manage geoblocking
From the Edgio Developer console, load the desired property.
From within the Environments tab, click on the desired environment.
From within the Configuration tab, find the Geoblocking section and then click Edit Geoblocking.
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.
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.
You can add basic authentication to your site using the requireBasicAuth router method. For example, add the following to the top of your router:
JavaScript
1router.requireBasicAuth({
2username: process.env.BASIC_AUTH_USERNAME,
3password: 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.
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:
JavaScript
1// routes.js
2
3// Respond to Let's Encrypt HTTP-01 challenge.
4router.match(
5{
6protocol:'http',
7path:'/.well-known/acme-challenge/<your token>',
8},
9({ send })=>{
10send('<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.
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.
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.
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:
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.
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.