---

Hej Alle,

Jeg synes at have læst et eller andet sted, at man kan forøge sikkerheden
ved at have
en ekstra pc imellem den alm. daglige Pc og ADSL nettet. Hvis dette er
rigtigt, skal den
så køre noget firewall software eller skal den være en proxy server?

Jeg er ikke helt med på denne tankegang, så yderligere info er meget
velkommen (hvorfor er dette
bedre end bare en firewall software på drift Pc'en?)

/Michael

---

Den Sat, 28 Apr 2001 17:14:15 +0200 skrev Miks:
>Hej Alle,
>
>Jeg synes at have læst et eller andet sted, at man kan forøge sikkerheden
>ved at have
>en ekstra pc imellem den alm. daglige Pc og ADSL nettet. Hvis dette er
>rigtigt, skal den
>så køre noget firewall software eller skal den være en proxy server?

Der er flere muligheder:

- Hvis du har en Cisco 677 model, så kan den lave firewall'ing.
- En linux (eller *BSD) maskine med ipchains/iptables/ipfilter.
- Eller den nemme løsning: luk for serverfunktionen i din PC
(unix: kvæl inetd og nfsd. Windows: fjern bindingen mellem
fildeling og TCP/IP).

Glem alt om "personal firewalls", og hold dig langt fra proxy-server
(oftest et Microsoft produkt, der gør internetadgang meget mere
besværligt, og sikkeheden meget lav, men kan også være en alm.
caching web-proxy (fx. Squid), som hvis den er konfigureret korrekt
ikke burde have indflydelse på sikkerheden (hverken bedre eller
værre).

Mvh
Kent
--
http://www.celebrityshine.com/~kfr/ - sidste billede: garden.png

---

On Sat, 28 Apr 2001 15:39:03 +0000 (UTC), leeloo@mailandnews.com
(Kent Friis) wrote:

> - Hvis du har en Cisco 677 model, så kan den lave firewall'ing.

Nej.

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

---

Den Sat, 28 Apr 2001 18:58:08 +0200 skrev Asbjorn Hojmark:
>On Sat, 28 Apr 2001 15:39:03 +0000 (UTC), leeloo@mailandnews.com
>(Kent Friis) wrote:
>
>> - Hvis du har en Cisco 677 model, så kan den lave firewall'ing.
>
>Nej.

Det var ellers mit indtryk.

Men normalt kører ADSL-linier med et ip-nummer, og DNAT til den
relle PC, så man må kunne nøjes med at DNAT'e de services man
skal bruge (eller slå det helt fra, og kun køre SNAT).

Mvh
Kent
--
http://www.celebrityshine.com/~kfr/ - sidste billede: garden.png

---

On Sat, 28 Apr 2001 17:19:13 +0000 (UTC), leeloo@mailandnews.com
(Kent Friis) wrote:

>>> - Hvis du har en Cisco 677 model, så kan den lave firewall'ing.

>> Nej.

> Det var ellers mit indtryk.

En 677'er har ingen firewall-funktionalitet. Hvis man ønsker det,
kan man se på fx. 827'er.

> Men normalt kører ADSL-linier med et ip-nummer, og DNAT til den
> relle PC, så man må kunne nøjes med at DNAT'e de services man
> skal bruge (eller slå det helt fra, og kun køre SNAT).

Ja.

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

---

"Asbjorn Hojmark" <Asbjorn@Hojmark.ORG> wrote
> >>> - Hvis du har en Cisco 677 model, så kan den lave firewall'ing.
>
> >> Nej.
>
> > Det var ellers mit indtryk.
>
> En 677'er har ingen firewall-funktionalitet. Hvis man ønsker det,
> kan man se på fx. 827'er.
>

Det var ellers noget af en udtalelse. Der er mulighed for at sætte filter
regler op i en cisco 677. Er det ikke noget af det der kendetegner en
firewall? ok, den kører ikke IDS, men det er der jo osse andre ting der ikke
gør.

---

Bent skohorn <a@b.c> wrote:
>Det var ellers noget af en udtalelse. Der er mulighed for at sætte filter
>regler op i en cisco 677. Er det ikke noget af det der kendetegner en
>firewall? ok, den kører ikke IDS, men det er der jo osse andre ting der ikke

Et IDS har intet med en firewall at goere.

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

---

>> > Det var ellers mit indtryk.
>>
>> En 677'er har ingen firewall-funktionalitet. Hvis man ønsker det,
>> kan man se på fx. 827'er.
>>
>
>Det var ellers noget af en udtalelse. Der er mulighed for at sætte filter
>regler op i en cisco 677. Er det ikke noget af det der kendetegner en
>firewall? ok, den kører ikke IDS, men det er der jo osse andre ting der ikke
>gør.
>

At man kan filtrere ved hjælp af access-lister og lign. er ikke ensbetydende
med at man har en firewall. Når du indbygger intelligens med f.eks.
[1] Stateful Inspection så kan du kalde det for en firewall, men ordet
firewall er ofte misbrugt, og ligeså er defineringen.


[1] http://www.checkpoint.com/products/technology/stateful1.html

--
Gorm Jorgensen - UB++++
http://www.area51.dk/

---

Den Sun, 29 Apr 2001 19:18:52 +0200 skrev Gorm Jorgensen:
>>> > Det var ellers mit indtryk.
>>>
>>> En 677'er har ingen firewall-funktionalitet. Hvis man ønsker det,
>>> kan man se på fx. 827'er.
>>>
>>
>>Det var ellers noget af en udtalelse. Der er mulighed for at sætte filter
>>regler op i en cisco 677. Er det ikke noget af det der kendetegner en
>>firewall? ok, den kører ikke IDS, men det er der jo osse andre ting der ikke
>>gør.
>>
>
>At man kan filtrere ved hjælp af access-lister og lign. er ikke ensbetydende
>med at man har en firewall. Når du indbygger intelligens med f.eks.
>[1] Stateful Inspection så kan du kalde det for en firewall, men ordet
>firewall er ofte misbrugt, og ligeså er defineringen.
>
>[1] http://www.checkpoint.com/products/technology/stateful1.html

Vil du dermed påstå at et produkt skal have stateful inspection, for at
være en almindelig stateless firewall?

Mvh
Kent
--
Nu med en e-mail adresse der virker...

---

>>At man kan filtrere ved hjælp af access-lister og lign. er ikke ensbetydende
>>med at man har en firewall. Når du indbygger intelligens med f.eks.
>>[1] Stateful Inspection så kan du kalde det for en firewall, men ordet
>>firewall er ofte misbrugt, og ligeså er defineringen.
>>
>>[1] http://www.checkpoint.com/products/technology/stateful1.html
>
>Vil du dermed påstå at et produkt skal have stateful inspection, for at
>være en almindelig stateless firewall?
>
Hvis en firewall er stateless så er det ikke en firewall men et filter !

--
Gorm Jorgensen - UB++++
http://www.area51.dk/

---

On Sun, 29 Apr 2001 14:25:31 +0200, "Bent skohorn" <a@b.c> wrote:

>> En 677'er har ingen firewall-funktionalitet. Hvis man ønsker det,
>> kan man se på fx. 827'er.

> Det var ellers noget af en udtalelse. Der er mulighed for at sætte filter
> regler op i en cisco 677. Er det ikke noget af det der kendetegner en
> firewall? ok, den kører ikke IDS, men det er der jo osse andre ting der ikke
> gør.

I min begrebsverden gør filtrering og / eller NAT alene ingen
firewall. For at gøre sig fortjent til den betegnelse må boxen
være i besiddelse af egentlig protokol-intelligens.

En 677'er kan køre NAT/PAT og kan lave simpel filtrering. Det gør
den ikke til en firewall.

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

---

Den Sun, 29 Apr 2001 22:55:33 +0200 skrev Asbjorn Hojmark:
>On Sun, 29 Apr 2001 14:25:31 +0200, "Bent skohorn" <a@b.c> wrote:
>
>>> En 677'er har ingen firewall-funktionalitet. Hvis man ønsker det,
>>> kan man se på fx. 827'er.
>
>> Det var ellers noget af en udtalelse. Der er mulighed for at sætte filter
>> regler op i en cisco 677. Er det ikke noget af det der kendetegner en
>> firewall? ok, den kører ikke IDS, men det er der jo osse andre ting der ikke
>> gør.
>
>I min begrebsverden gør filtrering og / eller NAT alene ingen
>firewall. For at gøre sig fortjent til den betegnelse må boxen
>være i besiddelse af egentlig protokol-intelligens.

Hvilket protokol-niveau snaker vi om her? IP-protokollen (stateless),
TCP-protokollen (statefull) eller ICQ-protokollen (application)?

>En 677'er kan køre NAT/PAT og kan lave simpel filtrering. Det gør
>den ikke til en firewall.

Selv en linux-maskine med ipchains er stateless. Men jeg ville til hver
en tid foretrække ipchains frem for fx. en Cisco PIX. (Men iptables
virker umiddelbart endnu bedre, så det er ikke bare et spørgsmål om
den er statefull).

Det eneste man så vidt jeg kan se ikke kan lukke for i en stateless
firewall er ikke-SYN pakker, som ikke hører til nogen forbindelse.
Det er meget begrænset hvad man kan lave af ulykker med den slags
pakker (winnukes er måske en mulighed, men så skrot windows en gang
for alle). Fordelen ved en statefull firewall er at man kan åbne
noget mere, uden at lukke helt op (gælder især UDP, men også fx. FTP-
protokollen, hvis ellers firewall'en kender den).

Jeg vil ikke påstå at det ene er mere sikkert end det andet. En
stateless firewall er simpel kode, men kompleks at administrere. Men
hvis ellers man har styr på TCP/IP bør man kunne sætte den op så den
er (næsten) lige så sikker som en statefull er i teorien.

En statefull firewall er meget nemmere at konfigurere, men bygger på
meget mere kompleks kode, med tilsvarende større risiko for bugs -
bugs der kan betyde store sikkerhedshuller, og kræver en opgradering
fra leverandøren. Et hul i opsætningen af en stateless firewall kræver
derimod blot at man ændrer opsætningen.

Derfor vil jeg mene at en statefull firewall kræver større tillid til
leverandøren.

Mvh
Kent
--
Nu med en e-mail adresse der virker...

---

Kent Friis <kfr@fleggaard.dk> wrote:
>Hvilket protokol-niveau snaker vi om her? IP-protokollen (stateless),
>TCP-protokollen (statefull) eller ICQ-protokollen (application)?

TCP, naturligvis.

>Selv en linux-maskine med ipchains er stateless. Men jeg ville til hver
>en tid foretrække ipchains frem for fx. en Cisco PIX.

Sikke en bemaerkning. Jeg ville ofte vaelge en PIX, ikke fordi der staar
Cisco paa den, men fordi det er langt svaerere at komme forbi stateful
filters, end det er at komme forbi stateless ditto.

>Derfor vil jeg mene at en statefull firewall kræver større tillid til
>leverandøren.

Nu stoler jeg aldrig mere paa en firewall af nogen art, end jeg kan sige, at
mine systemer er sikret saa godt, at hvis den skulle fejle er det ikke en
katastrofe.

Ofte bruges firewalls som sidste/eneste forsvar, hvor det i mange tilfaelde
vil give langt mere mening at binde en service til et andet interface, bruge
staerkere authentication, etc.

Mange mennesker er fjolser, og bruger teknologi forkert.

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

---

On Sun, 29 Apr 2001 23:37:09 +0000 (UTC), kfr@fleggaard.dk (Kent
Friis) wrote:

>> I min begrebsverden gør filtrering og / eller NAT alene ingen
>> firewall. For at gøre sig fortjent til den betegnelse må boxen
>> være i besiddelse af egentlig protokol-intelligens.

> Hvilket protokol-niveau snaker vi om her? IP-protokollen (stateless),
> TCP-protokollen (statefull) eller ICQ-protokollen (application)?

Jeg mener 'hele vejen op'.

> Selv en linux-maskine med ipchains er stateless. Men jeg ville til
> hver en tid foretrække ipchains frem for fx. en Cisco PIX.

Hvorfor?

> Det eneste man så vidt jeg kan se ikke kan lukke for i en stateless
> firewall er ikke-SYN pakker, som ikke hører til nogen forbindelse.

Hvis en firewall ikke har applikation-level intelligens, kan man
ikke med nogen ordentlig sikkerhed lukke op for de protokoller,
hvor der sendes pakker udefra, der ikke er en del af en TCP-
forbindelse (som fx. FTP, H.323, PPTP, traceroute og tonsvis af
andre).

Problemet bliver kun værre, hvis man også kører NAT, hvor der
igen er tonsvis af ting, der ikke fungerer, hvis ikke NAT-
funktionen forstår protokollen, og kan se, hvilke af disse ind-
kommende pakker, der er (del af) et svar på hvilke udgående.

> Jeg vil ikke påstå at det ene er mere sikkert end det andet. En
> stateless firewall er simpel kode, men kompleks at administrere. Men
> hvis ellers man har styr på TCP/IP bør man kunne sætte den op så den
> er (næsten) lige så sikker som en statefull er i teorien.

Hvis alt, hvad firewall'en har er L3/L4-intelligens, vil man fx.
med FTP være nødt til at åbne for et kæmpe range af porte, og det
samme gør sig gældende for en række andre protokoller.

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

---

Den Mon, 30 Apr 2001 07:24:43 +0200 skrev Asbjorn Hojmark:
>On Sun, 29 Apr 2001 23:37:09 +0000 (UTC), kfr@fleggaard.dk (Kent
>Friis) wrote:
>
>>> I min begrebsverden gør filtrering og / eller NAT alene ingen
>>> firewall. For at gøre sig fortjent til den betegnelse må boxen
>>> være i besiddelse af egentlig protokol-intelligens.
>
>> Hvilket protokol-niveau snaker vi om her? IP-protokollen (stateless),
>> TCP-protokollen (statefull) eller ICQ-protokollen (application)?
>
>Jeg mener 'hele vejen op'.
>
>> Selv en linux-maskine med ipchains er stateless. Men jeg ville til
>> hver en tid foretrække ipchains frem for fx. en Cisco PIX.
>
>Hvorfor?

Generel dårlig erfaring med Cisco, tror jeg nok.

>> Det eneste man så vidt jeg kan se ikke kan lukke for i en stateless
>> firewall er ikke-SYN pakker, som ikke hører til nogen forbindelse.
>
>Hvis en firewall ikke har applikation-level intelligens, kan man
>ikke med nogen ordentlig sikkerhed lukke op for de protokoller,
>hvor der sendes pakker udefra, der ikke er en del af en TCP-
>forbindelse (som fx. FTP, H.323, PPTP, traceroute og tonsvis af
>andre).
>
>Problemet bliver kun værre, hvis man også kører NAT, hvor der
>igen er tonsvis af ting, der ikke fungerer, hvis ikke NAT-
>funktionen forstår protokollen, og kan se, hvilke af disse ind-
>kommende pakker, der er (del af) et svar på hvilke udgående.

Der er vi så ovre i "man kan åbne noget mere, uden at ødelægge
sikkerheden fuldstændigt".

>> Jeg vil ikke påstå at det ene er mere sikkert end det andet. En
>> stateless firewall er simpel kode, men kompleks at administrere. Men
>> hvis ellers man har styr på TCP/IP bør man kunne sætte den op så den
>> er (næsten) lige så sikker som en statefull er i teorien.
>
>Hvis alt, hvad firewall'en har er L3/L4-intelligens, vil man fx.
>med FTP være nødt til at åbne for et kæmpe range af porte, og det
>samme gør sig gældende for en række andre protokoller.

Der vil jeg så nok foretrække at bruge en protokol er fungerer (http,
ssh/scp,...) - FTP bør efter min overbevisning kun bruges til
anonym FTP, og der kan passive kommandoen klare problemerne (udgående).
Jeg har selv slået ip_conntrack_ftp fra på min iptables, fordi den
ikke er nødvendig.

Dertil kommer så problemet med hvilke protokoller den skal kunne klare
- som bruger er det nemt nok, for den skal kunne dem man har brug for,
men for leverandøren - kan man nøjes med FTP og et par andre, eller
skal vi ud i ICQ og det der er værre?

Mvh
Kent
--
Nu med en e-mail adresse der virker...

---

On Mon, 30 Apr 2001 09:53:39 +0000 (UTC), kfr@fleggaard.dk (Kent
Friis) wrote:

>> Hvis en firewall ikke har applikation-level intelligens, kan man
>> ikke med nogen ordentlig sikkerhed lukke op for de protokoller,
>> hvor der sendes pakker udefra, der ikke er en del af en TCP-
>> forbindelse (som fx. FTP, H.323, PPTP, traceroute og tonsvis af
>> andre).

> Der er vi så ovre i "man kan åbne noget mere, uden at ødelægge
> sikkerheden fuldstændigt".

Ja. Og for mange organisationer er virkeligheden nu engang, at de
ikke kan nøjes med at køre noget, der kan baseres på, at det kun
må være en TCP-session initieret indefra.

Så kan man (som du åbenbart) vælge at undlade at køre disse andre
protokoller, eller man kan vælge at bruge en firewall, der kan
håndtere dem sikkert.

> Der vil jeg så nok foretrække at bruge en protokol er fungerer (http,
> ssh/scp,...) - FTP bør efter min overbevisning kun bruges til
> anonym FTP, og der kan passive kommandoen klare problemerne (udgående).

Hvis du udelukkende baserer dig på filtre, kan du ikke engang
håndtere en TCP-session sikkert. Hvordan vil du i et filter
definere, at en TCP-pakke der ankommer til det eksterne inter-
face godt må lukkes ind?

Hvis ikke boxen holder styr på, at en maskine på indersiden først
har initieret forbindelsen, så kan du ikke vide, om den ankommen-
de pakke er God eller Ond.

Ja, man har tidligere brugt at checke på, om TCP SYN er sat, men
det kan ikke på nogen rimelig måde påstås at være sikkert.

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

---

Den Tue, 01 May 2001 01:03:01 +0200 skrev Asbjorn Hojmark:
>On Mon, 30 Apr 2001 09:53:39 +0000 (UTC), kfr@fleggaard.dk (Kent
>Friis) wrote:
>
>>> Hvis en firewall ikke har applikation-level intelligens, kan man
>>> ikke med nogen ordentlig sikkerhed lukke op for de protokoller,
>>> hvor der sendes pakker udefra, der ikke er en del af en TCP-
>>> forbindelse (som fx. FTP, H.323, PPTP, traceroute og tonsvis af
>>> andre).
>
>> Der er vi så ovre i "man kan åbne noget mere, uden at ødelægge
>> sikkerheden fuldstændigt".
>
>Ja. Og for mange organisationer er virkeligheden nu engang, at de
>ikke kan nøjes med at køre noget, der kan baseres på, at det kun
>må være en TCP-session initieret indefra.

Langt det meste bliver (mange steder) brugt på at surfe i arbejdstiden.

>Så kan man (som du åbenbart) vælge at undlade at køre disse andre
>protokoller, eller man kan vælge at bruge en firewall, der kan
>håndtere dem sikkert.
>
>> Der vil jeg så nok foretrække at bruge en protokol er fungerer (http,
>> ssh/scp,...) - FTP bør efter min overbevisning kun bruges til
>> anonym FTP, og der kan passive kommandoen klare problemerne (udgående).
>
>Hvis du udelukkende baserer dig på filtre, kan du ikke engang
>håndtere en TCP-session sikkert. Hvordan vil du i et filter
>definere, at en TCP-pakke der ankommer til det eksterne inter-
>face godt må lukkes ind?
>
>Hvis ikke boxen holder styr på, at en maskine på indersiden først
>har initieret forbindelsen, så kan du ikke vide, om den ankommen-
>de pakke er God eller Ond.
>
>Ja, man har tidligere brugt at checke på, om TCP SYN er sat, men
>det kan ikke på nogen rimelig måde påstås at være sikkert.

Medmindre man har noget skrammel stående bag ved, som kan lokkes til at
bluescreene, så er en TCP-pakke uden SYN ret uanvendelig. (Hmm, måske
noget connection-hijacking eller spoofing...)

Mvh
Kent
--
Nu med en e-mail adresse der virker...

---

>>Ja. Og for mange organisationer er virkeligheden nu engang, at de
>>ikke kan nøjes med at køre noget, der kan baseres på, at det kun
>>må være en TCP-session initieret indefra.
>
>Langt det meste bliver (mange steder) brugt på at surfe i arbejdstiden.
>
Ja http er tcp baseret, med hvad med dns som er udp hvordan vil du håndtere
det korrekt uden at kende state på forespørgsler ?

>>Ja, man har tidligere brugt at checke på, om TCP SYN er sat, men
>>det kan ikke på nogen rimelig måde påstås at være sikkert.
>
>Medmindre man har noget skrammel stående bag ved, som kan lokkes til at
>bluescreene, så er en TCP-pakke uden SYN ret uanvendelig. (Hmm, måske
>noget connection-hijacking eller spoofing...)
>
Derfor skal den selvfølgelig også smides væk.. En anden ting er dog at folk
tror en firewall beskytter selv en dårlig konfigureret web-server, og det er
jo lang fra korrekt, så dit eksempel med en bluescreen kan være temmelig
aktuelt.

--
Gorm Jorgensen - UB++++
http://www.area51.dk/

---

Den Tue, 1 May 2001 19:39:33 +0200 skrev Gorm Jorgensen:
>>>Ja. Og for mange organisationer er virkeligheden nu engang, at de
>>>ikke kan nøjes med at køre noget, der kan baseres på, at det kun
>>>må være en TCP-session initieret indefra.
>>
>>Langt det meste bliver (mange steder) brugt på at surfe i arbejdstiden.
>>
>Ja http er tcp baseret, med hvad med dns som er udp hvordan vil du håndtere
>det korrekt uden at kende state på forespørgsler ?

Hvis man bruger ekstern DNS-server: Ved at tillade indgående UDP fra
port 53 på lige præcis den ene maskine.

Hvis man bruger intern DNS-server: Ved at tillade UDP trafik fra
port 53 til port 53 (og/eller highports) på denne maskine.

Både/og (split horizon): ved at tillade UDP trafik fra port 53 på
den eksterne til port 53 (og/eller highports) på den interne, samt
at bruge "forward-only" på den interne.

>>>Ja, man har tidligere brugt at checke på, om TCP SYN er sat, men
>>>det kan ikke på nogen rimelig måde påstås at være sikkert.
>>
>>Medmindre man har noget skrammel stående bag ved, som kan lokkes til at
>>bluescreene, så er en TCP-pakke uden SYN ret uanvendelig. (Hmm, måske
>>noget connection-hijacking eller spoofing...)
>>
>Derfor skal den selvfølgelig også smides væk..

Pga. bluescreens? Der ville jeg hellere smide føromtalte skrammel i
Flensborg fjord.

Eller pga. connection-hijacking og spoofing - der bevæger vi os desværre
uden for min viden Det forekommer mig dog at det skulle være
håbløst mod fx. Linux-maskiner pga. "random" ISN's.

>En anden ting er dog at folk
>tror en firewall beskytter selv en dårlig konfigureret web-server, og det er
>jo lang fra korrekt, så dit eksempel med en bluescreen kan være temmelig
>aktuelt.

Sikkerhedsmæssigt løser DMZ rimeligt dette problem, ved at forhindre at
resten af netværket bliver berørt, og hvad angår selve webserveren med
bluescreen, så er føromtalte fjord stadig min foretrukne løsning.

Mvh
Kent

Ps: Hvis der skulle være nogen greenpeace-aktivister der læser med her,
så skal det altså ikke tages alt for bogstaveligt.
--
Nu med en e-mail adresse der virker...

---

>Hvis man bruger ekstern DNS-server: Ved at tillade indgående UDP fra
>port 53 på lige præcis den ene maskine.
>
>Hvis man bruger intern DNS-server: Ved at tillade UDP trafik fra
>port 53 til port 53 (og/eller highports) på denne maskine.
>
>Både/og (split horizon): ved at tillade UDP trafik fra port 53 på
>den eksterne til port 53 (og/eller highports) på den interne, samt
>at bruge "forward-only" på den interne.
>
Jeps, men du har porte åbne hele tiden hvis nu du skulle modtaget et
formodet reply, dermed kan dette bruges til at connecte baglens...


>>Derfor skal den selvfølgelig også smides væk..
>
>Pga. bluescreens? Der ville jeg hellere smide føromtalte skrammel i
>Flensborg fjord.
>
Nej da, alt som ikke har en SYN sat skal checkes mod state tabellen, og hvis
det ikke er en kendt session skal de droppes. Men i mit daglige arbejde mes
sikkerhed ser jeg desværee mange miskonfigurerede systemer som sagtens kan
nedlægges af et SYN attack.


>Eller pga. connection-hijacking og spoofing - der bevæger vi os desværre
>uden for min viden Det forekommer mig dog at det skulle være
>håbløst mod fx. Linux-maskiner pga. "random" ISN's.
>
spoofing af interne adresser fanges i firewallen, og hijacking afhænger som
du siger af OS'et, men _langt_ fra alle bruger linux ell. bsd, de har f.eks.
en NT4.0 ell. win2k.


>>En anden ting er dog at folk
>>tror en firewall beskytter selv en dårlig konfigureret web-server, og det er
>>jo lang fra korrekt, så dit eksempel med en bluescreen kan være temmelig
>>aktuelt.
>
>Sikkerhedsmæssigt løser DMZ rimeligt dette problem, ved at forhindre at
>resten af netværket bliver berørt, og hvad angår selve webserveren med
>bluescreen, så er føromtalte fjord stadig min foretrukne løsning.
>
Jow jow, men hjælper ikke på den dårlige konfigurering på web-serveren,
mange gange bruges der også en sql til lagring af data, nogle gange
fortrolige data, og det er jo kedeligt at få dem publiceret.


>Ps: Hvis der skulle være nogen greenpeace-aktivister der læser med her,
>så skal det altså ikke tages alt for bogstaveligt.
>
Hehe

--
Gorm Jorgensen - UB++++
http://www.area51.dk/

---

Den Tue, 1 May 2001 20:55:53 +0200 skrev Gorm Jorgensen:
>>Hvis man bruger ekstern DNS-server: Ved at tillade indgående UDP fra
>>port 53 på lige præcis den ene maskine.
>>
>>Hvis man bruger intern DNS-server: Ved at tillade UDP trafik fra
>>port 53 til port 53 (og/eller highports) på denne maskine.
>>
>>Både/og (split horizon): ved at tillade UDP trafik fra port 53 på
>>den eksterne til port 53 (og/eller highports) på den interne, samt
>>at bruge "forward-only" på den interne.
>>
>Jeps, men du har porte åbne hele tiden hvis nu du skulle modtaget et
>formodet reply, dermed kan dette bruges til at connecte baglens...

Det kræver at man først knækker den maskine som pakkerne skal komme
fra, eller at man spoofer pakkerne, hvilket forhindres ved at
putte den eksterne DNS-server på DMZ, og lukke for pakker der ikke
kommer fra det korrekte interface.

>>>Derfor skal den selvfølgelig også smides væk..
>>
>>Pga. bluescreens? Der ville jeg hellere smide føromtalte skrammel i
>>Flensborg fjord.
>>
>Nej da, alt som ikke har en SYN sat skal checkes mod state tabellen, og hvis
>det ikke er en kendt session skal de droppes. Men i mit daglige arbejde mes
>sikkerhed ser jeg desværee mange miskonfigurerede systemer som sagtens kan
>nedlægges af et SYN attack.
>
>>Eller pga. connection-hijacking og spoofing - der bevæger vi os desværre
>>uden for min viden Det forekommer mig dog at det skulle være
>>håbløst mod fx. Linux-maskiner pga. "random" ISN's.
>>
>spoofing af interne adresser fanges i firewallen, og hijacking afhænger som
>du siger af OS'et, men _langt_ fra alle bruger linux ell. bsd, de har f.eks.
>en NT4.0 ell. win2k.

Har du en nuke der virker mod w2k? Jeg kunne godt bruge en til samlingen


>>>En anden ting er dog at folk
>>>tror en firewall beskytter selv en dårlig konfigureret web-server, og det er
>>>jo lang fra korrekt, så dit eksempel med en bluescreen kan være temmelig
>>>aktuelt.
>>
>>Sikkerhedsmæssigt løser DMZ rimeligt dette problem, ved at forhindre at
>>resten af netværket bliver berørt, og hvad angår selve webserveren med
>>bluescreen, så er føromtalte fjord stadig min foretrukne løsning.
>>
>Jow jow, men hjælper ikke på den dårlige konfigurering på web-serveren,
>mange gange bruges der også en sql til lagring af data, nogle gange
>fortrolige data, og det er jo kedeligt at få dem publiceret.

fortrolige data har intet at gøre på en webserver eller en SQL der
er connectet til en webserver - så er det selvforskyldt.

Og hvis web-serveren har en bug, eller ikke er konfigureret korrekt,
så hjælper selv den bedste firewall ikke.

Mvh
Kent
--
Nu med en e-mail adresse der virker...

---

>Det kræver at man først knækker den maskine som pakkerne skal komme
>fra, eller at man spoofer pakkerne, hvilket forhindres ved at
>putte den eksterne DNS-server på DMZ, og lukke for pakker der ikke
>kommer fra det korrekte interface.
>
selvfølgelig.

>>spoofing af interne adresser fanges i firewallen, og hijacking afhænger som
>>du siger af OS'et, men _langt_ fra alle bruger linux ell. bsd, de har f.eks.
>>en NT4.0 ell. win2k.
>
>Har du en nuke der virker mod w2k? Jeg kunne godt bruge en til samlingen
>
>
Hmm, har ikke lige en liggende. Men mon ikke http://www.securityfocus.com/
har en liggende ?

>fortrolige data har intet at gøre på en webserver eller en SQL der
>er connectet til en webserver - så er det selvforskyldt.
>
Fundstændig mine ord, men sådan ser set langtfra ud :(

--
Gorm Jorgensen - UB++++
http://www.area51.dk/

---

Den Wed, 2 May 2001 10:41:02 +0200 skrev Gorm Jorgensen:
>>Det kræver at man først knækker den maskine som pakkerne skal komme
>>fra, eller at man spoofer pakkerne, hvilket forhindres ved at
>>putte den eksterne DNS-server på DMZ, og lukke for pakker der ikke
>>kommer fra det korrekte interface.
>>
>selvfølgelig.
>
>>>spoofing af interne adresser fanges i firewallen, og hijacking afhænger som
>>>du siger af OS'et, men _langt_ fra alle bruger linux ell. bsd, de har f.eks.
>>>en NT4.0 ell. win2k.
>>
>>Har du en nuke der virker mod w2k? Jeg kunne godt bruge en til samlingen
>>
>>
>Hmm, har ikke lige en liggende. Men mon ikke http://www.securityfocus.com/
>har en liggende ?

Jeg har kigget mange steder, uden at finde nogen.

>>fortrolige data har intet at gøre på en webserver eller en SQL der
>>er connectet til en webserver - så er det selvforskyldt.
>>
>Fundstændig mine ord, men sådan ser set langtfra ud :(

At lukke en skizofren[1] inde i en betonbuker forhindrer ikke at han
kommer til skade. Ligeledes hjælper det ikke at sætte en skizofren
webserver ind bag en firewall... Det farlige punkt er selve webserveren.

Mvh
Kent

[1] Eller hvad den korrekte betegnelse nu er for folk der er til fare
for sig selv.
--
Nu med en e-mail adresse der virker...

---

Asbjorn Hojmark <Asbjorn@Hojmark.ORG> wrote:

>Hvis en firewall ikke har applikation-level intelligens, kan man
>ikke med nogen ordentlig sikkerhed lukke op for de protokoller,
>hvor der sendes pakker udefra, der ikke er en del af en TCP-
>forbindelse (som fx. FTP, H.323, PPTP, traceroute og tonsvis af
>andre).
>
>Problemet bliver kun værre, hvis man også kører NAT, hvor der
>igen er tonsvis af ting, der ikke fungerer, hvis ikke NAT-
>funktionen forstår protokollen, og kan se, hvilke af disse ind-
>kommende pakker, der er (del af) et svar på hvilke udgående.

Nu ligger der jo en del logik, herunder protokoltilstandsanalyse,
i enhver implementation af NAT/PAT.

Jeg synes det er bagvendt at sige at "Problemet bliver kun værre,
hvis man også kører NAT". Hvis man også kører NAT, så har man jo
i sagens natur netop den fornødne tilstandsstyrede logik til at
håndtere de protokoller ens NAT-implementation understøtter.
Derfor mener jeg at sikkerheden generelt bliver meget bedre hvis
man også kører NAT, selvom funktionaliteten måske bliver mindre.

De fleste billige rutere har fx en svjv typisk udmærket
implementation af FTP med NAT. Den åbner de porte der er
nødvendige, og ikke andre.

Naturligvis er der "tonsvis af ting, der ikke fungerer, hvis ikke
NAT-funktionen forstår protokollen" - men hvis ikke
NAT-funktionen forstår protokollen så er det jo fordi man prøver
at bruge ruteren/firewallen til noget det ikke er beregnet til.
Så skal det ikke fungere. Præcis det samme gælder jo for
NAT-funktionen i den dyreste firewall man kan købe: den
understøtter visse protokoller, og ikke andre.

Hvis jeg bruger en ruter der kører NAT/PAT og ikke lukker nogen
forbindelser ind på initiativ udefra overhovedet, så mener jeg
ikke jeg har et sikkerhedsproblem i forhold til angreb udefra som
en mere avanceret firewall kunne gøre noget fornuftigt ved
(medmindre ruteren selv er sårbar, men det er en anden sag).

Min personlige brug af ordet "firewall" omfatter alt hvad der
yder den fornødne beskyttelse til at man ikke behøver bekymre sig
om indbrud i det interne net, og samtidig tillader den fornødne
trafik. Således i mange tilfælde - ikke mindst for privatbrugere
- også enkle pakkefiltre kombineret med NAT/PAT.

Det betyder ikke at jeg mener at man med rimelighed kan sælge et
pakkefilter som en generelt anvendelig firewall. Et generelt
anvendeligt firewallprodukt som på sikker vis skal kunne
understøtte at der står servere på indersiden bør levere
applikationsniveauproxyer til de almindeligt anvendte
protokoller. Så måske er vi ikke særlig uenige, udover at jeg
gerne bruger ordet "firewall" om et apparat der i den konkrete
situation dækker behovet, selvom det ikke er _generelt_
anvendeligt.

På min arbejdsplads bruger vi fx en firewall jeg har flikket
sammen af et Linuxsystem der kører ipchains med NAT, en
SMTP-forwarder, BIND, og 4 netkort (ekstern, DMZ, to adskilte
interne net). Bortset fra SMTP og DNS, som altså proxyes på
applikationsniveau, så er det ren NAT og pakkefiltrering, inkl.
til DMZ. Der er ikke åbent for nogen som helst forbindelse ind
på det indre net på initiativ udefra eller fra DMZ'en. Sådan en
enkel løsning er efter min mening fin i sammenhænge hvor man
overhovedet ikke ønsker at begrænse forbindelser der etableres
indefra. Og jeg holder mig ikke tilbage fra at kalde den en
firewall. Men jeg ville på den anden side ikke drømme om at
kalde den et generelt firewallprodukt.

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

---

>Hvis jeg bruger en ruter der kører NAT/PAT og ikke lukker nogen
>forbindelser ind på initiativ udefra overhovedet, så mener jeg
>ikke jeg har et sikkerhedsproblem i forhold til angreb udefra som
>en mere avanceret firewall kunne gøre noget fornuftigt ved
>(medmindre ruteren selv er sårbar, men det er en anden sag).
>
Den situation som du opridser hvor du ikke modtager nogle former for
connections initieret udefra er jo lang fra virkeligheden i over 95%
af de installationer der laves professionelt. Det er en helt anden ting hvis
vi snakker om private brugere..


>Min personlige brug af ordet "firewall" omfatter alt hvad der
>yder den fornødne beskyttelse til at man ikke behøver bekymre sig
>om indbrud i det interne net, og samtidig tillader den fornødne
>trafik. Således i mange tilfælde - ikke mindst for privatbrugere
>- også enkle pakkefiltre kombineret med NAT/PAT.
>
Det er så din fortolkning af ordet "firewall" og sikkert også en hel del
andres opfattelse, men et filter er kun et filter og kan på ingen måde give
samme sikkerhed som en firewall med intelligens så som statefull inspection.


>Det betyder ikke at jeg mener at man med rimelighed kan sælge et
>pakkefilter som en generelt anvendelig firewall. Et generelt
>anvendeligt firewallprodukt som på sikker vis skal kunne
>understøtte at der står servere på indersiden bør levere
>applikationsniveauproxyer til de almindeligt anvendte
>protokoller. Så måske er vi ikke særlig uenige, udover at jeg
>gerne bruger ordet "firewall" om et apparat der i den konkrete
>situation dækker behovet, selvom det ikke er _generelt_
>anvendeligt.
>
applikationsproxyer er en gammel måde at tænke på, det er dog rigtigt at en
sådan proxy har et højt sikkerhedsniveau, men man skal til gengæld have en
proxy pr. applikation og performance er et _større_ problem.


>På min arbejdsplads bruger vi fx en firewall jeg har flikket
>sammen af et Linuxsystem der kører ipchains med NAT, en
>SMTP-forwarder, BIND, og 4 netkort (ekstern, DMZ, to adskilte
>interne net). Bortset fra SMTP og DNS, som altså proxyes på
>applikationsniveau, så er det ren NAT og pakkefiltrering, inkl.
>
Nu svarer din bind forhåbentlig ikke på requests udefra, og du kører
forhåbentlig ikke sendmail som smtp-forwarder. Generelt skal en firewall
ikke køre andre service-applikationer ud over firewall funktionaliteten
selv. Ellers kan du løbe ind i *seriøse* sikkerhedsproblemer.

--
Gorm Jorgensen - UB++++
http://www.area51.dk/

---

Gorm@Area51.DK (Gorm Jorgensen) wrote:

>>Hvis jeg bruger en ruter der kører NAT/PAT og ikke lukker nogen
>>forbindelser ind på initiativ udefra overhovedet, så mener jeg
>>ikke jeg har et sikkerhedsproblem i forhold til angreb udefra som
>>en mere avanceret firewall kunne gøre noget fornuftigt ved
>>(medmindre ruteren selv er sårbar, men det er en anden sag).
>>
>Den situation som du opridser hvor du ikke modtager nogle former for
>connections initieret udefra er jo lang fra virkeligheden i over 95%
>af de installationer der laves professionelt. Det er en helt anden ting hvis
>vi snakker om private brugere..

Som jeg forsøgte at sige, så er det hele et spørgsmål om hvad man
har behov for.

På min arbejdsplads har vi hidtil kunne klare os med servere der
står i en DMZ (eller for en enkelts vedkommende helt på ydersiden
af firewallen) og ikke kan lave forbindelser indad; dvs. data der
skal flyttes fra det interne net til en server i DMZ skal _altid_
flyttes på initiativ indefra. Så længe man kan leve med det, så
giver NAT + pakkefilter ganske god sikkerhed for det interne net.

>>Min personlige brug af ordet "firewall" omfatter alt hvad der
>>yder den fornødne beskyttelse til at man ikke behøver bekymre sig
>>om indbrud i det interne net, og samtidig tillader den fornødne
>>trafik. Således i mange tilfælde - ikke mindst for privatbrugere
>>- også enkle pakkefiltre kombineret med NAT/PAT.
>>
>Det er så din fortolkning af ordet "firewall" og sikkert også en hel del
>andres opfattelse, men et filter er kun et filter og kan på ingen måde give
>samme sikkerhed som en firewall med intelligens så som statefull inspection.

Enhver nogenlunde ordentligt virkende NAT-implementation (hver
gang jeg siger NAT her mener jeg en mange-til-én NAT, også kaldet
PAT) har en grad af stateful inspection som gør den meget sikrere
end et ikke-NAT'ende filter. Den slipper jo ingen pakker ind
udefra som ikke matcher en forbindelse der er initieret indefra:
hvis implementationen er ordentlig, og det tror jeg den er i fx
Linux, er det sikkert nok til mig.

Men jeg er ganske enig i at et filter uden tilstandsanalyse, som
fx en ruters filtre uden NAT, er meget lidt sikre.

Jeg opfatter ordet "firewall" som primært beskrivende apparatets
funktion: en genstand hvis funktion er at beskytte et internt
net. Det kan den gøre dårligt eller godt, men jeg ville da kalde
den en firewall i alle tilfælde.

>>Det betyder ikke at jeg mener at man med rimelighed kan sælge et
>>pakkefilter som en generelt anvendelig firewall. Et generelt
>>anvendeligt firewallprodukt som på sikker vis skal kunne
>>understøtte at der står servere på indersiden bør levere
>>applikationsniveauproxyer til de almindeligt anvendte
>>protokoller. Så måske er vi ikke særlig uenige, udover at jeg
>>gerne bruger ordet "firewall" om et apparat der i den konkrete
>>situation dækker behovet, selvom det ikke er _generelt_
>>anvendeligt.
>>
>applikationsproxyer er en gammel måde at tænke på, det er dog rigtigt at en
>sådan proxy har et højt sikkerhedsniveau, men man skal til gengæld have en
>proxy pr. applikation og performance er et _større_ problem.

Ja. Hvilken teknik præcis er det egentlig du foretrækker som
åbenbart hverken er den stateful inspection enhver
NAT-implementation har eller en applikationsproxy?

>>På min arbejdsplads bruger vi fx en firewall jeg har flikket
>>sammen af et Linuxsystem der kører ipchains med NAT, en
>>SMTP-forwarder, BIND, og 4 netkort (ekstern, DMZ, to adskilte
>>interne net). Bortset fra SMTP og DNS, som altså proxyes på
>>applikationsniveau, så er det ren NAT og pakkefiltrering, inkl.
>>
>Nu svarer din bind forhåbentlig ikke på requests udefra,

Jo da, men kun for dens autoritative zoner. Den kører
naturligvis også i et chroot-fængsel og ikke som root (og jeg har
aldrig fattet hvorfor det ikke er BINDs normalkonfiguration) - og
det er stærkt begrænset hvad pakkefiltrene tillader lokale
processer at gøre mod det interne netværk. Men i øvrigt har du
naturligvis ret: man bør principielt slet ikke køre navneserver
på sin firewall overhovedet. Desværre er det lidt besværligt at
lave om på når den først er autoritativ for en 15-20 domæner, så
den har indtil videre alligevel fået lov til at blive ved med det
- og heldigvis kan den jo det med chroot.

>og du kører
>forhåbentlig ikke sendmail som smtp-forwarder.

Jo da, men kun som afsender, og den kører naturligvis ikke som
root. Modtagelsen er via den udmærkede sendmail-frontend "smtpd"
som kan findes på www.obtuse.com. (Jeg har måttet rette et par
(ikke sikkerhedsrelaterede) småfejl i den, men så virker den også
fint.) Hvis jeg skulle installere den forfra nu til dags, ville
jeg måske vælge postfix, fordi det er nemmere og formodentlig ca.
lige så sikkert.

>Generelt skal en firewall
>ikke køre andre service-applikationer ud over firewall funktionaliteten
>selv. Ellers kan du løbe ind i *seriøse* sikkerhedsproblemer.

Herhjemme har jeg jo en lidt anden situation: her er min
Linuxboks både firewall og webserver. Det skal man naturligvis
aldrig gøre på steder hvor man har råd og plads til en separat
server, men det viser sig at man faktisk med Linux 2.4 og
netfilter kan opnå en imponerende grad af sikkerhed alligevel,
fordi man kan lave filtre som hindrer lokale processer med
bestemte brugernavne i bestemte ting. De brugernavne der kører
CGI-scripts på min hjemmeLinux har fx slet ikke lov til at lave
forbindelser ind i det interne net (hvor min Windowsmaskine
står). Tilsvarende har det brugernavn der kører BIND lov til at
svare på DNS-forespørgsler indefra, men ikke til at lave nogen
som helst forbindelser indad på eget initiativ.

Det er faktisk en ret smart egenskab ved netfilter.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).

---

>Som jeg forsøgte at sige, så er det hele et spørgsmål om hvad man
>har behov for.
>
>På min arbejdsplads har vi hidtil kunne klare os med servere der
>står i en DMZ (eller for en enkelts vedkommende helt på ydersiden
>af firewallen) og ikke kan lave forbindelser indad; dvs. data der
>skal flyttes fra det interne net til en server i DMZ skal _altid_
>flyttes på initiativ indefra. Så længe man kan leve med det, så
>giver NAT + pakkefilter ganske god sikkerhed for det interne net.
>
Jeg kan kun give dig ret, at købe firewall er ikke som at tage et produkt
ned fra en hylde, det kommer an på hvor højt dit sikkerhedsniveau er..

>Men jeg er ganske enig i at et filter uden tilstandsanalyse, som
>fx en ruters filtre uden NAT, er meget lidt sikre.
>
>Jeg opfatter ordet "firewall" som primært beskrivende apparatets
>funktion: en genstand hvis funktion er at beskytte et internt
>net. Det kan den gøre dårligt eller godt, men jeg ville da kalde
>den en firewall i alle tilfælde.
>
Igen kan ordet bruges på mange måder, jeg foretrækker at bruge de tekniske
termer, og kalde et filter for et filter en proxy for proxy o.s.v.

>>applikationsproxyer er en gammel måde at tænke på, det er dog rigtigt at en
>>sådan proxy har et højt sikkerhedsniveau, men man skal til gengæld have en
>>proxy pr. applikation og performance er et _større_ problem.
>
>Ja. Hvilken teknik præcis er det egentlig du foretrækker som
>åbenbart hverken er den stateful inspection enhver
>NAT-implementation har eller en applikationsproxy?
>
Jeg foretrækker skam statefull inspection, jeg mener da ikke har har
udtalt noget andet, i så fald har jeg udtrykt mig forkert.


>>Nu svarer din bind forhåbentlig ikke på requests udefra,
>
>Jo da, men kun for dens autoritative zoner. Den kører
>naturligvis også i et chroot-fængsel og ikke som root (og jeg har
>aldrig fattet hvorfor det ikke er BINDs normalkonfiguration) - og
>det er stærkt begrænset hvad pakkefiltrene tillader lokale
>processer at gøre mod det interne netværk. Men i øvrigt har du
>naturligvis ret: man bør principielt slet ikke køre navneserver
>på sin firewall overhovedet. Desværre er det lidt besværligt at
>lave om på når den først er autoritativ for en 15-20 domæner, så
>den har indtil videre alligevel fået lov til at blive ved med det
>- og heldigvis kan den jo det med chroot.
>
Det er faktisk ikke så svært at flytte en autoritativ dns da du kan få lavet
en glue ændring hos DK-Hostmaster, bare du benytter det samme dns navn.

>>og du kører
>>forhåbentlig ikke sendmail som smtp-forwarder.
>
>Jo da, men kun som afsender, og den kører naturligvis ikke som
>root. Modtagelsen er via den udmærkede sendmail-frontend "smtpd"
>som kan findes på www.obtuse.com. (Jeg har måttet rette et par
>(ikke sikkerhedsrelaterede) småfejl i den, men så virker den også
>fint.) Hvis jeg skulle installere den forfra nu til dags, ville
>jeg måske vælge postfix, fordi det er nemmere og formodentlig ca.
>lige så sikkert.
>
Det ville jeg så ikke vælge, jeg ville bruge en mindre usikker frontend så
som postfix ell. qmail, men at du så kører chroot er da en sikre måde at
køre det på, jeg ville dog vælge at have en maskine på et DMZ så jeg ikke
bruger min firewall til det.

>>Generelt skal en firewall
>>ikke køre andre service-applikationer ud over firewall funktionaliteten
>>selv. Ellers kan du løbe ind i *seriøse* sikkerhedsproblemer.
>
>Herhjemme har jeg jo en lidt anden situation: her er min
>Linuxboks både firewall og webserver. Det skal man naturligvis
>aldrig gøre på steder hvor man har råd og plads til en separat
>server, men det viser sig at man faktisk med Linux 2.4 og
>netfilter kan opnå en imponerende grad af sikkerhed alligevel,
>fordi man kan lave filtre som hindrer lokale processer med
>bestemte brugernavne i bestemte ting. De brugernavne der kører
>CGI-scripts på min hjemmeLinux har fx slet ikke lov til at lave
>forbindelser ind i det interne net (hvor min Windowsmaskine
>står). Tilsvarende har det brugernavn der kører BIND lov til at
>svare på DNS-forespørgsler indefra, men ikke til at lave nogen
>som helst forbindelser indad på eget initiativ.
>
Et hjemmenet behøver heller ikke altid at have det samme sikkerhedsniveau
som et virksomhedsnet, som privat har man jo heller ikke uanede mængder af
maskiner/penge Du er da også gået lang videre end så mange andre, ved at
begrænse applikationer..

--
Gorm Jorgensen - UB++++
http://www.area51.dk/

---

Miks skrev:

>Jeg synes at have læst et eller andet sted, at man kan forøge sikkerheden
>ved at have en ekstra pc imellem den alm. daglige Pc og ADSL nettet.

Det er sikkert rigtigt. Jeg fik at vide af en erfaren
netspecialist at han ikke kunne drømme om at køre en firewall på
andet end en særskilt computer, men det er nok at skyde gråspurve
med kanoner hvis det bare er til et lille hjemmenet - især da
fordi det åbenbart er tvivlsomt om der overhovedet er brug for en
firewall til det.

>(hvorfor er dette bedre end bare en firewall software på drift Pc'en?)

Jo flere led, jo sværere at trænge ind? Lille Peter kommer ikke
ved et uheld til at disable firewallen?
Jeg ved det ikke præcist.

--
Bertel
http://lundhansen.dk/bertel/   FIDUSO: http://fiduso.dk/