---

Vi har en Raptor/Symantec Firewall stående (NT-platform)

Vi skal have etableret VPN til hjemmearbejdspladser!

Hvad er bedst / mest sikkert...
- at købe VPN-modul til Firewall'en
eller
- at opstille en dedikeret VPN-gateway lige før firewall'en ?

Er der nogen forskel på, om man adskiller Firewall og VPN-gateway - rent
sikkerhedsmæssigt!

Jeg er ikke så glad for at køre VPN på vores Raptor Firewall, da vi jo af og
til patcher vores NT med nye sikkerhedspatches fra Microsoft... men det er
jo ikke sikkert det betyder noget? Måske har jeg bare paranoia eller hva'
???


Med venlig hilsen

CLAUS HANSEN

---

"CLAUS HANSEN" <claushansen@claushansen.dk> wrote in message
news:HYEU7.1472$aS.224190@news010.worldonline.dk...
> Vi har en Raptor/Symantec Firewall stående (NT-platform)
>
> Vi skal have etableret VPN til hjemmearbejdspladser!
>
> Hvad er bedst / mest sikkert...
> - at købe VPN-modul til Firewall'en
> eller
> - at opstille en dedikeret VPN-gateway lige før firewall'en ?
>
> Er der nogen forskel på, om man adskiller Firewall og VPN-gateway - rent
> sikkerhedsmæssigt!
>
> Jeg er ikke så glad for at køre VPN på vores Raptor Firewall, da vi jo af
og
> til patcher vores NT med nye sikkerhedspatches fra Microsoft... men det er
> jo ikke sikkert det betyder noget? Måske har jeg bare paranoia eller hva'
> ???
>
>
> Med venlig hilsen
>
> CLAUS HANSEN
>

Jeg ville absolut foretrække en enhed for sig til terminering af VPN -
f.eks. en Cisco concentrator, men der findes garanteret andre lignende
produkter !

jeg synes ikke du er paranoid - ial fald ikke mere en rimeligt
--
Med venlig hilsen
Henrik Rask Mortensen

Dette indlæg er sendt som privatperson og repræsenterer
på ingen måde det firma jeg arbejder i.
>
>

---

H. J. R. M. wrote:

> Jeg ville absolut foretrække en enhed for sig til terminering af VPN -
> f.eks. en Cisco concentrator, men der findes garanteret andre lignende
> produkter !


Cisco concentrator klienterne gemme deres opsætning i klar tekst,
hvilket Raptor ikke gør!

Desuden har Cisco concentrator serveren konflikter mellem brugernavn og
gruppenavn, om det kan exploites har jeg ikke haft tid til at undersøge.


> jeg synes ikke du er paranoid - ial fald ikke mere en rimeligt

---

On Fri, 21 Dec 2001 16:09:43 +0100, "Christian E. Lysel"
<chlyshoswmdatapunktumcom@example.net> wrote:

> Cisco concentrator klienterne gemme deres opsætning i klar tekst,

Er det ikke ret ligegyldigt, hvordan konfigurationen gemmes, hvis
man ikke kan bruge informationen i konfigurationen til noget som
helst?

Er du vidende om, at man kan bruge informationen i Ciscos klient-
konfigurationer til noget som helst?

> Desuden har Cisco concentrator serveren konflikter mellem brugernavn og
> gruppenavn, om det kan exploites har jeg ikke haft tid til at undersøge.

"Konflikter mellem brugernavn og gruppenavn"?

-A
--
http://www.hojmark.org/

---

Asbjorn Hojmark wrote:

>>Cisco concentrator klienterne gemme deres opsætning i klar tekst,
> Er det ikke ret ligegyldigt, hvordan konfigurationen gemmes, hvis
> man ikke kan bruge informationen i konfigurationen til noget som
> helst?


Hvorfor kan informationerne i konfigurationsfilen ikke bruges til noget?


Der står IP adresse på VPN server, gruppe navn, gruppe password, bruger
navn og bruger password (bruger password'et kun hvis brugeren beder
klienten at huske dette).

Ovenstående oplysninger kan nemt bruges til at etablere en ny session,
og kan tappes fra maskinen via Microsoft Internet Explorer, der er
masser af Javascript fejl til at hente konfigurationen fra maskinen.

> Er du vidende om, at man kan bruge informationen i Ciscos klient-
> konfigurationer til noget som helst?


Ja, de er ikke krypteret, og hvis du mener de er, kan så ikke venligst
forklarer hvordan?

>>Desuden har Cisco concentrator serveren konflikter mellem brugernavn og
>>gruppenavn, om det kan exploites har jeg ikke haft tid til at undersøge.
> "Konflikter mellem brugernavn og gruppenavn"?


Opret en gruppe med navnet: christian
Opret en bruger med navnet: christian

Nu kan brugeren christian ikke logger på fordi hans password er forkert,
selvom han taster det rigtige password. Det kalder jeg en konflikt.

Jeg har kun testet ovennævnte med RADIUS brugere, dvs. at brugeren er
oprettet i RADIUS serveren.

---

On Sun, 23 Dec 2001 00:16:06 +0100, "Christian E. Lysel"
<chlyshoswmdatapunktumcom@example.net> wrote:

>>>Cisco concentrator klienterne gemme deres opsætning i klar tekst,

>> Er det ikke ret ligegyldigt, hvordan konfigurationen gemmes, hvis
>> man ikke kan bruge informationen i konfigurationen til noget som
>> helst?

> Der står IP adresse på VPN server, gruppe navn, gruppe password,
> bruger navn og bruger password (bruger password'et kun hvis brugeren
> beder klienten at huske dette).

Der står normalt en IP-adresse på VPN-serveren og et gruppenavn i
klar text. Desuden står der et krypteret gruppepassword.

Jeg er ikke bekendt med at krypteringen af gruppepassword skulle
være blevet brudt. Er du det?

Brugernavn og krypteret password *kan* stå der, hvis administra-
toren tillader brugeren at gemme det. Hvis man synes, krypterin-
gen i konfigurationsfilen er For Usikker(TM), kan man undlade at
give brugeren ret til at gemme det.

Sikkerheden er minimum baseret på, at man kender IP-adressen,
gruppenavn og -password samt brugernavn og password, og på en
rimeligt konfigureret box har man fra konfigurationsfilen en
IP-adresse og et gruppenavn i klartext samt et krypteret gruppe-
password. Der er for mig at se temmelig langt derfra til at man
er 'på', fordi man mangler et brugernavn og et password.

.... Og passwordet kan man jo helt undlade og bruge tokens, hvis
man foretrækker noget two-factor.

>> Er du vidende om, at man kan bruge informationen i Ciscos klient-
>> konfigurationer til noget som helst?

