mboost-dp1
Flickr - saschaaa
Det jo helt vildt. Så de smider lige 37,5GB/s i sekundet efter Spamhause. 300gb/s / 8 = 37,5GB/s inden nogle spøger.
Men interessant at Google har stillet servere til rådighed.
MS plejer jo at være rimelig aktive i at lukke botnets. Nogle der ved om MS blander sig i dette i forhold til politienhederne.
Men interessant at Google har stillet servere til rådighed.
MS plejer jo at være rimelig aktive i at lukke botnets. Nogle der ved om MS blander sig i dette i forhold til politienhederne.
"Cyberbunker, [er] et firma, der sælger sig selv på, at de vil hoste hvad som helst, der ikke er børneporno eller relateret til terrorisme."
Det kunne man også skrive som "Cyberbunker er et firma som vil hoste alt som ikke er ulovligt, og som ikke fjerner dit lovlige indhold fordi Hollywood presser den svenske regering.
Spamhaus gør generelt et godt stykke arbejde, men det er godt nok ikke altid at jeg er enig i deres metoder (blackmail, osv).
Om Cyberbunker er fjenden eller offeret kommer helt an på hvordan man ser på det. Denne artikel gør imo Cyberbunker til fjenden (fx at et legitim firma skulle "samarbejde" med kriminelle fra Østeuropa og Rusland lyder absurd).
Det kunne man også skrive som "Cyberbunker er et firma som vil hoste alt som ikke er ulovligt, og som ikke fjerner dit lovlige indhold fordi Hollywood presser den svenske regering.
Spamhaus gør generelt et godt stykke arbejde, men det er godt nok ikke altid at jeg er enig i deres metoder (blackmail, osv).
Om Cyberbunker er fjenden eller offeret kommer helt an på hvordan man ser på det. Denne artikel gør imo Cyberbunker til fjenden (fx at et legitim firma skulle "samarbejde" med kriminelle fra Østeuropa og Rusland lyder absurd).
Laks (3) skrev:Det kunne man også skrive som "Cyberbunker er et firma som vil hoste alt som ikke er ulovligt,
Ahhhh.. Der er vist lidt flere ting i den her verden der er ulovligt end lige børneporno og terrorisme.
Laks (3) skrev:Om Cyberbunker er fjenden eller offeret kommer helt an på hvordan man ser på det.
Gør det så også det? Lad os nu antage at det er bevist at CyberBunker Står bag dette DDoS angreb, Hvordan kan de så være et offer? De vælge at besvare en lovlig fremgangsmåde, nemlig ekskludering, med en ulovlig fremgangs måde, nemlig DDoS.
Hvordan man så forholder sig til sagen rent moralsk, er jo subjektiv som altid, men i lovens forstand, er den jo lige til det højre ben
Personligt ville jeg da også selv prøve at holde min virksomhed væk fra virksomheder, der som udgangspunkt melder ud, at de selv vil bestemme hvilke love de vælger at overholde.
DEEF (5) skrev:Ved ikke helt, hvad jeg synes om at de store firmaer som Google blander sig i denne kamp, som for mig ligger i en "grå-zone". Hvad blev der af det frie internet?
Jeg forstår ikke helt hvad du mener der går imod det frie internet ved at google blander sig?
Google støtter det frie internet ved at hjælpe dem, der bliver undertrykket via krimineller metoder.
DEEF (7) skrev:Men hvem kastede den første sten?
Dumt spørgmål, Her snakker vi om lovlig versus ulovlige fremgangsmåder. Motiverne er som sådan irrelevante.
Hængerøven (4) skrev:Lad os nu antage at det er bevist at CyberBunker Står bag dette DDoS angreb, Hvordan kan de så være et offer?
Hvis vi antager at de er skyldige, ja, så er de sjovt nok skyldige.
Men i artiklen har jeg ikke kunnet finde andet bevis end Spamhaus' egne udtalelser. Og de kan næppe betragtes som en neutral kilde.
.. og hvornår har jeg sagt anderledes? Hvis du læser på CyberBunker hjemmeside, så kan du se at de selv skriver at de ikke hoster ulovligt indhold, at Newz så tolker dette som "børneporno og terrorisme" er en anden ting.Hængerøven (4) skrev:Ahhhh.. Der er vist lidt flere ting i den her verden der er ulovligt end lige børneporno og terrorisme.
CyberBunker er meget large hvad angår "gråzoner", men i og med at noget indhold ligger i en gråzone, så er det jo lige netop ikke (direkte) ulovligt.
Lad os nu antage at Osama Bin Laden er en uskyldig mand som aldrig har gjort en flue fortræd... kan du godt selv se at der er noget galt i at starte en sætning sådan? :)Hængerøven (4) skrev:Lad os nu antage at det er bevist at CyberBunker Står bag dette DDoS angreb, Hvordan kan de så være et offer?
Personligt er jeg selv en person som gerne tager kampen op, når man bliver trådt over tæerne af et stort firma som mener at de kan diktere loven fordi de har mange penge og politisk indflydelse - sådan er vi jo så forskellige.Hængerøven (4) skrev:Personligt ville jeg da også selv prøve at holde min virksomhed væk fra virksomheder, der som udgangspunkt melder ud, at de selv vil bestemme hvilke love de vælger at overholde.
Og i 3F sagen måtte det jo være Saxo som havde betalt "bagmændene" - lige indtil man fandt ud af at det var en flok scriptkiddies som sad og havde sjov på andres servere bekostning.Testa (11) skrev:Angrebet fortsætter jo nok kun så længe at der er penge i det for botnet´s bagmændene.
Det koster sådan set intet at sætte en anden (hacket) server til at gøre en opgave, og tit og ofte er angreb mere drevet af "lulz" end profit.
CyberBunker er nok populær hos en masse "hackere" fordi CyberBunker kæmper for et frit internet. Modsat er Spamhaus upopulær hos 'de mindre lovlige borgere'. Så er det ikke svært at gætte hvem det største (D)DoS rammer.
Nu skal man liiige ta' det med et gran salt og sætte tingene lidt i perspektiv. Det er et massivt angreb, men at internettet overordnet har været sløvt virker der ikke til at være konsensus om:
http://gizmodo.com/5992652/that-internet-war-apoca...
http://gizmodo.com/5992652/that-internet-war-apoca...
#15
Som jeg har forstået nyheden så er det jo netop størrelsen af angrebet, og længden af det som gør at det nok ikke bare er nogle scriptkiddies der sidder og gør det for the lulz.
Bare fordi at der er nogle der syntes det er "sjovt" så er der nok også nogle der går skridtet videre og forsøger at tjene på det.
Plus der er nok en forskel mellem en lokal dansk konflikt og så noget som bliver blæst op som en kamp for det frie internet.
Som jeg har forstået nyheden så er det jo netop størrelsen af angrebet, og længden af det som gør at det nok ikke bare er nogle scriptkiddies der sidder og gør det for the lulz.
Bare fordi at der er nogle der syntes det er "sjovt" så er der nok også nogle der går skridtet videre og forsøger at tjene på det.
Plus der er nok en forskel mellem en lokal dansk konflikt og så noget som bliver blæst op som en kamp for det frie internet.
Jeg læste nogle artikler som nævnte at angrebet bruger DNS servere til at forstærke angrebet. F.eks. denne artikel: http://epn.dk/article5285493.ece
Metoden går i sin enkelthed ud på at sende en DNS forespørgsel med forfalsket afsenderadresse. DNS serveren sender så et svar tilbage til den forfalskede afsenderadresse, som er det egentlige offer for angrebet. Da DNS svaret er større end forespørgslen vil offeret modtage mere trafik end afsenderen er i stand til at sende.
Den metode gør det også praktisk taget umuligt for offeret at se, hvor angrebet kommer fra. Hvilket så betyder at det ikke lyder voldsomt troværdigt, når specifikke personer hænges ud for at stå bag.
Hvor effektivt et angreb af den type kan være afhænger af forholdet mellem størrelsen på DNS forespørgslen og størrelsen på svaret. Oprindeligt havde DNS en øvre grænse på UDP pakker (både forespørgsler og svar) på 512 bytes. Men med DNSSEC er 512 bytes ikke længere nok.
Denne begrænsning ville have betydet, at man med DNSSEC var nødt til at sende forespørgslerne over TCP. Det er mindre effektivt til DNS opslag end UDP, og derfor ville man gerne undgå det. En feature i EDNS er at klienten kan fortælle serveren, hvor store svar den kan håndtere. Med EDNS kan svarene gå helt op til 4096 bytes. Og nogle domæner er tæt på den grænse.
Det betyder at ved at udnytte passende opslag kan angrebet blive 8 gange mere effektivt end uden EDNS. Dette er et kritikpunkt imod DNSSEC som er blevet rejst flere år tilbage. Og denne episode beviser at det er en relevant kritik.
Tvang man opslag med store svar over på TCP ville man ikke have det samme problem, da forfalsket afsenderadresse ikke vil virke. For at gennemføre et angreb ville man også være nødt til at gætte TCP sekvensnummeret. Chancen for at gætte sekvensnummeret rigtigt er så lille, at det reducerer effekten af angrebet så langt at forstærkelsesfaktoren bliver mindre end en.
Men desværre er der endnu ikke lavet nogen løsning som både giver de effektive opslag som EDNS tillader og beskyttelsen imod forstærkelse af flooding angreb som TCP giver.
Jeg undersøgte hvordan situationen ser ud med bind på en Ubuntu 12.04 installation med alle sikkerhedsopdateringer installeret. Hvis man har sat sådan en installation op til at tillade opslag fra hele Internettet er der tilsyneladende ingen beskyttelse imod denne type angreb.
Har man ikke brug for at håndtere DNS opslag fra hele nettet, så skal man sørge for at DNS serveren ikke tillader det. Har man grund til at acceptere DNS opslag fra hele nettet er den bedste beskyttelse på nuværende tidspunkt at lade være med at tillade svar op til 4096 bytes. Man kan tilføje følgende linje til sin bind konfiguration for at reducere den maksimale størrelse på svar:
Hvis man har en DNS server og gerne vil vide om den bliver brugt i angrebet kan man f.eks. bruge følgende tcpdump kommando:
Den kigger ikke efter DNS opslag eller svar, da det også ville fange alle legitime opslag. I stedet kigges efter de fejlmeldinger som sendes tilbage, når svarene sendes til en modtager, som ikke forventer noget DNS svar.
Faktisk ville det være muligt for DNS serveren selv at holde øje med disse fejlmeldinger for på den måde at opdage, at den bliver misbrugt i et angreb. Jeg har dog ikke kendskab til at nogen DNS server skulle have implementeret det.
Mit bedste forslag til DNS serverens reaktion, hvis den opdager at DNS svar resulterer i fejlmeldinger er at automatisk reducere den maksimale svar størrelse til 512 bytes indtil angrebet ser ud til at være ovre.
Måske er det på tide med en ny RPC protokol designet til at forhindre forstærkelsesangreb. Jeg har et par bud på, hvordan sådan en protokol kunne se ud:
1. Under normale omstændigheder udveksles to pakker. En forespørgsel fra klienten og et svar fra serveren. Svaret fra serveren inkluderer en cookie som klienten kan bruge i senere forespørgsler for at bevise at afsenderadressen er autentisk.
2. Hvis serveren ser fejlmeldinger komme tilbage med gyldig cookie er det indikation på at der kan være et angreb igang. Serveren sender herefter ikke fulde svar på forespørgsler uden gyldig cookie, men sender kun en cookie tilbage.
3. Hvis klienten kender en cookie sendes den automatisk med til serveren hver gang. Kender klienten ikke en cookie sendes request uden cookie, og får den ikke et fuldt svar anvendes den cookie som den modtog i stedet til at retransmittere forespørgslen.
Denne fremgangsmåde ville højst kræve et enkelt ekstra roundtrip, og det ekstra roundtrip ville kun være krævet, når det er absolut nødvendigt. Overheadet er langt lavere end en fuld TCP session. Serveren behøver ikke ekstra hukommelse for at huske på cookies. En HMAC beregnet på klientens IP adresse ville være alt rigeligt. HMAC-nøglen kan f.eks. opdateres en gang i timen, og gamle cookies kan accepteres i en halv time efter nøglen er udløbet.
Laver man sådan en opdatering til DNS protokollen vil man selvfølgelig også øge størrelsen på request ID ved samme lejlighed, så vi kan slippe af med cache poisoning. (På den anden side kunne problemet med cache poisoning mere eller mindre løses uden at introducere nogen nye protokoller. Man skulle bare give sin DNS server et /64 prefix og bruge de sidste 64 bits i IP adressen som supplement til det 16 bits ID der ellers bruges i DNS.)
Metoden går i sin enkelthed ud på at sende en DNS forespørgsel med forfalsket afsenderadresse. DNS serveren sender så et svar tilbage til den forfalskede afsenderadresse, som er det egentlige offer for angrebet. Da DNS svaret er større end forespørgslen vil offeret modtage mere trafik end afsenderen er i stand til at sende.
Den metode gør det også praktisk taget umuligt for offeret at se, hvor angrebet kommer fra. Hvilket så betyder at det ikke lyder voldsomt troværdigt, når specifikke personer hænges ud for at stå bag.
Hvor effektivt et angreb af den type kan være afhænger af forholdet mellem størrelsen på DNS forespørgslen og størrelsen på svaret. Oprindeligt havde DNS en øvre grænse på UDP pakker (både forespørgsler og svar) på 512 bytes. Men med DNSSEC er 512 bytes ikke længere nok.
Denne begrænsning ville have betydet, at man med DNSSEC var nødt til at sende forespørgslerne over TCP. Det er mindre effektivt til DNS opslag end UDP, og derfor ville man gerne undgå det. En feature i EDNS er at klienten kan fortælle serveren, hvor store svar den kan håndtere. Med EDNS kan svarene gå helt op til 4096 bytes. Og nogle domæner er tæt på den grænse.
Det betyder at ved at udnytte passende opslag kan angrebet blive 8 gange mere effektivt end uden EDNS. Dette er et kritikpunkt imod DNSSEC som er blevet rejst flere år tilbage. Og denne episode beviser at det er en relevant kritik.
Tvang man opslag med store svar over på TCP ville man ikke have det samme problem, da forfalsket afsenderadresse ikke vil virke. For at gennemføre et angreb ville man også være nødt til at gætte TCP sekvensnummeret. Chancen for at gætte sekvensnummeret rigtigt er så lille, at det reducerer effekten af angrebet så langt at forstærkelsesfaktoren bliver mindre end en.
Men desværre er der endnu ikke lavet nogen løsning som både giver de effektive opslag som EDNS tillader og beskyttelsen imod forstærkelse af flooding angreb som TCP giver.
Jeg undersøgte hvordan situationen ser ud med bind på en Ubuntu 12.04 installation med alle sikkerhedsopdateringer installeret. Hvis man har sat sådan en installation op til at tillade opslag fra hele Internettet er der tilsyneladende ingen beskyttelse imod denne type angreb.
Har man ikke brug for at håndtere DNS opslag fra hele nettet, så skal man sørge for at DNS serveren ikke tillader det. Har man grund til at acceptere DNS opslag fra hele nettet er den bedste beskyttelse på nuværende tidspunkt at lade være med at tillade svar op til 4096 bytes. Man kan tilføje følgende linje til sin bind konfiguration for at reducere den maksimale størrelse på svar:
max-udp-size 512;
Hvis man har en DNS server og gerne vil vide om den bliver brugt i angrebet kan man f.eks. bruge følgende tcpdump kommando:
tcpdump -pni eth0 -s0 'icmp[8] == 0x45 && icmp[17] == 0x11 && icmp[28] == 0 && icmp[29] == 53'
Den kigger ikke efter DNS opslag eller svar, da det også ville fange alle legitime opslag. I stedet kigges efter de fejlmeldinger som sendes tilbage, når svarene sendes til en modtager, som ikke forventer noget DNS svar.
Faktisk ville det være muligt for DNS serveren selv at holde øje med disse fejlmeldinger for på den måde at opdage, at den bliver misbrugt i et angreb. Jeg har dog ikke kendskab til at nogen DNS server skulle have implementeret det.
Mit bedste forslag til DNS serverens reaktion, hvis den opdager at DNS svar resulterer i fejlmeldinger er at automatisk reducere den maksimale svar størrelse til 512 bytes indtil angrebet ser ud til at være ovre.
Måske er det på tide med en ny RPC protokol designet til at forhindre forstærkelsesangreb. Jeg har et par bud på, hvordan sådan en protokol kunne se ud:
1. Under normale omstændigheder udveksles to pakker. En forespørgsel fra klienten og et svar fra serveren. Svaret fra serveren inkluderer en cookie som klienten kan bruge i senere forespørgsler for at bevise at afsenderadressen er autentisk.
2. Hvis serveren ser fejlmeldinger komme tilbage med gyldig cookie er det indikation på at der kan være et angreb igang. Serveren sender herefter ikke fulde svar på forespørgsler uden gyldig cookie, men sender kun en cookie tilbage.
3. Hvis klienten kender en cookie sendes den automatisk med til serveren hver gang. Kender klienten ikke en cookie sendes request uden cookie, og får den ikke et fuldt svar anvendes den cookie som den modtog i stedet til at retransmittere forespørgslen.
Denne fremgangsmåde ville højst kræve et enkelt ekstra roundtrip, og det ekstra roundtrip ville kun være krævet, når det er absolut nødvendigt. Overheadet er langt lavere end en fuld TCP session. Serveren behøver ikke ekstra hukommelse for at huske på cookies. En HMAC beregnet på klientens IP adresse ville være alt rigeligt. HMAC-nøglen kan f.eks. opdateres en gang i timen, og gamle cookies kan accepteres i en halv time efter nøglen er udløbet.
Laver man sådan en opdatering til DNS protokollen vil man selvfølgelig også øge størrelsen på request ID ved samme lejlighed, så vi kan slippe af med cache poisoning. (På den anden side kunne problemet med cache poisoning mere eller mindre løses uden at introducere nogen nye protokoller. Man skulle bare give sin DNS server et /64 prefix og bruge de sidste 64 bits i IP adressen som supplement til det 16 bits ID der ellers bruges i DNS.)
DEEF (5) skrev:Ved ikke helt, hvad jeg synes om at de store firmaer som Google blander sig i denne kamp, som for mig ligger i en "grå-zone". Hvad blev der af det frie internet?
Det er vel stadigvæk det frie internet så længe det Spamhaus tilbyder blot er en liste som alle andre på internettet frit kan vælge om de vil bruge.
Hvis Cyberbunker er hjemsted for spam så har jeg INTET problem med at de ryger i spamhaus's filterliste og jeg har ingen problemer med at andre bruger denne liste.
Jeg tror, det ville være endnu bedre, hvis man kunne få bind til at lade være med overhovedet at inkludere nogen records i svaret, såfremt det ville fylde mere end 512 bytes.kasperd (19) skrev:Har man grund til at acceptere DNS opslag fra hele nettet er den bedste beskyttelse på nuværende tidspunkt at lade være med at tillade svar op til 4096 bytes. Man kan tilføje følgende linje til sin bind konfiguration for at reducere den maksimale størrelse på svar:max-udp-size 512;
Med begrænsningen på 512 bytes sendes et svar med et flag, som indikerer at svaret ikke er komplet, men som dog indeholder så mange records, der er plads til på 512 bytes. En legitim klienten ville så prøve igen over TCP. Men i tilfælde af et DDoS angreb vil svaret sendt over UDP stadigvæk være større end forespørgslen.
Hvis nu bind sendte et svar som indikerer, at det ikke er komplet, og ingen records indeholder, så kunne svaret være en anelse mindre end forespørgslen (ved at udelade EDNS recorden). Men jeg tvivler på det er noget som bind er i stand til.
Det ville være glimrende, såfremt Spamhaus faktisk forsøgte at holde listen så præcis som det kan lade sig gøre. Men der cirkulerer historier om at Spamhaus bevidst inkluderer nogle legitime servere på deres liste. Hvis det er sandt må Spamhaus lister siges at være på grænsen til at være injurier.XxXxX (20) skrev:Hvis Cyberbunker er hjemsted for spam så har jeg INTET problem med at de ryger i spamhaus's filterliste og jeg har ingen problemer med at andre bruger denne liste.
Eller en måske endnu bedre løsning. Ved første forespørgsel fra en ukendt IP adresse sendes altid et tomt svar med et flag der fortæller at svaret ikke er komplet. Hvis klienten forbinder igen over TCP kan IP adressen tilføjes til en cache af kendte IP adresser, og fremtidige forespørgsler fra den IP adresse kan besvares over UDP med pakker på op til 4096 bytes.kasperd (21) skrev:Jeg tror, det ville være endnu bedre, hvis man kunne få bind til at lade være med overhovedet at inkludere nogen records i svaret, såfremt det ville fylde mere end 512 bytes.
Hvis svarene over UDP begynder at resultere i ICMP fejl skal adressen fjernes fra cachen igen.
kasperd (21) skrev:Men der cirkulerer historier om at Spamhaus bevidst inkluderer nogle legitime servere på deres liste. Hvis det er sandt må Spamhaus lister siges at være på grænsen til at være injurier.
Så længe det kun er rygter og der ikke er nogle håndfaste beviser så er det svært at tage seriøst.
Jeg har oplevet at en legitim mailserver kom på sådan en liste. Jeg kan ikke huske om det var Spamhaus. Og jeg har ikke haft brug for at vide om beskyldningerne imod Spamhaus har noget på sig, og jeg har derfor ikke brugt tid på at undersøge det. Det er jo ikke specielt nemt for en udenforstående at undersøge hvilken part der har ret, når beskyldningerne flyver frem og tilbage.XxXxX (23) skrev:Så længe det kun er rygter og der ikke er nogle håndfaste beviser så er det svært at tage seriøst.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund