• Status

Utreda och implementera Sunet Frontend CDN som DDoS-skydd.

• Bakgrund och förutsättningar

Behovsbilden kretsar kring att det idag sker skyddsarbetet i huvudsak reaktivt; utöver de fasta filter som implementerats. Riktade attacker är svåra att upptäcka om de inte är volymetriska.

• Projektleveranser

1. Pilotmiljö installerad för SUNET frontend CDN som DDoS-skydd internt samt hos minst ett lärosäte
2. Definierat en tjänstemodell om tidigare punkter anses lyckade för SUNET DDoS-skydd med möjligtvis två tjänstenivåer. Första för stöd och analys, andra för skydd av exponerade system.
3. Etablerat ett första tjänstekontrakt och genomfört handover till Sunet NOC

...

1. Projektplan
2. Projektdeltagare rekryterade och projektet organiserat 
3. Kommunikationsinsatser
4. Kravspecifikation-underlag till upphandling/ utveckling

• Etapp 3 

Test implemenetation SUNET Frontend CDN interna system.

Pilot installation Sunet Frontend CDN hos Sunetansluten organsiation

...

...

1. Lyckad installation internt
2. Lyckad installation externt
3. Etablerad utkast tjänsteavtal (innan tjänsteetablering beslutas)

Designval

Maskinlayout

Tanken är att bygga lastbalanseringslösning för att kunna skala ut till många cache-maskiner vid behov. Vi kommer använda BGP med ECMP-routing för att dela ut trafik till flera maskiner. Ett klassiskt problem i samband med detta är att ECMP-routingen kastas om helt när man plockar i eller ur maskiner för maintenance. Detta är ett mindre problem vid enkelt fråga→svar protokoll som DNS, men i fallet HTTP så kan det vara tråkigt att skicka RST-paket till alla klienter oavsett om de råkade prata med den specifika noden man tog ur drift eller inte.

...

Detta medför att det kommer finnas två servertyper i projeketet, de främre som terminerar BGP och ser till att skicka vidare paketen till samma bakomliggande cacheserver. Dessa kallas för "l4lb". Sedan kommer det finnas de bakomliggande servrarna som faktiskt håller cache av webdata, dessa kallas helt enkelt för cache.

Protokoll

Vi kommer stödja HTTP över port 80, och HTTPS över 443. Tanken är att båda protokoll förmedlas bakåt till origin-server, och att vi sen cache:ar resultatet. Det är ännu inte planerat att stödja QUIC.

Certifikatshantering

Första tanken var att använda Caddy och dess inbyggda clusterstöd för att sköta certinhämtning från Lets Encrypt och sedan förmedla dessa mellan sig. Detta fungerar bra så länge man håller sig på en site, men eftersom detta projekt förväntas vara multi-site så uppstår problem med storagelösningen när vi vill ha oberoende siter. Den enklaste lösningen skulle vara att ha flera siter som oberoende av varandra hämtar cert för samma namn från Lets Encrypt, men detta springer in i begränsningar som Duplicate Certificate Limit.

...

Vidare hade det varit trevligt att inte behöva lagra kunders privata TLS-certifikat på maskinerna alls, men just nu ser det ut som detta är ett krav för att kunna ha prestanda i systemet. Något som verkar lovande på den här fronten är Delegated Credential men det verkar vara på ett experimentellt stadie just nu.

XDP för att hantera stor mängd trafik

För att vara motståndskraftig mot volymbaserad DDOS vill vi använda XDP. Helst vill vi använda detta både för "bra" trafik som ska vidare till cache, men också för blockering av trafik som är elak. För att använda XDP för inledande lastbalansering mellan cache-noder så tittar vi på att använda oss av Cilium. Detta bör ge oss bra lastbalanseringshastighet på l4lb-lagret och åtminstone grundläggnade stöd för att blockera IP-addresser som upplevs aggressiva.

