Hallo allerseits, kurz zu mir: Einige Erfahrung in uC sind vorhanden, Board Design und Routing ebenfalls, einigermaßen zielführende C-Kenntnisse ebenso. Was ich aber noch NIE gemacht habe: 1.) Webprogrammierung in jedweder Facette 2.) IoT Letztenendes gehört beides ja irgendwie zusammen und da es in meiner Firma wohl auch in Richtung 2) geht, möchte ich gerne Erfahrungen in beiden Bereichen sammeln, thematisch gehört es ja sowieso zusammen. Da ich ohnehin mal wieder ein Projekt suche, denke ich ein kleiner Temperaturlogger mit Internetanbindung wäre eine schöne und runde Sache, um einen motivierten Einstieg in die Technik zu finden. Nun würde ich also gerne von euch Erfahrungen haben, wie ich am Besten vorgehe. Ich habe hier sowohl das PicKit 3, als auch einen MSPFET430. Welche u-Controller könnt ihr empfehlen? Welche Schnittstellen-Controller sollte ich mir ansehen? Kabelgebunden würde mir wohl erstmal genügen. Welche Grundlagenliteratur ist Pflicht? Woran muss ich auf jeden Fall denken bevor es losgeht? Gibt es ein IoT für Dummies oder eine andere Lektüre, die mir (und euch)tägliches Nachragen hier im Forum erspart? mfg
> IoT Da kann man einiges drunter verstehen.... Aber im Grunde sind die T im Namen meist kleine Dinger.... Arg begrenzte Ressourcen. Und damit ist das I auch klein. Eigentlich würde das I für Internet stehen, TCP usw... Aber das ist kaum in die Zwerge zu pressen. Ich habe eine kleines Netz in Betrieb. Einige Arduino Pro Mini Und ein Raspberry, welcher Webserver spielt und die Verbindung zum Netz hält. Als (IoT) Funkis kommen NRF24L1+ zum Einsatz. Da schon Leute ordentliche Vorarbeit geleistet haben, nutze ich http://tmrh20.github.io/RF24Mesh/ . Das ist selbst organisierend und schon fertig (faul ich bin)
Für IoT (mit oder ohne extra uC) würde ich momentan eher zum esp8266 greifen. TCP und UDP kann das Teil schon von sich sus
Internet of Nothing schrieb: > Was ich aber noch NIE gemacht habe: > > 1.) Webprogrammierung in jedweder Facette > .... > Welche Grundlagenliteratur ist Pflicht? Siehe da: http://wiki.selfhtml.org/wiki/HTML/Tutorials
kenny schrieb: > https://www.dragoninnovation.com/projects/35-wunde... > > Wäre das nichts? Geil, ne App für voll geschissene Windeln
Also ich hab mal für ein Jahr in der IoT-Abteilung eines Haushaltsgeräteherstellers gearbeitet, somit habe ich etwas Einblick. Eine Strategie ist daran ganz naiv dran zu gehen, Du ersparst Dir damit jede Menge Frust, weil Du nicht mit bekommst wo denn die Probleme liegen. Willst Du in dem Bereich fachlich was drauf haben, würde ich Dir empfehlen "The Art of UNIX Programming zu lesen. http://www.catb.org/esr/writings/taoup/html/index.html Dann löse mal ein mittelkomplexes Problem in Assembler damit Du mal erlebt hat wie stark Komplexität weh tun kann. Aber bedenke immer, das Niveau in der Industrie ist sehr niedrig, besonders in solchen neuen Bereichen.
Ulrich F. schrieb: >> IoT > Da kann man einiges drunter verstehen.... Also wenn man ein ID dazu nimmt, weiss man für wen das steht.
Am Wichtigsten ist meiner Meinung nach, dass man diese Things nicht direkt an Internet anbindet. Alleine schon aus Sicherheitsgründen. Wenn du z.B. dein Haus übers lokale Netzwerk steuerst, dann könntest du einen Server mit Web-Interface einrichten. Die Webseiten nutzt du dann auf Handies, Tablets und eventuell auch über das öffentliche Internet. Aber es sollte keine Kommunikation aus dem Internet heraus direkt zu den Mikrocontrollern stattfinden. Wenn da ein ordentlicher Webserver zwischen hängt, kann man auf bewährte Mittel zurückgreifen, um das Ganze sicher zu machen. Wenn du deine eigene µC Firmware schreibst, wo das Netwerzkprotokoll und die Anwendung in wenige Kilobtes gequetscht werden, bleibt kein Platz für nennenswerte Sicherheit. Falls du wirklich eine (direkte oder indirekte) Anbindung ans öffentliche Internet vorhast, dann liest dich erstmal in das Thema Security ein. Denn ich bin sicher, dass es nach der Inbetriebnahme weniger als 24 Stunden dauert, bis das Ding von unerwarteten Kontaktversuchen heimgesucht wird..
Bestelle dir eine Handvoll esp8266, zB es-01 oder esp-07 Module. Dann schau dir an was man damit machen kann: nntp Zeit aus dem Internet holen, cloud update der firmware vom eigenen server, lokal gemessene Temperatur irgendwohin loggen, Programmierung in c/c++ mit der gcc toolchain, Programmierung in LUA mit der NodeMCU firmware. Kleiner http server auf dem gerät, ersteinrichtung als wifi AP, danach betrieb als wifi station/client. Sleep modes und Batteriebetrieb. SSL Verbindungen. Das sind schon einige Felder wo man experimentieren kann.
Ich arbeite gerade mit Atmel wifi Modulen winc1500 da diese im wifi chip sämtliche Protokolle inkl. Tls/ssl schon einbauen und was erstaunlich gut mit unseren Routern laufen welche wir weltweit eingesammelt haben ( aus Erfahrung da nicht alle Produkte am Markt überall laufen). Für die Sessionkey Generierung Ecdsa und Ecdh verwende ich den ecc508 der auch einen Schlüsselspeicher besitzt. Damit implementiere ich auch Authentifizierung der Node. Um das ganze Iot mit cloud einmal auszutesten und vor allem dann wenn du noch gar nicht so richtig weisst wie eine iot Lösung final aussehen kann, empfehle ich dir die Demo Agents Firmware von Pubnub oder proximetry anzuschauen. Damit kannst du auf dem samd21+winc1500 in ner Stunde eine fertige cloud demo (kostenlos ) bauen und ggf in der Firma vorstellen. Je nachdem wie die Anwendung es braucht wirst du dann entweder eigene Ideen entwickeln wie z.b data Center in Deutschland anstelle von USA ;-)
IoT-Erfahrung hat so richtig keiner. Keiner weiß genau, was es mal werden soll und ob es überhaupt praktisch einsetzbar sein wird. Auch haben Funknetze die Eigenschaft, einfach zusammen zu brechen, wenn die Dichte der Teilnehmer einen kritischen Wert überschreitet. Ob IoT massentauglich sein wird, weiß daher niemand. Ist so ähnlich, wie das voll elektronische Haus. Hört sich super an, aber keiner will es wirklich haben, da man erst eine lange Lernzeit braucht, um es bedienen zu können. Es ist für den Menschen unheimlich, wenn sich Dinge miteinander unterhalten, ohne daß er es merkt oder daß er es unterbinden kann.
:
Bearbeitet durch User
Hallo, erstmal danke für die bisherigen Antworten. So als kompletter Neuling habe ich jetzt einige Zeit mit dem Tutorial zum SelfHTML verbracht und bin doch positiv überrascht, wie einfach es zu sein scheint, eine eigene Website zu gestalten. Nun die vielleicht naive Frage: Kann man solche HTML-Dateien quasi auf dem vorgeschlagenen PIC18F67J60 draufspielen, und dann bei Eingabe der richtigen IP-Adresse im Browser genau auf dieses zunächst statische HTML-Verzeichnisse zugreifen? Die z.B. minütliche Aktualisierung gewisser Daten durch den Mikrocontroller wäre dann ja der nächste Schritt... Ist dieses Vorgehen zu naiv? Danke IoN
> Ist dieses Vorgehen zu naiv?
Ja!
Grundsätzlich möglich!
Aber praktisch weniger.
Das Zauberwort heißt "Speicher".
Webseiten ausliefern ....
Das können arg fette Brocken werden.
Bilder? (oje)
Tipp:
Mit den Zwergen konsequent das REST Konzept durchsetzen.
Ajax ?!?!
Statische Ressourcen von einem anderen Server holen(lassen).
Klar geht das. In einfachsten Fall machst du dir einfach ein Char-Array wo du deinen html-Code drin speicherst (am besten ohne nutzlose blanks, tabs, \n...). Also z.B. sowas wie const char header[] = "<html><header><title>Test-Seite</title></header>"; const char body[] = "<body><br>Uhrzeit %02d;%02d:%02d</body></html>; char buffer[128]; sprintf(buffer,body, time.hour, time.minute, time.second); Und immer wenn eine http-Anfrage über port 80 kommt (also "GET / HTTP...") dann schickst du einfach den header und buffer (welcher dann die aktuelle Uhrzeit enthält) einfach als Antwort zurück. Wenn du ne SD-Karte mit FAT verwenden willst liest du halt die entsprechenden Files und schickst diese halt.
:
Bearbeitet durch User
Hier gibt's etwas was einen Arduino leicht in ein IoT System umwandelt, schnell bekommt man etwas fertig: http://www.feoweb.com/, Vieleicht nicht ganz geignet wenn du von Auswahl von uC und Board design anfangen willst, aber falls ein fertiger Arduino schon in frage kommt, dann scheint es nützlich
Hier hast du so ein Projekt zum abgucken oder nachmachen. http://stefanfrings.de/net_io/index.html Ich halte es jedoch für nicht ratsam, allzu viel Zeit in den Webserver rein zu stecken. Denn die Speicherkapazität und Performance sind doch sehr begrenzt. Und ins öffentliche Internet gehört so ein Teil schonmal gar nicht. Da ist nämlich absolut gar nichts drauf, wass den Namen Sicherheistmechanismus verdient. Webinterface auf Mikrocontrollern sollten höchstens dazu dienen, das Gerät komfortabel zu konfigurieren. Mehr nicht. Webseiten gehören auf Webserver. Die kleinste sinnvolle Hardware dazu wäre meiner Meinung nach ein Raspberyy Pi. Auf jeden Fall sollte es ein Rechner mit einem "normalen" Betriebsystem und mit bewährter Software sein, wie zum Beispiel der Apache Http Server, Apache Tomcat, Jboss und wie sie alle heißen. Die Kommunikation zwische Webserver und dem "Ding" macht man dann typischerweise mit REST Services oder AJAX. Das wiederum kann man auf einem ESP8266 Modul bequem implementieren - falls man WLAN für ausreichend zuverlässig hält (tu ich nicht, aber ich bin ja auch ein elender Pechvogel). Ich schlage vor, dass du Dir mal eins dieser CrumbX1-Net Module besorgst (und eine passenden PDI Programmieradapter). Damit kannst du ganz schnell die Vor- und Nachteile deiner Iddee austesten. Ich denek, das ist besser, als wenn du so viele Stunden in den Sand setzt, wie ich es damals getan hatte. Verstehe mich nicht falsch: Mein Webserver funktioniert super, sogar fast tadellos. Aber letztendlich konnte ich damit bei weitem nicht so viel realisieren, wie ich ursprünglich vorhatte. Wenn ich das eher gewusst hätte, hätte ich diese Firmware nie entwickelt. Heute muss ich sagen, daß ich mit diesem Projekt viel Zeit vergeudet hätte, wenn es kommerziell gewesen wäre. Zum Glück war es nur Hobby und ich habe eine Menge dabei gelernt. Das ist ja auch schonmal was wert.
Na,nder IoT-Hype greift immer noch um sich... Meiner bescheidenen Meinung nach scheitert dieses grandiose IoT, was jeder an jedem Embedded-Messestand mit seiner HW promoted, an manchen grundsätzlichen Konzepten, denn stromsparend und Webserver verträgt sich schon mal nicht. Der esp8266 hat nach einem ersten Hype auch eher für Frust als Segen gesorgt, das Ding ist für industrielle Nutzung schlicht unbrauchbar. Eher würde ich mir zum spielen was wie den wrtnode und was es sonst aus der Mediatek-Community so gibt, besorgen. Die sind zwar nicht stromsparender, aber sie laufen stabil 24/7/365. Ansonsten steht immer noch die Frage im Raum, wofür man IoT wirklich braucht. Hausautomation kann man mit einer Menge anderer Protokolle machen. Zur Weiterbildung macht es sicher Sinn, sich mit einigen Prototkollen zu beschäftigen. Ich schmeisse mal wild um mich: - CAN, Ethernet, RS485: Link layer, die man so in der Automatisation findet - Drahtlos: Zigbee, Paket-Radio aller Arten im 868MHz-Band, Bluetooth... - Logical layer: MQTT, SWAP, modbus, Googles Protocol buffer, JSON, netpp, firmata, ... Bei der Betriebssystemseite gibt es eine Menge Wildwuchs, und alle haben sie IoT erfunden. Mit FreeRTOS habe ich ganz gute Erfahrungen gemacht, ansonsten würde ich da dem Fragesteller empfehlen, sich mit bare metal zu beschäftigen: Keine C Bibliothek, und eine eigene, thread-freie Main loop. Dann sieht man plötzlich, wieviel an IoT-Logik in, sagen wir 8 kB reingehen..
Hallo Will mich auch mit diesem Thema befassen und dachte an das zum Einstieg: https://www.conrad.de/de/maker-kit-franzis-verlag-maker-kit-internet-of-things-65316-ab-14-jahre-1418808.html Hat jemand damit Erfahrung? Taugt das was, technisch/ didaktisch?
Fitzebutze schrieb: > Der esp8266 hat nach einem ersten Hype auch eher für Frust als Segen > gesorgt, das Ding ist für industrielle Nutzung schlicht unbrauchbar. Mich wundert ja schon, das es die Dinger mittlerweile nicht in allem was eine Batterie beinhaltet gibt, aber kannst du mir sagen warum?
Kolja L. schrieb: > Fitzebutze schrieb: >> Der esp8266 hat nach einem ersten Hype auch eher für Frust als Segen >> gesorgt, das Ding ist für industrielle Nutzung schlicht unbrauchbar. > > Mich wundert ja schon, das es die Dinger mittlerweile nicht in allem was > eine Batterie beinhaltet gibt, > aber kannst du mir sagen warum? Da gibts eine ganze Liste: 1) UART-Design verkackt, bei der Pinbelegung nicht nachgedacht, Ausgabe von Debug-Kram beim Booten, den zweiten UART kann man für Peripherie ohne Hack nicht nutzen, wenn SPI aktiv (also Standard) 2) Eine Menge Aussetzer beim RF-Teil, wenig einheitliche Chip-Specs. Wie die ihren FCC-Test bestanden haben, ist mir ein Rätsel. Vermutlich gar nicht, ein FCC-Logo hat wohl den ähnlichen Wert wie "CE". Manche der esp-Boards haben "verbotene" Specs, käme nie durch den EMV-Test. Ok, das liegt teils am Eindesign der Chips, da kann Espressif nix für. 3) Nach über einem Jahr immer noch keine stabile Firmware, die API ist keine API sondern irgendwas semistabil zusammengefuddeltes mit einer Lizenzverletzung nach der andern. Das Espressif-Betriebssystem, sofern man es so nennen kann, ist relativ unbrauchbar und hat nach wie vor die nondeterministischen Hänger, die nerven. 4) FreeRTOS tut besser, aber auch da sind viele Böcke in der LWIP-Anbindung, das System lässt sich relativ leicht von aussen abschiessen, so dass es nicht mehr bootet. No go. 5) Stromsparend wäre der Chip ja, potentiell. Aber da müssten vielleicht doch noch ein paar Hausaufgaben gelöst werden, bevor man einen Dualcore raushaut (esp32), bei dem so einige Debug-Schnittstellen vergessen wurden. Was besonders stört, ist, dass die Espressif-Programmierer sich munter an OpenSource bedienen, aber das Prinzip dahinter nicht so richtig verstanden haben. So ist der Chip irgendwie eine Totgeburt für eine echte IoT-Anwendung. Zum irgendwas zu 90% hinfuddeln reicht er, ich gebe auch zu, dass ich damit ne Demo angeschmissen habe. Aber dabei bleibts auch. Der Chip war billig - das Lehrgeld der Evaluation nicht. Sollte aber eigentlich kein Verriss der esp8266 werden. Der Fragesteller wollte doch nur bisschen IoT...
Fitzebutze schrieb: > Sollte aber eigentlich kein Verriss der esp8266 werden. Der Fragesteller > wollte doch nur bisschen IoT... Das wollte er vor neun Monaten. Keine Ahnung, warum der Thread wieder ausgegraben wurde.
Stefan U. schrieb: > Aber es sollte keine Kommunikation aus dem Internet heraus direkt zu den > Mikrocontrollern stattfinden. Um Himmels willen, was empfielst Du da. Selbstverständlich kann sie das. Zum einen hat man den MC samt Interpretation der Daten selbst in der Hand, das sorgt schonmal für den höchstmöglichen Sicherheitslevel den man sich denken kann. Zum anderen ist es mitnichten so, daß man es sofort mit Hackern aller Art zu tun bekäme. Die haben da wesentlich interessantere Ziele im Blick.
Peter D. schrieb: > Ist so ähnlich, wie das voll elektronische Haus. Hört sich super an, > aber keiner will es wirklich haben, da man erst eine lange Lernzeit > braucht, um es bedienen zu können. Das ist aber nicht Sinn und Zweck des smarten Home. Da gehts nicht um Bedienen (schon gar nicht die Präsentation hunderter Parameter und das manuelle Verbraucher-Schalten auf einer schicken Tablett-Oberfläche) sondern um automatische Hilfestellungen, die das Leben erleichtern. Beispiele sind neben der satt Kosten sparenden Heizungsregelung das Licht-, Lüftungs- und Stromverbraucher Management, Türöffnung, Alarm- und (Fern-) Überwachungs- sowie Benachrichtigungsfunktionen.
Internet of Nothing schrieb: > Welche u-Controller könnt ihr empfehlen? Das können viele sein, der Controller ist nicht das Hauptproblem. > Welche Schnittstellen-Controller sollte ich mir ansehen? Kabelgebunden > würde mir wohl erstmal genügen. Ich verwende einen einfachen Netzwerk<->Serieller Port Umsetzer wie den XPort von Lantronix. Der kann, richtig am Router eingerichtet, Abfragen von beliebigen Webbrowsern auf seinen seriellen Port leiten, dessen ankommende Daten Du wiederum mit einem einfachen Controller wie dem AVR oder Deinem PIC auswerten und auf umgekehrtem Weg beantworten kannst. Für kleine textbasierte Webseiten langt der Speicher durchaus. Es gibt zwar heute billigere Lösungen. Mir hat das einfache Konzept aber sehr schnell zu einer funktionierenden, kompakten, störfesten Anbindung eines Controllers ans Netz verholfen.
:
Bearbeitet durch User
> Hat jemand damit Erfahrung? Taugt das was, technisch/ didaktisch?
Ich kennen jetzt nicht dieses konkrete Franzis Produkt. Aber einige
andere.
Technisch sind sie Ok. Didaktisch sehr schlecht. Die Franzis Bücher und
Bausätze lehren so gut wie gar nichts. Sie taugen bestenfalls als
Lötübung.
Und dann achte mal auf dem Preis. Diese Platine ist unter dem Namen
Pretzel-Board einzeln erhältlich, für ca 30 Euro. Du kannst aber auch
einen Arduino nano Clone selbst mit einem ESP-01 Modul verbinden, dann
hast du was gleichwertiges für nur 6 Euro!
Gute Bücher gibt es sicher viele - aber nicht bei Franzis. Ist meine
persönliche Meinung.
> Zum einen hat man den MC samt Interpretation der Daten selbst in > der Hand, das sorgt schonmal für den höchstmöglichen Sicherheitslevel > den man sich denken kann. > Zum anderen ist es mitnichten so, daß man es > sofort mit Hackern aller Art zu tun bekäme. Die haben da > wesentlich interessantere Ziele im Blick. Ja noch. Aber denke mal 5 Jahre weiter. Es sind schon Pumpanlagen zur Wasserversorgung gehackt worden. Wie willst du auf einem Mikrocontroller eine wirksame Firewall nachinstallieren? Oder einen Schutz gegen DOS? Das ist faktisch unmöglich. Wie realisierst du eine wirklich sichere Verschlüsselung und Authentisierung? Es geht ja nichtmal HTTPS (und das wäre schon unsicher genug, sagt sogar dessen Erfinder)! Mach doch nicht die gleichen Fehler erneut, die man in der PC Branche in den 80er-90er Jahren schon durch hatte. Das Internet ist ein äußerst riskantes und hartes Arbeistfeld. Jeder vollberufliche Webentwickler weiß das. Ich versuche ja auch nicht mit einem Boot aus Papier das Mittelmeer zu überqueren. Das ist sicher machbar, aber viel zu riskant. Du hast offensichtlich Null Ahnung von Internet-Security.
Ich stimme Fitzebutze weitgehend zu. In den verganenen Wochen habe ich intensiv nach kommerziellen Anwendungen gesucht, wo der ESP8266 drin ist. Ich habe keine einzige gefunden. Nichtmal bunte LED-lampen. Das Einzige, was ich mit diesem Chip gefunden habe, sind Bausätze und Arduino Module. Die AT Firmware läuft allerdings inzwischen stabil. Somit kann ich das Modul zum Basteln nun endlich doch empfehlen. Ich würde gerne wissen, ob die ESP Module immer noch nicht zulassungsfähtig sind. Die chinesischen Händler behaupten ja was anderes. Die Module mit Abschirmung haben alle das CE Logo drauf.
pretzelboard, dazu gibt es auch noch eine seite im internet, wo viele sachen zu dem teil erklärt werden.
Stefan U. schrieb: > Die chinesischen Händler behaupten ja was > anderes. Die Module mit Abschirmung haben alle das CE Logo drauf Ja welches CE? China Export -> schlecht Communauté Européenne -> gut https://de.wikipedia.org/wiki/CE-Kennzeichnung#Missbr.C3.A4uchliche_Verwendung
Moby schrieb: > Stefan U. schrieb: >> Aber es sollte keine Kommunikation aus dem Internet heraus direkt zu den >> Mikrocontrollern stattfinden. > > Um Himmels willen, was empfielst Du da. > Selbstverständlich kann sie das. > Zum einen hat man den MC samt Interpretation der Daten selbst in der > Hand, das sorgt schonmal für den höchstmöglichen Sicherheitslevel den > man sich denken kann. Wenn man auf bewährte Webserver-Technologien zurückgreift, bekommt man sogar den höchstmöglichen Sicherheitslevel, den man sich NICHT denken kann. In der Regel werden Sicherheitsprobleme ja gerade von den Sachen verursacht, an die der Entwickler NICHT gedacht hat. ;-)
Sheeva P. schrieb: > Wenn man auf bewährte Webserver-Technologien zurückgreift, bekommt man nein, nicht den höchsten Sichrheitslevel, sondern eine komplexe Technologie, die man nicht 100%ig selbst in der Hand hat inklusive aller unentdeckten Bugs und Lücken. Über die Zwischenstufe serieller Ascii-Daten inklusive der nur mir bekannten Dateninterpretation erreiche ich die höchstmögliche denkbare Sicherheit- diese Zwischenstufe in Hardware entkoppelt quasi von allen potentiellen Sicherheitslücken, die im Netzwerk-Interface selbst noch schlummern mögen. Da gibts keine Ausbruchmöglichkeit, das erübrigt sämtliche Überlegungen a'la Stefan U. schrieb: > Wie willst du auf einem Mikrocontroller eine wirksame Firewall > nachinstallieren? Oder einen Schutz gegen DOS? Das ist faktisch > unmöglich. Wie realisierst du eine wirklich sichere Verschlüsselung und > Authentisierung? Es geht ja nichtmal HTTPS (und das wäre schon unsicher > genug, sagt sogar dessen Erfinder)! Das war so in den letzten 5 und wird auch in den nächsten 50 Jahren so sein. Du hast offensichtlich obiges Prinzip der Entkopplung nicht verstanden ;-) Was sich freilich nie ausschließen lässt ist natürlich, daß das Netzwerk-Interface als geschlossenes, nicht einsichtiges System aufgrund irgendwelcher Lücken von außen "kampfunfähig" gemacht wird. Das dürfte aber mit so ziemlich jeder beliebigen Internet-Anbindung möglich sein und kein ungewöhnliches Risiko darstellen.
> Die Module mit Abschirmung haben alle das CE Logo drauf.
Stimm gar nicht (ich muss mir da selbst widersprechen).
Sie tragen das FCC Logo. CE Logos findet man auf ESP Modulen eher
selten.
Hallo, was riskiere ich eigentlich wenn ich ein AVR-NetIO ins Internet stelle oder einen ESP8266 im lokaln WLAN habe? Wenn jemand von druaßen die Web-URL des NetIO findet (wie?) kann er natürlich auf die Webseite zugreifen. Wenn da selbst nur eine simple Passwortabfrage ist, muß er das auch nochrausfinden. Übliche Angriffszenarien werden gegen die Wand laufen, weil da weder eine beknnte Sicherheittslücke im Webserver genutzt werden kann noch ein Zugriff auf das darunterliegende OS. Bestenfalls crasht das NetIO, weil meist zwar in der Firmware die Parameter ausgewertet werden aber kaum Fehlerbehandlung drin ist... Ein Angreifer müße also geziehlt das NetIO angreifen, nur wozu? Beim ESP im WLAN muß erstmal jemand in mein WLAN kommen und wenn ihm das gelingt, habe ich andere Probleme als das er mir das Licht ausschaltet... Bekannte Sicherheitslücken in der Kombination kann es also durchaus geben, die muß jemad dann aber auch geziehlt für dieses System suchen. Je mehr ich da also selber bastle umso weniger Risiko gehe ich im Prinzip ein. Fertige System wie MQTT, FHEM, OpenHub usw. haben das Problem, daß Fehler dort dann Angriffsmöglichekiten schaffen und genauso wie in irgendwelcher Blog-Software usw. gesucht und genutzt werden. Da hätte ich dann eher Sorge und dagegen hilft mir keine Firewall... Gruß aus Berlin Michael
> was riskiere ich eigentlich Zum Beispiel stellt jemand deine Heizung auf 35°C um (wenn sie denn mit deinem Webserver verbunden ist), während u im Urlaub bist. Du kommst zurück, deine Blumen sind kaputt, die Fische Tot und die Stadtwerke wollen 500 Euro nachzahlung für die Gasrechnung. Entscheident ist, wie gefährlich oder wichtig die Dinge sind, die über dein NET-I/O steuerbar sind. Und ja, ein Angreifer könnte dein gerät zum Absturz bringen oder wegen zu vieler sinnloser Anfragen unerreichbar machen (DOS, hatte ich schon genannt). Wenn dein µC sein eigenes Programm ändern kann (der ESP8266 kann das), könnte man auch Viren einschleusen, die Hackern z.B. Zugang zu deinem PC verschaffen. Oder jemand könnte dein Gerät als Proxy Station benutzen, um seine Identität zu verbergen. Dann bist du womöglich derjenige, der angeblich das Pentagon gehackt hat. > Je mehr ich da also selber bastle umso weniger Risiko gehe ich > im Prinzip ein. Das ist der falsche Denkansatz. Richtig ist: je mehr du ans Internet direkt oder indirekt anschließt, umso mehr Risiko gehtst du ein. Denk an die Autos, die man über das Multimedia Entertainment System in gewissen Grenzen fernsteuern konnte. Sowas kommt tatsächlich vor! Eigene Software ist nicht automatisch sicherer, nur weil sie unbekannt ist. Hacker finden Schwachstellen schnell und halb automatisiert. Sie klopfen Webserver nicht nur nach bekannten Security Lücken ab, sie suchen ständig nach neuen. Ansonsten gäbe es keine Security Alerts mehr und man bräuchte auch keine Virenscanner mehr. Die Lücken der 80er und 90er Jahre sind alle längst geschlossen. Aber es werrden immer neue gefunden, eben weil hacker ständig auf der Suche nach neuen Lücken sind. Sie suchen auch dein neues Gerät und dessen neue Lücken. Und sie werden es irgendwann finden, wenn du pech hast. Solange nur ein Licht geschaltet wird, mag das harmlos sein. Aber was ist, wenn dein Auto nicht mehr bremst? Oder wenn dein Computer oder Internet Anschluss als Maske für Verbrecher genutzt wird? Oder wenn Nacktvideos deiner minderjährigen Nachbarin auf deiner Facebook Seite auftauchen, weil jemand den Smarten Fernseher gehackt hat? Dann bist du am Ende, niemand redet mit Kinderschändern - außer gleichgesinnte. Dann wirst du im Knast um eine Einzelzelle betteln, damit du von den anderen Insassen nicht misshandelt wirst. Das sind alles reale Szenarien.
Also langer Rede kurzer Sinn: Es wäre halbwegs vernünftig, deine Internet-Dinge von außen unerreichbar zu machen. Was ja bei allen üblichen WLAN Routern die Standardvorgabe ist. Wenn du etwas von "draußen" mit deinem Smartphone steuern möchtest, dann hänge einen richtigen Webserver dazwischen. Smartphone --> Internet ---> DSL Modem --> Internet Router --> Webserver --> Lokales Netz --> Internet-Dinge Wenn dann jemand dein kleine Ding hacken will, muss er erstmal den Webserver austricksen. Es ist 100 mal einfacher, einen normalen Webserver abszusichern, als einen Mikrocontroller. Und selbst dass ist kompliziert genug, dass eine ganze Branche davon lebt.
Hallo, Stefan U. schrieb: >> was riskiere ich eigentlich > > Zum Beispiel stellt jemand deine Heizung auf 35°C um (wenn sie denn mit > deinem Webserver verbunden ist), während u im Urlaub bist. > > Entscheident ist, wie gefährlich oder wichtig die Dinge sind, die über > dein NET-I/O steuerbar sind. Das sind die Folgen WENN ein Zugriff gelungen ist. Das sagt nicht, wie dieser Zugriff zustande kommen soll. > Und ja, ein Angreifer könnte dein gerät zum Absturz bringen oder wegen > zu vieler sinnloser Anfragen unerreichbar machen (DOS, hatte ich schon > genannt). Ein Scan zeigt, daß auf Port 80 jemand wohnt, mehr erstmal nicht. Natürlich kann ein DDOS-Angriff das Netz dicht machen. Auch wenn er einfach nur auf meine öffentliche IP ziehlt. Das hat weder mit dem NetIO noch einem anderen Gerät in internen Netz zwingend zu tun. > Wenn dein µC sein eigenes Programm ändern kann (der ESP8266 kann das), > könnte man auch Viren einschleusen, die Hackern z.B. Zugang zu deinem PC > verschaffen. Oder jemand könnte dein Gerät als Proxy Station benutzen, > um seine Identität zu verbergen. Dann bist du womöglich derjenige, der > angeblich das Pentagon gehackt hat. Auch ein ESP kann nur daß, was sein System zuläßt. Selbst den OTA-Port müßte ich erst forwarden, damit er von Außen erreichbar ist. Wie sicher der Webclient intern ist, müßte man schauen. Letzlich muß man den ja überreden z.B. die OTA-Routinen anzuspringen oder ein Flashrwrite in eigener Regie zustande zu bringen. Das müßte aber erst in den Flash, auch der ESP startet so ohne weiteres kein Programm aus dem Ram. >> Je mehr ich da also selber bastle umso weniger Risiko gehe ich >> im Prinzip ein. > > Das ist der falsche Denkansatz. Richtig ist: je mehr du ans Internet > direkt oder indirekt anschließt, umso mehr Risiko gehtst du ein. Nein. Das Risiko entsteht, weil Daten ud Zugriffe aus dem Internet etwas auf dem System ausrichten können. Dazu müssen sie aber von der Software erstmal behandelt werden. Auf dem NetIO und auch auf dem ESP wird aber nur behandelt, was überhaupt behandelt wwerden soll, alles andere landet sowieso im Nichts, es wird höchstens ein 404 zurückgegen. Wenn er also an meiner Heizung drehen wollte, müßte er bereits die nötigen Parameter im Aufrauf kennen. Eine Fehlermeldung wie "Heizung nur mit temp=35 schicken" werde ich wohl kaum als Antwort bei Fehlangaben schicken... > Eigene Software ist nicht automatisch sicherer, nur weil sie unbekannt > ist. Hacker finden Schwachstellen schnell und halb automatisiert. Sie > klopfen Webserver nicht nur nach bekannten Security Lücken ab, sie > suchen ständig nach neuen. Ansonsten gäbe es keine Security Alerts mehr > und man bräuchte auch keine Virenscanner mehr. Wir reden hier von IoT, also Sachen die z.B. zwar einen Webserver haben, dieser hat aber nur eine auf die Anwendung bezogene Funktionalität. Wonach soll da also automatisch gesucht werden? Was soll zurückkommen, wo ein Angreifer merkt, daß er richtig liegt? > Solange nur ein Licht geschaltet wird, mag das harmlos sein. > Aber was ist, wenn dein Auto nicht mehr bremst? Das ist die andere Baustelle von IoT, die Verantwirtung dafür tragen definitv die Entwickler dieser Systeme. > Oder wenn dein Computer oder Internet Anschluss als Maske für Verbrecher > genutzt wird? Dazu brauche ich kein IoT, kein NetIO und keinen ESP, die Schaden da nicht, helfen aber auch nicht. Inzwischen werden solche Angriffe zu fast 100% von den User selbst ausgelöst. Pishing- und Trojandermails und die USer erledigen das schon lange. Der letzt echte allgemeine Angriff dürfte vermutlich der Blaster-Virus gewesen, ansonsten die Adobe-Lücken und DriveBy-infektionen auf Webseiten. Das sind Dinge, die es schon lange gab und gibt. > Das sind alles reale Szenarien. Die aber wenig mit IoT zu tun haben. Da werden sofort Katstrohenszenarien angemaht, die nötigen Daten dazu liefern doch eher die Handynutzer mit Standortbestimmung, Zugriff auf alles Mögliche im handy, daß jede billige App erstmal beansprucht und das abgenickt wird, weil die Spielerei ja sonst nicht geht... PS: mein AVR-Net-IO, daß hier fast 5 Jahre 24/7 Sensordaten in die Welt gesetzt hat, wurde nicht einmal abgeschossen. Mein FTP auf dem NAS hatte 2-3 mal hilflose Versuche eines Kiddies im Log, der unbedingt versuchte, User und Passwort rauszufinden. Eine IP hatte ich mal im Router gesperrt, weil die stundenlang sinnlose Anfrage schickte und mein Netz brenste (nein, kein DDOS, irgendeine Suche nach einer Apache-Lücke damals. Gruß aus Berlin Michael
Du hast gerade bestätigt, dass private Internet Anschlüsse real gehackt werden. Vorsicht ist die Mutter der Porzellankiste.
Ich zittiere mal die Computerwoche: Die bislang häufig praktizierte Methode, erst eine Lösung zu entwerfen und Sicherheitskonzepte dann "irgendwie dazu" zu implementieren ist von Grund auf unangemessen. Das Internet of Things (IoT) stellt durch die Anzahl der möglicherweise betroffenen Devices, deren Distribution und Zugänglichkeit sowie die notwendigen Reaktionszeiten völlig andere Anforderungen an die IT-Security. Die Vorstellung, dass ein Kunde am Patchday seines Kühlschrankes zur Korrektur der Kühltemperaturermittlung mit dem Gerät zum Service seines Elektro-Marktes fährt, ist im besten Falle zynisch. Für die Halter der 1,4 Millionen betroffenen FCA-Fahrzeuge ist das allerdings Realität. Quelle: http://www.computerwoche.de/a/iot-die-sicherheit-der-dinge,3213672
Weitere Links zum Thema: http://www.zeit.de/digital/datenschutz/2014-08/black-hat-2014-hotelzimmer-gehackt http://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/ http://www.elektroniknet.de/embedded/software/artikel/124122/2/ http://venturebeat.com/2015/12/14/the-iot-is-the-internet-of-easy-home-hacking/ ich könnte hunderte dieser Warnungen zusammentragen. Ich bin ein vorsichtiger Mensch, aber sicher nicht paranoid. Du darfst mich alt nennen, wenn du magst.
Stefan U. schrieb: > Du hast gerade bestätigt, dass private Internet Anschlüsse real gehackt > werden. Vorsicht ist die Mutter der Porzellankiste. Jetzt verbreite mal hier keine Panik. Kein Mensch treibt den Aufwand Stefan U. schrieb: > Zum Beispiel stellt jemand deine Heizung auf 35°C um (wenn sie denn mit > deinem Webserver verbunden ist), während u im Urlaub bist. Du kommst > zurück, deine Blumen sind kaputt, die Fische Tot und die Stadtwerke > wollen 500 Euro nachzahlung für die Gasrechnung. Was hätte derjenige davon? Ist doch total albern und unrealistisch. Ich nehm das aber sofort zurück wenn Du mir ein Beispiel bringst wo das schon mal passiert ist ;-) Anders stehen die Notwendigkeiten bei der Absicherung öffentlicher und kritischer Infrastruktur. Da liegt sicher noch einiges im Argen. Internet of Nothing schrieb: > ein kleiner > Temperaturlogger mit Internetanbindung wie er dem TO vorschwebt und noch einiges mehr ist völlig uninteressant für irgendwelche Hacker.
> Kein Mensch treibt den Aufwand Falsch ich kenne einen (damit meine ich nicht mich selbst). Übrigens funktionieren alle mir bekannten Haus-Automations Systeme auf dem Prinzip, dass zwischen den "Dingen" und dem Internet ein PC (oder Mini PC) mit Webserver steht. >> deine Blumen sind kaputt, die Fische Tot und die Stadtwerke >> wollen 500 Euro nachzahlung für die Gasrechnung. > Was hätte derjenige davon? Ist doch total albern und unrealistisch. Er könnte Lösegeld erpressen (zahle xxx€ oder ich mach das immer wieder), wie die ganzen Verschlüsselungstrojaner, die gerade ganz hoch im Kurs sind. > Ich nehm das aber sofort zurück wenn Du mir ein Beispiel bringst wo > das schon mal passiert ist ;-) Hab ich schon. In zwei der oben verlinkten Artikel wurden reale Szenarien beschrieben. > ein kleiner Temperaturlogger mit Internetanbindung > wie er dem TO vorschwebt und noch einiges mehr ist völlig > uninteressant für irgendwelche Hacker. Es sei denn, man kann das Gerät auch missbrauchen, um seine Identität zu verschleiern oder um damit geheime Daten (z.B. Passwörter) von anderen Internet Verbindungen in der selben Wohnung abzuschnorcheln. Denke immer daran, für welche Zwecke man das Gerät möglicherweise missbrauchen kann. Ein Temperaturfühler ist in der Tat langweilig. Aber wenn man den umprogrammieren kann, dann wird er schnell sehr spannend. Es gab auch schon bekloppte, die haben Doom auf dem Display eines Druckers gespielt. Da siehst du, dass vernetzte Geräte prinzipiell für Hacker interessant sind und auch umprogrammiert werden. Nur gut, dass dies ein harmloser Spaß war.
Stefan U. schrieb: > Falsch ich kenne einen (damit meine ich nicht mich selbst). Oh, dann muß ich mich wohl revidieren... ;-) Trotzdem muß ich mich schon sehr anstrengen, durch die Anbindung meiner Controller ans Netz irgendwelche paranoiden Angstgefühle zu entwickeln. > übrigens funktionieren alle mir bekannten Haus-Automations Systeme auf > dem Prinzip, dass zwischen den "Dingen" und dem Internet ein PC (oder > Mini PC) mit Webserver steht. Tja, es gibt eben auch Alternativen die Du noch nicht kennst. Die Standard-Lösung via PC Webserver mag zwar schnell aufzusetzen, leistungsfähig und günstig sein, bedeutet aber in aller Regel, daß man sich damit mehr Stromverbrauch, mehr Platzbedarf, unbekannte Sicherheitslücken und die ganze Palette der notwendigen Absicherungsmaßnahmen einhandelt.
Hallo, Stefan U. schrieb: > Du hast gerade bestätigt, dass private Internet Anschlüsse real gehackt > werden. Vorsicht ist die Mutter der Porzellankiste. wo? Hast Du Dir mal die Logs eines normal am I-Net hängenden DSL-Routers angeschaut, wenn es da welche gibt? Was sich täglich tummelt? Das hat nichts mit "gehackt" zu tun. Gehackt ist, wenn jemand reingekommen ist. >Es gab auch schon bekloppte, die haben Doom auf dem Display eines >Druckers gespielt. Da siehst du, dass vernetzte Geräte prinzipiell für >Hacker interessant sind und auch umprogrammiert werden. Nur gut, dass >dies ein harmloser Spaß war. Ich habe schon Doom und Tetris auf einer Kodak DC260 Kamera gespielt. Hat mit gehackt auch nichts zu tun. Wenn plötzlich MEIN Drucker hier angeht und jemand Doom drauf speilt, dann würde ich mich allerdings wundern. zu Moby: völlg richtig. Mein RasPi hat ein wesentlich größeres Risikopotenzial mit Mosquitto und IceCast drauf als die ESP direkt im WLAN. Gruß aus Berlin Michael
Moby schrieb: > Sheeva P. schrieb: >> Wenn man auf bewährte Webserver-Technologien zurückgreift, bekommt man > > nein, nicht den höchsten Sichrheitslevel, sondern eine komplexe > Technologie, die man nicht 100%ig selbst in der Hand hat inklusive aller > unentdeckten Bugs und Lücken. Über die Zwischenstufe serieller > Ascii-Daten inklusive der nur mir bekannten Dateninterpretation erreiche > ich die höchstmögliche denkbare Sicherheit- diese Zwischenstufe in > Hardware entkoppelt quasi von allen potentiellen Sicherheitslücken, die > im Netzwerk-Interface selbst noch schlummern mögen. Da gibts keine > Ausbruchmöglichkeit, das erübrigt sämtliche Überlegungen a'la Hybris gehört nach Larry Wall bekanntlich zu den Kardinaltugenden eines Programmierers. Aber findest Du nicht, daß Du es ein wenig übertreibst? Netzwerktechnik ist eine ziemlich komplexe Veranstaltung, und ich würde wirklich gerne einmal sehen, wie Du einen IP-Stack von der Bit- über die Ethernetschicht bis IP und TCP in Deinem geliebten Assembler schreibst. Aber Du hast damals schon gesagt, daß Dir das zu schwer ist, weshalb Du das lieber teuren Fertigmodulen wie dem X-Port überläßt... Stattdessen willst Du nun aber einen eigenen Webserver schreiben? Etwa in Assembler? Und als Grund dafür führst Du ausgerechnet an, daß Dir die über Jahre bewährten und gereiften Webserver nicht sicher genug seien -- und Du davon überzeugt bist, das besser zu können? Na dann: viel Glück. ;-)
Michael U. schrieb: > Auch ein ESP kann nur daß, was sein System zuläßt. Das hat man in den Anfangstagen der Computervernetzung auch gedacht. Bis einer gemerkt hat, wie man Code in fremde Systeme einschleusen kann. ;-)
Moby schrieb: > Stefan U. schrieb: >> Du hast gerade bestätigt, dass private Internet Anschlüsse real gehackt >> werden. Vorsicht ist die Mutter der Porzellankiste. > > Jetzt verbreite mal hier keine Panik. > Kein Mensch treibt den Aufwand > > Stefan U. schrieb: >> Zum Beispiel stellt jemand deine Heizung auf 35°C um (wenn sie denn mit >> deinem Webserver verbunden ist), während u im Urlaub bist. Du kommst >> zurück, deine Blumen sind kaputt, die Fische Tot und die Stadtwerke >> wollen 500 Euro nachzahlung für die Gasrechnung. > > Was hätte derjenige davon? Ist doch total albern und unrealistisch. > Ich nehm das aber sofort zurück wenn Du mir ein Beispiel bringst wo das > schon mal passiert ist ;-) Was hatten denn die Skriptkiddies in den Neunzigern davon, fremde Computer und Netzwerke lahmzulegen? Ist doch total albern und unrealistisch. Was haben die linken Faschos davon, in Berlin und anderen Städten fremde Autos abzufackeln? Ist doch total albern und unrealistisch.
Hallo, >> ... Heizung auf 35°C ... > Das sind die Folgen WENN ein Zugriff gelungen ist. > Das sagt nicht, wie dieser Zugriff zustande kommen soll. Je mehr Geräte du ins Netz hängst, desto wahrscheinlicher ist es, dass eins davon gehackt wird. Je mehr du selbst programmierst, desto sicherer ist dein System, weil es kein Standardsystem ist - und desto unsicherer ist dein System, weil du möglicherweise die ganzen Bugs der 90er wieder drin hast. > Ein Scan zeigt, daß auf Port 80 jemand wohnt, mehr erstmal nicht. Glaubst du ernsthaft, dass Hacker heutzutage noch zu Fuß einen nmap auf eine IP-Adresse schicken und schauen, was da passiert? Die entwickeln sich auch weiter. Künstliche Intelligenz gibt es nicht nur bei Google, sondern inzwischen auch in den Netzwerk-Analysetools. Da kippst du vorne eine grobe Beschreibung deines Protokolls rein ("\w+ URL HTTP/1.\d") und eine mögliche Antwort rein und dann lässt du das Teil suchen. Modernes Fuzzing. Öffentliche SSH-Server werden auch abseits von Port 22 gefunden, und die Passwörter werden langfristig durchprobiert. Alle 5 Minuten ein Versuch, das ganze über Monate, und du wirst in deinen Logs eher nichts bemerken. Hauptsache, das Botnetz bleibt unerkannt. (Die Great Firewall macht das auch, um Tunnel und Proxys zu erkennen.) > Auch ein ESP kann nur daß, was sein System zuläßt. Flash ist zur Laufzeit beschreibbar. Dank ROP braucht man das aber nichtmal, um eigenen Code auszuführen. Es reicht, die Kontrolle über den Stack zu haben. Ein Buffer Overflow und NX ist ausgehebelt. > Eine Fehlermeldung wie "Heizung nur mit temp=35 schicken" werde ich wohl > kaum als Antwort bei Fehlangaben schicken... Ein Fuzzy-Angriff wird relativ schnell merken, was behandelt wird und was nicht. Und möglicherweise auch, was behandelt wird, aber besser nicht sollte. > Wir reden hier von IoT, also Sachen die z.B. zwar einen Webserver haben, > dieser hat aber nur eine auf die Anwendung bezogene Funktionalität. > Wonach soll da also automatisch gesucht werden? Was soll zurückkommen, > wo ein Angreifer merkt, daß er richtig liegt? Ein 200 für "request war gültig", ein 500 für "der request wurde nicht verstanden", ein Timeout für "Treffer, versenkt". Wenn du im Urlaub bist, muss der Angreifer auch nicht deine Heizung auf 35 Grad stellen. Es reicht, wenn er den Regler abschießt - je nachdem, in welchem Zustand der gerade war, hast du dann entweder Eisblumen am Fenster oder Asche auf dem Boden... und bei einer selbst gebauten Steuerung wird dir die Versicherung in beiden Fällen was husten. >> Oder wenn dein Computer oder Internet Anschluss als Maske für Verbrecher >> genutzt wird? > Dazu brauche ich kein IoT, kein NetIO und keinen ESP, die Schaden da > nicht, helfen aber auch nicht. Wenn deine Hausautomatisierung (oder dein Router) als Botnetz arbeitet, Spam verschickt und Kinder*piep* tunnelt, merkst du das nie. > Der letzt echte allgemeine Angriff dürfte vermutlich der Blaster-Virus > gewesen, ansonsten die Adobe-Lücken und DriveBy-infektionen auf > Webseiten. Stelle mal ein ungepatchtes System für ein paar Wochen ins Internet. ;-) Moby schrieb: > Jetzt verbreite mal hier keine Panik. > Kein Mensch treibt den Aufwand Da hast du vollkommen Recht. Den Aufwand treiben nämlich Programme in Maschinen, denn die werden nicht müde und können stundenlang protokollieren. Und das Protokoll filtern. Und es gibt genug Menschen, die solche Programme antreiben. Da fällt gelegentlich auch mal ein Jobangebot bei raus (oder ein SEK). > Was hätte derjenige davon? Ist doch total albern und unrealistisch. Genau so albern und unrealistisch wie "gib mir ein Bitcoin und ich entschlüssele deine Festplatte wieder". > Ich nehm das aber sofort zurück wenn Du mir ein Beispiel bringst wo das > schon mal passiert ist ;-) Gewisse Elemente verdienen so ihr Geld. > Trotzdem muß ich mich schon sehr anstrengen, durch die Anbindung meiner > Controller ans Netz irgendwelche paranoiden Angstgefühle zu entwickeln. Man muss böse Dinge nicht mit 4 MB/s durchs Internet jagen, um anderen Leuten Sand ins Getriebe zu streuen... 20 KB/s durch einen AVR reichen auch. Unsere Gesellschaft ist inzwischen so weit, dass man durch Facebook-Posts seinen Job verlieren kann und mutmaßlichen Kinderschändern glaubt man ohnehin nichts mehr. >> übrigens funktionieren alle mir bekannten Haus-Automations Systeme auf >> dem Prinzip, dass zwischen den "Dingen" und dem Internet ein PC (oder >> Mini PC) mit Webserver steht. Am besten sind simple Brücken, die Modbus/Zweidraht auf Modbus/IP umsetzen und noch nie davon gehört haben, dass die notwendige Sicherheit in beiden Systemen deutlich unterschiedlich ist. Da gab's letztens einen schönen Hotel-Hack. Gruß, Svenska
Sheeva P. schrieb: > Stattdessen willst Du nun aber einen eigenen Webserver schreiben? Etwa > in Assembler? Und als Grund dafür führst Du ausgerechnet an, daß Dir die > über Jahre bewährten und gereiften Webserver nicht sicher genug seien -- > und Du davon überzeugt bist, das besser zu können? Na dann: viel Glück. Dieses Glück genieße ich schon viele Jahre ;-) Wer sagt denn, daß es zur Auslieferung einfacher Internetseiten eines ausgereiften Servers bedarf? Das schafft schon jeder Tiny, wenn die Netzwerk-Schnittstelle gekapselt und einfach seriell zu beschicken ist. Das ist ja das Schöne an einem einfachen Netzwerk<->Ser.Port Wandler. Offensichtlich hast Du meine Umsetzung gar nicht verstanden- oder willst es nicht.
Moby schrieb: > Offensichtlich hast Du meine Umsetzung gar nicht verstanden- oder willst > es nicht. Gilt auch für Dich hier: S. R. schrieb: > Da hast du vollkommen Recht. Den Aufwand treiben nämlich Programme in > Maschinen, denn die werden nicht müde und können stundenlang > protokollieren. Und das Protokoll filtern. Mit Protokollieren und Protokoll filtern kommt man eben bei individuellen Lösungen nicht unbedingt zum Ziel. Dann muß man als Hacker auch erstmal die Adresse finden. Erstmal die Absicht haben, einen bestimmten Schaden anzurichten. Mich erstmal kennen... Einfach nur lächerlich, was hier an Gefahren für den Hobbybastler an die Wand gemalt werden.
Hallo, @ Moby (Gast): Zustimmung. Diese Szenarien sind reine Theorie, wenn ein AVR oder ein ESP am anderen Ende wohnt. Programmcode in den Stackbereich bringen ist ohnehin völlig nutzlos da, er kann nicht ausgeführt werden, weil der AVR sowieso keinen Programmcode im Ram ausführen kann und beim ESP der Stack im data Ram und nicht im instruction Ram liegt. Man kann keine Webserver- oder Systemfunktionen mißbrauchen, wenn diese schlicht ganicht implementiert sind. Gruß aus berlin Michael
Moby schrieb: > Sheeva P. schrieb: >> Stattdessen willst Du nun aber einen eigenen Webserver schreiben? Etwa >> in Assembler? Und als Grund dafür führst Du ausgerechnet an, daß Dir die >> über Jahre bewährten und gereiften Webserver nicht sicher genug seien -- >> und Du davon überzeugt bist, das besser zu können? Na dann: viel Glück. > > Dieses Glück genieße ich schon viele Jahre ;-) > Wer sagt denn, daß es zur Auslieferung einfacher Internetseiten eines > ausgereiften Servers bedarf? Das schafft schon jeder Tiny, wenn die > Netzwerk-Schnittstelle gekapselt und einfach seriell zu beschicken ist. > Das ist ja das Schöne an einem einfachen Netzwerk<->Ser.Port Wandler. > > Offensichtlich hast Du meine Umsetzung gar nicht verstanden- oder willst > es nicht. Ich habe Deine Umsetzung verstanden -- und auch das, was Du hier behauptet hast. Du behauptest nämlich, daß Du nicht auf einen vorhandenen Webserver zurückgreifen willst. Mit Deinem "Netzwerk<->Ser.Port Wandler" machst Du aber ganz genau das: Du benutzt den eingebauten Webserver Deines XPort. Der dürfte aber mindestens ebensoviele Fehler enthalten wie ein beliebiger Apache, nginx, lighthttpd, uwsgi, ... wobei die von mir genannten bereits seit vielen Jahren im Einsatz und technisch zweifellos ausgereifter sind, als irgendeine dubiose, proprietäre Software in einem exotischen Gerät wie dem XPort. Und Dein XPort ist zwar kein PC, hat aber genug Leistung und Ressourcen, daß sich ein Angreifer dort prima einnisten könnte. Insofern scheinst es Du selbst zu sein, der Deine eigene "Umsetzung" und ihre Gefahren gar nicht verstanden hat -- und es nicht will.
Sheeva P. schrieb: Du behauptest nämlich, daß Du nicht auf einen > vorhandenen Webserver zurückgreifen willst. Mit Deinem > "Netzwerk<->Ser.Port Wandler" machst Du aber ganz genau das: Du benutzt > den eingebauten Webserver Deines XPort. Das ist Unsinn. Dort ist zwar ein Webserver der HTML-Seiten ausliefern könnte eingebaut, der wird aber nicht genutzt. Tatsächlich werden Daten aus Web-Anfragen nur 1:1 seriell durchgereicht. > Der dürfte aber mindestens ebensoviele Fehler enthalten wie ein > beliebiger Apache, nginx, lighthttpd, uwsgi, ... wobei die von mir > genannten bereits seit vielen Jahren im Einsatz und technisch zweifellos > ausgereifter sind, als irgendeine dubiose, proprietäre Software in einem > exotischen Gerät wie dem XPort. Du scheinst nicht zu begreifen, daß diese Fehler so sie denn vorhanden wären hier irrelevant sind: Maßgeblich ist das, was hinten seriell rauskommt. Enthielte es Fehler oder wären die Daten unplausibel passiert damit bei der Auswertung im Controller (selbstverständlich in Asm ;-) just nur eines: Es wird ignoriert. > aber genug Leistung und Ressourcen, daß sich ein Angreifer dort prima > einnisten könnte. Das dürfte beim XPort nicht so einfach sein, kannst es ja mal versuchen. Durch einen dahergelaufenen Hacker ohne bekanntes Ziel schon mal gar nicht. Da wird das "Exotische" echt zum Vorteil ;-) Was sollte dieser Angreifer auch bewirken? Die erwähnte Plausibilitätsprüfung der Daten durch den MC wird er nicht überlisten. Die Zweiteilung der Aufgabe über a) ein Netzinterface und b) einem angeschlossenen Controller über c) die unüberwindliche Klartext-Brücke "Serielle Leitung" wird hier zu einem echten Sicherheits-Plus. Hast Du das jetzt verstanden? Und überhaupt- wenn, dann darf man Geheimdiensten diese Einnist-Fähigkeiten zutrauen. Die wird das Interface meiner bescheidenen Haussteuerung aber einen Sch... interessieren. Also merke: Nicht alles was theoretisch möglich ist ist es auch in der Praxis ;-)
Hallo, Sheeva P. schrieb: > Ich habe Deine Umsetzung verstanden -- und auch das, was Du hier > behauptet hast. Du behauptest nämlich, daß Du nicht auf einen > vorhandenen Webserver zurückgreifen willst. Mit Deinem > "Netzwerk<->Ser.Port Wandler" machst Du aber ganz genau das: Du benutzt > den eingebauten Webserver Deines XPort. > > Der dürfte aber mindestens ebensoviele Fehler enthalten wie ein > beliebiger Apache, nginx, lighthttpd, uwsgi, ... wobei die von mir > genannten bereits seit vielen Jahren im Einsatz und technisch zweifellos > ausgereifter sind, als irgendeine dubiose, proprietäre Software in einem > exotischen Gerät wie dem XPort. Und Dein XPort ist zwar kein PC, hat > aber genug Leistung und Ressourcen, daß sich ein Angreifer dort prima > einnisten könnte. auch wenn es eine Antwort für Moby war: selbstverständlich kann dieser oder ein anderer Webserver Fehler haben. Ein Angriff erfordert aber 2 Grundlagen: ich muß rausfinden, in welcher Systemumgebung ich gelandet bin, dort ein ausführbares Progrmm unterbringen und Starten können. Beim den üblichen Webservern geht das meist über Lücken in der Script-Ebene (PHP,Pearl,...) da dort Zugriff mit den nötigen Rechten vorliegt. Primitiv gesagt: ich kann auf einer Linux-Maschine den Aufruf von "format c:" zwar loslassen, erreiche aber nichts damit. Genauswenig wie unter Windows mit "rm xyz". Alles was Du anführst, bedingt erstmal Kenntnis über das System zu erlangen, völlig egal, ob direkt geziehlt oder indirekt, indem eben mehrere Versuche gemacht werden, bis einer passt. Natürlich geht das alles (auch) automatisch mit allen bekannten Lücken auf allen bekannten Systemkonfigurationen, dazu die zero-Day-Lücken, wo die Chance am Größten ist. Das geht aber eben an dem vorbei, worüber Moby und ich sozusagen philosophieren. Um z.B. eine Lücke im lighthttp angreifen zu können muß ich a) rausfinden das ein lighthttp läuft b) welche Version des lighthttp läuft c) auf welchem System der lighthttp läuft Das ist einfach, weil ein üblicher Webserver das sowieo meldet bzw. ganz legal abfragbar ist. Ich müßte den WiPort, der irgendwo noch rumliegt, mal anwerfen um zu schauen, was dieser antwortet. Bei mir endet schon diese Abfrage im Dunkeln, ich könnte natürlich mit "ESP-Webserver v1.x SDK1.5.0" antworten, würde vermutlich aber kaum Schaden anrichten können. PS: ich finde das Thema interessant, weil ich mir darüber durchaus Gedanken mache. Das ist dann aber für mich was Konkretes, dazu ist das bisher aber alles zuviel Allgemeines, das eben kein Angriffsszenario auf solche ein System darstellen kann, auch wenn es Internet steht. Gruß aus Berlin Michael
:
Bearbeitet durch User
Michael U. schrieb: > Das geht aber eben an dem vorbei, worüber Moby und ich sozusagen > philosophieren. Ich glaube daß Sheeva P. sich einfach nicht vorstellen kann, wie man eingehende HTTP Daten (nach einem Umsetzer auf seriell) auch ganz ohne vorhandenen (hochausgereiften :-) Webserver manuell mit einem Controller handeln kann... Programmcode über diese Daten auf dem Controller selbst einzuschleusen ist natürlich vollkommen illusorisch. Den XPort habe ich in verschiedenen Varianten schon viele Jahre im Einsatz. Heute würde ich es mit dem billigen ESP-x versuchen und mich damit genauso sicher fühlen, wenn das Teil denn die gleiche nötige Langzeit-Stabilität im Betrieb nachweist.
:
Bearbeitet durch User
Hallo, Moby A. schrieb: > Heute würde ich es mit dem billigen ESP-x versuchen und mich > damit genauso sicher fühlen, wenn das Teil denn die gleiche nötige > Stabilität im Betrieb nachweist. schwierig zu beantworten. Hier laufen im Moment nur "unsinnige" Sachen, vorrangig als MQTT-Clients. Ein ESP mit RFM12 spielt Bridge zu meinen alten Sensoren, abgestürzt ist er in den letzten Wochen nicht, WLAN-reconnects vielleicht 2-3x pro Woche, wenn hier am Wochenende im Umfeld WALN-Chaos herrscht. Es gibt Situationen, in denen die Antwortzeit das Timeout des HTMLWindows-Client (irgendwo im Netz gefunden) übersteigt und dieser "Seite nicht gefunden" meldet (Seite wird mit "<meta http-equiv="refresh" content="15; URL=index.html">" ausgeliefert. Allerdings laufen dort eben noch ein paar andere Sachen, RFM12-Empfang im Interrupt, +ber die serielle kommen die Daten der E3000 Energiesensoren und empfangene IR-Fernbedienbefehle von einem Mega328. Mein IceCast Stream-Client (ESP + VS1003-Decoder) ist stabil bis 320kBit, allerdings laufen bereits bei 192kBit weder PubSubClient noch der ESP8266-MQTT stabil zusammen mit dem Stream. Es stürzt nichts ab, es werden entweder MQTT-Connects gemeldet, obwohl er eigentlich nicht raus war oder empfangene Nachrichten werden unterschlagen. Das habe ich mir aber noch nicht genauer angesehen. OTA-Update geht mit laufendem Stream auch nicht mehr (Timeout). Ist auch mehr eine Art Grenzwert-Test und eher verblüffend, was dieses Spielzeug zustande bringt, für die wenigen Euro. Ich halte den ESP mit dem aktuellen SDK für stabil wenn man in seinen Grenzen bleibt und auf die internen Eigenarten Rücksicht nimmt. Gruß aus Berlin Michael
Moby schrieb: > Mit Protokollieren und Protokoll filtern kommt man eben bei > individuellen Lösungen nicht unbedingt zum Ziel. > Dann muß man als Hacker auch erstmal die Adresse finden. Richtig, es dauert schließlich Monate, wenn nicht gar Jahrzehnte, das Internet abzuscannen! Man muss schließlich jede einzelne IP per Hand eingeben! > Erstmal die Absicht haben, einen bestimmten Schaden anzurichten. > Mich erstmal kennen... (Un)Geschickt scannen hat schon so manches Programm zum Absturz gebracht. Nicht jeder DoS ist ein gezielter Angriff. > Einfach nur lächerlich, was hier an Gefahren für den Hobbybastler an die > Wand gemalt werden. Die Wahrscheinlichkeit, dass jemand gezielt einsteigt, ist sehr gering. Der maximal mögliche Schaden hängt davon ab, was genau da gesteuert wird. Das Risiko (und damit das, was eine Versicherung bewertet) ist das Produkt aus beiden. Und IoT basiert grundsätzlich darauf, dass du billigsten Chinakram mit wenig Absicherung für die gesamte Haus- und Lebensautomatisierung einsetzt. Letzteres schafft Umsatz, ersteres schafft Gewinn. Eine handgefrickelte Rollosteuerung ist nicht anfällig für (un)bekannte Windows-Lücken. Sie ist aber anfällig für primitive Bugs. Michael U. schrieb: > Programmcode in den Stackbereich bringen ist ohnehin völlig nutzlos da, > er kann nicht ausgeführt werden, [ ] Du hast verstanden, was ROP ist und wie es funktioniert. > Man kann keine Webserver- oder Systemfunktionen mißbrauchen, wenn diese > schlicht ganicht implementiert sind. Auch ein primitiver, handgeklöppelter Webserver enthält genug Gadgets, um turingvollständig zu sein. Moby schrieb: > Enthielte es Fehler oder wären die Daten unplausibel > passiert damit bei der Auswertung im Controller (selbstverständlich in > Asm ;-) just nur eines: Es wird ignoriert. Fehlerhafte Anfragen werden also einfach ignoriert. Das klappt schon seit 70 Jahren ausreichend gut, also bauen wir auch weiterhin darauf. Michael U. schrieb: > Ein Angriff erfordert aber 2 Grundlagen: ich muß rausfinden, in welcher > Systemumgebung ich gelandet bin, dort ein ausführbares Progrmm > unterbringen und Starten können. Nein. Es reicht, wenn ich das bereits vorhandene Programm dazu bringe, Dinge zu tun, die es nicht tun sollte. > Beim den üblichen Webservern geht das meist über Lücken in der > Script-Ebene (PHP,Pearl,...) da dort Zugriff mit den nötigen Rechten > vorliegt. Die auf einem Mikrocontroller de facto immer vorliegen. Wenn der Webserver behauptet, er wäre ein "lighttpd/1.3.5", dann lässt sich relativ schnell fingerprinten, ob es auch wirklich einer ist. Tools machen sowas automatisiert, um z.B. Honeypots zu erkennen. Gleiches gilt für den TCP-Stack, der das OS verrät. Im Gegensatz zu großen Netzwerken (wo man mal eine OS/2-Maschine dazu stellen kann, um Angreifer zu verwirren) ist dein Controller auch vollkommen deterministisch. Und wenn es kein bekanntes Produkt ist, kann ich ja mal eine 4 MB große HTTP-Anfrage hinschicken und schauen, was passiert. Der AVR wird entweder abstürzen oder die Spezifikation verletzen müssen. Wenn er Encoding kann, also statt "index.html" auch "inde%78.html" akzeptiert, dann kann ich ja mal ein "%00" oder ein "%2500" einbauen, oder sogar ein "%%30%30". Wenn irgendwo eine Ausgabe als Teil eines Formatstrings benutzt wird (z.B. in der Fehlermeldung) und das Gerät eine halbwegs plausible libc hat, kann ich beliebige Brainfuck-Programme ausführen - passenden Compiler gibt's im Netz - und habe damit eine turingmächtige Sprache zur Hand. Ob du das Risiko als vernachlässigbar einschätzt oder nicht, bleibt dir überlassen - aber es einfach wegzuerklären ist fahrlässig.
Michael U. schrieb: > Ich halte den ESP mit dem aktuellen SDK für stabil wenn man in seinen > Grenzen bleibt und auf die internen Eigenarten Rücksicht nimmt. Interessant. Man hört ja hinsichtlich Absturzsicherheit so einiges. Danke für die Rückmeldung. Hab schon so einige von den ESPs hier rumliegen aber noch nicht im Einsatz. > Es gibt Situationen, in denen die Antwortzeit das Timeout des > HTMLWindows-Client (irgendwo im Netz gefunden) übersteigt und dieser > "Seite nicht gefunden" meldet Das Phänomen kenn ich beim XPort aber auch. Bleibt aber in erträglichem Rahmen (vielleicht mal 1 von 50 Abfragen, provoziert auch von mehreren schnellen Abfragen hintereinander).
S. R. schrieb: > Richtig, es dauert schließlich Monate, wenn nicht gar Jahrzehnte, das > Internet abzuscannen! Man muss schließlich jede einzelne IP per Hand > eingeben! Um Zugriff auf das eigentliche Ziel hinterm Umsetzer zu erhalten brauchst Du nicht nur IP und Port ;-) > (Un)Geschickt scannen hat schon so manches Programm zum Absturz > gebracht. Meinen XPort noch nicht ;-) Die Möglichkeit die Internetanbindung von außen so unbrauchbar zu machen hatte ich aber glaube ich schon erwähnt. Das ist aber weit entfernt davon, gleich irgend einen Schaden oder gar missbräuchliche Bedienung auszulösen. Tatsächlich kommen so einige Anfragen zusätzlich rein. Die stehen aber in keinem Verhältnis zu den von mir getätigten. > Die Wahrscheinlichkeit, dass jemand gezielt einsteigt, ist sehr gering. > Der maximal mögliche Schaden hängt davon ab, was genau da gesteuert > wird. Das Risiko (und damit das, was eine Versicherung bewertet) ist das > Produkt aus beiden. Was soll mir das jetzt sagen? Soll ich es mit der Angst zu tun bekommen? > Und IoT basiert grundsätzlich darauf, dass du billigsten Chinakram mit > wenig Absicherung für die gesamte Haus- und Lebensautomatisierung > einsetzt. Letzteres schafft Umsatz, ersteres schafft Gewinn. Ich setze keinen "billigsten" Kram ein und chinesische Produkte werden auch immer besser... Umsatz und Gewinn der beteiligten Unternehmen interessieren mich nur insoweit als daß diese Größen für ein reichhaltiges Angebot unabdingbar sind. > Eine handgefrickelte Rollosteuerung ist nicht anfällig für (un)bekannte > Windows-Lücken. Sie ist aber anfällig für primitive Bugs. Ach erzähl doch keine Opern. Deine imaginären "primitiven Bugs" würde ich nach vielen Jahren längst kennen. Wohlweislich nennst Du keine konkreten ;-) > Fehlerhafte Anfragen werden also einfach ignoriert. Das klappt schon > seit 70 Jahren ausreichend gut, also bauen wir auch weiterhin darauf. So und genau so schaut es aus! > Ob du das Risiko als vernachlässigbar einschätzt oder nicht, bleibt dir > überlassen - aber es einfach wegzuerklären ist fahrlässig. Nicht das Risiko wird wegerklärt sondern seine Bedeutung für die Praxis. Du kannst mir keine aussichtsreiche Strategie erläutern, wie man in ein wie von mir beschrieben zweistufig aufgebautes System eindringen könnte. Wer das wollte und warum. Nicht mal theoretisch. Was fortwährend in Deinem Kopf rumspukt sind die hunderttausend Sicherheitsprobleme, die (hochausgereifte) Standard-Software in Standard PC-Technik offenbart!
:
Bearbeitet durch User
Hallo, S. R. schrieb: > Und wenn es kein bekanntes Produkt ist, kann ich ja mal eine 4 MB große > HTTP-Anfrage hinschicken und schauen, was passiert. Der AVR wird > entweder abstürzen oder die Spezifikation verletzen müssen. Wenn er > Encoding kann, also statt "index.html" auch "inde%78.html" akzeptiert, > dann kann ich ja mal ein "%00" oder ein "%2500" einbauen, oder sogar ein > "%%30%30". ok, das sieht viel konkreter aus: Zu der 4MB großen Anfrage: ich werde das mal Testen, muß jetzt vermuten: wenn ein /r in den ersten 2,2k kommt, bekomme ich die Anfrage zu sehen, sonst dürfte ein leerer String ankommen und der Timeout von 1s schlägt zu. Schaue ich mir unbedingt mal an. Encoding ja, aber bedingt: Wenn ein GET vorkommt (POST habe ich (vorerst) hier garnicht drin) wird der Pfad extrahiert, dort wird kein Encoding geprüft, es bliebe also "inde%78.html". Diese Datei wird dann versucht, auf dem Flasfilesysten zu öffnen. Eigentlich sollten alle Varaitionen damit ein 404 zurückliefern. Joker kann das SPIFFS nicht, es bleibe aslo nut der Slash als gültiges Zeichen für einen Ordner, wäre also auch ein 404. Das kann ich nachprofen, soviel ist die Parameterübergabe in den Sourcen vom SPIFFS nicht. Außer bei einem 0-Byte sollte eigentlich garnichts passieren, das wäre dann eben ein Stringende, alles danach kommt sowieso nicht an, genauso bei \r. PS: natürlich wärst Du z.B. mit dem Aufruf der IP oder IP/index.html auf der regulären Webseite und würdest somt (im Moment) sehen, wie warm in meinem Keller oder im Gefrierfach ist. Wenn ich User/Passwort abfrage, kann natürlich eine Wörterbuch-Attacke usw. regulären Zugang verschaffen, da kann man dann gern Zeitbegrenzungen, IP-Sperren usw. einbauen, da wären wir aber wieder da, wo jedes System von Außen nur die nötige (elektronische) Geduld aufbringen müßte. Die Frage ist doch, was will der Nutzer von seinem System. Die Heizung aus dem Urlaubsort hochdrehen war ja so ein Beispiel. Entweder ich mache es mit spezieller Software vom Handy oder Pad mit (hoffentlich) sicherer Übertragung, dann muß die da eben drauf und sicher sein. Die "tolle App" aus der Kostenlos-Ecke wird das vermutlich nicht bieten, die nehmen aber die Leute gern... Wie sicher sind z.B. FHEM, OpenHub usw. wirklich? Ich will damit nichts in Frage stellen, ich weiß es schlicht nicht, weil sie nicht genutzt habe und mich damit bisher auch nicht informiert habe. Oder ich mache es per Webinterface aus jedem Browser, dann ist es auch in diesem Rahmen angreifbar. Gruß aus Berlin Michael
Eine einzelne über Internet steuerbare Lampe macht mich sicher nicht heiß. Aber wenn das ganze Haus steuerbar ist, mit allem Pi-Pa-Po der heute so angeboten wird, dann vertausendfacht sich das Risko allein schon wegen der Menge der Geräte. Wenn das Internetfähige Gerät beispielsweise online aktualisiert werden kann (wie die meisten Smartphones, Internetrouter und sigar die ESP8266 Module), dann muss ich mich nur noch als Man-In-The-Middle in die Internetverbindung einklinken und das Update auslösen. Es ist dann kinderleicht, beliebige Fremdsoftware auf die Geräte zu installieren. Du magst denken "Mein Router kann nur von "innen" zu einem Firmware-Upgrade bewegt werden". Und was, wenn das nur die halbe Wahrheit ist? Hatte die Firma LG nicht gerade erst rote Ohren bekommen, weil sie erwischt wurden, die Kamera im TV aus der Ferne aktiviert zu haben? Man kann ja nichtmal den Herstellern der Geräte trauen! Was, wenn dein Xport einen Bug hat und man durch einen Pufferüberlauf von Außen den Download einer modifizierten Firmware anstoßen kann? Was, wenn Dir jemand eine böse Email schickt, die deinen Router unbemerkt anweist, sich zu aktualisieren? Dann kommt der Angriff plötzlich indirekt doch von innen. Ok, dein PC ist sicher. Was ist mit deinem Smartphone? Macht deine Taschenlampen App wirklich nur Licht? Dient der Youtube Downloader wirklich nur dazu, Videos runterzuladen? Oder kann er als Relaistation dienen, um dein Netz von innen anzugreifen? Alle aktuellen WLAN Geräte (ja auch der ESP8266) haben ein Stück Closed-Source Software, sonst wären die Geräte nicht zulassungsfähig. Weist du wirklich, was diese Software tut und kann? Die Hersteller von IoT Geräten gehen Studien zufolge grenzenlos naiv mit dem Thema Internet Sicherheit um. Sogar Hersteller von teuren Autos erlauben Zugriff ohne jegliche Sicherheit (man braucht nur die Seriennummer, die von außen mit bloßem Auge ablesbar ist). Es scheint, dass bei diesen Produkten nur der Coolness Faktor und viel Umsatz zählt. Security interessiert keinen. Soweit waren wir auch, als das Internet in Deutschland für Privatkunden zugänglich wurde. Und da ging es erst richtig los mit Viren, Spam, Hackern, Erpressung und Identitätsdiebstahl. Diese Themen haben wir inzwischen einigermaßen im Griff. Ich fürchte aber, dass die IoT Geräte in richtig großem Stil neue Lücken einführen, die uns sicherheitstechnisch zurück in die 90er Jahre verfrachten. Und dann geht der ganze Scheiß wieder los. Ich sehe hier noch keinen Grund zur Panik, aber Vorsicht halte ich für angemessen.
Hallo, @Stefan Us (stefanus): alles, was Du ansprichst, ist prinzipiell richtig, kann passieren, ist teilweise schon passiert. Prinzipiell reicht mir aber hier nicht. Die Frage eiens Angriffs von Innen ist eine generelle, völlig unabhängig von IoT. Ich und alle anderen müssen bis zu gewissen Grenzen "an das Gute im Menschen" glauben, speziell, wenn sie Windows benutzen. Aber selbst da hat sich in den letzten Jahres positives getan. Ich muß darauf vertrauen, daß Thunderbird nicht ungefragt Mail-Inhalte ausführt. Ist letztlich eine Sache der Einstellung, muß ich eben explizit jedesmal erlauben, was er jeweils darf. Ich muß nicht jeden Krempel runterladen und installeiren, nur weil jemadn sagt, daß das ganz toll wäre. Das sind aber alles meine Entscheidungen und die haben mich all die Jahre nicht im Stich gelassen. >Alle aktuellen WLAN Geräte (ja auch der ESP8266) haben ein Stück >Closed-Source Software, sonst wären die Geräte nicht zulassungsfähig. >Weist du wirklich, was diese Software tut und kann? nein, ich weiß es nicht. Es gab hier einen Thread, ob der ESP nach Hause telefoniert. Sorry, aber wenn man WireShark-Protokolle nicht zu deuten versteht, kann man auch Panik verbreiten. Ein abstürzender ESP kann auch begrenzt Amok laufen, dafür kann der Hersteller dann wenig, da passiert aber nichts zeilgerichtetes. >Soweit waren wir auch, als >das Internet in Deutschland für Privatkunden zugänglich wurde. Und da >ging es erst richtig los mit Viren, Spam, Hackern, Erpressung und >Identitätsdiebstahl. Ist doch aber normal. Die ersten Autos hatten auch keinen Bremsassisteten, kein ABS, keine Gurte, keine Air-Bags. Daür konnte der Fahren den Motot unteregs mal schnell auseinandernhemen, wenn nötig. Alle Sicherheitsfeature kamen erst, als die breite Masse ein Auto haben wollte. Da wurde dann auch nichts mehr über Kupplung und Getriebe in der Fahrschule gelehrt. In meinem direkten Bekanntenkreis habe ich zumindest insofern gewonnen, daß keine unbekannten Mailanhäge geöffnet werden, weder die von der Erbschaft noch die von der Bank. Es wird auch nicht mehr jeder Kram auf den Rechern losgelassen. Verhindern läßt sich manches ohnehin nicht, entweder mal will (einen Teil) der "schönen neuen Welt" oder man läßt es völlig... Mein TV darf auch gern LG die Betriebsstunden melden und noch ein paar Sachen. Ich will ja Amazon-Prime nutzen und habe mich damit dafür entschieden. Das mir Amazon und auch ebay personalierte Angebote einblenden, könnte ich nur verhindern, wenn ich dort eben nichts kaufe. Bei Google Groups findet man unter meinem Real-Namen die News-Postings von 1999 ohne Probleme. Gehörte sich damals so, heute undenkbar. Hat jetzt aber alles wenig mit IoT zu tun... Gruß aus berlin Michael
Stefan U. schrieb: > Aber wenn das ganze Haus steuerbar ist, mit allem Pi-Pa-Po der heute so > angeboten wird, dann vertausendfacht sich das Risko allein schon wegen > der Menge der Geräte. Entschuldigung, das ist doch Quatsch. Das Möglichkeit missbräuchlicher Nutzung steht und fällt hardwaremäßig allein mit der Sicherheit des Zugangs. > Wenn das Internetfähige Gerät beispielsweise online aktualisiert werden > kann (wie die meisten Smartphones, Internetrouter und sigar die ESP8266 > Module), dann muss ich mich nur noch als Man-In-The-Middle in die > Internetverbindung einklinken und das Update auslösen. Es ist dann > kinderleicht, beliebige Fremdsoftware auf die Geräte zu installieren. Das dürfte beim Xport ausgeschlossen sein oder zumindest höchstes Geheimdienst-KnowHow bzw. Mithilfe des Herstellers erfordern. Der XPort wird i.d.R. lokal geupdatet. Selbst wenn: Die Kenntnis zum Zugang und zur Interpretation der Daten (Command-Strings) der eigentlichen Steuerung bleibt weiter notwendig. Der Man in the Middle schließlich muß zur richtigen Zeit am richtigen Ort sein. All das setzt schon ein erhebliches (institutionelles oder persönliches) Interesse samt besonderer Fähigkeiten des Hackers voraus. So ohne Weiteres geht da gar nix. > Man kann ja nichtmal den Herstellern der Geräte trauen! Nun, mit dieser Einstellung solltest Du kein Internet-Gerät anfassen. Ich denke, eine gewisse Sicherheit gibt die transparente Presse- und SocialMedia Landschaft, daß (genutzte) Spionagefunktionen kein Regel- sondern nur ein Spezialfall bleiben. Wer würde schon so ein Gerät kaufen von dem bekannt würde, daß es regelmäßig Nutzer zu ihrem Schaden ausspioniert. > Was, wenn Dir jemand eine böse Email schickt, die deinen Router > unbemerkt anweist, sich zu aktualisieren? Dann kommt der Angriff > plötzlich indirekt doch von innen. Ok, dein PC ist sicher. Was ist mit > deinem Smartphone? Macht deine Taschenlampen App wirklich nur Licht? > Dient der Youtube Downloader wirklich nur dazu, Videos runterzuladen? > Oder kann er als Relaistation dienen, um dein Netz von innen > anzugreifen? Siehe oben. > Alle aktuellen WLAN Geräte (ja auch der ESP8266) haben ein Stück > Closed-Source Software, sonst wären die Geräte nicht zulassungsfähig. > Weist du wirklich, was diese Software tut und kann? Siehe oben. > Die Hersteller von IoT Geräten gehen Studien zufolge grenzenlos naiv mit > dem Thema Internet Sicherheit um. Sogar Hersteller von teuren Autos > erlauben Zugriff ohne jegliche Sicherheit (man braucht nur die > Seriennummer, die von außen mit bloßem Auge ablesbar ist). Werf mal nicht alles in einen Topf. Zur Erinnerung: Hier gehts um die Sicherheit beim Anschluß eines Bastel- Controllers (des TO) ans Netz. > Und da > ging es erst richtig los mit Viren, Spam, Hackern, Erpressung und > Identitätsdiebstahl. Werf mal nicht alles in einen Topf. Ja, auf dem PC gibts so einige Problemchen. Lass die mal jetzt außen vor. > Diese Themen haben wir inzwischen einigermaßen im Griff. Nö. Am PC jetzt gerade nicht! > Ich fürchte > aber, dass die IoT Geräte in richtig großem Stil neue Lücken einführen, > die uns sicherheitstechnisch zurück in die 90er Jahre verfrachten. Und > dann geht der ganze Scheiß wieder los. Deine Befürchtungen in allen Ehren, aber wir sind hardwaretechnisch und im Sicherheitsbewußtsein nun doch schon ein ganzes Stück weiter- auch wenn IoT selbst noch am Anfang steht. > Ich sehe hier noch keinen Grund zur Panik, aber Vorsicht halte ich für > angemessen. Damit werden wir uns nun doch noch einig ;-)
:
Bearbeitet durch User
Michael U. schrieb: > Encoding ja, aber bedingt: Wenn ein GET vorkommt (POST habe ich > (vorerst) hier garnicht drin) wird der Pfad extrahiert, dort wird kein > Encoding geprüft, es bliebe also "inde%78.html". Also dürfen deine URLs nur druckbare ASCII-Zeichen enthalten. > Außer bei einem 0-Byte sollte eigentlich garnichts passieren, das wäre > dann eben ein Stringende, alles danach kommt sowieso nicht an, genauso > bei \r. Und du bist dir sicher, dass ein einzelnes Nullbyte vorne in einem längeren String keinen Buffer-Overflow auslöst? :-) > PS: natürlich wärst Du z.B. mit dem Aufruf der IP oder IP/index.html auf > der regulären Webseite und würdest somt (im Moment) sehen, wie warm in > meinem Keller oder im Gefrierfach ist. Wenn da keine Steuerung dranhängt, ist das erstmal nur ein Informationsleck. Das kann schlimm genug sein, ist es aber meistens nicht. Richtig interessant wird es erst, wenn das Teil auch als Aktor dienen kann. Denn dann hast du schlagartig noch die ganzen möglichen Bugs auf höherer Ebene (diverses Encoding, ungültige oder nichtdarstellbare Zahlen, Denkfehler, unzureichende/schlechte Fehlerbehandlung, ...). Es gibt einen Compiler, der normalen Brainfuck-Code in einen C-Formatstring umsetzt. Wenn also der Code irgendwo ein schlecht ausgewürfeltes printf() macht, hast du direkt Remote Code Execution. > Wenn ich User/Passwort abfrage, ... ... landest du ganz schnell bei komplexen Lösungen, die wieder neue Bugs erzeugen. Oder bei Betriebssystemen, die dir den ganzen Kram abnehmen und hoffentlich sicher sind. > Wie sicher sind z.B. FHEM, OpenHub usw. wirklich? Wie sicher sind kommerzielle Systeme? Zyniker sagen "auf Windows 95-Niveau" und die Wissenschaft gibt ihnen Recht. Und die schwarzen Hüte sind in meiner Welt ein paar Jahre weiter. Moby A. schrieb: > Tatsächlich kommen so einige Anfragen zusätzlich rein. > Die stehen aber in keinem Verhältnis zu den von mir getätigten. Das habe ich mir in Bezug auf SSH auch mal gedacht. > Was soll mir das jetzt sagen? Dass du keine Ahnung hast, aber das ist bei dir ja normal. :-) > Wohlweislich nennst Du keine konkreten [primitiven Bugs] ;-) Du kannst halt weder lesen noch hast du Vorstellungsvermögen. Der Hinweis auf %%30%30 ist übrigens noch relativ frisch. >> Fehlerhafte Anfragen werden also einfach ignoriert. Das klappt schon >> seit 70 Jahren ausreichend gut, also bauen wir auch weiterhin darauf. > So und genau so schaut es aus! **kicher** > Nicht das Risiko wird wegerklärt sondern seine Bedeutung für die Praxis. > Du kannst mir keine aussichtsreiche Strategie erläutern, wie man in ein > wie von mir beschrieben zweistufig aufgebautes System eindringen könnte. Erstens trage ich weder einen weißen noch einen schwarzen Hut auf Arbeit, noch will ich mir dein System im Detail anschauen - auch nicht remote. Muss ich aber auch nicht. Und ein Angreifer muss an sich nur deinen HTTP-auf-UART-Wandler zu einem Tunnel umdefinieren und ist dann in deinem Netzwerk, von wo aus sich Angriffe auf den Rest der Infrastruktur viel besser fahren lassen. Aber wir schweifen ab. Die Bedeutung in der Praxis wird sich dann schlagartig ändern, wenn die Dienste für die breite Masse relevant werden. Bis dahin ist ignorance noch bliss.
S. R. schrieb: > Und ein Angreifer muss an sich nur deinen > HTTP-auf-UART-Wandler zu einem Tunnel umdefinieren Da darf ich dann wohl auch mal S. R. schrieb: > **kicher** Und echt saublöd, daß man nur über die UART an die Steuerung rankommt. Kann aber natürlich sein, daß Du einen ganz speziellen quantenmechanischen Tunneleffekt anwenden möchtest :-) Junge, Junge, was soll ich nur von Deiner Ahnung halten... Was soll der Hinweis auf irgendwelche Formatstrings? Irgendwelche sinnvolle Funktionen wirst Du damit nicht auslösen. Und auch keinen Absturz meines Controllers. Hängt damit zusammen, daß eben nur plausible Daten was bewegen können. Ein sinnvolles Prinzip für das Du ja nur ein dummalbernkindliches > **kicher** übrig hast...
:
Bearbeitet durch User
Hallo, S. R. schrieb: > Also dürfen deine URLs nur druckbare ASCII-Zeichen enthalten. nein, der Seitenname ja, die Argumente werden decodiert. > >> Außer bei einem 0-Byte sollte eigentlich garnichts passieren, das wäre >> dann eben ein Stringende, alles danach kommt sowieso nicht an, genauso >> bei \r. > > Und du bist dir sicher, dass ein einzelnes Nullbyte vorne in einem > längeren String keinen Buffer-Overflow auslöst? :-) Ja. Der ESP-Client liest die Daten als uint_8 in den Buffer. Das sind gut 2kB. Wenn der nicht rechtzeitig abgeholt wird, stürzt er zumindest nicht ab, er verwirft den Rest. Nach außen dürfte das ein TimeOut werden, müßte ich aber nachschauen. Abgeolt wird mit readuntil, ich bekomme also Daten bis \r oder einen TimeOut, wenn innerhalb 1s kein \r aufgetaucht ist. 0-Bytes an dieser Stelle sind egal, die kommen mit, bis hier sind es binär-daten, die alles enthalten dürfen. > Richtig interessant wird es erst, wenn das Teil auch als Aktor dienen > kann. Denn dann hast du schlagartig noch die ganzen möglichen Bugs auf > höherer Ebene (diverses Encoding, ungültige oder nichtdarstellbare > Zahlen, Denkfehler, unzureichende/schlechte Fehlerbehandlung, ...). Zu komplex. Parameteranfang im GET wird auf ? geprüft, auf die = und auf &, also ganz simpel. Die Teilstrings landen in einer Struktur, Name und Wert. an dieser Stelle verkürzt z.B. ein 0-Byte in Name oder Wert den String, aus Lich\0t würde Lich werden... Es würde aber keine Katastrophe auf dem "System" auslösen können. > Es gibt einen Compiler, der normalen Brainfuck-Code in einen > C-Formatstring umsetzt. Wenn also der Code irgendwo ein schlecht > ausgewürfeltes printf() macht, hast du direkt Remote Code Execution. Wäre auch alles zu prüfen, müßte ich mir mal ein Beispiel suchen. Die Frage wäre auch eher: was kann der umgesetzte String anrichten? >> Wenn ich User/Passwort abfrage, ... > > ... landest du ganz schnell bei komplexen Lösungen, die wieder neue Bugs > erzeugen. Oder bei Betriebssystemen, die dir den ganzen Kram abnehmen > und hoffentlich sicher sind. Nun mache ich es als Beispiel nicht komplex. Username und Passwort aus Formular schicken oder z.B. Javascript bemühen. Letztlich endet es wieder bei einem Stringvergleich auf Übereinstimmung oder nicht. Die dazwischen liegenden notwendigen! Routinen bleiben überschaubar, es sind eben keine Aufrufe von komplexen Systemfunktionen, die alles mögliche können sollen und alles mögliche falsch machen können. Du hattest bei Deiner 4MB-Anfrage die Spezifikationen erwähnt: mein "Webserver" muß genau die Spezifikationen einhalten, die nötig sind, die gewünschte Funktion in jedem Browser sicherzustellen. Ansonsten sind irgendwelche Spezifikationen bei unerwünschten Zugriffen sowas von egal. Von mir aus kann gern der Rechern des Hackers dabei abstürzen, wenn er mit meiner dann geschickten aber vermutlich unsinnigen Antwort ein Problem hat... :-) Gruß aus Berlin Michael
Moby schrieb: > Du scheinst nicht zu begreifen, daß diese Fehler so sie denn vorhanden > wären hier irrelevant sind: Maßgeblich ist das, was hinten seriell > rauskommt. Enthielte es Fehler oder wären die Daten unplausibel > passiert damit bei der Auswertung im Controller (selbstverständlich in > Asm ;-) just nur eines: Es wird ignoriert. > [...] > Durch einen dahergelaufenen Hacker ohne bekanntes Ziel schon mal gar > nicht. Da wird das "Exotische" echt zum Vorteil ;-) Was sollte dieser > Angreifer auch bewirken? Die erwähnte Plausibilitätsprüfung der Daten > durch den MC wird er nicht überlisten. Ja, das hab' ich schon oft gehört und gelesen... und am Ende war es dann genau diese Plausibilitätsprüfung, die versagt hat. Sowas richtig zu machen ist schon in modernen dynamischen Skriptsprachen nicht ganz einfach. Aber eigentlich rede ich gar nicht von Deinem uC, sondern von dem XPort selbst, auf dem Deine Webserversoftware läuft. Wenn sich ein Angreifer darauf einnisten kann, hast Du ein Problem.
Moby A. schrieb: > Michael U. schrieb: >> Das geht aber eben an dem vorbei, worüber Moby und ich sozusagen >> philosophieren. > > Ich glaube daß Sheeva P. sich einfach nicht vorstellen kann, wie man > eingehende HTTP Daten (nach einem Umsetzer auf seriell) auch ganz ohne > vorhandenen (hochausgereiften :-) Webserver manuell mit einem Controller > handeln kann... Programmcode über diese Daten auf dem Controller selbst > einzuschleusen ist natürlich vollkommen illusorisch. Oh, doch, das kann ich mir schon sehr gut vorstellen -- und habe selber auch so etwas Ähnliches im Betrieb, einen Arduino mit Ethernet-Shield. Aber ich käme nie auf die Idee, sowas ungeschützt direkt ans Internet zu hängen. Aus welchem Grund sollte man das auch tun wollen? Aber Dein Mikrocontroller dahinter ist für den Angreifer uninteressant, es sei denn, daß er damit Deine Garage, Haustüre öffnen oder vielleicht etwas kaputt machen kann. Dein XPort und der darauf laufende Webserver sind für einen Angreifer ein viel lohnenderes Ziel.
:
Bearbeitet durch User
Der Xport unterstützt doch SSH Verbindungen. Und SSH wurde mehrfach missbraucht, um Programme auszuführen. Meinst du nicht, dass das auch deinen Xport betreffen könnte? Alleine das kann schon sehr gefährlich sein. Denn wenn es jemandem gelingt, auf dein XPort eine falsche Firmware zu laden, dann kann er diese als Relaisstation nutzen, um alle anderen Geräte im Haus zu kompromitieren (sei es dein PC, die Smartphones, die Spielkonsole oder den Fernseher). Dann ist deine Hausautomation zwar nicht gestört, aber sie ist zum Zentralen Zugangspunkt für weitaus schlimmere Hacks geworden. Sowas kommt real vor, besonders häufig werden Internet Router, Smarphones und Smart TV's für socleh Zwecke missbraucht.
Hallo, schläfst Du eigentlich nie? ;-) Sheeva P. schrieb: > Oh, doch, das kann ich mir schon sehr gut vorstellen -- und habe selber > auch so etwas Ähnliches im Betrieb, einen Arduino mit Ethernet-Shield. > Aber ich käme nie auf die Idee, sowas ungeschützt direkt ans Internet zu > hängen. Aus welchem Grund sollte man das auch tun wollen? Der Arduino wäre die sicherste Maschine in Deinem ganzen Netzwerk. Alle üblichen Angriffsszenarien würden ins Leere laufen. Kein kömplexer Interpreter, kein Heap-Sprying, NOP-Rutschen scheitern schon am abweichenden NOP-Befehl. Kein bekannten Sprungziele für ein Trampolin, alles die Dinge und viele weitere, auf die Angriffe aufbauen. Eine Chance, vom AVR in Dein Netz eunzubrechen gibt es auch nicht, weil er die Funktionen garnicht bietet. Letztlich geht es ja darum, eine bekannte Lücke eines auf der Maschine zu dieser Zeit laufenden Programms aufzurufen. Flash ist da ja Beispiel genug für die Clientseite gewesen. Einen Aufruf des Flash-Plugin in die Wegseite und präparierte Parameter für die Lücke übergeben, um letztlich im eigenen ausführbaren Code zu landen. Dieser Code kann ein Script für einen auf dem System vorhanden Interpreter sein, der auf bekannte Art dann aufgerufen werden kann. Bei einem Angriff auf einen WebServer ist man nicht besser dran. Es muß eine bekannte Lücke geben, man muß wissen, daß der Aufruf von (bleiben wir bei Deinem printF()) ein Problem in der Typprüfung hat, daß ein Overflow damit möglich ist und daß man dann da auch rankommt. Das klappt aber eben nur in genau diesem Umfeld. Wenn es eine andere Implemetierung ist oder auf einer unüblichen CPU läuft, muß ich das wissen. x86-Code läuft nicht auf einem ARM oder ESP. > Aber Dein Mikrocontroller dahinter ist für den Angreifer uninteressant, > es sei denn, daß er damit Deine Garage, Haustüre öffnen oder vielleicht > etwas kaputt machen kann. Dein XPort und der darauf laufende Webserver > sind für einen Angreifer ein viel lohnenderes Ziel. Für den XPort gilt nur begrenzt, er hat einen x186 drin, der dürfte in Grenzen sogar noch binär-compatibel zum x86 sein. Allerdings könnte a) der Umgang mit den mit dem Real-Mode ein Problem sein und außerdem wird (im Moment) kaum noch jemand Angriffe mit 16Bit-Code fahren, der läuft auf aktuellen Maschinen nicht, 86186 kann aber nichts anderes. Es sind doch 2 Seiten in unserer Diskussion: was kann ich HEUTE in meinem Umfeld mit IoT-Geschichten nutzen und mit welchem Gefährdungspotenzial und was bringt die Zukunft wenn IoT zur echten Massenware wird. PS: es gab bis voriges Jahr einen PC mit Win2000 letzter Patchlevel, ohne zusätzliche Firewall, ohne Virenscanner an einem DSL-Anschluß im Internet. Daruaf lief ein Kassenprogramm von 1998 (DOS-Software, dBase/FoxPor-Datenbanken). Internet wurde genutzt, um EMails mit einem alten Thunderbird abzuholen und ein alter Firefox besuchte manchmal wenige bekannte Seiten von Lieferanten (machte teilweise schon ziemliche Probleme). Dieser Rechner wurde damals vom Blaster-Virus erwischt, erzeugte des Zwnagsrunterfahren des Systems, weil der Blaster mit W2000 schon nicht mehr zurecht kam. Hat keinen Schaden angerichtet, außer daß ich hinfahren durfte und erstmal rausfinden mußte, was los war... Wahrscheinlich würde ich heute am wenigsten riskieren, wenn ich einen Datenabgleich per FTP machen wollte, wenn ich einen alten W98SE-Rechner mit DSL-Modem direkt ins Internet hänge, den Kram greift praktisch heute keiner mehr an... Gruß aus Berlin Michael
Moby A. schrieb: > Was soll der Hinweis auf irgendwelche Formatstrings? Fancy source of bugs. Natürlich nicht für dich, wenn du nimmst ja nur Assembler auf AVRs und überlässt die höhere Programmierung anderen (die dann selbstverständlich andere Programmiersprachen auf anderen Architekturen benutzen). Dann sind es zumindest nicht mehr deine Bugs und du bist fein raus. > Irgendwelche sinnvolle Funktionen wirst Du damit nicht auslösen. > Und auch keinen Absturz meines Controllers. Hängt damit zusammen, daß > eben nur plausible Daten was bewegen können. Ich wüsste von dir gerne mal, wie du eine Plausibilitätsprüfung garantiert wasserdicht bekommst, mit einer zusätzlichen Randbedingung: Du musst dich an eine bereits vorhandene Spezifikation halten (darf auch deine eigene sein), und diese ist entweder nicht zu 100% vollständig oder nicht zu 100% widerspruchsfrei. Außerdem ist Plausibilität nur notwendig, nicht hinreichend. Beispiele gabs oben. Michael U. schrieb: >> Also dürfen deine URLs nur druckbare ASCII-Zeichen enthalten. > nein, der Seitenname ja, die Argumente werden decodiert. Das verschiebt das mögliche Problem (so es überhaupt eins ist) nur. Aber wir schweifen ab, denn ursprünglich wollte ich nur ein paar Kleinigkeiten zeigen, die einem handgeknüppeltem Webserver schon gefährlich werden könnten. >> Es gibt einen Compiler, der normalen Brainfuck-Code in einen >> C-Formatstring umsetzt. Wenn also der Code irgendwo ein schlecht >> ausgewürfeltes printf() macht, hast du direkt Remote Code Execution. > Wäre auch alles zu prüfen, müßte ich mir mal ein Beispiel suchen. > Die Frage wäre auch eher: was kann der umgesetzte String anrichten? Alles? Was gibt es denn jenseits von "fremder, eingeschleuster Code wird ausgeführt" noch? > Du hattest bei Deiner 4MB-Anfrage die Spezifikationen erwähnt: mein > "Webserver" muß genau die Spezifikationen einhalten, die nötig sind, die > gewünschte Funktion in jedem Browser sicherzustellen. Wenn du die HTTP-Spezifikation nicht (vollständig) implementierst, dann ist deine Implementation formal kein HTTP. Das kann dir in deinem Bastelkeller herzlich egal sein, einer semiprofessionellen Firma eher nicht. Dann sind wir ganz schnell wieder bei der klassischen Problemkette: - Spezifikation ist widersprüchlich und/oder unvollständig; - Implementationen variieren in Randbereichen; - Implementationen sind unvollständig oder buggy; - Schuld ist der Hersteller des zuletzt hinzugefügten Gerätes; - der also Workarounds für bekannt-kaputte Implementationen einbauen muss; - die erst Recht die Spezifikation verletzten. IoT ist deswegen so gefährlich, weil es eine direkte, gewollte Verbindung von Software zur Realität schafft - und die Software nicht sicher genug ist. Michael U. schrieb: > Bei einem Angriff auf einen WebServer ist man nicht besser dran. Es muß > eine bekannte Lücke geben, man muß wissen, daß der Aufruf von (bleiben > wir bei Deinem printF()) ein Problem in der Typprüfung hat, daß ein > Overflow damit möglich ist und daß man dann da auch rankommt. Das printf()-Problem basiert darauf, dass %n in Speicher schreiben kann und man damit direkt eine (ziemlich beschissene, aber turing-vollständige) Umgebung schaffen kann. > Wahrscheinlich würde ich heute am wenigsten riskieren, wenn ich einen > Datenabgleich per FTP machen wollte, wenn ich einen alten W98SE-Rechner > mit DSL-Modem direkt ins Internet hänge, den Kram greift praktisch heute > keiner mehr an... ...zumindest nicht mit Massenware. Womit wir wieder bei dem Thema wären, dass seltsame Konfigurationen weniger anfällig gegenüber Breitbandangriffen sind und deutlich anfälliger gegenüber gezielten Angriffen sind.
Hallo, wir drehen uns ein wenig im Kreis. Es gibt keine absolute Sicherheit, im Internet nicht und im täglichen Leben auch nicht. Was bleibt, ist immer eine Risikoabschätzung und Minimierung, eben "nach menschlichem Ermessen"... S. R. schrieb: > IoT ist deswegen so gefährlich, weil es eine direkte, gewollte > Verbindung von Software zur Realität schafft - und die Software nicht > sicher genug ist. Ah ja. Die Verbindung zwischen PC und leergeräumten Konto ist keine Verbindung zur Realität? Die zwischen Trojaner-verschlüsselten Verwaltungs-PCs in einer Stadt auch nicht? Die extreme Telefonrechnung wegen Umprogrammierung des Routers mit Telefonanlagenfunktion nicht? Der BTX-Hack mit Umfüllen des Kontonhalts war auch keine Verbindung zur Realität? Wenn ich irgendwelchen IoT-Kram nutze, egal ob industriell oder selbst gebaut, muß ich das für mich machen oder ich kann es lassen, weil der Hersteller ja sagt "das ist sicher". Genau wie in obigen Fällen. Ich kann jetzt Online-Banking lassen, meinen PC nicht mehr ins Internet lassen, statt des Komfort-Router wieder 3 getrennt Kisten hinstellen (gut, Dank VoIP auch nicht mehr...), will ich aber nicht, ich mag die Vorteile und bin mir auch der möglichen (bekannten und halbwegs wahrscheinlichen) Risiken bewußt. Wenn ich also IoT in irgendeiner (selbst gebauten) Machart ins Internet stelle liegt es letztlich in meiner Verantwortung. Mein Heizungsregler müßte dann z.B. den Maximalwert unabhängig begrenzen, ich werde hier nie 35 Grad haben wollen, also darf er die garnicht zulassen. Natürlich wird das zum Problem werden, das ist aber kein Problem von IoT als Solches, das ist ein Problem der Verantwortlichen und jedes Einzelnen. Beides wird den Weg gehen, den Du zum Them Spezifikationen angesprochen hast, mindestens bis eben die erste Meldung des komplett gehackten Hauses durch die Presse geht und die ersten Firmen plötzlich entdecken, daß Sicherheitsfeatures ein Verkaufsargument sein kann. Erfahrungsgemäß aber erst, nachem die ersten Kinder im Brunnen liegen, vorher würden die Leuten den Kram nicht kaufen, weil ja teuerer als das andere und das andere kann ja sogar mehr... PS: vermutlich könnte man Mobys XPort hacken und umprogrammieren, meinen ESP zumindest theoretisch sicher auch. Moby und auch mir würde es sehr wahrscheinlich nicht lange verborgen bleinen, wenn mein Licht plötzlich 1s länger zum Angehen braucht, weil das Ding anderweitig beschäftigt ist. Gruß aus Berlin Michael
:
Bearbeitet durch User
> Natürlich wird das zum Problem werden, das ist aber kein Problem > von IoT als Solches Richtig. Wie ich schon sagte, die Anzhal der potentiell angreifbaren Geräte wird durch den EInsatz von IoT jedoch rasant ansteigen und alleine schon deswegen das Risiko erheblich erhöhen. Bei der Einführung von Smartphones war es nicht anders. Da wurden bis dahin super sichere SMS-TAN Verfahren plötzlich unsicher. Das hat sogar die Banken überrascht. Trotzdem nutzt man das Verfahren noch, nun aber mit bewusstem Risiko. Die totale Vernetzung wird kommen, genau wie die totale Überwachung - ich denke das kann sich jeder selbst ausmalen. Nur sollte man bitte nicht völlig naiv davon ausgehen, dass Bösewichte diese Techniken nicht nutzen werden und bitte auch nicht davon ausgehen, dass die Hersteller der Komponenten sich um angemessene Sicherheit kümmern werden. Erfahrungsgemäß tun sie das nämlich erst dann, wenn ihr Ruf völlig versaut ist und die Firma aus wirtschaftlichen Gründen zu Verbesserungsmaßnahmen gezwungen ist. Wer dann die "alten" Produkte von der Zeit davor im Einsatz hat, der hat dann halt keine angemessene Sicherheit. Spätestens, wenn ein Hersteller krasse Sicherheitslücken geschlossen hat, werden die alten Teile an den Pranger gestellt. Dann kann jeder, der Lesen kann, im Internet recherchieren, wie man die alten Sachen angreift. Dass heisst, als Kunde bis du dann erpresst. Entweder kauft du die neuen Teile, oder du geht doppeltes Risiko ein. Und mal Hand auf's Herz: Wenn ich mein ganzes Haus vernetzt habe und 5 Jahre später einzelne Teile auf neuere sicherere Komponenten umrüsten will, was meinst du wohl wie kompatibel die neuen Komponenten zu den alten sein werden?
Um ein Haus zu schuetzen benoetige ich zB einen Router, da muss ich an der Hausinstallation nichts aendern. Weshalb sollte man einzelne Geraete exponieren.
Hallo, Oh D. schrieb: > Um ein Haus zu schuetzen benoetige ich zB einen Router, da muss ich an > der Hausinstallation nichts aendern. Weshalb sollte man einzelne Geraete > exponieren. jein... In erster Linie Zugriffe von Außen verhindern, soweit nicht vom User explizit erlaubt wurden (PortForwarding z.B.). Das machen inzwischen auf billige Router recht gut, solange die Friemware nicht mal wieder einen kritischen Bug hat. Unterlaufen wird das teilweise schon, wenn UPnP aktiv ist. Dann kann eine Software da ganz legal dran drehen. Wir sind bei I0T aber gerade an dem Punkt, daß wir den Zugriff von Außen ja erlauben wollen... Solange da eine zentrale Instanz ist, über die alle Zugriffe laufen, ist es zumindest auch noch beherrschbar, weil man deren Software dann eben sicher und aktuell halten muß usw. Jetzt sind wir aber an dem Punkt, daß wir für nahezu beliebige Geräte den Zugriff von Außen wollen. Man will an die Heizungssteuerung ran, an die Rollos, an den Medieserver. Noch kann man das prinzipiell über eine Zentrale laufen lassen, die sich auch um die Zugriffssicherjeit kümmert. Dazu muß die aber mit allen Komponenten umgehen können, wissen, was die dürfen und was nicht. Entweder muß also alles von einem Hersteller sein, jede Komponente, und der muß die sichere Software bauen oder es müßte einen definierten Standard geben , der einerseits für Sicherheit sorgen kann und auf die unwahrscheinlichsten Geräteklassen vorbereitet ist und an den sich alle Hersteller halten. Und spätestens da platzt der Traum... Ich kann privat (ich traue es mir eben zu...) meine Risikoabschätzung mit meinen Bastelein machen und es entsprechend realisieren. Schon bei meinem TV mit Smart-TV endet das, beim oft als Beispiel genannten "intelligenten" Kühlschrank genauso. Beide wollen einfach ins Netz und schon ist es die Entscheidung: nutze ich die Funktion? Kann ich das Risiko mit den gegebenen Informationen und meinen Kenntnissen überhaupt abschätzen? Diese (und und viele kommende) Sachen wollen einfach "ins Internet". Der Hersteller sagt mir, wozu. Der sagt höchsten einen Werbespruch... Natürlich sind die Risiken real. Jetzt TV-Sehgewohnheiten mit erfassen, später Essgewohnheiten, Energieverbrauchsstatistiken usw. usw. Wird den "Otto-Normalverbraucher" alles nicht interessieren. Wie beim Handy: Standorterfassung ist doch toll, weiß ich immer, wo mein Kumpel ist. Und ist doch auch für mich sicherer, wenn mir was passiert, weiß jeder, wo ich rumliege. Wir sind hier im mikrocontroller.net, also einem Forum, wo sich Leute tummeln, die sich mit der Materie µC in allen Spielarten befassen und meist auch selber bauen, ob als Hobby oder als Beruf ist völlig egal. Da liegt auch meine Sichtweise: das reale Risiko, daß jemand einen AVR-NetIO, einen ESP-Webserver oder den xPort-Webserver angreift, erfolgreich hackt und die "Haussteuerung" übernimmt, liegt z.Z. bei nahezu 0, auch dann wenn die Sachen per Forwarding direkt im I-Net hängen. Das mag sich ändern, das ist aber mein Problem, da dicht genug dranzubleiben, aktuell informiert zu blieben und eben notfalls Vorkehrungen zu treffen. Warum ich das so sehe, habe ich versucht zu begründen, da zählen durchaus auch die Beispiele mit den alten Windows-Rechnern im I-Net dazu. Natürlich kann sowas durch irgendeinen dummen Zufall schiefgehen, es müssen dann aber genug Sachen zusammentreffen, die relativ unwahrscheinlich sind. Ich kann auch vom Auto überfahren werden, von einem Dachziegel erschlagen oder in Berlin vom Hochwasser erwischt werden... Man kann durch eigenes Vorgehen das Risiko nur minimieren, man kann es nicht auf 0 reduzieren. Gruß aus Berlin Michael
Sheeva P. schrieb: > Wenn sich ein Angreifer > darauf einnisten kann, hast Du ein Problem. Noch nie von dieser beim XPort realistischen Möglichkeit gehört. Mit entsprechendem (motiviertem!) Geheimdienst-KnowHow vielleicht. Und selbst dann gilt > Dein Mikrocontroller dahinter ist für den Angreifer uninteressant, dann ist doch alles in Butter ;-) > es sei denn, daß er damit Deine Garage, Haustüre öffnen oder vielleicht > etwas kaputt machen kann. Features die man erst mal kennen müsste ;-) > Dein XPort und der darauf laufende Webserver > sind für einen Angreifer ein viel lohnenderes Ziel. Der lässt sich außer Betrieb nehmen.
Stefan U. schrieb: > Der Xport unterstützt doch SSH Verbindungen. Und SSH wurde mehrfach > missbraucht, um Programme auszuführen. > > Meinst du nicht, dass das auch deinen Xport betreffen könnte? Nein. Jedenfalls nicht um irgendeinen Zugriff auf den angebundenen Controller zu erhalten. Stefan U. schrieb: > Denn wenn es jemandem > gelingt, auf dein XPort eine falsche Firmware zu laden, Wenn... Das dürfte aber praktisch ausgeschlossen sein ;-) Stefan U. schrieb: > Sowas kommt real vor, besonders häufig werden Internet Router, > Smarphones und Smart TV's für socleh Zwecke missbraucht Die Behauptung lass ich mal dahingestellt. Zum Einbruch ins interne Netzwerk missbraucht werden dürften wohl in erster Linie ans Netz angebundene PCs- alles andere erfordert schon sehr gezieltes Wissen und Motivation- und ist ein Risiko für alle gleich ;-)
S. R. schrieb: > Moby A. schrieb: >> Was soll der Hinweis auf irgendwelche Formatstrings? > > Fancy source of bugs. Natürlich nicht für dich, wenn du nimmst ja nur > Assembler auf AVRs und überlässt die höhere Programmierung anderen (die > dann selbstverständlich andere Programmiersprachen auf anderen > Architekturen benutzen). Dann sind es zumindest nicht mehr deine Bugs > und du bist fein raus. Genau so schauts aus. Ein Überlast/Format$ unempfindlicher serieller Controller-Eingang lässt sich auch mit jeder anderen Sprache realisieren. > Ich wüsste von dir gerne mal, wie du eine Plausibilitätsprüfung > garantiert wasserdicht bekommst, mit einer zusätzlichen Randbedingung: > Du musst dich an eine bereits vorhandene Spezifikation halten (darf auch > deine eigene sein), und diese ist entweder nicht zu 100% vollständig > oder nicht zu 100% widerspruchsfrei. Du denkst zu kompliziert. Dummerweise wird an dieser Stelle zu ausgiebige Plauderei über (meine) Plausibilitätsprüfung schon selbst zum Sicherheitsrisiko ;-) Ganz allgemein kann man aber sagen, daß die Commands zur Auslösung von Funktionen - nur mir selbst bekannt sein dürfen - einmalig zu verwenden abhängig von nur mir bekannten aktuellen Randbedingungen sein müssen Um aus irgendwelchen Protokollen eines theoretischen Angreifers irgendeine konkrete Funktion abzuleiten müsste der schon über viele Jahre konstant 'in der Leitung' hängen. Das ist alles dermaßen irreal daß ich es jetzt damit bewenden lasse. Mich interessieren nicht die allerletzten theoretischen Möglichkeiten sondern allein die Praxis. Schließlich: Ehe ein Angreifer bei diesen Schwierigkeiten meine Haustür geöffnet hat ist sie längst aufgehebelt. Also: Bitte die Kirche im Dorf lassen. > Wenn du die HTTP-Spezifikation nicht (vollständig) implementierst, dann > ist deine Implementation formal kein HTTP. Das kann dir in deinem > Bastelkeller herzlich egal sein, einer semiprofessionellen Firma eher > nicht. Absolut. Individualität verschafft eben mehr Sicherheit ;-) > IoT ist deswegen so gefährlich, weil es eine direkte, gewollte > Verbindung von Software zur Realität schafft - und die Software nicht > sicher genug ist. Verwende doch den Begriff 'gefährlich' nicht so leichtsinnig. 'Gefährlich' ist erstmal nur der Zugriff auf (öffentliche) kritische Infrastruktur und nicht auf Bastelprojekte.
:
Bearbeitet durch User
Michael U. schrieb: > Moby und auch mir würde es sehr wahrscheinlich nicht lange verborgen > bleinen, wenn mein Licht plötzlich 1s länger zum Angehen braucht, weil > das Ding anderweitig beschäftigt ist. Gewiss. Nach diesem kostenlosen Hinweis auf böswillige Aktivitäten im Hintergrund würde einfach entsprechend reagiert und der liebe Angreifer darf von vorn beginnen ;-) Aber im Ernst: So interessant ist das alles wirklich nicht. Interessant für Angriffe (auf Privatleute) sind heute Dinge, die man (möglichst schnell!) zu Geld machen kann.
:
Bearbeitet durch User
Michael U. schrieb: >> IoT ist deswegen so gefährlich, weil es eine direkte, gewollte >> Verbindung von Software zur Realität schafft - und die Software nicht >> sicher genug ist. > Die Verbindung zwischen PC und leergeräumten Konto ist keine > Verbindung zur Realität? Doch, aber dafür haftet im Zweifelsfall die Bank. Denen ist das Risiko nämlich nachweislich bekannt (und der Ruf zu wichtig). Die selbstgebastelte Garagentür hat bei der Hausratsversicherung eher nicht den gleichen Stellenwert. > Dummerweise wird an dieser Stelle zu ausgiebige Plauderei über (meine) > Plausibilitätsprüfung schon selbst zum Sicherheitsrisiko ;-) Security through obscurity also. Dann wäre das immerhin geklärt. >> IoT ist deswegen so gefährlich, weil es eine direkte, gewollte >> Verbindung von Software zur Realität schafft - und die Software nicht >> sicher genug ist. > > Verwende doch den Begriff 'gefährlich' nicht so leichtsinnig. > 'Gefährlich' ist erstmal nur der Zugriff auf (öffentliche) kritische > Infrastruktur und nicht auf Bastelprojekte. Gewisse private Infrastruktur (z.B. Wasser, Strom, Heizung, Internet, Auto, Tür) empfinde ich als mindestens genauso kritisch. Es hängt davon ab, was man damit tut. Und "ich möchte eine Rollosteuerung bauen" ist wesentlich weniger kritisch als "ich möchte IoT machen", weil letzteres irgendwo das volle Programm impliziert.
Hallo, S. R. schrieb: > Security through obscurity also. Dann wäre das immerhin geklärt. in diesem Zusammenhang zur Zeit uneingeschränkt ja. Solange, bis die Verbreitung von IoT groß genun ist, da0 die bösen Leute das Potenzial entdeckt haben. Noch nimmmt ein Einbrecher lieber ein Stemmeisen als ein Notbook mit, schon weil es eine Zeitfrage ist, herauszufinden, was da für Elektronik ist und wie man die "aufbekommt". War doch bei Autos nicht anders, Zetralverriegelung mit billiger 433MHz-Fernbedienung war das non-plus-ultra an Komfort. Bis es auffiel, daß sich nur jemamd mit einer Handfunke in relative Nähe stellen mußt und beim Zusperren des Autos die Sendetaste drücken. Von 10 Leuten haben 2 nicht geschaut, ob es am Auto blinkte und damit verriegelt und ein Wegfahrsperre in Betrieb war. Und ein Auto war dann eben dabei, wo der Dieb wußte, wie er das von innen in 20s kaltstellen und mit dem Wagen wegfahren konnte. Inzwischen werden eben geziehlt die richtigen Fahrzeuge gesucht, wo man die nötige passende Software auf dem Notebook hat, die die richtige Lücke ausnutzt... Gruß aus Berlin Michael
Michael U. schrieb: > Hallo, > > S. R. schrieb: > Security through obscurity also. Dann wäre das immerhin geklärt. > > in diesem Zusammenhang zur Zeit uneingeschränkt ja Nein. Immer! > Solange, bis die Verbreitung von IoT groß genun ist, daß die bösen Leute > das Potenzial entdeckt haben Das ist eine Frage und die empfindliche Seite von vielgenutzten Standards in Hard- und Software. Technisch lässt sich aber prinzipiell auch dort sicherstellen, daß der Aufwand zum Knacken und Hacken stets über dem zu erzielenden Nutzen bleibt. Was entsprechende Aufmerksamkeit verlangt, was ggf. entsprechend kostet. Um das Wachstum der IoT Landschaft ist mir trotzdem nicht bange- es bleibt zwar ein ewiges Katz-und Mausspiel zwischen Hackern und Produktentwicklern, die Mehrheit der Anwender wird aber vom steten Reifungsprozeß der Technik profitieren, so wie heute auch schon. Das Katz-und Mausspiel ist ja geradezu notwendige Voraussetzung und Treiber der Entwicklung angemessen sicherer Produkte. Die gleiche Funktion haben in der Luftfahrttechnikgeschichte diverse Unglücke aller Art. Ergebnis: Heute fliegt (fast) jeder sicher ;-)
:
Bearbeitet durch User
Hallo, Moby A. schrieb: >> S. R. schrieb: >> Security through obscurity also. Dann wäre das immerhin geklärt. >> >> in diesem Zusammenhang zur Zeit uneingeschränkt ja > > Nein. Immer! privat ja, aber nur, solange es das Umfeld zuläßt. Irgendwann kommt der Punkt, wo man nicht mehr alles selber machen will oder kann, dann bleibt nur neu entscheiden und/oder umdenken. Spatestens, wenn eine IoT-Steckdose oder ein IoT-Lichtschalter billiger ist als ein normaler und der normale kaum noch zu bekommen und in der neuen Wohnung garkein Kabel mehr in der Schalterdose ist... Sag jetzt nicht, soweit kommt es NIE. ;-) Das dauert aber noch ein paar Tage. Gruß aus Berlin Michael
:
Bearbeitet durch User
Michael U. schrieb im Beitrag #4533005 > Spatestens, wenn eine IoT-Steckdose oder ein IoT-Lichtschalter billiger > ist als ein normaler und der normale kaum noch zu bekommen und in der > neuen Wohnung garkein Kabel mehr in der Schalterdose ist... > Sag jetzt nicht, soweit kommt es NIE. ;-) > > Das dauert aber noch ein paar Tage. Und bis es soweit ist ist diese Art von Technik meiner Meinung nach ausreichend sicher- auch wenn Standards wiegesagt mehr Risiko mit sich bringen. Sie würde auch nicht gekauft/ eingesetzt wenns nicht so wäre.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.