Gå til innhold
Trenger du hjelp med internett og nettverk? Still spørsmål her ×

Branmuren fra NGT tilstrekkelig?


Anbefalte innlegg

Ikke glem at det her er snakk om noder som står på samme subnett som eksternt interface til ruteren. Dette skrev jeg i den første posten.

 

Jeg må si jeg er nokså skeptisk jeg også. Kan du forklare i detalj hvordan du har tenkt å bygge opp pakken for at den skal bli sendt fra en "nabomaskin" til meg? Husk at pakken vil gå innom en annen ruter før den kommer til meg.

 

Som andre har nevnt tror jeg også det vil regnes som en bug om pakker blir rutet fra WAN til LAN utfra IP når man bruker NAT.

Endret av tvangsgreie
Lenke til kommentar
Videoannonse
Annonse

Ok, jeg har måttet slåss for å få gjennom dette faktumet i andre fora også.

 

Sentralt er at man betrakter NAT og Ruting som to separable fenomener. En Ruter har som primær oppgave å sende pakker i henhold til sin rutetabell med sine interfaces. NAT'ing er en ekstra ting man kan gjøre for å skrive om avsenderadresse.

 

Ruting har ingenting med pakkefiltrering å gjøre. Det er en annen oppgave som man normalt bruker firewall's til (mye engelsk på norsk, men greiest slik)

 

Alt dette er selvsagt uavhengig av om man definerer visse nett som lokale, ikke-rutbare. (dvs 10, 172.16 og 192.168)

 

Gitt et ISP nett, 80.202.0.0/16

 

Der sitter 80.202.ond.cracker med et par hendige verktøy for å lage pakker.

 

Der sitter også 80.202.min.ruter som er en ruter med 2 interfaces.

eth0 er på 80.202.0.0/16 og eth1 er på 10.0.0.0/8

 

Uavhengig av NAT, så har denne ruteren en rute til de to nettene. Hvis man bruker en linux software ruter så vil rutene lages automatisk f.eks.

 

Hvis en intern maskin, 10.0.0.2 sender en pakke med destinasjon 123.123.123.123 til det interne interfacet på min ruter, så vil ruteren sjekke sine egne ruter og deretter sende den videre til sin default gateway siden den ikke har rute til den ip'en. Enkelt og greit så langt.

 

Hvis 10.0.0.2 sender en pakke til 80.202.a.b, altså til en maskin som står på samme nett som det eksterne interfacet til min ruter, så vil ruteren se at den har en rute til dette nettet og sende den direkte til mottageren.

 

Ruteren sender her videre pakker selvom de ikke er adressert direkte til ruteren. Hvilket er det man bruker rutere til.

 

Se nå på et eksempel uten NAT. Den har fortsatt samme rutedefinisjon, men snu på situasjonen. 80.202.ond.cracker bruker min ruter som gateway til 10.0.0.0/8 nettet. Han sender en pakke med destinasjon 10.0.0.2 til 80.202.min.ruter

 

Pakken kommer selvfølgelig fram fordi den sendes direkte. ruten til 10.0.0.0/8 er en rute som alle andre ruter, ruteren sjekker sin rutetabell, og sender pakken til 10.0.0.2

 

Hvis du nå legger på NAT, det vil si omskrivning av avsender adresse, så betyr det at pakker som sendes innenfra får manipulert avsenderadressen. Men pakkene som kommer utenfra slipper fortsatt inn som de er. Ruteren driver ikke pakkefiltrering, det skal firewallen gjøre.

 

Konseptet er enkelt å forstå. Det er bare å se for seg ruteren med sine rutetabeller og hvilken vei en pakke tar. Og ikke henge seg opp i NAT og lokale nett som noe mere mystisk enn det det er. En enkel regel for å endre avsender adresser og et ipnett som alle andre nett. Bare at rutere ute på internett ikke har ruter til dem.

 

Risken er selvsagt begrenset til ISP nett, men om en orm utnytter dette, ser jeg ikke noen grunn til å stole blindt på at naboen min holder pc'ene sine rene. Det er bare sunn paranoia!

 

Så ja, nei ville ikke deaktivert firewallen. Alle rc.firewall skript jeg har sett har med en linje som dropper inkommende pakker adressert til lokale nett.

 

