Internet of Things

[dirklammers]

Op het gevaar af dat dit onderwerp nét iets te ver af staat van Synology en dus verwijderd wordt door de moderators trap ik toch een nieuwe discussie af.

Sinds kort ben ik enthousiast gebruiker van een RT2600AC. Dankzij ondersteuning van Babylonia draait het ding inmiddels stabiel en kan ik 4 verschillende netwerken gebruiken.
Eén van die netwerken (VLAN) is een IoT netwerk. Maar wélke "things" kan ik hier nu het beste op zetten?

Inmiddels heb ik er al op draaien de twee Daikin airco units en de KaKu bridge. Die dingen staan alle drie in contact met hun "thuis-server" en lijken me dus gevoelig voor misbruik als iemand de KaKa- of Daikin-server kraakt.

Maar wat nog meer? Tijdens vakanties heb ik twee Dahua camera's gekoppeld staan aan Synology Surveillance station zodat ik af en toe eens een blik kan werpen thuis.
Die dingen staan gewoon via WiFi in mijn "standaard"-netwerk om de NAS te kunnen bereiken. Ze blijven dus geheel "intern". Ook een risico?
Mijn Philips TV. Zal af en toe wel eens "naar huis bellen" om te kijken of er een update is. Ook een risico?

SONOS-units ? Risico?

Kortom, help me eens mijn risico's te detecteren zodat ik die òf in de firewall òf via een eigen netwerk kan beheersen.

Groet, Dirk

[Plerry]

Ik heb mijn Sonos, TV, AV-receiver, BlueRay speler, Nest thermostaat+rookmelders+deurbel, Google home display, Hue bridge, beveiligings camera's, inbraakalarm en mijn zonnepanelen allemaal op mijn IOT netwerk zitten; deels bedraad, deels via Wifi.
In principe alle netwerk-verbonden spullen met software waar je meestal zelf weinig controle over hebt.

Enige implicatie is dat als je vanaf apps op je mobiele telefoon wil kunnen streamen naar je TV, die mobieltje ook met je IOT netwerk
moeten zijn verbonden.
Dat vormt voor ons zelden een probleem.
Moeten de mobieltjes onverhoeds toch een keer met het hoofdnetwerk verbinden (met NAS of printer), dan doen we dat via een VPN verbinding naar het hoofdnetwerk. Maar daarvoor zijn ook andere oplossingen mogelijk.

[Babylonia]

Nu ja, tegenwoordig verzamelt elk bedrijf wel op een of andere manier data.
Dus bij connecties naar buiten zal dat al snel gebeuren, met name je eigen "internet surfgedrag", via allerlei cookies - en tracking van data.

Daarnaast bedrijven die een server runnen m.b.t. die IoT  apparaten.
Mag je "hopen" dat het alleen betrekking heeft op die apparaten, en of het zinvol is data te verzamelen voor die bedrijven.
Dus een Philips TV, voor een update van firmware is dat niet zo erg.
Maar of men daarbij ook data verzamelt van bijv. de SMART functies van die TV met daarop geïnstalleerde apps is een vraag.

Voor wat betreft die Dahua Surveillance camera's, is daar eerder al ophef over geweest.
https://nos.nl/artikel/2416279-omstreden-chinese-camera-s-hangen-overal-in-nederland-ook-bij-ministeries

Via  "Verkeersbeheer"  een functie van de Synology router, is "globaal" per apparaat logdata te verzamelen.
Met welke domeinen / URL's die apparaten contact leggen en de hoeveelheid data.
Zie een korte weergave van die functies op het Engelstalige Synology forum (reactie enkele jaren terug):
https://community.synology.com/enu/forum/2/post/124384?reply=423797

Zo kwam ik er bijv. ook achter dat  KPN IPTV functies  in het geval dat je de eigen KPN router gebruikt (Experia Box),
daarin automatisch ook enkele Port Forwarders vast legt voor de door KPN gebruikte apparaten.
In mijn geval een enkele port forwarder voor de TV-ontvanger.

