Mysterieus netwerkverkeer

[YellowOnline]

Eigenlijk hoort dit zowel hier als in Windows Client thuis...

Gisteren bracht het netwerkteam de sysadmins op de hoogte van een probleem, nl. 1000en clients die een gekke query naar de DNS sturen: "SERVER*"

Wij hebben gezocht naar scripts of scheduled tasks op de clients waar dit gedrag zich voordoet en niets gevonden. Volgende stap: Wireshark en NetMon, parallel met ProcMon en TCPView.

Resultaat: we zien de query, maar er zit geen patroon in wanneer hij voorkomt en we weten nog steeds niet wat het precies veroorzaakt. De NetMon output ziet er als volgt uit (enkel relevante zaken en fictieve IPs/namens)

code:

ProcID  Source      Destination Protocol    Description
0x4     10.1.1.5    10.1.1.255  NbtNs       NbtNs:Query Request for SERVER*  <0x20> File Server Service

Formatting beetje naar de vaantjes

0x4 is de Process ID van de SYSTEM account. We krijgen geen process te zien maar gewoon de SYSTEM account. Er is ook geen enkele correlatie met ProcMon rond dezelfde timestamp - tot onze verwondering.

Na een halve dag zoeken weten wij niet meer hoe te weten te komen welke applicatie deze request de wereld instuurt. Als iemand een idee heeft, dan hoor ik het graag!

[ Voor 6% gewijzigd door YellowOnline op 13-09-2013 13:59 ]

[Equator]

Is er niet een gekke applicatie gedistribueerd die niet goed geconfigureerd is?

/farfetched..

Stel eens op een enkele client een host entry in voor "server" naar een ip adres van een aparte machine. Kijk eens wat voor verkeer er verstuurd wordt naar die doos.

[YellowOnline]

Equator schreef op vrijdag 13 september 2013 @ 14:07:
Is er niet een gekke applicatie gedistribueerd die niet goed geconfigureerd is?

/farfetched..

Helemaal niet zo far fetched. We hebben 800 applicaties of zo (exe, msi & App-V), zonder rekening te houden met verschillende versies en scripts. Een gekke applicatie die niet goed geconfigureerd is, is dus net wat we proberen uitzoeken.

Stel eens op een enkele client een host entry in voor "server" naar een ip adres van een aparte machine. Kijk eens wat voor verkeer er verstuurd wordt naar die doos.

We hadden de traffiek al doorgestuurd om meer informatie terug te krijgen (die niet hielp), maar nu hebben we ook monitoring aan de andere kant gezet. Nu wachten op de query... het is volledig random en kan een anderhalf uur niet opduiken en dan 10 keer op 5 minuten tijd. Zucht.

[ Voor 7% gewijzigd door YellowOnline op 13-09-2013 14:22 ]

[ShadowBumble]

nbts is volgens mij NetBios over TCP/IP wat ik "vreemd vind" is dat dit gestuurd word naar ogenschijnlijk een broadcast adres wat dus inhoud dat iets of iemand constant een netbios discovery aan het doen is.


Als je het packetje onderschept met wireshark zie je dan de volgende transaction id "x1337" zo ja da is er iemand fanatiek bezig met nmap om exploits te zoeken. Netbios zit er namelijk vol mee.

[ Voor 32% gewijzigd door ShadowBumble op 13-09-2013 14:26 ]

[Equator]

Fictieve IP's. Inderdaad slecht gekozen Overigens is niet alles wat eindigt op 255 een broadcast adres.

[YellowOnline]

(de .255 is niet fictief)

[Gitano]

http://social.technet.mic...y-for-file-server-service

Komt een beetje in de buurt .. in de link hebben ze het over evt. een netwerk printer(s)

[Equator]

YellowOnline schreef op vrijdag 13 september 2013 @ 14:38:
(de .255 is niet fictief)

Maar is het een broadcast adres?

[ShadowBumble]

Equator schreef op vrijdag 13 september 2013 @ 14:35:
Fictieve IP's. Inderdaad slecht gekozen Overigens is niet alles wat eindigt op 255 een broadcast adres.

Mensen hebben de akelige gewoonte bij fictieve ip's de laatste octet wel intact te laten Dit wil niet zeggen dat het inderdaad dan maar een broadcast is, dat hangt helemaal van het subnet af, vandaar ook de ogenschijnlijke.

Hoe dan ook als jullie gesnifferd hebben copy paste eens de inhoud van de specifieke NBST packetjes hier daar kunnen we iets meer mee zeg maar.

[YellowOnline]

Gitano schreef op vrijdag 13 september 2013 @ 14:40:
http://social.technet.mic...y-for-file-server-service

