---

Hej Ng

Jeg vil lige høre om der er nogen der kender til noget software der kan lave
en vpn koncentrator på ens linux maskine, således at andre i verdnen har
mulighed for at logge sig ind i mit interne netværk udefra ?

Mit problem er at jeg skal supportere nogle mennesker der sidder på nogle
internet linier med routere, hvor vi ikke har adgang til konfigurationen, og
dermed ikke mulighed for at åbne op for fjernsupport/administration af
maskinerne. Og så ville det jo være lidt lettere at få folk til at logge ind
i mit netværk, og derefter overtage dem.

Mvh Jacob

---

"Jacob d'Andrade" <jacob@removethezub.dk> wrote in
news:ei79ak$c5d$1@daniella.thezub.dk:

> Hej Ng
>
> Jeg vil lige høre om der er nogen der kender til noget software der
> kan lave en vpn koncentrator på ens linux maskine, således at andre i
> verdnen har mulighed for at logge sig ind i mit interne netværk udefra
> ?
>
> Mit problem er at jeg skal supportere nogle mennesker der sidder på
> nogle internet linier med routere, hvor vi ikke har adgang til
> konfigurationen, og dermed ikke mulighed for at åbne op for
> fjernsupport/administration af maskinerne. Og så ville det jo være
> lidt lettere at få folk til at logge ind i mit netværk, og derefter
> overtage dem.
>
> Mvh Jacob
>

OpenVPN?

mvh
Lars

---

"Lars L. Christensen" <lars_christesen@ieee.org> skrev i en meddelelse
>
> OpenVPN?
>
> mvh
> Lars

Ja selvfølgelig Takker mange gange ... tænkte ik lige så langt..

Mvh Jacob

---

Den Tue, 31 Oct 2006 11:42:22 +0100 skrev Jacob d'Andrade:
> Hej Ng
>
> Jeg vil lige høre om der er nogen der kender til noget software der kan lave
> en vpn koncentrator på ens linux maskine, således at andre i verdnen har
> mulighed for at logge sig ind i mit interne netværk udefra ?

VPN Koncentrator er en Cisco-kasse.

VPN kan du lave, der er fx IPSEC-standarden der er supporteret under
både Linux og Windows.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Kent Friis <nospam@nospam.invalid> writes:

>VPN Koncentrator er en Cisco-kasse.

....og en ZyXEL og en NetGear og en Sarian og en Aruba og en
Altiga og en... ja. En del andre der alle kalder deres eget
produkt for VPN Concentrator

Alt i alt er det mere et begreb end et produkt.

Mvh.
   Klaus.

---

Den Tue, 31 Oct 2006 16:59:02 +0000 (UTC) skrev Klaus Ellegaard:
> Kent Friis <nospam@nospam.invalid> writes:
>
>>VPN Koncentrator er en Cisco-kasse.
>
> ...og en ZyXEL og en NetGear og en Sarian og en Aruba og en
> Altiga og en... ja. En del andre der alle kalder deres eget
> produkt for VPN Concentrator

Ok. Men stadig en kasse man køber.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

On Tue, 2006-10-31 at 11:42 +0100, Jacob d'Andrade wrote:
> Hej Ng
>
> Jeg vil lige høre om der er nogen der kender til noget software der kan lave
> en vpn koncentrator på ens linux maskine, således at andre i verdnen har
> mulighed for at logge sig ind i mit interne netværk udefra ?

Ja, der er masser af software der opfylder det behov.

Hvilke OS bruge klienterne?

> Mit problem er at jeg skal supportere nogle mennesker der sidder på nogle
> internet linier med routere, hvor vi ikke har adgang til konfigurationen, og
> dermed ikke mulighed for at åbne op for fjernsupport/administration af
> maskinerne. Og så ville det jo være lidt lettere at få folk til at logge ind
> i mit netværk, og derefter overtage dem.

Vi bruger VNC, hvor vi vender setup'et om på hoved.

Normalt har supporteren en VNC klient der sender en forspørgelse til
brugerens VNC serveren, der skal fjernstyres. Dette virker ikke da,
vores brugere typisk har en bærbar med en VPN klient med en simpel
firewall, der forhindre alle forbindelser ind.

