Synology-Forum.nl
Synology Router => Synology Router => Topic gestart door: dirklammers op 07 mei 2024, 10:41:30
-
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
-
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.
-
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 (https://www.google.nl/search?q=Port+7547+KPN) 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. 8)
-
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
-
01:00:5e:03:02:06 opgezocht en is een onbekend (vendor) mac adres.
-
Het is multicast:
https://networklessons.com/multicast/introduction-to-multicast
Omgerekend, 224.3.2.6
-
Dank Pippin, dat is hem :thumbup:
Ik leer toch elke dag weer wat zeg. Leuk hoor.
Groet, Dirk
-
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.
-
@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.
-
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. [attach=1] 2. [attach=2] 3. [attach=3] 4. [attach=4]
-
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
-
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 (https://www.synology-forum.nl/synology-router/internet-of-things/msg328949/#msg328949) 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" (https://nl.wikipedia.org/wiki/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).
-
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.
-
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
-
"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.
-
(N.a.v. reactie vorige pagina (https://www.synology-forum.nl/synology-router/internet-of-things/msg328981/#msg328981) - m.b.t. "Threat Prevention" wat ikzelf niet gebruik ---> zie eerdere reactie (https://www.synology-forum.nl/synology-router/internet-of-things/msg328949/#msg328949)).
De RT6600ax gebruik ik nog steeds niet als hoofd router.
Komt misschien wel een keer als alles "stabiel" aan functies werkt. Er zijn nog steeds zaken door Synology aan te passen / te verbeteren.
(Met allerlei updates en testen, "teveel" volledige fabriek-resets, om dat dan telkens opnieuw te moeten installeren).
Verder heeft het een bepaalde problematiek.
Hoe sneller het internet, hoe sneller het externe geheugen moet zijn om de internet snelheid bij te kunnen houden
in de controle met data die op dat geheugen is opgeslagen.
Om Threat Prevention daarbij met zo min mogelijk bandbreedteverlies in te zetten, moet men nogal wat maatregelen nemen,
om "zeer snel" extern geheugen in te zetten via USB. (Uitschakeling van instelling om snelheid USB 3 poort te beperken naar USB 2.0 specs).
Waarbij men speciale aandacht moet schenken aan afschermingen van USB-kabel en behuizing van dat extern geheugen.
Om interferentie met WiFi over- en weer met het opslagmedium te minimaliseren.
Past men die extra afschermende maatregelen niet toe, loopt men door interferentie tegen fouten op welke corrupte data veroorzaakt,
en daarmee betrouwbaarheid van routerfuncties en toename van vreemde "onbegrepen" storingen.
-
De RT6600ax gebruik ik nog steeds niet als hoofd router.
Ben nu even nieuwsgierig? Wat gebruik je dan wél als hoofdrouter?
Groet, Dirk
-
De RT2600ac, die achter de RT6600ax zit. (Dubbel NAT). Die RT2600ac draait hier nog onder SRM 1.2.5
Op dit moment draai ik overigens wel "dubbel" in de zin, dat TV via de RT6600ax loopt, en ik ook WiFi inzet van de RT6600ax.
Tegelijkertijd via "bekabeld" ethernet, ook connectie heb met achterliggende NAS, en extra drives gekoppeld aan de RT2600ac.
NAS is zowel bekabeld verbonden via netwerk achter de RT2600ac, alsook met de RT6600ax.
Met telkens testen van RT6600ax, en mogelijke tussentijdse interventie van Synology Support, die er patches opzet.
In verleden bij "begin introductie" van de RT6600ax is dat nogal eens gebeurd, wil ik niet telkens puur afhankelijk zijn van de RT6600ax.
Nu met uitdiepen van IPv6 afgelopen periode heb ik de RT6600ax al meermalen naar volledige fabrieksreset terug gezet.
Daarbij zitten er nog steeds een aantal fouten m.b.t. VPN. (Niet IPv6 compatible),
waarbij interventie van Synology Support zal worden gevraagd, en zij er wellicht ook weer een patch op gaan zetten.
-
De RT2600ac
Ik ben weer gerustgesteld: als jíj nu zelfs geen Synology-router als hoofdrouter zou gebruiken dan zou ik me zorgen gaan maken omdat ik dat nu inmiddels dus wél doe :o
Overigens nog steeds tot volle tevredenheid: alles werkt hier stabiel :clap: :thumbup:
-
Heb hier diverse Synology routers, die met allerlei tests geregeld wel een keer worden teruggezet naar fabrieksinstellingen. :geek:
Behalve de hoofd router niet (1x RT2600ac - SRM 1.2.5).
1x RT1900ac (SRM 1.2.5)
2x RT2600ac (eentje met SRM 1.2.5. de andere SRM 1.3.1)
1x MR2200ac (SRM 1.3.1)
1x RT6600ax (SRM 1.3.1)
Synology is overigens erg slordig met hun firmware updates.
Komen ineens eerdere bugs die zijn hersteld, in een latere versie weer terug, en moet dat weer opnieuw worden hersteld.
Of sluipen er nieuwe kleine foutjes in met functies of menu-instellingen, waar eerdere SRM versies geen last van hadden.
Om die allemaal weer te melden, daar ben ik mee gestopt.
Bijv. een MR2200ac, ook die kan als "hoofd" router direct achter KPN glasvezel, met het KPN profiel worden ingezet.
Maar inmiddels werkt dan "internet" zelf niet meer, maar wel de TV streams via VLAN-4 van dat profiel.
(Al je de TV-ontvanger "aan laat staan" en van de ene aansluiting naar een half werkende MR2200ac overgaat).
Omdat die MR2200ac waarschijnlijk nooit (of niet meer) met "KPN" profiel direct achter glasvezel zal worden gehangen,
maar meer als "mesh" router zal worden ingezet achter een van de meer uitgebreide Synology router modellen.
Heb ik die bug bijv. niet aan Synology gemeld.
-
Kennelijk gebruiken ze dan geen goede source code management (SCM, bijv. via svn/git etc) of is er iets anders aan de hand waardoor Synology niet "in control" lijkt? Het is op z'n minst opmerkelijk te noemen dat voorheen gemelde en opgeloste bugs, weer herintroduceerd zijn in latere builds. Ik vermoed, maar dit blijft natuurlijk gissen, dat Synology hoogstwaarschijnlijk zelf wel " in control" is over z'n eigen codebase, maar ze heeft geen "controle" heeft over 3rd party dependencies. Dit is iets wat binnen een linux software omgeving maar vaak genoeg voor komt (toolchains, drivers, etc etc).
Het niet meer melden van deze "regressie bugs" werkt daarbij ook averechts (dit weet je natuurlijk ook ;-) )
Ik zou je graag bij deze dan ook willen verzoeken die oude bugs die teruggekomen zijn dan in iedergeval allemaal in 1 enkele ticket te duwen en daarmee juist WEL te melden! Synology heeft dan tenminste een aanleiding om uit te vissen "hoe of wat". Die ticket moet namelijk in iedergeval bekeken en hopelijk behandeld worden.
Ik ben als Synology gebruiker wel hardstikke blij met de feedback en moeite die je tot heden in hun producten hebt gestoken, ga zo door!
-
Ik vermoed, maar dit blijft natuurlijk gissen, dat Synology hoogstwaarschijnlijk zelf wel " in control" is over z'n eigen codebase, maar ze heeft geen "controle" heeft over 3rd party dependencies.
Nee, het zijn hun eigen slordigheden, wat niets met third party afhankelijkheden te maken heeft.
Bijv. bij KPN IPTV met een goed draaiende "Support" SRM versie op mijn eigen router (feitelijk KPN IPTV "hier" al draaiend vanaf 3 nov. 2020).
Had men bij de officiële firmware versie die 29 december 2020 (https://www.synology.com/en-global/releaseNote/SRM#ver_8081-2) werd geïntroduceerd "vergeten" bepaalde code op te nemen.
Dus KPN IPTV werkte alsnog niet met die versie. En moest dat weer worden hersteld met de latere update van SRM 1.2.5-8227 (https://www.synology.com/en-global/releaseNote/SRM#ver_8227)
Precies dezelfde fout heeft men anderhalf jaar later weer gemaakt bij introductie van de RT6600ax met hun eerste SRM 1.3 firmware versie.
(Dezelfde code vergeten op te nemen. Heb Synology toen geattendeerd met verwijzing naar support tickets van "anderhalf jaar eerder").
Eerdere tijd synchronisaties (bijv. tijdschema's voor in- uitschakelen van WiFi) waren niet "zomer / wintertijd" bestendig.
Die fouten zijn na herstel later ook weer opnieuw in een aantal varianten terug gekomen.
Het komt ook meermaals voor dat een eenmaal uitgebrachte update door Synology weer wordt ingetrokken.
Het lijkt me dat controle van dit soort bedrijfsprocessen en controle op correcte werking van nieuwe firmware
niet de taak is van gebruikers om daar Synology op te moeten attenderen. Maar in eerste instantie een taak van Synology zelf.
Gewoon met "proef opstellingen" voor allerlei voorkomende netwerk set-ups zou men "vergissingen" snel kunnen traceren,
voordat een update wordt gelanceerd.