Beantwoord

Graag weer een volledige MTR / Traceroute / Sniffing / DPI



Toon eerste reactie

110 reacties

Reputatie 3

bump

Gezien aldus de klantenservice het antwoord hier vandaan moet komen.

Kom maar op met dat goede antwoord.

Reputatie 3

@Brian of @Jason 

Dit topic trek ik toch maar weer even omhoog gezien er nog geen reactie is van jullie zijde. Punt blijft dat het vreselijk onhandig is om geen fatsoenlijke traceroute uit te kunnen voeren. Traceroute is na een simpele echo request een van de basis tools waar eenieder naartoe grijpt om een netwerk probleem op te lossen. Neem hier dus ook in mee dat jullie het ook andere bedrijven lastiger maken om support te kunnen geven. Zo had ik zelf laatst een collega die problemen had met ons vpn, vpn problemen van T-Mobile daargelaten, aan wie ik een traceroute vroeg waar ik niks mee kon. Bel de overbelaste klantenservice maar was m’n reactie. 

In bovenstaand geval lostte het probleem zich automagisch op. Waarschijnlijk omdat het vpn probleem toen wel redelijk bekend was. Punt blijft dat er niks zichtbaar is.

Maar… Wat ik nog veel erger vind. T-Mobile rommelt bewust met de packets van haar klanten. Dat een router de ttl verlaagt met 1 dat is niet rommelen, zo werkt een traceroute. De ttl naar een vaste waarde zetten is een heel ander issue. Ik kan niets anders dan concluderen dat traceroutes bewust gefrustreerd worden. Dit laatste ook niet vanuit security, daarover is hierboven al genoeg gezegd. Mijn gevoel is dat we dtag weer gaan doen en T-Mobile daar niet open over wil zijn.

Dus in het kader van TLDR (gebeurt wel vaker bij brian en jason) Gewoon geen antwoord op de vragen geven of e.a half lezen.

Afijn, @Brian en @Jason ….

Twee simpele vragen.

  1. Hoe  leggen jullie uit dat de ttl  een packet aangepast wordt, naast wat een router default doet? Leg ook uit waarom je, onterecht, de packets van de klant modificeert.
  2. Hoe verklaren jullie dingen als ‘dit is industry standard’ in deze context en dat dit overal gebeurt. Hier ben ik wel benieuwd naar. Ik zie namelijk niemand dit doen.

is al een iets ouder topic, maar aangezien ik er naar verwezen ben door een t-mobile medewerker en ik nu idd issues heb met de verbinding..

Dat verhaal dat opgehangen wordt over het verbergen van routers is naar mijn mening gewoon onzin. De argumenten die aangevoerd worden voor ‘beveiliging’ klopt geen barst van want het verbergt alleen de traceroutes vanuit de router thuis. Als je vanuit een datacenter vanaf een unix server dat richting dat modem doet zijn er zat truukjes om er achter te komen hoe eea in elkaar zit.

Dus dat lijkt zoals eerder opgemerkt inderdaad meer op security door obscurity maar dat het werkelijk iets beveiligd: niet echt.

Dat men aanhaalt dat het niet weergeven van die hops een industrie standaard is, is gewoon ronduit flauwekul. Geen enkele fatsoenlijke netwerk beheerder zal dat op deze manier doen omdat dan het achterhalen van de oorzaak en/of locatie van een probleem vrijwel onmogelijk wordt. Het heeft er dan alle schijn van dat men door die actie zichzelf de vrijheid schept om ongezien allerlei rare zaken (zoals routeren via goedkopere verbindingen of zoals voorheen via DTAG) uit te halen zonder dat de klant dit door zal hebben of kan zien.

Eea lijkt op de uitgebreide obfuscatie waar de regering ook niet vies van is tegenwoordig: lekker je gang gaan, vooral niets vastleggen of mededelen, volhouden dat er niets vreemds is gebeurd tot het keiharde tegendeel wordt bewezen, wat dan flink wordt tegengewerkt door (in dit geval) ondermeer die traceroutes niet meer mogelijk te maken. Ondertussen wordt dan bij elke storing een slappe smoes gegeven van: de lijn is ok, dus het ligt aan jou router of thuis netwerk, wat in dit geval absolute onzin is, tot die conclusie kwam de door t-mobile gestuurde monteur ook..

 

@Gerrit078

Hier het topic over de toemalige DTAG probleem, waarbij de routing een dusdanige latency opleverde dat bijna elke klant van TMT er last van had (dus die 99%) .. zelfs ik.

Dit was toen een heel ander probleem, maar ook gewoon merkbaar door het hele netwerk van TMT.

 

Waar het mij om ging was dat hoe jij netneutraliteit omschreef onjuist was en ook het verkeer via DTAG - wat inderdaad zwaar vertragend functioneerde - gewoon onder netneutraliteit viel. Netneutraliteit houdt n.l. ook in dat providers verplicht zijn om zo goed mogelijk de internet snelheden te communiceren die men (mogelijk) zou moeten kunnen behalen. Net zoals men moet informeren wanneer men als provider besluit bepaalde wijzigingen aan te brengen die nadelig kunnen uitpakken voor de consument.

Niet alleen werd de wijziging van DTAG niet aan de consument medegedeeld, ook werden snelheden veelal niet behaald welke in de praktijk gewoon haalbaar hadden moeten zijn.

 

 

