[Løst] Grunnleggende spm ang VPN

[FullColor]

Jeg ville bare skjekke en ting, VPN gaar hele veien fra VPN server til en PC ikke sant ? altsaa, den gar ikke bare til routeren, men fortsetter hele veien gjennom wifi til den individuelle klienten ?

 

Slik at viss en annen person har kontroll og tilgang over routeren/access point, sa beskytter vpn trafikken ende-til-ende uansett, fra server til klient. Slik at det burde vare relativt trygt mot 'man in the middle' angrep, selv om personen skulle ha fysisk tilgang til router og access point ?

Endret 24. februar 2014 av FullColor

[Kakeshoma]

Hvis du setter opp en VPN tunnel fra maskinen din ja..

[FullColor]

Hvis du setter opp en VPN tunnel fra maskinen din ja..

I motsetning til hva da ? hva slags distinksjoner snakker vi om naa ?

[Kakeshoma]

Site-to-site VPN mellom to routere feks..

Om du har VPN-klientprogramvare på maskinen som kobler seg opp mot en VPNserver er linjen mellom maskin og server kryptert hele veien.

[process]

Med tilgang til router/AP/gateway kan man sette opp et alternativt VPN-endepunkt og overstyre DNS (evt. reroute IP-trafikk) og således lure deg til å tro at du kobler til din VPN-tilbyder mens du i realiteten kobler til angriperen sin maskin.

 

Dette vil trigge et sertifikatvarsel dersom VPN-gatewayen har et sertifikat og du har hentet riktig sertifikat en gang tidligere. Det er derfor greit å være obs på slike meldinger.

 

Det beste er å bruke klientsertifikat for å autentisere begge veier, slik at det kontrolleres at serveren, såvel som klienten er de de skal være. Vet ikke hvilke leverandører som gjør dette.

 

Dette ligger ganske høyt på paranoia-skalaen, men er krav i noen miljø

Endret 24. februar 2014 av process

[FullColor]

Takk for all tilbakemelding, det var berikende informasjon i mine øyne.

 

Når vi er inne på det:

og du har hentet riktig sertifikat en gang tidligere.

Er det også mulig og gjøre det du skriver om med en gang, eller måtte en mulig angriper la meg opprette vpn først, før han kunne sette opp en alternativt vpn-endepunkt og prøve og lure meg med tanke på sertifikatene ? Eller er det trygt og og stole på at når man først oppretter vpn så for man riktig sertifikat selv om angriperen har kontroll og tilgang til router\AP på forhånd ? Endret 25. februar 2014 av FullColor

[process]

Takk for all tilbakemelding, det var berikende informasjon i mine øyne.

 

Når vi er inne på det:

og du har hentet riktig sertifikat en gang tidligere.

Er det også mulig og gjøre det du skriver om med en gang, eller måtte en mulig angriper la meg opprette vpn først, før han kunne sette opp en alternativt vpn-endepunkt og prøve og lure meg med tanke på sertifikatene ? Eller er det trygt og og stole på at når man først oppretter vpn så for man riktig sertifikat selv om angriperen har kontroll og tilgang til router\AP på forhånd ?

 

 

Dersom angrepet er satt opp og forberedt på forhånd så ja, men her skal vedkommende være ganske godt forberedt for at dette skal gå sømløst. Nok til at jeg ikke tror det er grunn til bekymring sånn uten videre, men det ligger mange muligheter i å kontrollere gatewayen din.

 

Når det gjelder verifisering av sertifikatet kommer det litt an på om det er godkjent av en 3. instans, disse er ofte validert av CA'ene som har utstedt. Er det selvsignert må du finne en måte å selv validere at det er korrekt. Det grunnleggende problemet er den første utvekslingen av gyldige kredensialer/identitet, som per i dag løses av CA-modellen.

 

Utover dette så er det nok ganske trygt. Dette er en høyst hypotetisk mulighet, men det er slike og lignende problemstillinger som ligger til grunn for at noen krever å bero på klientsertifikat.

 

Videre kan det være verdt å merke seg at du mest sannsynlig vil ønske å tunnelere all trafikk via VPN, herunder også DNS.

Endret 25. februar 2014 av process

[FullColor]

Takk igjen.

 

Videre kan det være verdt å merke seg at du mest sannsynlig vil ønske å tunnelere all trafikk via VPN, herunder også DNS.

Though, jeg må si at denne siste merknaden var litt vanskelig for meg og forstå. Var det ikke det vi allerede snakket om, altså og tunnelere all trafikk gjennom vpn ? I så fall så gir det meg inntrykket at du sier "å tunnelere all trafikk gjennom vpn for så og opprette vpn. Men det kan være meg some leser det må en feilaktig måte, du mener vell kanskje bare å empasisere kun en ting, at jeg også sender dns gjennom vpn tunnelen ? Jrg trodde i så fall det var automatisk, at når man opprettet vpn så gikk ALL trafikk gjennom vpn'en, er det ikke så ? Endret 28. februar 2014 av FullColor

[process]

Jrg trodde i så fall det var automatisk, at når man opprettet vpn så gikk ALL trafikk gjennom vpn'en, er det ikke så ?

 

 

Det var muligens en unødvendig presisering, det er litt avhengig av oppsettet, men kan være verdt å sjekke da det er viktig at også DNS går via VPN. All trafikk blir ikke nødvendigvis sent gjennom en VPN tunnel, men mange klienter gjør det slik og mest sannsynlig vil det også være slik (VPN kan brukes på ulike forskjellige måter for å løse ulike oppgaver).

 

Det du vil oppleve er at rutene for hele lokalnettet ditt blir liggende (route print på windows, sudo route på osx/linux). Du trenger en route til routeren for å i det hele tatt nå VPN-tilbyderen, så ikke slett denne.

 

Poenget er at hvis du benytter ruteren (eller noe annet på lokalnettet) som DNS forwarder/'server' så kan denne bli liggende igjen og fortsette å gjøre DNS-oppslag via denne uten å fortsette videre ut via VPN-tunnellen, men at ruteren selv videresender DNS-oppslaget.

 

Dette forutsetter nok overstyring av DNS på VPN-forbindelsen eller en klient som mot formodning beholder lokale DNS innstillinger.

 

Ingen big deal, men verdt å sjekke da jeg mener å ha lest om at noen som har opplevd dette.

 

EDIT: Klarte ikke legge det fra meg og fant en god stack exchange som omhandler akkurat dette, er et par interessante ting der, bla om prioritering av nettverkstilkoblinger ift. hvilke DNS instillinger som benyttes: http://security.stackexchange.com/questions/13900/if-i-use-a-vpn-who-will-resolve-my-dns-requests

Endret 2. mars 2014 av process