Blokkade netbios verkeer UPC

[DuLaC]

Ik heb sinds deze week een Extreme verbinding via UPC. Door UPC worden echter een aantal poorten geblokkeerd waaronder 139 en 445. Aangezien ik netbios gebruik om media te streamen van m'n server naar huis heb ik nu dus een probleem.

Heb al een aantal keer contact opgenomen met UPC en ze blijven bij hoog en laag bewerken dat ze niet blokkeren. Kan me niet voorstellen dat ik de enige ben die hier tegen aan loopt. Kan er echter weinig op internet over terug vinden.

Ik heb op dit moment 2 verbindingen aan m'n router hangen. (Alice = ipx1 en UPC = ipx2) Als ik netbios verkeer routeer over mijn Alice verbinding werkt het wel en via UPC niet.

In alle 2 de gevallen verlaat het pakketje mijn thuis netwerk. Zie mijn router log:

Jun 23 20:11:21 2008 Connection Accepted TCP 192.168.0.5:3069->85.12.X.X:445 on ixp2

Jun 23 20:23:00 2008 Connection Accepted TCP 192.168.0.5:3108->85.12.X.X:445 on ixp1

Vervolgens dropt het UPC netwerk het pakketje ergens want het komt niet aan op m'n server.

Zie mijn transfer log van mijn server wanneer ik verbind via Alice:

Source: destination: Bytes in: Bytes out: Description:
93.125.X.X:3108 85.12.X.X:445 188.938kb 100.344kb tcp connection accepted

Via UPC gebeurt er niets. Geen geaccepteerd pakketje maar ook geen geblokt pakketje.

Poortscan laat het zelfde beeld zien.

Antwoord UPC:

Hartelijk dank voor uw bericht. Wij maken graag van deze gelegenheid gebruik om uw probleem op te lossen en/of uw vraag te beantwoorden.
Allereerst onze welgemeende excuses namens UPC voor de overlast welke u hiervan ondervindt.

Wij blokkeren de door u genoemde poorten echter niet. Met het gebruik van windows zijn een aantal poorten zoals 136, 137 en 138 dichtgezet door de interne firewall voor inkomende verzoeken. Wij raden u aan voor uw machine en de server deze poorten via de aanwezige firewall aan te zetten. Wel worden de poorten 136, 137 en 138 ook gebruikt voor het besmetten van Windows Machines. U maakt gebruik van Samba, Dit zou betekeken dat u gebruik maakt van een *nix variant. In dat geval kunnen wij u alleen adviseren de juiste porten via Webmin/usermin te openen of informatie hierover te zoeken via de *nix communities voor de door u gebruikte *nix variant.

*zucht*

Anderen die dit ook ervaren? Regio Amsterdam?

[CyBeR]

Vrijwel alle consumentenISP's blokkeren NETBIOS poorten. Kom je niet omheen, is gewoon een ACL ergens op hun spullen. Enige manier is om via een VPN te werken.

[Bergen]

Als ik het me goed herinner zijn deze poorten dichtgezet ten tijde van de uitbraak van de Blaster worm in 2003, om verspreiding binnen het chello-netwerk te voorkomen. Voor zover ik weet zitten die inderdaad nog steeds dicht. Degene die je mail beantwoord heeft, heeft dit blijkbaar niet geweten.

[ Voor 12% gewijzigd door Bergen op 25-06-2008 03:49 ]

[gertvdijk]

Ja en logisch ook. Je hoort het ook niet zo te streamen.
Voor zoiets bestaat VPN of andere tunnels.
Die Netbios poorten open gooien voor het internet is leuk als mensen eens hun firewall uitzetten en dingen hebben gedeeld via Windows. Trojantje hier, Trojantje daar.

[pven]

Dit is meer iets voor Internetproviders en Hosting

[Brahiewahiewa]

Kan me slecht voorstellen dat je hiermee een publieke service aanbiedt. En als het alleen voor jezelf is, moet het toch niet zo moeilijk zijn om een ander poortje te gebruiken; 444 ofzo.

[dion_b]

Bergen schreef op woensdag 25 juni 2008 @ 03:37:
Als ik het me goed herinner zijn deze poorten dichtgezet ten tijde van de uitbraak van de Blaster worm in 2003, om verspreiding binnen het chello-netwerk te voorkomen. Voor zover ik weet zitten die inderdaad nog steeds dicht. Degene die je mail beantwoord heeft, heeft dit blijkbaar niet geweten.