Istedet starter supporteren en VNC listner klient, og brugeren starter
en VNC server med en udgående session til VNC listner klienten. Herved
kan maskinen fjernstyres.


Det hedder i VNC termonologien "reverse connections".

Mere info på google:

http://www.google.com/search?q=vnc+reverse+connections


Hvis klienterne er windows brugere skal de starte et program på
166Kbyte, hvorefter du kan fjernstyre deres maskine:

http://sc.uvnc.com/index.php?section=12.

---

> Hvis klienterne er windows brugere skal de starte et program på
> 166Kbyte, hvorefter du kan fjernstyre deres maskine:
>
> http://sc.uvnc.com/index.php?section=12.
>

Har du fået uvnc til at fungere med andre vnc-klienter (listener's)?

Mvh / Preben

---

On Tue, 2006-10-31 at 16:19 +0000, Kent Friis wrote:
> VPN kan du lave, der er fx IPSEC-standarden der er supporteret under
> både Linux og Windows.

Det er noget snavs, da det giver klienterne flere sikkerhedsproblemmer
end de oprindeligt havde.

---

Den Tue, 31 Oct 2006 19:24:50 +0100 skrev Christian E. Lysel:
> On Tue, 2006-10-31 at 16:19 +0000, Kent Friis wrote:
>> VPN kan du lave, der er fx IPSEC-standarden der er supporteret under
>> både Linux og Windows.
>
> Det er noget snavs, da det giver klienterne flere sikkerhedsproblemmer
> end de oprindeligt havde.

Det må du godt forklare.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

On Tue, 2006-10-31 at 20:32 +0100, Preben wrote:
> Har du fået uvnc til at fungere med andre vnc-klienter (listener's)?

Jeg bruger ikke uvnc, men TightVNC, RealVNC og blot VNC...de virker
alle.

---

"Christian E. Lysel" <sunsite.dk@spindelnet.dk> skrev i en meddelelse
news:1162320750.2601.30.camel@bigfoot.lan.spindelnet.dk...
On Tue, 2006-10-31 at 20:32 +0100, Preben wrote:
> Har du fået uvnc til at fungere med andre vnc-klienter (listener's)?

Jeg bruger ikke uvnc, men TightVNC, RealVNC og blot VNC...de virker
alle.

---

Jeg takker for hjælpen og alle de gode svar. Jeg er endt med at bruge vnc og
reverse connections istedet for... det var lidt lettere

Mvh Jacob

---

On Tue, 2006-10-31 at 20:25 +0000, Kent Friis wrote:
> >> VPN kan du lave, der er fx IPSEC-standarden der er supporteret under
> >> både Linux og Windows.
> >
> > Det er noget snavs, da det giver klienterne flere sikkerhedsproblemmer
> > end de oprindeligt havde.
>
> Det må du godt forklare.

En VPN klient, kan se andre VPN klienter.

Jeg kan som kunde måske have tillid til min leverandør, men slet ikke
til leverandørens kunder.

---

Den Tue, 31 Oct 2006 23:02:07 +0100 skrev Christian E. Lysel:
> On Tue, 2006-10-31 at 20:25 +0000, Kent Friis wrote:
>> >> VPN kan du lave, der er fx IPSEC-standarden der er supporteret under
>> >> både Linux og Windows.
>> >
>> > Det er noget snavs, da det giver klienterne flere sikkerhedsproblemmer
>> > end de oprindeligt havde.
>>
>> Det må du godt forklare.
>
> En VPN klient, kan se andre VPN klienter.
>
> Jeg kan som kunde måske have tillid til min leverandør, men slet ikke
> til leverandørens kunder.

Det lyder ikke korrekt. En IPSEC-forbindelse har en shared key, og kun
de to maskiner der har denne key kan snakke sammen. Andre kunder vil
naturligvis bruge en anden key, hvorved forbindelse direkte imellem
dem ikke burde være muligt.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

On Tue, 2006-10-31 at 22:19 +0000, Kent Friis wrote:
> Det lyder ikke korrekt. En IPSEC-forbindelse har en shared key, og kun
> de to maskiner der har denne key kan snakke sammen.

Det lyder som en slem misforståelse.

Du har ret hvis vi kun snakker om IKE, men IPSEC indeholder jo mere end
IKE. Trafikken der encapsuleres af ESP kan forgå mellem andre maskiner
end de to som deles om shared key.

Scenarie: To klienter kobler sig op til VPN routeren. Disse kan via VPN
routerens routningsregler se hinanden. Det var den oprindelig
problemstilling.

> Andre kunder vil naturligvis bruge en anden key,

Faktisk ikke, det er mere undtagelsen.

De fleste Cisco VPN concentrator konfigurationer jeg har set er shared
secret identisk for grupper af brugere. De gør det meget nemmere alt
laver regler for denne gruppe af brugere.


Det minder om en undersøgelse af SSL daemoner på Internet, hvor 10% af
enhederne _ikke_ har unike private nøgler. Se mere på
http://tech.netscape.com/story/2006/10/30/dan-kaminskys-ssl-hell/

---

>>>>> "CEL" == Christian E Lysel <sunsite.dk@spindelnet.dk> writes:

CEL> Scenarie: To klienter kobler sig op til VPN routeren. Disse kan
CEL> via VPN routerens routningsregler se hinanden. Det var den
CEL> oprindelig problemstilling.

Kun vis VPN-routeren tillader routing mellem de enkelte tunneler, OG
tunnelerne rent faktisk indeholder hinandens IP-er.

Hvis f.eks. firmanettet er 10.0.0.0/24 (tunnelen sættes til kun at
dække dette net), og klienterne tildeles adresser i 172.16.0.0/24, så
kan klienterne umuligt se hinanden.


/Benny

---

Den Tue, 31 Oct 2006 23:39:13 +0100 skrev Christian E. Lysel:
> On Tue, 2006-10-31 at 22:19 +0000, Kent Friis wrote:
>> Det lyder ikke korrekt. En IPSEC-forbindelse har en shared key, og kun
>> de to maskiner der har denne key kan snakke sammen.
>
> Det lyder som en slem misforståelse.
>
> Du har ret hvis vi kun snakker om IKE, men IPSEC indeholder jo mere end
> IKE. Trafikken der encapsuleres af ESP kan forgå mellem andre maskiner
> end de to som deles om shared key.

Men hvis de ikke har den rigtige key kan de ikke dekryptere trafikken.

> Scenarie: To klienter kobler sig op til VPN routeren. Disse kan via VPN
> routerens routningsregler se hinanden. Det var den oprindelig
> problemstilling.

Det gælder alle former for VPN og routing. Er der en maskine der
router den dekrypterede trafik imellem de forskellige net, så
vil trafik kunne routes imellem dem. Men det må man jo bare lade
være med så.

>> Andre kunder vil naturligvis bruge en anden key,
>
> Faktisk ikke, det er mere undtagelsen.

Der er sg* da ingen pointe i at kalde noget privat, og så give alle
den samme nøgle.

> De fleste Cisco VPN concentrator konfigurationer jeg har set er shared
> secret identisk for grupper af brugere. De gør det meget nemmere alt
> laver regler for denne gruppe af brugere.

At Cisco-folk ikke kan finde ud af at sætte det op er da ikke et
argument imod IPSEC.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

On Wed, 2006-11-01 at 11:22 +0100, Benny Amorsen wrote:
> >>>>> "CEL" == Christian E Lysel <sunsite.dk@spindelnet.dk> writes:
>
> CEL> Scenarie: To klienter kobler sig op til VPN routeren. Disse kan
> CEL> via VPN routerens routningsregler se hinanden. Det var den
> CEL> oprindelig problemstilling.
>
> Kun vis VPN-routeren tillader routing mellem de enkelte tunneler, OG
> tunnelerne rent faktisk indeholder hinandens IP-er.

Ja. Et normalt setup på Cisco VPN er at klienterne får en IP adresse på
firmanettet.

Som klient har du ej nogen garanti for konfiguration ikke pludselig kan
ændre sig.

> Hvis f.eks. firmanettet er 10.0.0.0/24 (tunnelen sættes til kun at
> dække dette net), og klienterne tildeles adresser i 172.16.0.0/24, så
> kan klienterne umuligt se hinanden.

I mit ovenstående eksempel, vil klienterne få ip adresser på
10.0.0.0/24, og således fint kunne se hinanden.

---

On Wed, 2006-11-01 at 15:33 +0000, Kent Friis wrote:
> Men hvis de ikke har den rigtige key kan de ikke dekryptere trafikken.

Nej, det har jeg ej påstået.

> > Scenarie: To klienter kobler sig op til VPN routeren. Disse kan via VPN
> > routerens routningsregler se hinanden. Det var den oprindelig
> > problemstilling.
>
> Det gælder alle former for VPN og routing. Er der en maskine der
> router den dekrypterede trafik imellem de forskellige net, så
> vil trafik kunne routes imellem dem. Men det må man jo bare lade
> være med så.

Det har du som kunde ingen mulighed for at kontrollere, uden at gøre
noget ulovigt, eller stole på din leverandør.

> >> Andre kunder vil naturligvis bruge en anden key,
> >
> > Faktisk ikke, det er mere undtagelsen.
>
> Der er sg* da ingen pointe i at kalde noget privat, og så give alle
> den samme nøgle.

Privat i denne sammenhæng referere til RFC1918 adresser.

Brok dig til Cisco konsulenterne. :)

> > De fleste Cisco VPN concentrator konfigurationer jeg har set er shared
> > secret identisk for grupper af brugere. De gør det meget nemmere alt
> > laver regler for denne gruppe af brugere.
>
> At Cisco-folk ikke kan finde ud af at sætte det op er da ikke et
> argument imod IPSEC.

Det er idéen bag gruppering på en Cisco VPN concentrator.

---

Den Wed, 01 Nov 2006 20:30:13 +0100 skrev Christian E. Lysel:
> On Wed, 2006-11-01 at 15:33 +0000, Kent Friis wrote:
>> Men hvis de ikke har den rigtige key kan de ikke dekryptere trafikken.
>
> Nej, det har jeg ej påstået.
>
>> > Scenarie: To klienter kobler sig op til VPN routeren. Disse kan via VPN
>> > routerens routningsregler se hinanden. Det var den oprindelig
>> > problemstilling.
>>
>> Det gælder alle former for VPN og routing. Er der en maskine der
>> router den dekrypterede trafik imellem de forskellige net, så
>> vil trafik kunne routes imellem dem. Men det må man jo bare lade
>> være med så.
>
> Det har du som kunde ingen mulighed for at kontrollere, uden at gøre
> noget ulovigt, eller stole på din leverandør.

Så må man jo anskaffe sig en troværdig leverandør.

>> >> Andre kunder vil naturligvis bruge en anden key,
>> >
>> > Faktisk ikke, det er mere undtagelsen.
>>
>> Der er sg* da ingen pointe i at kalde noget privat, og så give alle
>> den samme nøgle.
>
> Privat i denne sammenhæng referere til RFC1918 adresser.

Nævn bare en RFC hvor P'et i VPN (Virtual *Private* Network) står
for RFC1918.

> Brok dig til Cisco konsulenterne. :)

Det er sg* da ikke mig der har valgt Cisco som leverandør.

>> > De fleste Cisco VPN concentrator konfigurationer jeg har set er shared
>> > secret identisk for grupper af brugere. De gør det meget nemmere alt
>> > laver regler for denne gruppe af brugere.
>>
>> At Cisco-folk ikke kan finde ud af at sætte det op er da ikke et
>> argument imod IPSEC.
>
> Det er idéen bag gruppering på en Cisco VPN concentrator.

Det er da ikke IPSEC's skyld at Cisco er noget klamphuggere.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

On Wed, 2006-11-01 at 20:13 +0000, Kent Friis wrote:
> > Det har du som kunde ingen mulighed for at kontrollere, uden at gøre
> > noget ulovigt, eller stole på din leverandør.
>
> Så må man jo anskaffe sig en troværdig leverandør.

Ja, eller basere det på certifikater.

> >> Der er sg* da ingen pointe i at kalde noget privat, og så give alle
> >> den samme nøgle.
> >
> > Privat i denne sammenhæng referere til RFC1918 adresser.
>
> Nævn bare en RFC hvor P'et i VPN (Virtual *Private* Network) står
> for RFC1918.

Beklager, du ikke kan se usynlig ironi.

> > Brok dig til Cisco konsulenterne. :)
>
> Det er sg* da ikke mig der har valgt Cisco som leverandør.

