SIDN brengt 1.0-release van netwerkanalysetool SPIN uit

SIDN Labs heeft een 1.0-release uitgebracht van zijn netwerkanalysetool SPIN. Gebruikers kunnen daarmee verkeer van iot-apparaten in hun netwerk analyseren. In SPIN 1.0 zitten een bridgemodus en betere beveiliging.

De repo's voor SPIN 1.0 zijn op GitHub te vinden. De Stichting Domein Registratie Nederland had SPIN al langer geleden uitgebracht, maar vooral als experimentele tool. Met versie 1.0 is 'de basisfunctionaliteit nu compleet', schrijft SIDN Labs.

In de 1.0-release zit onder andere een bridgemodus. Daarmee kan de tool worden geïnstalleerd op routers die alleen als bridges worden gebruikt. "Daardoor is het systeem waarop SPIN draait, geen router, maar een transparante 'bump in the wire'", schrijven de ontwikkelaars. Gebruikers hoeven hun apparaten met die bridgemodus niet opnieuw te configureren als ze SPIN willen gebruiken.

Ook nieuw in de release is dat de webinterface nu via https kan worden geladen en dat de MQTT-verbinding gebruikersauthenticatie krijgt. Ook kan SPIN voortaan loggen naar bestanden en systeemlogs. In SPIN 1.0 is ook de eerder aangekondigde PCAP-reader aanwezig.

SPIN, ofwel Security and Privacy for In-home Networks, is een opensourcetool die volledig door SIDN is ontwikkeld. Het is een tool die gebruikers in hun thuisnetwerk kunnen installeren zodat ze iot-verkeer kunnen scannen. Ook wordt de tool standaard meegeleverd met de Valibox-software, die SIDN zelf uitbrengt.

Reacties (82)

[Earry]

Op zich vind ik dit soort tools heel mooi maar dat SIDN deze uitbrengt blijf ik bijzonder vinden. Hun taak is domeinregistratie verzorgen voor de .nl zone maar op een of andere manier hebben zij genoeg mankracht om veel meer te doen dan dat. Voor mij klinkt dat alsof ze teveel inkomen hebben..

[nandervv]

Wow, iemand is met het verkeerde been uit bed gestapt.
Statuten SIDN:

SIDN heeft ten doel ten behoeve van en vanuit Nederland toegevoegde waarde te leveren voor de
internetgemeenschap middels het tegen verantwoorde tarieven ontwikkelen en in stand houden van diensten en producten op het gebied van digitale registratie en/of resolving in netwerken, zoals domeinnaamsystemen (waaronder in ieder geval .nl), en voorts al hetgeen met een en ander rechtstreeks of zijdelings verband houdt of daartoe bevorderlijk kan zijn, alles in de ruimste zin des woords.

Volgens mij valt deze tool gewoon binnen het toegevoegde waarde leveren doel van SIDN, en dus binnen hun doelstelling.

Daarnaast, ik kan me zo voorstellen dat een organisatie als SIDN een redelijke hoeveelheid expertise in-house wil houden, en daar hoort bij dat je je mensen tevreden houdt. En als iemand dan tijd over heeft in de planning, en daarom zo'n tool kan maken, dan is dat logisch. Dat is meer logisch dan je blind-staren op doelen en je mensen daarom niets laten doen.

[Tozz]

Statuten kun je wijzigen, dus wat je nu copy/paste mag zo zijn, maar Earry heeft m.i. wel een punt. Al die 'onzin' die de SIDN doet, zoals SIDN Labs worden allemaal bekostigd met geld afkomstig van .NL domeinhouders.

De SIDN weet eigenlijk van gekkigheid niet wat ze met hun geld moeten doen en pompen het in projecten die voordat ze zijn begonnen al gedoemd zijn te mislukken. Toevallig kreeg ik ook vandaag weer een uitnodiging voor een seminair over IoT, gehost door de SIDN. Heeft ook niets te maken met hun kerntaak.

Of neem 'Valibox', een OpenWRT cloon. De SIDN heeft dus een project (en spendeert dus geld) aan een opensource router firmware.. Er zijn al weinig mensen die OpenWRT gebruiken.. Laat staan mensen die dan SIDN's versie Valibox zullen draaien. En waarom? Omdat het DNSSEC validatie toepast op DNS queries.. Whooptiedoo. De meeste browsers doen tegenwoordig DoH en een gebruiker kan verder volstaan door een willekeurige publieke DNS server te gebruiken zoals Google, Quad9 of OpenDNS. Wat is nu precies de added value voor Valibox, anders dan 'wat zullen we vandaag eens doen?' Hoe geeft just-another-OpenWRT-cloon iets terug aan de Internet gemeenschap?


Daar komt bij dat er genoeg andere zaken die wel tot hun kerntaak behoren die gewoon enorm achterlopen op de rest van de wereld. Zo heeft de .NL zone nog altijd geen (near) realtime updates, terwijl EU, BE, COM, NET, ORG, INFO, etc, etc, etc, etc dat allemaal wel hebben. Dit betekent dat je tot op de dag van vandaag met een beetje pech 2 uur met een niet werkend domein zit als je bv. je DNSSEC keys kwijtraakt of je bv. snel nameservers moet wisselen vanwege een outage ergens.

En ondertussen voert de SIDN weer een prijsverhoging door..

De SIDN is letterlijk aan het hobbyen met jouw en mijn centen.

[Reactie gewijzigd door Tozz op 26 juli 2024 08:18]

[batjes]

Je kan zeuren over dat het van de betalers van een NL domein afkomt.

Wat heb je liever? Dat er een bedrijf met winstoogmerk en zonder maatschappelijke motivatie met onze TLD er vandoor gaat?

Ons TLD is spotgoedkoop en we hebben 1 van de meest betrouwbare TLDs in de wereld.

Dat ze dat geld niet in de eigen broekzak stoppen, maar gebruiken voor zulke projecten is juist enorm positief.

Maar ik begrijp dat je liever meer voor een. NL domein wil gaan betalen?

.nl is 5 euro.. Com is 3 tot 10 keer zo duur. Be is 2-3 keer zo duur.

Al die TLDs hebben geen SIDN achtige nonprofit organisatie erachter zitten. Winst is belangrijker.

[Tozz]

De SIDN heeft een taak.. Namelijk het beheer van de .NL zonefile. De kosten die ze vragen voor domeinregistraties moeten die kosten dekken, inclusief een financiele reserve voor mogelijke risico's. Daarbij mag er best ruim vet op de botten zitten zodat je bijvoorbeeld een kunt kunt denken 'We gaan eens een rewrite van de code doen' zonder dat je al te veel hoeft na te denken over de kosten daarvan. Kortom, ze mogen best ruim in cash zitten.

Maar als je dan tot de conclusie komt "Het geld klotst tegen de randen op, de reserves zijn tot de rand gevuld, wat gaan we in godsnaam doen?" dan is de enige juiste conclusie dat je tarieven omlaag kunnen. Dan moet je niet aan komen zetten met OpenWRT clones, seminairs over IoT en andere onzin.

Dat terwijl ik nog wel een aantal zaken kan bedenken die bijvoorbeeld *wel* nuttig zijn. Denk aan registrar modules voor systemen als WHMCS of HostFact. Of iets als een registratie module voor Plesk.. Ik noem maar wat.. er zijn genoeg veelgebruikte software systemen op Internet waar de SIDN een integratie plugin/module zou kunnen bieden. Nu laten ze dat stukje over aan de community (ze linken bv. naar een github account van iemand anders) maar gaan ze wel een router OS maken..

.BE is overigens zeker niet 2-3 keer zo duur. Beter nog, die zijn goedkoper (uit mijn hoofd 2,50 per domein). Daar komt bij dat de interface en de techniek bij .BE en .EU een stuk beter op orde is. Zo hebben die 2 namelijk oa. realtime updates van de zonefile.

"1 van de betrouwbaarste TLDs" durf ik wel met een korreltje zout te nemen. Flink wat jaar geleden waren ineens alle .NL nameservers offline door een fout in een zonefile update. Daarbij was de SIDN buiten kantooruren niet te bereiken, waardoor het ook nog eens heel lang heeft geduurd. Nou is dat lang geleden, en misschien niet meer zo relevant.. Maar het punt is dat veel andere TLDs ook eigenlijk nooit problemen hebben. De "uptime" van alle TLDs is heel erg hoog.

[NielsFL]

Een eigen openwrt versie maken gaat inderdaad veel te ver. Het lijkt zo simpel, maar ga het nu maar onderhouden de komende tig jaar.

Ik snap wel dat de SIDN meer wil doen, maar mijns inziens kunnen ze dat beter doen in de vorm van bounty’s. En dan alleen voor zaken die echt een directe link met domein registratie hebben.

Eventuele verdere overschotten lekker in reserve houden en latere, mogelijk noodgedwongen, prijsverhogingen mee verzachten.

[GertMenkel]

De "openwrt-versie" is een bestaande openwrt-image met een of twee packages voorgeïnstalleerd. Het is niet alsof dat nou zoveel tijd kost om op te zetten.

[NielsFL]

De tijd zal het leren. Maar het is iets wat ik erg vaak heb gezien: Op enig moment werken de scriptjes die dat bij elkaar rapen niet meer goed, is die ene persoon die er echt aan werkte weg bij SIDN, blijkt dat er maar een handjevol gebruikers zijn en verdwijnt het stilletjes van de website.

Geen ramp voor die paar gebruikers, want OpenWRT zelf blijft wel updaten. Maar het is gewoon zonde van de tijd die er nu aan besteed is. Het blijft voor mij logischer om het - al dan niet met wat bounty-geld - toe te voegen aan OpenWRT zelf. Dat bereik je veel meer mensen en heb je een grotere kans dat het langdurig overleeft.