> Ja, de er ikke krypteret, og hvis du mener de er, kan så ikke
> venligst forklarer hvordan?

Jeg ved ikke, *hvordan* de er krypteret, men kan blot konstatere,
at *jeg* ikke kan læse dem. (Gruppepassword står i min konfig som
112 hex-cifre).

>> "Konflikter mellem brugernavn og gruppenavn"?

> Opret en gruppe med navnet: christian
> Opret en bruger med navnet: christian
>
> Nu kan brugeren christian ikke logger på fordi hans password er forkert,

Ja, det er godt nok ikke særlig smart. Men jeg kan ikke komme i
tanker om en situation, hvor jeg ville lave gruppenavne, der var
det samme som brugernavnene.

-A
--
http://www.hojmark.org/

---

Asbjorn Hojmark wrote:


> Jeg er ikke bekendt med at krypteringen af gruppepassword skulle
> være blevet brudt. Er du det?


Hvad er nøglen til denne kryptering?

Hvornår indtaster brugeren denne nøgle?

På Raptor mobile, opretter brugeren en lokale brugerprofil til den
lokale klient. Denne brugere profil bruges til at kryptere en
brugerdatabase. Brugerdatabasen indholder brugere profiler til VPN
serverne brugeren skal bruge.


> Brugernavn og krypteret password *kan* stå der, hvis administra-
> toren tillader brugeren at gemme det. Hvis man synes, krypterin-
> gen i konfigurationsfilen er For Usikker(TM), kan man undlade at
> give brugeren ret til at gemme det.


Ja.


> Sikkerheden er minimum baseret på, at man kender IP-adressen,
> gruppenavn og -password samt brugernavn og password, og på en
> rimeligt konfigureret box har man fra konfigurationsfilen en
> IP-adresse og et gruppenavn i klartext samt et krypteret gruppe-
> password. Der er for mig at se temmelig langt derfra til at man
> er 'på', fordi man mangler et brugernavn og et password.


Men man er kommet et godt stykke af vejen.

Desuden mangler man typisk kun brugernavnet.

Endvidere er gruppenavnet og gruppe passwordet ikke blot det man i andre
VPN løsninger kalder "shared secret"? Hvis det er tilfældet falder hele
sikkerheden til jorden da en 3. person kan dekryptere alt.


> ... Og passwordet kan man jo helt undlade og bruge tokens, hvis
> man foretrækker noget two-factor.


Ja.

>>>Er du vidende om, at man kan bruge informationen i Ciscos klient-
>>>konfigurationer til noget som helst?
>>Ja, de er ikke krypteret, og hvis du mener de er, kan så ikke
>>venligst forklarer hvordan?


> Jeg ved ikke, *hvordan* de er krypteret, men kan blot konstatere,
> at *jeg* ikke kan læse dem. (Gruppepassword står i min konfig som
> 112 hex-cifre).


Men kan du ikke blot kopiere dem over i en anden konfigurations fil på
en anden maskine?

Eller lad mig vende den om, hvorfor sender du ikke gruppepasswordets 112
hex-cifre ud i denne gruppe, hvis det er ubrydeligt.

>>>"Konflikter mellem brugernavn og gruppenavn"?
>>>
>
>>Opret en gruppe med navnet: christian
>>Opret en bruger med navnet: christian
>>
>>Nu kan brugeren christian ikke logger på fordi hans password er forkert,
>>
>
> Ja, det er godt nok ikke særlig smart. Men jeg kan ikke komme i
> tanker om en situation, hvor jeg ville lave gruppenavne, der var
> det samme som brugernavnene.


Hvis du opretter en gruppe pr. bruger.

Dog kan den omgåes nemt, ved at kalde gruppen christian_group.

Min pointe er blot at det ikke er smart, og om der eksitere flere "fejl"
ved jeg ikke, jeg har blot opdaget det ved tilfælde.

At boksen understøtter PPTP, taler ikke til dens fordel som et
sikkerhedsprodukt.

---

On Sun, 23 Dec 2001 01:04:59 +0100, "Christian E. Lysel"
<chlyshoswmdatapunktumcom@example.net> wrote:

>> Jeg er ikke bekendt med at krypteringen af gruppepassword skulle
>> være blevet brudt. Er du det?

Da du 'svarede' på dette med spørgsmål, tager jeg det som et nej.

>> Sikkerheden er minimum baseret på, at man kender IP-adressen,
>> gruppenavn og -password samt brugernavn og password, og på en
>> rimeligt konfigureret box har man fra konfigurationsfilen en
>> IP-adresse og et gruppenavn i klartext samt et krypteret gruppe-
>> password. Der er for mig at se temmelig langt derfra til at man
>> er 'på', fordi man mangler et brugernavn og et password.

> Men man er kommet et godt stykke af vejen.

Ja, hvis vi forudsætter at brugernavn og password skulle være
trivielle at gætte. Det mener jeg ikke er en rimelig forudsæt-
ning. (Og som sagt, hvis man ønsker det sikrere, er der ikke
noget til hinder for det).

> Desuden mangler man typisk kun brugernavnet.

Hvor skulle man få passwordet fra?

> Endvidere er gruppenavnet og gruppe passwordet ikke blot det man i andre
> VPN løsninger kalder "shared secret"? Hvis det er tilfældet falder hele
> sikkerheden til jorden da en 3. person kan dekryptere alt.

Gruppenavn og password er basalt set kun beregnede til at defi-
nere, hvad gruppen må, ikke om man kan få en VPN-forbindelse in
the first place.

> At boksen understøtter PPTP, taler ikke til dens fordel som et
> sikkerhedsprodukt.

At boxen *også* understøtter setups, hvor ultimativ sikkerhed
ikke er afgørende, taler i min begrebsverden ikke som en ulempe.

-A
--
http://www.hojmark.org/

---

Asbjorn Hojmark wrote:

>>>Jeg er ikke bekendt med at krypteringen af gruppepassword skulle
>>>være blevet brudt. Er du det?
> Da du 'svarede' på dette med spørgsmål, tager jeg det som et nej.


Hvorfor skal man bryde "krypteringen", hvis man blot kan kopiere den
"krypteret" streng, over på en anden klient?

At det en kryptering, tvivler jeg på, da klienten ikke selv kan finde på
en hemlig nøgle ud i den blå luft!!

>>>Sikkerheden er minimum baseret på, at man kender IP-adressen,
>>>gruppenavn og -password samt brugernavn og password, og på en
>>>rimeligt konfigureret box har man fra konfigurationsfilen en
>>>IP-adresse og et gruppenavn i klartext samt et krypteret gruppe-
>>>password. Der er for mig at se temmelig langt derfra til at man
>>>er 'på', fordi man mangler et brugernavn og et password.


