"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