Næ, det er blot det tråden handler om.

> Det er da ikke IPSEC's skyld at Cisco er noget klamphuggere.

Enig.

---

Den Wed, 01 Nov 2006 21:59:52 +0100 skrev Christian E. Lysel:
> On Wed, 2006-11-01 at 20:13 +0000, Kent Friis wrote:
>> > Det har du som kunde ingen mulighed for at kontrollere, uden at gøre
>> > noget ulovigt, eller stole på din leverandør.
>>
>> Så må man jo anskaffe sig en troværdig leverandør.
>
> Ja, eller basere det på certifikater.

Eh? Skulle de forhindre at der bliver routet noget på den anden
side af VPN'en?

>> >> Der er sg* da ingen pointe i at kalde noget privat, og så give alle
>> >> den samme nøgle.
>> >
>> > Privat i denne sammenhæng referere til RFC1918 adresser.
>>
>> Nævn bare en RFC hvor P'et i VPN (Virtual *Private* Network) står
>> for RFC1918.
>
> Beklager, du ikke kan se usynlig ironi.

WTF?

>> > Brok dig til Cisco konsulenterne. :)
>>
>> Det er sg* da ikke mig der har valgt Cisco som leverandør.
>
> Næ, det er blot det tråden handler om.

"VPN Koncentrator på Linux" - Jeg kan ikke lige se ordet Cisco deri.
Jeg foreslog at sætte Linux-maskinen op til at køre IPSEC, det
behøver man altså ikke have en Cisco-mand til at gøre.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

