MINISERVER AUSFALL seit heute Nacht (2.11.2016)

[nonem]

Gibt es denn jemand mit dem Problem der nicht seinen Server extern freigegeben hat? Ich habe hinter einem VPN keine Probleme. Klingt für mich aufgrund der zeitlichen Häufung wirklich nach DoS-Attacken.

[Benjamin Jobst]

Wir haben einige MS, die Loxone-gerecht extern freigegeben sind - auch über den Port 80. Da gibt es bisher keine Probleme *aufHolzklopf*
Der MS hat ja mittlerweile auch eine integrierte Firewall, die auch SYNflood blocken können soll und auch ihre Aktivitäten im Logfile aufzeichnet...

[Gast]

Hallo,
auch mich hat es erwischt, mein MS bootet alle ca. 20 Sekunden neu. Antwort vom Support:
"Die Reboots sind kontrollierte Neustarts da es sich hier um eine Sicherheitsfunktion des Miniserver handelt. Bei diesen "Angriffen" werden sehr viele Anfragen in der Sekunde gemacht. Deshalb wird hier der Miniserver stark ausgelastet. Aus diesen Grund startet hier aus Sicherheitsgründen der Miniserver seine Dienste neu."
Ich werde meine Einstellungen der FritzBox und der Firewall überprüfen und schauen, wie er Reagiert, wenn er gar nicht von Außen erreichbar ist.

[scallywag]

Hm, ich habe ca. 60% der Miniserver in einem VPN, bei dem Rest nutze ich den Loxone eigenen Cloud-DNS.
Betroffen waren bisher nur die Miniserver, die den Cloud-DNS Dienst von Loxone nutzen.

Mein Problem ist, dass ich diverse Log-Files in regelmäßigen abständen per HTTP-Request von den Servern abhole und somit den Port 80 nutzen muss, da bei einer Portänderung der Loxone Cloud-DNS damit nicht klarkommt...
Alles irgendwie sehr unschön.

[Gerrit]

Mein Problem ist, dass ich diverse Log-Files in regelmäßigen abständen per HTTP-Request von den Servern abhole und somit den Port 80 nutzen muss, da bei einer Portänderung der Loxone Cloud-DNS damit nicht klarkommt...
Alles irgendwie sehr unschön.

Einfach einen anderen DynDNS Service wie no-ip o.ä. nutzen. Und danach nochmal den Port ändern, da Loxone Cloud DNS den erst noch behält. Würde keinen DYN DNS Service nutzen, bei dem die Adresse und Port einfach erratbar ist.

BTW: Würd ich das Loxone auch direkt nochmal schreiben, dass Sie durch ihren Cloud DNS Service indirekt mitverantwortlich für solche Angriffe sind und doch am besten den Service nochmal in der technischen Umsetzung überarbeiten sollten (auch wenn dadurch ein potentielle Umstellung beim User einmalig notwendig wird).

[HIS-Loxone]

also meine Miniserver hatten bis jetzt kein Problem.
sind zwar alle bei Loxone registriert aber nicht von außen erreichbar.

[HIS-Loxone]

wenn es sich um gezielte DDOS Angriffe handelt sollte doch Loxone da mal eine Info an die Partner raus schicken.
stellt sich die Frage warum Loxone ihre Cloud Service nicht absichert.

Die müssten ja auch sehr viele Anfragen dann auf Ihr DNS Service haben.

[Gast]

Hallo zusammen,

Alles wie immer ein bedauerlicher Einzelfall
würde auch behaupten das man einen DDos von normalem Nutzerverhalten unterscheiden kann - wenn man möchte...

Gut, wieder etwas gelernt - nicht die Loxone DNS Service nutzen.

Danke an alle die sich beteiligt haben

Grüsse
Christian

[Leigh]

Interessant ist es, wenn es vornehmlich MS betrifft die den DNS Service von Loxone benutzen.
Dann wurde deren Dienst evtl kompromitiert?
Und es ist IMMER ein Einzelfall.
Man sollte einfach mal eine Liste betroffener Systeme anlegen und auf diese verweisen.

[Christian Fenzl]

Es ist doch naheliegend:
Von Heise gab es einen Artikel, dass der Loxone Cloud DNS das Auffinden von Miniservern ermöglicht, und dass viele Kunden Standardpasswörter verwenden.
Ein Monat später hat das halt jemand mal ausprobiert, was Heise beschrieben, und Loxone nicht verbessert hat.

Ich glaube nicht, dass der Dienst kompromittiert wurde. Das Design hat sich seit der Heise-Bekanntmachung nicht geändert, und so ist es ein Leichtes, sich MS's zu suchen.

Gast Die Lehre daraus ist nicht, den Cloud DNS nicht mehr zu verwenden. Die Lehre muss sein, ein VPN zu verwenden, und den MS nicht in die freie Wildbahn zu lassen!

[Gast]

Christian Fenzl vermutlich hast Du, und all die Anderen zu diesem Thema vollkommen Recht!
Die Lösungen zu VPN on demand (IOs) und VPN- allgemein sind aber eher weniger smart.