BTW, alles wat ik schrijf of schreef is niet persoonlijk bedoeld, mocht het wel zo aanvoelen .. mijn excuus daarvoor.

Zo zie/ervaar ik het ook niet, ook mijn reacties zijn vanzelfsprekend niet persoonlijk (als persoonlijke aanval bedoeld).

 

Overigens wel opvallend, we zijn inmiddels bijna twee weken verder en een officiële statement is vanuit T-Mobile uitgebleven, evenals verdere reacties. Mogelijk gevalletje doofpot dus ?

 

Reputatie 7
Badge +3

@Gerrit078 

Hier het topic over de toemalige DTAG probleem, waarbij de routing een dusdanige latency opleverde dat bijna elke klant van TMT er last van had (dus die 99%) .. zelfs ik.

Dit was toen een heel ander probleem, maar ook gewoon merkbaar door het hele netwerk van TMT.

Godzijdank is er wet en regelgeving en is het aan toezichthouders om te bepalen of en zo ja, iets wel of niet toegestaan is.

Daarom, in afwachting van een uitspraak vanuit de toezichthouder.

BTW, alles wat ik schrijf of schreef is niet persoonlijk bedoeld, mocht het wel zo aanvoelen .. mijn excuus daarvoor.

@Gerrit078

Als reden zou je kunnen zien, je hebt een perfect werkend internet .. en daar stopt meestal alle onderzoek van de ACM.

 

In principe behoort de ACM gewoon te handhaven op alle vlakken waarvoor ze als toezichthouder zijn aangesteld. Dat houdt dus niet in, als internet werkt dan stopt onderzoek. Want dan zou men ook geen onderzoek hoeven doen als Spotify, Netflix of welke andere streamingdienst etc. dan ook, gewoon functioneren.

 

 

 

Denk dat 99% van alle klanten van TMT dit topic al snel overslaan, zeker als ze geen issues ondervinden met het opbouwen van hun verbindingen.

 

Het gaat ook niet om 99% van de klanten, de ACM hanteert een aantal klachten per geval. Wat het aantal klachten moet zijn in dit geval ? Joost zal het weten.

 

Ik weet dat je als netwerkbeheerder (prive of beroepsmatig) een punt hebt, maar alles werkt gewoon.

 

Zoals jij het interpreteert zou het inhouden dat er niet hoeft te worden onderzocht en opgetreden wanneer de snelheid van Netflix door een internetprovider zou worden beperkt tot maar een Mbit want .. hé, het werkt. Zo werkt netneutraliteit dus niet.

 

Iemand gooide al het woord ‘Netneutraliteit’ in het topic, maar dit heeft vooral betrekking op het beperken van toegang tot bepaalde websites … maar die zijn gewoon bereikbaar, ook al zien wij de route er naar toe niet.

 

En daar ga jij nu net de mist in, bij netneutraliteit kan en mag dus per definitie al geen onderscheid worden gemaakt zoals jij dit nu dus wel doet over komen. De verordening die de EU heeft opgesteld wordt zelfs nergens gesproken over een expliciete dienst, protocol etc. in tegendeel alle  verkeer moet bij wet en verordening als gelijkwaardig te worden behandeld een mooie quote van artikel 3 in de verordening - waaraan Nederland en dus Nederlandse providers zich dienen te houden;

 

Aanbieders van internettoegangsdiensten behandelen bij het aanbieden van internettoegangsdiensten alle verkeer op gelijke wijze, zonder discriminatie, beperking of interferentie, en ongeacht de verzender en de ontvanger, de inhoud waartoe toegang wordt verleend of die wordt verspreid, de gebruikte of aangeboden toepassingen of diensten, of de gebruikte eindapparatuur.

De eerste alinea belet aanbieders van internettoegangsdiensten niet redelijke verkeersbeheersmaatregelen te treffen. Om als redelijk te worden beschouwd, moeten die maatregelen transparant, niet-discriminerend en evenredig zijn, en mogen zij niet berusten op commerciële overwegingen, maar op objectief verschillende technische kwaliteitsvereisten van specifieke categorieën verkeer berusten. Zulke maatregelen mogen niet inhouden de specifieke inhoud gevolgd, en zij worden niet langer dan nodig aangehouden.

Aanbieders van internettoegangsdiensten treffen geen verkeersbeheersmaatregelen die verder gaan dan de in de tweede alinea bedoelde maatregelen, en gaan met name niet over tot het blokkeren, vertragen, wijzigen, beperken of degraderen van, interfereren met of discrimineren tussen specifieke inhoud, toepassingen of diensten, of specifieke categorieën daarvan, behalve indien - en slechts zolang - dit nodig is om:

a) te voldoen aan de wetgevingshandelingen van de Unie of de nationale wetgeving die in overeenstemming is met het Unierecht, waar de aanbieder van de internettoegangsdiensten onder valt, of aan de met het Unierecht in overeenstemming zijnde maatregelen ter uitvoering van dergelijke wetgevingshandelingen van de Unie of dergelijke nationale wetgeving, met inbegrip van beslissingen van rechters of overheidsinstanties die terzake bevoegd zijn;

b) de integriteit en de veiligheid van het netwerk, van de diensten die via dit netwerk worden aangeboden en van de eindapparatuur van de eindgebruikers te beschermen;