On Wed, 2006-11-01 at 21:25 +0000, Kent Friis wrote:
> >> Så må man jo anskaffe sig en troværdig leverandør.
> >
> > Ja, eller basere det på certifikater.
>
> Eh? Skulle de forhindre at der bliver routet noget på den anden
> side af VPN'en?

Næ, det forhindre Cisco concentrator problemmerne, hvis man da ikke er
så dum at bruge det samme cert til alle brugerne.

> > Beklager, du ikke kan se usynlig ironi.
>
> WTF?

Ja, da klienterne alligevel deler nøgler og kan route til hinanden, må
P'et i VPN da referere til RFC1918.....det er ironisk ment.

> > Næ, det er blot det tråden handler om.
>
> "VPN Koncentrator på Linux"

...."VPN Koncentrator er en Cisco-kasse."

> - Jeg kan ikke lige se ordet Cisco deri.
> Jeg foreslog at sætte Linux-maskinen op til at køre IPSEC,

Hvordan vil du lave det sikkert, uden at leverandøren kan bruges af en
angriber?

> det behøver man altså ikke have en Cisco-mand til at gøre.

Nej, enig.

---

Den Wed, 01 Nov 2006 23:00:31 +0100 skrev Christian E. Lysel:
> On Wed, 2006-11-01 at 21:25 +0000, Kent Friis wrote:
>> >> Så må man jo anskaffe sig en troværdig leverandør.
>> >
>> > Næ, det er blot det tråden handler om.
>>
>> "VPN Koncentrator på Linux"
>
> ..."VPN Koncentrator er en Cisco-kasse."