Heb de port forwarder ook wel eens als test in mijn Synology router vastgelegd, en "zo nu en dan" getraceerd,
dat de KPN TV-ontvanger connectie legt via die port forwarder "Firewall regel" buiten het KPN domein om (zelfs buitenland).
Heb die port forwarder in ieder geval in mijn eigen router weer verwijderd. (Voor update firmware KPN TV-ontvanger niet nodig).


Verder heeft een Synology router nog een extra pakket "Threat Prevention", dat data op packet niveau controleert.
Die traceert dubieuze data pakketjes.  Maar dat kost de nodige extra CPU, snel extern USB geheugen.
En de nodige aanvullende instellingen om daar goed gebruik van te kunnen maken.
Heb daar vroeger op een RT1900ac wel mee geëxperimenteerd, maar door de hoge CPU load (met die router), er weer vanaf gehaald.
Daarna ook niet meer opnieuw in gebruik genomen bij nieuwere Synology router modellen (Gebruik ikzelf dus niet).
https://www.synology.com/nl-nl/srm/feature/secure_network_foundation
https://kb.synology.com/nl-nl/SRM/help/ThreatPrevention/threatprevention_desc?version=1_3

Op het Engelstalige Synology forum is er meer over te vinden.


Afgezien van die eerdere berichten m.b.t. veiligheid van Dahua Surveillance camera's.

Tijdens vakanties heb ik twee Dahua camera's gekoppeld staan aan Synology Surveillance station zodat ik af en toe eens een blik kan werpen thuis.
Die dingen staan gewoon via WiFi in mijn "standaard"-netwerk om de NAS te kunnen bereiken. Ze blijven dus geheel "intern". Ook een risico?

Meerdere opties mogelijk:
Je kunt de loggegevens "per apparaat" zoals eerder genoemd eerst eens bestuderen of het nodig is.
Maar voor elk apparaat met vast IP-adres, zou je een Firewall regel kunnen aanmaken die geen dataverkeer naar buiten toestaat.
Via VPN kun je echter toch die camera benaderen of in de NAS opgenomen beelden via Surveillance station bekijken.

Heb je "veel" apparaten die niet naar buiten toe mogen communiceren, kun je daarvoor nog een extra "intern gesloten" IoT netwerk aanmaken.
De NAS verbind je via een managed switch tevens met een van de extra LAN poorten die je NAS apparaten hebben "op dat andere IoT netwerk".
De NAS is via zo'n intern gesloten netwerk via VPN te benaderen (of zelf op dat netwerk inloggen),
of via het Primair netwerk waarmee de NAS'sen ook zijn aangesloten.

Je kunt nogal wat kanten uit. 

[dirklammers]

Beiden opnieuw bedankt voor jullie reacties. Er gaan weer werelden voor mij open en ik ga e.e.a. eens goed bestuderen.
Eén ding valt me gelijk wel op:
Ik zie een aantal MAC-adressen "iets" downloaden"; zie meegestuurde afbeelding b.v. 01:00:5e:03:02:06.
Dat MAC-adres kom ik nergens op mijn netwerk tegen althans niet bij de apparaten die genoemd worden in de router.
Kennelijk zijn er apparaten actief of hebben apparaten meerdere MAC-adressen die dingen staan te downloaden die niet direct te zien zijn via hun "eigen" MAC-adres.
Ik druk me wat ongelukkig uit, maar misschien is de vraag wel duidelijk.... Wat gebeurt hier?

Groet, Dirk

[Birdy]

01:00:5e:03:02:06 opgezocht en is een onbekend (vendor) mac adres.

[Pippin]

Het is multicast:
https://networklessons.com/multicast/introduction-to-multicast

Omgerekend, 224.3.2.6

[dirklammers]

Dank Pippin, dat is hem 
Ik leer toch elke dag weer wat zeg. Leuk hoor.
Groet, Dirk

[Briolet]

Pippin,  ik had even niet door dat dit een aantal pagina's met lessen was.  Het verhaal over de MAC adressen staat 2 lessen verder. https://networklessons.com/multicast/multicast-ip-address-to-mac-address-mapping

Het was nieuw voor me dat de eerste 3 oktets de waarde "01-00-5E" gereserveerd heeft voor Multicast. Die had eigenlijk in een vendor lijst moeten staan.  Vendors krijgen 3 tot 5 oktets toegewezen bij registratie. Maar als ik twee mac-vendor lijsten raadpleeg krijg ik net als Birdy de melding onbekend.

