Veel traffic van 1 device

[The Executer]

Probleem: De laatste tijd houd ik mij op het werk wat meer bezig met ons netwerk en heb al succesvol wat puntjes kunnen verhelpen. Een aantal devices die connectie verloren door slechte contacten, slechte Wi-Fi resultaten etc, maar ik loop nu tegen een probleem aan waar ik wat hulp kan gebruiken.

Ik heb 1 apparaat (betreft een security-apparaat) die, in vergelijking met de andere apparaten van dit merk & type, veel data genereert op ons netwerk. Hij blijft de gehele tijd maar communiceren met de server, gemiddeld op een rate van 240Kb/s. Een firmware-update heeft er voor gezorgd dat de traffic wat gedaald is maar nog steeds verstookt hij op deze manier redelijk wat data ten opzichte van de andere appraten (2.4GB vs 2MB (en minder) voor de andere apparaten) waarbij ik mij afvraag of het een netwerk, kabel of apparaat-probleem is.

Reeds gedaan:
- Switch gecontroleerd, device blijft online, snelheid blijft onveranderd, geen TX / RX errors op de poort
- Device gereboot, settings gecontroleerd, firmware geupdate. Deze laatste actie heeft er voor gezorgd dat de traffic van ruim 400+ Kbps naar ± 240Kbps is gezakt.
- Wireshark laten lopen

Nu valt het mij op in de Wireshark dat er flink wat Dup ACK's en retransmissions plaats vinden. Op een capture van 5 minuten zijn er totaal 9624 pakketten gecaptured, Daarvan waren er 1343 Dup ACK's en 3208 (suspected) retransmissions.



Een klein gedeelte van de capture:


Nog niet gedaan:
- Fysieke connectie controleren. Wil ik de connector kunnen checken, zal ik hem even samen met iemand van de technische dienst van de muur moeten schroeven.
- Apparaat vervangen. Last resort, apparaat is ± € 1000 en hebben we momenteel niet op voorraad liggen.

Hebben jullie tips in welke richting ik dit moet gaan zoeken? Op zich is de fysieke connectie een redelijke verdachte aangezien het apparaat in weer en wind hangt, vol op zuiden dus zon en regen. Apparaat is IP67/IK09 uitgevoerd, maar op andere locaties hebben we ook al vochtproblemen gezien. Aan de andere kant, ik zie geen errors op de switch wat mij doet vermoeden dat de fysieke kant gewoon in orde is en het apparaat mogelijk een bug heeft.

[laurens0619]

Is dit niet gewoon funxtionaliteit van het apparat?
Wat is de functie van dat ding?

[Ben(V)]

En wat is het merk/type, niemand hier heeft een glazen bol.

[MasterL]

En zitten deze in hetzelfde subnet (192.168.x.x/?), firewalls/routers kunnen natuurlijk vanalles blokkeren?

[GarBaGe]

Ik zou dit apparaat isoleren van de rest.
Dan heeft de rest er geen kast van,

[The Executer]

laurens0619 schreef op maandag 5 juni 2023 @ 12:28:
Is dit niet gewoon funxtionaliteit van het apparat?
Wat is de functie van dat ding?

Kortgezegd: Nee, dit is geen functionaliteit die hij hoort te hebben. Het apparaat krijgt 1 keer per nacht een synchronisatie met alle gebruikers, waarna het apparaat op zichzelf dient te werken.

De functie van het apparaat valt in de toegangsbeveiliging.

Ben(V) schreef op maandag 5 juni 2023 @ 12:29:
En wat is het merk/type, niemand hier heeft een glazen bol.

Ik wil niet teveel qua beveiliging weggeven, daarom dat ik (bewust) geen merk/type benoem.

MasterL schreef op maandag 5 juni 2023 @ 12:30:
En zitten deze in hetzelfde subnet (192.168.x.x/?), firewalls/routers kunnen natuurlijk vanalles blokkeren?

