Blog: Alternativ DDoS beskyttelse

DDoS er kommet for at blive, se eksempelvis dagens artikel It-chef: Forsvar mod DDoS-angreb bliver hverdag i folkeskolen

Emnet DDoS er også noget vi allesammen bør være opmærksomme på, uanset om vi betragter os som powerbrugere af internet eller leverer ydelser indenfor eksempelvis ISP eller hosting. Alle der læser version2 er formentlig i målgruppen, og ramt af DDoS i nogen grad.

Vi skal være opmærksomme på at vores resourcer ikke bruges til DDoS-angreb, som en del af botnet eller fordi vi tillader DNS eller NTP servere at blive brugt til reflektion og forstærkning af angreb.

Hvis man er interesseret i disse emner er der mange steder man kan læse, men prøv evt. at se i arkivet fra den nyligt overståede RIPE68 konference, https://ripe68.ripe.net/presentations/presentation-archive/

Der findes man eksempelvis

Specielt den sidste er interessant, fordi man med nytænkning ændrer forholdene for DDoS betragteligt.

DFZ – default free zone

Lad mig lige kort introducere DFZ begrebet, for det er relevant for diskussionen af disse nye tiltag, og mit eget forslag nedenfor. Normalt når man konfigurerer en enhed med IP protokollerne angiver man en adresse for enheden, et subnet/en netværksmaske og en default gateway (gateway of last resort).

Denne gateway bruges til at nå alle andre destinationer end dem som findes på det lokale subnet, angivet med netværksmasken. Så en enhed med IP-adresse 192.168.1.10/24 kan nå alle enheder fra 192.168.1.1-254 lokalt på LAN (typisk Ethernet eller wireless). Når den skal videre ud i verden vil det typisk være enten via 192.168.1.1 eller 192.168.1.254 som er defineret som default gateway.

For fuldstændighedens skyld er det samme sag med IPv6, du kan eksempelvis have en host med IPv6 adresse 2a03:a480:1:1::2/64 og en default gateway 2a03:a480:1:1::1. IPv6 bruger som standard 64-bit så det lokale netværk er 2a03:a480:1:1::/64. En internetudbyder har således i RIPE regionen mulighed for at uddele MANGE subnets til kunder.

Godt med en default gateway kan man nå andre destinationer ude i verden, aka internet. Det som mange dog ikke ved er at et stykke ude i din ISPs netværk er der en ISP router som er overgangen fra ISP til default free zone, altså den del af core-internet som IKKE har en default gateway?! Derude er det den globale routing tabel med ~500.000 IPv4 routes/prefixes og ~15.000 IPv6 routes/prefixes. Eksempelvis er der routes annonceret med 185.27.112.0/22 og 2a03:a480::/32 som jeg står for i Solido Networks.

Jeg angiver altså til mine internetudbydere – transit providers – og til internet exchanges (DIX og Netnod Comix pt.) hvilke netværk jeg har bagved min router, pt. annoncerer vi således ~35 prefixes og dermed ~20.000 IPv4 adresser – som så fordi vi betaler for det kan nås fra “hele internet”. NB: en route peger på en router, next-hop men typisk tales om prefix som er det netværksprefix som det drejer sig om.

TL;DR default free zone har ikke en gateway of last resort så får en router en pakke til en destination som ikke findes i tabellen smides pakken væk!

Du kan læse mere om dette ved at søge på, CIDR report, BGP, default free zone

BGP blackhole for DDoS protection

Når vi som ISP befinder os på kanten af DFZ kan vi styre hvorledes vi annoncerer vores prefixes, og vore kunders prefixes og det kan i høj grad automatiseres med indstillingerne for BGP communities https://en.wikipedia.org/wiki/Border_Gateway_Protocol#Communities

Jeg kan eksempelvis vælge at min annoncering til Tier 1 ISP X skal være “længere” – path prepending eller at det pågældende prefix kun skal annonceres videre under bestemte forhold. Et mere eller mindre tilfældigt eksempel kan findes for Telia International Carrier AS1299 http://onesc.net/communities/as1299/

Så ved at sætte BGP community 1299:7009 på en annoncering burde Telia ikke annoncere dette prefix videre i asien. Aha! Vi kan altså som kunde begynde at influere på hvordan vi annoncerer, og hvordan vores netværk ses længere ude på internet – i DFZ.

