Mulig å sperre for router?

[ChrisCo]

Ingen som har bedt han endre noen ting som helst... Og TTL settes alltid høyere enn 64 over TCP og 32 over UDP, så det kan ikke være TTL som gjør at det feiler... TTL er jo for at pakker ikke skal loope rundt i et nettverk - det er en levetid - hvor mange hopp (nettverk/lag 3/routere) pakkene skal kunne routes igjennom før dem droppes... I praksis så er nettet laget sånn at det skal mer enn 2-3 hopp før du kommer fram dit du skal.. Er jo en grunn til TTL settes såpass høyt uansett.... Bare fra meg til vg.no er det 8 hopp, ink min egen router...

 

Så se litt logisk på det og i perspektiv - det er neppe TTL sperre som kødder det til... Det er nødt til å være noe annet! For i såfall så måtte nettverket ha blokkert/droppet pakker med en verdi HØYERE enn de hoppene alle andre her mener det skal være fra stikket til TS, til gateway routeren på skolen.. Og INGEN pakker blir tagget med en TTL verdi lavere enn 32! Ergo da ville ALLE pakker ha blitt droppet av GW og ingen ville ha kommet seg ut på nettet...

 

Her et bilde av første pakke mot vg.no... TTL = 64

 

 

Svar fra vg.no . TTL = 245

 

Endret 2. september 2014 av ChrisCo

[Konto brukes ikke]

Skader ikke å teste.

[ChrisCo]

Hehe nei da for all del! But it ain't gonna work.... Det er jeg 99,9% sikker på!

 

Hvis jeg tar feil, så skal jeg være den første til å legge heeeelt flat og innrømme det uten å mukke...

[Chris93]

Teste, ja. Det kan jeg prøve å gjøre senere i dag. Snort skal kunne filtere pakker utifra minimumsverdi på TTL. Jeg får se hva som skjer dersom jeg setter den på 64 på utgående trafikk på LAN interfacet på routeren min.

[Heika98]

Trur jeg fant ut at windows har 128 TTL som deflaut. Var nå det det sto på PCen min.

[ChrisCo]

Ja da sier det seg selv at det ikke er TTL som stopper deg....

[Heika98]

Faen, rota litt nå. Var ikke TTL jeg såg på. Skal finne ut hva TTL'en egentlig er

[Heika98]

WTF??? Oppgitt TTL på PCen min er 0. Er det mulig da???

[ChrisCo]

Hæ? Hvor fant du det? Bilde?

[Chris93]

Snort skal kunne filtere pakker utifra minimumsverdi på TTL.

Øh, med alt satt opp og litt mer lesing i dokumentasjon så var det nok ikke helt den filtreringen jeg trodde det var.

[Heika98]

Hæ? Hvor fant du det? Bilde?

 

 

Verdien for TTL vises etter answares (rød boks).

[ChrisCo]

Det der har ingenting med TTL å gjøre! Og det hjelper ikke å sjekke seg selv.. Prøvde det samme, og fikk identisk resultat.. Prøv mot vg.no f.eks....

[Heika98]

Det der har ingenting med TTL å gjøre! Og det hjelper ikke å sjekke seg selv.. Prøvde det samme, og fikk identisk resultat.. Prøv mot vg.no f.eks....

 

Ok, sikkert dumt spørsmål, men hvordan? Vet bare om hvordan man sjekker i cmd.

[ChrisCo]

Hør her.. TTL er en verdi som settes i et eget felt i en ethernet ramme.. Den blir redusert med 1 for hvert hopp (nettverk/router) som den passerer/routes igjennom/videre fra.. Den har 1 oppgave - å forhindre loops i et nettverk... Når/hvis verdien når 0, så vil pakken(e) droppes av den routeren som mottar pakkene, helt uavhengig av alt annet... 0 = død!

 

TTL er heller ingen verdi du setter manuelt.. Det tagges automatisk... Hvis du skal sjekke TTL til og fra, så last ned Wireshark, kjør sniffing og browse til en tilfeldig side - vg.no f.eks som jeg har brukt her...

Så dobbelklikker du på første TCP pakke (linje) i Wireshark etter du har gått til vg.no og så ser du på IPv4 feltet hva TTL verdien er.. Se på bildene mine lengre opp i tråden...

[sjurtf]

Hør her.. TTL er en verdi som settes i et eget felt i en ethernet ramme.. Den blir redusert med 1 for hvert hopp (nettverk/router) som den passerer/routes igjennom/videre fra.. Den har 1 oppgave - å forhindre loops i et nettverk... Når/hvis verdien når 0, så vil pakken(e) droppes av den routeren som mottar pakkene, helt uavhengig av alt annet... 0 = død!

 