Natürlich muss man dann halt auch mal den Totalausfall in kauf nehmen.
Ich würde mir von LOXONE da gerne etwas wünschen...

Der Aufwand der mittlerweile (auch durch Erkenntnisgewinn) betrieben werden (sollte) ist so immens das
ich mich frage wie andere Leute damit Geld verdienen können...

Grüße
Christian

[HIS-Loxone]

Wir Loxone Partner! Setzen in letzter Konsequenz die Projekte beim Kunden um, daraus ergibt sie auch eine Verantwortung gegen über unseren Kunden.
Bei der LOXONE Lösung (und nicht nur dort) treffen IT-Lösungen und Elektrotechnik auf einander.

Ist es nicht fakt das die meisten Elektrotechnik Firmen keine IT Erfahrung haben und damit die Gefahren von Angefriffen unterschätzen?

Ja auch Wir sind dafür das LOXONE Ihre Systeme besser absichert. Der MS ist und bleibt ein Computer und ist damit angreifbar.

Doch auch der Kunde hat seine Verantwortung zu tragen (natürlich müssen wir Fachbetriebe denn Kunden bestmöglich beraten auch in IT Sicherheits Relevanten Bereichen).
Aus diesem Grund beraten wir unsere Kunden dahingehend das die MS nicht vom Internet aus erreichbar sind (sollte ein Kunde dies dennoch möchten dann auf sein Risiko hin).

[scallywag]

HIS-Loxone Naja, das halte ich aber nicht unbedingt für den richtigen Ansatz, den MS aus dem Internet nicht erreichbar zu machen...
Wie verkaufst Du Deinen Kunden denn bitte, dass Du für jeden Pups, den sie in der Konfig geändert haben möchten, Du eine An-/Abfahrtpauschale berechnest? Oder sind die Kunden alle in der Nachbarschaft?
Erst die Erreichbarkeit aus dem Internet macht den Einsatz eines MS oft erst interessant.

[HIS-Loxone]

Wir machen das über Teamviewer oder eine Side to Side VPN, In unseren LOXONE Projekten ist auch immer eine richtige Firewall (Checkpoint oder Cisco ASA) dabei.

[Benjamin Jobst]

HIS-Loxone du hast durchaus Recht, in gewissem Maßstab ist es die Verantwortung des Installierenden, für die Sicherheit des Smart Home zu sorgen bzw. zumindest den Kunden über die Sicherheitsthematik aufzuklären.
Allerdings ist das ein derart weitläufiges Thema, dass der einfache Elektrobetrieb da wohl schnell überfordert sein wird. Und selbst wenn man sich IT-technisch etwas fortgeschrittener bewegt, ist das eine äußerst delikate Gratwanderung zwischen Sicherheit und Usability.

Das Landeskriminalamt NRW hat einen Leitfaden mit Sicherheitsempfehlungen für Smart Homes herausgegeben, den ich an sich sehr gut und umfassend finde. Das hat allerdings auch einen gewissen Beigeschmack:

• Grundlagen für ein sicheres Heimnetzwerk schaffen
• Sichere Hardware verwenden
• Topologische Planung in der Heimvernetzung
• Funktions- und Adressbereiche für Heimnetzwerke
• Sichere Passwörter erstellen und verwalten

Diese Punkte decken einen Großteil der Maßnahmen ab, die für ein sicheres Heimnetz erforderlich sind.
Aber wer von euch geht bei der Einrichtung der Smart Homes so vor? Wer überprüft die Sicherheit der Netzwerke? Wer trennt beim Kunden Smart Home- und private Geräte im Netzwerk, vielleicht sogar durch getrennte physikalische Netzwerke mit definierten Übergabepunkten und Schnittstellen?
Schreibt ihr dem Kunden vor, wie sicher sein Passwort zu sein hat?
Richtet ihr dem Kunden auf jedem Endgerät ein VPN on demand ein, damit er auf den Miniserver zugreifen kann, weil er es selbst nicht auf die Reihe bekommt? Was macht ihr, wenn der Kunde sich nach zwei Jahren ein neues iPhone kauft?
Welche VPN-Lösung wird genutzt, die Fritzbox-interne? Mit der Fritz-eigenen DynDNS-Lösung, damit man von unterwegs die Fritzbox findet? Und wenn der Kunde ein Speedport hat?

Das ist nur ein Teil der Fragen und offenen Punkte, denen man sich als Installateur von Smart Homes stellen muss. Und zwar nicht nur bei Loxone sondern auch beim HomeServer, Domovea oder wie sie alle heißen. Loxone lässt einen meiner Meinung nach da erst mal im Regen stehen. Es gibt keine größeren Sicherheitshinweise, mit der Freigabe wird der einfachste Weg des geringsten Widerstands gegangen. Und wenn es Probleme gibt, muss man eben den Port wechseln. Wieso wird denn standardmäßig der Port 80 verwendet, wenn man am Ende weiß, dass er unsicher ist?