---

Jeg er på udkig efter en router, primært for at dele en internetforbindelse
mellem flere brugere på et netværk.

Flere producenter af routere skriver at NAT giver sikkerhed mod hackere
eksempelvis Netgear som skriver; "Rest assured that your network is
protected against hackers thanks to Network Address Translation (NAT)
firewall".

Så er det at jeg tænker...... Giver det virkelig en sikkerhed eller er der
tale om varm reklameluft her?

Claus

---

"Claus Nygaard-Pedersen" <cnpXX@ofir.dk> wrote in message
news:aap5ct$e9q$1@sunsite.dk...
> Jeg er på udkig efter en router, primært for at dele en
internetforbindelse
> mellem flere brugere på et netværk.
>
> Flere producenter af routere skriver at NAT giver sikkerhed mod hackere
> eksempelvis Netgear som skriver; "Rest assured that your network is
> protected against hackers thanks to Network Address Translation (NAT)
> firewall".
>
> Så er det at jeg tænker...... Giver det virkelig en sikkerhed eller er der
> tale om varm reklameluft her?

Det giver en vis grad af sikkerhed, ja
Forstået på den måde alle dine maskiner på lokalnettet bliver 'skjult' bag
det IP nummer NAT boksen har fået sin yderside.
Du altså ikke umiddelbart portscanne eller på anden komme i kontakt med dine
maskine udefra (medmindre self du fanger en session der allerede er åbnet
inde eller fordi du har redirectet en masse fra den NAT boks)
For nogen er NAT godt nok, men igen det kommer anpå hvor parnoid du er..


/Dennis

---

Dennis Pedersen wrote:

> Det giver en vis grad af sikkerhed, ja


NAT giver ingen sikkerhed.

NAT kombineret med fornuftige filtre, ja, men det er en helt anden historie.

> Forstået på den måde alle dine maskiner på lokalnettet bliver 'skjult' bag
> det IP nummer NAT boksen har fået sin yderside.

> Du altså ikke umiddelbart portscanne eller på anden komme i kontakt med dine
> maskine udefra (medmindre self du fanger en session der allerede er åbnet


Hvad forhindre mig i at bruger routeren som router?

> inde eller fordi du har redirectet en masse fra den NAT boks)
> For nogen er NAT godt nok, men igen det kommer anpå hvor parnoid du er..


Parnoid?

http://www.bursztein.net/secu/pixieadv.html

---

On Wed, 01 May 2002 21:49:48 +0200, Christian E. Lysel wrote:
> Dennis Pedersen wrote:
>
>> Det giver en vis grad af sikkerhed, ja
>
> NAT giver ingen sikkerhed.

Det er nu ikke helt rigtigt, hvis vi taler om NAT som i PAT, hvor der
skal være en aktiv port mapping for at udefra kommende trafik kommer
videre til de indre host, så giver det en ikke ubetydelig sikkerhed, da
en angriber ikke kan komme til de services som kører på klienten.

--
Jesper Skriver, CCIE #5456
FreeBSD committer

---

Jesper Skriver wrote:

> Det er nu ikke helt rigtigt, hvis vi taler om NAT som i PAT, hvor der
> skal være en aktiv port mapping for at udefra kommende trafik kommer
> videre til de indre host, så giver det en ikke ubetydelig sikkerhed, da
> en angriber ikke kan komme til de services som kører på klienten.


Hvis du har en router med to interface, og du slå NAT/PAT til, vil din
router da stadigvæk route trafikken igennem begge interfaces, dette
ændre NAT/PAT ikke noget ved.

---

On Wed, 01 May 2002 22:20:49 +0200, Christian E. Lysel wrote:
> Jesper Skriver wrote:
>
>> Det er nu ikke helt rigtigt, hvis vi taler om NAT som i PAT, hvor der
>> skal være en aktiv port mapping for at udefra kommende trafik kommer
>> videre til de indre host, så giver det en ikke ubetydelig sikkerhed, da
>> en angriber ikke kan komme til de services som kører på klienten.
>
> Hvis du har en router med to interface, og du slå NAT/PAT til, vil din
> router da stadigvæk route trafikken igennem begge interfaces, dette
> ændre NAT/PAT ikke noget ved.

Nej, men i Internet sammenhæng, så router en ISP alså ikke de rfc1918
adresser som kunden typisk har på indersiden af NAT devicet.

Og så betyder det intet.

--
Jesper Skriver, CCIE #5456
FreeBSD committer

---

Jesper Skriver wrote:

>>Hvis du har en router med to interface, og du slå NAT/PAT til, vil din
>>router da stadigvæk route trafikken igennem begge interfaces, dette
>>ændre NAT/PAT ikke noget ved.
> Nej, men i Internet sammenhæng, så router en ISP alså ikke de rfc1918
> adresser som kunden typisk har på indersiden af NAT devicet.


Hvem siger kunden har rfc1918 adresse på indersiden?

Endvidere har jeg set flere eksempler på ISP'er der router pakker med
rfc1918 adresser som source.

En anden angrebs metode kan være en server der står foran routeren, hvis
serveren er sat forkert op, fx med compaq managment system som proxy'er
http request, vil det også være muligt at skyde mod et rfc1918 adresse
rum bag routeren. Her vil en ISP ingress og rfc1918 filter ikke
forhindre noget.

Andre eksempler kan være socks4 og socks5, dem er der mange af der er
sat forkert op.

> Og så betyder det intet.


Når man tror det intet betyder, betyder det alt. :)

---

On Wed, 01 May 2002 22:54:18 +0200, Christian E. Lysel wrote:
> Jesper Skriver wrote:
>
>>>Hvis du har en router med to interface, og du slå NAT/PAT til, vil din
>>>router da stadigvæk route trafikken igennem begge interfaces, dette
>>>ændre NAT/PAT ikke noget ved.
>> Nej, men i Internet sammenhæng, så router en ISP alså ikke de rfc1918
>> adresser som kunden typisk har på indersiden af NAT devicet.
>
> Hvem siger kunden har rfc1918 adresse på indersiden?

Det har 99.9% af alle private brugere på ADSL.

> Endvidere har jeg set flere eksempler på ISP'er der router pakker med
> rfc1918 adresser som source.

Source er 100% ligegyldig her, når vi taler om situationer hvor en
angriber på Internet tilgår en intern service.

> En anden angrebs metode kan være en server der står foran routeren, hvis
> serveren er sat forkert op, fx med compaq managment system som proxy'er
> http request, vil det også være muligt at skyde mod et rfc1918 adresse
> rum bag routeren. Her vil en ISP ingress og rfc1918 filter ikke
> forhindre noget.

Hvor mange er der af dem på en typisk ADSL linie ?

> Andre eksempler kan være socks4 og socks5, dem er der mange af der er
> sat forkert op.

ditto.

>> Og så betyder det intet.
>
> Når man tror det intet betyder, betyder det alt. :)

Vrøvl

--
Jesper Skriver, CCIE #5456
FreeBSD committer

---

Jesper Skriver wrote:

>>Hvem siger kunden har rfc1918 adresse på indersiden?
> Det har 99.9% af alle private brugere på ADSL.


Hvem snakker private brugere på ADSL, vi snakker om at dele en
internetforbindelse?

Endvidere går dit argment på at ISP har sat resten sikkert op, det jeg
snakker om er NAT som en selvstændig feature der intet har med sikkerhed
at gøre.

Du snakker om NAT som en helhed i et ISP netværk, hvilket jeg ser som at
snakke uden om.

Mit argument går på at man ikke kan klarer sig med NAT alene i en
router, men også bør have nogle fornuftige filtre.

>>Endvidere har jeg set flere eksempler på ISP'er der router pakker med
>>rfc1918 adresser som source.
> Source er 100% ligegyldig her, når vi taler om situationer hvor en
> angriber på Internet tilgår en intern service.


Hvorfor er source ligegyldigt?

Setup:
angriber 1.1.1.2 --- 1.1.1.1 router 192.168.1.1 --- 192.168.1.2 klient

Angriberen bygger en pakke med følgende udseende:

proto icmp, type echo request, source 192.168.1.2, destination 1.1.1.1

Routeren vil herefter svarer med følgende pakke.

proto icmp, type echo reply, source 1.1.1.1, destination 192.168.1.2

Herved kan jeg udefra sende trafik ind på det private net.

Selvfølgelig er ovenstående uskadeligt, men at det intet betyder giver
jeg dig ikke ret i.

Ovenstående kan også designes mere destruktivt.

>>En anden angrebs metode kan være en server der står foran routeren, hvis
>>serveren er sat forkert op, fx med compaq managment system som proxy'er
[cut]

> Hvor mange er der af dem på en typisk ADSL linie ?


Hvem snakker om ADSL?

[cut]


>>>Og så betyder det intet.
>>Når man tror det intet betyder, betyder det alt. :)
> Vrøvl


Det som man ser det.

---

On Wed, 01 May 2002 23:58:55 +0200, Christian E. Lysel wrote:
> Jesper Skriver wrote:
>
>>>Hvem siger kunden har rfc1918 adresse på indersiden?
>> Det har 99.9% af alle private brugere på ADSL.
>
> Hvem snakker private brugere på ADSL, vi snakker om at dele en
> internetforbindelse?

Den oprindelige poster, kan næppe tolkes som andet end en privat bruger,
der omtales også de små CPE routere, f.eks. NetGear.

> Endvidere går dit argment på at ISP har sat resten sikkert op, det
> jeg snakker om er NAT som en selvstændig feature der intet har med
> sikkerhed at gøre.

Jo, du kan være 100% sikker på at en ISP ikke router rfc1918 adresser ud
til en kunde.

> Du snakker om NAT som en helhed i et ISP netværk, hvilket jeg ser som
> at snakke uden om.

Nej jeg gør ikke.

> Mit argument går på at man ikke kan klarer sig med NAT alene i en
> router, men også bør have nogle fornuftige filtre.

Kommer an på situationen !

>>>Endvidere har jeg set flere eksempler på ISP'er der router pakker med
>>>rfc1918 adresser som source.
>>
>> Source er 100% ligegyldig her, når vi taler om situationer hvor en
>> angriber på Internet tilgår en intern service.
>
> Hvorfor er source ligegyldigt?

Fordi det i det konkrete tilfælde handler om hvorvidt destination
adressen gør at NAT routeren forward'er pakken til indersiden eller ej,
og routening går som bekendt på DESTINATION adressen, og ikke SOURCE
adressen !

> Setup:
> angriber 1.1.1.2 --- 1.1.1.1 router 192.168.1.1 --- 192.168.1.2 klient
>
> Angriberen bygger en pakke med følgende udseende:
>
> proto icmp, type echo request, source 192.168.1.2, destination 1.1.1.1
>
> Routeren vil herefter svarer med følgende pakke.
>
> proto icmp, type echo reply, source 1.1.1.1, destination 192.168.1.2
>
> Herved kan jeg udefra sende trafik ind på det private net.
>
> Selvfølgelig er ovenstående uskadeligt, men at det intet betyder giver
> jeg dig ikke ret i.
>
> Ovenstående kan også designes mere destruktivt.

Hvorledes vil du få routeren til at sende en "skadelig" pakke ind på det
interne net på den måde, på ovenstående vis kan du få sendt ICMP og evt.
svar på TCP/UDP smallservers - men ikke vilkårlige pakker.

>>>En anden angrebs metode kan være en server der står foran routeren, hvis
>>>serveren er sat forkert op, fx med compaq managment system som proxy'er
> [cut]
>
>> Hvor mange er der af dem på en typisk ADSL linie ?
>
> Hvem snakker om ADSL?

Se ovenfor !

--
Jesper Skriver, CCIE #5456
FreeBSD committer

---

Jesper Skriver wrote:

>>Hvem snakker private brugere på ADSL, vi snakker om at dele en
>>internetforbindelse?
> Den oprindelige poster, kan næppe tolkes som andet end en privat bruger,
> der omtales også de små CPE routere, f.eks. NetGear.


Det kan også være en ISDN router.

Disse har i mange konfigurationer store sikkerhedsproblemer, grundet
teleoperatøren.

>>Endvidere går dit argment på at ISP har sat resten sikkert op, det
>>jeg snakker om er NAT som en selvstændig feature der intet har med
>>sikkerhed at gøre.
> Jo, du kan være 100% sikker på at en ISP ikke router rfc1918 adresser ud
> til en kunde.


>>Du snakker om NAT som en helhed i et ISP netværk, hvilket jeg ser som
>>at snakke uden om.
> Nej jeg gør ikke.


Han spørger til NAT og ikke et ISP's netværk.

Jeg har endvidere den holdning at ens sikkerhed ikke bør være afhængig
af en ISP's sikkerhed.


Selv har jeg oplevet flere tilfælde hvor det har været trivielt at få
adgang til fx Cisco routeren.

Typisk kan passwordet gættes, dette har jeg set flere eksempler på.

En gang har jeg oplevet hos "en af de 5 største danske ISP'er" at et
telefon opkald til den rigtige person har resulteret i oplysning af
deres standard password til 1/3 af deres router!

En anden metode er at smide en WAN sniffer på seriel interfacet, og
ringe efter en konfigurationsændring, herefter logger ISPen på routeren
med telnet og passwordet bliver sent i klar tekst (en metode kan være
brute forcing). Hos nogle ISP'er kan dette password bruges hos andre kunder.

Har jeg først adgang til ISP'erens router, kan jeg fx bygger en GRE
tunnel til transport af pakker med rfc1918 adresser, og kan herved
hurtigt få adgang til kundens interne net der "kun er beskyttet af en
router med NAT".

En anden angrebsvej kan være via den blå boks der sidder ude på vejen og
noget udstyr til at bryde ind i en ISDN/ADSL/ecetera forbindelse. Det
sidste sted jeg arbejde havde vi dette til rådighed, og det var muligt
at sniffe traffik og at injecte traffik ind i forbindelsen. Udstyret kan
lejes eller købes (sidste nævnte hvis man har _mange_ penge). Denne
mulighed er overset af mange, når man tænker sikkerhed.