>>Men man er kommet et godt stykke af vejen.


> Ja, hvis vi forudsætter at brugernavn og password skulle være
> trivielle at gætte. Det mener jeg ikke er en rimelig forudsæt-
> ning. (Og som sagt, hvis man ønsker det sikrere, er der ikke
> noget til hinder for det).


Vi ser en del scanninger på kun Port 500/UDP og 50/IP.

Men den sikring der kan fortages er på brugervalideringen, hvilket ikke
har noget med krypteringen af VPN forbindelsen af gøre. Hvis "Shared
secret"'en som jeg antager længere nede, i virkeligheden er
gruppe-begrebet, og gruppe-oplysningerne ligger i en tekst fil, så kan
3. mand aflytte VPN kommunikationen, og evt. overtage sessionen.

>>Desuden mangler man typisk kun brugernavnet.


> Hvor skulle man få passwordet fra?


Jeg mente passwordet, men skrev brugernavnet :)

>>Endvidere er gruppenavnet og gruppe passwordet ikke blot det man i andre
>>VPN løsninger kalder "shared secret"? Hvis det er tilfældet falder hele
>>sikkerheden til jorden da en 3. person kan dekryptere alt.
> Gruppenavn og password er basalt set kun beregnede til at defi-
> nere, hvad gruppen må, ikke om man kan få en VPN-forbindelse in
> the first place.


Problemet er blot at den brugere gruppe-begrebet til ovenstående, og at
det kan hentes fra konfigurations filen.

Da der i konfigurationsfilen ikke noget sted hvor du kan taste et
"shared secret", antager jeg at gruppe-begrebet også bruges som "shared
secret".

Hvis dette er tilfældet (hvilket kun er en antagelse), falder
sikkerheden til jorden, da VPN krypteringen kan aflyttes af 3. part i
real time, med almidelig CPU-kraft.

>>At boksen understøtter PPTP, taler ikke til dens fordel som et
>>sikkerhedsprodukt.
> At boxen *også* understøtter setups, hvor ultimativ sikkerhed
> ikke er afgørende, taler i min begrebsverden ikke som en ulempe.

Hvad med at filter reglernes virke, ændres fra en software release til
en anden?

Generelt er boksen nem at sætte usikkert op, istedet for blot at
understøtte én sikker metode.

---

> >>>Sikkerheden er minimum baseret på, at man kender IP-adressen,
> >>>gruppenavn og -password samt brugernavn og password, og på en
> >>>rimeligt konfigureret box har man fra konfigurationsfilen en
> >>>IP-adresse og et gruppenavn i klartext samt et krypteret gruppe-
> >>>password. Der er for mig at se temmelig langt derfra til at man
> >>>er 'på', fordi man mangler et brugernavn og et password.
>
>

Er det ikke smartere at bruge certifikater istedet for grupper
Det er vel lidt sværere at skulle have fat i et certifikat i stedet for et
gruppenavn

Mvh
Lars

---

On Sun, 23 Dec 2001 15:38:40 +0100, "Lars Soerensen"
<Lars-Hammond@get2net.dk> wrote:

> Er det ikke smartere at bruge certifikater istedet for grupper

Jo.

-A
--
http://www.hojmark.org/

---

Lars Soerensen wrote:

> Er det ikke smartere at bruge certifikater istedet for grupper
> Det er vel lidt sværere at skulle have fat i et certifikat i stedet for et
> gruppenavn


Hvorfor?

---

On Sun, 23 Dec 2001 13:32:02 +0100, "Christian E. Lysel"
<chlyshoswmdatapunktumcom@example.net> wrote:

> Hvorfor skal man bryde "krypteringen", hvis man blot kan kopiere
> den "krypteret" streng, over på en anden klient?

Jeg kan ikke se, det skulle være anderledes end alle andre ste-
der, hvor man anvender preshared keys. Jeg er heller ikke uenig
i, at der er nogle principielle sikkerhedsproblemer med preshared
keys.

Men jeg forventer, at sikkerhedsadministratoren tager stilling
til dette før han vælger at bruge preshared keys. Og hvis han
finder, sikkerheden i det ikke er god nok, så kan han bruge noget
andet, fx. certifikater.

> Da der i konfigurationsfilen ikke noget sted hvor du kan taste et
> "shared secret", antager jeg at gruppe-begrebet også bruges som "shared
> secret".

Det er SVJV ikke korrekt. Man kan angive en fall-back preshared
key, hvis man har udstyr, der ikke understøtter gruppebegrebet.
Men jeg skal indrømme, at jeg ikke kender detaljerne.

> Hvad med at filter reglernes virke, ændres fra en software release til
> en anden?
>
> Generelt er boksen nem at sætte usikkert op, istedet for blot at
> understøtte én sikker metode.

Så din pointe er i virkeligheden, at du foretrækker boxe, der
ikke kan mere end én ting? Det kan jeg da godt følge dig i et
stykke ad vejen.

Men så forstår jeg blot ikke, hvorfor du som modsætning til
Ciscos VPN3000 nævnte Raptor, der udover at være VPN-koncentrator
også agerer firewall, content security device, DNS-server and
whatnot.

-A
--
http://www.hojmark.org/

---

Asbjorn Hojmark wrote:

>>Hvorfor skal man bryde "krypteringen", hvis man blot kan kopiere
>>den "krypteret" streng, over på en anden klient?

> Jeg kan ikke se, det skulle være anderledes end alle andre ste-
> der, hvor man anvender preshared keys. Jeg er heller ikke uenig
> i, at der er nogle principielle sikkerhedsproblemer med preshared
> keys.


I Raptor Mobile klienten er alle oplysninger krypteret, og brugeren skal
logge ind i VPN klienten for at kunne bruge disse oplysninger.


> Men jeg forventer, at sikkerhedsadministratoren tager stilling
> til dette før han vælger at bruge preshared keys. Og hvis han
> finder, sikkerheden i det ikke er god nok, så kan han bruge noget
> andet, fx. certifikater.


Hvad hjælper certifikater?

Certifikater er godt hvis de ikke ligger på klient maskinen, eller hvis
de ligger krypteret hvor brugeren skal enable det vha. et password.

Men i modsatte tilfælde, har der været for mange huller i Explorer til
at certifikater/filer ligger sikkert på en windows maskines harddisk.


>>Da der i konfigurationsfilen ikke noget sted hvor du kan taste et
>>"shared secret", antager jeg at gruppe-begrebet også bruges som "shared
>>secret".
> Det er SVJV ikke korrekt. Man kan angive en fall-back preshared
> key, hvis man har udstyr, der ikke understøtter gruppebegrebet.
> Men jeg skal indrømme, at jeg ikke kender detaljerne.


