---

Hej NG

Jeg sidder som administrator på et lille netværk med en filserver og en
Exchange/Terminal server - begge er Win 2K.

Vi har 5-10 afdelinger/medarbejdere rundt om i Europa der kan arbejde via
VPN, hvor der står en Firewall i begge ender og vi kræver normalt fast
ipadresse - så har vi lidt styr på hvem det er der kommer igennem til vores
servere.

Men nu kommer der et pres, for at en/flere medarbejdere skal kunne koble
deres bærbare på nettet hvorsomhelst i verden og derefter have adgang på
lige fod med dem som har fast IP.

Det er ikke noget teknisk problem - vi kan åbne i vores Firewall at man ikke
skal have fast IP-adresse for at komme på VPN og vi har en software
VPN-klient og det virker såmænd OK.

Men jeg er lidt utryg ved at opgive den sikkerhed der ligger i at kræve fast
IP.

Der er 2 løsninger, som jeg ser det:

1. Accepter ovenstående uden fast IP
2. Lave en anden teknisk løsning, så disse medarbejdere har adgang til de
dokumenter de måtte ønske - når de måtte ønske det via nettet, men ikke
adgang til hele serveren.

1'eren er selvfølgelig den letteste, men jeg ville foretrække 2'eren, da jeg
så kan "styre" hvad der ligger på den anden (og usikre) side af min firewall
og hvad der kræver fast IP.

Men findes der nogle løsninger der ville kunne opfylde mine paranoia
lignende tendenser mht sikkerhed ?? Eller er jeg bare gået i selvsving her
???


Jan V.

---

Jan V. wrote:
> Men jeg er lidt utryg ved at opgive den sikkerhed der ligger i at kræve fast
> IP.
>
> Der er 2 løsninger, som jeg ser det:
>
> 1. Accepter ovenstående uden fast IP

Nu går jeg da ud fra at jeres VPN er IPsec. Så ligger sikkerheden jo i
de certifikater der er installeret i begge ender. Det faste IP giver da
en hvis tryghedsfornemmelse, men det er ikke det du skal lægge din tillid i.
Jeg ville være langt mere nervøs for at din nøgler kompromiteres. Det
har de selvfølgelig lettere ved at blive på en laptop, hvis brugeren
ikke passer ordentligt på dem - og i det tilfælde er det faste IP da en
rar ting at have. (afhængig af hvem, der stjæler nøglerne)
Du kunne evt. oprette et selvstændigt VPN til den ene maskine som du kan
lukke uden at gerere dine andre brugere, hvis det kompromiteres.

> 2. Lave en anden teknisk løsning, så disse medarbejdere har adgang til de
> dokumenter de måtte ønske - når de måtte ønske det via nettet, men ikke
> adgang til hele serveren.

Det er jo altid fornuftigt ikke at give adgang til mere end der er brug for.

> Men findes der nogle løsninger der ville kunne opfylde mine paranoia
> lignende tendenser mht sikkerhed ?? Eller er jeg bare gået i selvsving her
> ???

Det er jo altid et problem. Tilsvarende hvis du opretter en SSH-tunnel
og du ved at den kun kommer fra et IP, så bør man da også kun lytte på
port 22 efter pakker fra det IP.

Det du bør gøre er at stille krav til integriteten af den laptop, der
roder rundt i verden. Sørg for at den ikke kan anvende VPN'et uden den
rigtige brugeres tilladelse. Instruer ham i sikkerheden omkring det.
(lad være med at efterlade den når den er på VPN, skriv ikke passwords
på post-it o.s.v.).

Peter

---

