One.com ramt af massivt DDoS-angreb via NTP-servere

Kilden skrev:

I morgen ved 8:30-tiden

Enten kan i se fremtiden, eller også er det rent faktisk en invitation til et angreb i morgen!

Har naturligvis sendt en rettelse, fandt det bare lidt morsomt :)

Jeg har ved én af mine kunder oplevet samme problem. Dog knap så voldsomt DDOS - Men det kunne mærkes.

Jeg forstår ikke hvorfor en stor udbyder som One, ikke gør noget ved problemet på forhånd, da det har været kendt et par uger efterhånden?

#2: Du finder da bare lige på en metode til at blokere for DDoS uden at lukke af for legitime forbindelser.

#3 Mon ikke det var sårbarheden i NTP-serverene der blev henvist til?

Kender ikke noget til det specifikke problem, så ved ikke om det er nemt at gøre noget ved.

#4 Spot on.

Læs evt. http://blog.cloudflare.com/understanding-and-mitig...

#3 Er udmærket klar over problematikken med DDOS - Men det er i de flestes tilfælde muligt at anvende lokal NTP server, og undgå at åbne for det i firewall, og dermed begrænse belastningen på netværket voldsomt.

#5: Lokal NTP server vil ikke gøre en disse.
Probemstillingen er den samme som med DNS Bouce. Selv om du lukker for indadgående trafik på NTP eller DNS, så vil det uanset stadig være din firewall der "ejer" den ramte IP eller IP ranges og dermed skal den først modtage pakken før den kan afvise den.

I realiteten betyder det at pakkerne når at ryge over "din del af internettet" og lægge din linje ned.

Og selv om du har alverdens båndbredde skal din FW stadig formå at filtrere tusinder/millioner af "falske" forbindelser da disse "bounce"/båndbredde DDoS attacks typisk ledsages af netop SYN floods.

Altså er det meget begrænset hvad en lokal FW kan gøre. Den eneste måde er at have lokalt udstyr på ISP'ens breakouts - helst en T1 eller T2 ISP.

Her fra min lænestol ligner det mest af alt at firmaerne bag alle de store backbone netværk må tjene kassen på det DDoS halløj her.

Ellers var de jo for længst gået i gang med at fjerne deres peering med netværk der tillader spoofede source adresser at forlade nettet.

Jeg skal dog erkende at jeg ikke ved om de rent faktisk er travlt igang allerede.

Det er da helt oplagt Microsoft der står bag!

#8
Tænkte præcis det samme da jeg læste nyheden! Eller en aktionær i Microsoft der plejer sin formue..

Ca halvdelen af internettet har ikke implementeret antispoofing, så det er lidt op af bakke..
#6: når man som one.com har flere peeringpartnere er det nok temmeligt usandsynligt at de ikke har routere INDEN diverse stateful firewallls, og her er det ret trivielt at police ntp til 20mbit eller lignende fra hver upstream provider.
Der kan dog stadig komme så meget trafik at regulær trafik droppes hos upstreams,inden det når one.com og det er der ikke meget at gøre ved - udover bigger pipes!

Er det bare mig, eller har der været utroligt mange angreb af den her slags på det sidste?

Og stadigvæk hører man intet om, hvem der evt. kunne stå bag?

luuuuu (7) skrev:

Ellers var de jo for længst gået i gang med at fjerne deres peering med netværk der tillader spoofede source adresser at forlade nettet.

Problemet er at man kan ikke afgøre med sikkerhed, om source IP er spoofet.

Et stabilt internet kræver redundans. Når man har redundante forbindelser er der også mulighed for asymmetrisk routing, hvor pakker fra A til B går gennem andre routere end pakker fra B til A.

Kombineret med at internettet består af mange forskellige AS, og man ikke ved hvordan de andre router deres pakker kan det altså være umuligt at afgøre om en source IP er spoofet.

Nogle udbydere vælger at være meget skrappe i deres filtrering, hvilket resulterer i, at legitime pakker kan filtreres. Dermed vil kunderne være nødt til at route deres trafik på en måde, som undgår filtrene. Når der er færre muligheder for, hvordan man router sin trafik er der større risiko for, at man bliver nødt til at route på en måde, som ikke giver den optimale stabilitet.

Af den grund kan jeg sagtens forstå at nogle udbydere lader være med at filtrere. Og som kunde er der fordele ved at vælge en udbyder, der ikke filtrerer.

Jeg mener at problemet ene og alene er amplification. Jeg har flere gange set problemer, hvor en forbindelse blev floodet pga. amplification uden at der var nogen form for spoofing involveret.

Forhinder amplification og du vil have løst problemet plus nogle andre. Det er selvfølgelig lidt omstændigt at gå gennem alle protokoller, som potentielt kan lide af amplification svagheder. Men det er helt klart primært UDP baserede protokoller, der er udsat.

Måske ville det være fornuftigt hvis de fleste links havde en policy der ikke tillod at UDP brugte mere end 50% af båndbredden. Så ville man altid kunne få TCP trafik igennem, uanset om netværket var udsat for et UDP baseret amplification angreb.

Og da TCP nok udgør over 50% af den legitime trafik på nettet, og TCP protokollen i sig selv forhindrer amplification sådan at applikationslaget ikke skal bekymre sig om det, ville det måske være fornuftigt at reservere en procentdel af båndbredden til TCP, således at man altid har noget fri båndbredde til TCP, uanset hvilke andre protokoller der evt. måtte være involveret i et amplification angreb.

