Neuer ioBroker-Blog online: Monatsrückblick März/April 2026

[hschief]

Liebes Forum,

ich bin mir nicht sicher ob dies ein Bug ist, ein Einstellungsproblem oder Konfig Fehler.
Mein IOBroker läuft hinter einer Firewall und darf nur auf bestimmte, externe IP Adressen zugreifen.
Ich habe eben einen Update auf den Admin Adapter: v6.12.0 durchgeführt. Nach dem Update crashed der admin Adapter nach kurzer Zeit, wenn die IP Adresse 185.199.108.133 gesperrt ist.

Log Eintrag:
Error: connect ETIMEDOUT 185.199.110.133:443 at AxiosError.from (/opt/iobroker/node_modules/axios/dist/node/axios.cjs:837:14) at RedirectableRequest.handleRequestError (/opt/iobroker/node_modules/axios/dist/node/axios.cjs:3083:25) at RedirectableRequest.emit (node:events:513:28) at eventHandlers.<computed> (/opt/iobroker/node_modules/follow-redirects/index.js:14:24) at ClientRequest.emit (node:events:513:28) at TLSSocket.socketErrorListener (node:_http_client:502:9) at TLSSocket.emit (node:events:513:28) at emitErrorNT (node:internal/streams/destroy:151:8) at emitErrorCloseNT (node:internal/streams/destroy:116:3) at process.processTicksAndRejections (node:internal/process/task_queues:82:21)

Kennt einer das Problem?
Vielen Dank für eure Ideen

[Thomas Braun]

@hschief sagte in Admin adapter crash v6.12.0:

Kennt einer das Problem?

Geb den Zugriff frei. Das ist github auf der anderen Seite.

[hschief]

@thomas-braun

Hallo Thomas,
nach meiner Meinung sollte man Zugriff von einem IOT Netzwerk nur dann nach aussen freigeben, wenn man weiß was da übertragen wird.
In den vorheriegen Versionen wurden keine Daten nach GIT Hub übertragen. Ich würde nun schon gerne wissen wollen, welche Daten denn dorthin übertragen werden.

Auf der eine Seite warnen wir davor den IOBroker nur gesichert an das Internet zu provisionieren, auf der andere Seite ist aber die Idee Daten einfach zu übertragen?

Viele Grüße
Helmut Schiefer

[Thomas Braun]

@hschief sagte in Admin adapter crash v6.12.0:

Auf der eine Seite warnen wir davor den IOBroker nur gesichert an das Internet zu provisionieren, auf der andere Seite ist aber die Idee Daten einfach zu übertragen?

Ja, für Zugriffe von AUSSEN.
Von Innen müssen diverse Dienste natürlich erreichbar sein. Die von github z. B.

[Glasfaser]

@hschief

@thomas-braun
Geb den Zugriff frei. Das ist github auf der anderen Seite.

Richtig da sonst dein :

Mein IOBroker läuft hinter einer Firewall und darf nur auf bestimmte, externe IP Adressen zugreifen.

per Firewall blockt .

Wie soll denn sonnst ein ein Update / abfrage funktionieren !?

Davon ab ist es aber ein falsches Sicherheitskonzept ...
denn du schreibst :

eben einen Update auf den Admin Adapter: v6.12.0 durchgeführt.

der ist aber schon lange bei dir überfällig

github:	6.13.11 for 3 days
latest:	6.13.11 for 5 days
stable:	6.12.0 for 67 days

daher sollte man schon UpToDate sein .

Siehe auch hier im Forum ... zu Nodejs !

[hschief]

@glasfaser

Vielen Dank für die Antworten.

1. Backdoors furnktionieren immer über den Weg von Ihnen nach aussen und werden über updates eingespielt. Daher ist es ein Security Issue wenn ein Programm plötzlich und ohne Grund Verbindungen von Innen nach Aussen aufmacht. Über diesen Weg werden System angegriffen.
   Wenn ich einen Adapter installiere und dieser Daten braucht, dann öffnet man gezielt die IP Adressen kontrolliert. So funktioniert ein sicheres IOT Netz.

2. Upates spielt man nicht ein um Up-To Date zu sein, dies ist nicht nice to have. Grundsätzlich gilt: Ein stabiler Betrieb in einem gesicherten Netz wird nur bei einer Funktionsänderung angepasst. Never touch a running system!