EDIT: *discalimer* jeg har ikke prøvd dette selv, og kjenner ærlig talt ikke vanlig praksis i hardwarerutere, men prinsippet burde gjelde. Så korriger meg gjerne hvis jeg er ute i det blå.

 

80.202.ond.cracker vil selvsagt få pakker i retur med avsenderadresse 80.202.min.ruter istedet for 10.0.0.2 som avsender adresse, men det er en smal sak å skrive om så det blir rett hvis man først har kommet så langt.

Endret av Torbjørn
Lenke til kommentar

OK... skjønner hva du mener! Teskjemodus hjalp ;)

 

Det BURDE kanskje kunne funke ja... hadde vært interessant å prøvd!

 

Som du skriver så er jo NAT og stateful inspection to helt forskjellige ting. Men har ikke de fleste SOHO-routere en form for stateful inspection innebygget?? De sperrer jo default for alle porter fra utsiden, men åpner (selvfølgelig) for returtrafikk, dette må vel da antakelig gjøres ut fra avsender/mottaker/SYN/ACK/sekvensnummer = stateful...

 

Edit: Det det hele muligens koker ned til er at ren routing + NAT ikke gir noen fullgod beskyttelse pga. muligheten for å forwarde spoofede pakker fra utsiden til innsiden av routeren. MEN pga. innebyggede filteringsmekanismer i de fleste DSL routere så er de allikevel godt nok sikret?

 

Interessant diskusjon!

 

timtowtdi

Endret av timtowtdi
Lenke til kommentar

Den innebyggede funksjonen for det vet jeg ikke i hvilken grad eksisterer, men viktig å være klar over muligheten og bakgrunnsprinsippet som gjelder.

 

Diskusjonen vil om ikke annet klargjøre bedre konseptet "ruter", ie en node som fordeler pakker utfra sin rutetabell, og at NAT ikke er mer mystisk enn adresseomskrivning og at lokale ikke-rutede nett er en "menneskelig" konstruksjon.

Lenke til kommentar

Hei dere! Så dere holder det fortsatt gående!? :D

Jeg må inrymme at selv mistet jeg tråden for lengts.

Dersom ikke noen av de "paranoide" kan forklare for meg hvordan jeg får konfiguerert min ruter slik at den ikke blokerer for ned- og opplastninger gjennom eMule så får de "uansvarlige" et stikk der.

Jeg har som sagt NGT og en Netopia ruter.

Lenke til kommentar

1. Sjekk i eMule preferences, hvilke porter som må slippes inn (4602 eller noe sånt og en til)

2. Sørg for at disse slippes inn gjennom filteren (hvis du ikke har endret noe, slippes alle pakker over 1023 inn)

3. Konfigurer din PC med fast IP - sjekk i ipconfig hvilken adresse den har fått tildelt fra DHCP, så kan du legge denne adressen inn i nettverksoppsettet. For eksempel 10.0.0.2

4. Nå må du opprette 2 servere i NAT servers. Begge skal ha samme adresse (10.0.0.2), men forskjellige porter (de du fant i punkt 1). External port skal være likt Internal port.

 

Du kan bruke enten telnet eller NGTs konfigureringsverktøy for dette.

Lenke til kommentar
Dette hysteriet med at folk blir hacket er jo bare tull.

 

Hvis man har en router med NAT og et oppdatert antivirusprogram holder det lenge, og det skader heller ikke å bruke huet  :p

Det er ikke bare tull. Problemet er at det er så mange som ikke skjønner data og heller ikke vet å beskytte seg mot problemer. De er jo levende målskiver for virus, trojanere, ormer osv. Ikke rart det flommer over av slike når det flommer like mye over av uvettige PC-brukere.

Nei det er nok ikke bare tull. Mange vil bli mer og mer forsiktig jo mer oppegående de blir. :p Jeg har gradvis blitt paranoid i årenes løp og ser helt klart store fordeler med at enkelt brukere er interessert i sikkerhet. Store virus angrep, DDOS angrep osv skyldes etter min mening i stor grad uforsiktige brukere som ikke tenker seg om. Folk som sitter med åpne porter, uten AV med blankt passord på admin kontoen og sier at det aldri kan skje noe med dem..

 