[Pippin]

@Briolet,

Ja, ik was wat kort.

Die had eigenlijk in een vendor lijst moeten staan.

Ik denk dat je het het beste kunt vergelijken met class A, B en C.
Er is ook nog class D en E.
Deze zijn gereserveerd voor private netwerken, dat zal je bekend zijn.
Voor die reeksen zal een whois ook geen resultaat opleveren (anders dan "Allocated Unspecified", "ga lezen bij IANA").

Bovenstaande zijn IP reeksen en IP is werkzaam op laag 3.
MAC adressen zijn werkzaam op laag 2.
Ook daar is blijkbaar een deel gereserveerd.
In dit geval gaat het over multicast, dat blijkbaar werkt op laag 2 en 3.
Zoals ik het begrijp vindt er een vertaalslag plaats tussen MAC en IP, en die IP adressen zitten dan weer in het class D netwerk.
Nu weet ik wel dat class D voor multicast gebruikt wordt maar niet dat er een vertaalslag plaatsvindt.

Zoals je inmiddels zult begrijpen is dit ook nieuw voor mij.
Learn as we go

@dirklammers
Kans is groot dat het met IPTV of een apparaat dat streaming doet (audio/video) te maken heeft.

[Babylonia]

Klopt.  Betreffen de multicast streams van KPN IPTV  - Vergelijkbaar ook hier adressen met  01:00:5e:x:x:x  notatie.
KPN IPTV wordt via IGMP Proxy op alle LAN poorten van de router aangeboden. (@dirklammers heeft ook KPN internet met IPTV).

1. Bij  Live TV  (glasvezel) - kanaal 661 een strakke stream van 1,7 MegaByte/s  (omgerekend 13,6 Megabit/s)
2. Bij wisselen / zappen van TV kanaal  (lagere kwaliteit) --->  ~875 KiloByte/s  (omgerekend   7    Megabit/s)
3. Nog eens wisselen naar ander TV kanaal
4. Als je programma's gaat terugkijken, wordt de stream "Unicast"
    en zie je de download verplaatsen naar de TV-ontvanger (Arcadyan HMB2260)

1.         2.         3.         4.

[dirklammers]

Voordat ik mijn volgende vraag stel (zucht) wil ik jullie toch eerst maar eens bedanken hoor. Sinds de aanschaf van de Synology router zo'n vier weken geleden heb ik meer over netwerken geleerd dan heel mijn leven ervoor. Geweldig! Maar zoals met meer dingen in het leven: hoe meer je weet hoe meer je ontdekt dat je nog veel meer NIET weet 

Dus maar weer eens een vraag:
Inmiddels heb ik één camera via WiFi gelinkt aan mijn IoT VLAN 20 met IP 192.168.20.210. Maar die moet natuurlijk wel connecten met mijn NAS op het standaard LAN met IP 192.168.2.3 om het Surveillance Station te kunnen bereiken.
Tja, "iets" instellen in de firewall dus?

Ik ben begonnen met een regel die alle verkeer van 192.168.20.210 doorlaat naar 192.168.2.3. Maar Surveillance station accepteert het VLAN 20 IP-adres niet. Kan vanaf mijn PC op 192.168.2.50 de camera ook niet pingen. Lijkt me logisch want beide apparaten (PC en Camera) zitten natuurlijk niet op hetzelfde netwerk.
Wat is de oplossing?

Of maak ik het mezelf te moeilijk: de camera gewoon op het standaard LAN laten zitten en alleen in de firewall blokkeren dat het specifieke IP-adres van de camera naar het internet kan beveiligt de boel natuurlijk ook al.

Bedankt vast voor jullie antwoord: ik ga vast weer wat leren vandaag!

Groet, Dirk

[Babylonia]