Gruppe begrebet eksistere ikke i IPSEC, derfor antager jeg de bruger
sharedsecret til bruger begrebet, og dermed kan lave denne "udvidelse"
af IPSEC.

>>Hvad med at filter reglernes virke, ændres fra en software release til
>>en anden?
>>
>>Generelt er boksen nem at sætte usikkert op, istedet for blot at
>>understøtte én sikker metode.


> Så din pointe er i virkeligheden, at du foretrækker boxe, der
> ikke kan mere end én ting? Det kan jeg da godt følge dig i et
> stykke ad vejen.


Jeg fortrækker en boks der er sikker pr. default, hvor man ikke skal ind
og disable support for PPTP og andre ting. Og som ikke tillader man
enabler usikre ting, som ICMP redirect, RIP, PPTP, ectetera.


> Men så forstår jeg blot ikke, hvorfor du som modsætning til
> Ciscos VPN3000 nævnte Raptor, der udover at være VPN-koncentrator
> også agerer firewall, content security device, DNS-server and
> whatnot.


Nu kan man jo også bruge en Raptor som kun VPN server, således at man
disabler de andre funktioner.

Content security device passer ikke.

DNS-server, dette er faktisk vigtigt, da næsten alle andre firewalls på
markede ikke beskytter imod DNS-spoofing!!

Jeg er dog enig i at jo mere en firewall kører af applikationer, jo mere kan den exploites. Problemet med Raptoren

er blot at den er en af de ældste Windows firewalls, men kun én exploit,
og få DoS, hvilket er en historie andre firewalls ikke har.

Endvidere kan man styrer sine brugere således at de fra domain
controlleren kun må validere sig, fra filserveren kun må læse filer.
Denne styring kan fortages på bruger eller gruppe niveau.

Og gruppe begrebet er implementeret rigtigt, ved at brugeren er knyttet
en eller flere grupper.


Checkpoint blev exploited meget omkring jan-aug 2000 og har haft mange
exploits. PIX'en har også haft mange fejl.

Raptoren har haft, http://www.securityfocus.com/archive/1/171335,
hvilket set fra RFC'en ikke er en exploit.

Problemet med at bruge Raptor firewallen som VPN serveren, er at den
ikke er alt for fleksibel, fx virker nogle netværkskort ikke, da
firewallen og vpn klienten snakker direkte med netværkskorts driveren.
Firewallen og vpn klienten har så en virtuel netværkskortsdriver der
snakker med NT's TCP/IP stak.

---

On Mon, 24 Dec 2001 12:56:22 +0100, "Christian E. Lysel"
<chlyshoswmdatapunktumcom@example.net> wrote:

> Hvad hjælper certifikater?

De hjælper da noget ved at være personlige, fremfor at være
tildelt en gruppe af personer.

> Certifikater er godt hvis de ikke ligger på klient maskinen, eller
> hvis de ligger krypteret hvor brugeren skal enable det vha. et
> password.

Man kan jo også bruge certifikater på smart cards.

.... Og ellers er det som sagt muligheden for at bruge tokens.

> Gruppe begrebet eksistere ikke i IPSEC, derfor antager jeg de
> bruger sharedsecret til bruger begrebet, og dermed kan lave denne
> "udvidelse" af IPSEC.

Ja, det er også sådan jeg forstår det.

> Jeg fortrækker en boks der er sikker pr. default, hvor man ikke
> skal ind og disable support for PPTP og andre ting. Og som ikke
> tillader man enabler usikre ting, som ICMP redirect, RIP, PPTP,
> ectetera.

Et hvilket som helst system, og altså ikke blot sikkerhedsudstyr,
er ikke mere sikkert end den person der konfigurerer det udfra
den politik, der nu engang er besluttet.

At fx. et operativsystem giver mulighed for at administratoren
kan slette alle data, gør det ikke i min begrebsverden til et
dårligt operativsystem.

> Nu kan man jo også bruge en Raptor som kun VPN server, således
> at man disabler de andre funktioner.

Det er netop min pointe. Man kan konfigurere systemerne, så de
lever op til ens sikkerhedspolitik. At et system giver nogle
muligheder, som man vælger ikke at bruge, gør det ikke til et
dårligt system.

> Content security device passer ikke.

Jeg tænkte på WebNOT / NewsNOT. Som jeg forstår det, kan man
bruge det til at definere politiker for indhold, men jeg er ikke
Raptor-mand, så jeg kan have misforstået det.

> DNS-server, dette er faktisk vigtigt, da næsten alle andre
> firewalls på markede ikke beskytter imod DNS-spoofing!!

Jeg er ikke enig med dig i, at DNS hører hjemme på en firewall,
men pointen var igen blot, at systemerne indeholder funktiona-
litet, som man ikke i alle tilfælde er interesseret i at anvende.


Blot for at sikre mod misforståelser: Er du enig eller uenig i,
at en VPN3000 concentrator kan konfigureres ca. så sikkert til
access VPN, som man måtte ønske sig?

-A
--
http://www.hojmark.org/

---

Asbjorn Hojmark wrote:

>>Jeg fortrækker en boks der er sikker pr. default, hvor man ikke
>>skal ind og disable support for PPTP og andre ting. Og som ikke
>>tillader man enabler usikre ting, som ICMP redirect, RIP, PPTP,
>>ectetera.

> Et hvilket som helst system, og altså ikke blot sikkerhedsudstyr,
> er ikke mere sikkert end den person der konfigurerer det udfra
> den politik, der nu engang er besluttet.
>
> At fx. et operativsystem giver mulighed for at administratoren
> kan slette alle data, gør det ikke i min begrebsverden til et
> dårligt operativsystem.


Men et operativsystem, der selv sletter tilfældige filer pr. default er
vel dårligt?

Eller et operativsystem, der kan konfigurers i grænsefladen til at
slette tilfældige filer, er det dårligt?

Jeg fortrækker stadigvæk at en firewall er sikker pr. default.

>>Nu kan man jo også bruge en Raptor som kun VPN server, således
>>at man disabler de andre funktioner.
> Det er netop min pointe. Man kan konfigurere systemerne, så de
> lever op til ens sikkerhedspolitik. At et system giver nogle
> muligheder, som man vælger ikke at bruge, gør det ikke til et
> dårligt system.


Nej.

>>Content security device passer ikke.
> Jeg tænkte på WebNOT / NewsNOT. Som jeg forstår det, kan man
> bruge det til at definere politiker for indhold, men jeg er ikke
> Raptor-mand, så jeg kan have misforstået det.