[GertMenkel]

Het OpenWRT team gaat dit project niet uitvoeren of af en toe haar dependencies bijwerken, ik zie niet wat het nut is van het uitbesteden van het werk.

[Tozz]

Maar wel om te onderhouden. Iemand moet periodiek dat bijwerken, de website moet geupdate worden.. Er worden management vergaderingen gehouden over de voortgang en status van het project.. Documentatie moet gemaakt worden, etc, etc, etc.

[Odie]

Dit is een fenomeen wat we wat meer in deze hoek zien, waarbij er zoveel geld binnenkomt op de kernactiviteiten dat men allerlei hand en spandiensten er om heen gaat bouwen. Ik ga bewust geen partijen aanwijzen nu, maar ik kan er zo nog wel twee uit deze contreien noemen waarbij ik ook al vaker met opgetrokken wenkbrauwen keek naar allerlei nieuwe activiteiten die eigenlijk weinig te maken hebben met waarvoor de entiteiten ooit zijn opgericht.

[Redwood]

En het is ook nog niet bepaald zo dat SIDN er de laatste jaren maar goedkoper op wordt. Ik weet nog dat ze de abonnementen toen in 2011 ofzo? Van 240 per jaar naar 60 per maand gooiden en tegelijkertijd registratiekosten gingen verhogen.

[Earry]

Nee hoor. Ik bedoel eigenlijk nog niet eens zo zeer deze tool, die kan nog in ‘vrije tijd’ zijn ontwikkeld. Maar met SIDN Labs en enkele andere diensten, concurreert deze stichting die - nota bene via een convenant en niet via een publieke aanbesteding - de controle heeft over de .nl zone gewoon keihard met commerciële bedrijven.

Overigens zijn die statuten niet de originele statuten maar zijn deze aangepast naar de huidige vorm een aantal jaar geleden. Voorheen was de kerntaak de registratie. Momenteel is het gewoon een commerciële organisatie met als rechtsvorm ‘stichting’.

SIDN heeft op 12 juli 2019 SIDN Business BV opgericht om risico’s van de CyberSterk en IRMA activiteiten te scheiden van de .nl-activiteiten. De statuten zijn zo opgesteld dat de bestuurder van SIDN Business BV vooraf goedkeuring van haar aandeelhouders (SIDN) dient te verkrijgen voor dezelfde soort besluiten als waarvoor de bestuurder van SIDN vooraf goedkeuring van de raad van toezicht van SIDN dient te verkrijgen. Dit verzekert het toezicht van de raad van toezicht van SIDN op SIDN Business BV. SIDN Business BV zal als kraamkamer voor new business activiteiten van SIDN fungeren. Gezien de opstartfase waarin SIDN Business zich nu nog bevindt, willen we van de wettelijke mogelijkheid gebruik maken om een verlengd boekjaar toe te passen. Omdat dit bij de oprichting niet was voorzien dienen de statuten van SIDN Business hierop aangepast te worden.

[Reactie gewijzigd door Earry op 26 juli 2024 08:18]

[nandervv]

Wow. Een organisatie maakt iets nuttigs gratis en onbeperkt beschikbaar voor iedereen. En het punt van discussie is dat het slecht is dat mensen gratis kunnen checken of hun IOT-devices zich netjes gedragen?

[Earry]

Nee, dan ga je voorbij aan het punt. De tool is nuttig, het feit dat SIDN zich hier mee bezig houdt zet ik mijn vraagtekens bij.

[batjes]

SIDN richt zich hiermee op thuisgebruikers. Een poging om IoT (in Nederland) toch weer wat veiliger te maken en zo ons stukje internet toch weer wat meer vrij weten te houden van rotzooi. Of dure zakelijke paketten/inhuur of zelf lopen rotzooien met een Linux bakje.

Dat gedram tegen SIDN is soms best vermoeiend. Beetje jammer dat half Tweakers lijkt te vinden dat SIDN op moet bokken.

Niet iedereen is het altijd eens met elk project waar SIDN mee bezig is, begrijpelijk, ik zelf ook niet altijd. Maar er zit over het algemeen een sterk idealisme achter en het is niet zo zwart wit als hier beweerd wordt.

Wat is nou het probleem dat SIDN hiermee concurrenten in de weg zit? Dit soort paketten zijn er vooral zakelijk en... doorgaans nogal duur. Ja met een Cisco-achtige router en wat knutselen bak je dit ook zo voor elkaar, maar die klasse routers zijn ook niet goedkoop. Of je moet zelf gaan knutselen met een Linux bakje. Oplossingen genoeg, maar duur of best tijdrovend.

Voor vele medetweakers bv geen optie. Nu kan praktisch elke medetweaker dit voor elkaar boksen, gratis en voor niets. Toch ook weer een leuk extra tooltje voor de tweakers toolbox?

Het is ook geen gigantisch project wat bakken met geld gekost heeft, lijkt me meer een soort side-project dat in de vrije uurtjes gedaan werd waar ze nu al 4 jaar mee bezig zijn (ik heb het verder niet gevolgd, eerste indruk van de github). Er zitten ook niet SIDN contributors bij.

Het idealisme van SIDN heeft grote invloed op ons stukje internet, iets waar we echt heel erg blij mee mogen zijn. Kijk alleen al naar de prijzen van domeinnamen, nooit opgevallen dat het .nl tld in verhouding altijd spotgoedkoop is geweest?

Ook nooit opgevallen dat er maar bar weinig van .nl domeinen gebruik gemaakt wordt bij scams e.d.?

Of dat we in verhouding een best laag aantal botnet clients hebben ondanks onze internetdichtheid?

Allemaal medemogelijk gemaakt danzij SIDN en het idealisme dat op het Nederlandse internet altijd al groot is geweest. Verdiep je in SIDN, alleen al dit project of soortgelijke initiatieven en vraag jezelf eens af of je liever had gezien dat dat hele gebeuren in handen van bedrijven met een winstoogmerk had gezeten. Daarvoor hoef je alleen maar naar onze buurlanden te kijken of ... naja praktisch elke willekeurige TLD houder.

[Tozz]

- Niemand zegt dat SIDN weg moet. De kritiek zit 'm erin dat SIDN aan het hobbyen is met andermans geld. Dat is niet erg als de SIDN een reguliere onderneming was, maar dat zijn ze niet. Het is in feite semi-overheid. Zou jij het ook goed vinden als de Nederlandse overheid dergelijke hobbyprojecten gaat financieren uit jouw belastinggeld?
- De .NL is niet 'spotgoedkoop', er zijn zat extensies die goedkoper zijn. .DE en .BE bijvoorbeeld, onze buren zijn allebei goedkoper. Bovendien heeft .NL de prijzen recent verhoogd.
- Ik denk dat +/- 50% van de bankscams die ik recent heb gekregen een .NL domein is (anders een .COM) denk aan klant-contactcenter.nl, bank-informatie.com, dat soort domeinen. Ik denk overigens niet dat dit komt door de SIDN, maar omdat anoniem betalen voor een domeinregistratie in Nederland lastiger is. Weinig providers accepteren bijvoorbeeld creditcards.
- Aantal botnet clients lijkt mij ook weinig relevantie hebben met de .NL zonefile. Dat lijkt mij meer een verdienste van bv. het NCSC in combinatie met het feit dat we welvarend zijn en primair een diensteneconomie hebben (en dus veelal erg afhankelijk zijn van onze IT)

Maar zelfs al zou je gelijk hebben dat al jou voorbeelden dankzij de SIDN zijn.. Dan nog moet je je afvragen of het dan correct is dat de kosten die daarmee gemoeid zijn betaald worden door domeinnaamhouders. Waarom betaald niet iedereen daar dan aan mee in de vorm van bv. belasting? Waarom moet ik met bv. 5 domeinen daar aan mee betalen, maar betaald een ander 0,- terwijl die ook de voordelen van dat 'veilige Internet' ervaart? Wellicht zou een 'belasting' op Internet connectiviteit dan beter zijn?

Jouw argument is dat de SIDN goede dingen doet.. Niemand zegt dat de dingen die ze doen niet 'goed' zijn (ik heb wel vraagtekens bij een aantal projecten). Het bezwaar is dat het niet hun taak is, en dat de kosten ervan niet gedragen moeten worden door domeinnaamhouders.

[batjes]

Graag zou ik zien dat de overheid zich met zulke projecten bezig houd.

Want dit is geen kostbaar project waar bakken met 'publiek geld' in gestopt is. Dit is een project van een handje vol mensen met gemiddeld ~100 commits per persoon over 4+ jaar tijd verspreid.

SIDN heeft het alleen onder haar hoede, er zitten ook niet-SIDN contributors bij.

Het heeft 'ons' geen drol gekost dit, het is een side-project gedaan uit beetje idealisme in (vermoed ik) de vrije uurtjes of zelfs vrijetijd.

De prijs van een BE of DE domein is goedkoper?

.NL is 5 euro per jaar met korting, op zijn duurst een euro of 20.
.BE en .DE beginnen bij 10-15 euro per jaar en zonder korting zijn deze 30-40 euro p/m.
.com begint ook pas bij een euro of 25 en dat loopt best hard op.

Zoek wat registars op en vergelijk de prijzen zelf. NL is keer op keer het goedkoopste 'normale' TLD. Er zijn wat goedkopere (met acties en kortings) zoals wat gare nieuwerwetse TLD's, maar die tel ik niet echt mee. Zelf ben ik nu een handje vol grotere registars langsgeaan in NL en hier om ons heen in Europa.

Zelf regelmatig te maken met scam/phishing domeinen, het zijn echt zo ontzettend zelden een .nl domein en soms wel, maar vaker wel dan niet is het domein binnen no-time offline. Het zijn 9/10 keer echt van die buttdomeinen.