>>Mit argument går på at man ikke kan klarer sig med NAT alene i en
>>router, men også bør have nogle fornuftige filtre.
> Kommer an på situationen !


Vil det sige du vil anbefalde folk at konfigurere en router med NAT uden
filtre?

I hvilke situationer vil du det?

>>Ovenstående kan også designes mere destruktivt.

> Hvorledes vil du få routeren til at sende en "skadelig" pakke ind på det
> interne net på den måde, på ovenstående vis kan du få sendt ICMP og evt.
> svar på TCP/UDP smallservers - men ikke vilkårlige pakker.


Og du ser ikke noget problem i at det er muligt at sende trafik ind på
et lokalt netværk?

>>>>En anden angrebs metode kan være en server der står foran routeren, hvis
>>>>serveren er sat forkert op, fx med compaq managment system som proxy'er
>>>Hvor mange er der af dem på en typisk ADSL linie ?
>>Hvem snakker om ADSL?
> Se ovenfor !


Du snakker stadigvæk om en ISP's sikkerhed og ikke om den ikke eksiterne
sikkerhed ved NAT/PAT.

NAT/PAT har ikke noget med sikkerhed og beskyttelse af segmenter at
gøre, men er en ren adresse oversættelse.

---

On Thu, 02 May 2002 20:34:24 +0200, Christian E. Lysel wrote:
> Jesper Skriver wrote:
>
>>>Hvem snakker private brugere på ADSL, vi snakker om at dele en
>>>internetforbindelse?
>> Den oprindelige poster, kan næppe tolkes som andet end en privat bruger,
>> der omtales også de små CPE routere, f.eks. NetGear.
>
> Det kan også være en ISDN router.

Ja, men i denne sammenhæng er det samme situation, ISP'en router
ikke rfc1918 adresser til kunden.

> Disse har i mange konfigurationer store sikkerhedsproblemer, grundet
> teleoperatøren.

Uddyb venligst.

>>>Endvidere går dit argment på at ISP har sat resten sikkert op, det
>>>jeg snakker om er NAT som en selvstændig feature der intet har med
>>>sikkerhed at gøre.
>>
>> Jo, du kan være 100% sikker på at en ISP ikke router rfc1918 adresser ud
>> til en kunde.
>
>>>Du snakker om NAT som en helhed i et ISP netværk, hvilket jeg ser som
>>>at snakke uden om.
>>
>> Nej jeg gør ikke.
>
> Han spørger til NAT og ikke et ISP's netværk.

Ja.

> Jeg har endvidere den holdning at ens sikkerhed ikke bør være afhængig
> af en ISP's sikkerhed.

Det har ikke noget med ISP'ens sikkerhed at gøre, men det faktum at en
ISP ikke router de rfc1918 adresser han har på indersiden til ham.

> Selv har jeg oplevet flere tilfælde hvor det har været trivielt at få
> adgang til fx Cisco routeren.
>
> Typisk kan passwordet gættes, dette har jeg set flere eksempler på.

Ja, derfor bør der naturligvis vælges fornuftige passwords, og sikres at
man kun kan tilgå routeren fra "sikre" ip adresser.

> En gang har jeg oplevet hos "en af de 5 største danske ISP'er" at et
> telefon opkald til den rigtige person har resulteret i oplysning af
> deres standard password til 1/3 af deres router!
>
> En anden metode er at smide en WAN sniffer på seriel interfacet,
> og ringe efter en konfigurationsændring, herefter logger ISPen på
> routeren med telnet og passwordet bliver sent i klar tekst (en metode
> kan være brute forcing). Hos nogle ISP'er kan dette password bruges
> hos andre kunder.

Dette vil være direkte kriminelt, og ikke noget en 3. part kan gøre.

> Har jeg først adgang til ISP'erens router, kan jeg fx bygger en GRE
> tunnel til transport af pakker med rfc1918 adresser, og kan herved
> hurtigt få adgang til kundens interne net der "kun er beskyttet af en
> router med NAT".

Hvis du først har adgang til routeren, så kan du også fjerne de filtre
som er i den.

> En anden angrebsvej kan være via den blå boks der sidder ude på
> vejen og noget udstyr til at bryde ind i en ISDN/ADSL/ecetera
> forbindelse. Det sidste sted jeg arbejde havde vi dette til rådighed,
> og det var muligt at sniffe traffik og at injecte traffik ind i
> forbindelsen. Udstyret kan lejes eller købes (sidste nævnte hvis man
> har _mange_ penge). Denne mulighed er overset af mange, når man tænker
> sikkerhed.
>
>>>Mit argument går på at man ikke kan klarer sig med NAT alene i en
>>>router, men også bør have nogle fornuftige filtre.
>>
>> Kommer an på situationen !
>
> Vil det sige du vil anbefalde folk at konfigurere en router med NAT
> uden filtre?

Ja, hvis vi taler om hr og fru Hansen på deres hjemme netværk.

>>>Ovenstående kan også designes mere destruktivt.
>>
>> Hvorledes vil du få routeren til at sende en "skadelig" pakke ind på
>> det interne net på den måde, på ovenstående vis kan du få sendt ICMP
>> og evt. svar på TCP/UDP smallservers - men ikke vilkårlige pakker.
>
> Og du ser ikke noget problem i at det er muligt at sende trafik ind på
> et lokalt netværk?

Ikke så længe at der er tale om en ICMP pakke.

>>>>>En anden angrebs metode kan være en server der står foran
>>>>>routeren, hvis serveren er sat forkert op, fx med compaq managment
>>>>>system som proxy'er
>>>>
>>>>Hvor mange er der af dem på en typisk ADSL linie ?
>>>
>>>Hvem snakker om ADSL?
>>
>> Se ovenfor !
>
> Du snakker stadigvæk om en ISP's sikkerhed og ikke om den ikke
> eksiterne sikkerhed ved NAT/PAT.
>
> NAT/PAT har ikke noget med sikkerhed og beskyttelse af segmenter at
> gøre, men er en ren adresse oversættelse.

Det giver en VIS sikkerhed, ved at man ikke kan connecte fra Internet
til de services der måtte køre på en intern maskine, som jeg started med
at sige.

Det er klart at man med andre metoder kan få mere sikkerhed, men en
ganske simple NAT router, giver ofte en tilstrækkelig sikkerhed.

--
Jesper Skriver, CCIE #5456
FreeBSD committer

---

Jesper Skriver wrote:

>>Disse har i mange konfigurationer store sikkerhedsproblemer, grundet
>>teleoperatøren.
> Uddyb venligst.


Helst ikke, problemet går ud på at der stoles for meget på teleudbyderen
og det er muligt at ændre noget som jeg ikke ønsker at komme ind på. Jeg
har endvidere vendt den med en tdc teknikker og han gav mig desværre ret.

Endvidere har jeg selv testet sikkerhedshuller på egne telefon- og ISDN
linier, og sikkerhedshullet fungere fint og har fungeret i mange år.