For http og nntp er den god nok, er det muligt at styre URL'er og
nyhedsgrupper, ellers ikke.

Men jeg vil ikke kalde det content security, da der er meget overfladisk.

>>DNS-server, dette er faktisk vigtigt, da næsten alle andre
>>firewalls på markede ikke beskytter imod DNS-spoofing!!
> Jeg er ikke enig med dig i, at DNS hører hjemme på en firewall,


Mange installation kan stadigvæk i dag angribes vha. af DNS-spoofing!

Derfor mener jeg det bør ligge i en firewall.

At Raptor/Axent/Symantec kan finde ud af at kode en DNS server der ikke
har været sårbar siden den første version, ligesom D. J. Bernstein's
djbdns, er godt gået i forhold til andre DNS producenter.

> men pointen var igen blot, at systemerne indeholder funktiona-
> litet, som man ikke i alle tilfælde er interesseret i at anvende.


> Blot for at sikre mod misforståelser: Er du enig eller uenig i,
> at en VPN3000 concentrator kan konfigureres ca. så sikkert til
> access VPN, som man måtte ønske sig?

Ja, jeg er enig, men ikke helt da det på klienten ikke er muligt at
"gemme" alle oplysningerne. Stærk brugervalidering i form af token eller
certifikater lagret offline, hjælpe. Dog kan gruppebegrebet kun bruges i
filterregler, og ikke på applikationslaget.

---

Christian E. Lysel <chlyshoswmdatapunktumcom@example.net> wrote:
> Asbjorn Hojmark wrote:
>> Jeg er ikke enig med dig i, at DNS hører hjemme på en firewall,
>
> Mange installation kan stadigvæk i dag angribes vha. af DNS-spoofing!
>
> Derfor mener jeg det bør ligge i en firewall.

Hvis en installation kan angribes vha. DNS spoofing tyder det paa nogle
alvorlige problemer i implementationen af sikkerhedspolitikken (firewall
reglerne).

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

---

Alex Holst wrote:

> Hvis en installation kan angribes vha. DNS spoofing tyder det paa nogle
> alvorlige problemer i implementationen af sikkerhedspolitikken (firewall
> reglerne).

Hvorfor?

Firewall reglerne tillader typisk at man kan lave en dns-forspørgelse
til det store Internet. Hvis svaret der kommer tilbage, kommer fra den
rigtige IP adresse, vil firewallen tillade trafikken, også selvom svaret
indeholder et spoofet DNS svar. Firewallen kikker nemlig ikke på
indholdet af DNS forspørgelsen eller DNS svaret og sammenligner disse.

Ovenstående er forudsat at vi snakker om filter- eller statefull
inspection firewalls og ikke applikation firewalls (der vil forhindre
angrebet).

---

Christian E. Lysel <chlyshoswmdatapunktumcom@example.net> wrote:
> Alex Holst wrote:
>> Hvis en installation kan angribes vha. DNS spoofing tyder det paa nogle
>> alvorlige problemer i implementationen af sikkerhedspolitikken (firewall
>> reglerne).
>
> Hvorfor?

Fordi jeg tolkede dit tidligere indlaeg til at mene, at en simpel spoofing
af DNS svar gjorde at en angriber kunne liste pakker forbi firewallen, men:

> Firewall reglerne tillader typisk at man kan lave en dns-forspørgelse
> til det store Internet. Hvis svaret der kommer tilbage, kommer fra den
> rigtige IP adresse, vil firewallen tillade trafikken, også selvom svaret
> indeholder et spoofet DNS svar. Firewallen kikker nemlig ikke på
> indholdet af DNS forspørgelsen eller DNS svaret og sammenligner disse.

Efter at have laest dette kan jeg slet ikke foelge din tankegang. Hvordan
ser de relevante dele af netvaerket ud i dette tilfaelde, hvilket angreb
taler vi om, og hvordan mener du at en name server paa firewallen forhindrer
angrebet?

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

---

Alex Holst wrote:

> Efter at have laest dette kan jeg slet ikke foelge din tankegang. Hvordan
> ser de relevante dele af netvaerket ud i dette tilfaelde, hvilket angreb
> taler vi om, og hvordan mener du at en name server paa firewallen forhindrer
> angrebet?


Forstil dig to netværk, ISP og LAN. Imellem ISP og LAN sidder en firewall.

På ISP sidder en DNS server og en ond hacker. På LAN sidder en intern
DNS server, og dennes klienter.

hackeren har købt domainet, mircosoft.com.

En bruger på LAN'er kan ikke stave til microsoft og kommer derfor til at
taste www.mircosoft.com. Denne host på LAN'et spørger nu sin lokale DNS
server som derefter spørger en DNS server hos ISP, hvad
www.mircosoft.com er. DNS serveren svarer at "www.mircosoft.com er
3.4.5.6 og at ftp.openbsd.org er 6.7.8.9".

En anden bruger på LAN'er, vi kan kalde ham Alex, skal nu ud og hente
OpenBSD 3.1, men den lokale DNS server har cachet ftp.openbsd.org fra
sidste DNS forspørgelse, derfor vil Alex nu havne hos den onde hacker. :)

3.4.5.6 er microsoft's rigtige ip adresse, så brugeren ikke fatter mistanke.

6.7.8.9 er den onde hackers ip adresse.




En applicationlevel firewall vil undre sig over at få svaret omkring
ftp.openbsd.org, når der spørges på www.mircosoft.com. Derfor smide
firewallen svaret over højre skulder således at det lander i /dev/null
istedet for hos klienten.

DNS spoofing kan ske på mange måder, ovenstående er blot en måde.


En anden type fejl kunne være:

http://google.com%1b.snoop.anonymizer.com/cgi-bin/show_cookie3.cgi

I dette tilfælde resolver google.com%1b.snoop.anonymizer.com til en IP
adresse hos anonymizer.com, IE tror dog den snakker med google.com og
giver derfor gladeligt sine cookies til anonymizer's webserver. Dette
ville også undgåes med en applikations firewall.

Udover ovenstående beskytte en applikationsfirewall imod mange andre
angreb hvor en filter/statefull inspection firewall må give op.

---

Christian E. Lysel <chlyshoswmdatapunktumcom@example.net> wrote:
> Alex Holst wrote:
>
>> Efter at have laest dette kan jeg slet ikke foelge din tankegang. Hvordan
>> ser de relevante dele af netvaerket ud i dette tilfaelde, hvilket angreb
>> taler vi om, og hvordan mener du at en name server paa firewallen forhindrer
>> angrebet?
>
> Forstil dig to netværk, ISP og LAN. Imellem ISP og LAN sidder en firewall.
[snip forklaring af DNS cache poisoning]

