mboost-dp1
unknown
så vidt jeg er informeret er det ikke engang nødvendigt at tage alle 13 ned for at lamme internettet. Det er en håndfuld servere der skal tages ned for at langt den største del af nettet ikke svarer.
Selv om det er svært at undgå så kunne der helt sikkert laves en bedre struktur der gjorde det mere drift sikkert under et sådant angreb (det er helt sikkert ikke det sidste)
De finder nok aldrig dem der stod bag det. DDoS sager har det med kun at blive løst hvis en eller anden taler over sig.
@2 kan godt være DDoS ikke er en nyhed, men et angreb på selve rygraden af internettet der gjorde at 2 ud af 13 servere ikke svarede de brugere der bruger den må siges at være en nyhed. Ikke noget der sker hver dag.
Selv om det er svært at undgå så kunne der helt sikkert laves en bedre struktur der gjorde det mere drift sikkert under et sådant angreb (det er helt sikkert ikke det sidste)
De finder nok aldrig dem der stod bag det. DDoS sager har det med kun at blive løst hvis en eller anden taler over sig.
@2 kan godt være DDoS ikke er en nyhed, men et angreb på selve rygraden af internettet der gjorde at 2 ud af 13 servere ikke svarede de brugere der bruger den må siges at være en nyhed. Ikke noget der sker hver dag.
firewall hjælper ikke på DDoS angreb. Du beder en røvfuld maskiner om at sender pakker til maskinen som den i forvejen modtager. En webserver ville fx modtage overdrevet mange http requests. I dette tilfælde ville root serveren modtage DNS requests.
Da dette er data den er lavet til at modtage vil den som et overvægtigt barn æde sig ihjel af det data der kommer ind.
Intelligente firewalls er stadig ikke så langt fremme i udviklingen de har en reel effekt på DDoS. Med tilstrækkeligt mange maskiner kan du endda DDoS'e en maskine der ikke modtager den type data du sender idet downstream vil være så satuated at ingen return packages vil komme igennem.
Da dette er data den er lavet til at modtage vil den som et overvægtigt barn æde sig ihjel af det data der kommer ind.
Intelligente firewalls er stadig ikke så langt fremme i udviklingen de har en reel effekt på DDoS. Med tilstrækkeligt mange maskiner kan du endda DDoS'e en maskine der ikke modtager den type data du sender idet downstream vil være så satuated at ingen return packages vil komme igennem.
Så forstår jeg sgu bedre at min mailserver har relayet alt mail til Lxxxx domæner gennem min internetudbyders SMTP server (som begrænser til 10 mb pr mail) istedet for direkte til Lxxxx mailserveren... den har ikke kunnet få fat i IP nummeret på Lxxxx serveren og benyttet "nødudgangen" istedet.
#9 Ehm. De returnerer IP for de DNS queries du laver.. Hvilket renderer domæner ikke funktionelle/langsomme, frem for direkte IP queries.
#5: Et forsigtigt bud kunne være millitante forekæmpere for indførelse af alt-root dns serverne Der er mange der har brokket sig over at fx det amerikanske forsvarsministerium har så meget at sige i forbindelse med dns (fx har man nægtet tibet sit eget tld - dette findes på en række af de alternative dns-root-servere)
#9: De er master-serverne for DNS. Hver gang du slår noget der hedder .com op bliver en af root-serverne i teorien forespurgt. Hvis du sætter et domæne op udelukkende på din egen private dns server (lad os sige den er hostet på ip 1.2.3.4), er der jo ingen der vil få fat i den, med mindre der er henvisninger til den højere oppe i hierakkiet. RIPE (som driver .net) vil man jo ikke kunne forespørge hvis ikke der er et index over hvad serverne hedder - Det er root-servernes opgave.
#9: De er master-serverne for DNS. Hver gang du slår noget der hedder .com op bliver en af root-serverne i teorien forespurgt. Hvis du sætter et domæne op udelukkende på din egen private dns server (lad os sige den er hostet på ip 1.2.3.4), er der jo ingen der vil få fat i den, med mindre der er henvisninger til den højere oppe i hierakkiet. RIPE (som driver .net) vil man jo ikke kunne forespørge hvis ikke der er et index over hvad serverne hedder - Det er root-servernes opgave.
#12
Hvis du har gennemført CCNA og er blevet certificeret uden at lære om DNS servere og de 13 root-servere, så synes jeg det er rimelig godt gået. :)
Jeg har selv CCNA, og der er et helt semester (eller det meste af et semester) der udelukkende omhandler DNS.
Det kan godt være de har lavet CCNA'en om, men lyder underligt hvis de har droppet alt læren om DNS.
Edit:
#13 Der var du lige lidt hurtigere. :)
Hvis du har gennemført CCNA og er blevet certificeret uden at lære om DNS servere og de 13 root-servere, så synes jeg det er rimelig godt gået. :)
Jeg har selv CCNA, og der er et helt semester (eller det meste af et semester) der udelukkende omhandler DNS.
Det kan godt være de har lavet CCNA'en om, men lyder underligt hvis de har droppet alt læren om DNS.
Edit:
#13 Der var du lige lidt hurtigere. :)
#16 root-nameservers ved hvilke servere der håndtere de enkelte tlds, står også længere oppe i en mere kringlet version :)
eftersom det skifter meget sjældent og mange root dns servere bruger anycast, har lidt ddos ikke den store effekt på netværk med en rimelig opsætning.
eftersom det skifter meget sjældent og mange root dns servere bruger anycast, har lidt ddos ikke den store effekt på netværk med en rimelig opsætning.
#17: Cisco Certified Network Associate.
http://www.cisco.com/web/learning/le3/le2/le0/le9/learning_certification_type_home.html
http://www.cisco.com/web/learning/le3/le2/le0/le9/learning_certification_type_home.html
#18 Mange og mange. Det er nu under halvdelen...
Det skal jo også lige tilføjes at de servere som blev taget ned jo ikke bruger anycast. Desuden da DNS blev angrebet i 2002 hvor 9/13 blev taget ned, hvor maximum DNS kan køre videre med er netop 9/13, kørte ingen rootservere med anycast. Så vil sige dette angreb er ikke særligt særlig godt. Tag en af de anycast serverne ned og jeg vil sige det er et stort angreb.
Det skal jo også lige tilføjes at de servere som blev taget ned jo ikke bruger anycast. Desuden da DNS blev angrebet i 2002 hvor 9/13 blev taget ned, hvor maximum DNS kan køre videre med er netop 9/13, kørte ingen rootservere med anycast. Så vil sige dette angreb er ikke særligt særlig godt. Tag en af de anycast serverne ned og jeg vil sige det er et stort angreb.
#3
Man kan hvad man vil, men fordele og ulemper bør vejes op mod hinanden!
Jo større driftssikkerhed, jo dyere bliver det! -Er man villig til at betale, eller ønsker man hellere at have drop-out en sjælden gang i mellem.
Balancen er der hvor man får mest for pengene!
Man kan hvad man vil, men fordele og ulemper bør vejes op mod hinanden!
Jo større driftssikkerhed, jo dyere bliver det! -Er man villig til at betale, eller ønsker man hellere at have drop-out en sjælden gang i mellem.
Balancen er der hvor man får mest for pengene!
#19 Nej det gør de heller ikke, men de henviser til de servere som ved mere om det.
ALM DNS.
Root server finder ud af hvilken server der styrer det tld du skal bruge
Næste server finder ud af hvilken server der styrer det domæne
Næste server finder ud af hvilken ip/cname domænet passer til.
Ved reverse dns er det stortset det samme
Root sender dig videre til en server der styrer en mindre del
Som igen sender dig videre til den server der har zonen, som retunere et hostname.
ALM DNS.
Root server finder ud af hvilken server der styrer det tld du skal bruge
Næste server finder ud af hvilken server der styrer det domæne
Næste server finder ud af hvilken ip/cname domænet passer til.
Ved reverse dns er det stortset det samme
Root sender dig videre til en server der styrer en mindre del
Som igen sender dig videre til den server der har zonen, som retunere et hostname.
Undrer mig lidt over at næsten alle root serverne står i USA!?
Ville det ikke være bedre at de var spredt udover hele verden?
Ville det ikke være bedre at de var spredt udover hele verden?
#24 de er jo ikke hemmelige så du spørger dem bare direkte, kræver ikke det store at lave et script der spørger efter rdns på en masse iper :)
Anycast serverne er sværre da man ikke selv har indflydelse på hvilken server man får, og derfor skal havde rigtig mange maskiner med i ddos for at være sikker på de alle er nede
Anycast serverne er sværre da man ikke selv har indflydelse på hvilken server man får, og derfor skal havde rigtig mange maskiner med i ddos for at være sikker på de alle er nede
Så vidt jeg husker fra mine mange timers CCNA læsning er Root-serverne det sidste punktum (det usynlige af dem) i et hostname...
Eksempelvis: http://www.newz.dk. <-- punktummet efter "dk" er rootserveren. Dernæst læses TLD, dernæst domain osv :P
Ret mig hvis jeg er stiv at høre/læse(?!) på!
Eksempelvis: http://www.newz.dk. <-- punktummet efter "dk" er rootserveren. Dernæst læses TLD, dernæst domain osv :P
Ret mig hvis jeg er stiv at høre/læse(?!) på!
#24
det gælder om at sende invalide pakker afsted som serveren ikke kan tolke, og derfor skal arbejde mere på end normalt, hvorefter den så sender et "jeg kan ikke forstå hvad du siger" svar tilbage.
hvis du så ganger det op med en million eller en milliard pakker i sekundet, så blokerer det lige pludselig for alle de mange andre legit pakker der også skal igennem, samtidig med at den æder alt cpu på at prøve at finde ud af hvad helvede den skal gøre, mens der er flere og flere pakker der bare stiller sig i kø... sådan ca.
#4
du finder sgu ikke en firewall der kan hjælpe mod ddos, der skal filtrering til på routerniveau.
det gælder om at sende invalide pakker afsted som serveren ikke kan tolke, og derfor skal arbejde mere på end normalt, hvorefter den så sender et "jeg kan ikke forstå hvad du siger" svar tilbage.
hvis du så ganger det op med en million eller en milliard pakker i sekundet, så blokerer det lige pludselig for alle de mange andre legit pakker der også skal igennem, samtidig med at den æder alt cpu på at prøve at finde ud af hvad helvede den skal gøre, mens der er flere og flere pakker der bare stiller sig i kø... sådan ca.
#4
du finder sgu ikke en firewall der kan hjælpe mod ddos, der skal filtrering til på routerniveau.
#1
Hvis der står mindst 3 ud af 13 computere, så er det artiklen der har misset målet. Der er langt mere end 13 computere, du kan være ret sikker på at de alle sammen er clustere.
Hvis der står mindst 3 ud af 13 computere, så er det artiklen der har misset målet. Der er langt mere end 13 computere, du kan være ret sikker på at de alle sammen er clustere.
Der er en del her der ikke er helt klar over hvad et dos angreb er for noget. Det gundlæggende princip er at man overbelaster en server eller en netforbindelse ved at sende en masse meningsløs trafik. Modsat hvad flere her inde siger, så er det ikke normal trafik der sendes, det er ikke effektivt.
Der er flere muligheder, f.eks. SYN-flood med spoofede ip-adresser. Hvis man skal tage en så stor forbindelse ned som root servere sidder på, er relay attacks nok mere sandsynlige. Her sendes en syn pakke til eller anden server f.eks. newz.dk, men med spoofed ip-adresse, så den svarer til den server man vil ligge ned. newz.dk sender så et syn/ack til mål-serveren. Denne fatter bjælle af en syn/ack da den ikke selv har forsøgt at oprette forbindelse til newz.dk, og dropper derfor pakken. Newz.dk får ikke noget svar på sit syn/ack og sender derfor et nyt 5 gange. Ved at sende en enkelt spoofed pakke til newz.dk kan vi altså ramme vores mål-server med 5 nonsense pakker. Så looper man over et par tusinder servere mere stor forbindelser og mange hits, og laver samme nummer, og har nogle hundrede zombie maskiner til at gøre det samme, og mål-serveren dør. Ikke af at forsøge at behandle for mange normale forespørgsler, men fordi en eller anden router tæt på den bliver nødt til at droppe en stor procentdel af alle pakkerne (her under lovlige pakker) fordi den er overbelasted.
anyway, læs Gibsons beskrivelse af drdos (distributed relay denial of service) her og den mere klassiske version af ddos her. Så kan i lige lære lidt om tcp hvis i ikke ved det i forvejen, og så er det sjov læsning, især det sidste link :)
Der er flere muligheder, f.eks. SYN-flood med spoofede ip-adresser. Hvis man skal tage en så stor forbindelse ned som root servere sidder på, er relay attacks nok mere sandsynlige. Her sendes en syn pakke til eller anden server f.eks. newz.dk, men med spoofed ip-adresse, så den svarer til den server man vil ligge ned. newz.dk sender så et syn/ack til mål-serveren. Denne fatter bjælle af en syn/ack da den ikke selv har forsøgt at oprette forbindelse til newz.dk, og dropper derfor pakken. Newz.dk får ikke noget svar på sit syn/ack og sender derfor et nyt 5 gange. Ved at sende en enkelt spoofed pakke til newz.dk kan vi altså ramme vores mål-server med 5 nonsense pakker. Så looper man over et par tusinder servere mere stor forbindelser og mange hits, og laver samme nummer, og har nogle hundrede zombie maskiner til at gøre det samme, og mål-serveren dør. Ikke af at forsøge at behandle for mange normale forespørgsler, men fordi en eller anden router tæt på den bliver nødt til at droppe en stor procentdel af alle pakkerne (her under lovlige pakker) fordi den er overbelasted.
anyway, læs Gibsons beskrivelse af drdos (distributed relay denial of service) her og den mere klassiske version af ddos her. Så kan i lige lære lidt om tcp hvis i ikke ved det i forvejen, og så er det sjov læsning, især det sidste link :)
nå ja lige en ting til. ddos og drdos kræver adgang til raw sockets, så man kan spoofe ip-adresser. Uden det virker angrebet ikke, og det tager 10 sec. og spore angriberen. Der er ET ENESTE operativsystem der ude der giver adgang til raw-sockets. I må selv gætte hvilket. Ok unix giver vist også adgang hvis man er root, men den diskussion kender vi jo :)
Hele problemet med drdos angreb kunne løses hvis der ikke var adgang til raw sockets i microsofts operativsystemer.
Hele problemet med drdos angreb kunne løses hvis der ikke var adgang til raw sockets i microsofts operativsystemer.
#33
DRDOS imod root serverne er relativt let at forhindre, og rigtigt mange firewalls hos ISP'er forhindrer den slags angreb på root serverne, så uden at have læst for meget om angrebene, tvivler jeg på det er den taktik der er brugt.
Det er næsten ligeså effektivt bare at køre et syn angreb direkte imod rootserveren, det vil relativt let fylde netværks stakken på serverne og gøre dem ude af stand til at svare på legitimt trafik.
Mht. DRDOS har du ret i næsten alle andre tilfælde, men lige root serverne, som jo aldrig etablerer udafgående forbindelser til andet end andre root servere, er det ikke et holdbart koncept.... Heldigvis da...
DRDOS imod root serverne er relativt let at forhindre, og rigtigt mange firewalls hos ISP'er forhindrer den slags angreb på root serverne, så uden at have læst for meget om angrebene, tvivler jeg på det er den taktik der er brugt.
Det er næsten ligeså effektivt bare at køre et syn angreb direkte imod rootserveren, det vil relativt let fylde netværks stakken på serverne og gøre dem ude af stand til at svare på legitimt trafik.
Mht. DRDOS har du ret i næsten alle andre tilfælde, men lige root serverne, som jo aldrig etablerer udafgående forbindelser til andet end andre root servere, er det ikke et holdbart koncept.... Heldigvis da...
#35 joohh men de computere der fortager angrebne er typisk zombie maskiner. Ellers skal man vist være modig, da man nok kan se frem til problemer hvis man laver et syn/ack flood angreb fra sin egen maskine.
Forresten var der slet ikke raw sockets i windows før NT udgaverne, hvilket set med sikkerhedsøjne faktisk var bedre end det der er nu, hvor alle og en hver har adgang til at pille med osi stakken på en windows maskine.
#36 Ja du kan indbygge et firewall filter der forbyder adgang til root serverne, men det kræver at alle isp'er indbygger dette, ellers kan man jo bare bruge en eller anden isp med dårlig sikkerhed. Relay angreb er mere effektive end alm. syn angreb, da du får fordelen af 5 retries, samt at det er svært at blokere trafik på routere længere ude på nettet, da det kommer fra alle mulige forskellige servere.
Der er ikke tale om udadgående forbindelser, men indadgående. En syn pakke begyder "jeg vil gerne forbinde til dig". Derfor svarer relay maskinen tilbage med et syn/ack: "ok, det må du gerne". Det er altså en helt almindelig indadgående forbindelse, som resulterer i at relay maskinen sender nonsense til root serveren. Det er simpelthen antallet af nonsense syn/ack pakker der tager forbindelsen ned.
Jeg ved ikke om det er et relay angreb der er brugt, men det forekommer sandsynligt, da det er det sværeste at stoppe og det der generer mest trafik, hvilket er nødvendigt for at tage så store servere ned. Ok hvis man har zombie maskiner nok kan man naturligvis altid klare sig med alm. syn flood angreb hvor man fylder bufferen over halvåbne forbindelser op, men der findes flere gode løsninger på denne type, og derfor skal mængden af trafik alligevel være enorm før en root server dør.
Forresten var der slet ikke raw sockets i windows før NT udgaverne, hvilket set med sikkerhedsøjne faktisk var bedre end det der er nu, hvor alle og en hver har adgang til at pille med osi stakken på en windows maskine.
#36 Ja du kan indbygge et firewall filter der forbyder adgang til root serverne, men det kræver at alle isp'er indbygger dette, ellers kan man jo bare bruge en eller anden isp med dårlig sikkerhed. Relay angreb er mere effektive end alm. syn angreb, da du får fordelen af 5 retries, samt at det er svært at blokere trafik på routere længere ude på nettet, da det kommer fra alle mulige forskellige servere.
Mht. DRDOS har du ret i næsten alle andre tilfælde, men lige root serverne, som jo aldrig etablerer udafgående forbindelser til andet end andre root servere, er det ikke et holdbart koncept.... Heldigvis da..
Der er ikke tale om udadgående forbindelser, men indadgående. En syn pakke begyder "jeg vil gerne forbinde til dig". Derfor svarer relay maskinen tilbage med et syn/ack: "ok, det må du gerne". Det er altså en helt almindelig indadgående forbindelse, som resulterer i at relay maskinen sender nonsense til root serveren. Det er simpelthen antallet af nonsense syn/ack pakker der tager forbindelsen ned.
Jeg ved ikke om det er et relay angreb der er brugt, men det forekommer sandsynligt, da det er det sværeste at stoppe og det der generer mest trafik, hvilket er nødvendigt for at tage så store servere ned. Ok hvis man har zombie maskiner nok kan man naturligvis altid klare sig med alm. syn flood angreb hvor man fylder bufferen over halvåbne forbindelser op, men der findes flere gode løsninger på denne type, og derfor skal mængden af trafik alligevel være enorm før en root server dør.
"Forresten var der slet ikke raw sockets i windows før NT udgaverne, hvilket set med sikkerhedsøjne faktisk var bedre end det der er nu, hvor alle og en hver har adgang til at pille med osi stakken på en windows maskine."
Nej, det var meget interressant, microsoft fik først raw sockets da de lånte freebsd's netværksstack. Før det var der ingen der skulle bruge det, derefter kunne alle uanset privilegier, ligeså godt få det, for hvad kunne der dog gå galt. Suk...
"Ja du kan indbygge et firewall filter der forbyder adgang til root serverne, men det kræver at alle isp'er indbygger dette, ellers kan man jo bare bruge en eller anden isp med dårlig sikkerhed. Relay angreb er mere effektive end alm. syn angreb, da du får fordelen af 5 retries, samt at det er svært at blokere trafik på routere længere ude på nettet, da det kommer fra alle mulige forskellige servere."
Nah, det vil normalt ikke være noget problem, du behøver reelt kun blokere ved de store pipes, f.eks. forbindelserne imellem kontinenter og hvad der end grænser op til det netværk hvor root serverne er placeret.
"Der er ikke tale om udadgående forbindelser, men indadgående. En syn pakke begyder "jeg vil gerne forbinde til dig". Derfor svarer relay maskinen tilbage med et syn/ack: "ok, det må du gerne". Det er altså en helt almindelig indadgående forbindelse, som resulterer i at relay maskinen sender nonsense til root serveren. Det er simpelthen antallet af nonsense syn/ack pakker der tager forbindelsen ned."
Nej, i et DRDOS angreb bliver der aldrig sendt SYN pakker til root serveren, der bliver sendt SYN/ACK, som jo betyder at der bliver svaret på en forspørgsel(eller rettere, det er andel del af et handshake). At det er forfalsket betyder sådanset intet, du blokerer bare alle SYN/ACK pakker til root serveren fra offentlige netværk.
Og jeg synes egentligt jeg udtrykkede mig rigtigt, root serveren bør aldrig udsende SYN pakker til andre offentlige maskiner, og derved er der aldrig behov for at sende SYN/ACK til den.
Iøvrigt, efter at have læst lidt videre, lyder det som om det simpelthen var mangel på båndbredde der tvang serverne ned.
Nej, det var meget interressant, microsoft fik først raw sockets da de lånte freebsd's netværksstack. Før det var der ingen der skulle bruge det, derefter kunne alle uanset privilegier, ligeså godt få det, for hvad kunne der dog gå galt. Suk...
"Ja du kan indbygge et firewall filter der forbyder adgang til root serverne, men det kræver at alle isp'er indbygger dette, ellers kan man jo bare bruge en eller anden isp med dårlig sikkerhed. Relay angreb er mere effektive end alm. syn angreb, da du får fordelen af 5 retries, samt at det er svært at blokere trafik på routere længere ude på nettet, da det kommer fra alle mulige forskellige servere."
Nah, det vil normalt ikke være noget problem, du behøver reelt kun blokere ved de store pipes, f.eks. forbindelserne imellem kontinenter og hvad der end grænser op til det netværk hvor root serverne er placeret.
"Der er ikke tale om udadgående forbindelser, men indadgående. En syn pakke begyder "jeg vil gerne forbinde til dig". Derfor svarer relay maskinen tilbage med et syn/ack: "ok, det må du gerne". Det er altså en helt almindelig indadgående forbindelse, som resulterer i at relay maskinen sender nonsense til root serveren. Det er simpelthen antallet af nonsense syn/ack pakker der tager forbindelsen ned."
Nej, i et DRDOS angreb bliver der aldrig sendt SYN pakker til root serveren, der bliver sendt SYN/ACK, som jo betyder at der bliver svaret på en forspørgsel(eller rettere, det er andel del af et handshake). At det er forfalsket betyder sådanset intet, du blokerer bare alle SYN/ACK pakker til root serveren fra offentlige netværk.
Og jeg synes egentligt jeg udtrykkede mig rigtigt, root serveren bør aldrig udsende SYN pakker til andre offentlige maskiner, og derved er der aldrig behov for at sende SYN/ACK til den.
Iøvrigt, efter at have læst lidt videre, lyder det som om det simpelthen var mangel på båndbredde der tvang serverne ned.
Ret mig hvis jeg tager fejl, men DNS er typisk UDP trafik, og syn/ack hører til TCP pakker.
Angrebet udføres blot som en host sender DNS queries, udført over UDP(mulighed for at forge afsender).
Angrebet kunne uden problemer være sket fra unix/windows/linux/bsd, u named it, så gem venligst denne diskussion til en anden debat.
Angrebet udføres blot som en host sender DNS queries, udført over UDP(mulighed for at forge afsender).
Angrebet kunne uden problemer være sket fra unix/windows/linux/bsd, u named it, så gem venligst denne diskussion til en anden debat.
Var der overhovedet nogen, som mærkede noget til dette angreb? (Udover selvfølgelig administratorerne af de ramte root DNS servere). At der er så mange root DNS servere er jo netop for at systemet kan fungere når flere er nede samtidigt. Og skal der mere end en enkelt root DNS server til for at besvare alle de relevante queries? (Der skal måske lidt mere til for at svare på alle de ikke eksisterende top level domæner, som der hele tiden bliver spurgt efter).
Og er anycast adresserne som mange af root DNS serverne kører på nu ikke nok til at forebygge et effektivt angreb?
Og er det egentligt sandt, når de siger, at der ikke kan være mere end 13 root DNS servere? Jo selvfølgelig er man begrænset af de 512 bytes som DNS vil putte i en UDP pakke. Men lad os nu sige, at man øger antallet af root DNS servere til f.eks. det dobbelte, så ville det trods alt ikke kræve ret meget arbejde at udvikle en DNS server, der svarer med en tilfældig delmængde på 13 af de mulige servere, når den får en UDP forespørgsel. Og har man brug for den fulde liste med alle 26, så kan man jo stadig spørge med TCP.
Den udvidelse ville kræve en lille ændring af DNS softwaren på root DNS serverne, men alle andre DNS servere og klienter kunne køre videre med samme DNS software, som de altid har gjort. En DNS server vil når den starter op indlæse sin hints fil med alle 26 adresser, og så kontakte en af dem for at få en opdateret liste, som så dog kun indeholder 13 tilfældigt valgte root DNS servere.
Hvis det faktisk lykkes for nogen at lægge 13 root DNS servere ned vil der så stadigvæk være 13 tilbage, og kun en ud af hver 10.400.600 DNS servere vil tilfældigvis have fået lige netop listen med de 13, som endte med at blive lagt ned. Og skulle man prøve at genstarte DNS serveren vil det faktisk hjælpe.
[url=#22]#22[/url] Man in Black
[url=#25]#25[/url] mcm
[url=#29]#29[/url] luuuuu
Hvis serverne svarede på forespørgsler, de ikke forstår, så ville de være meget nemmere at bringe ned. Faktisk ville ganske få pakker med spoofet afsender adresse være nok. Send en korrupt pakke til a.root-servers.net, men angiv b.root-servers.net som afsender. Så sender a en svar pakke til b. Men b der ikke forventer noget svar kigger undrende på pakken og sender så et svar til a. Sådan bliver det ved indtil pakken går tabt. Bliv ved med at sende spoofede pakker i et par minutter med alle 169 kombinationer af afsender og modtager, og du kan være ganske sikker på, at de fleste bliver lagt ned.
Moralen er, at hvis man designer protokoller, der kører over UDP, så skal man passe ekstremt meget på at man ikke sender for mange pakker. Jeg har set det gå galt mere end en gang. En af gangene var det min egen skyld, men heldigvis var det kun min egen kabelforbindelse, jeg udsatte for et DoS angreb.
Jeg tror dem der designede DNS har taget højde for den slags problemer, og DNS serverne svarer kun på forespørgsler, de forstår. Der kan selvfølgelig sagtens være forespørgsler, som DNS serverne forstår, men hvor svaret er, at det efterspurgte navn ikke findes. I sådan en situation skal der selvfølgelig svares, for ellers vil klienten jo spørge igen og igen indtil den timer ud.
Under normale omstændigheder er de fleste forespørgsler til root DNS serverne (så vidt jeg ved) faktisk efter ikke eksisterende navne. Der er ikke mere end nogle få hundrede gyldige top level domains at spørge efter, og de opslag kan caches i lang tid.
[url=#33]#33[/url] iluka
Der er til gengæld andre måder hvorpå man i nogle tilfælde med en enkelt pakke kan generere mange svar. F.eks. ved at sende en pakke med spoofet afsender til broadcast adressen for et netsegment eller en multicast adresse. Men de fleste systmer burde efterhånden undgå den situation, f.eks. ved at unlade at svare hvis afsenderadressen ikke er en af modtagerne.
[url=#36]#36[/url] SmackedFly
[url=#41]#41[/url] mikbund
Nu er der selvfølgelig lige den detalje, at mange af root DNS serverne kører på anycast adresser. TCP på en anycast adresse er lidt upålideligt. Så muligvis besvarer de pågældende root DNS servere kun UDP forespørgsler, og de har nok en anden IP adresse til TCP trafik.
Og er anycast adresserne som mange af root DNS serverne kører på nu ikke nok til at forebygge et effektivt angreb?
Og er det egentligt sandt, når de siger, at der ikke kan være mere end 13 root DNS servere? Jo selvfølgelig er man begrænset af de 512 bytes som DNS vil putte i en UDP pakke. Men lad os nu sige, at man øger antallet af root DNS servere til f.eks. det dobbelte, så ville det trods alt ikke kræve ret meget arbejde at udvikle en DNS server, der svarer med en tilfældig delmængde på 13 af de mulige servere, når den får en UDP forespørgsel. Og har man brug for den fulde liste med alle 26, så kan man jo stadig spørge med TCP.
Den udvidelse ville kræve en lille ændring af DNS softwaren på root DNS serverne, men alle andre DNS servere og klienter kunne køre videre med samme DNS software, som de altid har gjort. En DNS server vil når den starter op indlæse sin hints fil med alle 26 adresser, og så kontakte en af dem for at få en opdateret liste, som så dog kun indeholder 13 tilfældigt valgte root DNS servere.
Hvis det faktisk lykkes for nogen at lægge 13 root DNS servere ned vil der så stadigvæk være 13 tilbage, og kun en ud af hver 10.400.600 DNS servere vil tilfældigvis have fået lige netop listen med de 13, som endte med at blive lagt ned. Og skulle man prøve at genstarte DNS serveren vil det faktisk hjælpe.
[url=#22]#22[/url] Man in Black
Er man villig til at betale, eller ønsker man hellere at have drop-out en sjælden gang i mellem.Mit umiddelbare svar er, ja man er villig til at betale. Der er mange virksomheder, der investerer store summer på at lave computersystemer med 100% tilgængelighed eller tæt derpå. Nogle af disse systemer skal kunne tilgås via Internettet. Hvad er alle disse investeringer værd, hvis systemet alligevel ikke kan tilgås når nogen finder på at gå til angreb på nogle uskyldige root DNS servere?
[url=#25]#25[/url] mcm
Undrer mig lidt over at næsten alle root serverne står i USA!?Gør de nu også det? Jeg læste et eller andet sted, at det er kun hvis man tæller navnene, at de fleste står i USA. Hvis man tager højde for, at mange af dem er anycast adresser og så tæller dem alle sammen med, så er der flest udenfor USA.
Ville det ikke være bedre at de var spredt udover hele verden?Bedre for USA eller bedre for Internettet?
[url=#29]#29[/url] luuuuu
det gælder om at sende invalide pakker afsted som serveren ikke kan tolke, og derfor skal arbejde mere på end normalt, hvorefter den så sender et "jeg kan ikke forstå hvad du siger" svar tilbage.Der tror jeg du tager helt fejl. Hvis serveren virkeligt ikke forstår hvad der bliver spurgt om vil det være bedre slet ikke at svare.
Hvis serverne svarede på forespørgsler, de ikke forstår, så ville de være meget nemmere at bringe ned. Faktisk ville ganske få pakker med spoofet afsender adresse være nok. Send en korrupt pakke til a.root-servers.net, men angiv b.root-servers.net som afsender. Så sender a en svar pakke til b. Men b der ikke forventer noget svar kigger undrende på pakken og sender så et svar til a. Sådan bliver det ved indtil pakken går tabt. Bliv ved med at sende spoofede pakker i et par minutter med alle 169 kombinationer af afsender og modtager, og du kan være ganske sikker på, at de fleste bliver lagt ned.
Moralen er, at hvis man designer protokoller, der kører over UDP, så skal man passe ekstremt meget på at man ikke sender for mange pakker. Jeg har set det gå galt mere end en gang. En af gangene var det min egen skyld, men heldigvis var det kun min egen kabelforbindelse, jeg udsatte for et DoS angreb.
Jeg tror dem der designede DNS har taget højde for den slags problemer, og DNS serverne svarer kun på forespørgsler, de forstår. Der kan selvfølgelig sagtens være forespørgsler, som DNS serverne forstår, men hvor svaret er, at det efterspurgte navn ikke findes. I sådan en situation skal der selvfølgelig svares, for ellers vil klienten jo spørge igen og igen indtil den timer ud.
Under normale omstændigheder er de fleste forespørgsler til root DNS serverne (så vidt jeg ved) faktisk efter ikke eksisterende navne. Der er ikke mere end nogle få hundrede gyldige top level domains at spørge efter, og de opslag kan caches i lang tid.
[url=#33]#33[/url] iluka
Newz.dk får ikke noget svar på sit syn/ack og sender derfor et nyt 5 gange.Den sender altså kun to, men det synes jeg så også er en for meget. Er der nogen god grund til at sende mere end en enkelt SYN/ACK pakke før klienten retransmiterer SYN pakken?
Der er til gengæld andre måder hvorpå man i nogle tilfælde med en enkelt pakke kan generere mange svar. F.eks. ved at sende en pakke med spoofet afsender til broadcast adressen for et netsegment eller en multicast adresse. Men de fleste systmer burde efterhånden undgå den situation, f.eks. ved at unlade at svare hvis afsenderadressen ikke er en af modtagerne.
[url=#36]#36[/url] SmackedFly
DRDOSHvad har Digital Research Disk Operating System gjort så det nu skal have den slags beskyldninger hængende på sig?
[url=#41]#41[/url] mikbund
Ret mig hvis jeg tager fejl, men DNS er typisk UDP trafik, og syn/ack hører til TCP pakker.Korrekt. Men hvis båndbredden bliver brugt op er det ligegyldigt, om der er tale om UDP eller TCP. Faktisk kører DNS i nogle tilfælde over TCP. Hvis forespørgslen eller svaret er større end 512 bytes anvendes der TCP. (Grænsen for UDP pakker er større end det, men DNS bruger ikke UDP pakker over 512 bytes).
Nu er der selvfølgelig lige den detalje, at mange af root DNS serverne kører på anycast adresser. TCP på en anycast adresse er lidt upålideligt. Så muligvis besvarer de pågældende root DNS servere kun UDP forespørgsler, og de har nok en anden IP adresse til TCP trafik.
#43
Valgt et navn med samme forkortelse som Distributed Relay Denial of Service?! :) Sådan nogle nisser...
Valgt et navn med samme forkortelse som Distributed Relay Denial of Service?! :) Sådan nogle nisser...
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