TTL er heller ingen verdi du setter manuelt.. Det tagges automatisk... Hvis du skal sjekke TTL til og fra, så last ned Wireshark, kjør sniffing og browse til en tilfeldig side - vg.no f.eks som jeg har brukt her...

Så dobbelklikker du på første TCP pakke (linje) i Wireshark etter du har gått til vg.no og så ser du på IPv4 feltet hva TTL verdien er.. Se på bildene mine lengre opp i tråden...

 

For å starte som deg ChrisCo - Hør her...

 

TTL hører til på Lag 3 i IPv4 Headeren. IPv6 har noe tilsvarende, men der heter det Hop Limit.

 

Som du sier er at pakker ikke skal gå i en løkke evig tanken bak dette feltet. Det kan dog brukes til masse, blant annet sperre for Lag 3 enheter på et nettverk - slik som denne tråden omhandler.

 

Man kan også fint ved hjelp av verktøyene ping og traceroute regne seg frem til hva inital TTL på systemet sitt er satt til.

Feks:

ping til vg.no svarer med ttl=246.

traceroute viser 9 hop.

9 + 246 = 255.

 

På mitt system tagges ta IP headeren med 255 - dette er meg bekjent vanlig på linux og mac os x.

[ChrisCo]

Ja? Ingenting i det du skriver som er uklart eller feil... Så hva var poenget ditt???????

 

Det jeg sier, er at det garantert ikke er TTL blokk som er problemet til TS, heller brukerfeil...

[sjurtf]

Ja? Ingenting i det du skriver som er uklart eller feil... Så hva var poenget ditt???????

 

Det jeg sier, er at det garantert ikke er TTL blokk som er problemet til TS, heller brukerfeil...

Leste du ikke hva jeg siterte deg på, og svarte tilbake?

 

1. Det du skriver - med at TTL hører til på lag 2 i en ethernet ramme er feil.

 

2. Det kan gått være, og er meget sannsynelig at det ligger ACL som inspiserer TTL feltet i pakken på ISP sin GW som er problemet til TS. Dette er en helt vanlig implementasjon for å forhindre for at klienter på et nett setter opp egene rutere.

Endret 3. september 2014 av sjurtf

[ChrisCo]

1. Jo, og ser feilen nå... Mente pakke, ikke ramme.... My bad!

 

2. Kan du da forklare den dypere? Har ikke vært borti en sånn type sperre før og klarer heller ikke se hvordan det skal kunne fungere i praksis, annet enn internt på et LAN... Skal man ut på nettet, så er det ganske kurrant at pakkene har såpass høy levetid at de kan nå målet sitt... Har selv vært borti router som er på +- 30 hopp... Da er det greit at TTL er høyere enn antall hopp.....

[sjurtf]

2. Kan du da forklare den dypere? Har ikke vært borti en sånn type sperre før og klarer heller ikke se hvordan det skal kunne fungere i praksis, annet enn internt på et LAN... Skal man ut på nettet, så er det ganske kurrant at pakkene har såpass høy levetid at de kan nå målet sitt... Har selv vært borti router som er på +- 30 hopp... Da er det greit at TTL er høyere enn antall hopp.....

Har forsøkt å forklare deg dette tidligere i tråden:

 

Følg dette eksempelet basert på min maskin på ett tilfeldig nettverk, uten at jeg har ruter lokalt hos meg.

 

Den første ruteren jeg kommer til da - min GW (ISP sitt første L3 interface) forventer da at alle mine pakker inneholder verdien 255 i TTL feltet.

Har den 254 betyr det at jeg har hatt en egen ruter på lokalnettet mitt -> ISP dropper da alle pakkene på GW ruteren.

 

På denne ruteren har den en liste med tilatte TTL verdier, gitt fra hva som er de ulike OS standardene.

Har pakkene denne veriden, så blir de kastet.

[Konto brukes ikke]

På mitt system tagges ta IP headeren med 255 - dette er meg bekjent vanlig på linux og mac os x.

 

Likt med hva som jeg har i windows 7 det.

Men ... jeg skjønner fortsatt ikke hvordan man da kan komme forbi via å endre på TTL på pc/enhet - dette må da i så fall endres i router, for man får vel ikke TTL høyere enn 255?

Går dette an i en 'vanlig' router da? (å åpne pakkene og sette ny TTL)