Chinese fabrikant roept apparaten terug die bij Dyn-ddos gebruikt werden

Het Chinese bedrijf Xiongmai houdt een terugroepactie van bepaalde producten die het in de VS verkoopt. Het bedrijf maakt onderdelen van webcams, die gebruikt werden in de recente ddos-aanvallen op dns-provider Dyn.

Persbureau Reuters meldt dat het bedrijf aankondigt een deel van zijn producten terug te roepen, wachtwoorden te verbeteren en patches uit te brengen voor apparaten die voor april 2015 zijn gefabriceerd. Het is onduidelijk welke producten het bedrijf precies terugroept, de berichtgeving spreekt alleen van webcams.

Volgens Xiongmai is het grootste probleem dat gebruikers de standaardwachtwoorden van zijn apparaten niet aanpassen. ComputerWorld schrijft dat de fabrikant gebruikers inmiddels bij het in gebruik nemen van apparaten vraagt om het standaardwachtwoord aan te passen. Ook heeft het bedrijf in september 2015 een beveiligingsupdate uitgebracht. Apparaten die niet van de nieuwe firmware zijn voorzien, zijn echter nog kwetsbaar. Eerdere kritiek op de apparaten richtte zich op de afwezigheid van een mogelijkheid om het voorgeprogrammeerde wachtwoord aan te passen.

Verschillende beveiligingsbedrijven meldden onlangs dat de ddos-aanval op dns-provider Dyn werd uitgevoerd door het Mirai-botnet. Dit bestaat uit ongeveer een half miljoen met malware besmette internet-of-things-apparaten, die voorzien zijn van geen of slechte beveiliging. Vrijdag was Dyn doelwit van grootschalige ddos-aanvallen, waardoor populaire sites als Reddit, Twitter en GitHub onbereikbaar waren. Een eerste aanval richtte zich op datacenters aan de Amerikaanse oostkust, een tweede was gericht op datacenters over de hele wereld. Ongeveer twintig procent van het Mirai-botnet zou tijdens de aanval op Dyn zijn ingezet. Xiongmai bestrijdt dat zijn webcams het grootste deel van de in de aanval gebruikte apparaten vormen.

Het Mirai-botnet is eerder gebruikt om de site van journalist Brian Krebs plat te leggen. In de dagen daarna maakte een persoon de broncode van malware openbaar die gebruikt wordt om iot-apparaten te infecteren en op te nemen in het botnet.

Reacties (136)

[Nightjar]

zomaar een ideetje hè.. zou je smart tv's ook kunnen gebruiken voor een DDOS aanval..?

[tweaknico]

Waarom niet? In principe kan ELK apparaat dat direct met het Internet kan praten gebruikt worden.
De enige die dat serieus kan voorkomen is het apparaat zelf. Daartoe moet het dan wel in de gelegenheid gesteld worden door z'n beheerder... (Eigenaar)... en die moet daarvoor weer de tools aangereikt krijgen door de bouwer (Fabrikant).

De eigenaar zal iets met toegangscontrole on site moeten kunnen doen. Fabrikanten moet zorgen dat alleen SSH/SSL toegang mogelijk is icm. afgedwongen goede wachtwoorden.
Geen voldoende sterk ingesteld ww. dan ook geen functionaliteit. ie. Zwart beeld etc.