Nee het aantal botnets is laag dankzij dit soort projecten, niet zo zeer omdat we een mooie TLD hebben. SIDN zet zich wel vaker in om de algehele veiligheid van ons stukje internet te verbeteren. Daar is dit project er dus 1 van!

Maar zelfs al zou je gelijk hebben dat al jou voorbeelden dankzij de SIDN zijn.. Dan nog moet je je afvragen of het dan correct is dat de kosten die daarmee gemoeid zijn betaald worden door domeinnaamhouders.

Het is heel simpel, er is slechts 1 alternatief: Het bedrijfsleven... zoals zo'n beetje elke andere registar... Dan gaan de prijzen dus omhoog en zien we daar als samenleving helemaal niets meer voor terug behalve een stuk waardelozer TLD.

Ik zie liever dat ze dat beetje geld gebruiken om wat ideologisch bezig te gaan met bepaalde projecten waar geen financieel gewin achter zit en de overheid zich ook niet mee bezig houd. Want voor de zoveelste keer, ons .NL TLD is echt goedkoop! Strato kon hier niet voor niets jarenlang domeinnamen rondstrooien voor 1 euro per jaar.

[Tozz]

Wat betreft de prijzen: Je kijkt nu naar wat providers vragen aan eindgebruikers. Ik had het over de prijzen die registries rekenen aan providers. Je bent dus appels met peren aan het vergelijken. In Nederland is een .NL domeinnaam goedkoop, omdat de concurrentie daar hoog is. Een .BE domein is hier veel duurder.

Ga je naar een Belgische webhoster dan zul je zien dat .BE goedkoper is en .NL duurder. Dat is dus allemaal appels met peren.. Je moet kijken naar wat de SIDN en andere registraties vragen aan hun klanten.

Laat ik nog zo'n onzin project noemen: Time.nl. Wat is dit? Het is een NTP server. Niet meer en niet minder. Ondersteund het de laatste technieken? Nee. Biedt het een SLA? Nee. Het is dus een zwak aftreksel van ntppool.org.

En wat is de reden dat de SIDN dit dan toch doet (copy/paste van hun website): "Answer: Because it fits in with our role". Kortom.. Er is geen reden anders dan 'In de statuten staat dat het kan'.

Is er een behoefte aan yet-another-NTP dienst? Nee
Biedt deze NTP dienst iets dat andere NTP services niet bieden? Nee
Biedt deze NTP dienst dan wellicht betere garanties? Nee

Ik hoop dat ik het mis heb.. Maar dit klinkt voor mij heel erg als: "Joh het is maandag! Wat gaan we doen deze week? Oh ja leuk, laten we een NTP server bouwen! Wat is het budget? HAHA. Leef je uit."

Echt pure geldverspilling.

En dan merk ik nog graag op dat op deze foto:
https://pbs.twimg.com/med...grV?format=jpg&name=large

De bekabeling van hun NTP GPS/Galileo receivers gewoon los op het dak ligt. Daar zou een beetje installatiebedrijf zich voor kapotschamen en is m.i. weer een indicatie van het hoge amateur gehalte van deze projectjes.

Laat ik als enig tegengas ook aangeven dat een aantal projecten wel een zinvolle bijdrage kunnen zijn, die ook een relatie hebben met hun taak (zonefile beheer). Dan denk ik aan bv. de Rollover monitor, en bv. een DANE Validator.

[Reactie gewijzigd door Tozz op 26 juli 2024 08:18]

[mdavids]

Hoi Tozz,

Time.nl. Wat is dit? Het is een NTP server. Niet meer en niet minder. Ondersteund het de laatste technieken? Nee. Biedt het een SLA? Nee. Het is dus een zwak aftreksel van ntppool.org.

Dit is alleen maar half waar. Wat het is, leggen we uit op https://time.nl/. Je kunt daar ook lezen welke kwaliteit je van ons mag verwachten. Ik ken niet zo heel veel NTP-diensten die dat ook zo transparant doen. Zelfs die van VSL niet. Als ik me vergis hoor ik het graag. (We proberen anderen te inspireren om ook duidelijker te zijn - dus dit kan in de loop der tijd verbeteren.)

Verder moet je nog weten dat TimeNL bijdraagt aan de NTPpool, die uiteraard niet van lucht alleen kan bestaan. Ik denk dat wij een van de mooiere Stratum 1's toevoegen aan de pool. TimeNL wordt trouwens door meer interessante partijen gebruikt. Zo vond ik het zelf best een eer dat 'time.cloudflare.com' ons heeft gekozen om (geauthenticeerd en wel) aan ons te synchroniseren.

Je had het ook over de 'laatste technieken'. Wist je dat TimeNL ook een NTS-server heeft? En een wereldwijde anycast-server (bestaande uit 28 nodes), die we allemaal ook laten meedraaien met de pool? De anycast-instances doen gezamenlijk ergens tussen de 100.000 - 150.000 queries per seconde. Er is dus een grote kans dat we jou ook wel eens voorbij zien komen om je tijd te synchroniseren, als je ergens in huis (of elders in de wereld) een apparaat hebt dat met de pool communiceert. Graag gedaan!

Dankzij TimeNL leren we veel over NTP in het algemeen en de NTPpool in het bijzonder. Die onderzoeksresultaten vertalen we weer naar bijdragen aan o.a. de NTPpool-community, zodat we er per saldo met elkaar beter van worden.

En wat is de reden dat de SIDN dit dan toch doet (copy/paste van hun website): "Answer: Because it fits in with our role".

Dat is de hele korte versie. In dezelfde FAQ staat ook het uitgebreide antwoord. Lees het eens, als je tijd hebt.

Is er een behoefte aan yet-another-NTP dienst? Nee

Dat is niet wat men ons doorgaans laat weten. De feedback is namelijk vooral heel positief.

Biedt deze NTP dienst iets dat andere NTP services niet bieden? Nee

Op https://time.nl/ leggen we vrij uitgebreid uit waarom wij denken dat het anders zit.

Ik hoop dat ik het mis heb.

Volgens mij wel.

Echt pure geldverspilling.

TimeNL is niet zo heel duur om te bouwen en de onderhouden.

En dan merk ik nog graag op dat op deze foto:
https://pbs.twimg.com/med...grV?format=jpg&name=large

De bekabeling van hun NTP GPS/Galileo receivers gewoon los op het dak ligt.

Ik moet je teleurstellen. We werken altijd zeer strikt volgens de geldende normen en voorschriften. Ook in dit geval. De betreffende bekabeling voor TimeNL verdwijnt, als je goed kijkt, in die regenpijp-achtige constructie vlak achter de antenne.

Hier wat beter te zien (toen we de uitbreiding van zonnepanelen nog niet hadden gedaan):

https://time.nl/img/antennes-TimeNL.jpeg

Op jouw foto zie je nog de aanleg, dus 'werk in uitvoering' van de nieuwe zonnepanelen. Die kabels gaan nog correct gemonteerd worden, uiteraard (volgens "scope 12 normering").

Hopelijk wat duidelijker zo? Als je nog vragen hebt, laat maar weten.

[Reactie gewijzigd door mdavids op 23 juli 2024 11:39]

[Tozz]

Tja, het veranderd mijn mening niet. Er zijn genoeg publieke NTP stratum-1 servers. Kan de SIDN er nog 1 bij zetten? Sure. Kan ik ook. Beter nog, iedereen met een GPS/Gallileo/whatever receiver en een Raspberry Pi in een tuinhuisje kan het. Stratum-1 servers de lucht in trappen is geen kunst.

Je onderschrijft mijn mening al een beetje met je reactie dat het is omdat jullie er wat van leren en weer teruggeven aan de NTP community. Dat geloof ik direct.. En an sich is dat natuurlijk goed, net zoals dat dit bijvoorbeeld gebeurd met Opensource software waarbij ik bijvoorbeeld een pull request kan insturen op een github project. Dan geef ik ook wat terug.

Dat het een leuk project is wil ik ook wel geloven.. Beetje spelen met GPS receivers, een anycast subnet de wereld in trappen.. Super leuk. Maar... mijn inziens geen taak voor de SIDN.

Dat is mijn bezwaar: Het is geen taak voor de SIDN en de SIDN heeft nog genoeg verbeteringen door te voeren die mijn inziens WEL relevant zijn voor haar taak. Denk aan fatsoenlijke registrar modules, realtime zonefile updates. Maar misschien ook wel iets als handleidingen/documentatie voor bijvoorbeeld implementatie van DNSSEC. Of wellicht misschien zelfs cursussen geven over die onderwerpen.

Omdat de SIDN een door de overheid aangewezen partij is voor de .NL zonefile vind ik dat je zorgvuldig om moet gaan met waar je je geld aan besteed, omdat jullie klanten geen andere leverancier kunnen kiezen... En ik ben hier gewoon op tegen, omdat ik er bij blijf dat het geen taak voor de SIDN is. Dat het dan verder een zinvol project is (of niet) doet daar niets aan af.

Het komt op mij over als cherrypicking van leuke projectjes, en de minder leuke dingen niet willen doen.

Maar misschien kun je mij dan dit uitleggen: Waarom doet de .NL zone als 1 van de weinige grote TLDs nog altijd geen realtime zonefile updates? Waarom pompt de SIDN daar niet eens wat tijd, geld en energie in? Zo'n NTP project lijkt me leuk als je niets meer te doen hebt, maar dat is volgens mij niet zo.

[mdavids]

Hi Tozz,

Iedereen met een GPS/Gallileo/whatever receiver en een Raspberry Pi in een tuinhuisje kan het.

Wij gebruiken geen Raspi, we hebben (o.a.) een Meinberg M3000.

net zoals dat dit bijvoorbeeld gebeurd met Opensource software waarbij ik bijvoorbeeld een pull request kan insturen op een github project. Dan geef ik ook wat terug.