SSL, TSL og lignende bliver brugt netop af denne aarsag, som du sikkert ved.
DNS er ikke noget man stoler paa. Dette er et kendt og gammelt problem.
Ingen grund til at goere noget stort ud af det.

> En applicationlevel firewall vil undre sig over at få svaret omkring

Hm. Jeg betragter ikke en firewall med en name server koerende som en
applikationsfirewall.

> En anden type fejl kunne være:
>
> http://google.com%1b.snoop.anonymizer.com/cgi-bin/show_cookie3.cgi

Soedt. Jeg har ikke ActiveX, JavaScript og andre ting slaaet til i min
Internet zone.

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

---

Alex Holst wrote:

>>Forstil dig to netværk, ISP og LAN. Imellem ISP og LAN sidder en firewall.
> [snip forklaring af DNS cache poisoning]
> SSL, TSL og lignende bliver brugt netop af denne aarsag, som du sikkert ved.
> DNS er ikke noget man stoler paa. Dette er et kendt og gammelt problem.
> Ingen grund til at goere noget stort ud af det.


Men løser ikke ovenstående!

Du har misforstået ovenstående, jeg skriver om et dns opslag der giver 2
svar, hvor den ene er en forgiftning af dns-serverens cache.

Desuden hvor mange brugere ringer til webmasteren hvis et SSL certificat
er ugyldigt?


>>En applicationlevel firewall vil undre sig over at få svaret omkring
> Hm. Jeg betragter ikke en firewall med en name server koerende som en
> applikationsfirewall.


Hvem skrev det er en firewall med en name server?

>>En anden type fejl kunne være:
>>http://google.com%1b.snoop.anonymizer.com/cgi-bin/show_cookie3.cgi
> Soedt. Jeg har ikke ActiveX, JavaScript og andre ting slaaet til i min
> Internet zone.


Det er ingen af ovenstående der udnyttes, blot at browseren sender de
forkerte cookies!!

---

Christian E. Lysel <chlyshoswmdatapunktumcom@example.net> wrote:
> Du har misforstået ovenstående, jeg skriver om et dns opslag der giver 2
> svar, hvor den ene er en forgiftning af dns-serverens cache.

Hvis ham Alex forsoegte at kontakte ftp.openbsd.org ville hans ftp klient
tale til den forkerte maskine, ja.

Men hvis han ikke stolede paa den slags ville han bruge rsync over ssh til
at hente en kopi af CVS repository fra en maskine han stoler paa, og kompile
den selv. Det var min pointe. Hvis man har noget naevnevaerdigt at tabe ved
at hente ondt software ned fra en ond server, boer man tage passende
forbehold.

> Desuden hvor mange brugere ringer til webmasteren hvis et SSL certificat
> er ugyldigt?

Omtrent lige saa mange som ringer til politiet naar de ser en bil slingre
ned af vejen, gaetter jeg paa.

>> Hm. Jeg betragter ikke en firewall med en name server koerende som en
>> applikationsfirewall.
>
> Hvem skrev det er en firewall med en name server?

Det gjorde du tidligere, og derfor gjorde jeg det ogsaa da jeg bad dig
uddybe.

>>>En anden type fejl kunne være:
>>>http://google.com%1b.snoop.anonymizer.com/cgi-bin/show_cookie3.cgi
>> Soedt. Jeg har ikke ActiveX, JavaScript og andre ting slaaet til i min
>> Internet zone.
>
> Det er ingen af ovenstående der udnyttes, blot at browseren sender de
> forkerte cookies!!

Jeg smed ikke en sniffer paa. Jeg fik blot et tomt vindue, og View source
viste et tomt HTML dokument (korrekte headers, men ingen naevnevaerdig
body).


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

---

Alex Holst wrote:

> Men hvis han ikke stolede paa den slags ville han bruge rsync over ssh til
> at hente en kopi af CVS repository fra en maskine han stoler paa, og kompile
> den selv. Det var min pointe. Hvis man har noget naevnevaerdigt at tabe ved
> at hente ondt software ned fra en ond server, boer man tage passende
> forbehold.


Eller købe CDROM'en :)

Hvis nu det var et antivirus produkt med over 50% markets-andel, der
automatisk downloader en zip-fil, for derefter at pakke denne ud, for
derefter at kører en exe-fil, uden nogle check, ville det så ikke været
et _stort_ problem. Hvilket nok er tilfældet for 20% af alle
IT-installationer i dag.

>>Desuden hvor mange brugere ringer til webmasteren hvis et SSL certificat
>>er ugyldigt?

> Omtrent lige saa mange som ringer til politiet naar de ser en bil slingre
> ned af vejen, gaetter jeg paa.


Flere ville nok ringe til politiet, specielt efter udbredelse af GSM
telefoner.

Og så er der skod implementationer af ssh.

Og Microsoft der ikke understøttede blacklistning af certifikater der
var kommet i forkerte hånder. Understøttelsen kom først efter der blev
stjålet Microsoft certifikater :)

>>>Hm. Jeg betragter ikke en firewall med en name server koerende som en
>>>applikationsfirewall.
>>Hvem skrev det er en firewall med en name server?
> Det gjorde du tidligere, og derfor gjorde jeg det ogsaa da jeg bad dig
> uddybe.


Hov, hov, den har både en DNS server og en DNS proxy.

Jeg rosede blot at den har lige så mange funde fejl som djbdns :)

>>Det er ingen af ovenstående der udnyttes, blot at browseren sender de
>>forkerte cookies!!
> Jeg smed ikke en sniffer paa. Jeg fik blot et tomt vindue, og View source
> viste et tomt HTML dokument (korrekte headers, men ingen naevnevaerdig
> body).


Det lader også til at det er rettet efterhånden i nyere IE browsere.


Men udover dette, er det en dejlig fejl.

---

"Christian E. Lysel" <chlyshoswmdatapunktumcom@example.net>
wrote:

>En applicationlevel firewall vil undre sig over at få svaret omkring
>ftp.openbsd.org, når der spørges på www.mircosoft.com.

Jeg indrømmer at jeg ikke er 100% sikker, men jeg er dog næsten
sikker på at det vil den lokale DNS-server også hvis den er en
blot nogenlunde ny BIND. Det betyder selvfølgelig at man bør
lade alle sine DNS-opslag gå via en velkonfigureret moderne
server, men jeg kan ikke se nogen grund til at den skal køre
netop på firewallen.

--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).

---

Jesper Dybdal wrote:

> Jeg indrømmer at jeg ikke er 100% sikker, men jeg er dog næsten
> sikker på at det vil den lokale DNS-server også hvis den er en
> blot nogenlunde ny BIND. Det betyder selvfølgelig at man bør
> lade alle sine DNS-opslag gå via en velkonfigureret moderne
> server, men jeg kan ikke se nogen grund til at den skal køre
> netop på firewallen.