Jeg ønsker dog ikke at udtale mig om hvordan det praktisk virker, regner
med du har forståelse for dette.

Endvidere er det udmærket at kende i forbindelse med en auditering :)

>>Jeg har endvidere den holdning at ens sikkerhed ikke bør være afhængig
>>af en ISP's sikkerhed.

> Det har ikke noget med ISP'ens sikkerhed at gøre, men det faktum at en
> ISP ikke router de rfc1918 adresser han har på indersiden til ham.


Det har meget med ISP'ens sikkerhed at gøre, om man kan router rfc1918
adresser.

> Ja, derfor bør der naturligvis vælges fornuftige passwords, og sikres at
> man kun kan tilgå routeren fra "sikre" ip adresser.


_Meget_ enig :)

>>En gang har jeg oplevet hos "en af de 5 største danske ISP'er" at et
>>telefon opkald til den rigtige person har resulteret i oplysning af
>>deres standard password til 1/3 af deres router!
>>
>>En anden metode er at smide en WAN sniffer på seriel interfacet,
>>og ringe efter en konfigurationsændring, herefter logger ISPen på
>>routeren med telnet og passwordet bliver sent i klar tekst (en metode
>>kan være brute forcing). Hos nogle ISP'er kan dette password bruges
>>hos andre kunder.
> Dette vil være direkte kriminelt, og ikke noget en 3. part kan gøre.


Telefon opkalder kan alle fortage.

Sniffning af password kan alle ISP'ens kunder fortage, med det rette udstyr.

Ja, selvfølgelig er det kriminelt, hvis der ikke forligger en aftale i
forbindelse med fx en auditering. At det er kriminelt afholder mig også
fra at gøre det i min fritid.

>>Har jeg først adgang til ISP'erens router, kan jeg fx bygger en GRE
>>tunnel til transport af pakker med rfc1918 adresser, og kan herved
>>hurtigt få adgang til kundens interne net der "kun er beskyttet af en
>>router med NAT".
> Hvis du først har adgang til routeren, så kan du også fjerne de filtre
> som er i den.


Jeg snakker om ISP'ens router ikke om kundens router han selv køber.

>>Vil det sige du vil anbefalde folk at konfigurere en router med NAT
>>uden filtre?
> Ja, hvis vi taler om hr og fru Hansen på deres hjemme netværk.


>>Og du ser ikke noget problem i at det er muligt at sende trafik ind på
>>et lokalt netværk?
> Ikke så længe at der er tale om en ICMP pakke.


Det er vel smag og beha', jeg bryder mig ikke om at udefra kommende kan
trafikken ind på mit private net. Det er det jeg forstår ved noget der
er privat.

>>NAT/PAT har ikke noget med sikkerhed og beskyttelse af segmenter at
>>gøre, men er en ren adresse oversættelse.
> Det giver en VIS sikkerhed, ved at man ikke kan connecte fra Internet
> til de services der måtte køre på en intern maskine, som jeg started med

> at sige.

Dette forhindre NAT/PAT ikke...dette forhindre ISP'en (hvis man stoler
på ISP'en) dit argment går primært på at ISP'en ikke tillader rfc1918
adresser.


> Det er klart at man med andre metoder kan få mere sikkerhed, men en
> ganske simple NAT router, giver ofte en tilstrækkelig sikkerhed.

Du mener den giver tilstrækkelig sikkerhed i forbindelse med udbyderens
sikkerhed, dvs. at udbyderen ikke router rfc1918 adresser.

---

On Thu, 02 May 2002 21:09:51 +0200, Christian E. Lysel wrote:

> Jesper Skriver wrote:
>
>>>Disse har i mange konfigurationer store sikkerhedsproblemer, grundet
>>>teleoperatøren.
>>
>> Uddyb venligst.
>
> Helst ikke, problemet går ud på at der stoles for meget på
> teleudbyderen og det er muligt at ændre noget som jeg ikke ønsker at
> komme ind på. Jeg har endvidere vendt den med en tdc teknikker og han
> gav mig desværre ret.
>
> Endvidere har jeg selv testet sikkerhedshuller på egne telefon- og
> ISDN linier, og sikkerhedshullet fungere fint og har fungeret i mange
> år.
>
> Jeg ønsker dog ikke at udtale mig om hvordan det praktisk virker,
> regner med du har forståelse for dette.
>
> Endvidere er det udmærket at kende i forbindelse med en auditering :)

Sådanne udokumentere påstande kan jeg ikke bruge til noget.

Iøvrigt kan jeg ikke se hvordan det skulle have noget med sikkerheden
for en ISDN router at gøre.

>>>Jeg har endvidere den holdning at ens sikkerhed ikke bør være afhængig
>>>af en ISP's sikkerhed.
>
>> Det har ikke noget med ISP'ens sikkerhed at gøre, men det faktum at en
>> ISP ikke router de rfc1918 adresser han har på indersiden til ham.
>
> Det har meget med ISP'ens sikkerhed at gøre, om man kan router rfc1918
> adresser.

Nej - det er der INGEN ISP'er som gør.

>> Ja, derfor bør der naturligvis vælges fornuftige passwords, og sikres
>> at man kun kan tilgå routeren fra "sikre" ip adresser.
>
> _Meget_ enig :)
>
>>>En gang har jeg oplevet hos "en af de 5 største danske ISP'er" at et
>>>telefon opkald til den rigtige person har resulteret i oplysning af
>>>deres standard password til 1/3 af deres router!
>>>
>>>En anden metode er at smide en WAN sniffer på seriel interfacet,
>>>og ringe efter en konfigurationsændring, herefter logger ISPen på
>>>routeren med telnet og passwordet bliver sent i klar tekst (en metode
>>>kan være brute forcing). Hos nogle ISP'er kan dette password bruges
>>>hos andre kunder.
>>
>> Dette vil være direkte kriminelt, og ikke noget en 3. part kan gøre.
>
> Telefon opkalder kan alle fortage.
>
> Sniffning af password kan alle ISP'ens kunder fortage, med det rette
> udstyr.

Ikke passwords til ISP'ens udstyr.

> Ja, selvfølgelig er det kriminelt, hvis der ikke forligger en aftale
> i forbindelse med fx en auditering. At det er kriminelt afholder mig
> også fra at gøre det i min fritid.
>
>>>Har jeg først adgang til ISP'erens router, kan jeg fx bygger en GRE
>>>tunnel til transport af pakker med rfc1918 adresser, og kan herved
>>>hurtigt få adgang til kundens interne net der "kun er beskyttet af en
>>>router med NAT".
>>
>> Hvis du først har adgang til routeren, så kan du også fjerne de
>> filtre som er i den.
>
> Jeg snakker om ISP'ens router ikke om kundens router han selv køber.

Du kan ikke logge ind i ISP'ens router, og du kan ikke sniffe dens
password ved at have en sniffer på WAN linien.

Ligeledes kender jeg ingen ISP, hvor man får en login prompt, hvis man
ikke kommer fra de rigtigte IP adresser.