Dat zal RPC geweest zijn. Lijkt me dat NetBIOS afgesloten zal zijn toen anno 1998 ofzo de ISP live ging en het abusedesk meldingen kreeg van buren die in elkaars mappen zaten te snuffelen...

* dion_b is doorgaans geen voorstander van betutteling, maar in dit geval bescherm je niet alleen mensen tegen zichzelf maar ook tegen elkaar en dat is wel degelijk iets wat een beheerder moet doen

[CyBeR]

dion_b schreef op woensdag 25 juni 2008 @ 19:37:
[...]

Dat zal RPC geweest zijn. Lijkt me dat NetBIOS afgesloten zal zijn toen anno 1998 ofzo de ISP live ging en het abusedesk meldingen kreeg van buren die in elkaars mappen zaten te snuffelen...

* dion_b is doorgaans geen voorstander van betutteling, maar in dit geval bescherm je niet alleen mensen tegen zichzelf maar ook tegen elkaar en dat is wel degelijk iets wat een beheerder moet doen

Dat, plus net send spam, etc. 't is ook niet iets wat je gewoonlijk op 't internet tegen zou komen.

[IEF]

Eerlijk gezegd verbaast me hun antwoord enigzins.

Ik kan me goed voorstellen dat ze het blokkeren, NetBIOS is ook niet ontworpen om over een WAN te routeren.

Je zoekt een oplossing bij UPC, al klopt dit niet echt. Jij bent degene die een protocol gebruikt dat
eigenlijk nooit voor het internet bedoeld is. Wil je het per se via NetBIOS doen, gebruik dan een VPN ofzo. Er zijn genoeg alternatieven voor NetBIOS die zeker weten niet geblokkeerd worden.

[SKiLLa]

CyBeR schreef op woensdag 25 juni 2008 @ 03:03:
Vrijwel alle consumentenISP's blokkeren NETBIOS poorten. Kom je niet omheen, is gewoon een ACL ergens op hun spullen. Enige manier is om via een VPN te werken.

Yup, veel ISPs hebben dergelijke ACLs voor de NETBIOS (135-139) poorten. En zelfs als je eigen ISP het niet blokkeert, kan het nog door andere partijen in verbindings-keten geblokkeert worden.

Zelfde geldt voor vaak voor SMTP (25) en in mindere mate SMB (445) en soms zelfs IPSec (88) wegens deze exploit en wie weet welke poorten nog meer allemaal ...

Wel een gevalletje slecht communicatie (of policy) dat de UPC helpdesk je dat niet kon mededelen; het is niet alsnog de UPC netwerk-boys het niet weten ...

[Bergen]

dion_b schreef op woensdag 25 juni 2008 @ 19:37:
[...]

Dat zal RPC geweest zijn. Lijkt me dat NetBIOS afgesloten zal zijn toen anno 1998 ofzo de ISP live ging en het abusedesk meldingen kreeg van buren die in elkaars mappen zaten te snuffelen...

* dion_b is doorgaans geen voorstander van betutteling, maar in dit geval bescherm je niet alleen mensen tegen zichzelf maar ook tegen elkaar en dat is wel degelijk iets wat een beheerder moet doen

Dat herinner ik me niet, maar het zou natuurlijk best kunnen. RPC werd inderdaad geëxploit door Blaster, maar niet alleen poort 445 werd gebruikt; ook poort 135 en 139. Zie de CERT advisory.

Het is een beetje apart dat een provider dit doet, maar ik vind het een goeie zaak. Je verbaast je er op de helpdesk soms over hoeveel mensen hun pc nog rechtstreeks op het internet hebben zitten zonder enige bescherming. Er is niks mis mee om al die klanten wat bescherming te bieden.

Wel een gevalletje slecht communicatie (of policy) dat de UPC helpdesk je dat niet kon mededelen; het is niet alsnog de UPC netwerk-boys het niet weten ...

Het Blaster-verhaal is al jaren achter de rug en die poorten zijn helemaal niet bedoeld om over het internet te worden gebruikt, dus het lijkt me op zich niet onlogisch dat niet iedereen ervan op de hoogte is op de helpdesk. Dit is typisch een geval van "je moet het toevallig weten".

[ Voor 32% gewijzigd door Bergen op 26-06-2008 01:14 ]

[GrooV]

XS4ALL blokt Netbios niet meer, maar als je er misbruikt van maakt wordt je zelf geblokkeerd

[SKiLLa]