Ett problem som finns är att det bara går att köra ett eBPF-program i XDP per nätverkskort (det finns saker som https://github.com/xdp-project/xdp-tools/tree/master/xdp-loader som simulerar att man kan ladda flera separata program, men det bygger då på att man har ett övergripande program som löser detta, och detta kräver att man använt libxdp, vilket inte är kompatibelt med Cilium, se https://github.com/cilium/ebpf/discussions/940). Det innebär att vi inte enkelt kan kombinera Ciliums paketforwardering med andra defensiva eBPF program, exempelvis för att effektivt kunna svara på en ICMP ping flood eller hantera SYN-flood med SYN-cookies i XDP samtidigt.

Cache

Hjärtat i DDOS-skyddet är att vi cache:ar HTTP-data så klienter inte ens når origin-servern, tanken är att detta görs med Varnish. Den ger via sitt VCL-språk mycket stor kontroll över vad som ska cache:as och hur. En utmaning i det här projektet är att man vanligtvis cache:ar en HTTP GET, men inte inte en POST, vilket kanske kan vara en väg att sänka origin-servern den vägen om man vet att det går att kliva rakt genom skyddet genom att skicka massa POST-förfrågningar istället. I den bästa av världar så är websidan man skyddar bara ett ställe att läsa från, inte att skriva till, men med tanke på att sådant kan vara olika från system till system så borde varnish vara ett sätt att skräddarsy exakt hur cachen ska bete sig för respektive kund.

...

Vidare är det relevant att vi kan behålla cache även om varnish (eller maskinen den går på) startar om, så vi kan fortsätta servera data från cache om bakomliggande nod är nere i händelse av att våra egna maskiner får strömavbrott, behöver uppdatera kernel eller liknande. Detta finns inte i open source varnish som standard (enterprise-versionen verkar kunna läsa det med sin MSE (Massive Storage Engine), däremot finns det ett nytt open source storage backend som dykt upp som ser ut att kunna lösa detta i form av SLASH med sin storage engine "fellow": https://gitlab.com/uplex/varnish/slash/-/blob/master/README.rst så den ser ut som en bra kandidat för att lösa detta problem.

Cache-invalidering

Sekunden efter man aktiverar en cache kommer någon undra varför en ändring man gjort inte syns på hemsidan. Vi behöver därför stödja invalidering av cache på beställning. Antingen genom att man skickar en HTTP PURGE request till den URL som ska invalideras, eller, om applikationen på origin-servern är mer cache-aware, kan tagga sidor med headers och sedan använda exempelvis varnish modulen xkey för att kasta alla relaterade sidor. En sådan request behöver spridas över alla körande cache-noder. Tanken är att sköta detta purge-spridande via MQTT-meddelanden som kan spridas både inom ett DC och mellan DC. Förmodligen kommer vi använda en MQTT-broker per datacenter, och sen bygga bryggor så varje MQTT-broker ansvarar för att pusha sina dc-specifika topics till alla andra brokers i andra datacenter, det leder i så fall till en full mesh koppling mellan alla brokers. Work-in-progress kod för MQTT-prataren finns här: https://github.com/SUNET/sunet-cdnp.

Inkoppling i nätverket

Vi vill ha fristående  fysiska interface för internet-exponerade portar som vi serverar tjänsten på, både managementtrafik . Managementtrafik (SSH) och förmodligen eventuellt även routeannonsering (BGP) bör ske på separat interface för att inte störas av överbelastningsattacker. Det är möjligt att BGP faktiskt bör gå inline med prod-trafik för att göra setupen mindre komplex samt kunna använda BFD och liknande. Vi bör även se till att ha så mycket filter som möjligt i framförvarande router så bara sådant som behövs för tjänsten kan ta sig fram till l4lb-maskinerna. Allt som kan filtreras innan det når oss är en vinst. Vi vill göra silent drop så tidigt som möjligt på alla annan trafik.

Offernod

Det finns en tanke om att adresser förutom att annonseras på olika platser i sverige också ska annonseras på något enskilt ställe utanför landet. Tanken med detta är att omfattande DDOS-attacker som kommer från utlandet ska attraheras till den nod som finns utanför landet, och därför inte störa ut inhemska frågor.

Kundlayout

Vi vill förmodligen köra på modellen att varje kund passerar gemensam l4lb men har egen IP-address, egen haproxy och egen och egen varnish. Det gör det lättare att hålla nere konfigurationsstorleken och en enskild kund med problem bör vara lättare att lokalisera och hantera när man inte har direkt påverkan på övriga kunder.

Loggar

Det finns en tanke om att vi ska kunna skicka loggar uppdelade per kund från systemet, det kan försvåra felsökning en hel del om man har en vägg framför sin origin-maskin som man inte har insikt i. Det hade varit väldigt praktiskt om kunder kan ta del av vad cachen faktiskt serverar till folk, inte minst för att hålla koll på vilken material som efterfrågas osv.