Skip to content

Advanced WAF#

The amazee.io Advanced Web Application Firewall (WAF) is an opinionated implementation of Fastly's Next Generation WAF - (previously known as Signal Sciences).

The serves as an intrusion detection system (IDS) and intrusion prevention system (IPS) for web requests.

How it works#

Architecture#

There are 2 ways you can have the WAF deployed.

1. Fastly edge deployment#

You are able to deploy the WAF as a part of your amazee.io CDN subscription. This option can be useful if you do not have a dedicated cluster, or if you only want to protect a subset of domains for some reason on your dedicated cluster.

Architecture of a Fastly edge deployment

2. Dedicated cluster deployment#

If you do have a dedicated cluster, you are able to deploy the WAF as the cluster ingress, so all traffic to the origin cluster is inspected, irrespective of the domain used. This is the most secure implementation as you cannot route around the WAF.

Architecture of a cluster deployment

Key differences vs traditional WAFs#

There are a number of differentiators versus more 'traditional' WAFs that you might have seen:

  • Tight integration with kubernetes - able to inspect all traffic that hits the origin cluster, irrespective of how it got there. Pricing is tied origin requests, not CDN requests.
  • Threshold blocking - suspicious payloads over time and with context to determine whether an actual attack is occurring
  • Virtual patching - you can apply virtual patches that address various CVEs. This can buy your development team time to patch all the applications.
  • SigSci IP - whenever an IP address is flagged by any Signal Sciences customer, that IP address is recorded as a known potential bad actor and flagged to the whole network. You are able to use this as an input to your rules.
  • Low false positives - due to thresholds blocking, and ability to exclude IP addresses
  • Response object aware - you are able to create rules that know about the origin response. e.g. no more than 100 HTTP 404s in 1 minute.

Screenshots#

Here are example screenshots from a real customer over a 24-hour period. Names and website addresses redacted.

Dashboard

Overview of the amazee.io Advanced WAF. This is a dashboard that shows you the key information for a given time range.

RPS

You can view the Requests Per Second (RPS) hitting the WAF, and look for peaks that might be of interest.

OWASP

The WAF is able to automatically detect requests attempting to exploit common items in the OWASP top 10. Here you will see signals like SQLi, XSS, CMDEXE and Traversal.

Scanners

The WAF is able to automatically detect automated scanning engines. It is up to you whether or not this traffic is desirable.

Request anomalies

The WAF will highlight which requests were blocked, and other unusual requests, e.g. impersonating GoogleBot (with the Imposter signal).

Response anomalies

Shows response HTTP status codes that are usually interesting to refer to.

Traffic anomalies

Shows requests from unusual traffic origins, e.g. already flagged as a SigSci IP by the network, or requests coming from a datacenter.

IP list

Here is a list of IP addresses that have exceeded thresholds, and now are effectively in the naughty corner for a configurable timeout (default 24 hours). You can click through each one to review their actions, and if needed, evict them from the naughty corner.

IP timeline

When you zoom into a given IP address from the list, you can see a detail overview of their requests, and what they did to exceed the thresholds.

Request blocked

Full details are logged for requests, and there is a search function to find and filter for requests you are interested in.

Rules#

You can add custom rules to build on top of the signals that the WAF supplies you. This allows you to create complex rules to protect your application, by snapping the conditions together.

Rules can have many different actions:

  • block (block the request in the WAF)
  • allow (do not block the request in the WAF)
  • add signal (log the request only)

We will work with you to craft any rules that you need to better secure your application. Normally new rules will start life in a log only mode, and then after some data has been collected, move to block or allow.

Allow rules will also take precedence over block rules.

Example rules#

To get you thinking about the possibilities this will allow, here are some example rules we have deployed:

Blocking user registrations from Russia

Blocking response splitting requests

Alerting for anomalous traffic#

You can create real-time alerts for events by adding a 'site integration'. See the Fastly documentation on the types of integrations there are.

These alerts are real-time, and will generate a new alert for each new even that matches the criteria. You can create a Slack message each time an IP address is flagged by the site for instance.

Logging#

The router-logs-<projectname>-* index pattern in ElasticSearch will show who which requests where blocked.