Ja, jeg protesterede over at han skrev VPN Koncentrator i stedet for
blot VPN, som reelt var det han spurgte om.

Men denne diskussion drejer sig om IPSEC, som jeg foreslog at installere
på både Linux og Windows-maskinen. Jeg har aldrig anbefalet Cisco til
andet end at hoppe på :-þ

>> - Jeg kan ikke lige se ordet Cisco deri.
>> Jeg foreslog at sætte Linux-maskinen op til at køre IPSEC,
>
> Hvordan vil du lave det sikkert, uden at leverandøren kan bruges af en
> angriber?

Det kan i sidste ende ikke laves mere sikkert end enhver anden løsning
- har man adgang til leverandørens system, har man lige så meget
adgang som denne har. Det gælder uanset om det er IPSEC, SSH eller
modem.

Mvh
KEnt
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

On Thu, 2006-11-02 at 16:54 +0000, Kent Friis wrote:
> Jeg har aldrig anbefalet Cisco til andet end at hoppe på :-þ

Pas på, de kan godt ødeligge et par gode sko.

> Det kan i sidste ende ikke laves mere sikkert end enhver anden løsning
> - har man adgang til leverandørens system, har man lige så meget
> adgang som denne har. Det gælder uanset om det er IPSEC, SSH eller
> modem.