c) nakende netwerkcongestie te voorkomen en de effecten van uitzonderlijke of tijdelijke netwerkcongestie te beperken, op voorwaarde dat gelijkwaardige soorten verkeer gelijk worden behandeld;

 

 

 

Dit kan een topic worden tussen 3 of 4 netwerkbeheerders (prive of beroepsmatig), maar elk ander die er naar kijkt zal zeggen .. “mijn gevraagde webpagina krijg ik gewoon, wat is het probleem?”

 

Je hoeft geen netwerkbeheerder te zijn om even een ping of tracert uit te voeren, in tegendeel zelfs. Mijn zoon (14) gebruikt tracert zo nu en dan eens als er een gameserver niet bereikbaar is of als hij niet in de learningportal kan komen van de onderwijsinstelling waar hij naar school gaat. Het ene moment bleek het een storing bij de cloud-provider waar die onderwijsinstelling is aangesloten maar met enige regelmaat bleek het ook nog wel eens elders te liggen.

Zie…. waarom moet iemand meteen netwerkbeheerder zijn als je een simpele ping of traceroute wilt doen?

Overigens best grappig hoe je dit nu stelt… want…. groot deel van de klanten had gewoon internet toen verkeer over DTAG verliep. Dus wat was nu het probleem? Of zoals eerder gezegd, als Netflix in snelheid wordt beperkt moet jij niet klagen als je niet in 4K kunt kijken door die beperking want het werkt gewoon.

Godzijdank is er wet en regelgeving en is het aan toezichthouders om te bepalen of en zo ja, iets wel of niet toegestaan is.

 

Dus of we binnenkort bij Radar o.i.d. een 30 minuten topic zullen zien over dat we de route niet kunnen volgen??? .. ik heb grote twijfels. Radar’s vraag zal ook zijn .. “Werkt het niet of werkt het slecht om een internetsite waar ook ter wereld te bereiken?”

Goed mijn 2 cent voor nu even .. geef iedereen weinig tot geen hoop in deze, want alles werkt.

Radar komt over het algemeen pas in beeld wanneer consumenten alle mogelijke wegen bewandeld heeft en werkelijk nergens meer aan de bel kan trekken. Eerste stap is over het algemeen;

  • Provider
  • Geschillencommissie en/of toezichthouder(s)

 

Reputatie 7
Badge +14

Ik voorzie ook geen handhaving door de ACM. Als een consument meer wenst dan een standaard internet aansluiting is het enige wat je kan bereiken dat je zonder afkoopsom binnen je contact termijn mag opzeggen. Dat je een route niet ziet is geen item voor handhaving door ACM. Er is geen wet overtreden

Reputatie 7
Badge +3

@Gerrit078

Wil mij eigenlijk zover mogelijk weg houden van deze discussie, maar er is denk ik meer nodig dan een handvol netwerkbeheerder (prive of beroepsmatig) om de ACM in beweging te krijgen.

Als reden zou je kunnen zien, je hebt een perfect werkend internet .. en daar stopt meestal alle onderzoek van de ACM.

Dat je als netwerkbeheerder (prive of beroepsmatig) op een ‘huis tuin en keuken’ aansluiting graag een ‘deep dive’ neemt in de route (ook al zijn er geen connectie issues), dat is aan jou.

Denk dat 99% van alle klanten van TMT dit topic al snel overslaan, zeker als ze geen issues ondervinden met het opbouwen van hun verbindingen.

Ik weet dat je als netwerkbeheerder (prive of beroepsmatig) een punt hebt, maar alles werkt gewoon.

Iemand gooide al het woord ‘Netneutraliteit’ in het topic, maar dit heeft vooral betrekking op het beperken van toegang tot bepaalde websites … maar die zijn gewoon bereikbaar, ook al zien wij de route er naar toe niet.

Dit kan een topic worden tussen 3 of 4 netwerkbeheerders (prive of beroepsmatig), maar elk ander die er naar kijkt zal zeggen .. “mijn gevraagde webpagina krijg ik gewoon, wat is het probleem?”

Dus of we binnenkort bij Radar o.i.d. een 30 minuten topic zullen zien over dat we de route niet kunnen volgen??? .. ik heb grote twijfels. Radar’s vraag zal ook zijn .. “Werkt het niet of werkt het slecht om een internetsite waar ook ter wereld te bereiken?”

Goed mijn 2 cent voor nu even .. geef iedereen weinig tot geen hoop in deze, want alles werkt.

de gelijke akamai-nog-wat

@Gerrit078

Zou het helpen om bij ACM te melden dat Tmobile onze internet aansluiting verne…. of in ieder geval een gemankeerde aansluiting levert. 

Voor zover ik begrepen heb van ACM/Consuwijzer valt het verbergen dat men nu doet onder overschrijding van het verbod. Let wel, dit was gewoon een 1.2.3. antwoord, om werkelijk die conclusie te trekken zijn voldoende klachten benodigd.

Overigens had T-Mobile haar klanten wel officieel in moeten lichten over deze verandering al is het in het kader van het beveiligen van haar eigen infrastructuur. Let wel, dit beveiligen gaat over de eigen infrastructuur van het internet, niet wat zich daarbuiten (derde partijen) bevind. Zonder verder onderzoek mag dus eigenlijk best worden geconcludeerd op basis van die informatie, dat het verbergen van hops buiten de eigen infrastructuur van T-Mobile per definitie dus niet eens toegestaan is.