>>>Vil det sige du vil anbefalde folk at konfigurere en router med NAT
>>>uden filtre?
>>
>> Ja, hvis vi taler om hr og fru Hansen på deres hjemme netværk.
>>
>>>Og du ser ikke noget problem i at det er muligt at sende trafik ind
>>>på et lokalt netværk?
>>
>> Ikke så længe at der er tale om en ICMP pakke.
>
> Det er vel smag og beha', jeg bryder mig ikke om at udefra kommende
> kan trafikken ind på mit private net. Det er det jeg forstår ved noget
> der er privat.

Men en ICMP svar pakke fra routeren, gør ingen skade, og kan ikke på
nogen måde give en "angriber" information om det interne net.

>>>NAT/PAT har ikke noget med sikkerhed og beskyttelse af segmenter at
>>>gøre, men er en ren adresse oversættelse.
>>
>> Det giver en VIS sikkerhed, ved at man ikke kan connecte fra Internet
>> til de services der måtte køre på en intern maskine, som jeg started
>> med at sige.
>
> Dette forhindre NAT/PAT ikke...dette forhindre ISP'en (hvis man stoler
> på ISP'en) dit argment går primært på at ISP'en ikke tillader rfc1918
> adresser.

Det handler netop IKKE om at tillade rfc1918 adresser, det handler om
ISP'en router pakker med en rfc1918 DESTINATION adresse til den kunde.

>> Det er klart at man med andre metoder kan få mere sikkerhed, men en
>> ganske simple NAT router, giver ofte en tilstrækkelig sikkerhed.
>
> Du mener den giver tilstrækkelig sikkerhed i forbindelse med
> udbyderens sikkerhed, dvs. at udbyderen ikke router rfc1918 adresser.

Se ovenfor.

--
Jesper Skriver, CCIE #5456
FreeBSD committer

---

Jesper Skriver wrote:

> Sådanne udokumentere påstande kan jeg ikke bruge til noget.


Enig, lad os glemme det.

> Iøvrigt kan jeg ikke se hvordan det skulle have noget med sikkerheden
> for en ISDN router at gøre.


Enig, jeg forstår dig.

>>Det har meget med ISP'ens sikkerhed at gøre, om man kan router rfc1918
>>adresser.
> Nej - det er der INGEN ISP'er som gør.


Et er hvad ISP'en _forsøger_ at opnå, et andet er hvad der faktisk er
muligt.

>>Telefon opkalder kan alle fortage.

>>Sniffning af password kan alle ISP'ens kunder fortage, med det rette
>>udstyr.
> Ikke passwords til ISP'ens udstyr.


Hvorfor ikke?

Jeg har en router stående hos mig der tilhørere min ISP, jeg smider en
sniffer på WAN linien, når udbyderen logger på routeren kan jeg da se
passwordet. Hvilken udbyder bruger kryptering på sin WAN forbindelse.

Selvfølgelig er der muligheden for at kører SSH, og i dette tilfælde vil
ovenstående ikke være muligt.

>>Jeg snakker om ISP'ens router ikke om kundens router han selv køber.
> Du kan ikke logge ind i ISP'ens router, og du kan ikke sniffe dens
> password ved at have en sniffer på WAN linien.


Hvorfor kan jeg ikke sniffe på en WAN linie?

Jeg har arbejdet med udstyr der er bygget til dette formål, nemlig at
sniffe trafik (i forbindelse med fejlsøgning).


> Ligeledes kender jeg ingen ISP, hvor man får en login prompt, hvis man
> ikke kommer fra de rigtigte IP adresser.


Ok, efter en søgning på 20 sek har jeg fundet en hos TDC 194.192.19.2,
baglænsopslag giver cpe.ser5-0-1.0xc2c01302.boanxd3.customer.tele.dk,
hvilket så vidt jeg kan genkende er en router hos en tilfældig TDC kunde.

I mange auditeringer jeg har fortaget har det været muligt at få et
login prompt på ISP'ens router, hvilket jeg også har kommenteret.

Et hint, prøv at tage fat i Internetforbindelser der blev oprettet for
fx 5 år siden eller senere.

> Men en ICMP svar pakke fra routeren, gør ingen skade, og kan ikke på
> nogen måde give en "angriber" information om det interne net.


Hvad hvis det er chargen istedet for ICMP og sourcen er det private nets
broadcast adresse?

Bryder du dig om at en tyv uden arme kan gå rundt i dit hus (ja det er
en meget dårlig sammenligning :)

>>Dette forhindre NAT/PAT ikke...dette forhindre ISP'en (hvis man stoler
>>på ISP'en) dit argment går primært på at ISP'en ikke tillader rfc1918
>>adresser.
> Det handler netop IKKE om at tillade rfc1918 adresser, det handler om
> ISP'en router pakker med en rfc1918 DESTINATION adresse til den kunde.


Har jeg adgang til routeren kan jeg sætte denne op til at understøtte
GRE eller IPSec, der findes artikler selv scriptkids kan finde ud af at
følge. Via GRE eller IPSec kan jeg transportere rfc1918, også selvom
ISP'en øvrige net ikke vil transportere rfc1918.

---

On Thu, 02 May 2002 22:49:24 +0200, Christian E. Lysel wrote:
>
>>>Sniffning af password kan alle ISP'ens kunder fortage, med det rette
>>>udstyr.
>>
>> Ikke passwords til ISP'ens udstyr.
>
> Hvorfor ikke?
>
> Jeg har en router stående hos mig der tilhørere min ISP, jeg smider en
> sniffer på WAN linien, når udbyderen logger på routeren kan jeg da se
> passwordet. Hvilken udbyder bruger kryptering på sin WAN forbindelse.

En udbyder bruger naturligvis ikke samme passwords på CPE placeret
udstyr, som på central placeret udstyr, da kunden har fysisk adgang til
de CPE placerede udstyr, og dermed har alle muligheder for at hacke det
hvis kunden har sådanne hensigter.

> Selvfølgelig er der muligheden for at kører SSH, og i dette tilfælde vil
> ovenstående ikke være muligt.
>
>>>Jeg snakker om ISP'ens router ikke om kundens router han selv køber.
>>
>> Du kan ikke logge ind i ISP'ens router, og du kan ikke sniffe dens
>> password ved at have en sniffer på WAN linien.
>
> Hvorfor kan jeg ikke sniffe på en WAN linie?

Det kan du sikkert, men du kan ikke få password'et til ISP'ens routere.

> Jeg har arbejdet med udstyr der er bygget til dette formål, nemlig at
> sniffe trafik (i forbindelse med fejlsøgning).
>
>> Ligeledes kender jeg ingen ISP, hvor man får en login prompt, hvis man
>> ikke kommer fra de rigtigte IP adresser.
>
> Ok, efter en søgning på 20 sek har jeg fundet en hos TDC 194.192.19.2,
> baglænsopslag giver cpe.ser5-0-1.0xc2c01302.boanxd3.customer.tele.dk,
> hvilket så vidt jeg kan genkende er en router hos en tilfældig TDC kunde.