Aber ehrlich - schön Argumente auszutauschen - leider erklärt mir damit aber immer noch keiner warum der Admin Adapter Daten aus meinem Netz nach GitHub übertragen will und welche Daten

[haselchen]

@hschief sagte in Admin adapter crash v6.12.0:

Never touch a running system!

OT

Ring frei, Runde 1 :)

@Thomas-Braun

[Thomas Braun]

@hschief sagte in Admin adapter crash v6.12.0:

Never touch a running system!

Och nein, schon wieder so'n Quark...
Updates auf eine stabile Version spielt man IMMER ein.
Um eben da up-to-date zu sein. Das ist natürlich KEIN nice-to-have sondern absolut erforderlich für ein gesundes System.

[Thomas Braun]

@hschief sagte in Admin adapter crash v6.12.0:

leider erklärt mir damit aber immer noch keiner warum der Admin Adapter Daten aus meinem Netz nach GitHub übertragen will und welche Daten

Versionsstände z. B.? Um aktuelle Versionen abzufragen?

Da du es dir ja auch zutraust zu entscheiden ob oder wann ein System 'getatscht werden' muss: Schau in den Code und bewerte dann, ob und welche Daten da warum da evtl. an GitHub gehen müssen:

https://github.com/ioBroker/ioBroker.admin

[hschief]

@thomas-braun
Hallo Thomas,

mein Admin Adapter steht auf update: Manuell, daher gibt es keinen Grund warum er im laufenden Betrieb alle 5 Minuten irgendetwas überträgt. Ich habe auch in den Release Notes diese Änderung nicht gefunden.

Ja, bei einem Update wird es gebraucht und dann öffnet man mit einem Click die Firewall.

[hschief]

@thomas-braun

Es gibt bei IT Systemen einen Closed Shop Ansatz (Ich betreibe Systeme und Sicherheitsbereich seit 1984 - Unix seit 1990), daher gibt es vielleicht verschiedenen Ansätze ein IOT Netz zu betreiben.

Vielleicht können wir aber diese Diskusion bzgl. verschiedener Ansätze einfach beenden.

[Glasfaser]

@hschief sagte in Admin adapter crash v6.12.0:

Never touch a running system!

Naja ... dazu sage ich mal nichts .

Und nebenbei , nicht nur GitHub ;) sondern auch hier werden Daten gesendet :

Upates spielt man nicht ein um Up-To Date zu sein, dies ist nicht nice to have.

... aus dem Grund gibt es auch Sentry , damit Entwickler mitbekommen das ein Fehler vorliegt usw.

https://forum.iobroker.net/topic/46921/meldungen-an-sentry-iobroker-net-deaktivieren

[ticaki]

@hschief

Nur zur erweiterten Info - Der Admin Adapter läd regelmässig z.B. die zu dieser Doku gehörende Definition runter um gegen zu checken:

https://github.com/ioBroker/ioBroker.admin/blob/master/packages/jsonConfig/SCHEMA.md

Daher sollte der zugriff auf github.com frei gegeben sein. Denke der macht das über rawIRGENDWAS.github.com

[Thomas Braun]

@hschief sagte in Admin adapter crash v6.12.0:

Vielleicht können wir aber diese Diskusion bzgl. verschiedener Ansätze einfach beenden.

Dann check halt den Code, musst du ja bei dem Ansatz dann für jedes Software-Paket eh machen.

[hschief]

@ticaki
Vielen Dank für den Kommentar, auch dies erklärt die Änderung nicht, in der älteren Version ist der zykliche Update nicht durchgrführt worden, muss auch nicht, denn wir habe ja extra die Einstellung:

Update -> Manuell, warum sollte ein automatischer Abgleich notwendig sein? Hacker holen sich immer erst de installierten Versionen um über bekannte Exploits anzugreifen. Dies wird dadurch möglich, das man Daten nach aussen überträgt.

Daher vielleicht einfach die Frage: Warum ist der Zugriff nach aussen plötzlich erforderlich?

Wenn die Antwort nur der Entwickler kennt - OK, akzeptiert.