Bergen schreef op woensdag 25 juni 2008 @ 23:43:
[...]
Het Blaster-verhaal is al jaren achter de rug en die poorten zijn helemaal niet bedoeld om over het internet te worden gebruikt, dus het lijkt me op zich niet onlogisch dat niet iedereen ervan op de hoogte is op de helpdesk. Dit is typisch een geval van "je moet het toevallig weten".

Nou, het port-filteren heeft zoveel impact op de core dienstverlening (in het geval van een internetverbinding) dat je mag verwachten dat het bij de helpdesk bekend is vind ik. Of het nu poort 25 is (inbound SMTP) of 135-139 (NETBIOS) maakt in die context niet uit ... Het is niet bij wet verboden om b.v. poort 135 ergens anders voor te gebruiken, al is het uiteraard wel sterk afgeraden.

Naast IP poorten worden vaak ook (lagere OSI layer) protocollen als b.v. BGP, etc. gefiltert; een beetje serieuze helpdesk kan je dat ook vertellen (al is het dan per email en/of via de website en niet via de 1ste lijns tel-hulp); dat een groot deel van de klanten potentieel digibeet is doet daar niets aan af.

[Bergen]

Als poort 25 geblockt zou zijn wel ja, dan zou waarschijnlijk iedereen daarvan op de hoogte zijn. Maar UPC blokkeert poort 25 niet (en andere poorten voor veelgebruikte services ook niet) en de poorten uit dit topic gebruikt niemand over het internet (omdat ze daar niet voor bedoeld zijn), dus dit hele onderwerp komt nooit ter sprake.

En wat heeft een klant met eventuele BGP-filtering te maken?

[ Voor 14% gewijzigd door Bergen op 26-06-2008 00:57 ]

[SKiLLa]

Bergen schreef op donderdag 26 juni 2008 @ 00:41:
... en de poorten uit dit topic gebruikt niemand over het internet (omdat ze daar niet voor bedoeld zijn), dus dit hele onderwerp komt nooit ter sprake. ...

Dat is geen excuus. En het "verkeerd gebruik" komt toch echt wel voor, neem alleen de TS in dit geval. Met X honderdduizenden internet-aansluitingen heeft UPC de vraag vast wel vaker gehoord ...

[Bergen]

SKiLLa schreef op donderdag 26 juni 2008 @ 00:53:
[...]

Dat is geen excuus.

Ik noem geen excuus, ik noem een feit. Het komt nooit ter sprake, klaar.

En het "verkeerd gebruik" komt toch echt wel voor neem alleen de TS in dit geval.

Zou kunnen.

Met X honderdduizenden internet-aansluitingen heeft UPC de vraag vast wel vaker gehoord...

Nou nee, eigenlijk niet. Ik werk daar al heel wat jaartjes, maar alleen ten tijde van de Blaster-uitbraak was het een hot item. Daarna heb ik er nooit meer iemand over gehoord. Behalve deze (op internet ongebruikte) poorten zit er bij UPC niets dicht, dus er valt niets te discussieren. Zo gek is dat toch niet?

[ Voor 10% gewijzigd door Bergen op 26-06-2008 01:06 ]

[CyBeR]

SKiLLa schreef op donderdag 26 juni 2008 @ 00:23:
[...]


Naast IP poorten worden vaak ook (lagere OSI layer) protocollen als b.v. BGP, etc. gefiltert;

Nu zit je gewoon uit je kont te praten hoor. Ten eerste heeft een consument absoluut geen mogelijkheid tot het gebruiken van BGP in een nuttige wijze. Maar belangrijker, BGP is gewoon een protocol op basis van TCP. IP poorten bestaan trouwens ook niet, dat zijn TCP of UDP poorten.

[DuLaC]

Zo onveilig hoeft het nou allemaal niet te zijn. Ik broadcast de share niet, heb admin shares uit staan en toegang enkel aan staan voor mijn thuis ip adres. Daarnaast is de share read only. Al komt men er bij, ik heb geen staatsgeheimen op de share staan.

Ik heb jarenlang internet via Wanadoo/Orange gehad die dit gewoon toestaat.

Naast het mailtje heb ik hier ook een aantal keer over gebeld. Ze doen daar net of ik achterlijk ben. Wat voor argumenten je ook aanvoert, de medewerker van UPC houd gewoon vol de alles wide open staat. Wanneer je vervolgens over verstuurde en niet aangekomen pakketjes begint krijg je te horen dat dat soort vragen niet ondersteund worden.