Daar bovenop wordt niet alleen per klacht gekeken maar ook naar het geheel, als providers - zoals T-Mobile - lekker blijven aanmodderen en het aantal klachten, problemen, onduidelijkheden toeneemt wordt op den duur gewoonweg gekeken of de wetgever moet worden ingelicht over eventuele wijzigingen, verduidelijking etc. in de wetgeving of niet.

Dat durf ik bijna niet te doen, ik ben al beschuldigd van conspiracy denken door @Brian.

Die uitspraak kun je ook andersom zien. T-Mobile die de weg kwijt is en nu onder het mom van beveiliging allerlei zaken gaat uitvreten over de rug van klanten. Terwijl het zoals meerderen al zeggen eigenlijk gewoon security by obsecurity is.

Bij een zo korte trace naar de NSA (National Security Agency) was dat delen van gegevens met het CBS (Centraal Buro Statistiek) maar een druppel lijkt het wel :kissing_smiling_eyes:

Ik kan ook niet wachten tot de nodige sancties worden uitgedeeld, dat aanmodderen komt steeds meer mensen de spuigaten uitlopen.

 

Qua melding aan de ACM, “Baat het niet, dan schaad het niet". Melding doen kost hooguit een paar minuten en voor het zelfde geldt wordt er wel tegen opgetreden. Als de mensen met snelheidsissues dit ook meteen doen wordt er alleen maar meer dossier opgebouwd.

 

Reputatie 7
Badge +5

Nou ja, maar even op een andere pc ingelogd met een andere glas provider en dezelfde tracert gedaan naar nsa.gov

  1    <1 ms    <1 ms    <1 ms  pfsense [192.168.192.2]
  2    <1 ms    <1 ms    <1 ms  powered-by.xenosite.net [217.1x8.1x5.xx]
  3     6 ms     8 ms     8 ms  100.64.0.1
  4     6 ms     5 ms     6 ms  89.184.160.162
  5     5 ms     5 ms     5 ms  89.184.160.161
  6     6 ms     6 ms     6 ms  62.115.174.228
  7    25 ms    24 ms    24 ms  adm-bb3-link.ip.twelve99.net [62.115.136.194]
  8    25 ms    24 ms    25 ms  ffm-bb1-link.ip.twelve99.net [62.115.120.241]
  9    23 ms    23 ms    23 ms  win-bb3-link.ip.twelve99.net [62.115.137.203]
 10    24 ms    23 ms    23 ms  win-b2-link.ip.twelve99.net [62.115.114.185]
 11    24 ms    29 ms    23 ms  akamai-ic317493-win-b2.ip.twelve99-cust.net [62.115.147.101]
 12    23 ms    23 ms    22 ms  a104-103-108-118.deploy.static.akamaitechnologies.com [104.103.108.118]

trace complete

Oeps toch, daar moeten wat meer sprongetjes gemaakt worden en eindigt het zelfs niet op hetzelfde IP adres. Wel de gelijke akamai-nog-wat

@Gerrit078 

Zou het helpen om bij ACM te melden dat Tmobile onze internet aansluiting verne…. of in ieder geval een gemankeerde aansluiting levert. Dat durf ik bijna niet te doen, ik ben al beschuldigd van conspiracy denken door @Brian.
Bij een zo korte trace naar de NSA (National Security Agency) was dat delen van gegevens met het CBS (Centraal Buro Statistiek) maar een druppel lijkt het wel :kissing_smiling_eyes:

Vandaag een tracert naar nsa.gov

4 hops in totaal.

1.   vertrek uit mijn eigen netwerk
2    <1 ms    <1 ms    <1 ms  192.168.178.1
3     2 ms     3 ms     2 ms  1-32-144-85.ftth.glasoperator.nl [85.144.32.1]
4     8 ms     8 ms     8 ms  a72-246-175-75.deploy.static.akamaitechnologies.com [72.246.175.75]

Trace complete.

Er staat hier een 30 cm globe langs mijn scherm en zelfs daarop is het vanuit de speldeprik die nederland is een behoorlijk lange kabel om direct ergens in de USA uit te komen.

Nee Tmobile doet niet aan traffic shaping, althans dat kunnen ze zich niet herinneren. Waar heb ik dat afgelopen week meer gehoord?  

 

Ach, T-Mobile Nederland zal vast trots zijn dat het de enige provider wereldwijd is die directe verbinding heeft met alles en iedereen :joy:  Beetje misleidend is het natuurlijk wel.

Ondanks dat het niet echt ongelofelijk zin heeft, is het wellicht wel raadzaam dat iedereen dit zo goed en uitgebreid mogelijk kenbaar maakt aan de ACM. Al is het maar om op termijn een onderzoek los gepeuterd te krijgen. Gezien het verleden en heden van T-Mobile kan het tenslotte nog wel eens goed zijn dat ook omtrent dit soort zaken gewoon keiharde regels opgesteld gaan worden!

8ms is toch heel netjes voor een ping naar de USA?

Het is alleen niet naar de USA, Akamaitechnologies is een CDN/Cloud provider. Een cloud provider is nou niet echt een goed voorbeeld om te nemen. Neem dan bijvoorbeeld Colocrossing, alwaar T-Mobile doet laten over komen dat ze met hen een directe verbinding hebben (zie hun Traceroute) maar dit voor zover mij bekend totaal niet het geval is.

