CloudFlare-nedbrud trak 785.000 hjemmesider offline

Jeg sad på 4chan hele dagen og har ikke haft problemer med siden overhovedet. Så det kan ikke være længe den har været nede da

#1

/b/ ?

Fedt med detaljerne omkring nedbruddet. Det gør det mere forståeligt for folk og andre sites kan lære af det.

Nu er det vel ikke så mærkeligt de går ned, hvis man laver en regl i JunOS som tjekker for packet-length [ 99971 - 99985 ];
Hele problemet ved at lave dette tjek er at man skal gemme samtlige packets i rammene for at lave tjekket.

dvs, hvis et ddos står på, sender de pakker, skal hver packet skrives til rammene på routeren, for at lave et tjek om størrelsen er mellem 99971 og 99985 bytes. Da tjekket højest sandsynligt tager længere længere tid, end hver packet der kommer ind, vil hver packet gemme ca 97kilobytes i rammene.

Dvs, 10000 packets i sekundet vil betyde et ram forbrug på 970000kilobyte. Da de højest sandsynligt modtager en del mere end 10k packets per sekund, så skal de kunne lave checks utrolig hurtigt, og gøre plads til en ny række packets.

Hvad de kunne have gjort istedet for, var at sige, hvis backet er større end 4470bytes, så drop dem.
Da de har en maximum packet size på 4470 bytes. så hvis den er 4471 bytes vil den ikke blive godtaget.

Så ville de kun tage op 4.47kilobyte per packet istedet for 97kilobyte - så teoretisk ville de kunne klare 20-21 gange flere packets med samme mængde ram.

#1

/b/ ?Montago (#2)

4chan bruger selv Cloudflare din pong xD

#1

/b/ ?Montago (#2)

4chan bruger selv Cloudflare din pong xDHerrMansen (#5)

ved jeg da godt... :)

tænkte at der sad en noob hacker og hackede 127.0.0.1'ish

tænkte at der sad en noob hacker og hackede 127.0.0.1'ishMontago (#6)

Hah... Særere ting er sket derinde i gennem årene.

Alle internettjenestens netværk gik ned, hvilket også ramte tjenestens statusblog. Derfor var den eneste måde, som kunder kunne få informationer på, at følge med på CloudFlares Twitter-profil.

Kunne være de skulle hoste den hos rackspace ;)

Så de tilbyder DDoS-beskyttelse til deres kunder, og når de (kunderne) så bliver udsat, laver de et fuckup så ALLE kunder ryger offline? Flot :D

#9
Vi sætter jo vores lid til deres ekspertise, og det er OFTE at det er godt nok. Jeg ville aldrig opdage et DDoS mod et af mine sites (grundet deres lille størrelse), og endnu mindre vide hvad jeg skulle gøre for at forhindre det.

At Cloudflare så én gang i mellem laver ged i den, det kommer jo så med. Men som #4 siger, så lyder det som om (givet de infos vi har) at det kunne være gjort bedre. :)

EDIT:
Jeg kan anbefale at læse kilden. Det er en interessant historie. To ting slår mig dog:

1. Det virker som en overilet / rutinepræget solution som blev udført: Blot at filtrere angrebet med en specifik regel uden tanke for præmisserne (pkt. 2)

2. Hvis reglerne tidligere siger at ingen pakke må overstige 4470 bytes. Hvordan kan reglen om DNS pakker på 99 KB nogensinde rammes - og hvorfor skal DNS reglen så implementeres, den er jo for pokker unødvendig grundet maks-størrelsen?

#9
Vi sætter jo vores lid til deres ekspertise, og det er OFTE at det er godt nok. Jeg ville aldrig opdage et DDoS mod et af mine sites (grundet deres lille størrelse), og endnu mindre vide hvad jeg skulle gøre for at forhindre det.

At Cloudflare så én gang i mellem laver ged i den, det kommer jo så med. Men som #4 siger, så lyder det som om (givet de infos vi har) at det kunne være gjort bedre. :)

EDIT:
Jeg kan anbefale at læse kilden. Det er en interessant historie. To ting slår mig dog:

1. Det virker som en overilet / rutinepræget solution som blev udført: Blot at filtrere angrebet med en specifik regel uden tanke for præmisserne (pkt. 2)

2. Hvis reglerne tidligere siger at ingen pakke må overstige 4470 bytes. Hvordan kan reglen om DNS pakker på 99 KB nogensinde rammes - og hvorfor skal DNS reglen så implementeres, den er jo for pokker unødvendig grundet maks-størrelsen?LordMike (#10)

Problemet er den regl med de maks acceptere 4470 bytes, dropper ikke alle andre pakker, den sender dem stadig videre (Giver egentligt ikke mening, fordi så virker deres regl jo ikke helt).

Hvorimod hvis de brugte:

packet-length-except [5-4470]; så ville det gøre, alle der ikke matchede, ville blive dropped direkte.

Så selvom du maks tillader 4470 bytes i packet-length, så kan juniper routers stadig modtage pakker, og sende dem videre, hvis ikke du specifikt har fortalt JunOS til at droppe de pakker der ikke matcher.

Problemet ligger i, at jeg tror ikke de har tænkt over det da de lavede reglen, og sagt, vi acceptere kun 4470 bytes, lad os lave en regl der dropper alt andet.

Meen alle kan fejle, selv CloudFlare

Jeg synes at de har klaret den godt med en nede tid på 1 time. Det er self meget når der er så mange sites på spil.

Men ja, de skulle nok ha sagt, som mange af Jer nævner. Kun pakke størrelser i 4,471 og ikke mere... Det undre mig at de har valgt at specificere at den skal droppe alt fra de mega pakker der bliver sendt ind.
Men okay.

Selv de bedste kan fejle. De har fået en Lessons-learned, til næste gang ;)

Også synes jeg at det er super fedt at de har forklaret meget detaljeret om hvad der har forgået under nedetiden. :) Den ros skal de da bestemt ha.