Skip to main content

Allen,

 

De ExperiaBox (versie 10A) stuurt elke minuut tien UDP-137 pakketjes weg.

Doorgaans is dit iets wat bij Samba/SMB gebruikt wordt.

Op zich niet ernstig - hooguit hinderlijk omdat de achterliggende firewall “aanslaat” (i.e. alarm genereert) omdat dit type netwerk pakketje als verdacht wordt aangemerkt.

Kan ik dat ergens uitschakelen? Waar?

 

 

MhG - Will

En wat heb je in je thuis netwerk hangen?
Het kan te maken hebben met connectie van apparaten onderling in je thuisnetwerk.


Ik dacht dat dit ondertussen historie was, maar de “nmb” component van zelfs de actuele samba versie stuurt udp/137 broadcast pakketjes om zichzelf bekend te maken op het netwerk. Als de V10a de mogelijkheid heeft om de inhoud van een USB drive te delen, dan moet dat ergens uit te schakelen zijn, anders heeft KPN een overbodige service draaien in de router en zou dat bij een firmware update verholpen kunnen worden.

 

 


Als de V10a de mogelijkheid heeft om de inhoud van een USB drive te delen, dan moet dat ergens uit te schakelen zijn,

Het hoeft helemaal niet daarmee te maken te hebben.

Als een gebruiker bijv. een NAS in zijn netwerk heeft, en Windows / Apple apparatuur (ja zelfs die ondersteunt SMB), en aanvullende andere apparaten als players e.d. heb je er ook mee te maken.
Het is gewoon een standaard gebruikt netwerk protocol van een router binnen het LAN.


Zou niet weten waarom de V10A dir zou doen omdat de USB poort slechts 1 doel heeft. 4G backup.

Eventueele Samba zal ook dus niet actief zijn ( Lijkt me vreemd ) 

Maar kijk inderdaad eens kritisch naar je eigen netwerk, Denk eerder dat er ergens eventueel foutief of overbodig een Samba draait in je netwerk en Dat deze de broadcast veroorzaakt.


Ik lees iets over een achterliggende firewall. Een 2de router dus? In dat geval zal er waarschijnlijk verder niks rechstreeks aan de Experiabox gekoppeld zijn. Alle apparaten zitten dan achter de 2de router. SMB verkeer kan dan dus alleen bij de Experiabox vandaan komen. Of misschien eventueel bij de tv ontvangers. 

Dat het bij de Experiabox vandaan komt is ook niet vreemd. Want als je een Windows pc aan de Experiabox koppelt en je kijkt bij netwerkoverzicht, dan staat daar de Experiabox ook bij. Volgens mij de tv-ontvangers ook. Dus ze doen wat. Je kunt er verder niets mee.


Ik lees iets over een achterliggende firewall. Een 2de router dus?

Maar zelfs bij dubbel NAT kan men vanuit het LAN van de 2e router connectie leggen met het LAN van de Experia Box.


Ik ging er van uit dat @nogneetmachinaa in de firewall meldingen ziet die van 192.168.2.254 afkomen, anders is de vraag op de verkeerde plek gesteld. Als de V10a net als de V10 alleen 3G/4G backup ondersteunt, is er geen enkele reden om netbios paketten rond te sturen, dat is voor bestands- en printerdeling.  Ieder systeem, waaronder NAS e.d., kan deze paketten versturen, een (oude?) Windows PC met gedeelde directories of printers, andere besturingssystemen die samba gebruiken. Maar waarom zou een pure router dat doen? De V10 zonder A is in ieder geval stil op deze poort, Windows 10 ook.  De V10 kondigt zich wel aan op SSDP poort 1900, dat is een nieuwer (multimedia)  systeem waarmee apparatuur zich bekend maakt op het netwerk.


Ik ging er van uit dat @nogneetmachinaa in de firewall meldingen ziet die van 192.168.2.254 afkomen, anders is de vraag op de verkeerde plek gesteld. Als de V10a net als de V10 alleen 3G/4G backup ondersteunt, is er geen enkele reden om netbios paketten rond te sturen, dat is voor bestands- en printerdeling.  Ieder systeem, waaronder NAS e.d., kan deze paketten versturen, een (oude?) Windows PC met gedeelde directories of printers, andere besturingssystemen die samba gebruiken. Maar waarom zou een pure router dat doen? De V10 zonder A is in ieder geval stil op deze poort, Windows 10 ook.  De V10 kondigt zich wel aan op SSDP poort 1900, dat is een nieuwer (multimedia)  systeem waarmee apparatuur zich bekend maakt op het netwerk.

Nee precies heb geen V10A dus kan het niet met zekerheid uitsluiten maar weet wel dat de V10A net als de V10 op USB alleen 4G backup ondersteund dus dat er geen reden is voor Netbios broadcasts.