Komt een beetje in de buurt .. in de link hebben ze het over evt. een netwerk printer(s)

Artikel had ik al gelezen. Niet echt relevant imho.

Equator schreef op vrijdag 13 september 2013 @ 14:41:
[...]

Maar is het een broadcast adres?

Jazeker. Maar dat Netbios naar een broadcast gaat is toch normaal?

[Equator]

Ik zie dat Chrome ook vreemde dingen kan doen..

http://productforums.goog...!topic/chrome/ffbKaGMEu50

YellowOnline schreef op vrijdag 13 september 2013 @ 14:44:
[...]
Jazeker. Maar dat Netbios naar een broadcast gaat is toch normaal?

Ansich niet, het is de laatste stap van nameresolution. Gewoon hard schreeuwen en hopen dat er iemand reageert. Maar in je startpost heb je het over verkeer naar je DNS server. Daarom ging ik er vanuit dat het ip gefingeerd was

[ Voor 65% gewijzigd door Equator op 13-09-2013 14:46 ]

[ShadowBumble]

Equator schreef op vrijdag 13 september 2013 @ 14:44:
Ik zie dat Chrome ook vreemde dingen kan doen..

http://productforums.goog...!topic/chrome/ffbKaGMEu50

Past ook niet echt in het probleem beeld als ik eerlijk ben als jij 800 applicaties hebt dan zit je niet met maar 40 werknemers maar een heel stuk meer de kans dat je dat spontaan 90 minuten geen requests hebt, lijkt me onwaarschijnlijk want dat er _NIEMAND_ gedurende 90 minuten Chrome dan gebruikt is extreem klein en te verwaarlozen.

[YellowOnline]

Equator schreef op vrijdag 13 september 2013 @ 14:44:
Ik zie dat Chrome ook vreemde dingen kan doen..

http://productforums.goog...!topic/chrome/ffbKaGMEu50

Had ik ook al gelezen. Ik heb de plugins van IE met PE Explorer gedisassembled en niets gevonden dat dit gedrag kan veroorzaken. Chrome en FireFox (waar gelijkaardige issues zijn als bij Chrome) staan er niet op.

[Equator]

ShadowBumble schreef op vrijdag 13 september 2013 @ 14:47:
[...]


Past ook niet echt in het probleem beeld als ik eerlijk ben als jij 800 applicaties hebt dan zit je niet met maar 40 werknemers maar een heel stuk meer de kans dat je dat spontaan 90 minuten geen requests hebt, lijkt me onwaarschijnlijk want dat er _NIEMAND_ gedurende 90 minuten Chrome dan gebruikt is extreem klein en te verwaarlozen.

Ik denk alleen maar mee Overigens kan deze applicaties alleen voor bepaalde noodzaak gebruikt worden.

[YellowOnline]

ShadowBumble schreef op vrijdag 13 september 2013 @ 14:47:
[...]


Past ook niet echt in het probleem beeld als ik eerlijk ben als jij 800 applicaties hebt dan zit je niet met maar 40 werknemers maar een heel stuk meer de kans dat je dat spontaan 90 minuten geen requests hebt, lijkt me onwaarschijnlijk want dat er _NIEMAND_ gedurende 90 minuten Chrome dan gebruikt is extreem klein en te verwaarlozen.

25 000 gebruikers, maar ik kan niet zomaar op alle PCs waar dit gedrag zich voordoet een sniffing tool installeren en wachten op hits... . Oh, en we gebruiken geen Chrome en dit probleem doet zich voor in 4 verschillende domeinen.

[ShadowBumble]

YellowOnline schreef op vrijdag 13 september 2013 @ 14:50:
[...]


25 000 gebruikers, maar ik kan niet zomaar op alle PCs waar dit gedrag zich voordoet een sniffing tool installeren en wachten op hits... . Oh, en we gebruiken geen Chrome en dit probleem doet zich voor in 4 verschillende domeinen.

File Server(SAN oplossing dus ) actief in alle 4 de domeinen ?

[YellowOnline]

ShadowBumble schreef op vrijdag 13 september 2013 @ 14:51:
[...]


File Server(SAN oplossing dus ) actief in alle 4 de domeinen ?

Euh, in realiteit zijn er nog veel meer domeinen en zo ongeveer elke vorm van storage bestaat hier. Maar relevant hier: de servers waar de query naar verwijst zijn fileservers op ESX infrastructuur waar een of andere HP EVA aan hangt. Met de hardwarekant houd ik me wel niet bezig.

(met netwerk evenmin trouwens, ik ben System Center specialist, maar men moet wat flexibel zijn)