Ergens zou je dit dus eigenlijk best onder een stukje misleiding mogen gooien. Hopen dat potentiële klanten bij een T-Mobile Thuis klant zien hoe direct de verbinding is naar diverse targets, en ze vervolgens blij maken met een dooie mus.

Reputatie 7
Badge +14

8ms is toch heel netjes voor een ping naar de USA?

Reputatie 7
Badge +5

Vandaag een tracert naar nsa.gov

4 hops in totaal.

1.   vertrek uit mijn eigen netwerk
2    <1 ms    <1 ms    <1 ms  192.168.178.1
3     2 ms     3 ms     2 ms  1-32-144-85.ftth.glasoperator.nl [85.144.32.1]
4     8 ms     8 ms     8 ms  a72-246-175-75.deploy.static.akamaitechnologies.com [72.246.175.75]

Trace complete.

Er staat hier een 30 cm globe langs mijn scherm en zelfs daarop is het vanuit de speldeprik die nederland is een behoorlijk lange kabel om direct ergens in de USA uit te komen.

Nee Tmobile doet niet aan traffic shaping, althans dat kunnen ze zich niet herinneren. Waar heb ik dat afgelopen week meer gehoord?  

Dit klinkt meer naar security by obsecurity.

laten we dan ook iedereen maar niet een extern ip geven. dat is veiliger…..

Precies wat ik al aangaf, met hoe T-Mobile zich meer en meer gedraagt zal het niet meer de vraag worden of maar wanneer T-Mobile overgaat tot NAT'ted verbindingen. Blijkbaar zijn ze tot alles toe in staat!

zorg eerst er maar eens voor dat je zelf de zaken op orde heb!

Het nadeel is, dat T-Mobile meer en meer bewijst dat het geen zaken op orde heeft en niet in staat is deze ook werkelijk in orde te hebben. Ze willen een grote speler in de markt worden maar door eigen achterlijke fouten en gebrek aan communicatie maken ze zichzelf steeds minder geliefd.

 

ik heb hier dan ook geen goed woord voor over…. zou wel eens willen spreken met die gene die dit heeft bedacht. (die zou het eens van uit een andere hoek moeten bekijken)

Kijkende naar hoe er gedacht en gehandeld wordt krijg ik sterk de indruk dat we het hebben over wat lui die ooit het woord “beveiliging” hebben horen vallen … je weet wel, wel de klok horen luiden maar niet weten waar de klepel hangt.

Weet je wat echt niet industry-standard is? Je niet houden aan je eigen gedragscode voor transparantie:

https://www.t-mobile.nl/Consumer/media/pdf/klantenservice/netwerk-en-bereik/gedragscode-transparantie-internetsnelheden.pdf

En het ergste is nog, dit is dan een gedragscode welke onderling is afgesproken voor zover ik mij kan herinneren en waar je eigenlijk in principe weinig waarde aan kunt hechten. Het is tenslotte niet zo dat er consequenties tegenover zullen staan wanneer je (zoals T-Mobile) te beroerd bent om consumenten te informeren. Wettelijk is het echter wel in de wet ‘netneutraliteit’ vastgesteld dat je bij dergelijke beslissingen verplicht bent de consument te informeren. Lees; 

Een open internet is belangrijk zodat alle consumenten vrij toegang hebben tot dezelfde informatie. Ook is het goed voor de ontwikkeling van nieuwe internetdiensten, zoals ‘video on demand’.

 

En ook dat vertikt T-Mobile !

In principe kan en mag je ICMP - het verrichten van traceroutes - als “informatie” beschouwen. Het geeft je inzicht en informatie hoe een route enigszins verloopt en kan zelfs informatie prijs geven wanneer zich ergens in die routering één of meerdere problemen voordoen.

 

 

Reputatie 2

@Brian, industry-standard? welke Nederlandse providers verbergen nog meer de route die data aflegt voor klanten die vreemde afwijkingen constateren in de prestaties van hun intrernetverbinding?  

 

Weet je wat echt niet industry-standard is? Je niet houden aan je eigen gedragscode voor transparantie:

 

https://www.t-mobile.nl/Consumer/media/pdf/klantenservice/netwerk-en-bereik/gedragscode-transparantie-internetsnelheden.pdf

 

 

Reputatie 7
Badge +4

Dit klinkt meer naar security by obsecurity.

laten we dan ook iedereen maar niet een extern ip geven. dat is veiliger…..

Debuggen is gewoon totaal niet meer mogelijk op deze manier. en om nou te zeggen dat T-Mobile hier goed in is kan ik ook niet echt zeggen. zorg eerst er maar eens voor dat je zelf de zaken op orde heb!

ik heb hier dan ook geen goed woord voor over…. zou wel eens willen spreken met die gene die dit heeft bedacht. (die zou het eens van uit een andere hoek moeten bekijken)

@Brian Aanvullend op wat @Thomas_R hierboven al zegt, en ik in mijn uiteenzetting hierboven:

Zoals Thomas stelt is de huidige manier een fix met schijnveiligheid. Met een IP Record Route ping kun je dit al omzeilen, met dus ook een aantal hops intern uit het T-Mobile netwerk.

Volgens mij is die niet helemaal compleet, tenminste … laatste keer dat ik een volledige traceroute had, zaten er heel wat meer IP-Adressen (hops) tussen. Volgens mij ontbreken er dus nog best een aantal. 

