mboost-dp1
SXC - Exian
Heuse langer samtidigt ud efter Microsoft, fordi Exchange ikke længere kan bruges på en server, hvor IPv6 er slået fra.
Har det været muligt? Jeg synes altud der har været problemet hvis man har disabled IPv6 ... dvs boot tider på 30-60 mins af en eller anden grund. Men hvis det kun er localhost og "jeg kan ikke finde en address" ... hvad er så lige problemet?
IPv6 forbedrer sikkerheden på nogle områder, men introducerer også nye trusler på andre områder.Vossen (4) skrev:kasperd, vi hidkalder dig! Er det sandt?
IP over Ethernet
Med IPv4 over Ethernet bruges ARP protokollen til at udveksle oplysninger om MAC adresser. Har man brug for dynamisk konfiguration er BOOTP/DHCP den eneste udbredte mulighed.
Med IPv6 over Ethernet bruges der ikke ARP, i stedet bruges en ny neighbour discovery protocol, som kører over ICMPv6. Og til dynamisk konfiguration bruges router advertisements, evt. kombineret med DHCPv6.
I begge tilfælde er der mulighed for spoofing. Det er nøjagtigt de samme spoofing angreb man kan udføre i begge tilfælde. Highend switches kan lave filtre, således at switchen ved hvilke porte der må være routere og DHCP servere på. Og spoofing forhindres ved at switchen dropper spoofede pakker. Der er switches som kun har denne type foranstaltninger til IPv4 og ikke til IPv6. Men nogle nyere switches har også disse foranstaltninger til IPv6.
Selvom neighbour discovery ligner ARP meget, så ligger der nogle nye muligheder i at køre på et højere protokollag. Da det kører ovenpå IPv6 kan det også udnytte features i IPv6 som f.eks. pakke fragmentering. Legitime neighbour discovery pakker er dog så små, at der ikke er brug for fragmentering. Men det kan udnyttes til angreb, da en switch ikke kan se på en fragmenteret pakke om det er neighbour discovery.
Den bedste beskyttelse imod den type angreb er filtre i switchene som forhindrer spoofing vha. ufragmenterede pakker og filtre i computernes oprativsystem som forhindrer neighbour discovery med fragmenterede pakker.
En anden trussel er at da pakkerne kører over IPv6 kan de routes, og dermed spoofes udefra. Så vidt jeg husker er der allerede taget højde for det i protokolspecifikationen, og korrekte implementationer vil ikke være sårbare. Løsningen er at altid sende pakkerne med hop limit sat til maksimumsværdien på 255. Hvis pakken modtages med hop limit på 255 kan den ikke have været gennem nogen router og man ved derfor at den er fra det lokale netsegment.
Alt dette er relevant, hvis man ikke kan stole på sit eget lokalnet. Truslerne er der både med IPv4 og IPv6.
Hvis man vil undgå de nye trusler er det ikke nok at bare ignorere IPv6. Et netværk hvor der kun er IPv4 routere, men alle computerne har support for IPv6 er faktisk det mest sårbare overfor denne type angreb. Man ville altså skulle slå IPv6 fra på hver enkelt computer for at beskytte sig ad den vej. Og sådan har det været i flere år. I stedet for at bruge tid på at slå IPv6 fra er det nok bedre at overveje, hvordan man sikrer sig fremadrettet.
Adressering
Der er så mange IPv6 adresser at scanning af netværk ikke længere er en realistisk måde at finde IP adresser på. Klassiske orme, der udbredte sig ved at angribe tilfældige adresser vil forsvinde.
Men der er mange andre måder at finde IPv6 adresser på, så man skal ikke tro, at man er immun overfor angreb, bare fordi ens IPv6 adresse ikke kan findes.
Da man ikke bruger NAT til kommunikation mellem IPv6 hosts er det muligt at oprette forbindelser direkte mellem vilkårlige hosts. Dette kan ses som en sikkerhedstrussel. Den korrekte løsning på denne trussel er en firewall. En simpel firewall som filtrerer forsøg på at åbne pakker udefra kan fungere med langt mindre tilstand end en IPv4 baseret NAT. Sikkerhedsmæssigt tror jeg IPv6 er en fordel på det punkt, fordi en simplere løsning også har mindre risiko for fejl.
Nogen bekymrer sig om at man udfra IPv6 adressen kan genkende computere, og dermed kan se om forbindelser kommer fra samme computer eller forskellige computere på samme netværk.
IPv6 har en løsning på det. Man kan have flere IPv6 adresser på hver computer. Man kan have en fast adresse, som man bruger, hvis man f.eks. vil køre en server på computeren, som man skal kunne finde igen. Derudover kan man have midlertidige adresser, som bruges til forbindelser man selv åbner. Disse kan f.eks. udskiftes en gang i døgnet.
Bruger man disse midlertidige IPv6 adresser og har en passende IPv6 firewall, så vil jeg mene at IPv6 på det punkt er væsentligt bedre end IPv4.
Fragmentering
Fragmentering af pakker er noget man så vidt muligt bør undgå. Med IPv4 var der altid fragmenteringsoplysninger i headeren. Med IPv6 udelades disse oplysninger, når de ikke er nødvendige (hvilket vil sige, at de næsten aldrig er til stede). Det betyder at angreb som udnytter forudsigelige identifikation af pakker ikke længere vil kunne lade sig gøre med IPv6 (se f.eks. nmap idle scan).
Hvis der endeligt er brug for fragmentering og inkluderes en fragmenteringsheader og identifikationen er udvidet fra 16 til 32 bits, hvilket reducerer risikoen for kollisioner og gør at de kan være mindre forudsigelige.
Muligheden for sikkerhedsfejl som "ping of death" (der burde have heddet "fragmentation of death", fordi den intet har med ping at gøre) er nøjagtigt den samme i IPv4 og IPv6.
Implementationsfejl
Den største trussel stammer nok fra fejl i implementationer og altså ikke fra protokollen selv. Da IPv4 er ca. 20 år ældre end IPv6 har man haft længere tid til at finde og udrydde fejl i IPv4. På den anden side er mange af de mulige fejl de samme og var kendt da man begyndte at implementere IPv6. F.eks. burde alle der implementerer IPv6 være klar over truslen om overflow ved samling af fragmenterede pakker og ikke lave et bufferoverrun bare fordi sidste fragment er større end det må være.
Konklusion
Selvom Heuse har ret i mange af de punkter han fremsætter er jeg meget uenig i hans konklusion. For at overgangen kan ske så sikkert som muligt skal man have god tid, sådan at man ikke introducerer sikkerhedsproblemer pga. fejl begået under tidspres.
Der er virksomheder som har bevist at man sagtens kan lægge det interne netværk om til IPv6 samtidigt med at man fokuserer på at forbedre sikkerheden af det interne netværk.
Men hvis der er virksomheder som vil følge Heuses råd og holde deres interne netværk på ren IPv4, så har jeg faktisk brugt det sidste års tid på at udvikle en løsning som kan give dem mulighed for at kommunikere med IPv6 backbone uden at opgradere lokalnettet.
Tyrial (2) skrev:Sikkerhedseksperter er altid på bagben... det er deres job.
Der er ingen major sikkerheds risiko ved IPv6 sammenlignet med IPv4 hvis man ved hvad man laver... Det er bare min mening.
Og der er vel ikke ret mange som egentlig ved hvad de laver med IPv6?
Det var der jo heller ikke i starten med IPv4.
mireigi (11) skrev:Tyrial (2) skrev:Sikkerhedseksperter er altid på bagben... det er deres job.
Der er ingen major sikkerheds risiko ved IPv6 sammenlignet med IPv4 hvis man ved hvad man laver... Det er bare min mening.
Og der er vel ikke ret mange som egentlig ved hvad de laver med IPv6?
Det var der jo heller ikke i starten med IPv4.
I så tilfælde bør man ikke pille ved netværket. :P
Jo. Mange af tingene er faktisk blevet sagt før, blot ikke som en så kraftig advarsel imod IPv6.el_barto (6) skrev:Er det så ikke en aaanelse sent at melde sådan noget her ud?
Advarslerne er da også blevet hørt. Jeg kan dog ikke helt gennemskue om disse advarsler er en del af grunden til at så mange har holdt igen med IPv6, eller om de blot er blevet brugt som undskyldning af personer, som alligevel ville have fundet en grund til at holde igen.
At så mange har holdt igen betyder bare, at vi nu har kortere tid til at løse problemerne. På den måde har det faktisk øget sikkerhedstrusselen at så mange har holdt igen.
Hvilket på sin vis er lidt underligt, for så meget anderledes er IPv6 da ikke i forhold til IPv4.mireigi (11) skrev:Og der er vel ikke ret mange som egentlig ved hvad de laver med IPv6?
#0
der er "altid" sikkerhedsfejl, lige meget ved hvilken teknologi vi indfører, dog kan man eliminerer en del af de risici ved at opsætte sit miljø "korrekt".
Med de seneste cirka 5 års konstante "vi skal ha ipv6 nu!" kampagner og ramaskrig, er han håbløst sent ude, og prøver at få sine 15-minutes of fame. Skriv en bog til sys-/netadmins istedet..
Dog ikke meget ældre.
Exchange udkom i 1993 (kilde)
IPv6 arbejdet begyndte i 1994 (kilde)
:)
der er "altid" sikkerhedsfejl, lige meget ved hvilken teknologi vi indfører, dog kan man eliminerer en del af de risici ved at opsætte sit miljø "korrekt".
Med de seneste cirka 5 års konstante "vi skal ha ipv6 nu!" kampagner og ramaskrig, er han håbløst sent ude, og prøver at få sine 15-minutes of fame. Skriv en bog til sys-/netadmins istedet..
kasperd (10) skrev:Exchange er ældre end IPv6, så det må have været muligt engang.
Dog ikke meget ældre.
Exchange udkom i 1993 (kilde)
IPv6 arbejdet begyndte i 1994 (kilde)
:)
Man kan tage et kig på http://www.potaroo.net/tools/ipv4/plotend.png og spørge sig selv om der stadigvæk er nogen som tror, at den tyrkis farvede kurve, som angiver RIPEs beholdning, ikke vil ramme den røde linie, som er grænsen for hvornår der iværksættes rationering.Kenman (14) skrev:Med de seneste cirka 5 års konstante "vi skal ha ipv6 nu!" kampagner og ramaskrig
I årevis har der været nogenlunde præcise forudsigelser for, hvordan udviklingen ville gå. Men vi kan stadigvæk ikke sætte en præcis dato på. Dog ser det meget sandsynligt ud, at Europæiske virksomheder skal indrette sig på, at der rationeres fra et tidspunkt i oktober.
Hvis man kigger på kurven for APNIC ses det tydligt at omkring starten af 2011 fik virksomhederne i Asien øjnene op for at det var alvor. Forbruget af de resterende IPv4 adresser accelererede op til omtrent den dobbelte hastighed. Men selv hvis det ikke var sket ville de sandsynligvis være løbet tør inden udgangen af 2011.
Der har nok været en forventning om en lignende tendens i Europa: http://www.version2.dk/artikel/ripe-vi-loeber-toer...
Men som man kan se på grafen er den udeblevet. Eller også har RIPE bare været mere skrappe i deres krav til ansøgninger om adresser end APNIC var.
Men det var først i 1998 at der kom support for det i Windows. Og det blev først anset som klar til produktionsbrug i 2000: http://research.microsoft.com/en-us/projects/msrip...Kenman (14) skrev:IPv6 arbejdet begyndte i 1994
Jeg formoder at man også har kunnet bruge Exchange på Windows i perioden fra 1993 til 2000, og det må i så fald være sket uden IPv6.
Tyrial (2) skrev:Sikkerhedseksperter er altid på bagben... det er deres job.
Der er ingen major sikkerheds risiko ved IPv6 sammenlignet med IPv4 hvis man ved hvad man laver... Det er bare min mening.
Bare fordi der ikke er nogen Major der har udtalt sig om sikkerheds problemer betyder det jo ikke af der ikke findes et
Kan i øvrige slet ikke se hvorfor en Major skulle udtale sig om IT-Sikkerhed
Justin (16) skrev:
Bare fordi der ikke er nogen Major der har udtalt sig om sikkerheds problemer betyder det jo ikke af der ikke findes et
Kan i øvrige slet ikke se hvorfor en Major skulle udtale sig om IT-Sikkerhed
langt største delen af de ansatte hos NSA er personale fra USAF. Altså vil det ikke være helt utænkeligt at der vil være en eller flere der kunne tænkes at have en vis forstand på IT-sikkerhed :)
#18-19
NSA er en del af det amerikanske forsvar (hører under forsvaret), så det er jo ikke overraskende at det er befolket med miltær folk.
NSA er ansvarlig for aflytning af kommunikation. Så IT sikkerhed er åbenlyst en del af deres kerne kompetance.
Hvorfor lige netop USAF skulle levere flere folk end USN, USA og USMC har jeg ikke noget bud på.
NSA er en del af det amerikanske forsvar (hører under forsvaret), så det er jo ikke overraskende at det er befolket med miltær folk.
NSA er ansvarlig for aflytning af kommunikation. Så IT sikkerhed er åbenlyst en del af deres kerne kompetance.
Hvorfor lige netop USAF skulle levere flere folk end USN, USA og USMC har jeg ikke noget bud på.
Jo, men nogle ting strækker sig dog helt ned til IP laget. Men på de punkter er det nok oftere konfigurationsfejl der åbner huller end det er fejl i koden.arne_v (20) skrev:Det meste sikkerhed finder sted langt over IP niveauet.
F.eks. anses det som god praksis at man ikke tillader direkte adgang fra Internettet til sin databaseserver. Men netværksopsætningen til at forhindre det er forskellig i IPv4 og IPv6.
Fejl i IP koden kan forekomme, og når de bliver opdaget bør producenten udsende en sikkerhedsopdatering. Procedurerne for at installere sikkerhedsopdateringer er til gengæld de samme uanset om de retter fejl i IPv4 koden, IPv6 koden eller noget helt tredje. (Nogen gange fortæller producenten ikke engang, hvilke dele af koden der er blevet rettet i.)
Men jeg vil give dig ret i at der nok er langt flere sikkerhedshuller på så høje lag, at de har samme effekt på både IPv4 og IPv6, end der er IP relaterede huller i IPv4 og IPv6 tilsammen.
Meget anderledes. Alle vidste hvornår det ville ske, og at tidspunktet ikke kunne flyttes. Der var ingen der foreslog komplicerede foranstaltninger, som skulle sikre at datoer kunne genbruges og dermed udskyde årsskiftet indtil m an var klar.SygGangster (23) skrev:Y2K
Alle de alvorlige fejl blev rettet. Kosmetiske fejl eksisterede til gengæld flere år efter. Med en målrettet indsats undgik man altså totalt kaos. At det gik så godt burde betyde, at dem, som sørgede for at finde og udbedre fejlene, blev mødt med stor respekt. I praksis blev de dog mødt med en ligegyldighed, for befolkningen i almindelighed havde fået en opfattelse af, at problemet aldrig havde eksisteret.
Overgangen fra IPv4 til IPv6 er anderledes. Vi kender ikke den præcise dato hvor IPv4 adresserne bliver brugt op. Det har gjort at det er blevet taget mindre seriøst. Desuden har man i stor grad gjort det til de andres problem, og desværre har den strategi virket.
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