"Peter Mogensen" <apm-at-mutex-dot-dk@nospam.no> skrev i en meddelelse
news:pSScb.38$tM2.28@news.get2net.dk...
> Jan V. wrote:
> > Men jeg er lidt utryg ved at opgive den sikkerhed der ligger i at kræve
fast
> > IP.
> >
> > Der er 2 løsninger, som jeg ser det:
> >
> > 1. Accepter ovenstående uden fast IP
>
> Nu går jeg da ud fra at jeres VPN er IPsec. Så ligger sikkerheden jo i
> de certifikater der er installeret i begge ender. Det faste IP giver da
> en hvis tryghedsfornemmelse, men det er ikke det du skal lægge din tillid
i.
> Jeg ville være langt mere nervøs for at din nøgler kompromiteres. Det
> har de selvfølgelig lettere ved at blive på en laptop, hvis brugeren
> ikke passer ordentligt på dem - og i det tilfælde er det faste IP da en
> rar ting at have. (afhængig af hvem, der stjæler nøglerne)
> Du kunne evt. oprette et selvstændigt VPN til den ene maskine som du kan
> lukke uden at gerere dine andre brugere, hvis det kompromiteres.
>
> > 2. Lave en anden teknisk løsning, så disse medarbejdere har adgang til
de
> > dokumenter de måtte ønske - når de måtte ønske det via nettet, men ikke
> > adgang til hele serveren.
>
> Det er jo altid fornuftigt ikke at give adgang til mere end der er brug
for.
>
> > Men findes der nogle løsninger der ville kunne opfylde mine paranoia
> > lignende tendenser mht sikkerhed ?? Eller er jeg bare gået i selvsving
her
> > ???
>
> Det er jo altid et problem. Tilsvarende hvis du opretter en SSH-tunnel
> og du ved at den kun kommer fra et IP, så bør man da også kun lytte på
> port 22 efter pakker fra det IP.
>
> Det du bør gøre er at stille krav til integriteten af den laptop, der
> roder rundt i verden. Sørg for at den ikke kan anvende VPN'et uden den
> rigtige brugeres tilladelse. Instruer ham i sikkerheden omkring det.
> (lad være med at efterlade den når den er på VPN, skriv ikke passwords
> på post-it o.s.v.).
>
> Peter
>
Ovenstående er såmænd dækket af pkt 1, idet det er sådan det bliver kørt.

Men jeg kunne forestille mig 2 ting:

1. Den bærbare bliver stjålet
2. HvemSomHelst (TM) trænger igennem, da jeg ikke har lukket i min Firewall

Jeg ved ikke hvilke af punkterne jeg er mest bange for - det kan jo også
være min paranoia, men hvis man kommer uatoriseret igennem, står vores
server vidt åben og man har fuldt adgang til alle vores data - og det er
den, som jeg er mest bange for.

Jan V.

---

In article <3f73fd81$0$54814$edfadb0f@dread11.news.tele.dk>, Jan V. wrote:
> 1. Den bærbare bliver stjålet
> 2. HvemSomHelst (TM) trænger igennem, da jeg ikke har lukket i min Firewall

Brugervalidering af VPN forbindelsen?

Nogle VPN klienter er dog så "venlige" at
de gemmer brugerens validering..

---

> Men findes der nogle løsninger der ville kunne opfylde mine paranoia
> lignende tendenser mht sikkerhed ?? Eller er jeg bare gået i selvsving her
> ???
>
> Jan V.


Vi har en Watchguard som Firewall på netværket, og så kører vi >SafeNet
SoftRemote VPN Client< på de maskiner ude i byen, der skal have adgang til
netværket. Og det virker fint ( og sikkert !?! ). Maskinerne ude i byen
behøver ikke have fast IP.

Sten L.

---

"Steen Larsen (4040)" <sl@mboks301.get2net.dk> skrev i en meddelelse
news:3f73fab3$0$48913$edfadb0f@dtext02.news.tele.dk...
> > Men findes der nogle løsninger der ville kunne opfylde mine paranoia
> > lignende tendenser mht sikkerhed ?? Eller er jeg bare gået i selvsving
her
> > ???
> >
> > Jan V.
>
>
> Vi har en Watchguard som Firewall på netværket, og så kører vi >SafeNet
> SoftRemote VPN Client< på de maskiner ude i byen, der skal have adgang til
> netværket. Og det virker fint ( og sikkert !?! ). Maskinerne ude i byen
> behøver ikke have fast IP.
>
> Sten L.
>
Samme setup som der køres lige nu, hvor der ikke kræves fast IP adresse -
men er det SikkertNok (TM) ??

Jan V.

---