Jeg har blitt hacket (av vennligsinnede) tidligere og fått beviser sendt til meg nettopp for å vise at jeg var helt åpen.

 

Jeg kjører automatisk oppdatering av AV daglig, har software firewall (Kerio), kryptert MSN osv, osv. Mulig jeg overdriver men jeg vet at jeg likevel ikke er sikret mot innbrudd, men litt sikrere er jeg jo.. :p

Lenke til kommentar
Ok, jeg har måttet slåss for å få gjennom dette faktumet i andre fora også.

 

Sentralt er at man betrakter NAT og Ruting som to separable fenomener. En Ruter har som primær oppgave å sende pakker i henhold til sin rutetabell med sine interfaces. NAT'ing er en ekstra ting man kan gjøre for å skrive om avsenderadresse.

 

Ruting har ingenting med pakkefiltrering å gjøre. Det er en annen oppgave som man normalt bruker firewall's til (mye engelsk på norsk, men greiest slik)

 

Alt dette er selvsagt uavhengig av om man definerer visse nett som lokale, ikke-rutbare. (dvs 10, 172.16 og 192.168)

 

Gitt et ISP nett, 80.202.0.0/16

 

Der sitter 80.202.ond.cracker med et par hendige verktøy for å lage pakker.

 

Der sitter også 80.202.min.ruter som er en ruter med 2 interfaces.

eth0 er på 80.202.0.0/16 og eth1 er på 10.0.0.0/8

 

Uavhengig av NAT, så har denne ruteren en rute til de to nettene. Hvis man bruker en linux software ruter så vil rutene lages automatisk f.eks.

 

Hvis en intern maskin, 10.0.0.2 sender en pakke med destinasjon 123.123.123.123 til det interne interfacet på min ruter, så vil ruteren sjekke sine egne ruter og deretter sende den videre til sin default gateway siden den ikke har rute til den ip'en. Enkelt og greit så langt.

 

EDIT: *discalimer* jeg har ikke prøvd dette selv, og kjenner ærlig talt ikke vanlig praksis i hardwarerutere, men prinsippet burde gjelde. Så korriger meg gjerne hvis jeg er ute i det blå.

 

Snippet litt.

 

Jeg postet meldingen din på no.alt.sikkerhet

 

Etter mye om og men blir dog konklusjonen som følger: (siteter noen av innleggene)

 

 

>En router JA, men ikke så lenge det er snakk om NAT på routeren, da må man

>jo åpne for porter og henvise til hvor de skal hen, hvis ikke så hadde jo

>hele NAT bare vært tull. Grunnen til at man bruker NAT er jo at man internt

>kan bruke interne adresser som f.eks 192.168.1.1 ell. og at man utenifr har

>en gyldig adresse. Hvis man skal ha mulighet til å nå alle interne maskiner

>uansett port så må man ha like mange gyldige eksterne adresser og sette opp

>dette på routeren slik at routeren vet hvilken gyldig adresse som tilhører

>hvilken intern adresse, men hvis man skal gjøre slikt så kan man jo like

>godt bruke gyldige adresser internt siden man først har dem og ikke sette

>opp NAT på routeren.

 

******************

 

 

>

> > Men når den bruker NAT så fungerer den ikke lenger som en router på den

> > måten du tror den gjør. Den NATer inn på TCP/UDP og man kan også bruke

> > spesielle tjenester for å muligjøre FTP, DNS osv. Den router ikke som du

> > tror den gjør.

> >

> > Det er for å gi det inn med teskje til de som ikke skjønner det og så håper

> > jeg også at noen sender det videre til hardware.no som svar til han som

> > leter etter vann på Mars.

 

******************

 

 

>

> Som fyren stadig prøver å påpeke i innlegget over så dreier IKKE dette seg

> om NAT, men

> om routing. Det er to forskjellige ting og det er bare snakk om pakker,

> IKKE hvilke porter de skal inn

> på. Porter er et begrep som ligger i TCP og det eksisterer ikke i IP (hvor

> routingen foregår).

>

 

Men hvis man har NAT og denne ikke er satt opp for å slippe igjennom noen