Maar goed, is het niet gewoon een kwestie voor kwaadwillende om een kijkje te nemen naar een lijst en daar gewoon te sniffen of gewoon direct ip-addressen binnen de subnet's eindigend op .1 en .254 een flinke DDos voor de kiezen te gooien?

 

Reputatie 3

@Brian Aanvullend op wat @Thomas_R hierboven al zegt, en ik in mijn uiteenzetting hierboven:

Zoals Thomas stelt is de huidige manier een fix met schijnveiligheid. Met een IP Record Route ping kun je dit al omzeilen, met dus ook een aantal hops intern uit het T-Mobile netwerk.

jk-5@pc-jeffrey:~$ ping -R antennekaart.nl
PING antennekaart.nl (178.251.25.37) 56(124) bytes of data.
64 bytes from antennekaart.nl (178.251.25.37): icmp_seq=1 ttl=60 time=25.4 ms
RR: pc-jeffrey.vl220.7815xg-32.as64516.net (172.24.136.16)
69-101-145-85.ftth.glasoperator.nl (85.145.101.69)
10.10.10.254 (10.10.10.254)
t-mobilethuis.interxionams5.nl-ix.net (193.239.117.50)
178.251.25.2 (178.251.25.2)
antennekaart.nl (178.251.25.37)
antennekaart.nl (178.251.25.37)
interracks.previder-pdc2.nl-ix.net (193.239.116.140)
10.10.12.53 (10.10.12.53)

Omdat het 10.x.x.x adressen zijn zijn ze niet benaderbaar vanaf het internet, en vormt het in dit geval niet echt een beveiligingsrisico. Maar omdat hier wordt afgeweken van de “industry standard” manier om hops te verbergen in een traceroute, namelijk het filteren van ICMP, wordt hier iets over het hoofd gezien waardoor het gestelde doel niet wordt bereikt.

Dit is vanuit mij een extra argument om het anders op te lossen. De huidige manier werkt niet betrouwbaar en is irritant voor de klanten die dit inzicht willen hebben. In mijn ogen is het beter om deze TTL filtering op te heffen en het op de normale manier te doen, door te voorkomen dat het corenetwerk ICMP verstuurt naar klanten en naar het internet.

Hi all, excuses dat het even heeft geduurd maar we willen zorgen dat we duidelijk uit kunnen leggen hoe de vork in de steel zit. Een uitgebreidere uitleg volgt, maar de korte samenvatting is dat het zichtbaar zijn van de tussenliggende hops en de core routers een veiligheidsrisico met zich meebrengt. Het is ook niet 'industry standard’ dat deze netwerk informatie zichtbaar is. Als onderdeel van een aantal verbeteringen aan ons netwerk, waaronder een verbetering van de veiligheid bij bijvoorbeeld bij DDoS aanvallen, is de informatie die zichtbaar is bij een trace aangepast en is alleen het eindpunt nog zichtbaar. Ik kan mij voorstellen dat dit mogelijk wat vragen oproept en een uitgebreidere technische uitleg volgt!

Bedankt voor het doorsturen van de uitleg van je netwerk collega’s.

Het filteren van ICMP pakketten in netwerkverkeer om zo IP adressen van jullie routers te verbergen is schijnveiligheid (“security by obscurity”). Het zal het aanvallers misschien iets lastiger maken maar er zijn voldoende andere manieren voor aanvallers om deze IP adressen van jullie routers alsnog te achterhalen zoals kijken naar de edge routers, rDNS records, oude traceroutes van jullie klanten die overal op het internet rondzwerven, (poort)scans op jullie IP reeksen, etc.

Hoe verkeer binnen jullie netwerk wordt gerouteerd maakt mij niet zoveel uit, dus prima om ICMP uit te zetten op jullie eigen routers. Het zou wel netjes zijn om ICMP verkeer dat buiten jullie netwerk komt niet actief te filteren. Dat maakt netwerkproblemen troubleshooten een stuk makkelijker.

@Brian Ofwel je bent voor de 2e keer met een mooi verhaal terug gestuurd.

 

Zoals hier boven al gezegd prima als t-mobile niet wil laten zien hoe hun eigen netwerk eruit ziet.

Maar het verbergen / niet inzichtelijk maken van netwerken van andere partijen ….

Maar goed om te weten dat t-mobile zich aan de 'industry standard’ houd en de rest van de wereld niet. 

 

 

Ik dacht zelf altijd dat wanneer bij IETF een standaard vermeld werd, dit gewoon een industry standaard betreft. En daar staat voor ICMP wel enkele zaken beschreven/omschreven. Maar goed, ik begrijp dat dit dan nog niet per definitie een industry standaard betreft. Grappig want als je zoekt op internet industry standard dan is er ook niet echt op het eerste oog een standaard te vinden. Heeft T-Mobile dan niet nu plotsklaps gewoon een industry standard bedacht? :joy:

 

Zoals hier boven al gezegd prima als t-mobile niet wil laten zien hoe hun eigen netwerk eruit ziet.

Maar het verbergen / niet inzichtelijk maken van netwerken van andere partijen ….

Juist en vooral dat maakt het een zaak die stinkt. Dat je, binnen je eigen infrastructuur zaken verbergt c.q. niet wilt delen/prijsgeven snap ik dan nog wel… maar het “hele” internet is naast dat het op zwaar achterbakse wijze heeft plaatsgevonden, gewoonweg onnodig en zelfs eigenlijk gewoon onacceptabel.

 