Problemet er blot at du kan fører dit arguement så langt ud at du ingen
firewall behøver!

Jeg kan godt se fordelen i en firewall der sørger for at kommunikationen
igennem sig er RFC komplince, ikke indeholder buffer overflows, etc.

Således vil følgende være ugyldigt og ikke blive tilladt:

DNS:
asdsad-sadsadas-das-das-fs-df-ds-fsd-fsd-f-we-fw-fw--ef-wef-we-f.test-ad.sa.das.d.wefwfwef.w.fsd.fqfq-sdfaw.example.net

HTTP:
GET / HTTP/11.1213

HTTP:
GET
/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

SMTP:
rcpt to: | sed '1,/^$/d' | sh

Og Codered/Nimda slap da heller ikke igennem firewallen. Heldigvis
beyttede både codered og Nimda gamle exploits, men havde det været ikke
kende exploits, ville situationen havde været anderledes.

---

"Christian E. Lysel" <chlyshoswmdatapunktumcom@example.net>
wrote:

>Jesper Dybdal wrote:
>
>> Jeg indrømmer at jeg ikke er 100% sikker, men jeg er dog næsten
>> sikker på at det vil den lokale DNS-server også hvis den er en
>> blot nogenlunde ny BIND. Det betyder selvfølgelig at man bør
>> lade alle sine DNS-opslag gå via en velkonfigureret moderne
>> server, men jeg kan ikke se nogen grund til at den skal køre
>> netop på firewallen.
>
>Problemet er blot at du kan fører dit arguement så langt ud at du ingen
>firewall behøver!

Det særlige ved netop DNS er jo at man alligevel har en lokal
DNS-server som reelt fungerer som en slags proxy - hvad enten den
kører på firewallmaskinen eller ej. Hvis man vælger en tilpas
sikker udgave af den, så har jeg svært ved at se behovet for en
separat proxy til netop DNS.

>Jeg kan godt se fordelen i en firewall der sørger for at kommunikationen
>igennem sig er RFC komplince, ikke indeholder buffer overflows, etc.

Det kan jeg skam også generelt set - det er i høj grad et
spørgsmål om hvor meget man vil ofre af besvær,
konfigurationstid, og køretid på at blive mindre sårbar overfor
visse typer fejl i det programmel man har på indersiden af
firewallen.

--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).

---

Jesper Dybdal wrote:

> Det særlige ved netop DNS er jo at man alligevel har en lokal
> DNS-server som reelt fungerer som en slags proxy - hvad enten den
> kører på firewallmaskinen eller ej. Hvis man vælger en tilpas
> sikker udgave af den, så har jeg svært ved at se behovet for en
> separat proxy til netop DNS.


Nu er windows 2000 klienter jo også født med en proxy DNS server.

>>Jeg kan godt se fordelen i en firewall der sørger for at kommunikationen
>>igennem sig er RFC komplince, ikke indeholder buffer overflows, etc.
> Det kan jeg skam også generelt set - det er i høj grad et
> spørgsmål om hvor meget man vil ofre af besvær,
> konfigurationstid, og køretid på at blive mindre sårbar overfor
> visse typer fejl i det programmel man har på indersiden af
> firewallen.


Her er det at default konfigurationen på en Raptor beskytter imod denne
slags, uden at man skal konfigurere det mindste selv.

---

On Fri, 28 Dec 2001 02:06:04 +0100, "Christian E. Lysel"
<chlyshoswmdatapunktumcom@example.net> wrote:

>> At fx. et operativsystem giver mulighed for at administratoren
>> kan slette alle data, gør det ikke i min begrebsverden til et
>> dårligt operativsystem.

> Men et operativsystem, der selv sletter tilfældige filer pr.
> default er vel dårligt?

Jeg mener, det er en meget dårlig sammenligning.

> Jeg fortrækker stadigvæk at en firewall er sikker pr. default.

Det giver IMO ikke mening at tale om, at en firewall (eller en
VPN-koncentrator som var det vi snakkede om) er "sikker", uden at
man har tage stilling til sikkerhedspolitikken.

> For http og nntp er den god nok, er det muligt at styre URL'er og
> nyhedsgrupper, ellers ikke.
>
> Men jeg vil ikke kalde det content security, da der er meget overfladisk.

Jeg er enig i, at det ikke er særlig avanceret.

Pointen var imidlertid, at der var funktionalitet, der ikke har
noget at gøre med selve VPN- eller firewall-funktionaliteten.

>> Jeg er ikke enig med dig i, at DNS hører hjemme på en firewall,

> Mange installation kan stadigvæk i dag angribes vha. af DNS-spoofing!
> Derfor mener jeg det bør ligge i en firewall.

Ja, så må vi blot konstatere, at vi er uenige.

At mange web-servere kan angribes gør fx. heller ikke, at jeg
synes *den* funktionalitet hører til på en firewall. Det samme
gør sig gældende for DNS-servere.

-A
--
http://www.hojmark.org/

---

Asbjorn Hojmark wrote:

>>>At fx. et operativsystem giver mulighed for at administratoren
>>>kan slette alle data, gør det ikke i min begrebsverden til et
>>>dårligt operativsystem.
>>Men et operativsystem, der selv sletter tilfældige filer pr.
>>default er vel dårligt?
> Jeg mener, det er en meget dårlig sammenligning.


Mere dårlig end din sammenligning?

NT4.0 uden service packs slette da automatisk filer. Det var en fejl der
lå i default installationen.

>>Jeg fortrækker stadigvæk at en firewall er sikker pr. default.
> Det giver IMO ikke mening at tale om, at en firewall (eller en
> VPN-koncentrator som var det vi snakkede om) er "sikker", uden at


(nu har en VPN-koncentrator jo en indbygget firewall)

> man har tage stilling til sikkerhedspolitikken.


Dvs. en firewall der har 100 exploits pr. default, er sikker hvis
sikkerhedpolitikken ikke tage stilling til dette?

Hvor mange sikkerhedspolitikker tager forresten stilling til om en
firewall bør være sikker :)


> At mange web-servere kan angribes gør fx. heller ikke, at jeg
> synes *den* funktionalitet hører til på en firewall. Det samme
> gør sig gældende for DNS-servere.


Det kommer an på hvilket lag man kikke på sikkerheden fra.

En applikationsfirewall, vil kikke på applikationslaget.

---

On Sat, 29 Dec 2001 00:48:24 +0100, "Christian E. Lysel"
<chlyshoswmdatapunktumcom@example.net> wrote:

>>> Men et operativsystem, der selv sletter tilfældige filer pr.
>>> default er vel dårligt?