trafikk så vil ikke route tabellen bli brukt. Hvis man setter opp den

routeren på det nettet man vil inn på og setter opp denne som gateway så er

det kun routeren som svarer på alle forespørsler og det slippes ikke inn

noen ting hvis det ikke er satt opp noe i NAT. Hvis den kun hadde stått som

en router uten NAT så ville dette ha fungert, men så lenge det er NAT så vil

det ikke fungere på annet enn det som det er åpnet for.

 

 

********************

 

Så mao, NAT i seg selv er ikke mere enn security through obscurity, fordi man må vite eller gjette seg fram til ip-nettene bak den. men hvis man først treffer, så er det bare å kjøre i vei.

 

Så jo, NAT er bedre enn security by obscurity, sansynligvis derfor en NAT'ende router også kalles "meduim strenght firewall" :)

Endret av znapper
Lenke til kommentar

Bra at du fortsetter debatten, jeg skal ikke si noe mer før jeg prøver dette selv.

 

tvangsgreie:

ideen var å stå på 80.202-nettet og sende en pakke til 10.0.0.0 nettet via din ruter, utenfra og inn, akkurat som du kan stå på 10.0.0.0 nettet og sende en pakke til 80.202-nettet innenfra og ut. NAT mente jeg var en ting som skjer uavhengig av de faktiske rutene som er definert i ruteren.

Lenke til kommentar

Etter å ha prøv dette hjemme, så må jeg konkludere med at det fungerer smertefritt.

 

Jeg satte opp 3 maskiner for å teste det som har blitt diskutert, og ikke bare fungerte det slik forventet, det gikk i tillegg enklere enn jeg hadde trodd idet svar på ping utad (pong) ikke fikk omskrevet avsenderadressen.

 

Jeg brukte 4 maskiner i dette eksperimentet (de 4 maskinene jeg har hjemme). Det er ingen ekstern kobling til internett til det fysiske nettet som ble brukt.

 

Maskinen som er simulert utenfor:

"CRACKER", Redhat 9
- IP 80.202.22.22/16 på eth0
- Default gateway 80.202.11.11

Maskinen som kjører NAT:

"NAT", Redhat 9
- IP 80.202.11.11/16 på eth0
- IP 10.0.1.1/24 på br0 (eg. eth1)
- iptables for NAT'ing

Maskiner på lokalt nett:

"LOCAL", Fedora Core 1
- IP 10.0.1.3 på eth0
- Default gateway 10.0.1.1

"WINDOWS", Windows XP Pro
- IP 10.0.1.24/24
- Default gateway 10.0.1.1

 

Navnene er gjenspeilet så godt som mulig på de vinduene som er brukt i screenshots.

 

Det sysiske nettet og ip definisjonene er det samme for alle forsøk. CRACKER er koblet opp mot NAT på eth0. LOCAL og WINDOWS er plugget i en switch som er koblet til eth1 på NAT, mao ser nettet slik ut:

 

http://www.nt.ntnu.no/~lindahl/nat%20study/network.png

 

Forsøk 1 - Uten NAT

 

http://www.nt.ntnu.no/~lindahl/nat%20study/no_nat.jpg

 

Det ble først forsøkt uten NAT, det viste seg da at NAT slapp gjennom ping fra maskin CRACKER til maskin LOCAL uten problemer, og sendte dem riktig i retur igjen. Helt som forventet.

 

Til høyre sees NAT maskinenen, den har rutene satt opp riktig. Det skal bemerkes at br0 her er et container interface som bridge'r eth1 og eth3. Det er eth1 som er koblet til switchen.

 

Den har også alle "chains" på "ACCEPT" i iptables og ikke NAT satt opp.

 

CRACKER, nede til venstre, har også sine ruter satt opp korrekt, og sender ping til 10.0.1.3, slik det er vist. Det sees her at ping ser ut til å nå fram via default gateway.

 

Øverst til venstre sees LOCAL maskinen som blir pinget. På denne kjøres det et program "iptraf", som viser all trafikk som går gjennom maskinens nettkort. Programmet viser to ting, TCP øverst og alt annet nederst. Ping som er ICMP vises derfor i den nederste halvdelen og man ser der ping pakkene som kommer igjennom og blir returnert. (TCP trafikken over ikke relatert til forsøker men stammer fra en intern FTP-sessjon som var i full gang samtidig.)

 

