Stronger security with a unified CDN and WAF

As an edge platform network, Fastly has a number of customers that deploy both our Delivery and Next-Generation WAF (NGWAF) products to support their sites. Throughout the journey of increasing their application’s security posture, many of our customers wonder how they can leverage Fastly’s entire platform offering to work together to achieve their goals. 

As Fastly’s Cyber Security Operations Center (CSOC) Team, our security expertise spans across our product portfolio to help customers take advantage of the entire Fastly platform when mitigating against malicious events. As you prepare for the Black Friday shopping weekend, we can help to increase your security posture with the Fastly products you already have in place. 

In this blog, we want to show how Fastly’s CDN and NGWAF can work together in harmony to provide customers with a better security posture than either can on their own. By utilizing a few existing tools, like JA3 and various headers, Fastly’s  CDN can be used to both enrich data and improve visibility in the NGWAF. In return, customer security decisions configured on the NGWAF can be enforced at our delivery network’s edge with the option of imposing additional penalties on attackers. Enabling this feedback loop before Black Friday will create better blocking decisions and will reduce the impact that an attack can have during a high-traffic event.  

Enrich your CDN data to enhance NGWAF controls 

Before setting out to provide specific rule configurations on the NGWAF side, we need to enrich the data going out to the NGWAF from the CDN. Doing this is as easy as adding a VCL snippet to the vcl_recv subroutine on your CDN service. Make sure to have this at the lowest priority so it’s the first thing that runs before any unexpected returns in your vcl_recv:

#vcl_recv

if(fastly.ff.visits_this_service == 0 && req.restarts == 0){
 set req.http.Fastly-Client-IP = client.ip;
 set req.http.Client-JA3 = tls.client.ja3_md5;
 set req.http.asn = client.as.number;
 set req.http.proxy_type = client.geo.proxy_type;
 set req.http.proxy_desc = client.geo.proxy_description;
}

Adding this snippet results in the following headers now being visible in the NGWAF console:

Client-JA3
asn
proxy_type
proxy_desc

You could log these variables in vcl_log for internal digestion to see trends on top JA3s, autonomous system numbers (ASNs) and proxy characteristics. Aggregating this data and understanding the prevalence of each type of variable in your peacetime application traffic will allow you to take action on each of these in a more effective manner come attack time. 

Some, like proxy headers, you may already know. For example, you may understand that specific login endpoints on your site should not expect to see legitimate TOR or hosting facility traffic. But being able to pick an ASN or JA3 out of a set seen hitting your site will allow you to determine whether these are safe to block by comparing them against prevalence in peacetime. You can refer to our logging documentation for additional context.

If you are observing common JA3 signatures during an attack period and want additional insight into how safe it may be to block, please reach out to our CSOC team to provide additional intelligence on the JA3.

Using JA3 signatures and ASNs

As the security industry evolves, so do its adversaries. In a current example of this, we are observing volumetric DDOS events and ATO (Account Takeover) attacks distributing their request characteristics as an evasion tactic, cycling characteristics like User Agents and IPs to a degree that makes actioning on them ineffective. 

Many of these types of attacks lack malicious characteristics—because they are mainly targeting availability—and they are difficult to distinguish from legitimate requests. In this scenario, we would need to pivot off of traditional strategies to see if we can identify a common signature among these requests. 

One such signature uses TLS connection characteristics to fingerprint clients resulting in an actionable JA3 signature—a hash of the previously mentioned TLS characteristics. You can find an example rule to block a list of collected malicious JA3 signatures below:

If you want to self-serve this information, you could also join our Fastly Bot Management beta program through Fastly Security Labs. This beta product classifies automated bot requests based on JA3 signature, making it easier for users to block requests based on a signal type. Participation in the bot beta also allows for searching for JA3 fingerprints within the NGWAF console. 

Utilizing the ASN header

If you have been logging ASN data previously or have now set it up thanks to the recommendations of this blog, you may find yourself in an attack situation where all the attack traffic is coming from the same ASN despite other characteristics being rotated/spoofed. 