Situationen ser anderledes ud ved at bruge VNC reverse connections,
istedet for at bruge IPSec:

1) Brugeren kan selv følge med i hvad der sker med sin PC.

2) Brugeren skal selv starte sin VNC server.

3) Hvis leverandøren administrere to brugere, kan disse brugere ikke
direkte se hinandens sessioner. (Man kan dog godt forstille sig et hul i
VNC, der tillader udførelse af kode på leverandørens maskine, og igennem
denne styre en anden VNC session)

---

Den Thu, 02 Nov 2006 20:47:10 +0100 skrev Christian E. Lysel:
> On Thu, 2006-11-02 at 16:54 +0000, Kent Friis wrote:
>> Jeg har aldrig anbefalet Cisco til andet end at hoppe på :-þ
>
> Pas på, de kan godt ødeligge et par gode sko.

Erfaring?

>> Det kan i sidste ende ikke laves mere sikkert end enhver anden løsning
>> - har man adgang til leverandørens system, har man lige så meget
>> adgang som denne har. Det gælder uanset om det er IPSEC, SSH eller
>> modem.
>
> Situationen ser anderledes ud ved at bruge VNC reverse connections,
> istedet for at bruge IPSec:

Jeg ser det ikke som "i stedet for". VNC bør under alle omstændigheder
pakkes ind i en VPN.

Jeg er ikke uenig i anbefalingen af reverse connections, det giver
langt mere kontrol over hvornår der kan fjernstyres, og af hvem. Så
må man jo bare sætte sin VPN-tunnel op så det kun er VNC reverse
connections der går igennem.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

On Thu, 2006-11-02 at 20:54 +0000, Kent Friis wrote:
> > Pas på, de kan godt ødeligge et par gode sko.
>
> Erfaring?

Alt er jo lavet af metal.

> Jeg ser det ikke som "i stedet for". VNC bør under alle omstændigheder
> pakkes ind i en VPN.
>
> Jeg er ikke uenig i anbefalingen af reverse connections, det giver
> langt mere kontrol over hvornår der kan fjernstyres, og af hvem. Så
> må man jo bare sætte sin VPN-tunnel op så det kun er VNC reverse
> connections der går igennem.

Nogle VNC implementationer kan godt kryptere trafikken, andre kan
suppleres.

Hvilket IPSEC setup vil du forslå, uddyb evt. med eksempler på
adresserum. Husk at nogle klienter sidder bag NAT router (nogle NAT
router kan ikke holde styr på flere end én ESP session ad gangen), andre
har officielle adresser.

Hvilken implementation vil du forslå?

Vil du bruge firewall regler til at forhindre adgang fra leverandøren
til kunderne, og til at specifiere adgangen fra kunderne til
leverandøren?

Hvordan håndtere du adresse konflikter, fx kunder der har samme adresser
som leverandøren, eller kunder det har samme adresse som andre kunder?

Hvor mange kunder kan håndtere installationen af ovenstående setup?


Jeg er ikke modstander af IPSEC, tværtimod, bruger det til al ekstern
kommunikation i min hverdag.

---

On Thu, 2006-11-02 at 23:56 +0100, Regnar Bang Lyngsø wrote:
> Det er IMHO noget fordrukkent sludder. Du kan sagtens have
> IPSec-tunneler til forskellige brugere, hvor de to brugeres maskiner
> ikke kan se hinanden.

Selvfølgelig kan man det. Listen over punkter der skal laves, er dog
lang, og det er nemt at lave fejl.

Derefter skal du passe på at leverandørens maskine ikke kan bruges som
proxy ud til andre kunder.

> Du kan med Ciscos udstyr via TACACS eller RADIUS skyde access-lister ud
> på den enkelte IPSec-tunnel afhængig af, hvilken bruger der logger på.

Ja, det understøtter de fleste producente, på hver deres måde.

> Hvis du stoler på din leverandør vil du også stole på at han kan smide
> de rette access-lister på sine IPSec tunneler og på sit netværksudstyr
> bag VPN-koncentratoren. Se fx

I tilfældet med en leverandør der har brug for at administratere en
server, er det typisk fordi leverandøren har udviklet en applikation.