Maar vraag me dus even af hoe deze melding er staat.  Staat deze als bron x.x.x.254 of als broadcast x.x.x.255

Of staat er überhaupt geen IP bij en kan het dus bij vanalles vandaan komen.


Ik lees iets over een achterliggende firewall. Een 2de router dus?

Maar zelfs bij dubbel NAT kan men vanuit het LAN van de 2e router connectie leggen met het LAN van de Experia Box.

Ja... en? Daar gaat het hier toch niet om?


Het gaat specifiek om SMB. Dat netwerk protocol kan net zo goed vanuit apparaten vanuit het 2e LAN naar apparaten in het LAN van de Experia Box worden aangeroepen. Ofwel meldingen in de Experia Box daarover.


Het gaat specifiek om SMB. Dat netwerk protocol kan net zo goed vanuit apparaten vanuit het 2e LAN naar apparaten in het LAN van de Experia Box worden aangeroepen. Ofwel meldingen in de Experia Box daarover.

Ik vermoed dus dat er helemaal geen apparaten zijn in het eerste LAN. Maar @nogneetmachinaa mag daar eerst zelf wel eens wat meer duidelijkheid over geven.


Hi @nogneetmachinaa, goed om te zien dat er zo veel hulp aangeschoven is in jouw topic! Als je meer informatie kan delen en de gestelde vragen beantwoord, kan de rest verder met je mee denken. We horen het natuurlijk ook graag als je er intussen uit gekomen bent.


Dubbele post => deze verwijderd


Bedankt voor alle reacties. En sorry voor de late reactie/antwoorden.

Er zijn dit deel van het netwerk maar drie stations actief: de EB en twee routers/firewalls.

De EB is ingesteld op dmz-forwarding naar een van die twee: 192.168.2.10 (is tevens VPN-server). De EB zelf is 192.168.2.254. Deze twee IP-adressen zie ik steeds terug bij die UDP-137 pakketjes.

De fw stuurt zijn logs door naar splunk => dat was de trigger voor dit bericht. Een packet analyzer bevestigt dit.

De andere router/firewall (192.168.2.240) handelt het uitgaande verkeer af en is van de buitenkant niet rechtstreeks aan te spreken doordat dmz-forwarding naar de ander wijst.

Er is op dit onderdeel verder geen sprake van poort translatie. Poort translatie wordt wel gebruikt bij VoIP. 

Ik hoop hiermee wat onduidelijkheid weggenomen te hebben.

Suggesties blijven natuurlijk welkom!

 

Met een hartelijke groet - Will


De EB is ingesteld op dmz-forwarding naar een van die twee: 192.168.2.10 (is tevens VPN-server). De EB zelf is 192.168.2.254. Deze twee IP-adressen zie ik steeds terug bij die UDP-137 pakketjes.

Zet die DMZ eens uit, en alleen port forwarding voor services die je daadwerkelijk van buiten af benadert (zoals bijv. VPN). Zou me niet verbazen als die UDP-137 pakketjes dan ophouden.


De EB is ingesteld op dmz-forwarding naar een van die twee: 192.168.2.10 (is tevens VPN-server). De EB zelf is 192.168.2.254. Deze twee IP-adressen zie ik steeds terug bij die UDP-137 pakketjes.

Zet die DMZ eens uit, en alleen port forwarding voor services die je daadwerkelijk van buiten af benadert (zoals bijv. VPN). Zou me niet verbazen als die UDP-137 pakketjes dan ophouden.

 

Allemaal gedaan - zelfde resultaat - zie ook bijgevoegde afbeeldingen.

Misschien nog andere suggesties?

 

=====

 

 

 

 

 


Kun je op de achterliggende router/firewall met IP 192.168.2.10 daarin niet expliciet een firewall regel instellen dat data op poort 137 wordt geblokt, voor uitgaand verkeer?


Dit lijkt me toch duidelijk communicatie tussen Experia box and router, geen broadcast. De Experia V10  toont een mooi overzicht van alle verbonden systemen met IP adres en naam, en voegt de namen toe aan DNS. Geen probleem als de client zich netjes met DHCP aanmeldt en de naam meestuurt. Zou het kunnen zijn dat de V12 probeert de namen  van clients die zich niet met DHCP aanmelden te achterhalen via NETBIOS op poort  137?   Een Windows systeem met bestandsdeling ingeschakeld zal hierop reageren. 


Kun je op de achterliggende router/firewall met IP 192.168.2.10 daarin niet expliciet een firewall regel instellen dat data op poort 137 wordt geblokt, voor uitgaand verkeer?

 

Kun je iets zeggen over het verwachte resultaat?

 

Voor de volledigheid:

Op dit moment is het al zo dat fw met 192.168.2.10 staat ingesteld op het blokken van al het inkomend verkeer (tenzij anders aangegeven) waarbij de initiatief nemer afkomstig is van subnet 192.168.2.0/24 => dus ook de ExperiaBox. Dit is ook terug te vinden in de logging van de firewall (die wordt op zijn beurd weer opgevangen door Splunk).

 


Dit lijkt me toch duidelijk communicatie tussen Experia box and router, geen broadcast. De Experia V10  toont een mooi overzicht van alle verbonden systemen met IP adres en naam, en voegt de namen toe aan DNS. Geen probleem als de client zich netjes met DHCP aanmeldt en de naam meestuurt. Zou het kunnen zijn dat de V12 probeert de namen  van clients die zich niet met DHCP aanmelden te achterhalen via NETBIOS op poort  137?   Een Windows systeem met bestandsdeling ingeschakeld zal hierop reageren. 

 

Misschien alles nog eens teruglezen?

Ik maak gebruik van een EB v10A (dus geen EB v10 of EB v12).

En in het subnet 192.168.2.0/24 zitten geen clients => er zijn enkel 2 fw's en de EB.

Dus nee - voor mij is het geen gewone communicatie als een EB v10A (ogenschijnlijk?) spontaan UDP-137 pakketjes naar een van de twee fw's stuurt.

 


OK, V10a, geen V12. “Gewone” communicatie in die zin dat het geen broadcast is, maar “unicast”  tussen de V10a en de firewall 192.168.2.254 --→ 192.168.2.10.   Iets om met een packet sniffer als wireshark te bekijken, maar ik heb een V10 dus ik kan wat dat betreft niet helpen. Kun je specifiek 137 in de firewall afvangen zonder dat dit gelogged wordt? Dan ben je ervan af…

 

 

 


Kun je op de achterliggende router/firewall met IP 192.168.2.10 daarin niet expliciet een firewall regel instellen dat data op poort 137 wordt geblokt, voor uitgaand verkeer?

Voor de volledigheid:

Op dit moment is het al zo dat fw met 192.168.2.10 staat ingesteld op het blokken van al het inkomend verkeer (tenzij anders aangegeven) waarbij de initiatief nemer afkomstig is van subnet 192.168.2.0/24

Maar dat is niet datgene wat ik voorstel, en staat ook los ervan.
Bij twee routers in een NAT achter NAT opstelling kun je zonder aanvullende instellingen altijd het 1e netwerk bereiken, vanuit dat 2e netwerk. Dus mogelijke aanroepen vanuit dat 2e netwerk m.b.t. Netbios functies (is uitgaand verkeer) kunnen evengoed dat 1e netwerk bereiken en daar reageren op die aanroepen.


Kun je op de achterliggende router/firewall met IP 192.168.2.10 daarin niet expliciet een firewall regel instellen dat data op poort 137 wordt geblokt, voor uitgaand verkeer?

Voor de volledigheid:

Op dit moment is het al zo dat fw met 192.168.2.10 staat ingesteld op het blokken van al het inkomend verkeer (tenzij anders aangegeven) waarbij de initiatief nemer afkomstig is van subnet 192.168.2.0/24

Maar dat is niet datgene wat ik voorstel, en staat ook los ervan.
Bij twee routers in een NAT achter NAT opstelling kun je zonder aanvullende instellingen altijd het 1e netwerk bereiken, vanuit dat 2e netwerk. Dus mogelijke aanroepen vanuit dat 2e netwerk m.b.t. Netbios functies (is uitgaand verkeer) kunnen evengoed dat 1e netwerk bereiken en daar reageren op die aanroepen.

 

Even voor de zekerheid (om verwarring te voorkomen): wat zie je als eerste netwerk?


Het 1e netwerk is dat van de Experia Box, het 2e netwerk de router/firewall die je erachter hebt hangen. Je kunt zonder aanvullende instellingen altijd vanuit het 2e netwerk ook naar het 1e netwerk. Dat is “uitgaand” dataverkeer gezien voor die router/firewall die je achter de Experia Box hebt hangen.


OK, V10a, geen V12. “Gewone” communicatie in die zin dat het geen broadcast is, maar “unicast”  tussen de V10a en de firewall 192.168.2.254 --→ 192.168.2.10.   Iets om met een packet sniffer als wireshark te bekijken, maar ik heb een V10 dus ik kan wat dat betreft niet helpen. Kun je specifiek 137 in de firewall afvangen zonder dat dit gelogged wordt? Dan ben je ervan af…

 

 

 

 

In zoverre… de EB blijft sturen - als ik de aangesloten packet Sniffer mag geloven is het eenzijdig verkeer => alleen de EB stuurt iets => beide routers/firewalls doen er niks mee.