>> Jeg mener, det er en meget dårlig sammenligning.

> Mere dårlig end din sammenligning?

Ja, jeg mener, der er stor forskel på, hvad et system er konfigu-
reret til out-of-the-box (dvs. et bevidst valg fra producenten)
og hvad der er af fejl i systemet. Det første kan man konfigurere
sig ud af, hvis det ikke lever op til hvad man ønsker. Det andet
er der ikke meget andet at gøre ved end at vente.

>>> Jeg fortrækker stadigvæk at en firewall er sikker pr. default.

>> Det giver IMO ikke mening at tale om, at en firewall (eller en
>> VPN-koncentrator som var det vi snakkede om) er "sikker", uden at

> (nu har en VPN-koncentrator jo en indbygget firewall)

Der er i min begrebsverden ingen sammenhæng mellem de to ting,
men det er da rigtigt, at begge dele kan være bygget ind i samme
produkt.

>> man har tage stilling til sikkerhedspolitikken.

> Dvs. en firewall der har 100 exploits pr. default, er sikker hvis
> sikkerhedpolitikken ikke tage stilling til dette?

Hvis sikkerhedspolitikken siger, at PPTP giver OK sikkerhed i et
givent setup, så er det IMO en helt fin beslutning at understøtte
PPTP. At der er masser af setup, hvor det ikke vil være tilfældet
er en anden sag.

Og det har ikke en tøddel at gøre med exploits.

>> At mange web-servere kan angribes gør fx. heller ikke, at jeg
>> synes *den* funktionalitet hører til på en firewall. Det samme
>> gør sig gældende for DNS-servere.

> Det kommer an på hvilket lag man kikke på sikkerheden fra.

Nej, jeg mener som sagt ikke, at hverken DNS- eller web-servere
hører hjemme i en firewall. Og som sagt kan jeg sagtens leve med,
at vi ikke er enige om det.

-A
--
http://www.hojmark.org/

---

Asbjorn Hojmark wrote:

>>Det kommer an på hvilket lag man kikke på sikkerheden fra.
> Nej, jeg mener som sagt ikke, at hverken DNS- eller web-servere
> hører hjemme i en firewall. Og som sagt kan jeg sagtens leve med,
> at vi ikke er enige om det.


I Axel's tråd er det gået op for mig at jeg kaldt det en DNS-servere.

Jeg mente en DNS-proxy.

Anyway, hvordan beskytter man ellers sin web-server eller DNS-server,
hvis firewallen ikke validere applikationslaget?

Jeg forstår godt din holdning, da en firewall helst skal være minimal,
således at der er mindst mulig kode.

Men på den anden side, yder du ikke beskyttelse imod exploits der ikke
er kendte, og som du ikke kan patche webserveren imod.

Problemet med webserver producenterne er at deres primærer fokus er på
features og ikke sikkerhed.

Dog er det stadigvæk muligt at bygge en sikker løsning. I nogle banker
har man valgt at kombinere de to teknologier, filter regler og
applikations firewalls.

Andre steder flytter man proxy delen oven i en selvstændig server. Jeg
har således set løsninger, hvor man træner proxy serveren i hvad der er
normalt, og den derefter kun vil tillade normalt traffik. (forms,
cookies, headers, ect.)

Ved at bruge en applikationsfirewall kan du flytte beskyttelsen op på
applikationslaget. Jo højere vi bevæger os, jo mere snævert bliver
mulighederne for at exploite webserveren, men jo størrer bliver
muligheden også for at exploite firewallen.


Hvis vi nu kun havde en IP firewall (og dette var dagens teknologi), der
filtere på IP adresser, vil du jo argumentere for at vi skal et lag
højere op, nemlig op i TCP/UDP/ICMP lagene.

Jeg kunne nu argmentere imod, ved at sige at firewallen bliver mere
kompleks, og derfor mere sårbar. Men sjovt nok er der ingen der
argumentere for dette!

---

"Christian E. Lysel" wrote:
>
> Problemet med webserver producenterne er at deres primærer fokus er på
> features og ikke sikkerhed.

Har du nogen dokumentation for, at det gælder alle
webserver producenter?

>
> Andre steder flytter man proxy delen oven i en selvstændig server.

Hvilket også må forventes at være den sikreste
løsning.

>
> Hvis vi nu kun havde en IP firewall (og dette var dagens teknologi), der
> filtere på IP adresser, vil du jo argumentere for at vi skal et lag
> højere op, nemlig op i TCP/UDP/ICMP lagene.

Du kan have en række filtre/firewalls/proxies
eller hvad du nu foretrækker at kalde dem. De
forskellige bokse skal så sorteres efter hvilket
protokol lag de arbejder på. Den foreste skal
således filtrerer på det laveste niveau, og den
bageste skal filtrere på det højeste niveau.

Det forreste skulle så være filtrering på IP
addresser. Til det formål kan du passende
anvende en ganske almindlig router.

Den næste kunne så være en firewall der håndterer
ICPM, UDP og TCP.

Den bageste kunne så være en (eller flere) proxy,
der håndterer specifike protokoler bygget ovenpå
TCP eller UDP.

>
> Jeg kunne nu argmentere imod, ved at sige at firewallen bliver mere
> kompleks, og derfor mere sårbar. Men sjovt nok er der ingen der
> argumentere for dette!

Det er hermed gjort. Firewallen skal side bagved
en router der filtrerer på IP addresser. Du vil
nok hurtigt opdage, at filtrering på IP niveauet
ikke kan gøre ret meget andet end at frasortere
de mest oplagte tilfælde af IP spoofing, men det
er bestemt også en god begyndelse.

--
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.

---

CLAUS HANSEN wrote:

> Jeg er ikke så glad for at køre VPN på vores Raptor Firewall, da vi jo af og


Pather i Jeres Raptor firewall med de nyeste microsoft pathces??

Hvis det er tilfældet er der noget du har misforstået. Du må kun kører
med de patche der er godkendt af Symantec.


Endvidere hvor mange fejl har der været i firewallen?

Der har været 2-3 DoS angreb, og et angreb jeg og en kollega har fundet:

http://www.securityfocus.com/archive/1/171335


Men på den anden side, en firewall bør jo kører så lidt som muligt.

Derfor kan du evt. smide VPN over på en anden Raptor firewall. Raptor
firewallen har jo den fordel at kunne styrer VPN trafikken på
applikationslaget.

> til patcher vores NT med nye sikkerhedspatches fra Microsoft... men det er
> jo ikke sikkert det betyder noget? Måske har jeg bare paranoia eller hva'
> ???
>
>
> Med venlig hilsen
>
> CLAUS HANSEN