Meine Frage ist nicht - wie betreibt man ein sicheres Netz, auch nicht wie häufig sollte ich updaten.

[mcm1957]

@hschief

Dazu auch mal mein Senf:

a) Der Titel scheint falsch zu sein. Es sieht (für mich) nicht danach aus dass Admin CRASHE. Admin logget nur einen Fehler. Sollte admin doch crashen, dann geht das aus den hier geposteten Infos nicervor.

b) Ich kann aus dem Fehler nicht erkennen, dass Admin etwas zu Github SCHREIBEN möchte. Hast du dazu genauere Infos die vermuten lassen, dass ein SCHREIBZUGRIFF stattfinden soll?

c) Der Fehler erfolgt wahrscheinlich wegen des erst mit Admin 6 eingeführten Checks der Konfigurationsdateien. Dazu holt sich admin die benötigte Schema Datei von github. Ein Betrieb ist aber auch ohne diesen Check möglich.

d) @foxriver76 kannst du hier mal einen Blick drauf werfen ob die Vermutung dass es um den schema Zugriff geht wahrscheinlich richtig ist? Wenn ja dann sollte da kein Fehler sondern maximal ein Info Hinweis geloggt werden - und das einmali - dass die Schemaprüfung nicht geht. Da wurde zwar m.W. nach schon was abgefangen - aber offensichtlich macht hier die Firewall kein Blocking sondern führt zu einem Timeout, ev. ist der Fall nicht abgefangen.

[hschief]

@mcm57

Hi mcm57 - vielen Dank für die sachliche Analyse. Krankheitsbedingt konnte ich mich leider nicht mehr melden. Folgendes kann ich derzeit beitragen:

1. Ein Downgrade auf 6.11.0 behebt das Problem. Die Änderung ist also mit dem Wechsel auf 6.12.0 entstanden.

a) Der Titel scheint falsch zu sein. Es sieht (für mich) nicht danach aus dass Admin CRASHE. Admin logget nur einen Fehler. Sollte admin doch crashen, dann geht das aus den hier geposteten Infos nicervor.
==> Ich kann mich danach nicht mehr auf der AdminWeboberfläche anmelden, erst wenn ich den Adapter von der Shell neu starte geht es wieder für einen gewissen Timeout. Ich denke mal, der Adapter versucht zyklisch GIT zu erreichen, wenn dies nicht klappt entsteht wohl erst ein Timeout (Admin zeigt das drehende Icon) und stirbt dann)

b) Ich kann aus dem Fehler nicht erkennen, dass Admin etwas zu Github SCHREIBEN möchte. Hast du dazu genauere Infos die vermuten lassen, dass ein SCHREIBZUGRIFF stattfinden soll?
==> Ja, das hast du recht, heit schlägt meine Paranoia zu, ob er nur liest oder auch schreibt, kann ich natürlich nicht sagen. Ich bin halt sehr vorsichtig. Da der Update ja auf manuell konfiguriert ist sollten ja eigentlich keine Zugriff stattfinden.

c) Der Fehler erfolgt wahrscheinlich wegen des erst mit Admin 6 eingeführten Checks der Konfigurationsdateien. Dazu holt sich admin die benötigte Schema Datei von github. Ein Betrieb ist aber auch ohne diesen Check möglich.
==> Wie gesagt, 6.11 läuft, wahrscheinlich wird in 6.12 auf den fehlenden Connect anders reagiert.

d) @foxriver76 kannst du hier mal einen Blick drauf werfen ob die Vermutung dass es um den schema Zugriff geht wahrscheinlich richtig ist? Wenn ja dann sollte da kein Fehler sondern maximal ein Info Hinweis geloggt werden - und das einmali - dass die Schemaprüfung nicht geht. Da wurde zwar m.W. nach schon was abgefangen - aber offensichtlich macht hier die Firewall kein Blocking sondern führt zu einem Timeout, ev. ist der Fall nicht abgefangen.
==> Nach meiner Meinung bei Update Manuell noch nicht mal ein Hinweis.

Erneut vielen Dank auf die Rückführung auf die Sachebene.
Helmut

[foxriver76]

@hschief der fix ist erst in 6.12.2, da zur Zeit ruhiger bei Admin denke ich können wir stable zeitnah mal erhöhen