In article <3f73fde3$0$54813$edfadb0f@dread11.news.tele.dk>, Jan V. wrote:
> Samme setup som der køres lige nu, hvor der ikke kræves fast IP adresse -
> men er det SikkertNok (TM) ??

At baseret sin sikkerhed på IP er ikke blot dumt, det er også
naivt.

IPSEC hvis det er sat rigtigt op er meget mere sikkert end IP adresser!

Dine problemmer ligger typisk i dårligt implementeret VPN klienter.
Nogle gemmer oplysninger om netværks topologien og brugernavn
og password til VPN løsningen.

Dog kan de fleste løsninger konfigureres til at afvise brugere der cacher sine
oplysninger lokalt...eller også kan man bruger stærk brugervalidering, et
eksempel kan være http://www.cryptocard.com/ .

---

"Christian E. Lysel" <news.sunsite.dk@spindelnet.dk> skrev i en meddelelse
news:slrnbn829g.i6u.chel@weebo.dmz.spindelnet.dk...
> In article <3f73fde3$0$54813$edfadb0f@dread11.news.tele.dk>, Jan V. wrote:
> > Samme setup som der køres lige nu, hvor der ikke kræves fast IP
adresse -
> > men er det SikkertNok (TM) ??
>
> At baseret sin sikkerhed på IP er ikke blot dumt, det er også
> naivt.
>
> IPSEC hvis det er sat rigtigt op er meget mere sikkert end IP adresser!
>
> Dine problemmer ligger typisk i dårligt implementeret VPN klienter.
> Nogle gemmer oplysninger om netværks topologien og brugernavn
> og password til VPN løsningen.
>
> Dog kan de fleste løsninger konfigureres til at afvise brugere der cacher
sine
> oplysninger lokalt...eller også kan man bruger stærk brugervalidering, et
> eksempel kan være http://www.cryptocard.com/ .
>
Hov

Jeg HAR IPSec med - men bare med IP som ekstra sikkerhed. Men det var bare
om jeg kunne undvære IP'delen.

Jan

---

"Christian E. Lysel" <news.sunsite.dk@spindelnet.dk> wrote in message
news:slrnbn829g.i6u.chel@weebo.dmz.spindelnet.dk...
> In article <3f73fde3$0$54813$edfadb0f@dread11.news.tele.dk>, Jan V.
wrote:
> > Samme setup som der køres lige nu, hvor der ikke kræves fast IP
adresse -
> > men er det SikkertNok (TM) ??
>
> At baseret sin sikkerhed på IP er ikke blot dumt, det er også
> naivt.
>
> IPSEC hvis det er sat rigtigt op er meget mere sikkert end IP
adresser!
>
> Dine problemmer ligger typisk i dårligt implementeret VPN klienter.
> Nogle gemmer oplysninger om netværks topologien og brugernavn
> og password til VPN løsningen.
>
> Dog kan de fleste løsninger konfigureres til at afvise brugere der
cacher sine
> oplysninger lokalt...eller også kan man bruger stærk brugervalidering,
et
> eksempel kan være http://www.cryptocard.com/ .
>

Mon ikke det snarere drejer sig om penge ??

Det sidste sted jeg var havde vi 3 hoved noder med Cisco PIX/VPN3000/ACE
Server (128bit IPSec, trianguleret fail-over, US, EU, AP) og VPN
klienter på laptops skulle bruge SecureID nøgler udenfor huset... Puha -
prøv at få 128 bit udstyr ind i Kina..

Det virker - men det koster !!

Men.. man må ikke lægge sin SecureID nøgle til venstre på tastaturet
foran skærmen på en IBM laptop, det dør nøglen af og så er man f**ked..


-- Søren R

---

> Det sidste sted jeg var havde vi 3 hoved noder med Cisco PIX/VPN3000/ACE
>
> Det virker - men det koster !!

VPN3000 klienten kunne da jeg rodede med det (1 år siden) godt
lide at gemme sin konfiguration i klartekst på klient maskinerne,
der derefter kunne udlevere filen via en eller flere fejl i Internet
Explorer.

I de mest slemme tilfælde stod alt i filen, godt nok ikke i klar tekst,
men ved at kopiere filen over på en anden klient kunne man få VPN forbindelse.

Endvidere har jeg ikke fundet noget dokumentation for deres brugerbegreb, som
ligende en kreativ implementering af shared secret.

> Men.. man må ikke lægge sin SecureID nøgle til venstre på tastaturet
> foran skærmen på en IBM laptop, det dør nøglen af og så er man f**ked..

Gå ind i en telebutik, her benyttes SecureID til Sonofon og Orange...
gæt hvor nøglen typisk sidder....i de butikker jeg har været har de været
påmonteret til skærmen medarbejderen brugere til at oprette kunder *suk*

---

"Christian E. Lysel" <news.sunsite.dk@spindelnet.dk> wrote in message
news:slrnbn8k9v.463.chel@weebo.dmz.spindelnet.dk...
[SNIP]
>
> I de mest slemme tilfælde stod alt i filen, godt nok ikke i klar
tekst,
> men ved at kopiere filen over på en anden klient kunne man få VPN
forbindelse.
>

Så skal du da også have nøglen (Token) for at lukke den op da koden kun
gælder i 1 minut.

Og det er selvfølgelig fyringsgrund at opbevare sin Token i
computertasken..

-- Søren R.

---

In article <3f745cde$0$13258$edfadb0f@dread15.news.tele.dk>, Soren Rathje wrote:
> Så skal du da også have nøglen (Token) for at lukke den op da koden kun
> gælder i 1 minut.

I har købt en nøgle, en producent selv har programmeret, med
en algorime der er "hemlig"..Ergo skal i stole på at
producenten ikke afslører nøglen, eller at algoritmen er sikker.

På nøglen står hvilken seriel nummer det er.

Jeg gætter på at RSA kan producere koden til en hvilken som
helst tid, hvis de har lyst, sålænge de får seriel nummeret oplyst.

(Hmmm, det er måske ikke svært at se min holdning til RSA?)


Cryptocard, giver administratoren muligheden for selv at programmere
sine token. Algoritmen er almindelig kendt, ANSI X.9.
Denne standard har da også sine svagheder og skal konfigureres rigtigt,
før det er sikkert, hvilket forresten også er tilfældet med IPSEC.

> Og det er selvfølgelig fyringsgrund at opbevare sin Token i
> computertasken..

Mange glemmer at teste eller undersøge, om det svar som toket
generere sendes i klartekst, eller er beskyttet.

Er det første tilfældet, er det kun til skade, fordi ledelsen tror
det er sikkert selvom det ikke er tilfældet.

---

"Christian E. Lysel" <news.sunsite.dk@spindelnet.dk> wrote in message
news:slrnbn97j1.4r3.chel@weebo.dmz.spindelnet.dk...
> In article <3f745cde$0$13258$edfadb0f@dread15.news.tele.dk>, Soren
Rathje wrote:
> > Så skal du da også have nøglen (Token) for at lukke den op da koden
kun
> > gælder i 1 minut.
>
> I har købt en nøgle, en producent selv har programmeret, med
> en algorime der er "hemlig"..Ergo skal i stole på at
> producenten ikke afslører nøglen, eller at algoritmen er sikker.
>
> På nøglen står hvilken seriel nummer det er.
>
> Jeg gætter på at RSA kan producere koden til en hvilken som
> helst tid, hvis de har lyst, sålænge de får seriel nummeret oplyst.
>
> (Hmmm, det er måske ikke svært at se min holdning til RSA?)
>

Point taken... Gælder det ikke alting med sikkerhedskoder, leverandøren
kan jo altid lægge en bagdør ind for alle tilfældes skyld...

Typisk er det jo aldrig sikkerhedssystemerne der fejler, men personerne
som bruger det...

-- Søren R.

---

In article <3f757b15$0$13226$edfadb0f@dread15.news.tele.dk>, Soren Rathje wrote:
> Point taken... Gælder det ikke alting med sikkerhedskoder, leverandøren
> kan jo altid lægge en bagdør ind for alle tilfældes skyld...

Selvfølgelig, men at producenten både kender koden og kan implementere
en bagdør er dårligere end at producenten "kun" implementere en bagdør.

Er man bange for bagdøre, kan man evt. bruge Cryptocards tokens, og OpenBSD's
cryptoadm. http://www.openbsd.org/cgi-bin/man.cgi?query=cryptoadm

Symantecs Enterprise Firewall (Raptor), understøtter også
cryptocard uden en cryptocard server.

> Typisk er det jo aldrig sikkerhedssystemerne der fejler, men personerne
> som bruger det...

En stærk brugervalidering der bliver sendt i klartekst er også nemt at
udnytte! Også selvom valideringen er tidsbegrænset og genereret af et token.

---

"Christian E. Lysel" <news.sunsite.dk@spindelnet.dk> wrote in message
news:slrnbndirj.bvj.chel@weebo.dmz.spindelnet.dk...
>
> En stærk brugervalidering der bliver sendt i klartekst er også nemt at
> udnytte! Også selvom valideringen er tidsbegrænset og genereret af et
token.
>

Det kommer vel også an på hvor hemmelig ens information er.. Ikke alt
behøver en beskyttelse som er PET/MET/NSA/CIA/FBI klassificeret... Mange
gange er det nok at sørge for at det tager meget lang tid at bryde
igennem... Selvfølgelig har man IDS systemer som advarer de rette
personer i tide...

-- Søren R.

---

In article <3f76ea92$0$13221$edfadb0f@dread15.news.tele.dk>, Soren Rathje wrote:
>> En stærk brugervalidering der bliver sendt i klartekst er også nemt at
>> udnytte! Også selvom valideringen er tidsbegrænset og genereret af et
> token.

> Det kommer vel også an på hvor hemmelig ens information er.. Ikke alt
> behøver en beskyttelse som er PET/MET/NSA/CIA/FBI klassificeret... Mange

Hvilket typisk er fysisk beskyttelse...hvis data transmitteres over usikre
forbindelser er det nok data der kan fåes igennem offentlige kanaler.

> gange er det nok at sørge for at det tager meget lang tid at bryde
> igennem... Selvfølgelig har man IDS systemer som advarer de rette

Hvis valideringen sendes i klartekst, vil det tage under 1 sek. at
validere sig som brugeren.

> personer i tide...

Hvordan beskytte et IDS system imod at en brugers validering
er komprimiteret?

Sikke noget vrøvl, hvem ville dog bruge kassen på fx SecureID og således
få en to faktor brugervalidering, men vil være ligeglad med resten af
problemerne ved brugervalideringen?

Det skal dog siges at mange ligger i ovenstående gruppe, og jeg har
tit set kunder sidde med løsninger de har brugt mange penge på, som
havde fundamentale sikkerhedsproblemmer.

Min pointe var blot at man skal tænke sig om, undlader man dette
kan selv en stor pengepung ikke hjælpe.

---

"Christian E. Lysel" <news.sunsite.dk@spindelnet.dk> skrev i en meddelelse
news:slrnbn829g.i6u.chel@weebo.dmz.spindelnet.dk...
> In article <3f73fde3$0$54813$edfadb0f@dread11.news.tele.dk>, Jan V. wrote:
> > Samme setup som der køres lige nu, hvor der ikke kræves fast IP
adresse -
> > men er det SikkertNok (TM) ??
>
> At baseret sin sikkerhed på IP er ikke blot dumt, det er også
> naivt.
>
> IPSEC hvis det er sat rigtigt op er meget mere sikkert end IP adresser!
>
> Dine problemmer ligger typisk i dårligt implementeret VPN klienter.
> Nogle gemmer oplysninger om netværks topologien og brugernavn
> og password til VPN løsningen.
>
> Dog kan de fleste løsninger konfigureres til at afvise brugere der cacher
sine
> oplysninger lokalt...eller også kan man bruger stærk brugervalidering, et
> eksempel kan være http://www.cryptocard.com/ .
>
Men ellers ser http://www.cryptocard.com/ spændende ud - det var noget i den
retning jeg leder efter, manglede blot at blive peget i den rigtige retning.

Jan V.