Stronger security with a unified CDN and WAF

By admin
Stronger security with a unified

CDN
ORG

and

WAF
ORG

As an edge platform network, Fastly has a number of customers that deploy both our Delivery and Next-Generation WAF (

NGWAF
PERSON

) 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
ORG

(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
EVENT

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
PERSON

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
ORG

can be used to both enrich data and improve visibility in the

NGWAF
PERSON

. In return, customer security decisions configured on the

NGWAF
PERSON

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
EVENT

will create better blocking decisions and will reduce the impact that an attack can have during a high-traffic event.


Enrich
PERSON

your

CDN
ORG

data to enhance

NGWAF
PERSON

controls

Before setting out to provide specific rule configurations on the

NGWAF
PERSON

side, we need to enrich the data going out to the

NGWAF
PERSON

from the

CDN
LOC

. Doing this is as easy as adding a VCL snippet to the

vcl_recv
LAW

subroutine on your

CDN
ORG

service. Make sure to have this at the lowest priority so it’s the

first
ORDINAL

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
CARDINAL

; set req.http.

Client-JA3
ORG

= tls.client.ja3_md5; set req.http.asn =

client.as.number
DATE

; 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
PERSON

console:

Client-JA3

asn

proxy_type


proxy_desc
EVENT

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
ORG

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
ORG

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
ORG

(Account Takeover) attacks distributing their request characteristics as an evasion tactic, cycling characteristics like

User Agents
ORG

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
CARDINAL

such signature uses

TLS
ORG

connection characteristics to fingerprint clients resulting in an actionable JA3 signature—a hash of the previously mentioned

TLS
ORG

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
ORG

beta program through Fastly

Security Labs
ORG

. 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
PERSON

console.

Utilizing the

ASN
ORG

header

If you have been logging

ASN
ORG

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
ORG

despite other characteristics being rotated/spoofed.

In these cases, sometimes blocking an entire

ASN
ORG

is the best option depending on the specific

ASN
ORG

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
ORG

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
ORG

, 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
ORG

, 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
PERSON

enforcement with

the Edge Cloud Network
ORG

An important advantage of

CDN
ORG

over

NGWAF
PERSON

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
PERSON

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
PERSON

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
PERSON

.Fastly-Client-IP )) { error

801
CARDINAL

; } } } sub vcl_fetch{ if ( beresp.status = =

412
CARDINAL

) { ratelimit.penaltybox_add(rl_sigsci_penaltybox, req.http.Fastly-Client-IP ,

5 m
QUANTITY

); } } sub vcl_error{ if (

obj.status
ORG

= = 801 ) { set

obj.status
ORG

= randomint (

402
CARDINAL

,

410
CARDINAL

); 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
CARDINAL

response from the

NGWAF
PERSON

, 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
CARDINAL

of which is described in our

docs
PERSON

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
EVENT

, companies need to take advantage of every available tool, without acquiring new vendors or disrupting their workflows. Customers who use our

NGWAF
PERSON

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
ORG

team.