Forsøk 2 - Med NAT

 

http://www.nt.ntnu.no/~lindahl/nat%20study/with_nat.jpg

 

På dette bildet sees stort sett det samme, men her vises også "iptraf" vinduet på NAT maskinen.

 

Øverst til høyre ser man at iptables er satt opp til å NAT'e utgående pakker på eth0, slik man ønsker på et typisk NAT-oppsett av denne typen.

Nederst til venstre sees på nytt ping fra CRACKER til IP 10.0.1.3.

 

Disse går gjennom akkurat like enkelt som før, og de vises i "iptraf" til den lokale maskinen, akkurat som før, øverst til venstre.

 

Man ser også på NAT-maskinen at pakkene går rett gjennom. Verd å merke seg her, er at de ikke engang omskrives til avsender adresse 80.202.11.11 før de sendes i retur, hvilket gjør at de kommer fram som de skal uten at CRACKER trenger å gjøre en avsenderadresseomskrivning i PREROUTING (iptables chain)

 

EDIT: Grunner til at ping her bare ses på eth0 og ikke på eth1, er at jeg i iptraf valgte å kun vise eth0 pga forstyrrende smb trafikk som spyttet ut udp linjer med jevne mellomrom og forkludret bildet av icmp pakkene.

 

Forsøk 3 - med NAT, ping innenfra og ut

 

http://www.nt.ntnu.no/~lindahl/nat%20study/nat_detail.jpg

 

Til slutt ble det gjort et forsøk for å vise at NAT med oppsettet over, fungerte som tenkt. WINDOWS sender ping til CRACKER via NAT. Uten firewall noen steder bør det fungere helt greit, og det gjør det også.

 

Øverst til høyre vises WINDOWS klienten som sender ping til ip'en til CRACKER.

 

Nederst til høyre vises NAT som transporterer ping fra WINDOWS til CRACKER. Her ser man NAT i arbeid.

ICMP echo req kommer fra 10.0.1.24 til 80.202.22.22 gjennom eth1. Videre sendes ICMP req fra 80.202.11.11 til 80.202.22.22 gjennom eth0, mao er avsender omgjort idet ping'et vandrer gjennom NAT.

 

Det samme skjer når ICMP echo rply kommer tilbake fra 80.202.22.22 til 80.202.11.11, det sendes videre til 10.0.1.24 med avsender 80.202.22.22, som om NAT-maskinen var usynlig.

 

Så NAT'inga fungerer som den skal med oppsettet som er brukt.

 

MAO, for linux routere bør man absolutt ha med en regel i firewall som dropper inkommende pakker til lokale nett via eksternt interface.

Endret av Torbjørn
Lenke til kommentar

Jeg synes du burde poste denne i en tråd på no.alt.sikkerhet for det er en intressant observasjon.

 

Såvidt meg bekjent, og som de også sa i diskusjonen på no.alt.sikkerhet, er alle routere satt opp til å droppe pakker de ikke skal natte når de kjører NAT.

 

Men jeg anbefaler likevel å poste der, de gutta har mer peilig enn meg i allefall :cool:

Endret av znapper
Lenke til kommentar
Jeg synes du burde poste denne i en tråd på no.alt.sikkerhet for det er en intressant observasjon.

 

Såvidt meg bekjent, og som de også sa i diskusjonen på no.alt.sikkerhet, er alle routere satt opp til å droppe pakker de ikke skal natte når de kjører NAT.

 

Men jeg anbefaler likevel å poste der, de gutta har mer peilig enn meg i allefall :cool:

Eventuellt i en ny tråd kanskje, vet ikke hvor oppegående news servere er med gamle tråder for tiden (folk mister vel lett tråden?)

 

Du kan jo evt lage en posting med eksemplet, samt legge frem for diskusjon om hvorvidt routere rundt omkring faktisk har sikkerhet som forhindrer denne typen "manipulasjon". ?

Lenke til kommentar

hm.. det ser ut som om innlegget mitt der ble glemt ja, skal poste en ny en tror jeg.

 