Ja, men det er ikke ISP'ens udstyr, det er en tilfældig CPE router.

> I mange auditeringer jeg har fortaget har det været muligt at få et
> login prompt på ISP'ens router, hvilket jeg også har kommenteret.

Ingen TDC router.

> Et hint, prøv at tage fat i Internetforbindelser der blev oprettet for
> fx 5 år siden eller senere.

Jeg taler ikke om CPE placeret udstyr !

>> Men en ICMP svar pakke fra routeren, gør ingen skade, og kan ikke på
>> nogen måde give en "angriber" information om det interne net.
>
> Hvad hvis det er chargen istedet for ICMP og sourcen er det private nets
> broadcast adresse?

udp/tcp small servers er naturligvis disablet.

>>>Dette forhindre NAT/PAT ikke...dette forhindre ISP'en (hvis man stoler
>>>på ISP'en) dit argment går primært på at ISP'en ikke tillader rfc1918
>>>adresser.
>>
>> Det handler netop IKKE om at tillade rfc1918 adresser, det handler om
>> ISP'en router pakker med en rfc1918 DESTINATION adresse til den kunde.
>
> Har jeg adgang til routeren kan jeg sætte denne op til at understøtte
> GRE eller IPSec, der findes artikler selv scriptkids kan finde ud af at
> følge. Via GRE eller IPSec kan jeg transportere rfc1918, også selvom
> ISP'en øvrige net ikke vil transportere rfc1918.

Hvis du har adgang til CPE routeren, så er alt muligt.

--
Jesper Skriver, CCIE #5456
FreeBSD committer

---

Jesper Skriver wrote:

>>Jeg har en router stående hos mig der tilhørere min ISP, jeg smider en
>>sniffer på WAN linien, når udbyderen logger på routeren kan jeg da se
>>passwordet. Hvilken udbyder bruger kryptering på sin WAN forbindelse.
> En udbyder bruger naturligvis ikke samme passwords på CPE placeret
> udstyr, som på central placeret udstyr, da kunden har fysisk adgang til
> de CPE placerede udstyr, og dermed har alle muligheder for at hacke det
> hvis kunden har sådanne hensigter.


Jeg snakker kun om CPE, hvor password genbruges mellem kunders udstyr.
Dette behøver ikke at være tilfældet hos TDC, men det har været
tilfældet andre steder.

>>Hvorfor kan jeg ikke sniffe på en WAN linie?
> Det kan du sikkert, men du kan ikke få password'et til ISP'ens routere.


Jeg snakker stadigvæk kun om routeren kunden har lejet af ISP'en, jeg
snakker ikke om ISP'ens interne net.

>>hvilket så vidt jeg kan genkende er en router hos en tilfældig TDC kunde.
> Ja, men det er ikke ISP'ens udstyr, det er en tilfældig CPE router.


Er routeren ikke TDC's ejendom der er udlejet til en kunde?

>>I mange auditeringer jeg har fortaget har det været muligt at få et
>>login prompt på ISP'ens router, hvilket jeg også har kommenteret.
> Ingen TDC router.


Jeg har konkrette sager hvor dette har været tilfældet, og jeg snakker
stadigvæk om routeren der ejes af TDC men som er lejet til en kunde. Det
som du kalder en CPE placeret router.

>>Et hint, prøv at tage fat i Internetforbindelser der blev oprettet for
>>fx 5 år siden eller senere.
> Jeg taler ikke om CPE placeret udstyr !


Det er det jeg snakker om!

Mit argment går på hvis jeg kan tage en CPE router, kan jeg via denne
angribe en NAT routeren som kunden også har stående.

>>Hvad hvis det er chargen istedet for ICMP og sourcen er det private nets
>>broadcast adresse?
> udp/tcp small servers er naturligvis disablet.


Dvs. der fx i TDC's net, ikke er en router at finde med udp/tcp small
servers?


>>>>Dette forhindre NAT/PAT ikke...dette forhindre ISP'en (hvis man stoler
>>>>på ISP'en) dit argment går primært på at ISP'en ikke tillader rfc1918
>>>>adresser.
>>>>
>>>Det handler netop IKKE om at tillade rfc1918 adresser, det handler om
>>>ISP'en router pakker med en rfc1918 DESTINATION adresse til den kunde.
>>>
>>Har jeg adgang til routeren kan jeg sætte denne op til at understøtte
>>GRE eller IPSec, der findes artikler selv scriptkids kan finde ud af at
>>følge. Via GRE eller IPSec kan jeg transportere rfc1918, også selvom
>>ISP'en øvrige net ikke vil transportere rfc1918.
> Hvis du har adgang til CPE routeren, så er alt muligt.


Nej, hvis kunden selv har købt en firewall, har angriberen der sidder på
CPE routeren ikke adgang til det interne net.

Men hvis kunden har købt en NAT router (som skal forstille at være en
firewall), har angriberen faktisk fuld adgang til kundens lokalnet, hvis:

1. Han har adgang til CPE routeren.

2. NAT routeren ikke har fornuftige filtre implementeret.

---

On Fri, 03 May 2002 19:30:55 +0200, Christian E. Lysel wrote:
> Jesper Skriver wrote:
>
> Er routeren ikke TDC's ejendom der er udlejet til en kunde?

Aner det ikke, og jeg er ligeglad, det er en tilfældig CPE router, og
har intet med nettets integritet at gøre.

>>>I mange auditeringer jeg har fortaget har det været muligt at få et
>>>login prompt på ISP'ens router, hvilket jeg også har kommenteret.
>>
>> Ingen TDC router.
>
> Jeg har konkrette sager hvor dette har været tilfældet, og jeg snakker
> stadigvæk om routeren der ejes af TDC men som er lejet til en kunde. Det
> som du kalder en CPE placeret router.

Ja, for det er det !

>>>Et hint, prøv at tage fat i Internetforbindelser der blev oprettet for
>>>fx 5 år siden eller senere.
>>
>> Jeg taler ikke om CPE placeret udstyr !
>
> Det er det jeg snakker om!
>
> Mit argment går på hvis jeg kan tage en CPE router, kan jeg via denne
> angribe en NAT routeren som kunden også har stående.

Det er den samme router i 99.9% af tilfældene, du er en kværulant som
åbenlyst ikke har bedre ting at tage sig til.

EOD

--
Jesper Skriver, CCIE #5456
FreeBSD committer

---

Jesper Skriver wrote:
>>Er routeren ikke TDC's ejendom der er udlejet til en kunde?
>Aner det ikke, og jeg er ligeglad, det er en tilfældig CPE router, og
>har intet med nettets integritet at gøre.

Vi snakker forbi hinanden.

Jeg snakker om sikkerheden hos kunden, ikke om sikkerheden (eller mangle
på samme) hos ISP'en.

De routere jeg snakker om er dem der er placeret hos kunden. Omkring NAT
snakker jeg så endvidere om en router som kunden selv køber og sætte op
på ethernet segmenteret på ISP'ens router.

> Det er den samme router i 99.9% af tilfældene, du er en kværulant som