Waar ik gewoon een beetje moeite mee heb is dat UPC me beperkt ik het gebruik van mijn internet verbinding en dat bovendien niet toe geeft. Ik bepaal zelf wel wat (on)verstandig is, daar heb ik UPC niet voor nodig.

Kan me nog enigszins voorstellen dat UPC netbios verkeer blokkeerd van abonnee verbindingen naar het internet om klanten te beschermen die dit per ongeluk hun hele computer sharen met de rest van de wereld, maar welk nut dient het om deze blokkade ook andersom op te leggen?

[ Voor 13% gewijzigd door DuLaC op 26-06-2008 01:51 ]

[CyBeR]

DuLaC schreef op donderdag 26 juni 2008 @ 01:46:
Zo onveilig hoeft het nou allemaal niet te zijn. Ik broadcast de share niet, heb admin shares uit staan en toegang enkel aan staan voor mijn thuis ip adres. Daarnaast is de share read only. Al komt men er bij, ik heb geen staatsgeheimen op de share staan.

Ik heb jarenlang internet via Wanadoo/Orange gehad die dit gewoon toestaat.

Ik kan 't nu even niet checken (lijn kapot wegens verhuizing) maar afaik filtert ook orange gewoon netbios.

Naast het mailtje heb ik hier ook een aantal keer over gebeld. Ze doen daar net of ik achterlijk ben. Wat voor argumenten je ook aanvoert, de medewerker van UPC houd gewoon vol de alles wide open staat. Wanneer je vervolgens over verstuurde en niet aangekomen pakketjes begint krijg je te horen dat dat soort vragen niet ondersteund worden.

Je belt ook met een consumentenhelpdesk. Die is ingericht op consumentendigibeten. Die miepen aan de telefoon daar weten echt niks wat niet in hun script staat.

Waar ik gewoon een beetje moeite mee heb is dat UPC me beperkt ik het gebruik van mijn internet verbinding en dat bovendien niet toe geeft. Ik bepaal zelf wel wat (on)verstandig is, daar heb ik UPC niet voor nodig.

UPC zal dat prima toegeven als je 't aan de juist mensen vraagt. En de juiste mensen zijn niet de 1e lijns helpdeskers.

Kan me nog enigszins voorstellen dat UPC netbios verkeer blokkeerd van abonnee verbindingen naar het internet om klanten te beschermen die dit per ongeluk hun hele computer sharen met de rest van de wereld, maar welk nut dient het om deze blokkade ook andersom op te leggen?

Zit weinig verschil tussen in dit geval. NETBIOS maakt in beide richtingen gebruik van verkeer over dezelfde poorten, het een blokkeren blokkeert dus automatisch het andere. Het is ook een brak protocol dat helemaal niet voor dit gebruik gemaakt is. Lekker iets anders gebruiken dus, of VPN'en.

[Bergen]

CyBeR schreef op donderdag 26 juni 2008 @ 02:16:
[...]

Je belt ook met een consumentenhelpdesk. Die is ingericht op consumentendigibeten. Die miepen aan de telefoon daar weten echt niks wat niet in hun script staat.

CyBeR, over het algemeen ben ik het roerend met je eens, maar hier wil ik toch even inhaken. a) we zijn geen miepen en b) we zijn een van de weinige callcenters zonder belscripts.

UPC zal dat prima toegeven als je 't aan de juist mensen vraagt.

Zo is dat.

En de juiste mensen zijn niet de 1e lijns helpdeskers.

Ook de 1e lijns helpdeskers, dat zijn ook gewoon de juiste mensen. Als jij het beeld hebt dat er een 1e 'domme' lijn is en een 2e/3e 'slimme' lijn, dan heb je een compleet verkeerd beeld van de structuur van de helpdesk. Hopelijk begrijp je dat ik hier niet kan gaan uitleggen hoe dan wél precies inelkaar steekt maar de eerste lijn is gewoon een slimme afdeling. Dat er medewerkers tussen zitten die niet weten dat de NetBIOS- en RPC-poorten dichtzitten maakt het niet automatisch een domme afdeling. Dan sla je de plank behoorlijk mis.

[CyBeR]

Bergen schreef op donderdag 26 juni 2008 @ 03:03:
[...]
CyBeR, over het algemeen ben ik het roerend met je eens, maar hier wil ik toch even inhaken. a) we zijn geen miepen en b) we zijn een van de weinige callcenters zonder belscripts.