​​​​​​Maar goed om te weten dat t-mobile zich aan de 'industry standard’ houd en de rest van de wereld niet. 

Voor een klein overzichtje van netwerken dat zich dan niet aan de 'industry standard’  houd.….

En langzaam aan leren we de ware T-Mobile NL aard kennen.

 

 

@Gerrit078 kan je delen hoever jij komt met dit verhaal. Gezien jij contact het via de mail. (een van de andere wegen die t-mobile zelf aanbied om in contact te komen..)

Volgens https://www.t-mobile.nl/klantenservice#contact heb je 3 opties tot contact. Lijkt me handig dat ze dan deze opties ook allemaal juist ondersteunen.….

 

Ik ben verder nog niet benaderd aangezien het wat tijd in beslag kon nemen. Achteraf gezien snap ik ook waarom het tijd in beslag kan nemen, van interne communicatie of een systeem waarin dergelijke wijzigingen worden bijgehouden, is dus eigenlijk gewoon geen sprake. Als het nou bij interne communicatie zou blijven zou ik het nog niet eens zo heel erg vinden, maar het feit dat bepaalde besluiten zijn genomen zonder dat de consument daarvan is geïnformeerd geeft toch wel een hele vieze nasmaak.

Dat verklaart dan ook wel waarom de persoon die ik laatst sprak redelijk gedeprimeerd over kwam… 

 

Reputatie 3

Hi all, excuses dat het even heeft geduurd maar we willen zorgen dat we duidelijk uit kunnen leggen hoe de vork in de steel zit. Een uitgebreidere uitleg volgt, maar de korte samenvatting is dat het zichtbaar zijn van de tussenliggende hops en de core routers een veiligheidsrisico met zich meebrengt. Het is ook niet 'industry standard’ dat deze netwerk informatie zichtbaar is. Als onderdeel van een aantal verbeteringen aan ons netwerk, waaronder een verbetering van de veiligheid bij bijvoorbeeld bij DDoS aanvallen, is de informatie die zichtbaar is bij een trace aangepast en is alleen het eindpunt nog zichtbaar. Ik kan mij voorstellen dat dit mogelijk wat vragen oproept en een uitgebreidere technische uitleg volgt!

@Brian Ofwel je bent voor de 2e keer met een mooi verhaal terug gestuurd.

 

Zoals hier boven al gezegd prima als t-mobile niet wil laten zien hoe hun eigen netwerk eruit ziet.

Maar het verbergen / niet inzichtelijk maken van netwerken van andere partijen ….

Maar goed om te weten dat t-mobile zich aan de 'industry standard’ houd en de rest van de wereld niet. 

Voor een klein overzichtje van netwerken dat zich dan niet aan de 'industry standard’  houd.

kpn

ziggo

ntt

lumen / level3 

upc

bit

unet

eurofiber

comcast

surfnet

amazon

microsoft

google

bt

RIPE NCC 

DigitalOcean

Magyar Telekom Nyrt (mm grappig heeft hetzelfde logo.)

@Gerrit078 kan je delen hoever jij komt met dit verhaal. Gezien jij contact het via de mail. (een van de andere wegen die t-mobile zelf aanbied om in contact te komen..)

Volgens https://www.t-mobile.nl/klantenservice#contact heb je 3 opties tot contact. Lijkt me handig dat ze dan deze opties ook allemaal juist ondersteunen.

 

….

Hi all, excuses dat het even heeft geduurd maar we willen zorgen dat we duidelijk uit kunnen leggen hoe de vork in de steel zit. Een uitgebreidere uitleg volgt, maar de korte samenvatting is dat het zichtbaar zijn van de tussenliggende hops en de core routers een veiligheidsrisico met zich meebrengt. Het is ook niet 'industry standard’ dat deze netwerk informatie zichtbaar is.

 

Gatverdamme, dit klinkt een beetje dezelfde smoes die providers ook veelal gebruiken wanneer ze hun jaarlijkse tarieven verhogen. Alles onder het mom van verbeteringen en beveiligen, hoewel er op T-Mobile na wereldwijd hooguit een handje vol providers zijn die dit soort (eigenlijk, schijnheilige) praktijken uithalen.

Dit alleen al zet mij eigenlijk aan het denken over hoe ver T-Mobile nog kan of juist zal gaan om onder het mom van “beveiligen” zaken door te voeren. Volgende stap wellicht iedereen achter een NAT’ted verbinding of zelfs surfen via een proxy server van T-Mobile?

. Als onderdeel van een aantal verbeteringen aan ons netwerk, waaronder een verbetering van de veiligheid bij bijvoorbeeld bij DDoS aanvallen, is de informatie die zichtbaar is bij een trace aangepast en is alleen het eindpunt nog zichtbaar. Ik kan mij voorstellen dat dit mogelijk wat vragen oproept en een uitgebreidere technische uitleg volgt!

Zelfs met het verbergen blijven er risico's, iedere malloot die het voorziet op een gateway pakt gewoon IP-Adressen binnen de subnets die eindigen op .1 of .254.