Het interessante is dat de query in domeinen is waar de server nooit gevonden gaat worden, aangezien die in een ander domein zit. Om dit wat beter uit te leggen:

• DOMAIN1 bevat SERVER1, SERVER2, SERVER3 (het zijn er 350 of zo in realiteit)
• Een aantal clients uit DOMAIN2, DOMAIN3, DOMAIN4, DOMAIN5 doen een query naar "SERVER*"

Aan de kant van de server waar we het verkeer doorstuurde is trouwens weinig te zien dat we nog niet zagen aan de kant van de client:

[ Voor 45% gewijzigd door YellowOnline op 13-09-2013 15:15 ]

[Quadradial]

YellowOnline schreef op vrijdag 13 september 2013 @ 14:59:
[...]


Euh, in realiteit zijn er nog veel meer domeinen en zo ongeveer elke vorm van storage bestaat hier. Maar relevant hier: de servers waar de query naar verwijst zijn fileservers op ESX infrastructuur waar een of andere HP EVA aan hangt. Met de hardwarekant houd ik me wel niet bezig.

(met netwerk evenmin trouwens, ik ben System Center specialist, maar men moet wat flexibel zijn)

Het interessante is dat de query in domeinen is waar de server nooit gevonden gaat worden, aangezien die in een ander domein zit. Om dit wat beter uit te leggen:

• DOMAIN1 bevat SERVER1, SERVER2, SERVER3 (het zijn er 350 of zo in realiteit)
• Een aantal clients uit DOMAIN2, DOMAIN3, DOMAIN4, DOMAIN5 doen een query naar "SERVER*"

Wat is een aantal? 10? 100? 1000? IT IS OVER 9000!!!!
Als het serieus 10 - 20 machines zijn die geen netbios nodig hebben... gewoon uitzetten die handel.

Enne de link http://social.technet.mic...y-for-file-server-service

daar staat nog een heel mooi ander linkje in namelijk:
http://blogs.msmvps.com/acefekay/2013/03/02/do-i-need-netbios/
Hier staat in jip en janneke taal hoe en wat met NetBIOS werkt en helpt jou in de juiste richting te zoeken met een aantal voorbeelden.

[ Voor 3% gewijzigd door Quadradial op 13-09-2013 15:23 ]

[YellowOnline]

Quadradial schreef op vrijdag 13 september 2013 @ 15:21:
[...]


Wat is een aantal? 10? 100? 1000? IT IS OVER 9000!!!!
Als het serieus 10 - 20 machines zijn die geen netbios nodig hebben... gewoon uitzetten die handel.

Een paar duizend. Hoeveel exact zou ik aan Belgacom moeten vragen en dat antwoord heb ik niet vandaag meer.

Enne de link http://social.technet.mic...y-for-file-server-service

daar staat nog een heel mooi ander linkje in namelijk:
http://blogs.msmvps.com/acefekay/2013/03/02/do-i-need-netbios/
Hier staat in jip en janneke taal hoe en wat met NetBIOS werkt en helpt jou in de juiste richting te zoeken met een aantal voorbeelden.

Zoals gezegd heb ik die link gelezen en zie ik er de relevantie niet van in: het afschaffen van Netbios is niet aan de orde. Ten eerste omdat dit niet in mijn bevoegdheid ligt, ten tweede omdat ons Windowspark bestaat uit alle versies Windows vanaf 2000 (de 95 en 98 zijn eindelijk uitgeroeid).

(We hebben ook nog een collectie redhat, bsd, solaris, suse, debian, etc. in verschillende generaties, maar die spelen niet mee in het verhaal hier en worden sowieso afgeschaft)

De bewuste frame als XML: http://pastebin.com/qRfDxEw2. Niet dat ik denk dat iemand daar veel wijzer van wordt.

[ Voor 3% gewijzigd door YellowOnline op 13-09-2013 15:57 ]

[Brahiewahiewa]

YellowOnline schreef op vrijdag 13 september 2013 @ 14:59:...Om dit wat beter uit te leggen:

• DOMAIN1 bevat SERVER1, SERVER2, SERVER3 (het zijn er 350 of zo in realiteit)
• Een aantal clients uit DOMAIN2, DOMAIN3, DOMAIN4, DOMAIN5 doen een query naar "SERVER*"

...

Kun je het aantal kandidaten voor het zich slecht gedragende programma, op basis van de source domains reduceren? En draait er op "SERVER" iets wat 't gedraag zou kunnen verklaren?