Ok, sorry. Ik heb de afgelopen weken excessief veel met helpdesks aan de lijn gehangen (verhuizingen van telefoonlijnen, adsl verhuizing die mis ging, etc.) en dan merk je bijvoorbeeld bij KPN dat als je niet de business service desk belt maar direct de afdeling orderafhandeling dat die mensen gewoon meer weten en kunnen. Ik ben geen klant van UPC, dus mischien is dat daar anders. (Overigens werkt kpn ook niet met belscripts, iig voor deze toepassing niet.)

[DuLaC]

CyBeR schreef op donderdag 26 juni 2008 @ 02:16:

Zit weinig verschil tussen in dit geval. NETBIOS maakt in beide richtingen gebruik van verkeer over dezelfde poorten, het een blokkeren blokkeert dus automatisch het andere. Het is ook een brak protocol dat helemaal niet voor dit gebruik gemaakt is. Lekker iets anders gebruiken dus, of VPN'en.

Ondanks dat netbios over de zelfde poort werkt kun je op netwerk niveau toch aangeven dat een verbinding die geïnitieerd wordt van binnen het netwerk naar een remote server wel mag en andersom niet? Ik zie het probleem niet zo.

[CyBeR]

DuLaC schreef op donderdag 26 juni 2008 @ 08:40:
[...]


Ondanks dat netbios over de zelfde poort werkt kun je op netwerk niveau toch aangeven dat een verbinding die geïnitieerd wordt van binnen het netwerk naar een remote server wel mag en andersom niet? Ik zie het probleem niet zo.

Nee, want 't is UDP. Bij TCP zou dat inderdaad kunnen.

[dion_b]

Bergen schreef op donderdag 26 juni 2008 @ 03:03:
[...]

Dat er medewerkers tussen zitten die niet weten dat de NetBIOS- en RPC-poorten dichtzitten maakt het niet automatisch een domme afdeling. Dan sla je de plank behoorlijk mis.

Mwoeah, ik snap de frustratie van DuLaC wel. Er is een verschil tussen iets niet weten, waar op zich niets mis mee is, en iets met stelligheid beweren dat gewoon niet waar is (omdat je iets niet weet en dat niet durft toe te geven). Dat laatste is gewoon een kwalijke zaak dat niet goed te praten valt.

[DuLaC]

Ze houden vol... Nieuwe mail van UPC. Het wordt nu nog sterker... Als ik UPC mag geloven wordt er veelvuldig gebruik van gemaakt.

UPC blokkeert geen Netbios. Onze klanten maken er gewoon gebruik van.
UPC kan u echter niet inhoudelijk ondersteunen.
Een server draaien is toegestaan. Ook hiervoor geldt echter dat geen enkele vorm van ondersteuning mogelijk is.
Zijn de door u genoemde mogelijkheden van groot (zakelijk) belang en wilt u uitgebreide ondersteuning, dan raden wij u aan contact op te nemen met onze zakelijke afdeling www.priority.nl

*zucht* Wat moet ik hier nou mee... Ze hebben m'n mail ook maar half gelezen lijkt. Wat heeft het draaien van een server nou met dit verhaal te maken...

[ Voor 10% gewijzigd door DuLaC op 26-06-2008 23:52 ]

[Verwijderd]

dion_b schreef op woensdag 25 juni 2008 @ 19:37:
[...]

Dat zal RPC geweest zijn. Lijkt me dat NetBIOS afgesloten zal zijn toen anno 1998 ofzo de ISP live ging en het abusedesk meldingen kreeg van buren die in elkaars mappen zaten te snuffelen...

* dion_b is doorgaans geen voorstander van betutteling, maar in dit geval bescherm je niet alleen mensen tegen zichzelf maar ook tegen elkaar en dat is wel degelijk iets wat een beheerder moet doen

Tijden die ik nooit meegemaakt heb nee! Maar idd, via netbios kon je bepaalde services gewoon afstruinen. Iemand zijn shares via netbios bladeren enzo. Aangezien 90% niet weet of hun PC wel of niet geinfecteerd is vindt ik het een goede zet van de ISP om dit soort poorten te weren. Simpel. En niet iedereen heeft een SP1 of SP2/SP3 XP liggen thuis, sommigen hebben zelfs de Non-SP versie die dus wel vatbaar is nog voor de blasterworm.

Er was op T.net nog een review geloof ik over welk OS nu het meest destructief was achter een non-firewalled connectie, en vanzelfsprekend kwam daar Windows XP non-sp1 weer uit