En zelfs al is het geen industry standard, voor zover ik mij kan herinneren wordt er in de netneutraliteit niet expliciet gesproken over een standaard. Over standaarden heb ik weinig kaas gegeten, wel weet ik dat ICMP standaard onderdeel is van internet en is gespecificeerd bij de IETF. En ook dan nog geldt… dit soort zaken horen op voorhand te worden gecommuniceerd, 

Uw internetaanbieder moet zorgen dat het internetverkeer goed verloopt. Hij mag maatregelen nemen om problemen te voorkomen. Deze maatregelen moeten redelijk en begrijpelijk zijn. Ze moeten in verhouding staan tot de problemen die de aanbieder wil voorkomen.

Ze mogen geen onderscheid maken naar inhoud of toepassingen. En uw aanbieder moet u vertellen welke gevolgen deze maatregelen kunnen hebben voor de kwaliteit van uw internettoegang, uw privacy en de bescherming van uw persoonsgegevens.

 

Niet gebeurt, net zo min als de problematiek rondom DTAG of de deal met het CBS (remember). Of wat te denken van deze?

 

Internetaanbieders mogen geen diensten blokkeren, vertragen of beperken. Bijvoorbeeld als het gaat om apps waarmee je gratis kunt bellen of berichten kunt sturen. Ook moeten internetaanbieders voor het verbruik van alle data hetzelfde rekenen. Dus ze mogen er niet meer, maar ook niet minder voor vragen.

Een open internet is belangrijk zodat alle consumenten vrij toegang hebben tot dezelfde informatie. Ook is het goed voor de ontwikkeling van nieuwe internetdiensten, zoals ‘video on demand’.

 

Wellicht toch maar een paar tientjes extra per maand gaan betalen bij een provider die transparant is… Een niet transparante provider is nou niet echt iets waar ik mee door één deur kan.

Reputatie 3

Hi all, excuses dat het even heeft geduurd maar we willen zorgen dat we duidelijk uit kunnen leggen hoe de vork in de steel zit. Een uitgebreidere uitleg volgt, maar de korte samenvatting is dat het zichtbaar zijn van de tussenliggende hops en de core routers een veiligheidsrisico met zich meebrengt. Het is ook niet 'industry standard’ dat deze netwerk informatie zichtbaar is. Als onderdeel van een aantal verbeteringen aan ons netwerk, waaronder een verbetering van de veiligheid bij bijvoorbeeld bij DDoS aanvallen, is de informatie die zichtbaar is bij een trace aangepast en is alleen het eindpunt nog zichtbaar. Ik kan mij voorstellen dat dit mogelijk wat vragen oproept en een uitgebreidere technische uitleg volgt!

 

Bedankt voor je antwoord. Vanuit het oogpunt van veiligheid snap ik ook zeker dat jullie liever niet de tussenliggende informatie zichtbaar willen hebben in de traceroute. En dat is ook prima. Providers als KPN hebben dit ook niet zichtbaar. De ‘normale’ manier om dit te bereiken is het filteren van ICMP vanuit het corenetwerk naar hosts op het internet en klanten. Hierdoor zie je in een traceroute onbekende hops met sterretjes. Dat is zoals je benoemt de “industry standard” manier om dit te bereiken.

De manier waarop T-Mobile dit nu doet gaat nog een stap verder dan dat, door de TTL van alle IP packets zo aan te passen dat het lijkt dat de hops helemaal niet bestaan (traceroutes werken op basis van verlaging van TTL). Daarmee kunnen we de traceroute tools ook niet meer gebruiken om te kijken hoe routes buiten het T-Mobile netwerk lopen. Als systeem/netwerkbeheerder is dit iets wat ik dagelijks meerdere keren gebruik. Ik ben inderdaad niet geinteresseerd in hoe het T-Mobile netwerk inelkaar zit, maar juist in hoe routes lopen buiten het T-Mobile netwerk. Deze oplossing is alles behalve “industry standard”. Ik ken in Europa geen enkel netwerk die dit ook zo doet. Het is ook nog eens een oplossing die voor irritante routingloops of storingen kan zorgen in het T-Mobile corenetwerk. Daarnaast weet ik 100% zeker dat er binnen T-Mobile geen enkele techneut is die dit een goed idee vindt, vergeleken met de “normale” manier om dit te doen, namelijk het filteren van ICMP zoals hierboven beschreven.

Ik vraag absoluut niet om te zien hoe het T-Mobile corenetwerk in elkaar zit, maar zorg er op zijn minst voor dat mijn traceroute ‘normaal’ werkt voor hops buiten het T-Mobile netwerk, op de “industry standard" manier. Het verbergen van deze informatie zal voor mij in een ICT rol in combinatie met thuiswerken al een reden zijn om mijn abonnement niet te verlengen, en ik weet zeker dat ik niet de enige ben.

 

@Brian Dan wordt dit dus de reden dat ik het abonnementga opzeggen. 

me2

 

De route heen is niet direct de route terug.

en de route heen (uit klant oogpunt) is niet meer te zien. maar de route terug.

 

Op de route terug. (laat ik eens wat routes langs AMS-IX nemen) zie ik ook wat vreemde zaken…..

 

@Brian bedankt voor je input. Voor velen nu duidelijk dat t-mobile thuis wel het goedkoopste is maar dat je daarvoor wel wat moet inleveren. Maar voor veel huis tuin en keuken gebruikers voldoende is.

 

 

Reputatie 1

@Brian Dan wordt dit dus de reden dat ik het abonnementga opzeggen. 

Reageer