In these cases, sometimes blocking an entire ASN is the best option depending on the specific ASN and the traffic you might expect to be hitting your application. Then the information collected and the patterns gleaned from this data can help inform whether blocking an entire ASN or a group of them would be useful as a temporary or even permanent mitigation measure. 

You can see an example of such a rule below:

Taking Advantage of the Proxy Headers

Proxy headers allow customers to take action on known proxy characteristics of specific IPs. We often observe attacks, especially those utilizing botnets, that will take advantage of more easily obtained, low-verification hosting providers. Entities taking advantage of things like BPH (bulletproof hosting) or offering it as a service will often utilize these same hosting providers through reseller programs to host volumetric attacks. 

Since these IPs do not carry the same proxy characteristics as larger hosting providers like AWS, we can configure a rule like the one seen below to block these types of hosting providers:

Another option for utilizing these proxy headers is securing against anonymous proxy-type traffic which includes services that change location to beat DRM, TOR points, temporary proxies, and other masking services. Some customers would benefit from an overall anonymous proxy block while others may only want this targeted at specific endpoints:

Some customers will have these types of IPs and hosting providers in their legitimate, expected traffic. For this reason, we recommend placing these types of rules in logging mode—only add a signal—if you are unsure of whether you would expect this type of traffic regularly. Even in these cases, this is a good rule to have as it often correlates heavily with attack traffic and can prove effective as a temporary blocking measure when immediate mitigation is needed during an attack. 

Optimize NGWAF enforcement with the Edge Cloud Network 

An important advantage of CDN over NGWAF is its capability to absorb volumetric attacks by taking advantage of Fastly’s global network. This is why we often recommend moving the actual enforcement of security decisions to the edge, preventing your origin or NGWAF agents from getting overwhelmed by volumetric events like DDoS. 

Consider an example where you are rate-limiting a threat actor who is exploiting your sensitive endpoint. VCL allows for custom response configurations that can help confuse and further punish and discourage an attacker. You can take this mitigation to the next level by setting a different response code in NGWAF and acting on it on the edge. 

An example NGWAF rule would look like this:

You could add VCL logic as shown below to either add the malicious rate-limited actor to a penalty box at the edge, tarpit the response or serve random error codes to set them off their game:

Add the below code in the vcl_init subroutine via VCL snippet:

penaltybox rl_sigsci_penaltybox{}

sub vcl_recv{
  if (req.restarts == 0 && fastly.ff.visits_this_service == 0) {
    if (ratelimit.penaltybox_has(rl_sigsci_penaltybox, req.http.Fastly-Client-IP)) {
            error 801;
      
    }
}
}

sub vcl_fetch{
  if (beresp.status == 412) {
    ratelimit.penaltybox_add(rl_sigsci_penaltybox, req.http.Fastly-Client-IP, 5m);
}
}

sub vcl_error{
  if (obj.status == 801) {
  set obj.status= randomint(402,410);
 set obj.response = "Ok";
  return(deliver);
}
}

You can see the results in the browser:

We tested the above code using the load testing tool vegeta. Here you can see how following the 412 response from the NGWAF, the IP was added to the penalty box at edge and then began throwing random 4xx response codes at the client.

Note: The response shows up as Ok because we have set the obj.response in vcl_error to send that response but the browser renders the appropriate error message based on the HTTP status code.

There are other creative ways of generating synthetic responses, one of which is described in our docs here.

We suggest you try these recommendations initially in logging mode or in a staging environment before deploying it on production.

Utilize the whole Fastly Ecosystem to Stay Secure 

When preparing for Black Friday, companies need to take advantage of every available tool, without acquiring new vendors or disrupting their workflows. Customers who use our NGWAF and Delivery services together can easily improve security performance and realize the benefits of our edge network with just a few simple VCL changes. 

These rules and recommendations will help bring added visibility and security for better decision-making that can apply to any application. If you have any questions regarding any of these tips or require additional insight into some JA3 signatures you have observed in your environment, please reach out to the Fastly CSOC team.