Ik denk dat TS een andere manier zoeken moet om te streamen. Er zijn genoeg alternatieven lijkt me en UPC is jouw niet verplicht dat poortje open te zetten. Daar kan de helpdesk niets vanaf weten bijv, en stuurt je dus een voorgegenereerde mail terug.

[The Eagle]

@TS: Ik heb ook eens een gevalletje aan de hand gehad waarbij ik van te voren al 100% zeker wist dat ik minimaal de 2e lijn nodig zou hebben. Helpdesk (casema in mijn geval) gebeld, uitgelegd dat ik zelf redelijk diep in de ICT zat, aangegeven wat ik zelf allemaal al gedaan had (hoop vaktermen als DHCP, firewall-installingen, DMZ doet het ook goed, etc er doorheen gegooid) en tegen de man die ik aan de lijn had verteld dat ik vermoedde dat ik nu zo'n beetje al zijn bekende oplossingen wel opgenoemd had en eigenlijk gewoon graag rechtstreeks de 2e lijn wilde spreken
Hij gaf toen idd aan dat het hem behoorlijk boven zijn pet ging wat ik allemaal opnoemde, en verbond me vrijwel direct door

Het is dus eigenlijk een kwestie van weten aan te geven dat je meer weet en geprobeerd hebt als de helpdesker die je aan de lijn krijgt, en dan gewoon vriendelijk verzoeken om de 2e lijn. Works like a dream

[dion_b]

DuLaC schreef op donderdag 26 juni 2008 @ 23:48:
Ze houden vol... Nieuwe mail van UPC. Het wordt nu nog sterker... Als ik UPC mag geloven wordt er veelvuldig gebruik van gemaakt.

UPC blokkeert geen Netbios. Onze klanten maken er gewoon gebruik van.
UPC kan u echter niet inhoudelijk ondersteunen.
Een server draaien is toegestaan. Ook hiervoor geldt echter dat geen enkele vorm van ondersteuning mogelijk is.
Zijn de door u genoemde mogelijkheden van groot (zakelijk) belang en wilt u uitgebreide ondersteuning, dan raden wij u aan contact op te nemen met onze zakelijke afdeling www.priority.nl

*zucht* Wat moet ik hier nou mee... Ze hebben m'n mail ook maar half gelezen lijkt. Wat heeft het draaien van een server nou met dit verhaal te maken...

Volgens mij lees jij hun mail nu ook maar half

Er staat toch duidelijk in dat support op servers (en als jij vragen wil hebben over access op poorten is dat exact wat je wilt) niet geleverd wordt door de consumentenhelpdesk en dat als je dat support wel wilt, je een zakelijke abo dient te nemen.

Dat is een duidelijk antwoord, ook al is het niet het antwoord wat je zou willen.


Edit:
Het eerste deel is gewoon onzin, wederom niet goed te praten. Ik zou daarover een brief (papier!) sturen met de klacht meermaals verkeerd voorgelicht te zijn. Je kunt daarbij rustig verwijzen naar UPC helpdeskers in dit topic (Bergen!) die wel duidelijk weten hoe de vork in de steel zit.

In het beste geval levert het jou een bloemetje op, want die poorten zitten om een goede reden dicht en het belang van iedereen (geen spam, geen malware etc.) gaat boven jouw belang om ze te gebruiken - waarbij er voor jou zat alternatieven zijn (ik stream bijvoorbeeld op 8080...). Ze zullen dus niet voor je heropend worden. Wel kun je er zo voor zorgen dat een of andere rotte appel op de helpdesk een erg harde trap onder z'n kont krijgt waar jij en de rest van ons (UPC klanten) in de toekomst baat bij zullen hebben

[ Voor 25% gewijzigd door dion_b op 27-06-2008 15:56 ]

[Brahiewahiewa]

dion_b schreef op vrijdag 27 juni 2008 @ 15:30:
[...]een of andere rotte appel op de helpdesk...

Het is maar de vraag of daar het probleem ligt. Tot nu toe hebben we maar één kant van het verhaal gehoord. Gezien het gebrek aan inlevingsvermogen dat TS hier ventileert, zou het me niet verbazen dat het verhaal van de andere kant heel anders klinkt.

[leuk_he]

Met tracetcp (moet je wel wat drivers installeren) kun je terugtracen waar het in het upc netwerk geblokkeed wordt.

En hoewel ik het vaak niet met dion_b eens ben , in dit geval zul je op een andere poort aan de gang moeten, al dan niet via vpn, want meer support zul je niet krijgen.

[Wim-Bart]

