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)
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.
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.
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.
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..
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.
> 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.
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
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
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
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.
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!
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 ;-)
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...
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.
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
> 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.
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.
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 ;-)
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
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.