Dvs. den router som kunden køber og den router som ISP'en udlejer er den
samme?

> åbenlyst ikke har bedre ting at tage sig til.


Jeg bryder mig blot ikke om at man fortæller folk at NAT/PAT _alene_ har
noget med sikkerhed at gøre. Problemet er blot at du godt ved hvad jeg
mener.

Problemet med dig er at du arbejder hos en ISP, og derfor ikke kan indse
at en ISP også kan lave fejl. Jeg har set ISPer lave masser af fejl,
inkl. den du arbejder for, (fx enabling af TCP/UDP smallservers og brug
af svage passwords, eller ændring af konfiguration uden at ISP'en ved
hvem de snakker med). Den seneste episode oplevede jeg i starten af
denne uge hos Jer.

Det lader til, du er nået til et punkt hvor din holdning er, at du er
fejlfri. Det er trist.

Det er ganske normalt at lave fejl, jeg laver også fejl.


Disse fejl kan godt medfører at en NAT/PAT enhed uden filtre kan give
adgang til et "beskyttet" segment.

> EOD


Det styre du selv, det blot være kedeligt at slutte en diskution når den
ikke er færdig.


Og undskyld mit sprog.

---

Jesper Skriver wrote:

> Ligeledes kender jeg ingen ISP, hvor man får en login prompt, hvis man
> ikke kommer fra de rigtigte IP adresser.


Hvis vi kikke på nedestående som jeg regner med du kender:


http://freesbee.wheel.dk/~jesper/1400-proaccess.txt

access-list 10 permit 192.168.1.0 0.0.0.255

Hvis jeg kan smide pakker ind i ISP'ens netværk med destination i
adresserummet 192.168.1.0/24, vil jeg da opfylde access-list 10
kriteret. Godt nok kan jeg ikke få trafik retur, men hvis jeg kan gætte
sessionsnumre kan jeg i blinde tilgå routeren.

Hvis man skulle gører denne konfiguration mere sikker, ville jeg bla.
udvide access-list 121 med følgende:

access-list 121 deny ip 192.168.1.0 0.0.0.255 any



Dog ser det faktisk ud til at du undgår ovenstående situation vha.

access-list 121 deny ip host <Customer IP> any

---

On Fri, 03 May 2002 01:09:28 +0200, Christian E. Lysel wrote:
> Jesper Skriver wrote:
>
>> Ligeledes kender jeg ingen ISP, hvor man får en login prompt, hvis man
>> ikke kommer fra de rigtigte IP adresser.
>
>
> Hvis vi kikke på nedestående som jeg regner med du kender:
>
>
> http://freesbee.wheel.dk/~jesper/1400-proaccess.txt
>
> access-list 10 permit 192.168.1.0 0.0.0.255
>
> Hvis jeg kan smide pakker ind i ISP'ens netværk med destination i
> adresserummet 192.168.1.0/24, vil jeg da opfylde access-list 10
> kriteret.

Nej, lad være med at udtale dig om noget du ikke forstår !

1) Access liste angiver de SOURCE adresser som må connecte til
routeren
2) En IP pakke med en destination i 192.168.1.0/24 vil aldrig
nogen sinde blive routet til den 1400 hos en kunde.

--
Jesper Skriver, CCIE #5456
FreeBSD committer

---

Jesper Skriver wrote:

>>>Ligeledes kender jeg ingen ISP, hvor man får en login prompt, hvis man
>>>ikke kommer fra de rigtigte IP adresser.
>>Hvis vi kikke på nedestående som jeg regner med du kender:
>>http://freesbee.wheel.dk/~jesper/1400-proaccess.txt
>>
>>access-list 10 permit 192.168.1.0 0.0.0.255
>>
>>Hvis jeg kan smide pakker ind i ISP'ens netværk med destination i
>>adresserummet 192.168.1.0/24, vil jeg da opfylde access-list 10
>>kriteret.
> Nej, lad være med at udtale dig om noget du ikke forstår !


Rolig, jeg har vendt rundt på source og destination.

Dvs. source ligger i adresserummet 192.168.1.0/24.

Destination er selvfølgelig <Customer IP>.

Vil du stadigvæk mener man ikke kan få adgang til telnet på sådan en router?

> 1) Access liste angiver de SOURCE adresser som må connecte til
> routeren
> 2) En IP pakke med en destination i 192.168.1.0/24 vil aldrig
> nogen sinde blive routet til den 1400 hos en kunde.

---

On Fri, 03 May 2002 19:21:12 +0200, "Christian E. Lysel"
<chlyshoswmdatapunktumcom@example.net> wrote:

> Dvs. source ligger i adresserummet 192.168.1.0/24.
> Destination er selvfølgelig <Customer IP>.
>
> Vil du stadigvæk mener man ikke kan få adgang til telnet på sådan en router?

Hvis ISP'ens udstyr er fornuftigt konfigureret, får du ikke lov
til at sende en pakke med de adresser som source.

En fornuftig ISP har 'filtre' der sikrer at man ikke kan sende en
pakke, som ISP'en ikke har en returroute til. Desuden vil de ikke
tillade trafik fra kunde A til B, hvis ikke kunde A sender med
sin egen rigtige source.

-A
--
Heroes: Vint Cerf & Bob Kahn, Leonard Kleinrock, Robert Metcalfe, Jon Postel
Links : http://www.hojmark.org/networking/
FAQ : http://www.net-faq.dk/

---

Asbjorn Hojmark wrote:

> Hvis ISP'ens udstyr er fornuftigt konfigureret, får du ikke lov
> til at sende en pakke med de adresser som source.


Enig.


> En fornuftig ISP har 'filtre' der sikrer at man ikke kan sende en
> pakke, som ISP'en ikke har en returroute til. Desuden vil de ikke
> tillade trafik fra kunde A til B, hvis ikke kunde A sender med
> sin egen rigtige source.


Enig.

I virkeligheden er der dog ISP'er der ikke går op i source IP adresser.

Hvis man så har NAT router som ikke har filtre fordi nogle siger at NAT
er sikkert nok, kan man have et sikkerhedsproblem.

---

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

>Mit argument går på at man ikke kan klarer sig med NAT alene i en
>router, men også bør have nogle fornuftige filtre.

En normal billig NAT/PAT-ruter af den slags man plejer at bruge privat
eller i småfirmaer har jo den udmærkede egenskab at medmindre man
konfigurerer den til at gøre andet, så slipper den ingen pakker ind
udefra medmindre de ligner svarpakker for en forbindelse der tidligere
et etableret på initiativ indefra.

Og hvis det er implementeret ordentligt så gælder det ligegyldigt hvilke
IP-adresser der måtte stå som afsender og modtager (altså medmindre både
afsender, modtager, portnumre, og - for tcp's vedkommende - sekvensnumre
passer med en eksisterende forbindelse).

Og jeg vil påstå at det typisk er ganske svært at gætte hvordan man skal
lave en skurkagtig pakke så den ligner en der hører til en eksisterende
forbindelse og kan gøre skade.