Je kunt met aangepaste instellingen voor de camera, "over en weer" in netwerken daar wel oplossingen voor bedenken.
Maar is meer dan firewall regels aanpassen. Je zou daarmee ook de "basis regel" van gescheiden netwerken moeten laten varen.
(Voor dit soort functies gewoon de Synology help functies en "knowledge base" (kb) raadplegen).
https://kb.synology.com/nl-nl/SRM/tutorial/how_to_best_configure_network_isolation_and_firewall

        3. Schakel in het tabblad Algemeen het selectievakje Netwerkisolatie inschakelen uit en sla de instellingen op.

Het is eenvoudiger alleen voor die camera's een firewall regel aan te maken dat ze niet naar buiten mogen communiceren.

Wil je ze voor "het overzicht" en samenhang van functies toch in het IoT netwerk aangesloten willen hebben.
Eerder even kort in een "variatie" benoemd (maar door de hoeveelheid aan info de achterliggende gedachte wellicht nog niet begrepen).
Een van de andere LAN poorten van de NAS gebruiken om die via een managed switch "ook" te koppelen met het IoT netwerk.
Afhankelijk welk NAS model je inzet voor Surveillance Station, heb je mogelijk twee of misschien wel vier netwerkpoorten op die NAS??

(Gaat alleen als je nog LAN poorten over hebt. Bij gebruik van "Link aggregation" zijn al twee LAN poorten bezet).

Dus een NAS gekoppeld met twee netwerken.
Één NAS netwerkpoort gekoppeld met het Primaire netwerk.
Één NAS netwerkpoort gekoppeld met het IoS netwerk.

Heb hier een NAS DS415+ (zonder Link aggregation) ook gekoppeld met twee verschillende netwerken.

Zou je reeds één (twee) netwerkpoorten voor de NAS in gebruik hebben, is het met diepergaande kennis, ook nog mogelijk
de Netwerkpoorten van een NAS met gebruik van extra VLAN's te configureren onder "DSM 7". (Maar heb ik zelf nooit toegepast).
https://techblik.nl/2021/02/10/synology-dsm7-vlan/

Voor het overzicht, heeft de ene of andere benadering wellicht een (persoonlijke) voorkeur om in te zetten.

Zelf ben ik niet zo gecharmeerd van de eerste oplossing om de "basis regel" van gescheiden netwerken op te heffen.
En dan aangepaste firewall regels aan te maken om "haasje over te springen" naar het andere netwerk.
Fouten zijn snel gemaakt, en daarmee ook de veiligheid (en principe) in het geding waarom je juist "gescheiden" netwerken wilt inzetten.
Dus benadering via twee netwerkpoorten - voor twee verschillende netwerken met de NAS aangesloten heeft mijn voorkeur.
(En dan nog apart voor die camera's een firewall regel toevoegen dat ze niet naar buiten mogen communiceren vanuit het IoT netwerk).

[dirklammers]

Ik ben blij met je antwoord Babylonia, want al verder denkend heb ik ook niet stilgezeten en kwam eigenlijk tot dezelfde oplossing die ik overigens eerst nog wel wilde toetsen bij j(ulli)e.

De link aggregation was voor de DS720+ die ik voor "privé-doeleinden" inzet eigenlijk meer een speeltje dan een noodzaak.
Ik kan dus redelijk simpel die bond in de NAS opheffen, een vast IP-adres uit de IoT reeks meegeven en de betreffende poort op de TL-SG2216 ook naar (in mijn geval) VLAN 20 untaggen.

Dat lijkt me inderdaad ook technisch de meest charmante oplossing.

Dank weer.

[dirklammers]

Ja hoor, dit werkt ook weer!!

Nu toch zeker nog wel even beide camera's blokkeren voor "contact met internet" in de firewall, want standaard heeft IoT wel toegang tot internet i.v.m. de servers van Daikin en KaKu?

Groet, Dirk

[aliazzz]

"Daarna ook niet meer opnieuw in gebruik genomen bij nieuwere Synology router modellen (Gebruik ikzelf dus niet)."

Daar doe je jezelf, zekere als je een RT6600ax bezit tekort mee. Die is prima in staat DPI on the fly uit te voeren met behoud van pak em beet 70% bandbreedtebehoud. Natuurlijk zullen prestaties verschillen per situatie maar ik ben hierover tevreden en heb dit 24/7 op mijn WAN en VPN kanaal aangezet.