Mag je dit in werktijd doen, of is het liefdewerk oud papier in je vrije tijd?

SIDN heeft nog genoeg verbeteringen door te voeren die mijn inziens WEL relevant zijn voor haar taak. Misschien wel iets als handleidingen/documentatie voor bijvoorbeeld implementatie van DNSSEC. Of wellicht misschien zelfs cursussen geven over die onderwerpen.

Dat doen we ook. Zie https://www.sidn.nl/zoeken?s=DNSSEC of https://academy.sidn.nl/ bijvoorbeeld.

Ik ben hier gewoon op tegen, omdat ik er bij blijf dat het geen taak voor de SIDN is. Dat het dan verder een zinvol project is doet daar niets aan af.

Staat je geheel vrij. Waar het mij even om ging is om onjuistheden te voorkomen. Je schreef bijvoorbeeld dat TimeNL 'een zwak aftreksel van de NTPpool' is, terwijl het mijns inziens juist een van de (betere) motoren onder de pool is.

[Reactie gewijzigd door mdavids op 26 juli 2024 08:18]

[Tozz]

Ik mag dat in werktijd doen, maar ik mag dat omdat 't een commercieel bedrijf betreft. De werkgever mag doen en laten met zijn geld (of uren van personeel) wat ze maar willen. Dat vind ik bij de SIDN een ander verhaal, daar de SIDN een soort variatie op een overheidsinstantie is. De SIDN heeft een door de overheid verkregen monopolie op de .NL zonefile en mag zelf haar tarieven bepalen.

Dan vind ik dat je je uitgaven moet verantwoorden.. En ik heb niet het idee dat dat nu het geval is. Het komt op mij over alsof de SIDN zelf bedenkt waar ze hun geld aan uitgeven, en dat daar weinig echte verantwoording achter zit anders dan 'we denken dat het een positieve bijdrage levert aan het Internet in het algemeen'.

Maar nogmaals.. mijn grootste bezwaar vind ik nog altijd dat er aan de .NL zonefile nog zat te verbeteren valt op technisch vlak, en dat ogenschijnlijk compleet stil ligt. Ik mag van mijn baas ook wel wat hobbyen in werktijd als er even niets te doen is.. Maar bij de SIDN is er mijn inziens nog van alles te doen om de .NL zonefile voor registrars te verbeteren. "Eerst het oude afmaken voordat je met wat anders begint" zou ik denken..

[mdavids]

ik mag dat omdat 't een commercieel bedrijf betreft.

Deze redenatie volg ik niet. Sinds wanneer hebben organisaties met een winstoogmerk en aandeelhouders het alleenrecht om te bepalen waar ze hun geld aan besteden of hun mensen aan laten werken? SIDN hoeft geen geld af te zinken naar aandeelhouders. Daarom zijn .nl-domeinnamen ook zo aangenaam geprijsd en is er desondanks nog ruimte om structureel tijd te spenderen aan de verbetering van het internet. Daar is SIDN ook transparant over trouwens, zie https://impact.sidn.nl bijvoorbeeld. Je hoeft het niet eens te zijn met alle keuzes natuurlijk. Dat kan altijd.

De SIDN heeft een door de overheid verkregen monopolie op de .NL zonefile en mag zelf haar tarieven bepalen.

Het betreft een 'technisch monopolie', dat alleen bestaat omdat niemand nog met een briljant idee is gekomen over hoe dit beter kan worden ingericht (maar voel je vrij). De overheid heeft verder niets te maken met (de totstandkoming van) .nl en SIDN. De enige connectie tussen SIDN en overheid (naast een prettige verstandhouding) is een convenant, waarin SIDN en de overheid uitspreken en vastleggen dat ze het prima vinden zo, plus een paar beloften en waarborgen over en weer (met name aangaande de continuïteit).

mijn grootste bezwaar vind ik nog altijd dat er aan de .NL zonefile nog zat te verbeteren valt op technisch vlak

Het een hoeft het ander niet uit te sluiten. Het betreft ook totaal verschillende teams onder de SIDN-vlag. SIDN Labs staat nagenoeg helemaal los van de operatie, al wordt wel van elkaars expertise geprofiteerd.

[Reactie gewijzigd door mdavids op 26 juli 2024 08:18]

[batjes]

Klopt, SIDN vraagt zelf 3,48euro per domein https://www.sidn.nl/onze-prijzen
In Belgie betalen ze 4 euro per domein https://www.dnsbelgium.be...registrar-worden/tarieven

België valt direct opzich nog wel mee, maar goed die prijzen heb je als klant niet zo heel veel aan als de registrars hoge marges aanhouden. Door gebrek aan sturing in de markt.

https://www.denic.de/file.../Direct_Preisliste_DE.pdf Duitsland is wel belachelijk duur. Zal in bulk wel een stuk goedkoper zijn oid.

Je had ook zelf even kunnen kijken natuurlijk, scheelt toch al 15% met België en die prijzen van een .de domein slaan helemaal nergens meer op.

https://time.nl/#backgroundinfo

Het is wel meer dan slechts "een NTP server". Het is heel fijn dat we dit als Nederland ook zelf in beheer hebben en niet afhankelijk zijn van Amerika of andere landen. Dat is juist ontzettend goed.

Nu doet SIDN ook wel wat meer dan een beetje tijd syncen met een andere tijdservice. Ook doet het bv geen leap seconds en heeft het zo nog wel zijn eigen dingetjes waardoor het fijn is dat er een alternatief op de Amerikaanse meuk is.

Maar de strekking van jouw verhaal is dat we als Nederland niets zelf moeten doen wat een ander land ook ongeveer al doet?

Is er een behoefte aan yet-another-NTP dienst? Nee Ja
Biedt deze NTP dienst iets dat andere NTP services niet bieden? Nee Ja
Biedt deze NTP dienst dan wellicht betere garanties? Nee Misschien geen betere, andere garanties.

Waar haal jij toch vandaan dat dit soort projecten bakken met geld kosten? Zo veel kost het allemaal niet hoor als het gross van het werk vanuit idealisme gedaan wordt en er niet uurtje-factuurtje gerekend wordt. Het hosten an sich kost ze geen bal natuurlijk, paar extra servertjes meer of minder in hun datacenter....

Weet je wat pure geldverspilling is? Dat de prijzen omhoog gaan en al dat geld in de zakken van een paar dikke stinkerts gaat!

Je zoekt echt om te zoeken of niet? Paar losse kabels, oh nee.

Natuurlijk zou een professioneel bedrijf zich daar voor schamen, want dit is in elkaar gehobbied door een paar medewerkers van SIDN, die daar niet in gespecialiseerd zijn.

Weet je wat pure geldverspilling is? Een profesioneel installatiebedrijf inhuren omdat je anders bang bent dat iemand problemen maakt over een losliggende kabel

[c-nan]

SIDN = Stichting Internet Domeinregistratie Nederland

Zij zijn primair verantwoordelijk voor de .nl domeinregistraties. Ondertussen doen ze al veel meer dan dat, waarom?

Waarom wilt SIDN minder afhankelijk worden van inkomsten uit .nl-domeinen?

Ze nemen commerciële bedrijven over, een tijdje later verhogen ze de de tarieven van .nl-domeinen.

[CAPSLOCK2000]

SIDN = Stichting Internet Domeinregistratie Nederland

Zij zijn primair verantwoordelijk voor de .nl domeinregistraties. Ondertussen doen ze al veel meer dan dat, waarom?

Waarom niet? Het is geen overheid. Je zou je kunnen afvragen of dat misschien wel zo zou moeten zijn, het werk dat ze doen is belangrijk genoeg, maar het is gewoon niet zo.
De voetbalclub hier om de hoek doet ook allerlei activiteiten, (zoals een BBQ) voor hun leden die uiteindelijk niks met voetbal te maken hebben.

Die stichting heeft het doel om internet beter te maken. Het beheren van domeinnamen is het bekendste voorbeeld.
Het is misschien geen gekke gedachte dat SIDN alleen domeinregistraties zou moeten doen maar dat is gewoon niet zo. Een stichting doet wat er in de statuten staat en dat gaat verder dan domeinen beheren.

Waarom wilt SIDN minder afhankelijk worden van inkomsten uit .nl-domeinen?

Omdat het doel van de organisatie is om internet beter te maken, niet om domeinen te beheren. En om dat grotere doel te bereiken is het verstandig om niet afhankelijk te zijn van een enkele bron van inkomsten.

[Tozz]

De SIDN doet toevallig ook BBQs voor hun leden. En dat vind ik wel onderdeel van hun kerntaak. Het versterkt namelijk de relatie tussen je leden en tussen de organisatie en de leden. Idem met een voetbalclub.

Maar wat zou je er van vinden als die zelfde voetbalclub de bijdrage gaat verhogen omdat ze bijvoorbeeld willen gaan beleggen in vastgoed? Is dat dan nog steeds oke? De voetbalclub is toevallig een stichting en in hun statuten staat dat het mag.

[CAPSLOCK2000]

De SIDN doet toevallig ook BBQs voor hun leden. En dat vind ik wel onderdeel van hun kerntaak. Het versterkt namelijk de relatie tussen je leden en tussen de organisatie en de leden. Idem met een voetbalclub.

Het voorbeeld was niet helemaal toevallig gekozen

Maar wat zou je er van vinden als die zelfde voetbalclub de bijdrage gaat verhogen omdat ze bijvoorbeeld willen gaan beleggen in vastgoed? Is dat dan nog steeds oke? De voetbalclub is toevallig een stichting en in hun statuten staat dat het mag.

Je bedoelt zoals Ajax?

Om even met het laatste te beginnen: het is een stichting dus wat ik er van vind dat er wettelijk gezien niet toe. Maar goed, daar wil ik met niet achter verschuiven omdat het werk van SIDN zo belangrijk is.