Nee, het apparaat zit in een specifiek afgeschermd VLAN. Dat is het probleem ook niet, er wordt niets geblokkeerd. Alles werkt gewoon maar het apparaat op zich genereert dermate veel netwerktraffic dat hij opvalt tegenover de rest (Zoals genoemd, het apparaat genereert 2,4GB data per dag, eenzelfde apparaat wordt ook veelvuldig elders gebruikt en genereren <2MB aan data, een factor 1000 meer.

GarBaGe schreef op maandag 5 juni 2023 @ 13:06:
Ik zou dit apparaat isoleren van de rest.
Dan heeft de rest er geen kast van,

Op zich zijn er geen andere apparaten oid wat er last van heeft, maar het genereert continue netwerkverkeer (waaronder retransmissions) wat ik wil zien te voorkomen. Dingen proberen in de hand te houden, ipv het lekker z'n ding laten doen.

[MasterL]

The Executer schreef op maandag 5 juni 2023 @ 14:49:
[...]


Kortgezegd: Nee, dit is geen functionaliteit die hij hoort te hebben. Het apparaat krijgt 1 keer per nacht een synchronisatie met alle gebruikers, waarna het apparaat op zichzelf dient te werken.

De functie van het apparaat valt in de toegangsbeveiliging.


[...]


Ik wil niet teveel qua beveiliging weggeven, daarom dat ik (bewust) geen merk/type benoem.


[...]


Nee, het apparaat zit in een specifiek afgeschermd VLAN. Dat is het probleem ook niet, er wordt niets geblokkeerd. Alles werkt gewoon maar het apparaat op zich genereert dermate veel netwerktraffic dat hij opvalt tegenover de rest (Zoals genoemd, het apparaat genereert 2,4GB data per dag, eenzelfde apparaat wordt ook veelvuldig elders gebruikt en genereren <2MB aan data, een factor 1000 meer.


[...]


Op zich zijn er geen andere apparaten oid wat er last van heeft, maar het genereert continue netwerkverkeer (waaronder retransmissions) wat ik wil zien te voorkomen. Dingen proberen in de hand te houden, ipv het lekker z'n ding laten doen.

Nou oke prima toch? Wat verwacht je van dit topic? De boel zit in 1 L2 domain/subnet/VLAN dus tenzij er switches tussen zitten met ACL's (wat ik niet verwacht) zouden client/server ongehinderd met elkaar moet kunnen communiceren. Netwerktechnisch maakt dit natuurlijk ook helemaal niks uit, 500Mbps zou ook nog geen enkel probleem opleveren. Aangezien je screenshot niet compleet is is het onmogelijk om te bepalen wat het dst address van de packets is, de gateway toevallig? Misshien heeft het device een "call home" functie en probeert daarom vaak verbinding te maken met "het internet". Wellicht heeft het VLAN/subnet geen internet toegang dus blijft het device het proberen?

Succes verder

[Ben(V)]

Beetje vreemd argument om geen merk/type te willen noemen.
Maar hulp zonder info is onmogelijk.
Succes verder.

[Blasterxp]

Ik had een stroommeter die voortdurend 2,4 ghz gebruikt. Daarmee kwam mijn accespoint op wifi 5 &6 mee in de knoeien.
Dus los accespoint voor die band, en nu brult het uitstekend naast elkaar.

Bedoel je niet gewoon een camera? Het is bijzonder vaag dat je een vreemd apparaat in je netwerk hebt die 'beveiliging' doet. Of je uitleg moet beter.

[Han]

Riekt naar een verkeerd geconfigureerd device. Is het geen optie om het device terug te zetten naar default en deze opnieuw in te stellen? Desnoods de configuratie vergelijken met de andere soortgelijke devices op andere lokaties.

[The Executer]

MasterL schreef op maandag 5 juni 2023 @ 15:11:
[...]


Nou oke prima toch? Wat verwacht je van dit topic? De boel zit in 1 L2 domain/subnet/VLAN dus tenzij er switches tussen zitten met ACL's (wat ik niet verwacht) zouden client/server ongehinderd met elkaar moet kunnen communiceren. Netwerktechnisch maakt dit natuurlijk ook helemaal niks uit, 500Mbps zou ook nog geen enkel probleem opleveren. Aangezien je screenshot niet compleet is is het onmogelijk om te bepalen wat het dst address van de packets is, de gateway toevallig? Misshien heeft het device een "call home" functie en probeert daarom vaak verbinding te maken met "het internet". Wellicht heeft het VLAN/subnet geen internet toegang dus blijft het device het proberen?

Succes verder

- Wat ik hoop te bereiken, is een idee in welke richting ik moet zoeken waarom het device zoveel traffic genereert terwijl het apparaat dat niet hoort te doen. ACL's etc zijn niet van toepassing, er hoeft niets geblokkeerd te worden, firewalls zijn niet van toepassing, het probleem is: Het apparaat laat een factor 1000 meer traffic zien dan alle andere apparaten van hetzelfde merk en type. Waardoor zou dit kunnen ontstaan? Is dit een probleem op de fysieke laag (bekabeling)? Is het een bug?

- De source en destination tussen de pakketten is de server en het apparaat, het is rechtstreekse communicatie tussen deze 2.
- Er zitten wel switches tussen, maar andere apparaten op deze locatie tonen niet hetzelfde beeld, dus het ligt mogelijk niet aan de switch op deze locatie.

Ben(V) schreef op maandag 5 juni 2023 @ 15:29:
Beetje vreemd argument om geen merk/type te willen noemen.
Maar hulp zonder info is onmogelijk.
Succes verder.

Blasterxp schreef op maandag 5 juni 2023 @ 15:41:
Ik had een stroommeter die voortdurend 2,4 ghz gebruikt. Daarmee kwam mijn accespoint op wifi 5 &6 mee in de knoeien.
Dus los accespoint voor die band, en nu brult het uitstekend naast elkaar.

Bedoel je niet gewoon een camera? Het is bijzonder vaag dat je een vreemd apparaat in je netwerk hebt die 'beveiliging' doet. Of je uitleg moet beter.

Het betreft hier een fingerprintscanner.

Han schreef op maandag 5 juni 2023 @ 16:07:
Riekt naar een verkeerd geconfigureerd device. Is het geen optie om het device terug te zetten naar default en deze opnieuw in te stellen? Desnoods de configuratie vergelijken met de andere soortgelijke devices op andere lokaties.

Met de firmwareupdate is hij ook compleet gereset geweest. De traffic is met de helft afgenomen maar alsnog communiceert hij de hele dag door, terwijl de andere scanners alleen op het synchronisatiemoment communiceren en verder eigenlijk niet.

Configuratie met de andere scanners heb ik reeds vergeleken, maar niets geks in kunnen ontdekken.

[akimosan]

Het blijft een beetje speculeren zo. Maar goed, aanvullende vragen:
Wat zegt de vendor/leverancier als je hen de vragen stelt en je afwijking doorgeeft?

Vuil /vet op sensor? Zodat het apparaat constant denkt dat er iets te scannen/checken valt? Ook gezien je opmerking dat het apparaat in weer en wind staat.

Het kan "van alles" zijn...

[Han]

The Executer schreef op maandag 5 juni 2023 @ 16:49:
Met de firmwareupdate is hij ook compleet gereset geweest. De traffic is met de helft afgenomen maar alsnog communiceert hij de hele dag door, terwijl de andere scanners alleen op het synchronisatiemoment communiceren en verder eigenlijk niet.

Configuratie met de andere scanners heb ik reeds vergeleken, maar niets geks in kunnen ontdekken.

Dan is de enige mogelijkheid dat het een fout heeft in de hardware, maar dat zou op zich bijzonder zijn. Kan je geen specifieke log van het apparaat posten? Wat doet ie precies? Zijn het allemaal requesten? Stuur iets naar een verkeerd adres? Etc. Etc. Etc.

Wat je zou kunnen doen is een identiek device van een andere locatie omruilen met die ene die dit gedrag vertoond. Dan kan je kijken of het gedrag met het andere device op jouw netwerk het zelfde ongewenste gedrag vertoond. Als dat zo is dan het een security issue op je netwerk… malware?

Vertoond het andere device niet het zelfde gedrag en zie je het gedrag op de andere locatie terugkeren dan is het een issue met het device zelf en moet deze vervangen worden.

[Kabouterplop01]

Het kán een issue zijn op hardware. dus begin de connectie met de switch, de kabel en de netwerkpoorten te checken; misschien is het wel een duplex mismatch.
...Speculatie...

[Josk79]

Bij deze de oplossing. (Vanwege de veiligheid heb ik wat namen vervangen door XXXX)

Ga naar XXXX > XXXX > XXXX > XXXX en zet XXXX op XXXX. Controleer ook XXXX en XXXX.

[The Executer]

Ben(V) schreef op maandag 5 juni 2023 @ 15:29:
Beetje vreemd argument om geen merk/type te willen noemen.
Maar hulp zonder info is onmogelijk.
Succes verder.

Ik snap je reactie, alhoewel ik wat irritatie voel. En nogmaals dat snap ik maar zodra je weet wat voor apparaat er hangt kun je op zoek naar backdoors, het ding reverse engineeren etc. Als je weet in welke subnet het b.v. opereert weet je, zodra je toegang tot het netwerk zou hebben, waar je je pijlen op moet richten etc. Zie het als bescherming van onze beveiliging. Hoe zou jou werkgever het vinden als je alle info m.b.t. tot beveiliging zo open en bloot op internet zet? Daarom de terughoudendheid, ik hoop dat je dit begrijpt.

akimosan schreef op maandag 5 juni 2023 @ 17:16:
Het blijft een beetje speculeren zo. Maar goed, aanvullende vragen:
Wat zegt de vendor/leverancier als je hen de vragen stelt en je afwijking doorgeeft?

Vuil /vet op sensor? Zodat het apparaat constant denkt dat er iets te scannen/checken valt? Ook gezien je opmerking dat het apparaat in weer en wind staat.

Het kan "van alles" zijn...

Thanks voor je reactie. Ticket bij de leverancier staat uit (Sorry, vergeten in TS te zetten), maar op dit vlak verwacht ik daar weinig van aangezien het specifiek om netwerkverkeer gaat.

Vuil / vet zou heel goed kunnen, toevallig hangt deze bij de technische dienst. Echter zou dit niet uit mogen maken. Het apparaat ontvangt 1 keer per 24 uur encrypted al zijn data in 1 keer, deze data wordt encrypted op het apparaat opgeslagen en daarna communiceert het apparaat de rest van de dag niet meer (tenzij ik de logging uit de scanner op ga vragen, handmatig synchroniseer etc). Het is dus 1 bulkactie met netwerkverkeer, daarna kan je zo de stekker eruit trekken en blijft het apparaat gewoon functioneren.

Han schreef op maandag 5 juni 2023 @ 17:34:
[...]

Dan is de enige mogelijkheid dat het een fout heeft in de hardware, maar dat zou op zich bijzonder zijn. Kan je geen specifieke log van het apparaat posten? Wat doet ie precies? Zijn het allemaal requesten? Stuur iets naar een verkeerd adres? Etc. Etc. Etc.

Ik zou wel een of meerdere blokken info uit de Wireshark kunnen posten, maar kunnen we daar wat mee als dit encrypted (SSL) over en weer gaat? Volgens mij is er dan niets van te lezen toch? De log in het systeem/fingerprintscanner laat verder niets bijzonders zien gek genoeg.

Wat je zou kunnen doen is een identiek device van een andere locatie omruilen met die ene die dit gedrag vertoond. Dan kan je kijken of het gedrag met het andere device op jouw netwerk het zelfde ongewenste gedrag vertoond. Als dat zo is dan het een security issue op je netwerk… malware?

Nou, dat laatste puntje is ook waar ik dus bang voor ben. Aan de andere kant, in de capture is te zien dat het apparaat alleen naar de server communiceert, en de server communiceert terug. Thats it, ik zie geen verkeer buiten het subnet of buiten ons LAN gaan, het is continue traffic tussen de server en de fingerprintscanner. Wel zie ik dus een hele hoop retransmissions, oftewel, er gaan onderweg pakketten verloren.

Vertoond het andere device niet het zelfde gedrag en zie je het gedrag op de andere locatie terugkeren dan is het een issue met het device zelf en moet deze vervangen worden.

Ik kan helaas niet ergens anders een scanner wegtrekken, want elke ingang is veelgebruikt. Een deur open laten staan ten tijde van testen is niet toegestaan ivm de veiligheid binnen het bedrijf. Misschien dat ik specifiek deze even tijdelijk op mijn bureau kan plaatsen, aangezien deze op een plek zit die voor buitenstaanders minder voor de hand liggend is en ongewenste bezoekers binnen de kortste keren op de camera's naar voren komt en ook fysiek genoeg personeel rondloopt op die locatie om ze weg te kunnen sturen. Dan is deze deur tijdelijk even buiten gebruik.

[akimosan]

Het apparaat ontvangt 1 keer per 24 uur encrypted al zijn data in 1 keer, deze data wordt encrypted op het apparaat opgeslagen en daarna communiceert het apparaat de rest van de dag niet meer (tenzij ik de logging uit de scanner op ga vragen, handmatig synchroniseer etc).

Met zoiets ga ik dan denken aan één of andere (verbose) logging / diagnostische modus die wellicht voor of na de firmware update is ingeschakeld? Zelf ook al een handleiding van het apparaat opgesnord?

[x86dev]

Ben(V) schreef op maandag 5 juni 2023 @ 12:29:
En wat is het merk/type, niemand hier heeft een glazen bol.

Waarschijnlijk gebruikt hij BioStar. Grappig om dat niet mee te geven vanwege "beveiliging".

[Blasterxp]

Wat doet de server? Draait daar een service op? Kun je daar eens op inzoomen?
Als het apparaat identiek is met de rest, wellicht gaat de communicatie aan de andere kant mis.

[MasterL]

Ik vind het wel een apart "probleem", hoe zit het met eventuele uplinks of zit alles in 1 switch?
Het zou ook zo iets simpels kunnen zijn als een overbelaste link bijvoorbeeld (packet loss).

[The Executer]

akimosan schreef op maandag 5 juni 2023 @ 20:57:
[...]


Met zoiets ga ik dan denken aan één of andere (verbose) logging / diagnostische modus die wellicht voor of na de firmware update is ingeschakeld? Zelf ook al een handleiding van het apparaat opgesnord?

Ik heb zojuist contact gehad met de leverancier. We hebben alle instellingen doorgelopen, maar ook zij zien geen reden waarom het apparaat continue data loopt te versturen. Ik heb nog even gechecked, de data gaat voornamelijk van de scanner naar de server, andersom is er praktisch geen data (2.45GB van scanner naar server vs 33MB van server naar scanner).

Leverancier weet het ook niet, deze gaat nu bij de fabrikant een ticket inschieten.

Blasterxp schreef op dinsdag 6 juni 2023 @ 10:08:
Wat doet de server? Draait daar een service op? Kun je daar eens op inzoomen?
Als het apparaat identiek is met de rest, wellicht gaat de communicatie aan de andere kant mis.

Daar draait inderdaad een service op, maar die communiceert maar 1 maal per dag, verder vind er zoals aangegeven geen communicatie plaats tenzij ik logging op ga vragen.

MasterL schreef op dinsdag 6 juni 2023 @ 10:30:
Ik vind het wel een apart "probleem", hoe zit het met eventuele uplinks of zit alles in 1 switch?
Het zou ook zo iets simpels kunnen zijn als een overbelaste link bijvoorbeeld (packet loss).

Op deze locatie zit ook nog een andere scanner van hetzelfde type, op dezelfde switch, op dezelfde uplink naar het hoofdkantoor. Onze uplinks worden gemonitord en gedragen zich verder normaal.

---

Vanmiddag (als er geen storingen in de fabriek zijn) ga ik samen met de TD de fysieke verbinding checken.

[jadjong]

Is deze unit als enige soms ingesteld als lezer voor het inlezen van nieuwe vingers?

[The Executer]

jadjong schreef op dinsdag 6 juni 2023 @ 19:57:
Is deze unit als enige soms ingesteld als lezer voor het inlezen van nieuwe vingers?

Nee, inlezen gebeurt niet middels de fingerprintscanners bij de deuren, dit gebeurt middels lokale lezers bij de PC.

Vandaag helaas geen tijd gehad om de scanner los te schroeven, kwamen helaas andere issues tussendoor. Wel lopen we tegen een nieuw probleem aan: De scanners (zijn er 2) welke op een nieuwere firmware-versie draaien dan de grote groep lijken af en toe te... flippen. Ze geven aan dat de fingerprint toegang zou moeten krijgen, maar bedienen niet meer het relais. Onduidelijk of dit een firmware-dingetje is, de scanners met oudere software blijven gewoon normaal functioneren. Ticket bij de leverancier wordt vervolgd, hier lijkt meer te spelen.

[jadjong]

Welk relais? Het interne of eentje via RS485/IP?

[The Executer]

jadjong schreef op dinsdag 6 juni 2023 @ 20:16:
Welk relais? Het interne of eentje via RS485/IP?

Geen idee, dat is meer een vraag voor mijn collega's van TD . Je hebt een idee wat het zou kunnen zijn?

[jadjong]

The Executer schreef op dinsdag 6 juni 2023 @ 20:19:
[...]


Geen idee, dat is meer een vraag voor mijn collega's van TD . Je hebt een idee wat het zou kunnen zijn?

https://support.supremain...ebooting-of-the-device-af

https://support.supremain...shown-a-different-version

Mogelijk zoiets.

Als het interne relais faalt zou ik alle scanners van de muur trekken en de installateur dagvaarden.

[ Voor 8% gewijzigd door jadjong op 06-06-2023 20:35 ]

[Kabouterplop01]

Ben benieuwd of je nog iets aan de portinstellingen hebt kunnen vinden, of de counters op de port.
(Ik hoop dat het daar ergens te vinden is, tussen de scanner en de port op de switch)

Edit: Troubleshooting begint op Layer 1 des OSI's

[ Voor 13% gewijzigd door Kabouterplop01 op 06-06-2023 20:40 ]