eCDN Web Application Firewall

Protect your storefront using extra layer 7 protection for your storefront with the Embedded Content Delivery Network (eCDN) Web Application Firewall (WAF). WAF protects production and development storefront host-names from code-level vulnerabilities, such as SQL injection attacks, cross-site scripting, and OWASP-identified threats targeting the application layer.

WAF Protection

WAF constantly monitors Internet traffic, examining all HTTP or HTTPS (full site) and Ajax (small data snippets) requests made to your storefront.

WAF incorporates the Open Web Application Security Project (OWASP) most common web application vulnerabilities to determine the most effective rule set. A rule can be based on multiple request attributes such as user-agent, path, country, query string, IP address, and more.

WAF does the following.

Sensitivity Levels for Triggering OWASP Actions

When responding to a potential web application threat, the eCDN WAF looks at each incoming request, assigns the request a threat score, and responds appropriately. Each incoming request that triggers an OWASP rule increases the overall threat score. Some rules impact the score more than others.

How WAF Responds to Threats

WAF uses three action modes in response to a threat detected by OWASP.

Simulate
Logs events without blocking or challenging the web requests. This allows you to see the impact that WAF would have when in Challenge or Block mode, and determine an appropriate action mode for your storefront.
Challenge
The Enable Under Attack Mode dialog box shows when an incoming web request is determined to be a bad actor. When you enable Challenge Mode, the CAPTCHA page challenges the suspected bad actor to respond before they can proceed to your storefront. This is valuable because if WAF mistakenly targets a real shopper, as the shopper can simply enter the CAPTCHA information and continue with their experience. Keep in mind, some bots can solve CAPTCHA, so using Challenge does not provide all of the desired security as Block mode.
Block
If an incoming web request is suspicious, a Blocked page is shown and the web request is prevented from reaching your server. This is the most effective action to take if WAF believes that an incoming request is a bad actor. However, if WAF mistakenly determines that a real shopper is a bad actor, they are not able to enter your storefront.
Note: The CAPTCHA and Block pages are both generically branded and cannot be customized.

Network Traffic Logs

The logs contain all eCDN network traffic, not just the traffic that WAF identifies. You can track IP-reputation blocked traffic and analyze how much of your traffic doesn’t trigger WAF settings.

You can request log files at specified times for up to seven days. An email with a link to download the log is sent to your Business Manager email address. Because of General Data Protection Regulation (GDPR) restrictions, log files are removed after seven days. We recommend that you save log files on your own server.

Log entries are in 60-minute increments of traffic requests to your storefront. You can also request 60-minute increment log files via OCAPI (Open Commerce API). If using OCAPI, the URL for downloading the logs is returned to you via the API response. If you do not want to receive an email with every API call for log downloads, you can use a temporary token for downloading logs via OCAPI.

See Log Requests.

WAF Considerations

Keep these things in mind when using WAF.

First Time Users

When setting up WAF for the first time, it is recommended to run WAF in Simulate mode for at least one week. Doing so captures enough information about your site traffic that you can make a data-backed decision regarding your storefront action and sensitivity needs by reviewing the generated logs.

When reviewing your logs consider the following:

  • Which rules are triggering and how often?
  • Which countries are triggering rules? Do you even sell to those countries? Do you ship to those countries?
  • What IP addresses are these bad actors are coming from? Perform IP lookups on them and see who has them registered.
    • Google? Search engines are typically good bots.
    • AWS? Could be good scrubbing (populating information used across the web to drive more sales) or bad scrubbing (inventory scraping by a competitor).
    • Competitor IPs? They probably are looking for intelligence on your site.
If you see many bad actors getting through, it’s recommended to raise your sensitivity. If WAF is catching real shoppers, lower the sensitivity.

See Also: