/ Forside / Teknologi / Internet / Sikkerhed / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
Sikkerhed
#NavnPoint
stl_s 37026
arlet 26827
miritdk 20260
o.v.n. 12167
als 8951
refi 8694
tedd 8272
BjarneD 7338
Klaudi 7257
10  molokyle 6481
TDC bredbånd og manglende sikkerhed
Fra : Stig Holmberg


Dato : 24-12-01 02:10

Hej NG

Jeg har sat et netværk op med TDC BredBånd, ADSL forbindelse, 4 dynamiske ip
adresser, 1 Unex switch, 4 pc´er.

Alle maskinerne kan gå på nettet og se hinanden, problemet er at der slet
ingen sikkerhed er ifølge bl.a. www.grc.com

Hvis jeg sætter Norton Internet Serurity´s firewall op kan maskinerne ikke
se hinanden mere.

Hvad gør man?, humlen i det er at i firewall´en kan man definere "thrusted
adresses" og har her mulighed for at indtaste ip numre på de andre maskiner
i netværket, men da disse jo er dynamiske vil det kun virke indtil de ændrer
sig!

Hvis man forsøger at indtaste faste adresser på TDC´s dns-servere og gateway
og "interne" ip-numre på netværket i 168. rækken så virker det slet ikke.

Nogen der har en løsning?

Mvh. Stig




 
 
Alex Holst (24-12-2001)
Kommentar
Fra : Alex Holst


Dato : 24-12-01 02:49

Stig Holmberg <stig-holmberg@tdcadsl.dk> wrote:
> Jeg har sat et netværk op med TDC BredBånd, ADSL forbindelse, 4 dynamiske
> ip adresser, 1 Unex switch, 4 pc´er.

Disse 4 PCere skal bruges som workstations? Du skriver ikke hvilket OS de
koerer, men soerg for at de ikke koere nogle services mod netvaerket. Adskil
servere og workstations.

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.area51.dk/


Christian E. Lysel (24-12-2001)
Kommentar
Fra : Christian E. Lysel


Dato : 24-12-01 12:59

Alex Holst wrote:

> Stig Holmberg <stig-holmberg@tdcadsl.dk> wrote:
>
>>Jeg har sat et netværk op med TDC BredBånd, ADSL forbindelse, 4 dynamiske
>>ip adresser, 1 Unex switch, 4 pc´er.
>>
>
> Disse 4 PCere skal bruges som workstations? Du skriver ikke hvilket OS de
> koerer, men soerg for at de ikke koere nogle services mod netvaerket. Adskil
> servere og workstations.


Enventuelt kan du disable alle TCP/IP services, og kører det hele i IPX
protokollen.

IPX protokollen kan ikke routes til Internet.


Stig Holmberg (24-12-2001)
Kommentar
Fra : Stig Holmberg


Dato : 24-12-01 14:48


"Alex Holst" <a@area51.dk> wrote

> Disse 4 PCere skal bruges som workstations? Du skriver ikke hvilket OS de
> koerer, men soerg for at de ikke koere nogle services mod netvaerket.
Adskil
> servere og workstations.

Hej

De kører win 98 SE, alle 4 som workstations, der er ingen lokal server, alle
får deres ip-numre fra TDC´s dhcp server, der bliver kørt fil- og
printerdeling på netværket. Nogle foreslår at installere Netbeui-protokollen
og binde disse services til den i stedet for, lyder fornuftigt, men der
burde findes en fiksere løsning.

Mvh. Stig



cerberus (24-12-2001)
Kommentar
Fra : cerberus


Dato : 24-12-01 11:11

Du skal bruge computernes interne ip, som du selv kan definere, enten ved
168. osv eller 10.osv.
Prøv evt. tdc hjemmeside, der er helt sikkert hjælp at hente.

"Stig Holmberg" <stig-holmberg@tdcadsl.dk> skrev i en meddelelse
news:3c268074$0$89114$edfadb0f@dspool01.news.tele.dk...
> Hej NG
>
> Jeg har sat et netværk op med TDC BredBånd, ADSL forbindelse, 4 dynamiske
ip
> adresser, 1 Unex switch, 4 pc´er.
>
> Alle maskinerne kan gå på nettet og se hinanden, problemet er at der slet
> ingen sikkerhed er ifølge bl.a. www.grc.com
>
> Hvis jeg sætter Norton Internet Serurity´s firewall op kan maskinerne ikke
> se hinanden mere.
>
> Hvad gør man?, humlen i det er at i firewall´en kan man definere "thrusted
> adresses" og har her mulighed for at indtaste ip numre på de andre
maskiner
> i netværket, men da disse jo er dynamiske vil det kun virke indtil de
ændrer
> sig!
>
> Hvis man forsøger at indtaste faste adresser på TDC´s dns-servere og
gateway
> og "interne" ip-numre på netværket i 168. rækken så virker det slet ikke.
>
> Nogen der har en løsning?
>
> Mvh. Stig
>
>
>



Stig Holmberg (24-12-2001)
Kommentar
Fra : Stig Holmberg


Dato : 24-12-01 14:51


"cerberus" <hr_overgeneral@hotmail.com> wrote

> Du skal bruge computernes interne ip, som du selv kan definere, enten ved
> 168. osv eller 10.osv.
> Prøv evt. tdc hjemmeside, der er helt sikkert hjælp at hente.

Hej

Det har jeg prøvet, og det virker ikke, maskiner skal have deres ip-numre
fra tdc´s dhcp server (og det er wan-numre) ellers er der intet der virker.

Mvh. Stig



Kasper Dupont (24-12-2001)
Kommentar
Fra : Kasper Dupont


Dato : 24-12-01 13:22

Stig Holmberg wrote:
>
> Hej NG
>
> Jeg har sat et netværk op med TDC BredBånd, ADSL forbindelse, 4 dynamiske ip
> adresser, 1 Unex switch, 4 pc´er.
>
> Alle maskinerne kan gå på nettet og se hinanden, problemet er at der slet
> ingen sikkerhed er ifølge bl.a. www.grc.com
>
> Hvis jeg sætter Norton Internet Serurity´s firewall op kan maskinerne ikke
> se hinanden mere.
>
> Hvad gør man?, humlen i det er at i firewall´en kan man definere "thrusted
> adresses" og har her mulighed for at indtaste ip numre på de andre maskiner
> i netværket, men da disse jo er dynamiske vil det kun virke indtil de ændrer
> sig!
>
> Hvis man forsøger at indtaste faste adresser på TDC´s dns-servere og gateway
> og "interne" ip-numre på netværket i 168. rækken så virker det slet ikke.
>
> Nogen der har en løsning?
>
> Mvh. Stig

Prøv at skitsere hvordan dit netværk ser ud. Jeg forestiller mig,
at det ser sådan ud, men jeg kan tage fejl:

+-------------+
| Gateway |
| DHCP server |
+------+------+
|
+----------+---------+----------+
| | | |
+-+----+-+ +-+----+-+ +-+----+-+ +-+----+-+
| | FW | | | | FW | | | | FW | | | | FW | |
| +----+ | | +----+ | | +----+ | | +----+ |
| PC 1 | | PC 2 | | PC 3 | | PC 4 |
+--------+ +--------+ +--------+ +--------+

Problemet i denne opsætning er at hver maskine har sin egen firewall.
Det ville være bedre med en firewall foran netværket og en mere
begrænset eller måske slet ingen firewall på de enkelte maskiner.
Denne løsning skaber dog problemer idet du får brug for flere IP
addresser, og dine maskiner kan ikke direkte nå DHCP serveren.

Jeg formoder at du har overvejet NAT og beslutet dig for, at du
ikke kan leve med en NAT løsning.

Hvis du kan stole på at din gateway ikke spoofer MAC addresser kan
du sætte firewallen på hver maskine til at genkende de andre MAC
addresser på lokalnettet. (Ikke alle firewalls kan filtrere på MAC
addresser, men hvis det er det du har brug for, skal du finde en
firewall der kan.)

Hvis du ikke kan stole på din gateway, er du nødt til at gøre
noget andet. Du vil i dette tilfælde være nødt til enten at sætte
en firewall imellem gateway og lokalnet eller bruger VPN til
kommunikationen mellem maskinerne.

--
Kasper Dupont

Stig Holmberg (24-12-2001)
Kommentar
Fra : Stig Holmberg


Dato : 24-12-01 15:00


"Kasper Dupont" <kasperd@daimi.au.dk> wrote> >

> Prøv at skitsere hvordan dit netværk ser ud. Jeg forestiller mig,
> at det ser sådan ud, men jeg kan tage fejl:
>
> +-------------+
> | Gateway |
> | DHCP server |
> +------+------+
> |
> +----------+---------+----------+
> | | | |
> +-+----+-+ +-+----+-+ +-+----+-+ +-+----+-+
> | | FW | | | | FW | | | | FW | | | | FW | |
> | +----+ | | +----+ | | +----+ | | +----+ |
> | PC 1 | | PC 2 | | PC 3 | | PC 4 |
> +--------+ +--------+ +--------+ +--------+
>
> Problemet i denne opsætning er at hver maskine har sin egen firewall.
> Det ville være bedre med en firewall foran netværket og en mere
> begrænset eller måske slet ingen firewall på de enkelte maskiner.
> Denne løsning skaber dog problemer idet du får brug for flere IP
> addresser, og dine maskiner kan ikke direkte nå DHCP serveren.
>
> Jeg formoder at du har overvejet NAT og beslutet dig for, at du
> ikke kan leve med en NAT løsning.
>
> Hvis du kan stole på at din gateway ikke spoofer MAC addresser kan
> du sætte firewallen på hver maskine til at genkende de andre MAC
> addresser på lokalnettet. (Ikke alle firewalls kan filtrere på MAC
> addresser, men hvis det er det du har brug for, skal du finde en
> firewall der kan.)
>
> Hvis du ikke kan stole på din gateway, er du nødt til at gøre
> noget andet. Du vil i dette tilfælde være nødt til enten at sætte
> en firewall imellem gateway og lokalnet eller bruger VPN til
> kommunikationen mellem maskinerne.
>
> --
> Kasper Dupont


Hej

Netværket består af et ADSL-modem der bliver plugget ind i "uplink"
indgangen på en switch, de 4 pc´er er så forbundet til de 4 udgange på
denne, og der er installeret seperat FW på hver maskine. Der er ingen
router. Maskinerne har direkte forbindelse med TDC´s dhcp server (som man jo
af gode grunde ikke har adgang til!) der tildeler ip-numre dynamisk til
maskinerne, så der er altså ingen maskine imellem hvor man kan installere en
FW.

Lyder som en god idé at filtrere på MAC-adresserne, de er jo unikke, mener
at have læst at Sygate´s FW kan dette - at spoofe betyder?

VPN kender jeg ikke meget til men vil undersøge det nærmere.

Mvh. Stig




Kasper Dupont (25-12-2001)
Kommentar
Fra : Kasper Dupont


Dato : 25-12-01 01:13

Stig Holmberg wrote:
>
> "Kasper Dupont" <kasperd@daimi.au.dk> wrote> >
>
> > Prøv at skitsere hvordan dit netværk ser ud. Jeg forestiller mig,
> > at det ser sådan ud, men jeg kan tage fejl:
> >
> > +-------------+
> > | Gateway |
> > | DHCP server |
> > +------+------+
> > |
> > +----------+---------+----------+
> > | | | |
> > +-+----+-+ +-+----+-+ +-+----+-+ +-+----+-+
> > | | FW | | | | FW | | | | FW | | | | FW | |
> > | +----+ | | +----+ | | +----+ | | +----+ |
> > | PC 1 | | PC 2 | | PC 3 | | PC 4 |
> > +--------+ +--------+ +--------+ +--------+
> >
>
> Netværket består af et ADSL-modem der bliver plugget ind i "uplink"
> indgangen på en switch, de 4 pc´er er så forbundet til de 4 udgange på
> denne, og der er installeret seperat FW på hver maskine. Der er ingen
> router. Maskinerne har direkte forbindelse med TDC´s dhcp server (som man jo
> af gode grunde ikke har adgang til!) der tildeler ip-numre dynamisk til
> maskinerne, så der er altså ingen maskine imellem hvor man kan installere en
> FW.

Så dit netværk ser altså ud som jeg forestillede mig.
(Om vi kalder boksen for en gateway eller et ADSL-modem
er i denne forbindelse ligegyldigt. Og om ADSL-modemet
indeholder DHCP server eller bare fungerer som gateway
for en ekstern DHCP server er også ligegyldigt.)

>
> Lyder som en god idé at filtrere på MAC-adresserne, de er jo unikke, mener
> at have læst at Sygate´s FW kan dette - at spoofe betyder?

At spoofe betyder at man sender en pakke hvor man
skriver en falsk afsenderaddresse på. Hvis nogen udefra
kan sende pakker med falsk afsender addresse igennem
dit ADSL-modem eller kan cracke dit ADSL-modem og få
det til at sende pakker med en anden MAC addresse har
du et problem. Hvis ADSL-modemet sender pakker med
afsenderaddresse sat til en af de interne computere vil
de kunne komme igennem firewallen. Men hvis ADSL-modemet
er pålideligt har du ikke noget problem.


>
> VPN kender jeg ikke meget til men vil undersøge det nærmere.

Det er kun nødvendigt hvis du ikke stoler på dit ADSL-
modem ikke vil ændre strukturen af dit netværk. VPN vil
sætte hastigheden ned på dit lokalnet. Filtrering af
pakker på afsender MAC addresse vil ikke forårsage nogen
mærkbar nedgang i hastigheden.

--
Kasper Dupont

Christian E. Lysel (24-12-2001)
Kommentar
Fra : Christian E. Lysel


Dato : 24-12-01 17:32

Kasper Dupont wrote:

> Hvis du ikke kan stole på din gateway, er du nødt til at gøre
> noget andet. Du vil i dette tilfælde være nødt til enten at sætte
> en firewall imellem gateway og lokalnet eller bruger VPN til
> kommunikationen mellem maskinerne.


Hvad hjælper VPN?




Kasper Dupont (25-12-2001)
Kommentar
Fra : Kasper Dupont


Dato : 25-12-01 01:15

"Christian E. Lysel" wrote:
>
> Kasper Dupont wrote:
>
> > Hvis du ikke kan stole på din gateway, er du nødt til at gøre
> > noget andet. Du vil i dette tilfælde være nødt til enten at sætte
> > en firewall imellem gateway og lokalnet eller bruger VPN til
> > kommunikationen mellem maskinerne.
>
> Hvad hjælper VPN?

VPN betyder blandt andet at pakkerne har en digital signatur.
Dermed kan der ikke komme pakker udefra og se ud som om de
kommer indefra. Man kan så i sin firewall sætte forskellige
regler op for pakker modtaget vha VPN og pakker modtaget
direkte fra nettet.

--
Kasper Dupont

Christian E. Lysel (25-12-2001)
Kommentar
Fra : Christian E. Lysel


Dato : 25-12-01 02:12

Kasper Dupont wrote:

>>>Hvis du ikke kan stole på din gateway, er du nødt til at gøre
>>>noget andet. Du vil i dette tilfælde være nødt til enten at sætte
>>>en firewall imellem gateway og lokalnet eller bruger VPN til
>>>kommunikationen mellem maskinerne.
>>Hvad hjælper VPN?
> VPN betyder blandt andet at pakkerne har en digital signatur.


Digital signatur??

Du mener vel at de er krypteret?

> Dermed kan der ikke komme pakker udefra og se ud som om de
> kommer indefra. Man kan så i sin firewall sætte forskellige


En VPN løser ikke IP spoofing!

> regler op for pakker modtaget vha VPN og pakker modtaget
> direkte fra nettet.


Men en VPN mellem klienter hjælper ikke.

Klienterne er stadigvæk blottet.

IP spoofing beskyttelse skal stadigvæk fortages af firewallen, og har
ikke noget med VPN forbindelsen mellem de lokale klienter.


Kasper Dupont (25-12-2001)
Kommentar
Fra : Kasper Dupont


Dato : 25-12-01 02:49

"Christian E. Lysel" wrote:
>
> Kasper Dupont wrote:
>
> >>>Hvis du ikke kan stole på din gateway, er du nødt til at gøre
> >>>noget andet. Du vil i dette tilfælde være nødt til enten at sætte
> >>>en firewall imellem gateway og lokalnet eller bruger VPN til
> >>>kommunikationen mellem maskinerne.
> >>Hvad hjælper VPN?
> > VPN betyder blandt andet at pakkerne har en digital signatur.
>
> Digital signatur??
>
> Du mener vel at de er krypteret?

Nej jeg mener bestemt signatur. Pakkerne er også krypteret,
men i den her forbindelse er det signaturen, der er
interessant.

>
> > Dermed kan der ikke komme pakker udefra og se ud som om de
> > kommer indefra. Man kan så i sin firewall sætte forskellige
>
> En VPN løser ikke IP spoofing!

Jo, det gør den for IP addresser på VPN systemet, men
naturligvis ikke for IP addresser udenfor. Det forudsætter
naturligvis at det sættes rigtigt op.

>
> > regler op for pakker modtaget vha VPN og pakker modtaget
> > direkte fra nettet.
>
> Men en VPN mellem klienter hjælper ikke.
>
> Klienterne er stadigvæk blottet.

Hvis man vælger denne løsning, skal hver maskine naturligvis
have en firewall, der frasorterer de fleste indgående pakker.
Pakker indpakket af VPN systemet skal accepteres, alt andet
skal filtreres som man ønsker at filtrere pakker udefra. VPN
systemet checker signatur, og hvis signaturen accepteres
sendes pakken igennem firewallen igen, og firewallen kan
skelne disse pakker fra pakker der er modtaget direkte fra
netkortet.

>
> IP spoofing beskyttelse skal stadigvæk fortages af firewallen, og har
> ikke noget med VPN forbindelsen mellem de lokale klienter.

--
Kasper Dupont

Christian E. Lysel (25-12-2001)
Kommentar
Fra : Christian E. Lysel


Dato : 25-12-01 13:20

Kasper Dupont wrote:

> Nej jeg mener bestemt signatur. Pakkerne er også krypteret,
> men i den her forbindelse er det signaturen, der er
> interessant.


Kan du ikke pege på hvorhenne i IPSEC standarden man brugere digital
signatur af hver enkelt pakke?

Snakker du om AH eller ESP?


Citat fra http://sunsite.dk/RFC/rfc/rfc2401.html

o The IP Authentication Header (AH) [KA98a] provides
connectionless integrity, data origin authentication, and an
optional anti-replay service.
o The Encapsulating Security Payload (ESP) protocol [KA98b] may
provide confidentiality (encryption), and limited traffic flow
confidentiality. It also may provide connectionless
integrity, data origin authentication, and an anti-replay
service. (One or the other set of these security services
must be applied whenever ESP is invoked.)
o Both AH and ESP are vehicles for access control, based on the
distribution of cryptographic keys and the management of
traffic flows relative to these security protocols.

>>En VPN løser ikke IP spoofing!

> Jo, det gør den for IP addresser på VPN systemet, men
> naturligvis ikke for IP addresser udenfor. Det forudsætter
> naturligvis at det sættes rigtigt op.


Kan du ikke pege på hvorhenne i IPSEC standarden der bliver taget højde
for IP spoofing?
   
Du kan fx stadigvæk spoofe pakker til 127.0.0.1, selvom du kører VPN
klienter.

>>Men en VPN mellem klienter hjælper ikke.
>>
>>Klienterne er stadigvæk blottet.


> Hvis man vælger denne løsning, skal hver maskine naturligvis
> have en firewall, der frasorterer de fleste indgående pakker.


Ergo skal du stadivæk bruge en firewall.

> Pakker indpakket af VPN systemet skal accepteres, alt andet
> skal filtreres som man ønsker at filtrere pakker udefra. VPN
> systemet checker signatur, og hvis signaturen accepteres
> sendes pakken igennem firewallen igen, og firewallen kan
> skelne disse pakker fra pakker der er modtaget direkte fra
> netkortet.


Ovenstående fortages af en firewall, og ikke af en VPN klient.

Alt man så i dag efterhånden blander det hele sammen er en anden sag.




Kasper Dupont (25-12-2001)
Kommentar
Fra : Kasper Dupont


Dato : 25-12-01 21:09

"Christian E. Lysel" wrote:
>
> Kasper Dupont wrote:
>
> > Nej jeg mener bestemt signatur. Pakkerne er også krypteret,
> > men i den her forbindelse er det signaturen, der er
> > interessant.
>
> Kan du ikke pege på hvorhenne i IPSEC standarden man brugere digital
> signatur af hver enkelt pakke?

Jeg har ikke nævnt nogen standarder.

>
> Snakker du om AH eller ESP?

Jeg snakker om signaturer.

>
> Citat fra http://sunsite.dk/RFC/rfc/rfc2401.html
>
> o The IP Authentication Header (AH) [KA98a] provides
> connectionless integrity, data origin authentication, and an
> optional anti-replay service.
> o The Encapsulating Security Payload (ESP) protocol [KA98b] may
> provide confidentiality (encryption), and limited traffic flow
> confidentiality. It also may provide connectionless
> integrity, data origin authentication, and an anti-replay
> service. (One or the other set of these security services
> must be applied whenever ESP is invoked.)
> o Both AH and ESP are vehicles for access control, based on the
> distribution of cryptographic keys and the management of
> traffic flows relative to these security protocols.

Det der er væsentligt her er integritet og data origin
authentication. Jeg undrer mig over hvorfor der skelnes
mellem de to, da jeg kan ikke se hvordan data origin
authentication kan implementeres uden at man samtidig
opnår integritet. Da både AH og ESP har data origin
authentication kan begge bruges, data origin
authentication kan bruges til at forhindre spoofing.

>
> >>En VPN løser ikke IP spoofing!
>
> > Jo, det gør den for IP addresser på VPN systemet, men
> > naturligvis ikke for IP addresser udenfor. Det forudsætter
> > naturligvis at det sættes rigtigt op.
>
> Kan du ikke pege på hvorhenne i IPSEC standarden der bliver taget højde
> for IP spoofing?

Jeg kender ikke den standard, men et VPN system giver
mulighed for at genkende afsenderen, man skal blot for
hver afsender angive hvilke IP addresser der må sendes
pakker med. Dette burde intet have med standarden at
gøre, det er et implementations spørgsmål. En naturlig
måde at implementere VPN på er ved at man ser et
virtuelt netkort som så konfigureres på lige fod med
alle andre netkort.

>
> Du kan fx stadigvæk spoofe pakker til 127.0.0.1, selvom du kører VPN
> klienter.

Dette er et af de meget simple tilfælde af IP spoofing
som har en meget simpel løsning. Det er hverken
nødvendigt at anvende VPN eller firewall for at stoppe
denne type spoofede pakker. Den simpleste løsning, som
virker i ethvert ikke cycliske netværk er at finde
sourceaddressen i routenings tabelen og se om pakken
kommer fra det rigtige (virtuelle) netkort. Hvis pakker
fra samme source kan komme af forskellige ruter, bliver
det lidt mere compliceret. Men det er ikke tilfældet i
det konkrete netværk.

>
> >>Men en VPN mellem klienter hjælper ikke.
> >>
> >>Klienterne er stadigvæk blottet.
>
> > Hvis man vælger denne løsning, skal hver maskine naturligvis
> > have en firewall, der frasorterer de fleste indgående pakker.
>
> Ergo skal du stadivæk bruge en firewall.

Jeg sagde ikke at VPN var et alternativ til en firewall.
Jeg sagde, at det var en løsning på problemet med et
lokalnet, hvor hver computer har sin egen firewall i
stedet for en fælles firewall.

>
> > Pakker indpakket af VPN systemet skal accepteres, alt andet
> > skal filtreres som man ønsker at filtrere pakker udefra. VPN
> > systemet checker signatur, og hvis signaturen accepteres
> > sendes pakken igennem firewallen igen, og firewallen kan
> > skelne disse pakker fra pakker der er modtaget direkte fra
> > netkortet.
>
> Ovenstående fortages af en firewall, og ikke af en VPN klient.

En del af det foretages af firewallen, men check af
signatur skal naturligvis foretages af VPN systemet.

>
> Alt man så i dag efterhånden blander det hele sammen er en anden sag.

VPN og en firewall er to forskellige ting, men hvis man
har brug for begge ting kan det med fordel placeres i
samme fysiske boks.

Den virtuelle netforbindelse ønsker man typisk at
placere bagved sin firewall, men de indpakkede
pakker skal sendes over nettet udenfor firewallen.
Dermed har man tre mulige løsninger.

1) Lave regler i firewallen som lader VPN pakkerne
slippe igennem.
2) Lade VPN boksen have et netkort på hver side af
firewallen.
3) Placere det to ting i samme boks.

I det konkrete tilfælde, hvor der er tale om en
software firewall, der beskytter en enkelt computer,
skal VPN systemet naturligvis placeres i samme
computer.

--
Kasper Dupont

Christian E. Lysel (25-12-2001)
Kommentar
Fra : Christian E. Lysel


Dato : 25-12-01 22:17

Kasper Dupont wrote:

>>>Nej jeg mener bestemt signatur. Pakkerne er også krypteret,
>>>men i den her forbindelse er det signaturen, der er
>>>interessant.
>>Kan du ikke pege på hvorhenne i IPSEC standarden man brugere digital
>>signatur af hver enkelt pakke?
> Jeg har ikke nævnt nogen standarder.


Godt.

Ingen produkter jeg har set brugere digital signatur af hver enkelt
pakke, endvidere ville det fylde for meget.

> Det der er væsentligt her er integritet og data origin
> authentication. Jeg undrer mig over hvorfor der skelnes
> mellem de to, da jeg kan ikke se hvordan data origin
> authentication kan implementeres uden at man samtidig
> opnår integritet. Da både AH og ESP har data origin
> authentication kan begge bruges, data origin
> authentication kan bruges til at forhindre spoofing.


Hvad har det med digital signatur at gøre?

>>Kan du ikke pege på hvorhenne i IPSEC standarden der bliver taget højde
>>for IP spoofing?
> Jeg kender ikke den standard, men et VPN system giver
> mulighed for at genkende afsenderen, man skal blot for
> hver afsender angive hvilke IP addresser der må sendes
> pakker med. Dette burde intet have med standarden at
> gøre, det er et implementations spørgsmål. En naturlig
> måde at implementere VPN på er ved at man ser et
> virtuelt netkort som så konfigureres på lige fod med
> alle andre netkort.


Og hvis lokale nettet sender en ICMP redirect til klienten om at den
skal ændre sin routningstabel til at router VPN trafik til det fysiske
interface i stedet for det virtuelle?


>>Du kan fx stadigvæk spoofe pakker til 127.0.0.1, selvom du kører VPN
>>klienter.
> Dette er et af de meget simple tilfælde af IP spoofing
> som har en meget simpel løsning. Det er hverken
> nødvendigt at anvende VPN eller firewall for at stoppe
> denne type spoofede pakker. Den simpleste løsning, som
> virker i ethvert ikke cycliske netværk er at finde
> sourceaddressen i routenings tabelen og se om pakken
> kommer fra det rigtige (virtuelle) netkort. Hvis pakker


Og hvor mange TCP/IP stakke understøtter ikke dette?


> fra samme source kan komme af forskellige ruter, bliver
> det lidt mere compliceret. Men det er ikke tilfældet i
> det konkrete netværk.


>>Ergo skal du stadivæk bruge en firewall.
> Jeg sagde ikke at VPN var et alternativ til en firewall.


Jo :)

> Jeg sagde, at det var en løsning på problemet med et
> lokalnet, hvor hver computer har sin egen firewall i
> stedet for en fælles firewall.


Citat fra tidligere:

....Hvis du ikke kan stole på din gateway, er du nødt til at gøre
noget andet. Du vil i dette tilfælde være nødt til enten at sætte
en firewall imellem gateway og lokalnet eller bruger VPN til
kommunikationen mellem maskinerne...

Den først sætning præsisere du at vi ikke stoler på gatewayen. Den næste
sætning er en "enten, eller" struktur.

Og her sætter jeg spørgsmål ved hvad en VPN vil hjælpe?

En personlig VPN/Firewall vil hjælpe, eller en personlig firewall alene
vil hjælpe, eller at kører lokalnet trafik over fx IPX (og sætte
klienter op uden TCP/IP services) vil også hjælpe.

>>>Pakker indpakket af VPN systemet skal accepteres, alt andet
>>>skal filtreres som man ønsker at filtrere pakker udefra. VPN
>>>systemet checker signatur, og hvis signaturen accepteres
>>>sendes pakken igennem firewallen igen, og firewallen kan
>>>skelne disse pakker fra pakker der er modtaget direkte fra
>>>netkortet.
>>Ovenstående fortages af en firewall, og ikke af en VPN klient.


> En del af det foretages af firewallen, men check af
> signatur skal naturligvis foretages af VPN systemet.


Der er ingen signatur!

>>Alt man så i dag efterhånden blander det hele sammen er en anden sag.
> VPN og en firewall er to forskellige ting, men hvis man
> har brug for begge ting kan det med fordel placeres i
> samme fysiske boks.
>
> Den virtuelle netforbindelse ønsker man typisk at
> placere bagved sin firewall, men de indpakkede
> pakker skal sendes over nettet udenfor firewallen.
> Dermed har man tre mulige løsninger.
>
> 1) Lave regler i firewallen som lader VPN pakkerne
> slippe igennem.
> 2) Lade VPN boksen have et netkort på hver side af
> firewallen.
> 3) Placere det to ting i samme boks.


Eller:

4) kombination af 1 og 2, hvor VPN boksen sidder på segmenter på
firewallen...hvilket er min fortrukne.


2) hvorfor sætte nogle deres VPN boks op sådan. Man opnår kun at have en
VPN servere forbundet parallelt med Firewallen, og nu har angriberen to
indgangsmuligheder.


> I det konkrete tilfælde, hvor der er tale om en
> software firewall, der beskytter en enkelt computer,
> skal VPN systemet naturligvis placeres i samme
> computer.


Andreas Plesner Jaco~ (25-12-2001)
Kommentar
Fra : Andreas Plesner Jaco~


Dato : 25-12-01 22:43

In article <3C28ECE5.2050507@example.net>, Christian E. Lysel wrote:

>>>Kan du ikke pege på hvorhenne i IPSEC standarden man brugere digital
>>>signatur af hver enkelt pakke?
>> Jeg har ikke nævnt nogen standarder.
>
> Godt.
>
> Ingen produkter jeg har set brugere digital signatur af hver enkelt
> pakke, endvidere ville det fylde for meget.

Sludder, AH *er* digitale signaturer.

--
Andreas Plesner Jacobsen | E = MC ** 2 +- 3db

Christian E. Lysel (26-12-2001)
Kommentar
Fra : Christian E. Lysel


Dato : 26-12-01 03:05

Andreas Plesner Jacobsen wrote:

>>Ingen produkter jeg har set brugere digital signatur af hver enkelt
>>pakke, endvidere ville det fylde for meget.
> Sludder, AH *er* digitale signaturer.


Hvilken del af AH indeholder digital signatur, hvis du evt. kan refere
til et afsnit i RFC'en.

AH er et forsøg på at implementere nogle af de egenskaber digital
signatur giver.




Andreas Plesner Jaco~ (26-12-2001)
Kommentar
Fra : Andreas Plesner Jaco~


Dato : 26-12-01 11:20

In article <3C293058.8060408@example.net>, Christian E. Lysel wrote:
>
>>>Ingen produkter jeg har set brugere digital signatur af hver enkelt
>>>pakke, endvidere ville det fylde for meget.
>> Sludder, AH *er* digitale signaturer.
>
> Hvilken del af AH indeholder digital signatur, hvis du evt. kan refere
> til et afsnit i RFC'en.

Nu bliver du vist religiøs og ordkløverisk. Jeg vil ikke mene at et
menneske behøver være involveret for at en digital signatur er en
digital signatur. Hvis AH kan sikre authentication og integritet må det
være en digital signatur (non-repudiation er IMO et non-issue i denne
form for kommunikation)

> AH er et forsøg på at implementere nogle af de egenskaber digital
> signatur giver.

Jeg vil stadig hævde at AH _er_ digitale signaturer. At påstå andet vil
kræve at man bruger din definition på digitale signaturer og ikke den
resten af verden bruger.

--
Andreas Plesner Jacobsen | In vino veritas.
| [In wine there is truth.]
|    -- Pliny

Christian E. Lysel (26-12-2001)
Kommentar
Fra : Christian E. Lysel


Dato : 26-12-01 15:13

Andreas Plesner Jacobsen wrote:

>>Hvilken del af AH indeholder digital signatur, hvis du evt. kan refere
>>til et afsnit i RFC'en.
> Nu bliver du vist religiøs og ordkløverisk. Jeg vil ikke mene at et
> menneske behøver være involveret for at en digital signatur er en
> digital signatur. Hvis AH kan sikre authentication og integritet må det
> være en digital signatur (non-repudiation er IMO et non-issue i denne
> form for kommunikation)


Du er lige selv kommet med svaret, nemlig non-repudiation :)



Andreas Plesner Jaco~ (26-12-2001)
Kommentar
Fra : Andreas Plesner Jaco~


Dato : 26-12-01 18:20

In article <3C29DAF5.6000409@example.net>, Christian E. Lysel wrote:
>
>>>Hvilken del af AH indeholder digital signatur, hvis du evt. kan refere
>>>til et afsnit i RFC'en.
>> Nu bliver du vist religiøs og ordkløverisk. Jeg vil ikke mene at et
>> menneske behøver være involveret for at en digital signatur er en
>> digital signatur. Hvis AH kan sikre authentication og integritet må det
>> være en digital signatur (non-repudiation er IMO et non-issue i denne
>> form for kommunikation)
>
> Du er lige selv kommet med svaret, nemlig non-repudiation :)

Non-repudiation ligger implicit i authentication, men må afhænge af,
hvilket system man bruger til AH.

--
Andreas Plesner Jacobsen | New England Life, of course. Why do you ask?

Kasper Dupont (25-12-2001)
Kommentar
Fra : Kasper Dupont


Dato : 25-12-01 23:40

"Christian E. Lysel" wrote:
>
> LAN -----------------------
> | |
> |Firewall ------ VPN server
> |
> Internet
> |
> VPN klient
>
> Dvs. VPN klienten går igennem Internet og Firewall, ud på et segment
> hvor VPN serveren sidder, og herfra ind på LAN'et.
>
> På Internet sidder en 3. part der godt kan sende trafik til VPN
> klienten, selvom denne har sin "firewall" slået til!

Et lidt degenereret VPN system. På den ene side har du et større
netværk hvor firewall og VPN er seperate maskiner og du har
samtidig et netværk med en række maskiner, på den anden side har
du det hele samlet i en maskine. Den største risiko ved dette
system er at man kan glemme, at man skal være omhyggelig med
sikkerheden i BEGGE ender af VPN forbindelsen. (Ud fra din
beskrivelse lyder det som om der anvendes en for dårlig firewall
i den ene ende.)

I et mere generelt setup har man et antal netværk, der kan være
af varierende størelse. Hvert netværk skal have mindst en maskine
der foretager VPN og bør have sin egen firewall. Et antal af
disse netværk kan bestå af blot en enkelt maskine, i disse
tilfælde skal der stadig være VPN og firewall på denne maskine.

Du snakker om et tilfælde hvor der er et enkelt større netværk
og et antal enkeltstående maskiner, og formodentlig et tilfælde
hvor de enkeltstående maskiner ikke kan kommunikere uden at
sende pakkerne igennem VPN boksen på det større netværk.

Jeg snakker om et tilfælde hvor alle netværkene er reduceret
til enkelte maskiner, og hvor de er ligestillede, der er altså
ikke en server og et antal klienter. Så snart to vilkårlige
maskiner er oppe skal de kunne kommunikere.

>
> > Men denne løsning kan ikke anbefales da det giver en
> > dårlig ydelse, og desuden er det lidt ustabilt fordi
> > TCP forbindelsen som ssh basserer sig på kan blive
> > afbrudt. Desuden skal forbindelsen genstartes i begge
>
> TCP er en sessions afhængig protokol og vil derfor retransmittere ved
> fejl, derfor bør du ikke have problemer med at forbindelsen skal genstartes.

Det kan give problemer når nu TCP forbindelsen går igennem
en firewall med statefull inspektion som går ned mindst en
gang om ugen. (Jeg undgik timeouts ved at køre et cron job
der pingede en maskine i den anden ende hver time.)

>
> > ender hvis en af maskinerne har været genstartet.
>
> Dog kan problemet være at du kører:
>
> TCP session - PPP - SSH - TCP Session.
>
> Dvs. at evt. pakketab kan blive retransmitteret af TCP som bærer SSH
> trafikken og af TCP session der kører ovenpå PPP.

Der vil ikke være pakketab i ppp forbindelsen da den
kører ovenpå en pålidelig bytestream, men hvis der sker et
pakketab på den nederste TCP forbindelse kunne den øverste
retransmitere inden pakken når frem. Jeg har aldrig før
overvejet dette, men jeg tror ikke det er et problem, og
jeg så ingen symptomer på dette. TCP er indrettet til at
håndtere forsinkede pakker, der bliver retransmiteret, mens
den første udgave stadig er på nettet, så dette vil nok
aldrig give alvorlige problemer.

>
>
> > Et rigtigt VPN system vil kunne løse de nævnte
> > problemer og opnå samme sikkerhed. Men jeg har ingen
> > erfaring med konkrete implementationer, jeg kender
> > kun teorien.
>
> Hvilken teori?

VPN er i virkligheden blot en kombination af tunelling
kryptering og signatur.

>
> Den mest udbrede er IPSEC.
>
> IPSEC bygger ikke en digital signatur for hver enkelt pakken, hvilket
> også ville fylde alt for meget.

Jeg burde nok have præciseret lidt mere hvad jeg mener
når jeg siger digital signatur. Jeg mener selvfølgelig
ikke, at der skal anvendes en assymetrisk nøgle til
kryptering og signering af hver pakke. Der skal kun
anvendes assymetriske nøgler til initialisering. Ved
initialiseringen skal der udveksles symmetriske nøgler,
der anvendes til den videre kommunikation. Det er SVJV
sådan alle den slags protokoller, SSH bruger SVJV 16
bytes til signatur. Jeg formoder at det er noget
lignende der tales om i RFC2401 som du tidligere
citerede. Der nævnes integritet og data origin som er
det væsentlige.

>
> Endvidere løser IPSEC ikke sikkerhedsproblemer omkring routning og
> ligende ting.

Nej, det er en opgave for systemadministratoren der
sætter systemet op. (Og den software der anvendes til
dette formål.)

>
> I teorien er teori og praksis det samme, i praksis er teori og praksis
> forskellig.

Hvilket er et bevis ved eksempel for at teori og praksis
ikke er det samme. Hermed har vi altså et teoretisk
bevis for, at teori og praksis ikke er det samme. Og nu
skal jeg passe på at jeg ikke går i selvsving.

>
> >>>Nej jeg mener bestemt signatur. Pakkerne er også krypteret,
> >>>men i den her forbindelse er det signaturen, der er
> >>>interessant.
> >>Kan du ikke pege på hvorhenne i IPSEC standarden man brugere digital
> >>signatur af hver enkelt pakke?
> > Jeg har ikke nævnt nogen standarder.
>
> Godt.
>
> Ingen produkter jeg har set brugere digital signatur af hver enkelt
> pakke, endvidere ville det fylde for meget.

Ovenfor har jeg vidst forklaret, hvad jeg mener.

>
> > Det der er væsentligt her er integritet og data origin
> > authentication. Jeg undrer mig over hvorfor der skelnes
> > mellem de to, da jeg kan ikke se hvordan data origin
> > authentication kan implementeres uden at man samtidig
> > opnår integritet. Da både AH og ESP har data origin
> > authentication kan begge bruges, data origin
> > authentication kan bruges til at forhindre spoofing.
>
> Hvad har det med digital signatur at gøre?

Forklaret ovenfor.

>
> >>Kan du ikke pege på hvorhenne i IPSEC standarden der bliver taget højde
> >>for IP spoofing?
> > Jeg kender ikke den standard, men et VPN system giver
> > mulighed for at genkende afsenderen, man skal blot for
> > hver afsender angive hvilke IP addresser der må sendes
> > pakker med. Dette burde intet have med standarden at
> > gøre, det er et implementations spørgsmål. En naturlig
> > måde at implementere VPN på er ved at man ser et
> > virtuelt netkort som så konfigureres på lige fod med
> > alle andre netkort.
>
> Og hvis lokale nettet sender en ICMP redirect til klienten om at den
> skal ændre sin routningstabel til at router VPN trafik til det fysiske
> interface i stedet for det virtuelle?

Det skal man selvfølgelig undgå. Hvis ikke man kan få sin
IP implementation til at ignorere disse opdateringer har
man brug for en firewall til den opgave.

>
>
> >>Du kan fx stadigvæk spoofe pakker til 127.0.0.1, selvom du kører VPN
> >>klienter.
> > Dette er et af de meget simple tilfælde af IP spoofing
> > som har en meget simpel løsning. Det er hverken
> > nødvendigt at anvende VPN eller firewall for at stoppe
> > denne type spoofede pakker. Den simpleste løsning, som
> > virker i ethvert ikke cycliske netværk er at finde
> > sourceaddressen i routenings tabelen og se om pakken
> > kommer fra det rigtige (virtuelle) netkort. Hvis pakker
>
> Og hvor mange TCP/IP stakke understøtter ikke dette?

Du forventer vel ikke, at jeg kender alle dårlige IP
implementationer. Jeg ved, at dette kan lade sig gøre
på Linux. Og hvis det ikke kan lade sig gøre enten i
din IP implementation eller i din firewall har du et
alvorligt problem.

>
> > fra samme source kan komme af forskellige ruter, bliver
> > det lidt mere compliceret. Men det er ikke tilfældet i
> > det konkrete netværk.
>
> >>Ergo skal du stadivæk bruge en firewall.
> > Jeg sagde ikke at VPN var et alternativ til en firewall.
>
> Jo :)
>
> > Jeg sagde, at det var en løsning på problemet med et
> > lokalnet, hvor hver computer har sin egen firewall i
> > stedet for en fælles firewall.
>
> Citat fra tidligere:
>
> ...Hvis du ikke kan stole på din gateway, er du nødt til at gøre
> noget andet. Du vil i dette tilfælde være nødt til enten at sætte
> en firewall imellem gateway og lokalnet eller bruger VPN til
> kommunikationen mellem maskinerne...
>
> Den først sætning præsisere du at vi ikke stoler på gatewayen. Den næste
> sætning er en "enten, eller" struktur.
>
> Og her sætter jeg spørgsmål ved hvad en VPN vil hjælpe?

Lad os tage det helt fra starten igen.

Udgangspunktet er fire computere, der er fuldstændig
ubeskyttet. Der bliver så tilføjet en firewall til
hver computer, som betyder at de er beskyttet, men nu
har problemer med den interne kommunikation. Her kan
VPN hjælpe. De to alternativer jeg nævner er altså:
1) Sæt en firewall foran lokalnettet og reducer
beskyttelsen i de enkelte maskiners firewalls.
2) Lav et VPN system og behold firewall på de
enkelte maskiner.

VPN er altså et alternativ til en "hardware" firewall,
det er ikke et alternativ til de fire software firewalls
der allerede er installeret på maskinerne.

>
> En personlig VPN/Firewall vil hjælpe, eller en personlig firewall alene
> vil hjælpe, eller at kører lokalnet trafik over fx IPX (og sætte
> klienter op uden TCP/IP services) vil også hjælpe.

Det hjælper ikke hvis ADSL-modemet kan crackes, så kan
man også få det til at sende IPX pakker med spoofede
MAC addresser. Dit forslag er så vidt jeg kan se ikke
andet end security through obscurity.

>
> >>>Pakker indpakket af VPN systemet skal accepteres, alt andet
> >>>skal filtreres som man ønsker at filtrere pakker udefra. VPN
> >>>systemet checker signatur, og hvis signaturen accepteres
> >>>sendes pakken igennem firewallen igen, og firewallen kan
> >>>skelne disse pakker fra pakker der er modtaget direkte fra
> >>>netkortet.
> >>Ovenstående fortages af en firewall, og ikke af en VPN klient.
>
> > En del af det foretages af firewallen, men check af
> > signatur skal naturligvis foretages af VPN systemet.
>
> Der er ingen signatur!

Jo.

>
> >>Alt man så i dag efterhånden blander det hele sammen er en anden sag.
> > VPN og en firewall er to forskellige ting, men hvis man
> > har brug for begge ting kan det med fordel placeres i
> > samme fysiske boks.
> >
> > Den virtuelle netforbindelse ønsker man typisk at
> > placere bagved sin firewall, men de indpakkede
> > pakker skal sendes over nettet udenfor firewallen.
> > Dermed har man tre mulige løsninger.
> >
> > 1) Lave regler i firewallen som lader VPN pakkerne
> > slippe igennem.
> > 2) Lade VPN boksen have et netkort på hver side af
> > firewallen.
> > 3) Placere det to ting i samme boks.
>
> Eller:
>
> 4) kombination af 1 og 2, hvor VPN boksen sidder på segmenter på
> firewallen...hvilket er min fortrukne.

Altså den ene side af VPN boksen i det der af og til
kaldes for en DMZ zone. Det lyder umidelbart ikke helt
tosset, men er det nu også nødvendigt.

>
> 2) hvorfor sætte nogle deres VPN boks op sådan. Man opnår kun at have en
> VPN servere forbundet parallelt med Firewallen, og nu har angriberen to
> indgangsmuligheder.

Ja, denne løsning ser umidelbart mere farlig ud, men
jeg er ikke sikker på at det virklig er tilfældet.
Alt hvad VPN boksen skal modtage på det eksterne
netkort er VPN pakker. Det burde være nemt for VPN
boksen at ignorere alt andet. Hvis man kan cracke VPN
boksen ved at sende en passende VPN pakke til den,
hjælper firewallen ikke. Firewallen er jo nu en gang
nødt til at slippe VPN pakkerne igennem.

Der kan naturligvis være sikkerhedshuller i VPN boksen,
men sandsynligvis vil firewallen ikke hjælpe her. Men
dit netværk er naturligvis ikke mindre sikkert.

Hvis først man har cracket VPN boksen har man i begge
tilfælde straks fri adgang til lokalnettet bagved.

--
Kasper Dupont

Christian E. Lysel (26-12-2001)
Kommentar
Fra : Christian E. Lysel


Dato : 26-12-01 03:04

Kasper Dupont wrote:

> Et lidt degenereret VPN system. På den ene side har du et større
> netværk hvor firewall og VPN er seperate maskiner og du har
> samtidig et netværk med en række maskiner, på den anden side har
> du det hele samlet i en maskine. Den største risiko ved dette


VPN klienten er almidelige brugere. Fx hjemmearbejdsplads eller mobile
brugere.

> system er at man kan glemme, at man skal være omhyggelig med
> sikkerheden i BEGGE ender af VPN forbindelsen. (Ud fra din
> beskrivelse lyder det som om der anvendes en for dårlig firewall
> i den ene ende.)


Ja, Cisco's klient er lidt "sjov".


> Jeg snakker om et tilfælde hvor alle netværkene er reduceret
> til enkelte maskiner, og hvor de er ligestillede, der er altså
> ikke en server og et antal klienter. Så snart to vilkårlige
> maskiner er oppe skal de kunne kommunikere.


>>>Men denne løsning kan ikke anbefales da det giver en
>>>dårlig ydelse, og desuden er det lidt ustabilt fordi
>>>TCP forbindelsen som ssh basserer sig på kan blive
>>>afbrudt. Desuden skal forbindelsen genstartes i begge
>>>
>>TCP er en sessions afhængig protokol og vil derfor retransmittere ved
>>fejl, derfor bør du ikke have problemer med at forbindelsen skal genstartes.


> Det kan give problemer når nu TCP forbindelsen går igennem
> en firewall med statefull inspektion som går ned mindst en
> gang om ugen. (Jeg undgik timeouts ved at køre et cron job
> der pingede en maskine i den anden ende hver time.)


Både ssh og ppp understøtter keep-alive.

Jeg implementede ovenstående løsning for knap 5 år siden, men det kører
bedre i IPSEC, bedre preformance og stabilitet. Efterhånden understøtter
Linux jo også IPSEC :)

>>>ender hvis en af maskinerne har været genstartet.
>>Dog kan problemet være at du kører:
>>TCP session - PPP - SSH - TCP Session.
>>Dvs. at evt. pakketab kan blive retransmitteret af TCP som bærer SSH
>>trafikken og af TCP session der kører ovenpå PPP.


> Der vil ikke være pakketab i ppp forbindelsen da den
> kører ovenpå en pålidelig bytestream, men hvis der sker et
> pakketab på den nederste TCP forbindelse kunne den øverste
> retransmitere inden pakken når frem. Jeg har aldrig før
> overvejet dette, men jeg tror ikke det er et problem, og
> jeg så ingen symptomer på dette. TCP er indrettet til at


Problemet er blot at ved pakke tab, vil retransmission ske dobbelt.

> håndtere forsinkede pakker, der bliver retransmiteret, mens
> den første udgave stadig er på nettet, så dette vil nok
> aldrig give alvorlige problemer.


Helst skal VPN løsningen se det som et replay attack, men det bliver
ikke set som et replay!

> Jeg burde nok have præciseret lidt mere hvad jeg mener
> når jeg siger digital signatur. Jeg mener selvfølgelig
> ikke, at der skal anvendes en assymetrisk nøgle til
> kryptering og signering af hver pakke. Der skal kun


Godt.

> anvendes assymetriske nøgler til initialisering. Ved
> initialiseringen skal der udveksles symmetriske nøgler,
> der anvendes til den videre kommunikation. Det er SVJV

> sådan alle den slags protokoller, SSH bruger SVJV 16
> bytes til signatur. Jeg formoder at det er noget
> lignende der tales om i RFC2401 som du tidligere
> citerede. Der nævnes integritet og data origin som er
> det væsentlige.


Tak. Jeg bryder mig blot ikke om at det bliver omtalt som digital signatur.

For mig at se, kan man ikke snakke digital signatur, hvis man ikke også
snakker om PKI.

>>Endvidere løser IPSEC ikke sikkerhedsproblemer omkring routning og
>>ligende ting.
> Nej, det er en opgave for systemadministratoren der
> sætter systemet op. (Og den software der anvendes til
> dette formål.)


Eller de firewalls der benytte.

>>Og hvis lokale nettet sender en ICMP redirect til klienten om at den
>>skal ændre sin routningstabel til at router VPN trafik til det fysiske
>>interface i stedet for det virtuelle?
> Det skal man selvfølgelig undgå. Hvis ikke man kan få sin
> IP implementation til at ignorere disse opdateringer har
> man brug for en firewall til den opgave.


Yes, og ikke en VPN boks der påstår den kan alt.

>>Og hvor mange TCP/IP stakke understøtter ikke dette?

> Du forventer vel ikke, at jeg kender alle dårlige IP
> implementationer. Jeg ved, at dette kan lade sig gøre
> på Linux. Og hvis det ikke kan lade sig gøre enten i
> din IP implementation eller i din firewall har du et
> alvorligt problem.


På nyere Linux kerner ja, men ikke gamle.

> VPN er altså et alternativ til en "hardware" firewall,
> det er ikke et alternativ til de fire software firewalls
> der allerede er installeret på maskinerne.


Please kald det en personlig VPN/Firewall.

VPN alene yder ikke ovenstående.

>>En personlig VPN/Firewall vil hjælpe, eller en personlig firewall alene
>>vil hjælpe, eller at kører lokalnet trafik over fx IPX (og sætte
>>klienter op uden TCP/IP services) vil også hjælpe.


> Det hjælper ikke hvis ADSL-modemet kan crackes, så kan
> man også få det til at sende IPX pakker med spoofede
> MAC addresser. Dit forslag er så vidt jeg kan se ikke
> andet end security through obscurity.


Ok, så vi er derhenne hvor ADSL-modemet kan crackes. Det sammen kan en
VPN løsning vel også? :)

Er det ikke nemmere at smide ekstra netværkskort i maskinerne, således
at man kører et internt net på et selvstændigt segment?

Personligt er det nemmer at smide en Linux eller BSD boks op, på en
gammel 486...Jeg brugere selv 2 stk. og de har kørt fint.

Den ene står oppe på mit loft og bliver udsat for -5 grader til +40
grader, uden problemmer.   

>>4) kombination af 1 og 2, hvor VPN boksen sidder på segmenter på
>>firewallen...hvilket er min fortrukne.
>>
>
> Altså den ene side af VPN boksen i det der af og til
> kaldes for en DMZ zone. Det lyder umidelbart ikke helt
> tosset, men er det nu også nødvendigt.


Sammenlignet med hvad et ekstra netværkskort koster, og hvor stor
forøgelse af sikkerheden man opnår, findet jeg det _meget_ rimeligt.

>>2) hvorfor sætte nogle deres VPN boks op sådan. Man opnår kun at have en
>>VPN servere forbundet parallelt med Firewallen, og nu har angriberen to
>> indgangsmuligheder.


> Ja, denne løsning ser umidelbart mere farlig ud, men
> jeg er ikke sikker på at det virklig er tilfældet.
> Alt hvad VPN boksen skal modtage på det eksterne
> netkort er VPN pakker. Det burde være nemt for VPN
> boksen at ignorere alt andet. Hvis man kan cracke VPN
> boksen ved at sende en passende VPN pakke til den,


Windows 2000 bokse kan man skyde ned med fragmenteret UDP pakker.

Windows og gamle Linux bokse kan man skanne interne maskiner udefra med
pixie scan.

Endvidere er det sværer at administere sikkerheden på 2 bokse end det er
på 1 boks.


> hjælper firewallen ikke. Firewallen er jo nu en gang
> nødt til at slippe VPN pakkerne igennem.


Meget simpelt:

Firewallen har 2 sårbarheder, a og b, og VPN serveren har 3 sårbarheder,
a, x og y.

Dermed vil man kunne bruge 4 sårbarheder a,b,x,y når det er forbundet
parallel, men det var serielt kun 1, a.

> Der kan naturligvis være sikkerhedshuller i VPN boksen,
> men sandsynligvis vil firewallen ikke hjælpe her. Men
> dit netværk er naturligvis ikke mindre sikkert.


Firewallen vil ikke hjælpe i det tilfælde hvor hullet ligger i VPN
protokollen, nej, men ellers ja.


> Hvis først man har cracket VPN boksen har man i begge
> tilfælde straks fri adgang til lokalnettet bagved.


Nix i 4) har man kun adgang til det firewallen tillader!


Kasper Dupont (26-12-2001)
Kommentar
Fra : Kasper Dupont


Dato : 26-12-01 11:55

"Christian E. Lysel" wrote:
>
> Kasper Dupont wrote:
>
> > Et lidt degenereret VPN system. På den ene side har du et større
> > netværk hvor firewall og VPN er seperate maskiner og du har
> > samtidig et netværk med en række maskiner, på den anden side har
> > du det hele samlet i en maskine. Den største risiko ved dette
>
> VPN klienten er almidelige brugere. Fx hjemmearbejdsplads eller mobile
> brugere.

Det betyder ikke at sikkerheden er ligegyldig. Man skal
stadig fokusere på sikkerhed i begge ender.

>
> > Det kan give problemer når nu TCP forbindelsen går igennem
> > en firewall med statefull inspektion som går ned mindst en
> > gang om ugen. (Jeg undgik timeouts ved at køre et cron job
> > der pingede en maskine i den anden ende hver time.)
>
> Både ssh og ppp understøtter keep-alive.

Jeg havde alligevel brug for de periodiske pings for at
se, om forbindelsen stadig var åben, så jeg undersøgte
aldrig andre keep-alives.

>
> Jeg implementede ovenstående løsning for knap 5 år siden, men det kører
> bedre i IPSEC, bedre preformance og stabilitet. Efterhånden understøtter
> Linux jo også IPSEC :)

Jeg har ikke mere noget at gøre med førnævnte system,
men jeg kunne nu alligvel godt have lyst til at
eksperimentere med IPSEC på Linux.

>
> >>>ender hvis en af maskinerne har været genstartet.
> >>Dog kan problemet være at du kører:
> >>TCP session - PPP - SSH - TCP Session.
> >>Dvs. at evt. pakketab kan blive retransmitteret af TCP som bærer SSH
> >>trafikken og af TCP session der kører ovenpå PPP.
>
> > Der vil ikke være pakketab i ppp forbindelsen da den
> > kører ovenpå en pålidelig bytestream, men hvis der sker et
> > pakketab på den nederste TCP forbindelse kunne den øverste
> > retransmitere inden pakken når frem. Jeg har aldrig før
> > overvejet dette, men jeg tror ikke det er et problem, og
> > jeg så ingen symptomer på dette. TCP er indrettet til at
>
> Problemet er blot at ved pakke tab, vil retransmission ske dobbelt.

Ja, man spilder en lille smule båndbredde på den måde.
Men pakketab forekommer vist ikke så ofte, at det gør
noget særligt.

>
> > håndtere forsinkede pakker, der bliver retransmiteret, mens
> > den første udgave stadig er på nettet, så dette vil nok
> > aldrig give alvorlige problemer.
>
> Helst skal VPN løsningen se det som et replay attack, men det bliver
> ikke set som et replay!

Det er ikke et replay, det er en legal retransmition
foretaget af en "trustet" maskine.

>
> > Det hjælper ikke hvis ADSL-modemet kan crackes, så kan
> > man også få det til at sende IPX pakker med spoofede
> > MAC addresser. Dit forslag er så vidt jeg kan se ikke
> > andet end security through obscurity.
>
> Ok, så vi er derhenne hvor ADSL-modemet kan crackes. Det sammen kan en
> VPN løsning vel også? :)

Du kan selv vælge din VPN løsning, det kan du ikke
nødvendigvis med ADSL-modemet. Hvis der ingen
sikkerhedshuller er i ADSL-modemet, er VPN slet ikke
nødvendigt i det konkrete setup. I så fald kan man
blot filtrere pakker på MAC addresse.

Jeg ved ikke hvor stor risikoen er for sikkerheds
problmer i et ADSL-modem.

>
> Er det ikke nemmere at smide ekstra netværkskort i maskinerne, således
> at man kører et internt net på et selvstændigt segment?

Så får du brug for en ekstra IP addresse, og samtidig
skal du sætte en DHCP gateway op og du skal have
nogle ret interessante routetabeller. Men det ville
naturligvis være bedre med et fysisk privat net end
et virtuelt privat net.

>
> > Hvis først man har cracket VPN boksen har man i begge
> > tilfælde straks fri adgang til lokalnettet bagved.
>
> Nix i 4) har man kun adgang til det firewallen tillader!

I din skitse har du placeret VPN boksens interne netkort
direkte på lokalnettet, men det var måske ikke det du
mente. Hvis du placerer VPN boksens interne netkort på
et selvstændigt segment og dermed har endnu et netkort
på firewallen, opnår du selvfølgelig bedre sikkerhed.

LAN
|
+-+--+ +-----+
evt. DMZ | +---+ |
---------+ FW | | VPN |
| +---+ |
+-+--+ +-----+
|
Internet

Dette setup ser jo meget sikkert ud, hvis du stoler på
din firewall. En korrekt implementeret VPN løsning i
firewallen vil fungere på nøjagtigt samme måde. Men hvis
du stoler mere på, at firewallen kan håndtere 4-5 netkort
korrekt end du stoler på, at den kan implementere VPN, så
er det OK med ovenstående netværk. VPN er naturligvis ret
kompliceret, så jeg kan godt forstå. du vælger ovenstående
netværk, hvis sikkerheden er vigtigere end prisen. Og man
kan muligvis også vinde noget ydelse, da man får en
seperat boks til de lidt krævende beregninger som VPN
bruger.

--
Kasper Dupont

Christian E. Lysel (26-12-2001)
Kommentar
Fra : Christian E. Lysel


Dato : 26-12-01 15:19

Kasper Dupont wrote:

>>VPN klienten er almidelige brugere. Fx hjemmearbejdsplads eller mobile
>>brugere.
> Det betyder ikke at sikkerheden er ligegyldig. Man skal
> stadig fokusere på sikkerhed i begge ender.


I mit setup er det Cisco's VPN concentrator, og klienterne skal
forstille at være sikre, jeg blot lige vist at de ikke er :)

> Ja, man spilder en lille smule båndbredde på den måde.
> Men pakketab forekommer vist ikke så ofte, at det gør
> noget særligt.


Kunden kørte på en radio kæde, der var en et par tab hist og her.

>>Helst skal VPN løsningen se det som et replay attack, men det bliver
>>ikke set som et replay!
> Det er ikke et replay, det er en legal retransmition
> foretaget af en "trustet" maskine.


Anyway, et normalt kritere til et VPN system er at den fortæller om
pakker det bliver sendt dobbelt, også selvom det kommer fra en "trustet"
host.

> Jeg ved ikke hvor stor risikoen er for sikkerheds
> problmer i et ADSL-modem.


Der har været huller i ADSL-routere, men jeg har ikke hørt om det i
ADSL-modems.

>>Nix i 4) har man kun adgang til det firewallen tillader!

> I din skitse har du placeret VPN boksens interne netkort
> direkte på lokalnettet, men det var måske ikke det du


Det var en skitse af Cisco's VPN opsætning.

Mit setup i punkt 4, er som du selv tegner det i nedestående.

> mente. Hvis du placerer VPN boksens interne netkort på
> et selvstændigt segment og dermed har endnu et netkort
> på firewallen, opnår du selvfølgelig bedre sikkerhed.
>
> LAN
> |
> +-+--+ +-----+
> evt. DMZ | +---+ |
> ---------+ FW | | VPN |
> | +---+ |
> +-+--+ +-----+
> |
> Internet
>
> Dette setup ser jo meget sikkert ud, hvis du stoler på
> din firewall. En korrekt implementeret VPN løsning i
> firewallen vil fungere på nøjagtigt samme måde. Men hvis
> du stoler mere på, at firewallen kan håndtere 4-5 netkort
> korrekt end du stoler på, at den kan implementere VPN, så
> er det OK med ovenstående netværk. VPN er naturligvis ret
> kompliceret, så jeg kan godt forstå. du vælger ovenstående
> netværk, hvis sikkerheden er vigtigere end prisen. Og man
> kan muligvis også vinde noget ydelse, da man får en
> seperat boks til de lidt krævende beregninger som VPN
> bruger.


Ja, endvidere fortrækker jeg også at smide nogle filtre i Internet routeren.



Kasper Dupont (26-12-2001)
Kommentar
Fra : Kasper Dupont


Dato : 26-12-01 21:32

"Christian E. Lysel" wrote:
>
> > Ja, man spilder en lille smule båndbredde på den måde.
> > Men pakketab forekommer vist ikke så ofte, at det gør
> > noget særligt.
>
> Kunden kørte på en radio kæde, der var en et par tab hist og her.

I mit tilfælde var der ingen kunder, ingen radio kæder
og i øvrigt ingen andre problemer end dårlig performance
og en ustabil firewall på ruten.

>
> >>Helst skal VPN løsningen se det som et replay attack, men det bliver
> >>ikke set som et replay!
> > Det er ikke et replay, det er en legal retransmition
> > foretaget af en "trustet" maskine.
>
> Anyway, et normalt kritere til et VPN system er at den fortæller om
> pakker det bliver sendt dobbelt, også selvom det kommer fra en "trustet"
> host.

Hvis en maskine faktisk sender pakken to gange til VPN
gatewayen må den også gerne komme ud af VPN gatewayen
i den anden ende to gange. Men det vil naturligvis give
mening at forhindre pakkedublikeringer på ruten mellem
de to VPN gateways.

Med det setup, jeg nævnte, har man garanti for, at de
pakker der kommer ind i den ene VPN gateway kommer ud
i den anden ende i samme rækkefølge uden duplikater.

Med et mere fornuftigt connectionless setup vil det
ikke være praktisk muligt at garantere dette, men man
kan opnå en del af det med en simpel anvendelse af
sekvensnumre.

Den afsendende VPN boks tilføjer et 64 bits
sekvensnummer til hver afsendt pakke. Den modtagende
VPN boks accepterer pakker med større sekvensnummer
end den sidste accepterede. Hvis der modtages en
pakke med samme eller lavere sekvensnummer kasseres
den. Dermed har man garanti mod duplikater og
ændringer af rækefølgen, men vil få lidt større
pakketab hvis nettet faktisk ikke leverer pakker i
samme rækkefølge som de er afsendt. Man kan justere
lidt på dette ved at lade VPN boksen vente et
øjeblik med at sende pakker videre, hvis den ser, at
der mangler nogen.

>
> > Jeg ved ikke hvor stor risikoen er for sikkerheds
> > problmer i et ADSL-modem.
>
> Der har været huller i ADSL-routere, men jeg har ikke hørt om det i
> ADSL-modems.

Jeg bruger ikke selv ADSL, så jeg ville ikke kunne
kende forskel på en ADSL-router og et ADSL-modem. Og
der er med garanti andre, der heller ikke kan kende
forskel.

>
> Ja, endvidere fortrækker jeg også at smide nogle filtre i Internet routeren.

Fair nok, den bør være sat op til at forhindre nogle tilfælde
af IP spoofing. Og hvis du kan begrænse nogle tilfælde af
flooding i routeren, vil det også være fint.

--
Kasper Dupont

Notice: By sending SPAM (UCE/BCE) to this address, you are
accepting and agreeing to our charging a $1000 fee, per
email, for handling and processing, and you agree to pay any
and all costs for collecting this fee.

Christian E. Lysel (25-12-2001)
Kommentar
Fra : Christian E. Lysel


Dato : 25-12-01 16:49

Kasper Dupont wrote:

> Hvis man vælger denne løsning, skal hver maskine naturligvis
> have en firewall, der frasorterer de fleste indgående pakker.
> Pakker indpakket af VPN systemet skal accepteres, alt andet
> skal filtreres som man ønsker at filtrere pakker udefra. VPN
> systemet checker signatur, og hvis signaturen accepteres
> sendes pakken igennem firewallen igen, og firewallen kan
> skelne disse pakker fra pakker der er modtaget direkte fra
> netkortet.


Jeg har lige for sjovt kikket på Cisco's VPN klient.

Setup'et er således at alt trafik routeres igennem VPN tunnelen, således
kan der ikke kommunikeres med maskiner der ikke kører VPN eller hvor
trafikken gå igennem VPN'en.

Problemet er blot at pakker fra andre maskiner fiser igennem VPN
klientens "firewall" og ind i klientens TCP/IP stak, "sikkerheden",
består således i at svar fra klienten, routes igennem VPN'en og ud
igennem den centrale firewall i den anden side. Dvs. at der blot er
asymentrisk routning. Selvfølgelig vil en statefull inspection eller
applikationsfirewall, forhindre pakkerne at havne på Internet.

Endvidere er det nemt på en Windows boks at etablere en TCP forbindelse
selvom man kun har envejskommunikations, dvs. fra hacket til klient. På
Windows er det muligt at oprette et TCP handshake og oprette dennes TCP
session, selvom kommunikationen kun er envejs!!!

Jeg antager derfor du ikke snakker om Cisco's VPN klient.

Anyway, hvilken VPN klient snakker du om?



Kasper Dupont (25-12-2001)
Kommentar
Fra : Kasper Dupont


Dato : 25-12-01 21:28

"Christian E. Lysel" wrote:
>
> Kasper Dupont wrote:
>
> > Hvis man vælger denne løsning, skal hver maskine naturligvis
> > have en firewall, der frasorterer de fleste indgående pakker.
> > Pakker indpakket af VPN systemet skal accepteres, alt andet
> > skal filtreres som man ønsker at filtrere pakker udefra. VPN
> > systemet checker signatur, og hvis signaturen accepteres
> > sendes pakken igennem firewallen igen, og firewallen kan
> > skelne disse pakker fra pakker der er modtaget direkte fra
> > netkortet.
>
> Jeg har lige for sjovt kikket på Cisco's VPN klient.
>
> Setup'et er således at alt trafik routeres igennem VPN tunnelen, således
> kan der ikke kommunikeres med maskiner der ikke kører VPN eller hvor
> trafikken gå igennem VPN'en.

Hvad mener du helt præcist med "maskiner der kører VPN"?
Man vil normalt kun have en VPN maskine i hvert fysisk
afsnit af det virtuele netværk. De resterende maskiner
skal så blot bruge denne maskine som deres gateway til
de andre afsnit.

>
> Problemet er blot at pakker fra andre maskiner fiser igennem VPN
> klientens "firewall" og ind i klientens TCP/IP stak, "sikkerheden",
> består således i at svar fra klienten, routes igennem VPN'en og ud
> igennem den centrale firewall i den anden side. Dvs. at der blot er
> asymentrisk routning. Selvfølgelig vil en statefull inspection eller
> applikationsfirewall, forhindre pakkerne at havne på Internet.

Jeg tror ikke helt, jeg forstår, hvordan det netværk
ser ud. Kan du prøve at skitsere netværket.

>
> Endvidere er det nemt på en Windows boks at etablere en TCP forbindelse
> selvom man kun har envejskommunikations, dvs. fra hacket til klient. På
> Windows er det muligt at oprette et TCP handshake og oprette dennes TCP
> session, selvom kommunikationen kun er envejs!!!

Dårlige sequence numbers?

>
> Jeg antager derfor du ikke snakker om Cisco's VPN klient.

Nej.

>
> Anyway, hvilken VPN klient snakker du om?

Jeg snakker om VPN i almindelighed. Jeg vil ikke
benægte at VPN kan være dårligt implementeret eller
dårligt sat op. Jeg har selv prøvet at sætte et VPN
system vha ssh og ppp. Det virker, og der er ingen
problemer med sikkerheden bortset fra evt. fejl i ssh.

Men denne løsning kan ikke anbefales da det giver en
dårlig ydelse, og desuden er det lidt ustabilt fordi
TCP forbindelsen som ssh basserer sig på kan blive
afbrudt. Desuden skal forbindelsen genstartes i begge
ender hvis en af maskinerne har været genstartet.

Et rigtigt VPN system vil kunne løse de nævnte
problemer og opnå samme sikkerhed. Men jeg har ingen
erfaring med konkrete implementationer, jeg kender
kun teorien.

--
Kasper Dupont

Christian E. Lysel (25-12-2001)
Kommentar
Fra : Christian E. Lysel


Dato : 25-12-01 22:02

Kasper Dupont wrote:

>>Jeg har lige for sjovt kikket på Cisco's VPN klient.
>>
>>Setup'et er således at alt trafik routeres igennem VPN tunnelen, således
>>kan der ikke kommunikeres med maskiner der ikke kører VPN eller hvor
>>trafikken gå igennem VPN'en.

> Hvad mener du helt præcist med "maskiner der kører VPN"?


Klienter der kører VPN op imod den samme VPN server, kan typisk se
hinanden, for at hindre dette skal en firewall forhindre dette.

> Man vil normalt kun have en VPN maskine i hvert fysisk
> afsnit af det virtuele netværk. De resterende maskiner
> skal så blot bruge denne maskine som deres gateway til
> de andre afsnit.


Kommer an på formålet!

>>Problemet er blot at pakker fra andre maskiner fiser igennem VPN
>>klientens "firewall" og ind i klientens TCP/IP stak, "sikkerheden",
>>består således i at svar fra klienten, routes igennem VPN'en og ud
>>igennem den centrale firewall i den anden side. Dvs. at der blot er
>>asymentrisk routning. Selvfølgelig vil en statefull inspection eller
>>applikationsfirewall, forhindre pakkerne at havne på Internet.
> Jeg tror ikke helt, jeg forstår, hvordan det netværk
> ser ud. Kan du prøve at skitsere netværket.


LAN -----------------------
| |
|Firewall ------ VPN server
|
Internet
|
VPN klient

Dvs. VPN klienten går igennem Internet og Firewall, ud på et segment
hvor VPN serveren sidder, og herfra ind på LAN'et.

På Internet sidder en 3. part der godt kan sende trafik til VPN
klienten, selvom denne har sin "firewall" slået til!


>>Endvidere er det nemt på en Windows boks at etablere en TCP forbindelse
>>selvom man kun har envejskommunikations, dvs. fra hacket til klient. På
>>Windows er det muligt at oprette et TCP handshake og oprette dennes TCP
>>session, selvom kommunikationen kun er envejs!!!
> Dårlige sequence numbers?


Ja.

>>Anyway, hvilken VPN klient snakker du om?
> Jeg snakker om VPN i almindelighed. Jeg vil ikke
> benægte at VPN kan være dårligt implementeret eller
> dårligt sat op. Jeg har selv prøvet at sætte et VPN
> system vha ssh og ppp. Det virker, og der er ingen
> problemer med sikkerheden bortset fra evt. fejl i ssh.


Og dem har der været mange af!


> Men denne løsning kan ikke anbefales da det giver en
> dårlig ydelse, og desuden er det lidt ustabilt fordi
> TCP forbindelsen som ssh basserer sig på kan blive
> afbrudt. Desuden skal forbindelsen genstartes i begge


TCP er en sessions afhængig protokol og vil derfor retransmittere ved
fejl, derfor bør du ikke have problemer med at forbindelsen skal genstartes.

> ender hvis en af maskinerne har været genstartet.


Dog kan problemet være at du kører:

TCP session - PPP - SSH - TCP Session.

Dvs. at evt. pakketab kan blive retransmitteret af TCP som bærer SSH
trafikken og af TCP session der kører ovenpå PPP.


> Et rigtigt VPN system vil kunne løse de nævnte
> problemer og opnå samme sikkerhed. Men jeg har ingen
> erfaring med konkrete implementationer, jeg kender
> kun teorien.


Hvilken teori?

Den mest udbrede er IPSEC.

IPSEC bygger ikke en digital signatur for hver enkelt pakken, hvilket
også ville fylde alt for meget.

Endvidere løser IPSEC ikke sikkerhedsproblemer omkring routning og
ligende ting.

I teorien er teori og praksis det samme, i praksis er teori og praksis
forskellig.


Elmo Jensen (24-12-2001)
Kommentar
Fra : Elmo Jensen


Dato : 24-12-01 22:14

I indlæg <3c268074$0$89114$edfadb0f@dspool01.news.tele.dk>, skrev stig-
holmberg@tdcadsl.dk følgende....

> Nogen der har en løsning?

Du kan sikkert bruge denne løsning som har været vist tidligere og som
jeg sakser fra:

>Og en eller anden Lars (Tlaloc?) om Windows:
>>Jeps. Under
>>HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\NetTrans\
>>under den relevante adapter (typisk 0000 eller 0001) kan man
>>angive IPAddress & IPMask. Det jeg så brugte som værdier for at
>>få det til at virke var:
>>
>>IPAddress 0.0.0.0,192.168.1.125
>>IPMask 0.0.0.0,255.255.255.0

På den måde skulle dine netkort få to IP adresser istedet for kun et. Et
som de får via DHCP fra TDC og så det interne som du definerer på
ovenstående vis.

Med venlig hilsen
Elmo Jensen
--
[news3@ddibbsystem.dk][www/ftp/telnet.ddibbsystem.dk][ICQ 125572551]
[Fidonet 2:236/35][Virnet 9:451/35][Zyxnet 16:45/35][OS2net 81:445/35]
[STNnet 111:7045/35][Data +45 58853844 v90 / x75][Binkp 80.62.52.180]
[Vi modtager Fidopoints][Hent posten gennem Internettet][Det er nemt!]

Foo Bar (25-12-2001)
Kommentar
Fra : Foo Bar


Dato : 25-12-01 13:46


> Jeg har sat et netværk op med TDC BredBånd, ADSL forbindelse, 4 dynamiske
ip
> adresser, 1 Unex switch, 4 pc´er.
> ...

Jeg har det samme problem og har snakket med en regerende Roms-mester i
netværk om sagerne - og er kommet frem til følgende:

Problemet er at isolere dit 'indre' netværk (dvs. det lokalnet dine PC'ere
sidder i) fra det 'ydre' (dvs. TDC's IP-pulje) - og der er to relativt enkle
metoder til at gøre dette:

1) Skab et alternativt internt fysisk net til dine PC'ere.
Dette kunne f.eks. gøres relativt enkelt og billigt ved at købe 4 ekstra
netkort til dine PC'ere. Hvis du på nuværende tidspunkt har 100 Mb netkort,
kan du sagtens nøjes med at de 'nye' netkort er 10 Mb (der vel trods alt
stadig er billigere?!), idet din ADSL-forbindelse alligevel næppe overstiger
denne hastighed..?! Nu har hver maskine to netkort. Du vælger nu
(selvfølgelig!) de hurtigste netkort til dit 'indre' net og udstyrer dem med
faste IP-adresser der ikke kan routes (f.eks. 10.10.10.x) - og dine maskiner
kan nu 'se hinanden' gennem dette net. Det andet (evt. langsommere) netkort
kan du nu benytte til internet-forbindelser. Husk sikkerheden!

2) Skab et 'VPN-agtigt' netværk.
Indkøb en router. (Desværre har jeg ikke begreb om hvilke modeller der 'er
til noget' - men der er sikkert masser tilstede i dette forum der har input
til dette..!?) Udstyr alle maskinerne med IP-adresser der ikke kan routes -
og lad routeren stå for forbindelsen til internettet. På denne måde kan du
nøjes med en IP-adresse fra TDC idet kun routeren kan 'ses' udefra.
Konceptet hedder "Router on a stick" (da routeren fysisk kommer til at sidde
'parallelt' med dine maskiner og altså ikke i serie med dem...) Emnet er
fyldigere og bedre beskrevet rundt omkring på internettet end jeg kan gøre
det, så her vil jeg forslå dig at lede efter mere information...

Mvh.

Claus



Christian E. Lysel (25-12-2001)
Kommentar
Fra : Christian E. Lysel


Dato : 25-12-01 16:02

Foo Bar wrote:

> Problemet er at isolere dit 'indre' netværk (dvs. det lokalnet dine PC'ere
> sidder i) fra det 'ydre' (dvs. TDC's IP-pulje) - og der er to relativt enkle
> metoder til at gøre dette:
>
> 1) Skab et alternativt internt fysisk net til dine PC'ere.
> Dette kunne f.eks. gøres relativt enkelt og billigt ved at købe 4 ekstra
> netkort til dine PC'ere. Hvis du på nuværende tidspunkt har 100 Mb netkort,
> kan du sagtens nøjes med at de 'nye' netkort er 10 Mb (der vel trods alt
> stadig er billigere?!), idet din ADSL-forbindelse alligevel næppe overstiger
> denne hastighed..?! Nu har hver maskine to netkort. Du vælger nu
> (selvfølgelig!) de hurtigste netkort til dit 'indre' net og udstyrer dem med
> faste IP-adresser der ikke kan routes (f.eks. 10.10.10.x) - og dine maskiner
> kan nu 'se hinanden' gennem dette net. Det andet (evt. langsommere) netkort
> kan du nu benytte til internet-forbindelser. Husk sikkerheden!


Dette giver ikke beskyttelse imod spoofet IP pakker.


> 2) Skab et 'VPN-agtigt' netværk.
> Indkøb en router. (Desværre har jeg ikke begreb om hvilke modeller der 'er
> til noget' - men der er sikkert masser tilstede i dette forum der har input
> til dette..!?) Udstyr alle maskinerne med IP-adresser der ikke kan routes -
> og lad routeren stå for forbindelsen til internettet. På denne måde kan du
> nøjes med en IP-adresse fra TDC idet kun routeren kan 'ses' udefra.


Denne router skal understøtte at hente sin officelle IP adressen fra en
DHCP server.

> Konceptet hedder "Router on a stick" (da routeren fysisk kommer til at sidde
> 'parallelt' med dine maskiner og altså ikke i serie med dem...) Emnet er


Dog kan jeg ikke se argumentet for at sætte den parallelt, istedet kan
jeg se masser af argumenter for at stille den serielt.

> fyldigere og bedre beskrevet rundt omkring på internettet end jeg kan gøre
> det, så her vil jeg forslå dig at lede efter mere information...


Dette giver ikke beskyttelse imod spoofet IP pakker, men hvis du laver
den antagelse at din ISP beskytter imod spoofet IP pakker er dette ikke
noget problem. Hvad med ICMP redirect og så videre?

Dog skal routeren kunne NAT'e interne IP adresse til eksterne IP adresser.



Den nemmeste løsning er at slå alle TCP/IP services fra på klienterne
således at inden services lytter på TCP/IP stakken, nu kan TCP/IP
stakken bruges til almindelig internet trafik.

Den lokale trafik mellem klienterne kan derefter køres i fx IPX, som
ikke kan routes over en IP router.


Niels Andersen (26-12-2001)
Kommentar
Fra : Niels Andersen


Dato : 26-12-01 16:50

"Stig Holmberg" <stig-holmberg@tdcadsl.dk> wrote in message
news:3c268074$0$89114$edfadb0f@dspool01.news.tele.dk...
> Hvad gør man?, humlen i det er at i firewall´en kan man definere "thrusted
> adresses" og har her mulighed for at indtaste ip numre på de andre
maskiner
> i netværket, men da disse jo er dynamiske vil det kun virke indtil de
ændrer
> sig!

Hvad med at give computerne 2 ip-adresser?
Én LAN-adresse, og én WAN-adresse fra DHCP'en.
Så bruges LAN-adressen til LAN-aktivitet, og WAN-adressen til WAN-aktivitet.

Jeg har dog ingen ide om hvorvidt det kan lade sig gøre med de(t) OS('er) du
bruger. Mit umiddelbare gæt er, at det er nemt i Linux, men kan ikke lade
sig gøre i Windows.

--
Mvh.

Niels Andersen



Christian E. Lysel (26-12-2001)
Kommentar
Fra : Christian E. Lysel


Dato : 26-12-01 17:23

Niels Andersen wrote:

> Hvad med at give computerne 2 ip-adresser?
> Én LAN-adresse, og én WAN-adresse fra DHCP'en.
> Så bruges LAN-adressen til LAN-aktivitet, og WAN-adressen til WAN-aktivitet.


Det er nemt nok i windows NT og 2000, LAN siden giver man en virtuel
adresse.


> Jeg har dog ingen ide om hvorvidt det kan lade sig gøre med de(t) OS('er) du
> bruger. Mit umiddelbare gæt er, at det er nemt i Linux, men kan ikke lade
> sig gøre i Windows.


Problemet kommer når man kun vil binde Microsoft fildeling til LAN
siden. Dette er ikke muligt, kun på interfaces og ikke virtuelle interfaces.

Man kan så forsøge sig med microsofts filter regler, dem har jeg blot
ikke tillid til da de i NT4.0 ikke kunne implementere det korrekt.


Kasper Dupont (26-12-2001)
Kommentar
Fra : Kasper Dupont


Dato : 26-12-01 21:40

Niels Andersen wrote:
>
> "Stig Holmberg" <stig-holmberg@tdcadsl.dk> wrote in message
> news:3c268074$0$89114$edfadb0f@dspool01.news.tele.dk...
> > Hvad gør man?, humlen i det er at i firewall´en kan man definere "thrusted
> > adresses" og har her mulighed for at indtaste ip numre på de andre maskiner
> > i netværket, men da disse jo er dynamiske vil det kun virke indtil de ændrer
> > sig!
>
> Hvad med at give computerne 2 ip-adresser?
> Én LAN-adresse, og én WAN-adresse fra DHCP'en.
> Så bruges LAN-adressen til LAN-aktivitet, og WAN-adressen til WAN-aktivitet.

Jeg tror, det er mindst lige så sikkert at filtrere på MAC
addresser. Hvis man kommer udefra, vil det nok være nemmere
at få ADSL-modemet til at videresende pakker med falsk IP
source addresse end en falsk MAC source addresse.

>
> Jeg har dog ingen ide om hvorvidt det kan lade sig gøre med de(t) OS('er) du
> bruger. Mit umiddelbare gæt er, at det er nemt i Linux, men kan ikke lade
> sig gøre i Windows.

Det kan lade sig gøre i Linux. Men jeg ved ikke, om det kan
lade sig gøre i Windows. Hvad er det der "Windows", alle
snakker om, forresten for noget?

--
Kasper Dupont

Notice: By sending SPAM (UCE/BCE) to this address, you are
accepting and agreeing to our charging a $1000 fee, per
email, for handling and processing, and you agree to pay any
and all costs for collecting this fee.

Søg
Reklame
Statistik
Spørgsmål : 177550
Tips : 31968
Nyheder : 719565
Indlæg : 6408823
Brugere : 218887

Månedens bedste
Årets bedste
Sidste års bedste