mboost-dp1
Anonymous
Hmm - det er lidt som når indvandrerbander er i skuddueller med rockere....
Jeg ved godt, at det ikke løser nogle problemer, men jeg har stadig mest af alt lyst til at læne mig tilbage og nyde showet...
Jeg ved godt, at det ikke løser nogle problemer, men jeg har stadig mest af alt lyst til at læne mig tilbage og nyde showet...
Er det mon nu at nogen beslutter sig for at gøre endnu en stribe fra xkcd til virkelighed?
Er der nogen som ved hvor man finder en beskrivelse af det hul de påstår eksisterer?
Hvis det er korrekt at de udnytter en SQL injektion til at foretage et DoS angreb, så gør de egentlig de sites en tjeneste ved at gøre dem opmærksom på hullets eksistens uden at kopiere data fra deres database eller korrumpere databasen.
Apropos at udnytte en servers resurser imod den selv, så fandt jeg for nyligt ud af at man faktisk kan floode netværket på en server selvom man har mindre båndbredde end serveren.
Jeg skrev et lille program til at teste svagheden i TCP og testede det på mit eget lokalnet. Jeg kørte softwaren på en laptop med 11Mbit/s WIFI og lod den angribe en server som havde 1Gbit/s netværkskort. Det 1Gbit/s netværksinterface nåede op på 100% utilization.
En af de computere jeg prøvede at angribe lukkede faktisk ned for sit eget netkort da jeg kørte angrebet (sandsynligvis fordi jeg ramte en driver bug).
Er der nogen som ved hvor man finder en beskrivelse af det hul de påstår eksisterer?
Hvis det er korrekt at de udnytter en SQL injektion til at foretage et DoS angreb, så gør de egentlig de sites en tjeneste ved at gøre dem opmærksom på hullets eksistens uden at kopiere data fra deres database eller korrumpere databasen.
Apropos at udnytte en servers resurser imod den selv, så fandt jeg for nyligt ud af at man faktisk kan floode netværket på en server selvom man har mindre båndbredde end serveren.
Jeg skrev et lille program til at teste svagheden i TCP og testede det på mit eget lokalnet. Jeg kørte softwaren på en laptop med 11Mbit/s WIFI og lod den angribe en server som havde 1Gbit/s netværkskort. Det 1Gbit/s netværksinterface nåede op på 100% utilization.
En af de computere jeg prøvede at angribe lukkede faktisk ned for sit eget netkort da jeg kørte angrebet (sandsynligvis fordi jeg ramte en driver bug).
kasperd (8) skrev:Apropos at udnytte en servers resurser imod den selv, så fandt jeg for nyligt ud af at man faktisk kan floode netværket på en server selvom man har mindre båndbredde end serveren.
Jeg skrev et lille program til at teste svagheden i TCP og testede det på mit eget lokalnet. Jeg kørte softwaren på en laptop med 11Mbit/s WIFI og lod den angribe en server som havde 1Gbit/s netværkskort. Det 1Gbit/s netværksinterface nåede op på 100% utilization.
En af de computere jeg prøvede at angribe lukkede faktisk ned for sit eget netkort da jeg kørte angrebet (sandsynligvis fordi jeg ramte en driver bug).
Er det ikke netop ideen med DOS angreb... At man sender en pakkerequest der giver mere load/connections på serveren end på din client?
ala et SYN flood angreb
eller misforstår jeg dig?
Jeg er forvirret. Har deres angreb ikke ramt dem selv?
Jeg mener de angreb jo alle andre som ikke støttede wikileaks. Smider en masse tekst om deres angreb på Pastebin og anvender 4chan til deres kommunikation.
Men nu angriber de deres helte og egen kommunikationscentral, omvendt set fik de testet deres "venners" sikkerhed.
Jeg mener de angreb jo alle andre som ikke støttede wikileaks. Smider en masse tekst om deres angreb på Pastebin og anvender 4chan til deres kommunikation.
Men nu angriber de deres helte og egen kommunikationscentral, omvendt set fik de testet deres "venners" sikkerhed.
Den beskrivelse dækker en del DoS angreb, men ikke dem alle. Først og fremmest kan DoS angreb groft sagt deles op i dem der sender så meget trafik til serveren at man fylder dens indkommende netværksforbindelse op, og dem der ved at udnytte svagheder i serveren selv kan gøre den utilgængelig uden at sende den så store trafikmængder.TheGreenFoX (9) skrev:Er det ikke netop ideen med DOS angreb... At man sender en pakkerequest der giver mere load/connections på serveren end på din client?
De angreb der fungerer ved at sende så meget trafik til serveren at netværket ikke kan håndtere det hele kan sjældent udføres fra en enkelt maskine. Som regel anvendes maskiner der ikke har mulighed for at sende nok trafik til at overbelaste serverens netforbindelse. Derfor udføres denne type angreb for det meste som et distribueret angreb der sender trafik fra mange computere som til sammen overbelaster serverens netværk.
Nogle gange anvendes såkaldte amplification angreb hvor man sender nogle pakker der udgiver sig for at komme fra den server man vil angribe. Disse pakker sendes til forskellige destinationer rundt omkring på nettet som så sender deres svar til serveren. Hvis svaret er større end forespørgslen kræves der dermed mindre båndbredde for at overbelaste serveren.
Protokoller der kan misbruges til amplification anses af nogle personer som et sikkerhedshul. DNS kan anvendes til amplification. DNSSEC gør dette problem langt værre. Desværre vil løsningen kræve enten et ekstra roundtrip mellem klienten og serveren som gør DNS langsommere, eller at klienten padder sine requests med pseudotilfældige bytes for at gøre dem lige så store som svarene (hvilket med rette kan betragtes som meningsløs spild af båndbredde).
Et SYN flood angreb er en type angreb som udnytter en svaghed i TCP til at overbelaste en server uden at sende ret meget trafik.TheGreenFoX (9) skrev:ala et SYN flood angreb
For at oprette en TCP forbindelse sendes tre pakker mellem klient og server. Serveren er nødt til at huske nogle data så snart den har modtaget den første pakke. Hvis man klienten sender den første pakke uden nogensinde at sende den tredje pakke vil disse data opbevares på serveren i RAM i lang tid.
Der er en grænse for hvor mange af den type halvåbne forbindelser en server kan håndtere. Hvis dens tabel fyldes op kan den ikke mere håndtere flere forbindelser.
Fordi klienten aldrig sender den tredje pakke har den heller ikke brug for at se den anden pakke som sendes fra serveren til klienten. Dermed kan angrebet udføres af en klient som sender en forfalsket afsenderadresse, hvilket gør det sværere at afværge.
Men der er løsninger til SYN flooding. Der blev hurtigt opfundet en løsning med såkaldte SYN cookies. Det gik kort fortalt ud på at i stedet for at huske data kunne serveren indkode nogle af disse data i det sekvensnummer der sendes til klienten. Dermed kan forbindelsen færdiggøres når den tredje pakke når serveren uden den behøver huske noget i mellemtiden.
Man kan også nå langt med at afværge angrebet ved at lade serveren bruge en variabel mængde RAM på halvåbne forbindelser og kun gemme de absolut nødvendige data kan antallet af halvåbne forbindelser der kan håndteres øges betydeligt, men muligvis ikke nok til at overflødiggøre SYN cookies.
SYN cookies var en smart idé, men det har dog ulemper. Sekvensnummeret er kun 32 bits, og det skal også stadig bruges som sekvensnummer. Dermed kan kun ganske få data fra den oprindelige SYN pakke indkodes i sekvensnummeret. Det giver en mindre effektiv dataoverførsel for forbindelser der blev ǻbnet på basis af en SYN cookie. Grunden til at SYN cookies stadigvæk var en smart løsning var at det kun krævede ændringer på serversiden og stadig kunne virke med samme klientkode.
En udvidelse af TCP protokollen tillader en option som indeholder en ægte cookie. Det giver mere plads og man er fri for at udnytte sekvensnummeret. Samtidigt giver det mulighed for at serveren kan sætte en MAC på de data som kan verificeres når de kommer tilbage. Ulempen er at denne mulighed kun virker hvis både klient og server understøtter det.
Et SYN flooding angreb forsøger at overbelaste serverens RAM forbrug. Af andre resurser man kan forsøge at bruge op på serveren kan nævnes CPU, disk I/O og netværksbåndbredde.
Der er også angreb som blot forsøger at få serveren til at gå ned eller gå i en uendelig løkke. Denne type angreb prøver egentlig ikke at bruge nogen type resurse op, og det vil nogle gange kun kræve en enkelt eller ganske få pakker at gennemføre det.
Det angreb som jeg fandt og afprøvede udnytter en svaghed i TCP som intet har med SYN flooding at gøre. Jeg fandt ud af at jeg ved at sende en ganske lille mængde data til serveren kan få serveren til at sende så mange data tilbage at dens netværksforbindelse er helt fyldt op med data til en enkelt klient.
Normalt burde man ikke kunne få serveren til at sende med større båndbredde end man selv kan modtage. Men ved at udnytte denne svaghed kan man omgå den styring af båndbredden som foregår i TCP.
Jeg tror i øvrigt det vil kræve en udvidelse af TCP protokollen at rette op på det. Det bedste man kan gøre uden at ændre protokollen er nok at implementere en rate limit per forbindelse fra serversiden. Derudover kan man evt. fuske lidt med de pakker der sendes fra serveren for at opdage hvis nogen forsøger at udnytte svagheden. Et forsøg på at detektere det vil dog skade performance, så man bør kun gøre det for de klienter som når op på det rate limit man har sat.
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