With the increase in ransomware attacks, high-profile breaches, and exploitations, security is finally becoming near and dear or at least getting the emphasis it needs. However, given the prevalence of the cloud, which provides simple access to computing, this further emphasizes the need to focus on security.
This article series will cover some background information on platform constructs and one example approach to help secure your perimeter and origin (servers hosting content) running in AWS and using Fastly’s Edge (C@E +CDN) products.
- Part I will cover some background topics related to AWS and Fastly.
- Part II will cover how to leverage the two together to provide an option for perimeter security.
When it comes to perimeter security there are a few key threat vectors or attacks:
- People*
- DNS (foo.bar.com -> IP)
- Network (firewalls, routing)
- DDoS (overwhelming origin)
- Configuration (area to inject vulnerabilities/misconfigurations)
*unfortunately, sometimes the easiest to target via phishing/spoofing
In the following sections, I’ll cover some aspects of each of these and how they apply to the cloud (AWS) and CDN/edge (Fastly).
Amazon Web Services (AWS)
When it comes to AWS or any cloud for that matter, network security is of utmost importance given the lack of physical control and breadth of potential threat vectors if not done correctly. If you were to do an NMAP scan of AWS IP ranges (not recommending you do so), you’ll see a lot of things that are left exposed to the internet (0.0.0.0/0) and lack any/all security at the perimeter.
AWS offers a few levels of control to help secure your VPCs which I’ve defined below. I’ll assume you have a fairly decent understanding of AWS networking but will cover it briefly.
Network ACLs
Network ACLs are VPC-wide rules which can be defined and can be used to define both inbound and outbound rules. However, these are “stateless” meaning they don’t understand the source of the traffic.
For example, say you wanted to allow traffic from 1.1.1.1/24 inbound but allow everything (0.0.0.0/0) outbound. Network ACLs don’t know whether or not the packet came from 1.1.1.1 or originated internally (firewalls keep track of this). In this case, anything originating internally would be blocked besides traffic going to 1.1.1.1/24.
Simple answer, Network ACLs are very crude and won’t offer much help as internal services may need to reach external sources.
Security Groups
Security groups act as a virtual firewall for resources internal to the VPC and allow you to create rules (both inbound/outbound) that control:
- source/destination range(s)
- port range(s)
- protocol(s)
Like any firewall, you can only specify ALLOW rules with the default rule being DENY.
Now, given that security groups are applied to resources in the VPC it is very common to have cascading security groups that you can use to structure DMZs, choke points, etc.
For example, if you’re running an ELB you may have one external-ingress security group allowing certain things into it with DMZ resources associated, then from there another internal-ingress security group that only allows things for the ELB security group or things internal to the network (e.g. private ranges/security groups), etc. This is commonly used when using public/private ingress gateways, etc.
When using security groups you should really understand the following:
- What tiers of services do I have (e.g. public, DMZ, internal, etc.)
- Who should be able to access things (security groups, IP ranges)
- What ports they should be able to access (e.g. 443)
- What protocols they should be able to access (e.g. TCP)
- What target(s) should be exposed via the Security group
Pro-tip: you see any security groups with inbound rules allowing 0.0.0.0/0 with any/all port/protocols, or inbound SSH (yikes) you should consider evaluating things :)
Fastly CDN/C@E
CDNs are not a new concept and have been around for years providing static asset caching and DDoS prevention.
However, in the past few years, these have expanded to now include capabilities like web-application firewalls (WAFs) and edge compute (logic execution in the CDN) capabilities.
In this section, I’ll be talking about some of Fastly’s capabilities as that is what I am most familiar with and I am a fan of both their embracing of WebAssembly (WASM/WASI) at their edge and their WAF capabilities.
The way these platforms work is typically done via a few core constructs:
Getting traffic to the edge (DNS CNAME)
A key item with any CDN is you will create CNAME entries for your site and point them to Fastly’s endpoints. For example, foo.bar.com may point to k.sni.global.fastly.net instead of your web servers. This means when resolving foo.bar.com it would direct the traffic to hit Fastly’s servers.
This is important for a few key reasons, it enables them to hit a local Fastly point-of-presence (POP) and also allows them to be able to handle DDoS attacks before they hit your origin (if configured correctly, as I will cover).
Here you can see an example CNAME resolving to Fastly:
; <<>> DiG 9.16.1-Ubuntu <<>> foo.bar.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63760
;; flags: qr rd ad; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;foo.bar.com. IN A
;; ANSWER SECTION:
foo.bar.com. 0 IN CNAME k.sni.global.fastly.net.
k.sni.global.fastly.net. 0 IN A 151.101.2.137
k.sni.global.fastly.net. 0 IN A 151.101.66.137
k.sni.global.fastly.net. 0 IN A 151.101.130.137
k.sni.global.fastly.net. 0 IN A 151.101.194.137
;; Query time: 50 msec
;; SERVER: 172.29.208.1#53(172.29.208.1)
;; WHEN: Thu Apr 14 09:29:47 CDT 2022
;; MSG SIZE rcvd: 168
Request handling/caching
Traditionally a lot of delivery models would rely on CDNs only for their static asset caching and DDoS mitigation, still relying on origin to handle the majority of requests.
However, I do believe with edge compute and the ability to execute logic efficiently on the edge via WASM we will see an inverting of the delivery model where we can offload the burden of requests from hitting origin and push more to the edge (more to come here!).
In our case we are using a mix of edge compute (C@E) which allows us to compile and execute RUST code on Fastly’s edge, which can also take advantage of their CDN which can cache content from origin.
A quick note on WebAssembly (WASM)… this is one thing that is very interesting/exciting and will be one of the core enablers to making clients (and even server side) much more efficient given it enables you to run binary instructions in a stack-based VM.
Given this it offers some very nice performance and efficient improvements when compared to native JS.
I’ll write some articles dedicated to WASM, but there’s some very interesting things it will facilitate.
A key with any CDN is time to purge (aka how long it takes to remove stale content) from the network. With Fastly’s ability to purge things globally in ~100ms, it opens up some very interesting possibilities with response caching.
Surrogate keys are what allow you to identify groups of objects together (can be any groups of objects or even individual objects). With the ability to inspect each request at the edge, and purge on-demand during an update, there are a lot of interesting things we can do here. More on this to come!
WAF
As I alluded to above a benefit of forcing traffic to Fastly is obviously the DDoS mitigation piece, but more generally is the ability to minimize the amount of garbage hitting the origin.
With the addition of the WAF at the edge, we can inspect requests and block them before they ever get sent to the origin. This obviously offers many benefits from a security standpoint, but it also minimizes the load on the origin as the invalid requests are never forwarded.
WAFs will vary in how they work, but simply put they inspect the request and run it through a series of rules that can check for known bad actors, attacks, etc. The Open Web Application Security Project (OWASP) provides a good amount of detail including exploits to check for, etc.
One key difference with the Fastly WAF is instead of the traditional employment of regular expressions (RegEX), they use lexical analysis which tokenizes items that are then analyzed. I’ll write up some other content on WAFs at another point in the future!
Hope you enjoyed it! Part II will cover how to leverage the two together to provide an option for perimeter security.