mboost-dp1
Debogon og Hamachi
Jeg faldt over et sted der nævnte Hamachi og kom til at spekulere på om der var noget nyt omkring deres misbrug af 5.0.0.0/8.
RIPE NCC har gennem længere tid haft et Debogon projekt kørende som holder øje med misbrug af 5.0.0.0/8 og 37.0.0.0/8 før de tages i brug. Man kan læse mere om det projekt på http://www.ris.ripe.net/debogon/ og http://labs.ripe.net/Members/mkarir/first-impressi...
Men det RIPE kigger efter i deres analyse er nærmest det modsatte af hvad Hamachi gør, og derfor har analysen heller intet vist om Hamachi. Jeg tror nu alligevel RIPE er fuldstændigt klar over hvad Hamachi foretager sig, spørgsmålet er om de kan/vil gøre noget.
Den anbefaling der indtil videre er kommet ud af analysen er at undlade at uddele fem /24 netværk der modtager mest bogus trafik. Dette har tilsyneladende intet med Hamachi at gøre.
Rundt omkring på nettet er der computere som pga. fejl i konfiguration eller software har sendt pakker til adresser som ikke findes. Disse når ikke langt ud på backbone før det opdages at destination ikke findes, og der sendes en fejl tilbage. Hvis nogen fik tildelt en hidtil ikke eksisterende adresse, som modtog en masse af denne trafik ville deres netværk kunne lide under det.
Hamachi derimod forårsager at trafik fra Hamachi brugere der burde være sent til et sted under 5.0.0.0/8 ikke når frem til destination, men derimod sendes gennem Hamachi netværket.
RIPE annoncerede nogle prefixes under 5.0.0.0/8, men de kiggede kun på hvad de modtog af trafik som de ikke burde have modtaget. Derimod er det sværere at vurdere trafik som de burde have modtaget, men som de ikke modtog af den simple grund at dette netværk pt. ikke burde modtage noget trafik overhovedet.
Om det ene eller andet problem er størst har jeg ikke nogen holdning til. Men begge dele er et problem for dem som får tildelt adresser under 5.0.0.0/8.
Længe før RIPE blev tildelt 5.0.0.0/8 er Hamachi blevet spurgt hvad de ville gøre ved problemet, men de har endnu ikke svaret. Problemet for dem er at den eneste rigtige løsning er at Hamachi i sin nuværende form bliver lukket helt ned.
Den trafik som RIPEs debogon projekt burde have set fra Hamachi klienter har de naturligvis intet set til, da det burde være sendt ind i Hamachi netværket. Dermed har Hamachi måske haft mulighed til at se noget af samme bogus trafik, men jeg ved ikke om de har set det eller overhovedet skænket det en tanke.
Jeg ved ikke hvilken algoritme Hamachi bruger til at agøre hvilken IP adresse der tildeles hvilken klient. Dermed ved jeg heller ikke om der er nogen Hamachi klient som risikerer at modtage bogus trafik af den grund.
Der hvor problemet med Hamachi bliver interessant er når der rent faktisk bliver sat servere op på 5.0.0.0/8 adresser. Hamachi klienter der prøver at kontakte sådan en server vil opleve at DNS opslag virker korrekt, men efterfølgende kontakt til serveren vil fejle.
I stedet for at sende deres requests til den rigtige server vil de sende dem til en anden Hamachi klient (hvis Hamachi har tildelt den pågældende adresse) eller blot kassere pakken.
Hvis en Hamachi bruger får samme IP som en legitim server, så kan denne Hamachi bruger uden den mindste indsats hijacke alt trafik til denne legitime server fra andre Hamachi klienter. Er der tale om SSL beskyttet trafik vil brugerne selvfølgelig se en fejlmelding. Men er der ikke anvendt SSL vil et fake site som ligner det ægte nemt kunne sættes op.
Man kan ikke på nuværende tidspunkt kende IP adresserne på legitime servere i 5.0.0.0/8 netværket, så man kan ikke målrettet gå efter de gode adresser. Men det kunne sikkert sagtens lade sig gøre at hamstre adresser fra Hamachi i håb om at en af dem en gang i fremtiden kan bruges til at spoofe et interessant site.
Er her nogen som ved om man kan finde ud af om der er blevet hamstret IP adresser fra Hamachi? Og er her nogen som ved nok om hvordan Hamachi virker til at kunne svare på om de kan trække en adresse tilbage hvis den bliver anvendt til denne form for misbrug?
RIPE NCC har gennem længere tid haft et Debogon projekt kørende som holder øje med misbrug af 5.0.0.0/8 og 37.0.0.0/8 før de tages i brug. Man kan læse mere om det projekt på http://www.ris.ripe.net/debogon/ og http://labs.ripe.net/Members/mkarir/first-impressi...
Men det RIPE kigger efter i deres analyse er nærmest det modsatte af hvad Hamachi gør, og derfor har analysen heller intet vist om Hamachi. Jeg tror nu alligevel RIPE er fuldstændigt klar over hvad Hamachi foretager sig, spørgsmålet er om de kan/vil gøre noget.
Den anbefaling der indtil videre er kommet ud af analysen er at undlade at uddele fem /24 netværk der modtager mest bogus trafik. Dette har tilsyneladende intet med Hamachi at gøre.
Rundt omkring på nettet er der computere som pga. fejl i konfiguration eller software har sendt pakker til adresser som ikke findes. Disse når ikke langt ud på backbone før det opdages at destination ikke findes, og der sendes en fejl tilbage. Hvis nogen fik tildelt en hidtil ikke eksisterende adresse, som modtog en masse af denne trafik ville deres netværk kunne lide under det.
Hamachi derimod forårsager at trafik fra Hamachi brugere der burde være sent til et sted under 5.0.0.0/8 ikke når frem til destination, men derimod sendes gennem Hamachi netværket.
RIPE annoncerede nogle prefixes under 5.0.0.0/8, men de kiggede kun på hvad de modtog af trafik som de ikke burde have modtaget. Derimod er det sværere at vurdere trafik som de burde have modtaget, men som de ikke modtog af den simple grund at dette netværk pt. ikke burde modtage noget trafik overhovedet.
Om det ene eller andet problem er størst har jeg ikke nogen holdning til. Men begge dele er et problem for dem som får tildelt adresser under 5.0.0.0/8.
Længe før RIPE blev tildelt 5.0.0.0/8 er Hamachi blevet spurgt hvad de ville gøre ved problemet, men de har endnu ikke svaret. Problemet for dem er at den eneste rigtige løsning er at Hamachi i sin nuværende form bliver lukket helt ned.
Den trafik som RIPEs debogon projekt burde have set fra Hamachi klienter har de naturligvis intet set til, da det burde være sendt ind i Hamachi netværket. Dermed har Hamachi måske haft mulighed til at se noget af samme bogus trafik, men jeg ved ikke om de har set det eller overhovedet skænket det en tanke.
Jeg ved ikke hvilken algoritme Hamachi bruger til at agøre hvilken IP adresse der tildeles hvilken klient. Dermed ved jeg heller ikke om der er nogen Hamachi klient som risikerer at modtage bogus trafik af den grund.
Der hvor problemet med Hamachi bliver interessant er når der rent faktisk bliver sat servere op på 5.0.0.0/8 adresser. Hamachi klienter der prøver at kontakte sådan en server vil opleve at DNS opslag virker korrekt, men efterfølgende kontakt til serveren vil fejle.
I stedet for at sende deres requests til den rigtige server vil de sende dem til en anden Hamachi klient (hvis Hamachi har tildelt den pågældende adresse) eller blot kassere pakken.
Hvis en Hamachi bruger får samme IP som en legitim server, så kan denne Hamachi bruger uden den mindste indsats hijacke alt trafik til denne legitime server fra andre Hamachi klienter. Er der tale om SSL beskyttet trafik vil brugerne selvfølgelig se en fejlmelding. Men er der ikke anvendt SSL vil et fake site som ligner det ægte nemt kunne sættes op.
Man kan ikke på nuværende tidspunkt kende IP adresserne på legitime servere i 5.0.0.0/8 netværket, så man kan ikke målrettet gå efter de gode adresser. Men det kunne sikkert sagtens lade sig gøre at hamstre adresser fra Hamachi i håb om at en af dem en gang i fremtiden kan bruges til at spoofe et interessant site.
Er her nogen som ved om man kan finde ud af om der er blevet hamstret IP adresser fra Hamachi? Og er her nogen som ved nok om hvordan Hamachi virker til at kunne svare på om de kan trække en adresse tilbage hvis den bliver anvendt til denne form for misbrug?
Nu er det jo ikke værre end at klienten kan sættes offline og derved er tunnelen nedlagt.
At kalde det et misbrug af 5.0.0.0/8 vil jeg mene er at overdrive. Da Hamachi var en ung purk og et en mans hoppy projekt dvs. før LogMeIn,
har valget den gang ligget i mellem de jomfruelige ranges og de private ranges. Valget blev som det blev da han ikke havde andre alternativer der var lige så frie samt det var jo heller ikke et problem den gang.
At det i dag er det vokset og "kommercielt" det er hvad det er.
Apropos, man har ikke ukritisk adgang til alle andre, man skal joine "gruppe" hvor andre også er på. Der er grænser for hvor mange der kan være på en gruppe af gangen og en grænse for hvor mange grupper du kan være med i. så hermed er der en grænse for hvor mange der kan eksponeres.
At kalde det et misbrug af 5.0.0.0/8 vil jeg mene er at overdrive. Da Hamachi var en ung purk og et en mans hoppy projekt dvs. før LogMeIn,
har valget den gang ligget i mellem de jomfruelige ranges og de private ranges. Valget blev som det blev da han ikke havde andre alternativer der var lige så frie samt det var jo heller ikke et problem den gang.
At det i dag er det vokset og "kommercielt" det er hvad det er.
Apropos, man har ikke ukritisk adgang til alle andre, man skal joine "gruppe" hvor andre også er på. Der er grænser for hvor mange der kan være på en gruppe af gangen og en grænse for hvor mange grupper du kan være med i. så hermed er der en grænse for hvor mange der kan eksponeres.
Det er jo ikke ulovligt eller direkte "forkert" at bruge selv valgte ranges i egne tunneler, selv om vi godt kan blive enig om at det kan være uhensigt mæssigt.kasperd (1) skrev:Jeg tror nu alligevel RIPE er fuldstændigt klar over hvad Hamachi foretager sig, spørgsmålet er om de kan/vil gøre noget.
Hamachi er et lukket tunnel netværk, det er kun i tilfælde af temporært fnidder i program / cache / tunnel / windows at det kan leake ud på internettet.kasperd (1) skrev:Den anbefaling der indtil videre er kommet ud af analysen er at undlade at uddele fem /24 netværk der modtager mest bogus trafik. Dette har tilsyneladende intet med Hamachi at gøre.
Selvfølgelig var der alternativer. Han kunne have brugt 10.0.0.0/8 som er reserveret til formålet. Eller han kunne have betalt for en allokering igennem officielle kanaler (hvilket dog kunne have betydet at tjenesten var blevet lidt dyrere). Han kunne for den sags skyld have kombineret de to og givet en adresse under 10.0.0.0/8 til de brugere der ikke ville betale for en officiel. De to grupper af brugere ville stadig kunne kommunikere med hinanden.cnx (2) skrev:Valget blev som det blev da han ikke havde andre alternativer der var lige så frie samt det var jo heller ikke et problem den gang.
Det betyder nok at det er sværere at spoofe legitime sites. Det vil betyde at de fleste Hamachi brugere i den situation blot vil få en timeout når de prøver at kontakte sitet. Det er bedre end at blive sendt til et fake site, men stadig ikke ønskværdigt.cnx (2) skrev:Apropos, man har ikke ukritisk adgang til alle andre, man skal joine "gruppe" hvor andre også er på. Der er grænser for hvor mange der kan være på en gruppe af gangen og en grænse for hvor mange grupper du kan være med i. så hermed er der en grænse for hvor mange der kan eksponeres.
Ulovligt er det nok ikke, men forkert er det. Jeg har aldrig selv brugt softwaren, så jeg ved ikke hvor godt den advarer brugerne imod konsekvenserne. Hvis softwaren hver gang den startes advarer om at den vil gøre brugerens internetadgang mindre stabil, så er det måske ok.cnx (2) skrev:Det er jo ikke ulovligt eller direkte "forkert" at bruge selv valgte ranges i egne tunneler
Hvorvidt det rent faktisk er ulovligt får vi nok ikke noget svar på før der har været en sag med hijacking af trafik.
Hvor mange brugere har Hamachi? Hvor mange vigtige websites kan der komme til at ligge i 5.0.0.0/8? Når produktet af de to tal når 2^24 vil den første kollision af adresser sandsynligvis forekomme. Hvis Hamachi bruger en promille af adresserne i intervallet og hvis en promille af adresserne bruges til legitime websites vil man kunne forvente omkring 16 kollisioner.
Hvis en kollision kun vil kunne misbruges imod en lille andel af brugerne er det ikke så oplagt et mål. Men hvis nogen opdager at deres computer modtager trafik der f.eks. var ment til et netbanking site og finder på at misbruge det, så vil det ikke overraske mig om Hamachi kan komme til at stå som medansvarlig.
Der er flere måder det kan ske på.cnx (2) skrev:Hamachi er et lukket tunnel netværk, det er kun i tilfælde af temporært fnidder i program / cache / tunnel / windows at det kan leake ud på internettet.
Der kan f.eks. være åbne forbindelser når tunnellen lukkes. Det kan også være at nogen har valgt at lave et DNS navn for deres Hamachi IP som vil resultere i trafik til netværk med legitime adresser i 5.0.0.0/8, hvis disse navne tilgås fra maskiner uden Hamachi klienten.
Selv hvis navnene kun kan slås op så længe man er på Hamachi netværket vil trafik kunne lække, da mange browsere ignorerer TTL på opslag og bliver ved med at bruge en IP adresse længe efter den er udløbet og burde slås op igen.
Jeg ved ikke om Hamachi klienten overrider den DNS server som klientmaskinen er blevet tildelt fra sin internetudbyder. Hvis ikke den gør det, så kan man ikke lave navne som kun kan slås op af Hamachi klienter.
Men jeg tror ikke Hamachi er skyld i ret meget af den trafik der ender op på 5.0.0.0/8. Men jeg må dog tilstå at jeg ved ikke hvordan man skulle verificere det. Hamachi kan både forårsage trafik dertil men kan også opsluge noget af den trafik der ellers ville været blevet sendt dertil. Om de to datamængder er lige store ved jeg ikke, men jeg gætter på at antallet af Hamachi brugere trods alt er så lille at datamængden i sidste ende vil være en lille andel og nok forsvinde i mængden. Men jeg kender ikke talene, så jeg kan kun gætte på hvordan de ser ud.
Hvilket er en privat range og kunne fra start give klasse A brugere problemer.kasperd (3) skrev:Han kunne have brugt 10.0.0.0/8 som er reserveret til formålet.
Imo, giver det ikke mening at købe ip range til et lukket net.kasperd (3) skrev:officielle kanaler
Som sagt. Dog skal man tænke over Hamachi skal spille samme med alle private ranges og det kan den ikke problemfrit hvis den selv benytter den private range.kasperd (3) skrev:Ulovligt er det nok ikke, men forkert er det.
Det tvivler jeg på da det er ikke dens formål, men negativ omstændighed i designet pga. hvordan ip protokollen er bygget.kasperd (3) skrev:Hvorvidt det rent faktisk er ulovligt får vi nok ikke noget svar på før der har været en sag med hijacking af trafik.
Ligeledes kan jeg da sige jeg har se mange "smarte" ip ranges i vpn tunneler, hvilket hamachi kan side stilles med.
Af ren dovenskab var det med vilje jeg kun skrev det vagt.kasperd (3) skrev:Der er flere måder det kan ske på.
En nedlagt tunnel vil også lukke aktive forbindelser hvilke henleder til om softwaren eller en selv vil forsøge at genoprette forbindelse.
Og hvilken software skulle det så være, højfortrolig software er det nok ikke. Jeg vil mene det er en bagatel og middelstidigt det kan leake. Udover det er vi nok enig :)
Nej, Hamachi piller ikke ved DNS eller caches for den sags skyld.kasperd (3) skrev:Jeg ved ikke om Hamachi klienten overrider den DNS server som klientmaskinen er blevet tildelt fra sin internetudbyder.
Medvidere er det et virtuelt adapter og derfor følger windows's håndtering hvilket er efter adapteren og rutens prioritering.
For at lette forståelse vil jeg prøv at forklare Hamachi kort.
Hamachi er et virtuel netværks adapter i windows som argere vpn tunnel hvor man selv selektivt skal vælge folk eller grupper man vil være i netværk med. Alle brugere i tunnelen vil have en 5.x.x.x ip.
Windows håndter selv per design den virtuelle adapter som en hvilket andet netkort.
Det er jo netop det der er pointen.cnx (4) skrev:Hvilket er en privat range
Problemerne kan reduceres betydeligt hvis man blot er villig til at skrive en lille smule kode til at håndtere det:cnx (4) skrev:kunne fra start give klasse A brugere problemer.
- Som adgangspunkt vælg adresserne tilfældigt således at der er meget lille risiko for kollisioner.
- Giv brugeren 2-5 adresser at vælge imellem således at risikoen for at de alle har en kollision er negligible.
- Giv brugeren valget mellem en enkelt rute til 10.0.0.0/8 (effektiv, men virker ikke hvis han samtidig vil bruger intervallet til andet), eller separate ruter per peer (bruger mere CPU kraft til routing, men tillader at resten af adresserne i intervallet kan bruges til andet).
- Brugeren kan endeligt omkonfigurere sit lokalnet hvis der på trods af alt ovenstående stadig er konflikter.
Hvis du vil undgå kollisioner gør det. Og du begyndte selv på at argumentere for at kollisioner var et problem.cnx (4) skrev:Imo, giver det ikke mening at købe ip range til et lukket net.
Der er tre muligheder:
- Brug RFC1918 og lev med at du en gang imellem bliver nødt til at omnummerere pga kollisioner.
- Få tildelt et officielt prefix.
- Opgrader til IPv6 hvor RFC4193 har en løsning til at undgå de kollisioner man kunne se med RFC1918.
Den skal også fungere sammen med offentlige ranges. Det er kun nogle af brugerne der har brug for at kombinere det med deres egne private ranges. Men alle brugerne har brug for at det fungere sammen med offentlige ranges.cnx (4) skrev:Dog skal man tænke over Hamachi skal spille samme med alle private ranges og det kan den ikke problemfrit hvis den selv benytter den private range.
Hvorfor tog Hamachi ikke bare og brugte /0 prefixet i stedet? Så kunne de have haft 256 gange så mange brugere.
Ja, men det er stadig de højere lag der bestemmer hvad der står i routnings tabellen og hvilke DNS servere der anvendes.cnx (4) skrev:Windows håndter selv per design den virtuelle adapter som en hvilket andet netkort.
Jeg har ikke lyst til at fluekneppe tekniske detaljer som jeg har udemærket viden om. Hamachi må svare sig selv.
Jeg svarede kun sætte mit synspunkt for hvordan Hamachi ser ud fra mit synspunkt vi er enig i at der er problemstillinger. Hvor slemme problemstillingerne så er i forhold til hvor lille ubetydelig jeg ser softwaren hamachi er, er vi nok mere forskellige.
Jeg svarede kun sætte mit synspunkt for hvordan Hamachi ser ud fra mit synspunkt vi er enig i at der er problemstillinger. Hvor slemme problemstillingerne så er i forhold til hvor lille ubetydelig jeg ser softwaren hamachi er, er vi nok mere forskellige.
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
- ⟨
- Software
Gå til bund