Jeg stoler pr. default ikke på applikation udviklers viden omkring
netværk og sikkerhed, ej på de krav de stiller til deres
sikkerhedsleverandør. De flest har problemmer nok med at sikre deres
egne applikationer.

> Det du vinder ved VNC-løsningen er naturligvis, at du kan følge med i
> hvad leverandøren laver. Spørgsmålet er om du har lyst til det?

Personligt, ja. Jeg vil gerne lære hvorfor det ikke virkede.

> For mig
> at se handler leverandørers adgang til udstyr utroligt meget om tillid
> og aftaler. Ulempen ved VNC-løsningen er som jeg ser det, at det kræver
> at leverandør har en port åbent ud på internettet og det vil sige noget
> i retning af en VNC listening host i leverandørs DMZ, hvor leverandør
> fra indersiden (leverandør LAN) kan fjernstyre denne host som så kører
> VNC listening host (ud mod internet).

Tid udgøre en faktor du ikke nævner:

Leverandøren skal aktivt starte én listner, som lytter indtil der
kommer en klient, herefter er der ikke mere nogen listner.

> Derudover er VNC i udgangspunktet
> ikke krypteret (jeg er klar over at der er encryption plugins til visse
> versioner af VNC og at du kan lave tunnel over SSH - ifht. det sidste
> synes jeg IPSec er mere elegant).

Elegant...giver IPsec ingen problemmer?

Kan alle kunder, uden lige installere/konfigurer IPsec?

> I den specifikke situation, hvor det handler om at fjernstyre nogle
> PC'ere bag et fremmed netværk giver VNC god mening. Det skal lige sikres
> at det er i tråd med kundens sikkerhedspolitik. Jeg var meget tæt ved at
> flå hovedet af en konsulent, som installerede GoToMyPC på en host han
> fysisk havde adgang til i forbindelse med et projekt hos os.

Hvilket ikke er unormalt...nogle gange ser man brugere starte et sådan
program. Nogle programmer skal ikke engang installeres.

---

On Fri, 2006-11-03 at 01:42 +0100, Regnar Bang Lyngsø wrote:
> > Selvfølgelig kan man det. Listen over punkter der skal laves, er dog
> > lang, og det er nemt at lave fejl.
>
> Der er jeg absolut uenig. I et af de setups jeg vedligeholder skal du
> skal tildele en access-liste - og da default er deny any - så er det
> ikke mange punkter. Du skal oprette brugeren - og smide ham i den
> rigtige gruppe. På baggrund af hans gruppemedlemsskab får han kylet
> access-lister i hovedet. Nogle gange skal der oprettes nye
> grupper/ACL'er - men hånden på hjertet - det er ikke det mest
> komplicerede i denne verden. ACL'erne indeholder typisk 2-3 linier.

Det er nemt at være uenig, når man har et setup.

Forstil dig du intet har og gerne vil lave et setup...kan du i listeform
gennemgå hvad der skal laves?

> > Derefter skal du passe på at leverandørens maskine ikke kan bruges som
> > proxy ud til andre kunder.
>
> Der er åbnet for at leverandør kan åbne sessioner mod port 5900 hos
> kunde. Kunde kan ikke åbne sessioner mod noget som helst - jeg ser ikke
> hvor risikoen er.

Det lyder som en ordenligt løsning. Hvordan er du som kunde sikker på
ovenstående er tilfældet?

> > Jeg stoler pr. default ikke på applikation udviklers viden omkring
> > netværk og sikkerhed, ej på de krav de stiller til deres
> > sikkerhedsleverandør. De flest har problemmer nok med at sikre deres
> > egne applikationer.
>
> Ok - vi snakker vidst om organisationer af forskellig størrelse. Jeg
> forventer ikke at applikationsudvikleren konfigurerer netværksudstyr -
> med mindre han ved hvad han gør.

Vi har bunker af leverandører der har brug for adgang til vores anlæg:

o time planlægningssytemm.
o lønsystemmer, for hvert land.
o system til håndterminaler på et lager.
o en sorter på et lager
o nogle MAN kraner.
o et overordnet kran anlæg
o faktura indscanning
o telefon server
o alarm system
o kasse systemmer
o butiksserver applikationer
o Nogle Oracle databaser
o ectetera.