Dus daarom even terug naar de vastgoed-vergelijking. Als het vastgoed dat de club koopt een clubhuis of een stadion is dan draagt dat bij aan de doelen van die club: voetballen. Zelfs een investering in een fabriek voor voetbalschoenen of grasmaaiers is gerelateerd aan de missie. Nu de contributie verhogen om zo'n investering te doen om te voorkomen dat je later in de problemen komt kan een goede reden zijn.

Voor mij is het enige problematische aan de hele situatie dat voor sommigen dat .nl domein best wel belangrijk is en dat SIDN daar een monopolie op heeft, het lastige is dat het verschil vooral tussen de oren zin. Technisch gezien is "ing.nl" net zo goed als "ing.com" en "rijksoverheid.de" maar psychologisch gezien niet.

Er is nog een belangrijke reden om te investeren in iets anders dan domeinen. Domeinen worden namelijk steeds minder belangrijk. Dat komt vanuit verschillende kanten. Ten eerste heb je clubs als Google die zichzelf graag zien als de toegansweg naar internet. Die willen liever dat ieder bezoek aan internet begint met een zoekopdracht. Mensen die zelf de juiste URL intikken leveren geen reclameinkomsten op. Daarom zie je bij Google en chrome dat URLs steeds minder zichtbaar zijn. Ze hebben al verschillende pogingen gedaan om URLs helemaal niet meer te laten zien.
Een ander aspect is dat de meeste mensen geen eigen website of domein hebben maar gebruik maken van 'social media' sites als Facebook en Twitter. Zo identificeren mensen zich ook. Ze noemen zichzelf 'jantje@twitter' of zo iets, niet langer '[e-mail]'. Als je stichting het internet een betere plek wil maken kun je dus niet helemaal afhankelijk zijn van domeinnamen.

[Reactie gewijzigd door CAPSLOCK2000 op 26 juli 2024 08:18]

[Tozz]

Oke, investering in een fabriek voor grasmaaiers.. Ik vind 'm vergezocht, maar je zou kunnen stellen dat het nog een relatie heeft met voetballen. Het maakt ook niet zo veel uit, want de vergelijking gaat mank omdat je altijd bij een andere club kunt gaan spelen. Je kunt niet bij iemand anders een .NL domein kopen.

Uiteindelijk vind ik de verhouding gewoon krom. Er is voor de SIDN nog genoeg te doen op het vlak van .NL registraties. Denk aan realtime updates, het verhogen van gebruik van DMARC, DNSSEC, DANE en andere technieken, het leveren van up-to-date en goed werkende registrar modules voor veelgebruikte software pakketten. Of iets simpels als een fatsoenlijke WHOIS-dienst, die niet om de haverklap een 'Too busy' foutmelding geeft.

Maar voor bv. DNSSEC komt de SIDN niet heel veel verder dan 'We geven een korting als je veel DNSSEC doet', maar ondertussen wordt er wel budget vrijgemaakt voor een onzin project als time.nl.

Misschien is dit dan wel mijn grootste struikelblok: Ik heb soms het idee dat de SIDN haar kerntaak, de .NL zonefile onderhouden, saai is gaan vinden en steeds maar andere dingen bedenkt om maar niet de .NL zonefile te moeten verbeteren.

[CAPSLOCK2000]

Oke, investering in een fabriek voor grasmaaiers.. Ik vind 'm vergezocht, maar je zou kunnen stellen dat het nog een relatie heeft met voetballen. Het maakt ook niet zo veel uit, want de vergelijking gaat mank omdat je altijd bij een andere club kunt gaan spelen. Je kunt niet bij iemand anders een .NL domein kopen.

Het monopolie op .nl erken ik, maar dat we allemaal zo graag een .nl domein willen is een beetje kunstmatige.

Uiteindelijk vind ik de verhouding gewoon krom. Er is voor de SIDN nog genoeg te doen op het vlak van .NL registraties. Denk aan realtime updates, het verhogen van gebruik van DMARC, DNSSEC, DANE en andere technieken, het leveren van up-to-date en goed werkende registrar modules voor veelgebruikte software pakketten. Of iets simpels als een fatsoenlijke WHOIS-dienst, die niet om de haverklap een 'Too busy' foutmelding geeft.

Dat is fair, ook al hebben ze we al eens iets gedaan met sommige van die punten. Persoonlijk denk ik dat over die technieken eigenlijk wel genoeg is gezegd. We moeten ze breder toepassen maar technisch gezien is er al veel bereikt. Nog lang niet genoeg maar we weten ongeveer waar we naar toe willen.
Op het gebied van IoT zijn er nog een hoop uitdagingen waar geen antwoorden voor zijn. Wat dat betreft vind ik het wel tof dat SIDN zich daar mee bezig houdt. En DDOS-aanvallen die gebruik maken van IoT zijn duidelijk in opkomst.

Maar voor bv. DNSSEC komt de SIDN niet heel veel verder dan 'We geven een korting als je veel DNSSEC doet', maar ondertussen wordt er wel budget vrijgemaakt voor een onzin project als time.nl.

Nu vind ik dat je ze tekort doet. In de eerste plaats omdat die korting voor DNSSEC ontzettend succesvol is. Nederland is met zeer ruime marge de koploper van de wereld als het gaat om het toepassen van DNSSEC. Natuurlijk kan het altijd beter maar SIDN heeft al een enorme bijdrage gedaan. Volgens mij kun je daar niet meer van verwachten tot anderen ook wat hebben gedaan (ik kijk naar de ISPs).
Je kan overigens ook allerlei rapportje en dashbords bekijken om te zien hoe je er voor staat en waarmee je misschien je baas nog kan overtuigen om iets te veranderen.

Misschien is dit dan wel mijn grootste struikelblok: Ik heb soms het idee dat de SIDN haar kerntaak, de .NL zonefile onderhouden, saai is gaan vinden en steeds maar andere dingen bedenkt om maar niet de .NL zonefile te moeten verbeteren.

Ik weet niet of 'saai' het juiste woord is maar ik denk dat het wel zo'n beetje klopt. De mensen bij SIDN zitten daar niet omdat ze boekhouden zo ontzettend interessant vinden maar omdat ze graag aan vernieuwende techniek werken. Nu is er wel iets voor te zeggen dat ze het register dan maar moeten overdragen naar een gespecialiseerde boekhouder maar dan weet je ook dat er dan nooit meer technische vooruitgang komt. SIDN is opgericht om de pioniers van internet te helpen en dat zit nog steeds in het bloed. Dat er veel geld besteedt wordt aan onderzoek en projecten die niet aanslaan of domweg mislukken dat hoort een beetje bij pionieren.
Overigens heb ik wel begrepen dat deze functies intern strict gescheiden worden gehouden zodat ze geen last van elkaar hebben.

Niettemin valt moeilijk te ontkennen dat de systemen van SIDN soms nogal archaisch over komen.

[Tozz]

Ik ga het even kort houden, want we hebben er denk ik genoeg over gezegd.. Maar als ik een voorbeeld mag geven, als reactie op:

Volgens mij kun je daar niet meer van verwachten tot anderen ook wat hebben gedaan (ik kijk naar de ISPs).

Als ik bv. kijk naar HostFact, naast WHMCS een van de meest gebruikte administratie panels voor hosters.. Dat begrijpt geen DNSSEC. HostFact zelf heeft weinig motivatie om het te verbeteren. Doe je een DNS mutatie, dan blijven bijvoorbeeld de DS-records staan. Ook kan het zelf geen DNSSEC keys aanmaken.

Daar zie ik een 'taak' (of in ieder geval een mogelijkheid) om DNSSEC gebruik te verhogen, door modules voor dergelijke software aan te bieden. Idem voor WHMCS overigens, daar speelt eigenlijk hetzelfde. Zoiets zou ik veel meer als een taak van de SIDN zien dan een of andere IoT scanner.

[bbob]

Kijk naar de jaarcijfers van sidn, jaren dikke winst met dikke reserve, toen zijn ze allerlei projecten gaan doen, kosten vlogen omhoog en winst werd verlies dat uit de reserve kon worden opgevangen.

Ik begrijp @Earry dan de sidn misschien zich beter kan richten op haar kerntaken, domeinregistratie, hoewel dit hier een grensgeval lijkt te zijn.

[Hans C]

door belasting opgebrachte subsidie? Is dat een stokpaardje van je? Want belasting heeft hier niet zoveel mee van doen. SIDN krijgt zijn inkomsten vanuit een andere bron.

[amarissimo]

Je hebt gelijk, ik was nog niet wakker. Ik heb echter gewerkt bij dergelijke not for profit tech organisaties, en weet uit ervaring dat de inkomsten aan allerlei flauwekul worden besteed, om de gehanteerde prijzen of subsidie te rechtvaardigen.

[Onno]

Het gaat hierbij natuurlijk niet zozeer om wat ze zelf in hun statuten zetten en willen, maar om hoe (waarvoor) ze gefinancierd worden. Of dit soort projecten nuttig zijn of niet maakt daarvoor niet echt uit, maar moeten ze ook betaald worden van de opbrengsten van .nl-domeinen, of zouden die gewoon kostendekkend moeten zijn voor de operationele kosten van de .nl-registry, en niet meer dan dat?

[Aalard99]

Natuurlijk prachtig dat er een tool is die je gratis kan inzetten om je eigen netwerk te scannen maar het valt niet binnen de visie van het SIDN, het heeft niets met registraties of resolving te maken in netwerken. Ik ben het dus wel eens met het punt wat @Earry aankaart.

Hoe zou het zijn als bv de Belastingdienst een tool vanuit gemeenschapsgeld gaat ontwikkelen waarbij je kan scannen of je Wifi netwerken wel veilig zijn. Dit onder hem motto dat je veilig je aangifte vanuit huis kan doen.

Het punt is dus niet of de tool zijn nut heeft maar er is blijkbaar capaciteit binnen SIDN wat uiteindelijk betaald is door de leden die een domeinnaam geregistreerd hebben. Over dit punt mag er van mij wel een discussie zijn.

[Hans C]

Het zou onlogisch zijn om de Belastingdienst zo'n tool te laten ontwikkelen vanuit gemeenschapsgeld. Maar...... aan de andere kant. Als, en ik zeg als, we vaststellen dat bepaalde tools door de overheid ontwikkeld zouden moeten worden is dat altijd van belastinggeld.

[x280]

Wie zegt dat ze deze tool zelf niet intern gebruiken om te kijken of hun servers niet worden aangevallen ofzo ? ...

[3raser]

Als je hebt gelezen wat de tool doet dan weet je dat dit zeker niet wordt gebruikt om te zien of hun eigen servers worden aangevallen.

[GertMenkel]

Nee, hun taak is onder andere om .NL-domeinregistratie te doen. Ze doen veel meer, maar daar kennen de meeste mensen ze alleen niet van.

[Chris_147]

Kan nuttige tool zijn, maar toch niet direct geschikt voor de huis-tuin-keuken gebruiker:
- enkel op Linux of OpenWRT (daarmee vallen de meeste gebruikers al af)
- MQTT server moet draaien (wie heeft dat zo draaien?)
- ik vind ook niet direct binaries, dus zelf bouwen?

[jpgview]

zelfts Raspbian (voor raspberry pi) heeft een MQTT package. Ik heb er een tijdje mee geexperimenteerd, werkt perfect, low overhead, probleem is dat er geen fatsoenlijke client applicaties voor te vinden zijn. Ik probeerde (kocht zelfs) KR MQTT notifier, in de hoop op die manier windows 10 notifications te krijgen, maar helaas, het ding kan niet automatisch opstarten (geen windows 10 service), dus einde poging.

Volgens wat ik lees word MQTT alleen gebruikt om boodschappen door te geven, moet kunnen dus, zelfs op een raspberry pi.

[sprankel]

MQTT is ontwikkeld als de linux variant van OPC gezien OPC Windows only was. OPC is echter opgevolgd door OPC UA welke platform onafhankelijk werkt. Zowel OPC (UA) als MQTT zijn open standaarden.

Beide zijn niet meer dan een communicatie protocol bedoeld om live communicatie te doen tussen sturing systemen onderling of van sturingsysteem naar een software systeem. Of je nu data wilt uit een Siemens PLC, een Mercedes (niet beschikbaar voor consument) of uit gelijk welk sturings systeem, je verbind op dat communicatie protocol en je kan data uitwisselen.

Meeste use case is het uitwisselen van metingen of statussen, jij hebt een temperatuur sensor en ik wil weten welke temp die heeft. Dan vraag ik die meting op en dan kan ik via een refresh rate bepalen op welke snelheid, ik kan bijvoorbeeld iedere 60 seconden vragen maar ik kan ook elke 100 ms vragen.

Naast metingen bestaat er ook zoiets als alarms & events en die kunnen ook uitgewisseld worden via die communicatiebrug. Als jou systeem een event aanmaakt, "noodstop is ingedrukt", dan kan je dat event doorspelen. Dan heb je mogelijks een alarm, "noodstop is bezig", dat alarm kan je ook doorspelen.

Hoe jou stukje hardware/software die informatie naar de communicatie brug brengt intresseert mij niet en wat ik met die data doe langs mijn kant van de communicatie brug intresseert jou niet, zo lang we beide maar dezelfde communicatie brug ondersteunen.

Hoewel die bruggen meestal als een richtings verkeer gebruikt worden kan het ook in 2 richtingen. Ik weet bijvoorbeeld wat de luchtvochtigheid is en jij weet wat de temperatuur is, dan kunnen we die meting met elkaar uitwisselen alsook die gebruiken om zaken aan te sturen. Meestal word het echter gebruikt om van sturing systeem naar software systeem te gaan.

Het IoT gedeelte is niet meer dan wat het cloud gedeelte betekend, het is een marketing woord vooral bedoeld om het simpel te houden naar mensen die niet met die sturingsystemen rechtstreeks bezig zijn. Waar cloud 'het draait ergens anders en je moet het u niet aantrekken' betekend wilt IoT zeggen alles van automation systemen. Als ik tegen een IT'er zeg dat zijn SAP systeem OPC UA moet praten of MQTT dan kijkt die mij raar aan, als ik zeg u SAP systeem moet IoT praten dan weet hij waarover ik het heb.

En dat is ook mijn issue met deze SPIN tool dat IoT verkeer kan analyseren, als ik een tool heb dat cloud verkeer kan analyseren, dat is fantastisch voor iemand die niet weet wat achter het woord cloud zit maar voor diegene die het wel weet is het maar iets vaag. Wat voor IoT verkeer spreken we hier eigenlijk over, ik vind er niets van terug want ik ken veel IoT protocollen, het doet mij vermoeden dat het eigenlijk een uitgeklede wireshark is die in kaart brengt welke toestellen naar waar TCP verkeer sturen met een sticker IoT erop.

[Reactie gewijzigd door sprankel op 26 juli 2024 08:18]

[lenwar]

En dat is ook mijn issue met deze SPIN tool dat IoT verkeer kan analyseren, als ik een tool heb dat cloud verkeer kan analyseren, dat is fantastisch voor iemand die niet weet wat achter het woord cloud zit maar diegene die het wel weet is het maar iets vaag. Wat voor IoT verkeer spreken we hier eigenlijk over, ik vind er niets van terug want ik ken veel IoT protocollen, het doet mij vermoeden dat het eigenlijk een uitgeklede wireshark is die in kaart brengt welke toestellen naar waar TCP verkeer sturen met een sticker IoT erop.

Dit is ook precies mijn probleem met iets als dit. (zie mijn epos verderop). Op de eerste plaats is dit inderdaad geen IoT-device analyse, maar verkeersanalyse richting en van het internet. Het heeft in de basis niks specifieks met IoT te maken. Vrijwel al het verkeer wordt tegenwoordig versleuteld en heb je er dus effectief niet zo veel aan. Als het verkeer naar een generieke cloudprovider wordt gestuurd (Amazon, Akamai, enz.) weet je niet eens wie er achter zit. En als het al naar een 'fabrikantdomein.com' gaat, dan weet je niet of het "spionagedata" is of dat het een controle op een firmware update is.
Het enige dat je kan zien, is dat je apparaat iets met het internet doet, en ik vermoed dat de meeste mensen die de spullen hebben om dit überhaupt geïnstalleerd te hebben/krijgen, dat zij dat al wisten dat dat gebeurd. Hooguit alleen niet wanneer en hoe vaak, maar daar hebben zij dit stuk software weer niet voor nodig.

Edit: Goede beschrijving van MQTT trouwens!!

[Reactie gewijzigd door lenwar op 26 juli 2024 08:18]

[Raafz0r]

Er zijn tientallen goede MQTT clients, ook voor embedded toepassingen. Misschien dat jij een andere use case in gedachten hebt dan waar MQTT vooral voor bedoeld is?

En je kunt programma's ook automatisch laten starten als ze geen service zijn hoor. Enige nadeel is dat dit pas gebeurd na inloggen.
Of anders probeer je deze instructies: https://www.howtogeek.com...ion-as-a-windows-service/

[oef!]

Ik vraag me vooral af hoe het zit met qua gateway en configuratie. Hardop denkend zou mijn pi-hole naar de spin server moeten kijken als gateway, maar dan?

Overigens wordt het bouwen van binaries uitgelegd op de site.

[Noxious]

Ik denk dat je dit meer moet zien als 'port mirroring'.

[GertMenkel]

Ik heb met de mensen die hieraan werken mogen spreken. Ze hebben diverse providers en routerproducenten benaderd om zoiets ook in consumentenrouters te kunnen testen, maar ze zijn keer op keer afgewezen.

De firmware moet zo klein en vooral zo goedkoop mogelijk. Providers willen geen externe diensten integreren en geen features brengen die niet absoluut noodzakelijk zijn. Routermakers zouden het liefste een halve cent per router besparen door de firmware naar 32MiB te brengen met turbocompressie. Een paar MB aan extra RAM kost al snel een euro, en dat kan echt niet uit.

Met een beetje geluk slaat dit project een keer aan nu het stabiel is, zodat providers misschien nog een keer hier naar kijken. IoT-beveiliging is echt een drama en samen met andere projecten kan SPIN hier hopelijk eindelijk een keer wat aan doen.

[GeeBee]

Is dit ook te installeren op bv een RaspberryPi waar al Pi-hole op draait? Daar zit al DNS-afhandeling en logging in.

Edit: op hun website staat Raspbian vermeld.

[Reactie gewijzigd door GeeBee op 26 juli 2024 08:18]

[jpgview]

De vraag die ik me stel: waar in je netwerk moet dat ding staan? Ik heb een 4 port pfsense (freeBSD) draaien, maar daar kan het, volgens de GitHub pagina niet op draaien. Zet ik het op een raspberry pi (node-red - home automation), die in het wifi netwerk hangt (wpa_supplicant.conf - wlan0) of zet ik het op de raspberry pi (pi-hole) die op het ethernet (bedraad - eth0) netwerk hangt?

[GeeBee]

Alle verkeer moet er wel langs, dus als je het niet op je router zet, zul je ook je netwerk-instellingen moeten aanpassen (lijkt me).

[Maurits van Baerle]

Het lijkt me dat dit ofwel moet draaien op het apparaat dat de routing regelt ofwel op het apparaat dat de firewall regelt. Het moet namelijk wel een punt zijn waar al het verkeer langs komt anders mist ie van alles.