Så der er et ganske effektivt filter som en naturlig del at
NAT/PAT-implementationen.

Med forbehold for at der naturligvis kan eksistere dårlige
implementationer og (måske endda standard)konfigurationer, forekommer
det mig at sådan én giver en fortræffelig beskyttelse. Naturligvis ikke
mod vira og trojanske heste man selv henter ind, men det er en anden
sag.
--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).

---

Jesper Dybdal wrote:

>>Mit argument går på at man ikke kan klarer sig med NAT alene i en
>>router, men også bør have nogle fornuftige filtre.
> En normal billig NAT/PAT-ruter af den slags man plejer at bruge privat
> eller i småfirmaer har jo den udmærkede egenskab at medmindre man
> konfigurerer den til at gøre andet, så slipper den ingen pakker ind
> udefra medmindre de ligner svarpakker for en forbindelse der tidligere
> et etableret på initiativ indefra.


Ja, og en normal NAT/PAT er default sat op med mere end blot NAT/PAT.
Den har typisk nogle fornuftige filtre installeret.


> Og hvis det er implementeret ordentligt så gælder det ligegyldigt hvilke
> IP-adresser der måtte stå som afsender og modtager (altså medmindre både
> afsender, modtager, portnumre, og - for tcp's vedkommende - sekvensnumre
> passer med en eksisterende forbindelse).


Ja.


> Og jeg vil påstå at det typisk er ganske svært at gætte hvordan man skal
> lave en skurkagtig pakke så den ligner en der hører til en eksisterende
> forbindelse og kan gøre skade.


Mange producenter laver fejl i deres produkter, men det er en anden
diskution.


> Så der er et ganske effektivt filter som en naturlig del at
> NAT/PAT-implementationen.


NAT/PAT har intet med filter at gøre, dette er to selvstændige ting.

At sige NAT giver sikkerhed er en fejl, hvilket mange producenter gør.


> Med forbehold for at der naturligvis kan eksistere dårlige
> implementationer og (måske endda standard)konfigurationer, forekommer
> det mig at sådan én giver en fortræffelig beskyttelse. Naturligvis ikke
> mod vira og trojanske heste man selv henter ind, men det er en anden
> sag.


Enig.

---

"Christian E. Lysel" <chlyshoswmdatapunktumcom@example.net> skrev i en
meddelelse news:3CD046DC.2000502@example.net...
> NAT giver ingen sikkerhed.
>
> NAT kombineret med fornuftige filtre, ja, men det er en helt anden
historie.

Hov det vil jeg egentlig gerne høre lidt mere om!

Den førnævnte Netgear router/switch beskrives af en forhandler bl.a.
således: "Der kan opsættes filtre så websider indeholdende specielle ord
bliver blokeret, disse filtre kan gøres afhængige af tidspunktet på dagen,
du kan læse mere om dette i manualen."

Er det sådan du mener eller er det andre filtertyper du mener?

Claus

---

> Den førnævnte Netgear router/switch beskrives af en forhandler bl.a.
> således: "Der kan opsættes filtre så websider indeholdende specielle ord
> bliver blokeret, disse filtre kan gøres afhængige af tidspunktet på dagen,
> du kan læse mere om dette i manualen."
>
> Er det sådan du mener eller er det andre filtertyper du mener?

Sandsynligvis ikke - det ovennævnte filter er jo på indersiden af routeren,
så man f.eks. kan undgå, at ens medarbejdere går ind på www.sex.com mellem
kl. 08:00 og 16:00.

Hilsen Peter

---

Claus Nygaard-Pedersen wrote:

> Hov det vil jeg egentlig gerne høre lidt mere om!
>
> Den førnævnte Netgear router/switch beskrives af en forhandler bl.a.
> således: "Der kan opsættes filtre så websider indeholdende specielle ord
> bliver blokeret, disse filtre kan gøres afhængige af tidspunktet på dagen,
> du kan læse mere om dette i manualen."


Det er filte på applikationslaget, jeg snakker om netværkslaget, dvs.
filtere hvilke ip adresser der må hvad.


Anyway, Netgear og andre routere har garanteret de filtre jeg snakker om,

ellers ville deres produkter have et ry for at være hullet som en si. Problemet

er blot at deres marketingsafdeling snakker om NAT når det i
virkeligheden er filtrene der yder beskyttelsen.

Jeg har selv rodet med ZyWall'en, og i standard konfigurationen kan jeg
udefra ikke finde sårbarheder (indenfra tog det 10 sek at finde den
første sårbarhed :)

Efter jeg slå den filtre fra, var den udefra hullet som en si.

---

> Det er filte på applikationslaget, jeg snakker om netværkslaget, dvs.
> filtere hvilke ip adresser der må hvad.
>
>
> Anyway, Netgear og andre routere har garanteret de filtre jeg snakker om,

Jeg har downloadet manualen til den router/switch jeg påtænker at købe og du
har ret, disse filtre kan sættes op.

Kan du henvise til et fornuftigt sted på nettet hvor jeg kan læse mere om
hvilke ting man bør overveje inden man sætter disse filtre op?

Claus

---

Claus Nygaard-Pedersen wrote:

> Kan du henvise til et fornuftigt sted på nettet hvor jeg kan læse mere om
> hvilke ting man bør overveje inden man sætter disse filtre op?


Default installationen bør have disse filtre.

Hvis jeg skal henvise til et sted på nettet omkring opsætningen af
filtre, vil jeg anbefalde at du sætter dig ind i hvad TCP/IP er.

Meget information kan du finde på sunsite.dk/rfc men det er meget tekniske.

Er der nogle der han en god side omkring tcp/ip?

---

> Default installationen bør have disse filtre.

Den har nogen men om det rækker?

> Hvis jeg skal henvise til et sted på nettet omkring opsætningen af
> filtre, vil jeg anbefalde at du sætter dig ind i hvad TCP/IP er.
>
> Meget information kan du finde på sunsite.dk/rfc men det er meget
tekniske.
>
> Er der nogle der han en god side omkring tcp/ip?


Hvad med:

http://www.techtutorials.com/tutorials/tcpguide.shtml


Claus

---

Claus Nygaard-Pedersen wrote:

>>Default installationen bør have disse filtre.
> Den har nogen men om det rækker?


Det vil jeg stærk antage

> Hvad med:
>
> http://www.techtutorials.com/tutorials/tcpguide.shtml


Jeg synes ikke den ser god ud, men det kan vel ikke skade at læse den.

Generelt omkring tcp/ip.

http://rfc.sunsite.dk/rfc/rfc791.html

http://rfc.sunsite.dk/rfc/rfc815.html

http://rfc.sunsite.dk/rfc/rfc1180.html

Omkring adresse rum, du skal være opmærksom på.

http://rfc.sunsite.dk/rfc/rfc1918.html

http://rfc.sunsite.dk/rfc/rfc2780.html

Omkring NAT

http://rfc.sunsite.dk/rfc/rfc2663.html

http://rfc.sunsite.dk/rfc/rfc3022.html

Mere læsning

http://rfc.sunsite.dk/rfc/rfc1463.html