Men vi skal selvfølgelig også til at tænke mere over muligheden for amplification. Alle nye protokoller bør designes, så de ikke kan udnyttes til amplification, og vi skal se på, hvordan vi kan sikre de gamle.

Man kan detektere om ens DNS eller NTP server er involveret i et spoofing+amplification angreb ved at kigge efter ICMP fejlmeldinger. Hvis softwaren detekterer det kan man træffe passende foranstaltninger. Med DNS kan man f.eks. kræve at den pågældende klient IP laver mindst ét opslag over TCP, før den kan få lov at lave opslag over UDP igen. Jeg ved ikke om der findes lignende løsninger til NTP.

En protokoludvidelse, med en cookie til at beskytte imod amplification ville være den bedste løsning på længere sigt.

kasperd (12) skrev:

En protokoludvidelse, med en cookie til at beskytte imod amplification ville være den bedste løsning på længere sigt.

Efter lidt overvejelser tænker jeg at en sådan løsning faktisk kunne implementeres på IP niveau og dermed kunne beskytte alle protokoller så man ikke længere er nødt til at beskytte protokoller enkeltvis på applikationsniveau.

Løsningen jeg forestiller mig er følgende.

1. Klienten sender først en pakke (typisk UDP) til serveren.
2. Serveren ser at der ingen cookie er, og den dermed ikke ved om source IP er spoofet.
3. Serveren afviser pakken ved at sende en ICMP fejlmelding tilbage. Message body feltet i ICMP fejlmeldingen indeholder en 4 bytes cookie.
4. Serveren laver evt. rate limiting på ICMP fejlmeldingerne således at det samlede antal bytes i fejlmeldingerne ikke overstiger antallet af bytes i de oprindelige pakker.
5. Klienten ser fejlmeldingen og retransmitterer den oprindelige pakke.
6. Klienten indsætter en destination options header i svaret som indeholder en option med cookie fra serveren.
7. Serveren ser at klienten denne gang sender en korrekt cookie, og accepterer forespørgselen.
8. Serveren sender et stort svar tilbage til IP adressen, den nu har fået bekræftelse på er korrekt.

Det kræver et roundtrip mere end et opslag uden denne cookie, men det er en nødvendighed for at løse problemet. Ved at sikre at cookie kan genbruges til flere requests (f.eks. ved at lade dens gyldighed være en time lang) kan man undgå at skulle have det ekstra roundtrip på hver eneste request.

Det kunne måske være smart med en destination option som serveren kan bruge til at sende en ny cookie før den gamle udløber således at ved periodisk kommunikation mellem klient og server går der endnu længere med at man har det ekstra roundtrip.

Det vil nok være simplere at bruge en enkelt header til begge dele, lidt i stil med måden timestamp option i TCP er struktureret på. Så kan der bruges cookies i begge retninger. Det vil dog øge størrelsen af option headeren fra 8 til 16 bytes. Der vil være fire bytes til overs, som jeg ikke har nogen god idé til, hvad man kan bruge til.

Forslag til forbedringer inden jeg kaster mig over et proof of concept?

kasperd (13) skrev:

Det vil nok være simplere at bruge en enkelt header til begge dele, lidt i stil med måden timestamp option i TCP er struktureret på. Så kan der bruges cookies i begge retninger. Det vil dog øge størrelsen af option headeren fra 8 til 16 bytes. Der vil være fire bytes til overs, som jeg ikke har nogen god idé til, hvad man kan bruge til.

Efter jeg har sovet på det har jeg svaret på hvad de fire bytes skal bruges til. De fire bytes skal bruges til en nonce, som anvendes i følgende scenarie:

1. Det ene endepunkt sender pakke med cookie option. Denne option indeholder følgende tre felter af fire bytes hver: cookie valgt af destination, cookie valgt af source, nonce valgt af source.
2. Modtageren konstaterer at feltet med cookie valgt af destination er forkert.
3. Modtageren sender ICMP fejl tilbage med den rigtige cookie.
4. Afsenderen ser ICMP fejl og validerer alle 12 bytes i cookie option af den returnerede pakke før den nye cookie accepteres.

Ved at validere de 12 bytes sikrer man sig imod DoS angreb som forsøges udført ved at spoofe ICMP fejl af ovenstående type og dermed overskrive den korrekte cookie med en forkert cookie.

Bliz0r (2) skrev:

Jeg forstår ikke hvorfor en stor udbyder som One, ikke gør noget ved problemet på forhånd, da det har været kendt et par uger efterhånden?

Var det ikke andres NTP servere som blev brugt til at angribe One med?

tentakkelmonster (11) skrev:

Er det bare mig, eller har der været utroligt mange angreb af den her slags på det sidste?

Og stadigvæk hører man intet om, hvem der evt. kunne stå bag?

Der har været en hel del problemer med One.com her på det sidste (vi snakker henover de sidste ~4mdr).
Disse problemer har sikkert også været pga. dette, men de dog så nok først nu, har haft "lyst" til at fortælle om den egentlige årsag.

Edit:
..og ja; jeg finder det da bestemt også lidt underligt at der ikke kommer noget info frem om dem der står bag (Ikke kun bag dette med One.com, men generelt).