En anden feature som de store ISP’er tilbyder er blackholing, en service hvor man kan annoncere enkelte IP-adresser – /32 prefix, eksempelvis 192.0.2.10/32, hvorefter den pågældende udbyder smider alle pakker med denne destination væk! Det betyder at de kan droppe pakkerne hurtigt i deres netværk, og du betaler ikke for den trafik – men får heller ikke clean/valid trafik :-(

Et eksempel fra Cogent er deres formular http://cogentco.com/files/docs/customer_service/guide/bgpq.sample.txt:

Ulempen ved dette er at enten smider de trafikken væk, eller tillader den kommer igennem … dette kaldes derfor BGP blackholing. Fordelen er at resten af dit netværk stadig modtager trafik.

DDoS Damage Control

Enter DDoS Damage Control, altså begrænsning af skaderne, fremfor totalt blackhole, og her er
Job Snijders præsentation fra RIPE68 helt central. Anbefalingen her er at man med BGP communities i en mere udstrakt grad kan bestemme hvad der smides væk – og hvor! Det betyder at man selektivt smider pakkerne væk bestemte steder.

Så vi er nu, med få store skridt, kommet frem til at:

  • Vi kan annoncere vores netværk – dermed kan de nås via diverse udbydere
  • Vi kan tilpasse vores annonceringer så de annonceres på bestemte måder, annoncering i asien, eller ej
  • Vi kan smide traffik væk med BGP blackholing, eksempelvis fortælle nogle af vores udbydere at de skal smide alt væk til IP 192.0.2.10
  • Vi kan med forslaget fra Job annoncere at i bestemte regioner skal trafikken til bestemte destinationer smides væk

Værktøjskassen for at begrænse skaderne fra DDoS er altså blevet lidt større end den gammeldags, on/off BGP blackhole. Postulatet er således at vi kan opnå næsten fuld tilgængelighed indenfor et geografisk område, med NL som eksempel i Jobs præsentation. I praksis vil der formentlig stadig være noget DDoS-angrebstrafik som rammer målet, men hvis det er begrænset nok kan det håndteres med “normalt udstyr” firewalls, routere og serverkapacitet.

Konklusionen er ihvertfald klar, man skal ikke blot kaste håndklædet i ringen med det samme, men begynde at analysere sin brugssituation, lave en baseline over hvor ens “kunder” (i bred forstand) kommer fra og derefter tænke over hvilke værktøjer som kan bruges.

Det er selvfølgelig heller ikke alle der kan lave den slags trick, og for nogle vil det være bedre at købe en service, eller software til at håndtere dette.

Skole IT og eksamener

Når nu ovenstående er præsenteret, så har jeg et forslag. Der bliver talt meget om skoler og eksamener, undervisningsministeriet osv.

Der er formentlig ikke nogen udenfor Danmark som skal tilgå bestemte hjemmesider og applikationer som benyttes til eksamen i Danmark – ellers er det relativt få steder og kan testes på forhånd. Det vil altså være muligt at lave en positivliste over ISP’er i Danmark, man kunne starte med listen fra RIPE https://www.ripe.net/membership/indices/DK.html.

Dernæst kunne man placere de pågældende services indenfor samme netværksrange, den skal af tekniske årsager være en /24 – men det kan findes. Derved åbner man for alle ovenstående muligheder for at annoncere og påvirke datastrømmen – herunder eventuelle DDoS-angrebs datapakker – og forslaget er:

  • Eksamensnetværket annonceres kun i “Danmark”, dvs til danske ISP’er og eventuelt via tunnel ud til relevante steder i verden.
  • Eksamensnetværket annonceres ikke til “internet” – dvs optræder slet ikke i DFZ, og pakkerne fra en angriber/computer med denne destionation vil således ikke komme ret langt hos ISP’erne før de smides væk – no route to destination

Altså en begrænset, men overlagt strategi, som gør at visse services kun kan nås fra Danmark, og eventuel angrebstraffik vil således også kun komme fra Danmark, hvilket letter sporing og oprydning betragteligt!

Til slut, ovenstående kræver viden, men det er ikke raketvidenskab. Der er mange netværksadministratorer i Danmark som ville kunne udføre og drive en sådan løsning med relativt lille budget. Det er samtidig ikke en ekstraydelse fra ISP’erne at bruge deres BGP communities og derved er omkostningerne generelt ret lave for denne type løsning.

TL;DR lær teknologierne at kende, hold din viden opdateret med RIPE konference, bekæmp DDoS mere intelligent

Posted in computer.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>