litt kjedelig at det er vanskelig å prøve "in real life" med NGT sin løsning, da man ikke har så mye kontroll over rutern til NGT og man ikke kommer på nett uten å investere i et ADSL modem.

Lenke til kommentar

Var en lang krangel om dette under samme topic en stund til bake, hvor jeg og en del andre kranglet så busta føyk over det..jeg mener som jeg mente da at viruskiller er pinlig unødvendig for megselv, jeg har ikke virus og nettvettet mitt har ført til at jeg ikke er i risikosona..

 

Dessuten bruker Norton og en del andre programmer mye tid på å sjekke hver eneste fil som kjøres..det blir mye tid tapt pga en trussel som ikke eksisterer.

 

Firewall er dog en helt annen sak, nå viser det seg at Telenor hos meg blokkerer og har sannsyneligvis spart meg for mye problemer, med balster etc som jeg til tross for STOR spredning har ALDRI hatt.

 

Så...

er du usikker..viruskiller...er du mer dreven, er fortsatt firewall en god sikkerhet...

 

Janster

Lenke til kommentar

en høyst reell trussel - og en aldri så liten administrativ hodepine - er likevel personer som kommer på besøk med bærbar. Kanskje skal du vise fram hjemmenettet til onkel hans som har med seg bærbar, kanskje kommer "fjortiss-som-går-på-LAN"-lillebror på besøk med sin shuttle.

 

Alternativt kan man dele inn hjemmenettet i en sikker sone med en firewall foran. Det kan ofte være slitsomt å ikke ha direkte kontakt med de andre på hjemmenettet (ved spilling eks.) men man kan løse dette med en linux bridge f.eks men da begynner man å nørme seg et nivå hvor en klientfirewall eller antivirus program hadde vært like greit.

Lenke til kommentar
personer som kommer på besøk med bærbar

Mitt forslag:

Jeg kunne tenke å gi mine hjemme-PCer statiske IPer fra (for eksempel) 10.0.0.0/24, mens DHCP serveren konfigureres slik at alle nykommere får 10.0.1.0/24. Og så kan jeg sette opp en del filtrering eller kanskje ikke noe aksess mellom disse to nettene, siden gjestene må gjennom routeren for å nå mine PCer. Hvis de kommer med statisk IP, funker ikke dette, men da er sjansene store at IP-oppsettet må rekonfigureres uansett for å få nettverkstilgang.

Lenke til kommentar

joda, det er en fin løsning, men du vil miste mulighet for å game med spill som bruker lokale nett og broadcast.

 

en mulig løsning er å sette opp en software bridge, og dermed slippe å ha separate nett, og heller filtrere med ebtables, men det krever kernel kompilering og er ikke helt trivielt lengre.

Lenke til kommentar
Hei dere! Så dere holder det fortsatt gående!? :D

Jeg må inrymme at selv mistet jeg tråden for lengts.

Dersom ikke noen av de "paranoide" kan forklare for meg hvordan jeg får konfiguerert min ruter slik at den ikke blokerer for ned- og opplastninger gjennom eMule så får de "uansvarlige" et stikk der.

Jeg har som sagt NGT og en Netopia ruter.

denne tråden ble lang og lese igjennom jeg har selv ngt og bruker ngt sin router med mitt eget filteroppsett og jeg har ikke hatt noe problemer så langt,alle mine interne maskiner har antivirus innstallert og jeg har ikke hatt noe virus,trojan eller worm som jeg har funnet jeg er selv litt paranoid så jeg har sjekket med diverse software for og sjekke om jeg har fått noe infisert.prøvde også linkene som ble skrevet tidligere i forumet http://scan.sygate.com/probe.html og denne https://grc.com/x/ne.dll?bh0bkyd2 og fikk ikke noe uventet raport fra dem.jeg har en server som står med ftp og web de portene var sef oppe men alt annet var lukket og låst som forventet. skal man lære mer og diskutere mer om ngt sin router kan jeg absolutt annbefale http://www.relativt.net/ her kan man diskutere alt som har med ngt sin router og gjøre og få masse ideer og få mye lærdom fra andre.

eMule bruker forøvrig disse portene hvis jeg ikke tar feil.TCP: 4661-4662 UDP: 4665

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...