[jpgview]

Begrijp ik, maar iot is meestal wifi, dat is de traffic die ik wil bekijken. Ze geven aan (readme.md) dat je de software op een raspberry pi kan instaleren. Ik kan me niet echt voorstellen dat iemand een raspberry pi als router gebruikt.

Ik vermoed dat ik het zal moeten testen, tenzij natuurlijk iemand reeds een dergelijke setup heeft.

[Reactie gewijzigd door jpgview op 26 juli 2024 08:18]

[dss58]

geprobeerd op de raspberry pi met raspi OS lite, blijf hier op hangen:
configure: error: libnetfilter-log not found

[jpgview]

hier,
quote
libnetfilter_log requires libnfnetlink and a kernel that includes the nfnetlink_log subsyste (i.e. 2.6.14 or later).
/quote

heb je alle depencies geinstaleerd?

[dss58]

Uiteraard, het is in deze procedure: cd build; ../configure && make
eerder vond ie libmosquitto-dev niet, die heb ik kunnen installeren.

(edit)
dit krijg ik, en dan stopt ie

checking for fcntl.h... yes
checking net/ethernet.h usability... yes
checking net/ethernet.h presence... yes
checking for net/ethernet.h... yes
checking for unistd.h... (cached) yes
checking for netinet/if_ether.h... yes
checking for an ANSI C-conforming const... yes
checking for size_t... yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking net/bpf.h usability... no
checking net/bpf.h presence... no
checking for net/bpf.h... no
checking for vprintf... yes
checking for _doprnt... no
checking for pledge... no
checking for socket... yes
checking for strerror... yes
checking for crypt_checkpass... no
checking for crypt_r in -lcrypt... yes
checking for ranlib... ranlib
checking for mosquitto_lib_version in -lmosquitto... yes
checking for MHD_start_daemon in -lmicrohttpd... yes
checking for mnl_socket_open in -lmnl... yes
checking for nflog_open in -lnetfilter_log... no
configure: error: libnetfilter-log not found

[Reactie gewijzigd door dss58 op 26 juli 2024 08:18]

[jpgview]

deleted, fout gelezen...

[Reactie gewijzigd door jpgview op 26 juli 2024 08:18]

[dss58]

no problem
edit:
moest ik toch nog ff kwijt na wat na denken, met alle goeie techneuten die me van reply hebben gediend ben ik dankbaar , uiteindelijk kan ik de conclusie trekken dat SPIN (nog?) niet werkt op de raspberry pi, jammer maar helaas

[Reactie gewijzigd door dss58 op 26 juli 2024 08:18]

[GertMenkel]

Het moet tussen het internet en de andere netwerkapparaten zitten. Als je een los netwerk voor IoT host op je Pi, dus IoT<-->Pi<-->Router, kun je het daar dus zo op knallen.

Als je een los WiFi-toegangspunt hebt, moet je AP<-->Pi<-->router doen, met bijvoorbeeld een USB-ethernetadapter om de tweede LAN-poort werkend te krijgen.

Als je je pfSense-bak kan instellen met de nodige VLANs en routingconfiguratie zodat je al je IoT-verkeer eerst langs de Pi routeert, kun je het ook doen zonder de Pi er tussen te hangen. Je zou bijvoorbeeld het verkeer van je IoT-netwerk over een bepaalde VLAN kunnen sturen, die VLAN naar je Pi te routeren en dan de Pi het verkeer naar internet laten routeren via het normale VLAN.

Dat vereist alleen wel een hele hoop configuratie en gezeur en ik zou het niet aanraden, maar het kan wel.

Alternatief zou je het denk ik ook werkend kunnen krijgen door een kopie van al het IoT-verkeer te sturen naar de ethernetpoort waar de Pi aan hangt, maar dan moet je wel verzekeren dat de Pi er verder niks mee doet behalve de data aan het systeem voeren.

[Reactie gewijzigd door GertMenkel op 26 juli 2024 08:18]

[rutgersmit]

Heeft iemand hier al een Docker image van gemaakt?

[GertMenkel]

Dat lijkt me aardig lastig aangezien de software het verkeer van verschillende plekken in het netwerk (netwerkpoorten) inspecteert. De webinterface zal zou te draaien moeten zijn, maar het opnemen van het verkeer zelf vereist behoorlijk low-leveltoegang tot het netwerk. Bron- en bestemmings-IP-adressen moeten namelijk hetzelfde zijn, en met de standaard-Dockerconfiguratie die met bridges werkt, is dat niet mogelijk. Ook op IPv6 kun je hier problemen mee krijgen.

[rutgersmit]

En als je een container in host mode draait?

[GertMenkel]

Ik heb het niet vaak (genoeg) gebruikt, maar volgens mij kun je zelfs in host mode niet zomaar gerouteerd verkeer onderscheppen.

Zelfs als het kan, moet je ook nog de nodige kernelmodules installeren, wat vanuit Docker natuurlijk niet kan.

Ik heb er zelf de volgende Dockerfile van gemaakt:

FROM debian:stable

RUN apt-get update && apt-get install -y gcc make autoconf libnfnetlink-dev libmnl-dev libnetfilter-queue-dev libldns-dev libmicrohttpd-dev libnetfilter-log1 libnetfilter-queue1 libnfnetlink0 libmnl0 tcpdump libmosquitto-dev libnetfilter-log-dev libnetfilter-queue-dev libnfnetlink-dev libnetfilter-conntrack3 libnetfilter-conntrack-dev

COPY src/ /app/src
COPY scripts/ /app/scripts
WORKDIR /app/src/

RUN autoreconf --install
RUN mkdir /app/src/build
WORKDIR /app/src/build/

RUN ../configure
RUN make

WORKDIR /app/src/build/spind;

ENTRYPOINT /app/src/build/spind/spind -o -d

Je kan hem hier proberen: https://hub.docker.com/r/gertmenkel/spin

Ik krijg alleen maar access denied errors, maar misschien dat jij er wel wat mee kan. Default entrypoint draait de daemon (zoals in de handleiding staat), je zult ook nog een Mosquitto server moeten draaien om het goed te laten werken en wellicht een extra docker command om ook de webserver te runnen. Mount je config op /etc/spin/spind.conf of laat leeg voor de default.

[rutgersmit]

Nice, misschien dit weekend wat tijd, eens kijken hoe ver we komen.

[twdikkert]

Ik vind het prima dat het SIDN zich hier mee bezighoud, en iets verder gaat dan alleen een administratiekantoor.

https://www.sidnlabs.nl/over-sidnlabs

SIDN Labs is het researchteam van SIDN. Ons doel is het verder verhogen van de betrouwbaarheid van de internetinfrastructuur voor Nederland, Europa en de wereld op basis van toegepast technisch onderzoek.

[HKLM_]

Jaren 90 vibes als je die screenshot van de tool ziet Maar ziet er erg uit als een groot hobby project van iemand.

[Reactie gewijzigd door HKLM_ op 26 juli 2024 08:18]

[Keypunchie]

Het is gericht op de technische gebruiker, niet het grote publiek.

Erg leuk en positief dat (iemand bij) SIDN dit doet.

[KoffieAnanas]

Dat is dus al een pluspuntje voor deze tool. Geen opsmuk, focus op functionaliteit.

[lenwar]

Zeker fijn dat er geen toeters en bellen aan de interface geknoopt worden. Echter is een goed bruikbare interface is in mijn optiek ook belangrijke functionaliteit van een stuk software als deze? Je moet tenslotte wel goed kunnen interpreteren waar je naar kijkt.

En een interface mag van mij best wel naar de moderne tijd worden getrokken, toch? Ik vind dit wat het nu heeft wel heel erg summier.

[NielsFL]

Doet me inderdaad denken aan scotty/tkined. Mooie app was dat destijds.

[WarrieJunioR]

Waar is de screenshot te zien?

[Simon Weel]

Eens met @Chris_147 en @Keypunchie . Netwerkscanners te over, met Wireshark als een van de bekendste. Maarja, hoe moet je de gegevens die dit oplevert interpreteren? Da's nog lang geen sinecure...

Of SIDN zoiets moet ontwikkelen.... eerste gedachte is van niet. Maar even breder gezien - meer en meer beperken deskundige zich tot hun eigen gebiedje. Mooi voorbeeld is de medisch specialist. Kom je met een kwaal die gerelateerd lijkt aan zijn specialisme, maar dat toch niet blijkt te zijn? Wordt je domweg weer terug gestuurd naar de huisarts - is niet mijn gebied. Meedenken over wat het mogelijk wel kan zijn? Nee, daar beginnen we niet aan.
In die gedachtegang is de wereld zwart/wit en lekker simpel. Maar dat is niet de praktijk. En dus kan het helemaal geen kwaad als deze en gene 'out-of-the-box' denkt. Werkt in elk geval prikkelend, zoals de reacties laten zien....

[batjes]

Zie jij iemand die bv wel een APK op Android kan installeren, maar verder niet zo nerdy is. Wel even raspberry pi als bridge op te zetten met wireshark en mooie webinterface?

Er zit volgens mij toch best een behoorlijke skillgap tussen dit zelf wel even opzetten of deze package op je router of linux bakje neer te zetten.

Het maakt dit toch wel even heel wat makkelijker toegankelijk voor iemand die wel met IoT speelt maar verder geen doorgewinterde Tweaker is.

Lijkt me verder ook geen dondersgroot project waar super veel capaciteit in gestopt is, gemiddeld zo'n 100 commits per persoon in 4-5 jaar tijd.

Mooi initiatief.