Leverandørende er selvfølgelig af forskellige størrelse og
ekspertise...nogle aner ikke hvad IPsec er, andre sætter krav til
redundante IPsed konfigurationer.


1/3 på ovenstående liste, fortrækker at køre RDP mod en offentlig
IP!!!!!

Nogle leverandør har slet ikke adgang, og må køre forbi.


> Ohh ja - i support-situationen er jeg helt enig med dig. I situationen
> hvor du har outsourcet driften/supporten af noget grej til en leverandør
> er jeg græsk-katolsk. Jeg gider fx ikke sidde at glo på at en eller
> anden fyr retter nogle bugs i en eller anden Access-database i et
> system, som jeg ikke skal pille ved i dagligdagen.

Du er ikke tvangsindlagt til at følge med :)

> > Tid udgøre en faktor du ikke nævner:
>
> Det er vidst et holdningsspørgsmål. Jeg bryder mig ikke om at have
> inside-hosts åbne for ikke-autentificerede forbindelser initieret udefra
> - uanset om det så bare er et kvarter. Som du ikke har tillid til at
> folk kan finde ud af at konfigurere access-lister har jeg ikke tillid
> til at folk husker at lukke deres programmer.

Det er ikke noget holdningsspørgsmål. Du kan ikke have mere end én
session til en listner...andet er ikke muligt.

> > Elegant...giver IPsec ingen problemmer?
> >
> > Kan alle kunder, uden lige installere/konfigurer IPsec?
>
> Jeg tror at de fleste folk har nemmere ved at bruge og installere en VPN
> klient end de har ved at bruge SSH. Ifht. encryption plugins foretrækker
> jeg ikke IPSec.
>
> De fleste IT-mongoler kan installere en VPN-klient. De får en CD med en
> installationspakke og en profil.


Det var et eksempel på et problem, der er flere problemmer:

o Adresserums overlap

o NAT routere der ikke håndtere ESP

o Firewallregler der ikke tillader IPsec.

o Manglende administrator rettigheder.

o Konflikt med andet VPN software.

> Som sagt - jeg er fuldstændig enig med dig i at i den givne
> problemstilling er VNC listener den rigtige(tm) løsning, hvis det laves
> rigtigt - kryptering er IMHO et minimumskrav. Afhængig af leverandørs
> sikkerhedsnoia kan man vælge at smide listenermaskine i DMZ.

Eller en strippet maskine på Internet hvis det skal være rigtigt
simpelt.

> Jeg fik bare det indtryk af dine posts, at du mente, at det er
> supersvært at beskytte IPsec-brugere VPN-klienter mod hinanden. Det er
> jeg inderligt uenig i. Hvis folk har svært ved det, er det fordi de er
> inkompetente eller ikke ser det som et issue.

Det er svært at sætte et VPN miljø, når man sammenligner med VNC
løsningen.

> Valget mellem VNC og VPN afhænger for mig at se bl.a. af:
>
> - eksisterende setup (hvis man har en VPN koncentrator-dims - fx en
> Cisco VPN/PIX/ASA/IOS-boks - så er det ikke meget ekstraarbejde der skal
> til).

Enig.

> - hvad vej vender problematikken - hvor sidder netværkskompetencen - I
> vores tilfælde er vi tit kunden - og leverandøren har alt muligt
> mærkeligt han vil have adgang til - nogle gange VNC - andre gange
> Windows Remote Desktop (VNC er bare mindre effektivt på Windows trods
> driver hookup) - andre gange en webservice på noget embedded hardware
> han har stående. Derfor er IPSec for os den mindst
> vedligeholdelseskrævende løsning. Det er klart at der kan være en risiko
> forbundet med det - og derfor skal man stole på sin leverandør og have
> klare aftaler med ham om hvad han må bruge forbindelsen til. Du kan
> styre pakkerne - men du kan ikke i samme grad styre om han laver angreb
> fra den maskine han har adgang til.

Enig, jeg bruger da også selv IPsec, der hvor jeg kan "tvinge"
leverandøren til det.

> Leverandøren er ofte ikke
> netærkskyndig og sidder bag en firewall - så derfor har han ikke lige
> adgang til en offentlig IP-adresse han kan sætte sin listener til at
> lytte på.

Hvad koster en ekstra ADSL linie, eller blot en ekstra IP?