Ook de modem / CPE fabrikanten zouden het makkelijk moeten maken om een VPN tunnel tussen het de telefoon van de eigenaar en CPE mogelijk te maken, dan is er ook geen man in the middle nodig zoals bij Toon/Nest etc. (Want dat blijven ook zwakke schakels in de ketting, niet alleen voor IT security maar ook voor Social Security (ofwel Privacy).

[Verwijderd]

Nu leg je de verantwoordelijkheid op de clients terwijl dat volgens mij helemaal niet de juiste aanpak is.

Het hele netwerk moet hier gewoon tegen kunnen. Je gaat NOOIT alle apparaten zodanig aanpassen dat een aanval niet meer mogelijk is.

Ik denk dat de structuur die momenteel gebruikt word voor het internet te gecentraliseerd is. Een decentrale aanpak zou dit soort ongein gelijk aanpakken en met extra maatregelen zijn DDos aanvallen iets van het verleden.

[tweaknico]

De eigenaar moet z'n eigendommen WEL beheren, en er VERANTWOORDELIJKHEID voor nemen. Een fabrikant moet die verantwoordelijkheid wel MOGELIJK maken.
Laten we voor de verandering veiligheid (een neven dienst van veel van de domotica producten... Camera om kind in de gaten te houden, alarmering als er iets veranderd zonder dat er iemand thuis is...) ook serieus te nemen op het digitale vlak, want dat wordt al een jaar of 30+ afgewimpeld met te duur, te veel tijd, en er wordt niet om gevraagd.

Overigens is een netwerk een transport dienst en moet als zodanig NIETS doen dan bitten van A naar B verplaatsen. Een netwerk als filter is een verkeerd design.
Ze moeten zich beslist niet bemoeien met de inhoud van pakketten/brieven.
Censuur is geen beveiliging, op z'n best schijnveiligheid.

Het internet is extreem gedecentraliseerd juist door diensten als Akamai en OVH, Google.
Die zorgen ervoor dat bv. de DNS server 8.8.8.8 in Nederland een heel andere is dan die in de VS die ook 8.8.8.8 gebruikt. Netwerk routering aan de border van Google zorgt ervoor dat de AMSIX denkt dat het naar bv. 8.8.8.8 naar Delfzijl moet, terwijl de DUBAI Exchange het naar Californie stuurt.
DNS servers zijn per definitie als gedistribueerd. (13+ voor Toplevel)
Het is daarom indrukwekkend dat diensten als Akamai en OVH onderuit gehaald zijn.

En dat allemaal met name dank zij 30+ jaren laksheid op digitaal veiligheidsbeleid bij ontwikkeling van software. Op zich is dat ook een prestatie.

[Ablaze]

Even een nuancerende reactie

Bitten verplaatsen is slechts de taak van de fysieke laag (netwerkinterface). Een Ethernetnetwerk moet ook routeren (IP) en data op een goede manier transporteren (TCP/andere protocollen). Daarnaast kan netwerkapparatuur zich bemoeien met de applicatielaag (denk aan QoS). Deze middelen kunnen en moeten ingezet worden om dDoS aanvallen minder effectief te maken, dat kan zonder iets te filteren of censureren.

Het is een utopie om te denken dat software zichzelf altijd kan beschermen. Software ontwikkelen is complex en tijdrovend. Om de functionaliteiten te krijgen die mensen tegenwoordig verlangen, moet er gebruik worden gemaakt van software van anderen (besturingssystemen, libraries, drivers, services). In al deze software zitten potentiële fouten. Het is simpelweg onrealistisch om software zodanig ver te testen, dat er gegarandeerd kan worden dat deze beveiligd is tegen alle vormen van misbruik in het heden en de toekomst. Vooral niet omdat alle software waar je van afhankelijk bent, steeds weer evolueert.

De 30+ jaar laksheid die je noemt, is een gevolg van een voortschrijdend inzicht. De mate van misbruik neemt namelijk ieder jaar sterk toe. Het is goed om niets uit te lokken, maar we moeten ook niet vergeten dat een gebrek aan beveiliging geen oorzaak van misbruik is (hooguit een stimulans, op dezelfde manier als een fiets zonder slot dat is). Het is de kwaadwillendheid die je moet bestrijden. Jouw huis heeft waarschijnlijk ook geen stalen voordeur, maar je kunt daarmee leven omdat je weet dat inbraak een misdaad is die actief wordt aangepakt en dat je schade misschien zelfs wordt vergoed.

[Triblade_8472]

De 30+ jaar laksheid die je noemt, is een gevolg van een voortschrijdend inzicht. De mate van misbruik neemt namelijk ieder jaar sterk toe. Het is goed om niets uit te lokken, maar we moeten ook niet vergeten dat een gebrek aan beveiliging geen oorzaak van misbruik is (hooguit een stimulans, op dezelfde manier als een fiets zonder slot dat is). Het is de kwaadwillendheid die je moet bestrijden. Jouw huis heeft waarschijnlijk ook geen stalen voordeur, maar je kunt daarmee leven omdat je weet dat inbraak een misdaad is die actief wordt aangepakt en dat je schade misschien zelfs wordt vergoed.

Die 30+ jaar laksheid is een gevolg van democratie. Het internet is ontworpen door hele slimme mensen. Het waren er maar een paar die het 'voor het zeggen hadden' omdat zij simpelweg de enige experts waren.
Na een aantal jaren is langzaam aan gebleken dat een hoop misbruik kan worden gemaakt met 'oude' technieken en protocollen. Deze moeten dus vervangen of vernieuwd worden. Dit kost geld maar niemand wil het betalen zonder direct commercieel belang.

Hiernaast moeten er tegenwoordig vele overheden (=adviesorganen), communities, commerciele instellingen (Microsoft, Google, Apple) en andere commissies zich ermee bemoeien. En zij moeten allemaal een zegje hebben en polderen. Dit werkt in praktijk gewoon niet.

Ondertussen worden er goede initiatieven uitgevoerd zoals gratis SSL certificaten, DNSSEC, IPSEC enzovoorts, maar dit is (soms) lastig en voor het klootjesvolk simpelweg onmogelijk in te richten. Dit moet geautomatiseerd, anders gebeurt het gewoon niet.

Je spreekt over een stalen voordeur. Ik denk liever aan een zelfde sleutel voor elke huis in een dorp of stad. Je mag wel een eigen slot nemen, maar die is alleen in Italië te verkrijgen. Bijna niemand neemt de moeite!
Ook al heb je een stalen deur (firewall) dan nog is je sleutel hetzelfde (wachtwoord). Ik denk dat dit een betere vergelijking is met het artikel.


Alle modems die je tegenwoordig thuis krijgt hebben een ander wachtwoord dan je buren. Het kán dus wel, alleen moeten alle fabrikanten deze techniek daadwerkelijk gaan hanteren als de standaard. Zo wordt de hele wereld weer een klein beetje veiliger...

[tweaknico]

Die wachtwoorden zijn dan weer vaak afgeleid van het MAC adres dus zo goed is dat nu ook weer niet.
En de alternatieve sloten kun je in de Sahara kopen...

[djwice]

Nou, ik weet niet hoor. Ik heb de afgelopen 20 jaar heel wat kritieke lekken gevonden en hoe daar zo nu en dan mee is om gesprongen...

een voorbeeld
Een bank vond, bij monde van hun head of security, dat de DNB audit voldoende was, en dat er dus geen verdere maatregelen nodig waren.

Nádat ik hem verteld had dat ik binnen 4 uur als elke klant in zijn Mijn omgeving binnen kon komen (incl. de daarbij behorende mogelijkheden zoals adreswijzigen, transacties doen etc).

Dit lek heeft jaren bestaan na mijn melding en gesprek met hem waarin ik heb uitgelegd hoe het werkte.

[Reactie gewijzigd door djwice op 27 juli 2024 07:39]

[tweaknico]

Ethernetwerk routeert NIET. Het is een broadcast netwerk waarbij hubs dat letterlijk nemen en switches verzending staken als er geen geadresseerde achter een poort zitten. (indien bekend, anders wel verzenden).
Hubs en Switches zijn een soort veredelde kroonstenen.

IP is een protocol dat wel gerouteerd kan worden en dat verschillende media als transport kan gebruiken. [ Waaronder Ethernet, Seriele lijnen, postduiven = RFC2549] (IP Laag 3 routeert....).
QoS is geen functie van de applicatie laag, maar van de routerings laag, waarbij de API mogelijkheden bied om opties in te stellen (setsocketoptions() staat niet op het niveau van read()/write()..., anders had je per read/write wel iets in kunnen stellen).

Software moet zichzelf beschermen door gebruik van de JUISTE libraries.
Als OpenBSD dit al jaren kan (inderdaad, heel veel auditwerk in libraries) ...
waarom anderen dan niet..., of waarom de libraries van OpenBSD niet als vertrekpunt nemen.
Ik weet wat software ontwikkelen kost, en ook wat bug-fixing kost.
Een goede software design beslissing (bv. wel nadenken over security) scheelt later ongelofelijk veel reparatie werk.

[supersnathan94]

Veel beveiligingscentrales (zoals Somfy die heeft bijvoorbeeld) zijn wel degelijk goed beveiligd door tabellen met codes. Een beetje het Tan systeem van ING.

[tweaknico]

De spreekwoordelijke uitzondering?... maar is the MITM er ook uitgehaald?
Of maakt je mobiele appraat verbinding met een Somfy Server en maat je huis module ook contact met een somfy sever... en beheert de Somfy server je huis ipv. je thuismodule.
En bij elke opdracht een nieuw nummertje? of een nummertje per sessie?
Kan de sessie gekaapt worden?....

[supersnathan94]

Apparaat is alleen lokaal benaderbaar tenzij je er voor kiest om remote toe te staan via een C&C server van Somfy.

Bij eerste sessie geef je (naast user en pw) een nummertje in en als je admin aanpassingen maakt dan moet je ook bevestigen met een andere code uit de tabel.

Externe verbindingen zijn opt in. Bij in en uitschakelen van het alarm worden er pieptonen afgegeven door de binnensirene, centrale en keypad. Alles zit dicht met vandalswitches en batterijen.

Alleen signal jamming heb ik nog niet gecontroleerd, maar in theorie is een komplete wifi jam voor enkele seconden genoeg om het systeem te triggeren.

Er zijn een aantal bedrijven die veiligheid wel degelijk heel serieus nemen.
- Redundante vandal switches intern en extern.
- redundante powersupply
- redundante verbindingen vanaf de centrale (draadloos via eigen protocol, bedraad via lan en gsm optie)
- inloggen alleen lokaal
- inloggen vereist 2FA
- custom login vereist


Dus ja... het kan wel.

[tweaknico]

Jammer dat remote alleen via Somfy C&C kan...
Het zou bijna kunnen werken. (niet sarcastisch bedoeld)

[Reactie gewijzigd door tweaknico op 27 juli 2024 07:39]

[supersnathan94]

Nouja ik kan zelf natuurlijk wel via VPN dergelijke toegang regelen. Dat is het probleem niet. Ik denk dat het zonder C&C ook wel kan, maar dat deel van het systeem is een beetje vaag, want frans en slechte documentatie. Dus ik houd het liever lokaal met VPN ertussen.

[tweaknico]

Waarom niet....

Als we de leverancier verantwoordelijk maken voor schadevergoeding zolang de apparatuur niet over een zinnige veiligheidsvoorziening beschikt..
Waarbij zinnig moet ook bediend kunnen worden door je technofobe Opa/Oma van 90+ als het bv. een IoT Koffiezet apparaat wordt.
En als de fabrikant van het IoT Koffiezet apparaat niet de mogelijkheid geeft tot beveiliging dan is die fabrikant aansprakelijk...

Moet je zien hoe snel er oplossingen gaan komen.
Op dit moment is het: Risico Fabrikant 0.. gebruiker 100% door nu een kader te scheppen dat het 100%/0% gaan bedrijven wel actie ondernemen...
Op het moment dat dit 50/50 wordt is er evenwicht.
En ja je bent wel degelijk verantwoordelijk voor de spullen die je op je 220Net aansluit, alleen is dat in Nederland afgekocht door een Kema keur.

Als je ooit in huis brand krijgt en een postmortem van de brandweer aantoont dat de brand is ontstaan door nalatigheid van jouw kant(bv. gebruik van apparatuur zonder Kema Keur) gaat de verzekering niet uitbetalen.
En je hebt in zoverre mazzel dat in de EU meerdere instituten elkaar erkennen (TuV vs, Kema...) en elkaars keuringen overnemen dat je in de hele EU goedgekeurde spullen kan kopen. (Andere spullen MOGEN hier niet verkocht worden, als zal dat via Hong Kong mogelijk wel kunnen lukken maar dat is en blijft JOU verantwoordelijkheid... en dus aanspraakelijkheid)

En waarom is het nodig om een rijbewijs te hebben...? Ook een gediplomeerd chauffeur heeft ooit de eerste keer zonder rijbewijs die bus moeten inparkeren, er zijn heel veel zaken die mensen NOG NIET kunnen, maar wel kunnen leren.
Het wordt pas bijzonder als je het de eerste keer in 10 seconden kan zonder enige vorm van schade.

[Anonymoussaurus]

Ja, want krijgt een IP-adres. Maar werkt weer anders om te infecteren dan bijvoorbeeld een IP-camera.

[mkools24]

Volgens mij is wel de voorwaarde dat ze een publiek IP adres hebben, als je SmartTV achter NAT zit gaat het niet werken.

[freaky]

Via port forwards die mensen hebben wellicht wel, ze zetten ook nogal eens poorten naar binnen open die alleen naar buiten hoeven te staan.

Verder zou je ze aan kunnen vallen via andere al besmette apparaten in het netwerk. Of vanaf de router zelf als die te compromiteren is.

En NAT is straks dood met IPv6. Nergens goed voor. Zou wel een stateful firewall in de router houden, geeft in principe dezelfde bescherming.

_{[edit]Lekkere moderaties weer. Wellicht dat iemand me uit kan leggen wat hier OT/irrelevant aan is en/of waarom reacties hierop over hetzelfde onderwerp wel positief gemod worden.[/edit]}

[Reactie gewijzigd door freaky op 27 juli 2024 07:39]

[Anonymoussaurus]

Of het virus zet zelf de poorten open als je een brakke beveiliging hebt .

[thof]

Brakke beveiliging? Het is zelfs een feature: UPNP NAT Traversal.

Hierbij doet de applicatie gewoon het verzoek om de poort te openen in de NAT Router, waarna hij dat gewoon zonder verdere credentials zal doen. Voorwaarde is wel dat UPNP aan staat, wat meestal standaard wel het geval is.

https://en.wikipedia.org/...ug_and_Play#NAT_traversal

[Anonymoussaurus]

Het ligt er maar net aan hoe je het wilt bekijken. Ja, het is een feature, maar als je die misbruikt, is het brakke beveiliging. Je kunt de poorten die je nodig hebt handmatig openzetten zonder UPnP. UPnP maakt het alleen wel een stuk makkelijker. Het is maar wat je meer prioriteit geeft; beveiliging of gemak.

[tweaknico]

uPNP? dat is helemaal een lachertje mbt. beveiliging, Juist om allerlei apparaten aan de binnenkant van buiten uit bereikbaar te krijgen.
Wie zet uPNP uit op z'n firewall?

[Anonymoussaurus]

Wat dacht je van Skype + UPnP? Skype zet zonder pardon forward al meer dan 10 keer. Een kwaadwillende kan die open poorten zo misbruiken.

[tweaknico]

Precies, daarom op mijn firewalls geen uPNP...
en ook Skype wordt niet vaak meer gebruikt.
En zodra die huidige versie geen verbinding meer kan maken met de backends dan vervalt Skype vanzelf.

[Reactie gewijzigd door tweaknico op 27 juli 2024 07:39]

[Anonymoussaurus]

Fysieke firewalls of geïntegreerde in die van je thuis router?

[tweaknico]

Linux PC (gentoo based), iptables, ip6tables, haproxy,
letsencrypt, ejabberd, asterisk, exim, amavisd-new, clamav, DNS server, DHCP server, libreswan ipsec, openvpn, fail2ban icm. nog wat booby traps & honeypots,
+ tools voor routering, netwerk analyze....
ZONDER miniupnpd.

Ik heb geen thuisrouter (of CPE) in m'n netwerk. Er zijn wel 2 AP's
Turris Omnia (OpenWRT) [bg] & Linksys E4200 (dd-wrt) [zolder] . Die verschillende LAN's binnenshuis draadloos beschikbaar stellen.

Intern netwerk:
- VLAN voor TV en Multimedia [ kan niet naar buiten, wel naar twonkymedia server ]
- VLAN voor Gasten Alleen naar internet
- VLAN voor eigen wireless apparaten kan ook naar enkele servers in core netwerk, en naar internet
- VLAN voor core netwerk.
- VLAN voor zakelijke systemen. [ Offsite backup server voor enkele klanten, geheel separaat uitsluitend toegang via IPSEC tunnels ].

Er zijn gevorderde plannen voor (maar nog geen realisatie van ) domotica op basis ven Pine64, Z-Wave, Wifi over een eigen VLAN. mogelijk via een VPN op afstand benaderbaar. Div. componenten moeten nog geleverd worden.

[Dreamvoid]

Mensen begrijpen geloof ik niet hoe UPNP werkt. Van buitenaf werkt UPnP niet. Als de malware al binnen is, dan hoeven er geen poorten via UPnP meer opengezet te worden, dan zet de malware zelf via bv port 80 een verbinding op.

[tweaknico]

Als een applicatie dmv uPNP een link open zet is die applicatie gelijk ook een aanvalsvector geworden (immers accepteert verbindingen).

Dus als applicatie X dmv van gemanipuleerde data een bufferoverflow privilege escalatie heeft. ( kijk eens naar een "onschuldige" netwerk applicatie als finger.) en een uPNP gat in de firewall maakt ben je gelijk gevoelig voor een aanval op applicatie X.

Als ik ZELF een firewall rule maak om dat door te late ben ik evt verantwoordelijk te houden voor die keuze, maar als ik geen gat in de firewall maak omdat het tool op het LAN reuze handig is dan is het nog steeds een veilige keuze... tot uPNP achter m'n rug om de zaak molt.

[Dreamvoid]

Er verandert helemaal niks. Als je al malware op de device hebt draaien (die UPnP port forwarding kan doen), dan kan die zelf via loopback al naar diezelfde applicatie toe gaan, daar hoef je geen poorten voor open te zetten.

UPnP is een vorm van 'schijnonveiligheid'.

[Reactie gewijzigd door Dreamvoid op 27 juli 2024 07:39]

[tweaknico]

ik praat niet over de periode dat er al malware draait maar voordat die binnen kan komen....

Applicatie X heeft een zwakheid heeft privilege escalatie mogelijkheden EN maakt een uPNP opening. Eigenlijk is applicatie X bedoeld voor een stuk interne communicatie maar niet voor extern gebruik.

Deze opening wordt vervolgens door malware gebruikt om in te breken op applicatie X.
Bij een Firewall zonder uPNP is er nooit een verbinding met de buitenwereld mogelijk... tenzij de beheerder dat instelt.

Als je op zoek wil naar wie wereldwijd welk poortje en protocol toestaat: kijk eens op http://shodan.io ... netjes in categorieen maar ook custom doorzoekbaar. ALLE IP adressen in de wereld.
Als ik naar m'n firewall logs kijk dan is er een permanent constante portscan van enkele 10 tallen scanbots per dag aan de gang.

Alle applicaties die uPNP nodig hebben zouden een security audit moeten ondergaan!

[Reactie gewijzigd door tweaknico op 27 juli 2024 07:39]

[Dreamvoid]

Bij een Firewall zonder uPNP is er nooit een verbinding met de buitenwereld mogelijk

Jazeker, als applicatie X een verbinding opzet van binnenuit - dat is je risico. Je kan op je firewall op zich alles blokkeren voor dat IP adres natuurlijk, inkomend en uitgaand, maar dat is doorgaans niet wenselijk.

Eigenlijk is applicatie X bedoeld voor een stuk interne communicatie maar niet voor extern gebruik.

Die applicaties zijn er alleen niet. Voor lokale netwerkservices worden in de praktijk in 99.9% van de gevallen discovery methodes als Bonjour gebruikt. Ik bedoel, een iTunes of lokale DLNA server of zet geen poorten open naar buiten. En dingen als Skype, Back-to-my-Mac, Plex Media Server enzo hebben expliciet open poorten nodig om te kunnen werken, dat moet je zonder UPnP alsnog handmatig doen.

Je zou wettelijk kunnen eisen dat *alle* poorten standaard dichtgegooid worden bij consumenten internet abonnementen, dat lost een hoop op. Uberhaupt geen inkomende connecties meer, alleen uitgaande verbindingen. Dan werken alleen een hoop services niet meer, geen Skype, geen VNC, geen SSH, geen slimme thermostaten, niks.

[Reactie gewijzigd door Dreamvoid op 27 juli 2024 07:39]

[tweaknico]

Ok, engie uitbreiding:
Bij een firewall zonder uPNP is een verbinding van buiten naar binnen niet mogelijk zonder dat deze expliciet geconfigureerd is.....

Uitgaand is MEESTAL free for all... maar dat hoeft ook niet, dat kan best beperkt worden door bv. poort 25 uitsluitend toe te staan vanaf de mailserver.. Ik denk dat als je bereid bent om dergelijke configuraties te doen in je firewall dat daar verminderde aansprakelijkheid bij gebruik van jouw systemen als aanvals vector zou mogen meewegen!

En dingen als Skype, Back-to-my-Mac, Plex Media Server enzo hebben expliciet open poorten nodig om te kunnen werken, dat moet je zonder UPnP alsnog handmatig doen.

En wat is er mis om dat expliciet te regelen? in plaats van een lek op een firewall te maken....

Je zou wettelijk kunnen eisen dat *alle* poorten standaard dichtgegooid worden bij consumenten internet abonnementen, dat lost een hoop op. Uberhaupt geen inkomende connecties meer, alleen uitgaande verbindingen. Dan werken alleen een hoop services niet meer, geen Skype, geen VNC, geen SSH, geen slimme thermostaten, niks.

Hier beschrijf je censuur... Maar slimme termostaten werken nog uitstekend hoor, de sturen alleen maar data naar de centrale server van Nest/.Toon/Easy etc. en jij mag die data daar dan inzien.....
je mag ook opdrachten achterlaten op die server waarbij jouw Toon/Nest/Easy etc. die dan weer ophalen en uitvoeren.
(De C&C server).

[tweaknico]

NAT is geen beveiliging, alleen adresruimte uitbreiding met een paar bitjes, voor beveiliging heb je een firewall nodig. En dan een zonder "automatiseerbare gaten" die uPNP levert.

[freaky]

SNAT biedt wel degelijk wat beveiliging (in de meest voorkomende implementaties er van in ieder geval). Niet meer dan een stateful firewall doet echter. Gezien de manier waarop (S)NAT werkt komt het standaard met een stateful firewall in alle opzetten die ik gezien heb (en dat zijn er aardig wat - van simpele routers t/m UTMs), het is theoretisch wel mogelijk zonder, maar wat dingen zouden buiten de firewall om voor pure NAT geimplementeerd moeten worden om het werkend te houden. Zeker voor protocollen als FTP.

Een NAT tabel houdt idd ook source en destination ports bij. Soms zelfs TCP sequence numbers e.d. Dit om meer vertalingen te kunnen doen en verkeer van 192.168.1.1 en 192.168.1.2 naar bijv. tweakers.net:80 uit elkaar te kunnen houden en correct terug te kunnen NATen. Dat breidt de adresruimte echter niet uit. Adresruimte, is en blijft, 32 bit op v4 (en 128 bit op v6).

uPnP is geen NAT en ik zet het standaard uit ook. Zoals je al zei is het een manier om automatisch gaten in je firewall te maken. Veelal voor mensen zonder kennis, gemak en/of veel niet al te beste protocollen met bergen aan random poorten voor inkomend verkeer. Je kunt uPnP net zo goed toe passen op publiek v4 of v6 intern. Kan de firewall nog steeds een gaatje maken, zonder dat er ergens NAT is.

Ik haalde NAT aan omdat degene waarop ik reageerde zei dat een TV achter NAT niet te bereiken is en een beetje omdat velen nog steeds denken dat v6 zonder NAT onveiliger is dan private v4 adressen achter NAT. Een stateful firewall vangt dat laatste prima af zonder NAT. Net zo goed als de gemiddelde NAT router (met stateful firewall). Het is net alsof het dezelfde techniek betreft, minus het SNAT deel dan...

[tweaknico]

NAT breidt de adres ruimte uit (dat is ook het enige waarvoor het bedoeld is) doordat je de mogelijkheid hebt om meerdere apparaten achter een IP adres te stoppen.

Je ruilt een paar sourcepoort nummers in om deze interne onderscheiding te maken. Dus ja NAT is een uitbreiding van de adres ruimte met een paar bits.

uPNP is geen NAT maar een omgeving waar NAT gebruikt wordt en waarbij een externe partij naar binnen moet kunnen voor data transport heeft een Hole-Puncher nodig..., uPNP is de hole-puncher zowel voor een firewall als voor de NAT inrichting.

NAT wordt ten onrecht voor beveiliging aangezien, en met de houding van mensen mbt. beveiliging zie ik een statefull FW inrichten nog steeds niet gebeuren als NAT niet meer nodig is. (Het is geen beveiliging maar de deur staat op een kier ipv wijd open.)

[Dreamvoid]

Ook in een situatie zonder NAT heb je een holepuncher nodig - in een IPv6 wereld is er geen NAT meer, maar zit er op de doorsnee consumenten router (en elke provider box) nog wel een firewall die specifieke inkomende connecties moet doorlaten als dat nodig is voor de applicatie erachter.

[Reactie gewijzigd door Dreamvoid op 27 juli 2024 07:39]

[tweaknico]

Kwestie van configureren, en een configuratie toolkit aanleveren die door jan en alleman gebruikt kan worden......
Blanko gaten boor is in iedergeval geen antwoord....

EN als de gebruiker (niet de fabrikant) er dan voor KIEST om de zaak z'n beloop te laten gaan dan is ook een kwestie van wie z'n gat brand moet op de blaren zitten.
Dus imho automatische holepunchers/gaten boren zijn kwaadaardig.

[freaky]

Een mapping table is geen uitbreiding.

Ik kan namelijk niet zomaar een poort nummertje invullen, vanaf een adres komen dat niet in je mapping table staat en verwachten dat ik dan ineens bij een intern systeem van je uitkom.

Als je dat denkt zou ik toch maar eens beter nagaan hoe zo'n mapping table werkt.

Wat je nu impliceert zou er op neer komen dat je systemen extern benaderbaar zijn als je de juiste poort nummertjes van die 'adres uitbreiding' van je van maar weet. En zo werkt het dus niet. Het is wel mogelijk als je port forwarding doet, dat is DNAT, geen SNAT en is nog steeds geen uitbreiding van de adres ruimte.

Het doel van de sloot om m'n huis is om het mooier te maken en het regenwater van de wijk op te vangen evenals wat waterbeheer. Neemt niet weg dat het de beveiliging van m'n huis aan de zijkant en achterkant wel verhoogd. M.a.w. nee, NAT is niet gemaakt voor beveiliging, maar het draagt er wel enigszins aan bij.

[tweaknico]

Ik kan namelijk niet zomaar een poort nummertje invullen, vanaf een adres komen dat niet in je mapping table staat en verwachten dat ik dan ineens bij een intern systeem van je uitkom.

Als je dat denkt zou ik toch maar eens beter nagaan hoe zo'n mapping table werkt.

Je geeft nu precies aan waarom NAT een kwaadaardig verschijnsel is in een BEHEER(S)BAAR netwerk. Dank je daarvoor.

Ik heb helemaal geen willekeurig poortnummertje nodig als bv. VOIP (over SIP) poort 5060 gebruikt en alle apparaten die met
hun ADRES ipv. ADRES+POORT bereikbaar zijn.
Er is dan ook geen Bridge hulp nodig, geen connection tracking , geen STUN (in al z'n varianten)

ADRES+POORT is nu het adres, zie je nu waarom NAT alleen maar een adres uitbreiding is, overigens is NAT gelijktijdig met IPv6 geintroduceerd als een Quick stopgap omdat IPv6 naar verwachtin meer tijd zou gaan nemen dan er IPv4 adressen beschikbaar zouden zijn.
En inmiddels zijn de IPv4 adressen buiten de US en EU ongeveer op.

En wat betreft je sloot, inderdaad vergelijkbaar. En uPNP is een willekeurig neergelegde loopplank over die sloot.
Door een metselaar die toevallig op je erf bezig was, maar kan nu ook door iedereen gebruikt worden om de sloot over te steken.

[Reactie gewijzigd door tweaknico op 27 juli 2024 07:39]

[freaky]

uPnP is geen onderdeel van NAT. Het staat op zichzelf. Wij hebben geen 1, zakelijk, beheersbaar, netwerk waar uPnP aan staat. Sterker nog, in veel zakelijke firewalls zit niet eens uPnP.

Draai thuis VoIP. En veel andere dingen, daar niet van.

Je kan echt niet bij mijn VoIP client komen van buitenaf, ook al zou je mijn adres en het (erg voorspelbare gezien standaard) poort nummer in dat geval weten. Jouw adres staat niet in mijn mapping table naar buiten en je verkeer komt er dus gewoon niet in. Heb geen port forward voor 5060 nl. en je staat dus niet in m'n mapping table want mijn client legt geen verbinding met jou en die table controleert dus source IP/port en dest IP/port.

Maar goed, wellicht is jouw idee van 'beheersbaar' dat je overal port forwards voor aan maakt, zou zomaar kunnen, maar dat is DNAT, geen SNAT en dan zet jij (of je uPnP) heel bewust (nah ja, met uPnP ben je je er ws niet van bewust) iets open. Dat is niet NAT z'n fout, noch NAT z'n tekortkoming.

Die port forward kun je net zo goed vergelijken met een open zetten van een poort op een stateful firewall op een IPv6 netwerk met allemaal publieke adressen. Feitelijk is het zelfs hetzelfde + een destination NAT regel, in veel firewalls/beheer interfaces in 1 regel te regelen overigens. Om het in iptables termen te houden voor je, een DNAT regel in je PREROUTING en een accept regel in je FORWARD. Op IPv6 met publieke adressen intern heb je dan alleen die FORWARD regel nodig dus.

Bovendien, voor de goede orde, gebruikt mijn client een random (source) port > 1024 die verbind aan poort 5600 op de centrale (extern).

Dus stel:

192.168.0.11:28922 -> 30.30.30.30:5600
Komt voorbij de router, die gaat NAT'en, vertaalt het pakketje: 192.168.0.11:28922 -> 30.30.30.30:5600 naar 20.20.20.20:33221 -> 30.30.30.30:5600
Komt verkeer terug van 30.30.30.30:5600 -> 20.20.20.20:33221, kijkt in zijn tabel of die combinatie voor komt, vind hem in z'n tabel en vertaald 20.20.20.20:33221 -> 192.168.0.11:28922.

Nu kom jij aan vanaf 40.40.40.40:5600, en je raadt/weet/whatever het poortje en stuurt verkeer naar 20.20.20.20:33221. Wordt in NAT tabel gekeken, combinatie komt niet voor, bestaan geen port forwards en heb niet zo'n achterlijke forward alles maar naar deze server regel en dropped het verkeer dus gewoon (of stuurt ICMP dat het niet beschikbaar is).

Zelfs als m'n client een vaste poort gebruikt en de router geen noodzaak ziet om een andere te pakken, sta je nog steeds niet in die tabel en komt je verkeer er dus gewoon nog steeds niet in.

[tweaknico]

Leuk dat je NAT probeert uit te leggen en hoe het werkt.
Ja ik weet dat uPNP niet bij NAT as such hoort, maar doordat NAT zo'n grote vlucht heeft genomen was er ineens iets nodig dat een apparaat binnen (bv. bittorrent client, of een VOIP toestel om een paar populaire te noemen) aan de buitenkant een poortje beschikbaar stelt voor toegang van buiten naar binnen voor een HELE reeks van torrent leveranciers. Gesprekken.
Daarnaast is dan STUN nodig om het uiteindelijke externe adres te bepalen zodat vervolgens het externe poortje + adres aan de rest van de wereld geroepen kan worden....

zowel uPNP en STUN zouden niet nodig zijn als er geen NAT tussen zat. Op z'n best moet er iets in de policies van de firewall staan over de wenselijkheid van dergelijke verbindingen.
Daarnaast is er voor VOIP iets nodig zodat de SIP stream gevolgd kan worden om de benodigede NAT entries voor te bereiden voor de onvermijdelijke 2+ RTP sessies.
Terwijl zonder NAT zowel uPNP als STUN als Connection tracking overbodig zijn, slechts firewall policies zouden voldoende zijn.
(en zijn dat ook in een NAT loos netwerk).
Zonder NAT:
* kan ook de SIP header een 30% kleiner worden, hebben telefoon centrales geen NENC en FENC (near/far end nat compensation nodig)
* zijn er geen ALG/SBC in Firewalls nodig voor allerlei niet single channel protocollen.
* kan televisie zonder 100% track en trace mogelijk zijn via Broad/Multicast wat weer efficienter is voor het netwerk tov. 1 a 2 TCP Sessies per Beeldscherm per klant .

En heb je het volgende al een geprobeerd? NAT achter een NAT router, en kombineer dat eens met VOIP.

[Anonymoussaurus]

Dat klopt, maar NAT staat niet standaard aan in elke router. Bij een bedrijf waarschijnlijk wel. Sowieso heb je er dan een aparte firewall achter hangen.

[tweaknico]

NAT is geen veiligheids methode, alleen een methode om wat bitjes van poortnummers toe te voegen aan de adres ruimte van IP adressen.

Zodat er ipv. 3 miljard apparaten ongeveer 16-32 * zoveel (4 - 5 bitjes extra adres ruimte) aangesloten kunnen worden.
Daarnaast zorgt het voor extra barrières voor bv. VOIP die daardoor nodeloos extra complex wordt.

[Anonymoussaurus]

Dat weet ik . Maar als je apparaat achter NAT zit, is het lastiger om dat apparaat te bereiken.

[tweaknico]

mede dank zij uPNP dus niet. En veel apparaten werken "Beter" door uPNP niet op de CPE uit te zetten. De vraag is voor wie dat "beter" geldt.

[Verwijderd]

Waarom het apparaat bereiken? Het is gewoon Network Address Translation, een vertaalslag naar binnen. Alle werkstations in het netwerk kunnen prima naar buiten praten en NAT heeft hier niets mee te maken, maakt dit ook niet moeilijker.

Pas als we praten over een firewall, dan kun je ervoor zorgen dat apparaten met bijv. door QoS gelimiteerd naar buiten kunnen gaan of bij bepaald gedrag geblokkeerd worden.

[Anonymoussaurus]

Dat was even los gezegd van DdoSsen. Meer als je bijvoorbeeld op afstand toegang wilt krijgen.

Want als je een virus hebt die jouw apparaat in een botnet gebruikt, maakt het uiteindelijk niet zoveel uit welk apparaat er is besmet.

[Yggdrasil]

Niet per se. Als malware binnen je LAN terecht komt, bijv. via je laptop of telefoon dan kan deze proberen lokale apparaten te besmetten. Als dat lukt dan kunnen die apparaten eenvoudig de buitenwereld aanvallen.

[Speleding]

In theorie wel, maar een Smart TV zal over het algemeen achter een router/firewall zitten waardoor hij moeilijker te misbruiken is door derden. Het problem is vooral routers en IP camera's die direct aan het internet hangen of waarvoor de firewall openstaat zonder fatsoenlijke beveiliging waardoor ze op afstand geïnfecteerd kunnen worden.

[MsG]

Half Nederland heeft upnp aanstaan in de router. Dus de malware, mits eenmaal binnen, kan gewoon zelf de poorten open zetten in de router.

[hackerhater]

upnp zou moeten sterven. Probleem oorzaak nr 1 waardoor je ook nog niet eens op je netwerk-firewall kan vertrouwen.
Ik zet het altijd uit.

[Dreamvoid]

Als malware al binnen is, dan heb je geen open poorten nodig, dan legt de malware zelf de verbinding wel.

[ariekanari]

Daarnaast maken smart-tv's gebruik van servers van de fabrikant en ik vermoed dat deze servers dan snel plat zullen liggen. En zodra dat dat het geval is, smart-tv niet meer werkt.

Een storing van smart-tv houdt vaak in dat geen contact kan worden gemaakt met de server van de fabrikant (zogenaamd voor "versiecontrole" van de software). En andere apps vaak niet meer naar behoren werken ook als deze niet rechtstreeks gebruik hoeven te maken van de servers van de fabrikant, denk aan YouTube, Facebook, etc.

Ik denk dat smart-tv's daarom minder snel voor een ddos-aanval zullen worden gebruikt. Alhoewel, de hackers zijn waarschijnlijk slim genoeg om dit te omzeilen.

[Anonymoussaurus]

Als jouw smart-TV geïnfecteerd is, gaat dat via jouw thuis internet (de DdoSs aanval), niet via de servers van de fabrikant van de TV.

Inderdaad, en vergeet ook niet dat het schrijven van een virus totaal anders werkt voor TV's dan bijvoorbeeld Windows machines.

[evilution]

Het schrijven van een virus voor een webcam is vast ook heel anders dan voor Windows machines maar dat was in dit geval toch overkoombaar

[Anonymoussaurus]

Ligt eraan. Bedoel je een IP-cam? Of een doodgewone webcam? Een webcam zit aangesloten op je Windows/Linux/whatever machine. Als die geïnfecteerd raakt, ben je alsnog de sjaak.

[Room42]

Dat ze de server van de fabrikant nodig hebben voor de normale taken maakt niet dat ze niks anders kunnen. Het zijn gewoon (embedded) computers, dus die kunnen gewoon eigen code draaien, als de beveiliging omzeild is. Daarna is het niets anders meer dan je IP-cam, router, printer, telefoon, computer.

[misterbennie]

Klopt, mijn android TV heeft gewoon alle rechten die je maar kunt bedenken.

(Misschien die rechten toch een beetje intomen ;-) )

[TunderNerd]

Alles met de capaciteit om berichten over het internet te sturen is in feite geschikt voor een DDOS aanval, Jouw smart TV is diep van binnen een Linux computer, dus die kan prima gebruikt worden!

[MrHarry]

maar wie sluit zijn smarttv nou direct aan op internet, meestal staat er een firewall/router al voor iig hier in nederland ken ik geen enkele provider meer die je de mogelijkheid geeft om een apparaat direct aan internet te sluiten waarbij het device zelf dus het wan ip adres toegekend krijgt.

[Anonymoussaurus]

Nou. Heel veel consumenten. Mensen die al een smart TV hebben, hebben dan geen Chromecast nodig. Zij willen bijvoorbeeld Netflix kijken. Daarvoor heb je toch echt internet nodig.

[Ford Prefect]

Volgens mij ben je in dat geval nog altijd de initial connection vanuit je TV aan het opbouwen. Tenzijn je een rigged application hebt draaien op je Smart TV of je TV in DMZ hebt draaien moet een botnet toch eerst wel een manier vinden om remote mijn Smart TV te benaderen. Bij IP Camera's is dat anders, vaak hangen die direct met een webinterface aan een public IP adres waardoor het gewoon mogelijk is om remote bij de interface te komen.

[tweaknico]

uPNP pinholes juist door de TV gemaakt voor betere toegan voor diensten als Netflix etc.???

[Anonymoussaurus]

Naja, vroeg of laat zal zo'n connectie toch naar je router/modem moeten gaan. Dus of het nou via je pc, telefoon, tablet, TV, IP-camera, of slimme meter gaat, maakt dan ook niet meer uit. Ze trekken gewoon de volle upload en sturen die data buiten je LAN.

[Reactie gewijzigd door Anonymoussaurus op 27 juli 2024 07:39]

[Noppie1991]

Hij verwijst naar het toewijzen van een publiekelijk adres rechtstreeks op het apparaat (in dit geval een tv). Hoewel veel mensen een tv hebben met internetaansluiting erop aangesloten zit dat nog steeds achter een router/firewall en is het (als het goed is) niet van buitenaf te benaderen.

Echter maakt dat in het geval van een ddos aanval niet zoveel uit, omdat het vaak geïnfecteerde pc's zijn die meedoen met zo'n aanval. Dat de tv ook geïnfecteerd zou kunnen raken door die pc in het netwerk is denk ik best mogelijk. Waardoor de tv dus ook lekker meedoet. Dit kan natuurlijk gelden voor elke Internet of Things apparaat. De slimme meter in je meterkast die lekker meedoet met de ddos?

[Reactie gewijzigd door Noppie1991 op 27 juli 2024 07:39]

[RGAT]

Zowat elke provider heeft deze mogelijkheid
Zet je modem in bridge (of laat m door de ISP zo instellen bij bijv. ziggo) en de firewall, NAT enz gaat volledig uti en je krijgt achter je modem gewoon publieke IP's...
Zo heb ik vroegah nog problemen gehad met een lan party toen de Casema helpdesk me vertelde dat ik echt een router had en een switch daarom geen probleem was, ineens een tiental publieke IP's...

[Tozz]

Ehm, nee. Als je de modem in bridge mode zet kun je er 1 apparaat op aansluiten. Die krijgt 1 IP. Je kunt niet je hele interne netwerk op het Ziggo netwerk aansluiten, want die krijgen niet allemaal een IP-adres van Ziggo.

Kortom, als je meer dan 1 apparaat hebt dat INternet moet hebben moet je er nog altijd zelf een router tussen zetten.

Heeeeel vroeger was het inderdaad zo dat je wel meerdere IPs kreeg, maar dat is al wel een decennia geleden.

[.oisyn]

Dat ligt echt helemaal aan de configuratie van je provider, hoor. Ik heb in het verleden ook een tweetal internet-abonnementen gehad bij providers die doodleuk publieke IP's toekennen aan al je lokale netwerkapparatuur omdat het modem de DHCP aanvragen gewoon naar de DHCP server van de provider bridget.

[Annihlator]

Raar geconfigureerd bij de provider dan, normaal krijg je die adrestoewijzing namelijk pas bij het aanmaken vd ppp sessie, en dat zal het apparaat niet zomaar pogen zonder dat in te stellen... er zijn providers die subnets aanbieden, maar ook daar gaat dat mbv de ppp sessies (naar mijn weten).

[Mezz0]

jouw smart tv wordt door een ander apperaat op je netwerk geinfecteerd. Daarna kan hij zonder problemen naar buiten communiceren.

[r_AllocStarByte]

Lijkt mij van wel. Veel van deze firmware is gebaseerd op Unix/Linux en als een beveiligingsonderzoeker ergens een gaatje gevonden heeft en deze niet door de fabrikant gepatched zal worden loopt je TV een risico als het package waar het probleem in zit internet facing is c.q. als je TV aan het internet hangt. Maar waarschijnlijk is dit risico vrij laag, eerder zie je weather stations, cctv camera's, PI's, oude cmses en andere troep in een IoT botnet. TV's ben ik zelf nog niet tegengekomen. Dit kan zijn omdat ik misschien niet voldoende onderzoek heb gedaan maar in principe kan het dus wel

Let wel op bij de nieuwe HDMI versie zit er ethernet in je hdmi kabel die wellicht op je decoder aangesloten is die aan het internet hangt. Je snart TV doet data mining. Zoals het versturen van bestands namen van je USB mounted harddisk. Dit was geloof ik bij LG smart TV's zo. Geen idee of andere fabrikanten dit ook doen.

[Reactie gewijzigd door r_AllocStarByte op 27 juli 2024 07:39]

[totaalgeenhard]

Zal wel een dure operatie worden.

Als je camera's van een paar tientjes gaat terugnemen......

Ze hadden beter vooraf een auto update erop kunnen zetten die gebruiker alleen uit kan zetten indien hij een email zou stellen om notificatie met een directe link naar update op device te kunnen ontvangen.

Want het gaat alleen maar meer problemen geven met "embedded" systemen die ongepatched en vele jaren in gebruik blijven.

Ik heb klanten gezien die Panasonic IP camera's die al 10 jaar online hangen, om maar te zwijgen van DVR'recorders.

Omdat hardware minder snel defect gaat of helemaal geen roterende (aan slijtage onderhevige) onderdelen bevatten kan het allemaal heel lang ongepatched (en onbeheerd) aan het Internet blijven hangen.


Op de website van http://www.xiongmaitech.c...duct/product-list/151/0/3 staan alleen modules waarmee je een IP cam kunt maken en geen complete producten.

Waarschijnlijk leveren ze de onderdelen waarmee anderen de eind producten mee leveren.

Dus er zal wel sprake zijn van miscommunicatie met betrekking tot het terugnemen van webcams.

Our business mainly involves in security monitoring module, main board, supporting software and product solutions which contains AHD models as well as its motherboards, network HD models as well as its motherboards, AHD/network integration movements, automatic focusing modules, QQ content couplet modules , CMS, VMS, SNVR, MYEYE monitoring platform software, cloud services and so on.

http://www.xiongmaitech.com/en/index.php/about/company/18

[Reactie gewijzigd door totaalgeenhard op 27 juli 2024 07:39]

[Kenhas]

Dacht iets vergelijkbaars toen ik tijdens het lezen van het artikel de naam eens op zocht. Het is een fabrikant van onderdelen. Raar als zij producten rechtstreeks gaan terug roepen.
De modules zullen waarschijnlijk wel in veel toestellen aanwezig zijn maar is het niet aan de fabrikant van het uiteindelijke toestel om zaken terug te roepen.

Blijkbaar is de "paswoord veranderen bij eerste gebruik"-regel van toepassing sedert september 2015. Maar de modellen ervoor werken dus gewoon met een standaard admin account en paswoord. En, als het toestel eenmaal correct werkt, hoeveel keer logt iemand nog in op het toestel. Heb ook enkele camera's hangen en daar is het ook al meer dan een jaar geleden. Camera's kunnen niet op internet maar toch ...

[totaalgeenhard]

IP camera's hangen vaak in een netwerk (anders heb je er niets aan).

Als je remote over het Internet op de camera's kunt inloggen of als er in het netwerk ergens een DVR of NVR zit die je over het internet kunt bereiken, heb je daar het begin van een pad naar ellende.

[Kenhas]

Camera's zijn enkel te bereiken van op intern netwerk, via synology surveillance dinges.
Dus je moet al kunnen inloggen op de synology om aan beelden te geraken.

De IP camera's hebben geen toegang tot internet en zijn niet van buiten bereikbaar

[totaalgeenhard]

Beelden maak ik me het minst zorgen over.

Als ze op e.a. manier alleen bij de streams kunnen komen, is het probleem (betrekkelijk) klein.

Wat ze tegenwoordig doen is devices remote rooten en hun eigen code (scripts) op draaien.

Wat ze naast DDoSsen kunnen doen is alle devices en shares in je lokale netwerken afstruinen.

Het is een kwestie van tijd dat er een worm zal verschijnen die gewoon significant deel van veel gebruikte devices zal kunnen penetreren en lokaal verder tracht te verspreiden.

[Milosonator]

Het virus past de firmware op de camera aan zodat deze geen updates meer ontvangt AFAIK.

[totaalgeenhard]

Aanvalsvector gebruikt een exploit, op zerodays na, zal het altijd een aanval betreffen die "embedded" besturingsysteem waarin een lek zit omdat die niet gepatched is (b.v. oude kernel, oude http deamon etc..).

Als dit soort devices gewoon updates ontvangen, zijn ze niet meer vatbaar voor bekende bugs.

En zerodays doe je inderdaad niets aan.

Overigens denk ik niet dat ze firmware gaan zitten aanpassen. Het compilen voor elke platform en testen is gewoon niet te doen. Vaak zit er gewoon een shell op (of remote exploit upload een shell) waar je basale scripts, die je dus voor meeste platformen kunt draaien. Dan hoeven zich alleen bezig te houden met exploiten van device en verder niets.

[eborn]

Mijn ervaring met die IP-camera's van een paar tientjes is dat het qua software allemaal rommel is. Webinterfaces die gebouwd zijn op techniek uit 2008, alles wordt gewrapped via cgi-scripts die op de meest random plekken gedraaid worden en vaak geen enkele vorm van parameter checking gebruiken. Scripts die opeens zonder authenticatie aan te roepen zijn, waardoor je eigenlijk de complete authenticatielaag van je camera omzeild.

'Streams' van camera's met MJPEG ondersteuning lopen vaak wel beveiligd via een cgi-script. Maar h264 streams worden regelmatig gewoon onbeveiligd via een rtsp linkje aangeboden. Je mag echt blij zijn als er Basic authenticatie overheen zit. Maar goed, dat is allemaal weer redelijk nutteloos als je camera geen HTTPS ondersteund. En laat dat bij die goedkope Chinese rommel nou bijna nooit het geval zijn.

Overigens maken niet alleen kleine Chinese bouwers er een rommeltje van. Ik gebruik bijvoorbeeld ook een Babycam van D-Link. De hardware is prima, maar de software is een drama. In het begin had deze camera, net als andere IP-cam's van D-Link, een uitgebreid admin panel. Deze bleek echter lek, waarna men gewoon het hele admin panel verwijderd heeft. Prima natuurlijk, maar hierdoor kun je opeens de meest basic dingen niet meer doen met de camera (IP adres wijzigen, poorten aanpassen, tijdzone wijzigen...). Hang je de camera nu achter een router met uPNP ondersteuning, dan gooit de router opeens poortjes 80 en 443 naar de webcam. Leuk als je thuis een server draait...

[Reactie gewijzigd door eborn op 27 juli 2024 07:39]

[totaalgeenhard]

Los van kwaliteit van software, vertrouw jij de leverancier van je software ?

Zeker met camera's wil je niet dat derden meekijken (tenzij je hem om die reden hebt gekocht.)

Gewoon IP restricten (onhandig..) of via een VPN op je lokale netwerk binnen komen en zo die devices benaderen.

Verder Internetverkeer outbound niet toestaan van je device, je weet niet waar hij dingen naar toe kan sturen.

Er is een zoekmachine voor lekke devices, kan even niet op de naam komen.

[The_Woesh]

Ze hadden beter vooraf een auto update erop kunnen zetten die gebruiker alleen uit kan zetten.....

Als die apparaten zo makkelijk te hacken zijn kan de fabrikant ze zelf niet hacken en zo de firmware upgraden? Juridisch zal dit wel lastig zijn maar als het internet gevaar loopt is dat wellicht te rechtvaardigen?

[totaalgeenhard]

Als een device al reeds gehacked is, kan je weinig doen als je niet precies weet hoe/wat/waar.
Beste is dan om gewoon device weg te doen. Ook bij PC's kun je dingen dien op harddisk en bios nivo, waardoor het formatteren van je schijf niet voldoende is om van iets af te komen.

Maar preventief updaten van lekke versies voorkomt veel. (zie ook me overige reacties)

[CAPSLOCK2000]

Zal wel een dure operatie worden.

Als je camera's van een paar tientjes gaat terugnemen......

Ze hadden beter vooraf een auto update erop kunnen zetten die gebruiker alleen uit kan zetten indien hij een email zou stellen om notificatie met een directe link naar update op device te kunnen ontvangen.

Ik hoop dat anderen er van leren. Het geld dat ze hebben uitgespaard door geen (auto)updater toe te voegen raken ze nu dubbel en dwars kwijt.
Ik vrees alleen dat de meeste fabrikanten dat gewoon als bedrijfsrisico zien: 10 tegen 1 krijg je er nooit problemen. Je apparatuur is misschien lek en je gebruikers het haasje, maar er komt toch niet niemand naar China om te klagen. Volgend jaar kopen toch gewoon weer het goedkoopste prul van de Mediamarkt.

[totaalgeenhard]

Totdat er wet- en regelgeving komt mbt productaansprakelijkheid.... (zal niet gebeuren, maar dat is wel een oplossing).

[CAPSLOCK2000]

Totdat er wet- en regelgeving komt mbt productaansprakelijkheid.... (zal niet gebeuren, maar dat is wel een oplossing).

Ik vind dat dit soort gebreken gewoon onder garantie horen te vallen. Je hebt een product gekocht waar vanuit de fabriek een fout in zit, en ook nog een probleem dat je als klant eigenlijk niet van te voren kan ontdekken.
Als er zo'n fout gevonden wordt, binnen een redelijke periode na aanschaf, dan moet de winkelier/fabrikant die herstellen. Dat zal een hoop hard- en software een stuk duurder maken maar dat moet dan maar. Als fabrikanten die kosten niet maken dan komen ze uiteindelijk bij de klanten uit en zijn we met z'n allen samen nog veel duurder uit.

[CAPSLOCK2000]

Waarom zou een lek in software onder garantie vallen ?

Omdat de wet zegt dat je recht hebt op een product zonder die fouten.

Je betaald toch immers voor de functionaliteit van een iot device en zolang dat voldoet is security je eigen probleem.

Nee, je betaalt voor een compleet product. Veiligheid is deel van het product dat je koopt. Een auto koop je ook met remmen, bumpers en kreukelzones. Geen enkele autofabrikant gaat je vertellen dat je de kreukelzone zelf maar moet inbouwen.

[totaalgeenhard]

Omdat de wet zegt dat je recht hebt op een product zonder die fouten.

De wet zegt niets. Het zijn dode bomen boekwerken met globaal "catch-all" bepalingen.

En in de geest van de wet (aan rechters te bepalen) de toepasbaarheid per zaak te toetsen.

Artikel 185Aansprakelijkheid producent

1.De producent is aansprakelijk voor de schade veroorzaakt door een gebrek in zijn produkt, tenzij:
a. hij het produkt niet in het verkeer heeft gebracht;
b. het, gelet op de omstandigheden, aannemelijk is dat het gebrek dat de schade heeft veroorzaakt, niet bestond op het tijdstip waarop hij het produkt in het verkeer heeft gebracht, dan wel dat dit gebrek later is ontstaan;
c. het produkt noch voor de verkoop of voor enige andere vorm van verspreiding met een economisch doel van de producent is vervaardigd, noch is vervaardigd of verspreid in het kader van de uitoefening van zijn beroep of bedrijf;
d. het gebrek een gevolg is van het feit dat het produkt in overeenstemming is met dwingende overheidsvoorschriften;
e. het op grond van de stand van de wetenschappelijke en technische kennis op het tijdstip waarop hij het produkt in het verkeer bracht, onmogelijk was het bestaan van het gebrek te ontdekken;
f. wat de producent van een grondstof of fabrikant van een onderdeel betreft, het gebrek is te wijten aan het ontwerp van het produkt waarvan de grondstof of het onderdeel een bestanddeel vormt, dan wel aan de instructies die door de fabrikant van het produkt zijn verstrekt.

2.De aansprakelijkheid van de producent wordt verminderd of opgeheven rekening houdende met alle omstandigheden, indien de schade is veroorzaakt zowel door een gebrek in het produkt als door schuld van de benadeelde of een persoon voor wie de benadeelde aansprakelijk is.

bron: http://www.uwwet.nl/wette...ent-schade-vergoeding.htm


Wat is een fout in software ? Als jij iets koopt met bepaalde functionaliteit (zoals een IP camera) en hij doet dat gewoon, dan is er geen sprake van een gebrek. Als er later een bug ontdekt is en deze actief geexploiteerd is, kan je ook volgens bovenstaande de fabrikant niet aansprakelijk houden.

Bovendien zit er bij (tenminste GPL componenten) een clausule dat je die opensource software (die indirect in veel devices gebruikt is) een voorwaarde dat gebruiken open en licensieloos onder de conditie dat software "as-is" gebruikt word en je afstand doet van je enige claim op het moment dat je die software gebruikt.

Dus in deze casus heb je een fabrikant van IP camera modules. Deze levert componenten aan een derde die er een product omheen zet. Deze IPcamera modules leverancier gebruikt opensource (en als ze dat netjes doen staat source en licensie op hun site.).

De producent van eind product, dient licentie bepalingen kenbaar te maken aan eindgebruiker en daarmee houd de verantwoordelijkheid mbt software al meteen op. Immers jouw producent heeft de software niet gemaakt. En de toeleverancier heeft OS niet gemaakt.

Artikel 188Bewijslast benadeelde

De benadeelde moet de schade, het gebrek en het oorzakelijk verband tussen het gebrek en de schade bewijzen.

Het rechtsgeldig aannemelijk maken waar de schade door veroorzaakt is en het gebrek en de hoeveelheid schade, gaat duizenden euro's kosten omdat je van accountant t/m specialiseerde security bedrijven nodig om alles vast te stellen. En dan nog gezien eerdere bepalingen kan je je recht niet halen. Los nog van het feit dat het de kans dat je met een Nederlandse fabrikant te maken hebt nihil is.

Even los nog van kosten om e.a. voor te bereiden zodat je kunt procederen. Een bodemprocedure kost je zomaar 50.000 euro en 2 jaar. Als daar stukken bij zitten die vertaald moeten worden of partijen in het buitenland betreft dan gaat dat veel meer worden, bovendien bij verlies van je zaak of gedeeltelijk winst, ben je gewoon je "investering" KWIJT.

Ik hoop dat mijn insteek vanaf verschillende perspectieven je wijzer hebben gemaakt.

Even los van dit, stel er zal eens wel iemand zijn zaak winnen. Dan zul je vanzelf zien dat er op dozen en handleidingen, GUI's 1 regel tekst erbij komt "Do not use this product connected to the Internet or any network".

Daarmee zijn ze altijd gevrijwaard.

[CAPSLOCK2000]

Ik heb het niet over aansprakelijkheid, daar kwam jij mee. Ik heb het over garantie. Daarover zegt het burgerlijk wetboek (boek 7k, artikel 6a 1):

Indien in geval van een consumentenkoop in een garantie door de verkoper of de producent bepaalde eigenschappen zijn toegezegd, bij het ontbreken waarvan de koper bepaalde rechten of vorderingen woAls er later een bug ontdekt is en deze actief geexploiteerd is, kan je ook volgens bovenstaande de fabrikant niet aansprakelijk houden.rden toegekend, dan kan de koper deze uitoefenen onverminderd alle andere rechten of vorderingen die de wet de koper toekent.

Als iemand (bv) een webcam verkoopt dan impliceert de naam dat het ding geschikt is voor gebruik op internet. Mochten er dan fouten in de software zitten waardoor het niet meer verantwoord is om het ding te gebruiken dan vind ik dat het product niet voldoet aan de toegezegde voorwaarden.

Als jij iets koopt met bepaalde functionaliteit (zoals een IP camera) en hij doet dat gewoon, dan is er geen sprake van een gebrek.

Ik vind veiligheid gewoon bij de functionaliteit horen.

Als er later een bug ontdekt is en deze actief geexploiteerd is, kan je ook volgens bovenstaande de fabrikant niet aansprakelijk houden.

Ik wil dan ook niet de fabrikant aansprakelijk stellen maar de winkelier om garantie vragen. Op zijn beurt mag de winkelier dan de fabrikant aansprakelijk stellen voor de schade die de winkelier loopt omdat hij mijn product moet herstellen/vergoeden. Zo werkt dat ook met alle ander producten.

Even los nog van kosten om e.a. voor te bereiden zodat je kunt procederen. Een bodemprocedure kost je zomaar 50.000 euro en 2 jaar. Als daar stukken bij zitten die vertaald moeten worden of partijen in het buitenland betreft dan gaat dat veel meer worden, bovendien bij verlies van je zaak of gedeeltelijk winst, ben je gewoon je "investering" KWIJT.

Dat vind ik niet zo'n best argument. Recht hebben heeft niks te maken met proceskosten. Recht krijgen misschien wel, maar dat is geen reden om te stellen dat IT boven de wet staat.

Los nog van het feit dat het de kans dat je met een Nederlandse fabrikant te maken hebt nihil is.

Een Nederlandse (of zelfs Europese) winkelier is genoeg.

Even los van dit, stel er zal eens wel iemand zijn zaak winnen. Dan zul je vanzelf zien dat er op dozen en handleidingen, GUI's 1 regel tekst erbij komt "Do not use this product connected to the Internet or any network".

Dat mag niet in Nederland. Je mag geen product verkopen en in de kleine lettertjes zetten dat het niet geschikt is voor de primaire functie waar het ding voor verkocht wordt. Volgens mij noemen ze dat een "onredelijk bezwarende voorwaarde".

Misschien dat de prijzen van electronica dan omhooog schieten maar dat is in dit stadium eigenlijk niet meer te voorkomen. Iemand zal moeten betalen voor alle die onveiligheid op internet. Ik heb liever dat die kosten in de prijs van het product zitten en niet bij onschuldige vreemden op internet terecht komen.

[totaalgeenhard]

Ik wens je veel succes met verhaal halen bij je winkelier.

[coolriku]

Waarschijnlijk heeft Dyn wat advocaten achter de hand, en is het voor het chineese bedrijf alsnog goedkoper om de apparaten terug te nemen.

[WhatsappHack]

Welnee. Het Chinese bedrijf is hier absoluut niet aansprakelijk voor. Dat een apparaat makkelijk te kraken is dankzij standaard wachtwoorden (die door omwetendheid niet worden gewijzigd -_-), betekend nog niet dát je het mag kraken en mag misbruiken... Anders kan je elke PC fabrikant en Microsoft ook wel gaan aanklagen. Dus nee, al staan er 100 Dyn advocaten te springen, die kunnen toch niets beginnen tegen dit bedrijf.

Denk gewoon dat het bedrijf een slimme move maakt voor de veiligheid van henzelf, het internet en hun gebruikers. Dat het apparaat te benaderen is om een zombie van te maken, betekend ook dat er waarschijnlijk nog meer mee gedaan kan worden - en dat is voor de eindgebruiker mogelijk nog veel vervelender.

[Reactie gewijzigd door WhatsappHack op 27 juli 2024 07:39]

[CAPSLOCK2000]

Welnee. Het Chinese bedrijf is hier absoluut niet aansprakelijk voor. Dat een apparaat makkelijk te kraken is dankzij standaard wachtwoorden (die door omwetendheid niet worden gewijzigd -_-), betekend nog niet dát je het mag kraken en mag misbruiken...

Ik denk dat de rechter je op dit moment gelijk zou geven, maar over een paar jaar niet meer. Wie een auto verkoopt met remmen van papier en in de handleiding zet dat de remblokken voor gebruik moeten worden vervangen zou daar niet mee weg komen. Wie een auto koopt mag verwachten dat deze veilig is.

Cynisch genoeg zou het nu misschien wel andersom werken. Als je een IT-product koopt dan kun verwachten dat het zo lek als een zeef is.

[WhatsappHack]

True, alleen is het hier meer de situatie dat de remklauwen van de auto standaard schroeven gebruiken en een crimineel die eruit schroeft om je remmen onklaar te maken. Dat kan je de autofabrikant niet aanrekenen, maar die kan veiligheidshalve wel een recall doen om gratis de schroefjes te vervangen voor een speciaal model waardoor t veel moeilijker voor de crimineel wordt.
Hier speelt dan ook nog mee dat de fabrikant wel in de handleiding vermeld dat je t default wachtwoord behoort te wijzigen.

Dat maakt toch een wezenlijk verschil imho

[Reactie gewijzigd door WhatsappHack op 27 juli 2024 07:39]

[coolriku]

Het is inderdaad slim als fabrikant om dit te doen.
Er zijn talloze sites waar je over heel de wereld naar security cams kan kijken die open staan naar het WWW.
Ze moeten het op dezelfde manier aanpakken als router fabrikanten.
Standaard een gegenereerd password erin zetten, die je evt verplicht moet wijzigen.
Want anders blijft het een standaard gegenereerd wachtwoord met een algoritme wat uiteindelijk ook op straat komt te liggen.

[venqwish]

Dit is slechts 1 reactie die het symptoom bestrijdt. Zolang het probleem niet bij de basis wordt aangepakt zullen er IoT devices blijven bijkomen die slecht beveiligd zijn en dus snel een stukje van het botnet zullen vormen.

Het volgende botnet zullen de koelkasten worden, of de thermostaten, of wat dan ook. Zolang niet alle fabrikanten de boel op orde krijgen en alles "evergreen" krijgen, of zolang gebruikers te lui zijn om standaard wachtwoorden te veranderen, zullen we hiermee blijven te maken krijgen.

Ik meende ergens te hebben gelezen dat naar schatting slechts 20% van het botnet was ingezet. Hadden ze bijvoorbeeld ook OpenDNS en de DNS-en van Google lam gelegd, dan was zowat het halve internet de pineut geweest.

Hopelijk is dit inderdaad een precursor voor meer beveiligde IoT devices, anders zal deze "storing" zeker niet de laatste zijn van deze omvang.

[JDVB]

Ik snap niet dat al dat soort apparaten maar zonder firewall vanaf het internet toegankelijk moeten zijn.
Wanneer een goede router geplaatst wordt met daarop een simpel maar veilig VPN, dan is het helemaal niet nodig allerlei dingen open te zetten en zal vanaf het internet niet te zien hoeven zijn of en zo ja hoeveel IoT apparaten er achter een IP hangen.

[CAPSLOCK2000]

Ik snap niet dat al dat soort apparaten maar zonder firewall vanaf het internet toegankelijk moeten zijn.
Wanneer een goede router geplaatst wordt met daarop een simpel maar veilig VPN, dan is het helemaal niet nodig allerlei dingen open te zetten en zal vanaf het internet niet te zien hoeven zijn of en zo ja hoeveel IoT apparaten er achter een IP hangen.

Het moet niet, maar het kan, dat is het probleem. Zo'n apparaat werkt prima zonder firewall. Sterker nog, met een firewall er bij is er alleen maar meer kans dat het niet werkt. Voor de naieve eindgebruiker is het dus gewoon lekker makkelijk om het ding niet te beveiligen.
De meeste fabrikanten aan de onderkant van de markt zijn totaal niet met veiligheid bezig, dat zijn hun klanten immers ook niet. Zolang de klanten er niet om vragen, of de wet het afdwingt, gaan die fabrikanten geen cent uitgeven aan echte beveiliging.

[Dreamvoid]

Ik snap niet dat al dat soort apparaten maar zonder firewall vanaf het internet toegankelijk moeten zijn.

Omdat 99.9% van de huishoudens geen VPN server heeft draaien, en met zijn telefoon via die VPN verbindt.

En wie zegt dat ze niet achter een firewall zitten? Als alle poorten geblokkeerd zijn behalve de 80 en 443 die nodig zijn voor de streams, dan kan er alsnog aangevallen worden via die twee poorten. Gooi je die dicht, dan werkt de camera niet.

[Reactie gewijzigd door Dreamvoid op 27 juli 2024 07:39]

[Yariva]

Faith in humanity restored Was dit dan toch de schop die fabrikanten nodig hadden?

[Kars]

Nee, want er zijn nog zoveel 'slimme' apparaten die zo gruwelijk slecht in elkaar steken..
Het is een kwestie van investering / winst. Zolang er cheap-ass zooi uitgegeven wordt, is het softwaretechnisch gewoon brol.

Toevallig een paar weken terug een lezing gehad van James Lyne, die liet zien dat er in een IoT device (in dit geval een stekkerblok) gewoon de passwords in plain text staan opgeslagen, in de system\ dir...

[livePulse]

Ok... vertel mij dan eens waarom iemand in godsnaam een stekkerblok aan het internet wil hangen??? Wat een waanzin!!!

[WhatsappHack]

Nou om op afstand de stroom van een outlet te kunnen bedienen dus.
Dit kan voor lampen zijn, thuisservers (force reboot) en noem het maar op. Ook maakt het verbruik per outlet soms inzichtelijk.

Er zijn voldoende applicaties voor

[Verwijderd]

Voor smart apparaten zou altijd alleen een apart protocol gebruikt moeten worden zoals Zwave. Daarmee kunnen deze dingen nooit het internet op, alleen de veel beter te beschermen hub kan dat dan.

[totaalgeenhard]

Leuk dat je lokaal een iot netwerk hebt die een niet op WIFI/Ethernet gebaseerde infrastructuur gebruikt.

Maar ergens wil jij op je smartphone of PC toch profijt hebben van de iot devices.

Dus dan zullen die iot devices over de NON WIFI/Ethernet infrastructuur uiteindelijk toch met TCP/IP op je lan terecht komen.

Je "iot" gateway zal dan je probleem kunnen worden.

[PPie]

Je "iot" gateway zal dan je probleem kunnen worden.

Klopt, maar dat is een enkel apparaat waar wellicht voldoende marge op en performance in kan zitten om daadwerkelijk wat aan beveiliging te doen, in plaats van meerdere el-cheapo lampjes en dergelijke...

[totaalgeenhard]

Realiteit wil dat mensen prijsbewust zijn.

Zou jij een "iot" lampenschakelaar van 1000 euro per stuk kopen met een support contract van 25 euro per maand ?

Ergens maakt met een bewuste keuze tussen "veiligheid" en "wat iemand voor bepaalde functionaliteit" over heeft.

Beste voorbeeld is je smartphone, deze zit bij meeste mensen niet op een separate WIFI netwerk, terwijl vrijwel iedereen een smartphone heeft waar reeds al mobiele bekende security problemen mee zijn of nog te vinden/publiceren zero-days.

Om maar te zwijgen over mogelijkheden van je OS leverancier en APP developers....

[PPie]

Zou jij een "iot" lampenschakelaar van 1000 euro per stuk kopen met een support contract van 25 euro per maand ?

Nope.
Maar zo'n bedrag is natuurlijk onzin voor deze functionaliteit. Er zit echter een verschil tussen geen winst en voldoende winst om daadwerkelijk verantwoording te nemen voor de geleverde producten.
Andere optie gaat anders gewoon zijn dat mensen compleet verantwoordelijk gaan worden voor wat hun internetaansluiting doet.
En dan wordt zo'n lampenschakelaar toch duur, als je een enorme boete krijgt...

[totaalgeenhard]

Maar toch gebeurd het.

Neem een smartphone of tablet. Veel toestellen van een paar jaar oud krijgen geen updates meer.

Als toestel economisch niet meer rendabel is voor fabrikant vervalt (uit economische perspectief gezien terecht) nut en noodzaak om het te blijven onderhouden.

DVR en IP camera's blijven gerust 10 jaar werken.

[CAPSLOCK2000]

Ok... vertel mij dan eens waarom iemand in godsnaam een stekkerblok aan het internet wil hangen??? Wat een waanzin!!!

Dat maak ik zelf wel uit

Alles wordt aan internet geknoopt. Of wij daar nu een goede reden voor kunnen bedenken of niet, het gebeurt toch wel. Hoog tijd dat iedereen er rekening mee gaat houden. Het is zoiets als bellen in de auto, het is misschien geen goed idee maar mensen doen het toch wel. Helemaal verbieden is zinloos. Daarom vind ik de hands-free-regel een goed compromis. Daarmee neem je de meeste gevaarlijke situaties weg terwijl tegelijkertijd erkent wordt dat mensen nu eenmaal willen bellen uit de auto en dat doen ook.
Zo zie ik ook stekkerblokken op internet aansluiten. Misschien is het geen verstandig idee maar we weten met haast absolute zekerheid dat we wel die kant op gaan. Laten we ons daarom richten op de vraag hoe we die stekkerblokken veilig aansluiten, niet op de vraag waarom je dat zou willen.

[livePulse]

Nou, ik heb nog geen overtuigende reacties gezien om een stekkerblok aan het internet te willen hangen. Waarom zou ik per stekkerblok willen weten wat ik verbruik? Voor mij is het eindplaatje het belangrijkst.
Een lampp bedienen via een stekkerblok dmv je smartphone? Sorry, ik heb benen gekregen om even naar de lamp te lopen en aan te zetten.
Server reboot? Komop, serieus? Daarom heb je een stekkerblok nodig? What about remote login?
Bij bellen in de auto zie ik een functie (bv reageren op een ongeval).
Typisch gevalletje "niet omdat het moet..."

[vali]

Dit is de reden waarom mijn IP-cameras niet rechtstreeks benaderbaar zijn via het internet, maar alleen via een VPN-verbinding. Ze krijgen wel steeds netjes firmware update, maar vertrouw ze zeker niet 100%.

Overgrote deel van de consumenten passen dit niet toe en daar maken criminelen misbruik van.

[Reactie gewijzigd door vali op 27 juli 2024 07:39]

[ThinkPad]

Dachten maar mensen daar zo over: www.insecam.org

[dasiro]

als je ze achter een firewall hebt hangen die enkel op bepaalde poorten en naar bepaalde IP's mogen communiceren zit je goed, anders is een VPN nutteloos in dit geval, want dan nog kunnen ze sturen wat ze willen

[vali]

firewall hebt hangen die enkel op bepaalde poorten en naar bepaalde IP's mogen communiceren zit je goed,

Hoop niet dat je dit serieus bedoelde, want dit maakt het zeker niet veiliger. Op dit moment kan ik pas van buitenaf met mijn camera's communiceren als ik een VPN-verbinding opzet, anders niet.

[Reactie gewijzigd door vali op 27 juli 2024 07:39]

[mgizmo]

Hij bedoelt (en anders begrijp ik je reactie ook niet), dat jij wel access met je cams kan doen via VPN, maar dat je cams alsnog gewoon een default route naar je router hebben om alsnog het gehele internet te benaderen.

Dus jij kan wel van buitenaf met je camera's communiceren als je alleen een VPN toepast, maar geldt dit ook voor je camera's zelf? (maw pas je een out of band netwerk toe?)

[Reactie gewijzigd door mgizmo op 27 juli 2024 07:39]

[vali]

Dus jij kan wel van buitenaf met je camera's communiceren als je alleen een VPN toepast, maar geldt dit ook voor je camera's zelf? (maw pas je een out of band netwerk toe?)

Heb er uiteraard voor gezorgd dat ze niet naar buiten mogen praten, maar ik ging ook in op het stukje toelaten van "bepaalde IP's".

[dasiro]

bij voorkeur wel ja, tenzij je VPN-provider geen vaste ranges heeft of meedeelt.
jouw camera's moeten ook niet van zichzelf naar jou communiceren, tenzij misschien uitzonderlijk met een server om een verwittiging te sturen als er iets aan de hand is, voor de rest wil je enkel hun inhoud consulteren, maar dan is het een inbound connection en geen outbound

[vali]

misschien uitzonderlijk met een server om een verwittiging te sturen als er iets aan de hand is,

Dat wil ik nog realiseren, maar verder ben ik met je eens.

[Vexxon]

Dis de reden waarom ik geen ip camera's en ander zogenaamd 'smart'-spul' in mijn huis heb.
Het levert eigenlijk vrijwel alleen maar problemen op.

[Anonymoussaurus]

Nee hoor. Zolang je het zo goed mogelijk beveiligd, en de fabrikant helpt daar ook in mee..

[Lampie]

"Vrijwel alleen maar" lijkt me overdreven. Je koopt het omdat het iets realiseert wat je leuk/handig vindt. Er zit inderdaad ook een risico aan producten die aan het internet hangen.

[Verwijderd]

Dis de reden waarom ik geen ip camera's en ander zogenaamd 'smart'-spul' in mijn huis heb.
Het levert eigenlijk vrijwel alleen maar problemen op.

Moet je toch eens een IP scan doen in je huis, dan zie dat je vast wel een setupbox, 'smart' TV, Chromecast etc etc hebt hangen.

Het idee dat we het IoT kunnen beveiligen is zonder meer onmogelijk. Niemand gaat elke week alle apparaten langs om te zien of er nieuwe firmware is voor de TV, koelkast of stofzuiger is. De oplossing ligt ergens anders en die moeten we bedenken voor alles een IP6 adddress krijgt en daarmee direct kan communiceren.

[loki504]

En wat voor problemen heeft dit voor die mensen dan opgeleverd? Ja ze waren deel van een DDOS. En is ook beter om te voorkomen. Alleen merk je als consument 9/10 keer weinig als 1 van je apparaten meedoet aan een DDOS aanval(hier licht ook gelijk het probleem).

[biglia]

Webcams of ip beveiligingscamera's? Webcams stop je toch gewoon in USB of vergis ik me.

How is an IP Camera Different than a Web Cam?
http://blog.dlink.com/ip-cameras-vs-webcams/

[Reactie gewijzigd door biglia op 27 juli 2024 07:39]

[tweaknico]

Het merendeel van Webcams kan gewoon direct op een IP switch aangesloten worden, vaak een PoE switch zodat er geen extra draden meer nodig zijn.

Er bestaan ook USB webcams die vallen hier buiten... (Maar die zitten dan weer vaak aan een IP kastje om op afstand begluurd te kunnen worden.)

[Kaoh]

Een mooie business case voor Windows 10 IoT. Die heeft standaard de mogelijkheid om gewoon mee te updaten via Windows Update. En de App die je erop bouwt kan je als ontwikkelaar ook gewoon via de store updaten. Hoeven de gebruikers dus niets meer voor te doen. En net zo veilig als de rest van het Windows 10 Core platform

[CivLord]

Updates etc. maakt niet zo veel uit, wanneer het merendeel van de apparaten nog steeds 'admin' als wachtwoord heeft.
Je kunt nog zo'n goed slot hebben, wanneer je de sleutel aan de buitenkant van de deur plakt maakt dat weinig uit.

[Verwijderd]

Misschien is het een idee om die firmware opensource te maken

[totaalgeenhard]

Veel devices werken met een embedded Linux versie. Echter niet elke fabrikant is zo netjes om de onder GPL vallende onderdelen die hij gebruikt (zoals kernel en gebruikte deamons) te openbaren.

Bovendien kun je er als leek niets mee. Compilen voor een specifieke hardware platform zorgt voor nodige haken en ogen, in eerste instantie moet je de hardware identificeren.

[PDZ]

Goed ding dat de fabrikant dit zo aanpakt, kunnen sommige andere fabrikanten nog wat van leren!