Die specialist gaat niet meedenken aan wat het mogelijk wel kan zijn, want dat mag die niet. Die mag niet zo maar buiten zijn of haar specialisme gaan 'meedenken'. Daar is juist een huisarts voor. Beetje jammer dat er al jaren een chronisch tekort is aan huisartsen en er sneller fouten gemaakt worden dat je naar de verkeerde specialist gestuurd wordt.

SIDN doet met dit project precies waar het voor staat: Een kansrijk en zorgeloos digitaal bestaan voor iedereen.

[lenwar]

Ik snap het nut niet helemaal van deze tool om eerlijk te zijn. Ik heb de code niet gelezen (ben ik niet kundig genoeg voor), maar als ik puur naar de screenshot kijk zie ik het volgende:

Een Samsung tv, heeft verbinding gehad met hosts die verwijzen naar Netflix, een 224.x.x.x adres (multicast adres), wat domeinen van Samsung, een DNS-server van Google en een generieke cloud-provider (Akamai).

Hue-hub heeft verbinding gehad met een ntp-dienst, een hue-domein en een 239.x.x.x adres (discovery adres).

Ik zie alleen maar verkeer richting en van het internet (en lokaal multicast/broadcast verkeer). Ik kan dus niet zien of een stuk malware op een pc misbruik probeert te maken van de Samsung TV (of andersom!) Ik zie de aard niet van de verbinding richting het internet. Gaat de Samsung TV gescande data van m'n LAN naar Samsung sturen (wat al niet gedetecteerd werd), of heeft hij gecontroleerd op een update? (niet te zien omdat het waarschijnlijk allemaal versleuteld verkeer is)

Op zich niets wat je niet al kan zien op bijvoorbeeld een Unifi-router of één van al die andere routers die net wat uitgebreider zijn dan een standaard-router van een ISP.

Maar goed. De beschrijving die ze geven klopt ook niet helemaal. Je behoort het te installeren op een router/bridge.

SPIN is een platform voor het inspecteren van het netwerkverkeer van (IoT-) apparaten op je lokale netwerk. SPIN heeft als doel gebruikers en onderzoekers te helpen bij het analyseren van het gedrag van IoT-apparaten en andere netwerkapparatuur.

Dit stuk software controleert alleen al het netwerkverkeer dat richting (en van) het internet gaat. Alles wat lokaal op je LAN gebeurd (waar de grootste problemen liggen met al die IOT-devices), wordt dus niet gedetecteerd (want dat komt niet, afhankelijk van je router wel of niet je enige switch en access point is, of je allerlei VLANs hebt op je router, enz. enz. enz, langs je internetrouter). Het verkeer DAT daadwerkelijk van en naar het internet gaat zal grotendeels niet functioneel zichtbaar zijn omdat je dus niet goed kan interpreteren wat het is.
Dit, omdat tegenwoordig vrijwel alles wordt versleuteld. Alleen vooral DNS en NTP (maar ook in mindere maten SMTP/IMAP/POP3) lijken op dit moment nog niet op grote schaal versleuteld te worden)

Ik kan dus helemaal niets analyseren van het netwerkgedrag van een apparaat. Ik kan alleen het gedrag richting het internet bekijken. (en dat alleen heel oppervlakkig)

Tegenwoordig wordt er ook nog is gigantisch veel in cloudoplossingen gestopt. Amazon, Akamai of Azure in een hostname heb je effectief vrij weinig aan. (hacker-malware b.v. kan ook een dienst verstopt hebben op een cloudplatform). Zeker de kleinere cloudproductproducenten gebruiken dit. Hier is niks mee uiteraard, maar het maakt de nut en werkbaarheid voor dit soort tools een stuk minder groot.

Gezien de groep gebruikers die ze dit willen laten gebruiken (power-users), hadden ze denk ik beter het kunnen beperken tot een PCAP interpretator, gezien de meeste firewall oplossingen dit formaat kunnen gebruiken voor logging.

[GertMenkel]

De eerste versies hiervan werken onder andere op OpenWRT, en daar heeft het apparaat wat meer netwerktoegang. Als je domme switches gebruikt en de OpenWRT-router niet als AP instelt heb je inderdaad minder aan deze tool, maar ook lokaal verkeer kan door de tool verwerkt worden.

Een van de ideeën van het project is dat je de tool kan gebruiken om firewall-regels te maken. SIDN heeft bijvoorbeeld het een en ander bekeken gerelateerd aan MUD-bestanden, die het verwachte gedrag van een IoT-apparaat beschrijven qua netwerkverkeer. Je kunt deze tool gebruiken om die MUD-regels op te bouwen en die dan later weer te voeren aan iets dat er firewall-regels van maakt. De uiteindelijke bedoeling van MUD is dat fabrikanten een regelset zouden publiceren die consumenten zo in hun router kunnen laden zodat de apparatuur zelfs als deze gehackt wordt niet gebruikt kan worden voor dingen als DDoS-aanvallen, maar dat project is nog niet aangeslagen.

De verschuiving naar homogene cloudadressen is inderdaad heel lastig. Ik heb niks tegen versleuteling van IoT-verkeer, in tegendeel, maar de afhankelijkheid van willekeurige AWS-, Azure- en GCloud-IP-adressen maakt het lastig om iets nuttigs te zeggen over het verkeer. Als alles nou naar een bepaalde set domeinen ging met een duidelijke IP-tool, dan zou je nog wat nuttigs kunnen zeggen over het spul. Ik zou uitgaand verkeer het liefste dan ook gewoon blokkeren, maar dan werkt veel IoT-troep niet meer.

Met alleen een PCAP-scanner kun je net zo weinig zien als met het hele apparaat. Ik geloof dan ook niet dat de inhoud van het verkeer relevant is voor SPIN. Het is volgens mij vooral de bedoeling dat je IP-camera niet spontaan een server begint te DDoS-en of een VPN wordt voor kwaadaardige hackers zoals veel botnets normaal toestaan.

[lenwar]

De uiteindelijke bedoeling van MUD is dat fabrikanten een regelset zouden publiceren die consumenten zo in hun router kunnen laden zodat de apparatuur zelfs als deze gehackt wordt niet gebruikt kan worden voor dingen als DDoS-aanvallen, maar dat project is nog niet aangeslagen.

Het zou zeker zinvol zijn als er een soort database wordt opgebouwd met 'verwachte datastromen' (bij gebrek aan betere beschrijving van mijn kant). Dan kan je inderdaad helpen om botnets in de toekomst tegen te gaan.
Als de tool puur als doel heeft om DDoS aanvallen te detecteren en helpen tegen te gaan, dan zou het in theorie iets kunnen worden, maar dan verwacht ik op mijn beurt weer niet dat dit in de praktijk erg zal aanslaan. Pas wanneer de 'standaard-routers' van ISPs (wat de meeste mensen gebruiken zover ik weet) dit dan gaan gebruiken zal het zoden aan de dijk kunnen zetten.

Ik zou uitgaand verkeer het liefste dan ook gewoon blokkeren, maar dan werkt veel IoT-troep niet meer.

Dit is precies mijn probleem met veel IoT spul. Je hebt een app op een telefoon in hetzelfde LAN. Vervolgens gaat hij via internet je lokale apparaat bedienen, zoals mijn Dyson luchtreinigers. Het typische is, is dat mijn Home Assistant installatie ze wel direct over m'n LAN heen (zonder internet dus) bediend. Maar goed. Da's mijn persoonlijke frustratie.

[Dorank]

Maar goed. De beschrijving die ze geven klopt ook niet helemaal. Je behoort het te installeren op een router/bridge.
...
Dit stuk software controleert alleen al het netwerkverkeer dat richting (en van) het internet gaat. Alles wat lokaal op je LAN gebeurd (waar de grootste problemen liggen met al die IOT-devices), wordt dus niet gedetecteerd

Nee juist niet, de naam zegt het al: Security and Privacy for In-home Networks

Bridge is hier een netwerk apparaat wat transparant tussen een device en een netwerk verbinding plaatst, wellicht was het beter om dit een "probe" te noemen.

Zoals je zelf al zegt zinnige netwerk apparatuur hebt kan je deze info eigenlijk al achterhalen. Ik heb dus eigenlijk geen idee wie de doelgroep is. Maar wellicht dat het een mooie log collector is zodat het makkelijk historisch data/captures kan tonen.

[lenwar]

Nee juist niet, de naam zegt het al: Security and Privacy for In-home Networks

Ja, maar hij doet juist niks bij mij in huis. Alleen als het richting het internet gaat (of meer algemeen, richting de router).

Ik kan dus (bijvoorbeeld) niet zien wat een Samsung TV allemaal probeert te doen in mijn LAN om vervolgens de verkregen data op te sturen naar het internet, wat weer 'normaal gedrag' is voor een televisie (met internet praten). (en aangezien Samsung ook een advertentieverkoper is, zou het me niet verbazen dat zij allerlei data van mijn LAN zullen proberen te gebruiken voor profilering).

Het enige dat ik kan zien, is dat mijn Samsung TV met 'thuis' praat, maar ik zie niet of hij een tekening van mijn LAN opstuurt of dat hij alleen maar een controle doet voor een firmwareupdate.

[Dorank]

Als je dit ding tussen je TV en LAN plaatst (wat de bedoeling is), dan zie je juist of de TV iets probeert te doen binnen je LAN (en wat de TV gespammed krijgt vanuit je LAN).

Maar inderdaad nog steeds niet wat de daadwerkelijjke payload is die naar Samsung wordt verstuurd. Daarvoor zal je creatiever moeten zijn, maar ik vermoed dat Samsung de kleine moeite heeft genomen om dat tegen te werken. Stap 1 is echter nog altijd: plaats zulke devices niet in je LAN maar in quarantaine. Stap 2: monitor wat ze doen/proberen.

[Dorank]

verkeerde reageer knop

[Reactie gewijzigd door Dorank op 26 juli 2024 08:18]