Jun 23 20:11:21 2008 Connection Accepted TCP 192.168.0.5:3069->85.12.X.X:445 on ixp2
Jun 23 20:23:00 2008 Connection Accepted TCP 192.168.0.5:3108->85.12.X.X:445 on ixp1

Even een rare vraag. Je maakt verbinding van je lokale LAN naar je externe adres zo te zien. Staat je routering dan wel goed voor de UPC verbinding.

Overigens heb ik het volgende zelf eens getest met behulp van wat mensen:

137,138,139,445 TCP XS4ALL <-> UPC. werkt.
137,138,139,445 UDP XS4ALL <-> UPC. werkt
137,138,139,445 TCP KPN (Het Net) <-> UPC. werkt niet. (zowel zakelijk als consument)
137,138,139,445 UDP KPN (Het Net) <-> UPC. werkt niet. (zowel zakelijk als consument)
137,138,139,445 TCP BBNet (zakelijk) <-> UPC. werkt.
137,138,139,445 UDP BBNet (zakelijk) <-> UPC. werkt.

Dus waarschijnlijk zit er toch iets bij jou verkeerd. Overigens werkt RDP ook niet van en naar KPN aansluitingen.

[Bergen]

dion_b schreef op vrijdag 27 juni 2008 @ 15:30:
[...]

Edit:
Het eerste deel is gewoon onzin, wederom niet goed te praten. Ik zou daarover een brief (papier!) sturen met de klacht meermaals verkeerd voorgelicht te zijn. Je kunt daarbij rustig verwijzen naar UPC helpdeskers in dit topic (Bergen!) die wel duidelijk weten hoe de vork in de steel zit.

Ik weet het ook niet 100% zeker, omdat zoals ik zei dit hele onderwerp nooit ter sprake komt, maar voor zover ik me kan herinneren zijn ten tijde van het Blaster-gebeuren die poorten dichtgezet.

Ik heb een paar maanden geleden ook eens geprobeerd om bij mijn ouders vandaan (= @home) een Samba-share te benaderen bij mij thuis (UPC dus) en dat lukte niet. Daaruit concludeerde ik dat de poorten waarschijnlijk nog steeds dicht zaten, maar het kan ook aan de @home-kant geblokkeerd zijn. Dus tja, het is voor mij ook niet 100% zeker of de poorten wel echt dicht zitten. Als ik op de helpdesk die vraag zou krijgen van een klant, zou ik het eerst goed opzoeken voordat ik daar een zeker antwoord op geef.

Dat kan ik voor dit topic ook wel doen, maar indien die informatie onder interne info valt zul je begrijpen dat ik dat hier niet kan delen.

[edit]
Aan Wim-Bart zijn bevindingen hierboven te zien zouden de poorten gewoon open moeten staan...

[edit 2]
Ík heb het eens met de online portscanner van grc.com geprobeerd en getest op poorten 137-139 en 445. Ik heb alles wagewijd opengezet, in iptables heb ik de default policy van de input-chain zelfs even op accept gezet. Echter worden de poorten 137-139 en 445 nog steeds gerapporteerd alszijnde 'shielded'. Met andere woorden: de pakketjes worden gedropt.

[ Voor 34% gewijzigd door Bergen op 28-06-2008 04:25 ]

[DuLaC]

Wim-Bart schreef op vrijdag 27 juni 2008 @ 18:04:
[...]

Even een rare vraag. Je maakt verbinding van je lokale LAN naar je externe adres zo te zien. Staat je routering dan wel goed voor de UPC verbinding.

Dit gebeurd er wanneer ik een trace doe naar poort 80:

Tracing route to 85.12.x.x on port 80
Over a maximum of 30 hops.
1 1 ms 1 ms 2 ms 192.168.0.1
2 8 ms 8 ms 8 ms 10.15.151.1
3 9 ms 7 ms 5 ms 212.142.21.161 [p21161.net.upc.nl]
4 10 ms 8 ms 8 ms 212.142.32.65 [p14232065.net.upc.nl]
5 10 ms 10 ms 10 ms 213.46.183.229
6 9 ms 10 ms 247 ms 195.69.145.174 [ams-ix.sara-ams.as34305.net]
7 12 ms 10 ms 10 ms 85.12.0.34 [10ge-v3.core-2.ipv4-mg8.db-ams
euroaccess.nl]
8 12 ms 12 ms 10 ms 193.138.220.222 [gateway.mediaserve.nl]
9 Destination Reached in 10 ms. Connection established to 85.12.X.X
Trace Complete.