Verder zijn de frames gewoon de laatste stappen van het windows name-resolution proces. Of het daadwerkelijk de laatste stap is, hangt af van de nodeType parameter die DHCP meegeeft. 't Is dus inderdaad een broadcast en alleen netBios browse-masters worden geacht er op te antwoorden.
Als je nog WINS servers in je omgeving hebt staan (moet haast wel), kun je overwegen om een WINS record voor "SERVER" aan te maken. Dan ben je naar alle waarschijnlijkheid van de broadcasts af

Overigens hanteer ik in deze client side gevallen de regel: "Eerst kijken of het niet de virusscanner is"
Dat leidt dermate vaak tot succes, dat je de regel niet kunt negeren ;o)

[ Voor 18% gewijzigd door Brahiewahiewa op 13-09-2013 16:41 ]

[Remco]

Equator schreef op vrijdag 13 september 2013 @ 14:41:
[...]

Maar is het een broadcast adres?

Beetje offtopic, maar dat hangt van het gebruikte subnet af. Aangezien de ts geen subnet heeft opgegeven (of ik heb het gemist...) kan je niet concluderen dat het een broadcast adres is.

[Craven]

Remco schreef op vrijdag 13 september 2013 @ 19:24:
[...]

Beetje offtopic, maar dat hangt van het gebruikte subnet af. Aangezien de ts geen subnet heeft opgegeven (of ik heb het gemist...) kan je niet concluderen dat het een broadcast adres is.

Daarom stelt hij toch ook de vraag?

---

Aangezien je system center specialist bent gaat het hier neem ik aan om machines die jij hebt uitgerold vanuit SCCM? Zo ja, kun je het probleem reproduceren? Als in: is er een machine config die altijd dit gedrag vertoont (in meer of mindere mate)? If also yes, waarom rol je niet een machine uit stukje voor stukje? Kijken vanaf wanneer de machine in kwestie dit gedrag gaat vertonen?

Edit: kan het netwerkteam trouwens ook aangeven wanneer dit issue is begonnen? If so, changelijst o.i.d. even doorspitten rond die tijd. Geeft je al wat meer houvast om specifieker te kijken.

[ Voor 11% gewijzigd door Craven op 13-09-2013 19:34 ]

[YellowOnline]

Brahiewahiewa schreef op vrijdag 13 september 2013 @ 16:34:
[...]
Kun je het aantal kandidaten voor het zich slecht gedragende programma, op basis van de source domains reduceren? En draait er op "SERVER" iets wat 't gedraag zou kunnen verklaren?

Verder zijn de frames gewoon de laatste stappen van het windows name-resolution proces. Of het daadwerkelijk de laatste stap is, hangt af van de nodeType parameter die DHCP meegeeft. 't Is dus inderdaad een broadcast en alleen netBios browse-masters worden geacht er op te antwoorden.
Als je nog WINS servers in je omgeving hebt staan (moet haast wel), kun je overwegen om een WINS record voor "SERVER" aan te maken. Dan ben je naar alle waarschijnlijkheid van de broadcasts af

Overigens hanteer ik in deze client side gevallen de regel: "Eerst kijken of het niet de virusscanner is"
Dat leidt dermate vaak tot succes, dat je de regel niet kunt negeren ;o)

Tot ergernis van onze AV-man is McAfee altijd de eerste naar wie we wijzen bij problemen Het enige dat bij hem in de buurt komt van zo'n query is een exclusion list, maar de query is toch voldoende anders dan diegene die rondgestuurd wordt. Desalniettemin: ik hou nog steeds voor mogelijk dat het McAfee is, maar bewijs heb ik nog niet gevonden.

Craven schreef op vrijdag 13 september 2013 @ 19:33:
[...]

Daarom stelt hij toch ook de vraag?

---

Aangezien je system center specialist bent gaat het hier neem ik aan om machines die jij hebt uitgerold vanuit SCCM? Zo ja, kun je het probleem reproduceren? Als in: is er een machine config die altijd dit gedrag vertoont (in meer of mindere mate)? If also yes, waarom rol je niet een machine uit stukje voor stukje? Kijken vanaf wanneer de machine in kwestie dit gedrag gaat vertonen?

Edit: kan het netwerkteam trouwens ook aangeven wanneer dit issue is begonnen? If so, changelijst o.i.d. even doorspitten rond die tijd. Geeft je al wat meer houvast om specifieker te kijken.

Het is enkel op de machines in het oude domein die niet via SCCM uitgerold zijn (en die machines zijn allemaal pre-Win7 trouwens). In het nieuwe domein stelt het probleem zich niet.

Veel onderzoek kan ik vandaag niet doen. Ben wel aan het werk, maar enkel sysadmins zijn hier voor quarterly serverupdates en ik voor een SCOM 2007 -> SCOM 2012 migratie. Dat network issue moet wachten tot maandag de netwerkmannen terug zijn.