Dit naar poort 445:

Tracing route to 85.12.x.x on port 445
Over a maximum of 30 hops.
1 2 ms 2 ms 2 ms 192.168.0.1
2 10.15.151.1 reports: NO ROUTE
Trace Complete.

In mijn kabelmodem gaat het dus al mis, echter UPC beheerd dat ding.

Als in iets verkeerd doe... Ik hoor het graag...

[ Voor 12% gewijzigd door DuLaC op 28-06-2008 02:48 ]

[CyBeR]

DuLaC schreef op zaterdag 28 juni 2008 @ 02:46:
[...]

In mijn kabelmodem gaat het dus al mis, echter UPC beheerd dat ding.

Als in iets verkeerd doe... Ik hoor het graag...

Je doet niets verkeerd maar je interpreteert wel verkeerd. Je kabelmodem is een bridge, die ga je niet tevoorschijn zien komen in een traceroute. (En als 't wel een router is, staat 'ie er trouwens in en filtert 'ie dus niet.)

Je krijgt een port unreachable (o.i.d) terug van 10.15.151.1. Zoals je weet zijn 10.0.0.0/8 private IP's die niet voorkomen op het internet. In dit geval is dat gewoon de CMTS van UPS, en inderdaad die doet alvast het filteren. Dat is namelijk de beste plek:

• Weinig verkeer te verwerken (paar mbit per CMTS, vs. een paar gbit in de core)
• Het voorkomt ook meteen dat je bij je buren zit te kutten, terwijl dat verkeer de core nooit zou zien.
• Simpel per aansluiting te definieren of wel of niet gefilterd moet worden (als ze dat doen, iig.)

[dion_b]

Brahiewahiewa schreef op vrijdag 27 juni 2008 @ 17:41:
[...]
Het is maar de vraag of daar het probleem ligt. Tot nu toe hebben we maar één kant van het verhaal gehoord. Gezien het gebrek aan inlevingsvermogen dat TS hier ventileert, zou het me niet verbazen dat het verhaal van de andere kant heel anders klinkt.

Mwoeah, tenzij hij ook nog eens de emails die hij quote heeft zitten bewerken is het duidelijk genoeg:

UPC blokkeert geen Netbios. Onze klanten maken er gewoon gebruik van.

En dat is gewoon onzin. Dit is (iirc in een van de 'grote' UPC topics) vaker ter discussie gekomen en ook op chelloo.com is het al jarenlang bekend.

IMHO geen slechte zaak trouwens dat NetBIOS geblokkeerd wordt, verder kan ik er alle begrip voor opbrengen dat een helpdesker (onderscheid 1e lijns en 2e lijns kennen ze bij UPC niet) niet gelijk dit soort vrij specialistische info paraat heeft. Maar om dan uit die onwetendheid onwaarheden te gaan verkopen is wel kwalijk.

Wim-Bart schreef op vrijdag 27 juni 2008 @ 18:04:
[...]


Even een rare vraag. Je maakt verbinding van je lokale LAN naar je externe adres zo te zien. Staat je routering dan wel goed voor de UPC verbinding.

Overigens heb ik het volgende zelf eens getest met behulp van wat mensen:

137,138,139,445 TCP XS4ALL <-> UPC. werkt.
137,138,139,445 UDP XS4ALL <-> UPC. werkt
137,138,139,445 TCP KPN (Het Net) <-> UPC. werkt niet. (zowel zakelijk als consument)
137,138,139,445 UDP KPN (Het Net) <-> UPC. werkt niet. (zowel zakelijk als consument)
137,138,139,445 TCP BBNet (zakelijk) <-> UPC. werkt.
137,138,139,445 UDP BBNet (zakelijk) <-> UPC. werkt.

Dus waarschijnlijk zit er toch iets bij jou verkeerd. Overigens werkt RDP ook niet van en naar KPN aansluitingen.

Interessant. Exact welke UPC aansluitingen hebben we he hier over? Ik heb mezelf niet al te lang terug geportscanned vanaf een andere UPC aansluiting en vanaf een DSL (weet niet welke, ik vermoed HetNet oid) om werking van m'n firewall te controleren. Met firewall aan was wel meer niet te vinden ( ), maar met firewall uit ook duidelijk de 137-139 en 445 onzichtbaar.

UPC aansluiting in deze test was gewoon een consumentengeval (Power) op een EuroDOCSIS modem in Nijmegen Wolfskuil.