Weihnachtsangebot 2025! 🎄

[Markus84]

@ramses said in [Hinweis] Gefahren durch Port-Freischaltungen:

Wer so "blöd" ist den Menüpunkt "Selbstständige Portfreigaben für dieses Gerät erlauben." auszuwählen, hat es nicht besser verdient.
Zum Glück sind wirklich nur wenige so unschlau.

Blöde Frage: Selbständige Portfreigaben nicht zu aktivieren ist klar. Was ist denn mit Zugriff für Anwendungen zulassen und Statusinformationen über UPnP übertragen. Das ist okay, richtig? Zumal man ersteres ja ohnehin für den Fritbox Adapter braucht. Oder liege ich hier völlig falsch?

[MathiasJ]

@MathiasJ sagte in [Hinweis] Gefahren durch Port-Freischaltungen:

@astrakid
Ich wollte eigentlich mein System durch ein DMZ absichern.
Nun habe ich aber pfsense gefunden, den man als Router aber auch als mächtige Firewall einrichten kann.
Erfreulicher weise habe ich mir einen smartmanaged Switch gekauft.
da ich mir alles im Format rack 19" zugelegt habe, paßt sogar alles in einen Netzwerkschrank.
Ich muß mir nur noch einen leeren 19" Einschub zulegen, vllt paßt da auch noch IObroker und die Raspberrymatic rein.
ich denke halt so: lieber zu viel Sicherheit.
Bruteforce-Attacken gehen ja auch gut mit fail2ban zu verhindern.
Natürlich ist jeder für seine eigene Sicherheit verantwortlich, öffnen Ports und setzen keine Paßwörter.
Dann wundert man sich, wenn ein Miesling das System übernommen hat.

Edit:
Der leere Einschub hat sich erledigt.
Bin gerade dabei, alles auf Proxmox umzustellen. Dann spare ich mir wenigstens die 2 PI3 B+ für die Homematic und das PI 4B für IObroker. Die Umstellung auf VLAN und DMZ via OPNsense bleib jedoch bestehen.

[eric2905]

Moin,

@MathiasJ sagte in [Hinweis] Gefahren durch Port-Freischaltungen:

Dann spare ich mir wenigstens die 2 PI3 B+ für die Homematic und das PI 4B für IObroker.

denk bitte daran, das sowohl Debmatic wie auch RaspberryMatic auf x86 noch Beta sind.

Gruß,
Eric

[MathiasJ]

@eric2905
Laut Jens ist die RM auf dem x86 kein Beta mehr.
Guckst Du:
https://homematic-forum.de/forum/viewtopic.php?f=65&t=54055&start=380
Zur Zeit ist sie eher mein Spielplatz, weil ich alles wahrscheinlich neu installieren muß.
Derzeit hängt alles direkt an der Fritzbox, was sich nach dem Umzug ändern soll.

[XSDiver]

Hallo zusammen,

ich bin auch so ein Port weiterleiter, obwohl ich ioBroker Pro habe (und auch was bezahlt habe :))

Aber wenn ich über den Pro Account auf die Admin Oberfläche zugreife, dann bekomme ich bei manchen
(nicht bei allen) Instanzen wenn ich in die Einstellungen gehe. - 501 remote answer - angezeigt?

Warum - wie kann ich das beheben?

Vielen Dank für Eure Hilfe.

[MathiasJ]

@XSDiver
schon mal über VPN versucht?
Ich nutze nicht iobroker pro und habe über VPN trotzdem zu allem Zugriff.

[XSDiver]

@MathiasJ Hab auch Zugriff über VPN, aber wenn ich einen Pro Zugang habe, sollte es doch auch über diesen den Pro Account funktionieren. Unabhängig von den Möglichkeiten die es noch so gibt.

[oxident]

Wenn ich Euch hier richtig verstehe, dann wird generell davon abgeraten, iobroker aus dem Internet verfügbar zu machen, unabhängig von der Komplexität des Kennworts?
Ich meine, wenn man nur dediziert die Ports der Admin- und Web-Instanz freigibt, HTTPS nutzt und die Kennwörter sicher sind, dann sollte doch eigentlich nichts passieren ... es sei denn, bei der Implementierung des Webservers ist irgendwo ein Bug drin.

Ich war schon erfolgreich dabei, die Web-Instanz freizugeben. Sobald ich aber auch den Admin-Port durchleite, lande ich komischerweise auf beiden Ports immer nur noch auf der Admin-Seite (und kann daher nicht mehr auf die Vis-Seite zugreifen). Das wollte ich eigentlich weiter ausbauen ... bis ich diesen Thread hier gefunden habe ;-)

[astrakid]

@oxident ich sehe das Risiko als überschaubar an. Wenn natürlich jemand eingedrungen ist, hat er Zugriff auf deine Geräte. Aber wenn man gute Passwörter verwendet und dann noch fail2ban gegen bruteforce Attacken, sehe ich es als ausreichend sicher an.

[MiGoller]

@astrakid @oxident Wenn das ganze auf Docker läuft, dann lässt sich das ganze auch schön über einen Reverse Proxy bzw. Edge Router wie nginx oder Traefik absichern.

Ich persönliche nutze Traefik; an zentraler Stelle erfolgt die HTTPS-Terminierung. Da lassen sich auch Let's Encrypt Zertifikate mit automatischer Aktualisierung einsetzen. Gute Passwörter sind auch schon gut. In jedem Fall lässt sich fail2ban gut nutzen, um am Traefik Anmeldeversuche zu überwachen. Es geht sogar eine zusätzliche Absicherung mit Client-Zertifikaten.

Wenn ich jetzt noch LDAPS- bzw. Radius- oder OAuth-Authentifizierung am ioBroker hätte, wäre es richtig gut. Dann hätte ich z.B. mit DUO Security sogar noch eine MFA-Lösung dazu, die auch noch Session-Handling kann. Ich hoffe nicht, dass ich eine Erweiterung für den ioBroker übersehen habe, die genau das bietet.

[mickym]

@oxident Also ich habe einen nginx Reverse Proxy - aber das läuft nicht richtig, weil jeder Adapter Port usw. ein Riesenkonfigaufwand bedeutet und ich habe es bislang mit allem was ich hier im Netz gefunden habe nur rudimentär hinbekommen, wobei ich zugeben muss, dass ich hinter die Funktionalität von nginx auch nicht richtig durchsteige.

Ich habe aber noch eine VPN Lösung mittels OpenVPN implementiert und damit bin ich maximal flexibel und das funktioniert auch. Du kannst aber halt mit einem VPN nur Geräte nutzen, die DIr auch gehören. ;)

[astrakid]

@mickym sagte in [Hinweis] Gefahren durch Port-Freischaltungen:

Also ich habe einen nginx Reverse Proxy - aber das läuft nicht richtig, weil jeder Adapter Port usw. ein Riesenkonfigaufwand bedeutet und ich habe es bislang mit allem was ich hier im Netz gefunden habe nur rudimentär hinbekommen, wobei ich zugeben muss, dass ich hinter die Funktionalität von nginx auch nicht richtig durchsteige

wo liegen denn genau deine probleme bei der konfiguration? zugegeben, für jeden neuen port muss man in nginx einen server eintragen und einen proxy - mit einer vorlage dauert das aber keine minute:

upstream <bezeichnungMeinserver> {
    server <ip>:<internerPort>;
}

server {
    proxy_http_version 1.1;
    listen              <externerPort> ssl http2; 
    server_name         <fqdns>;
    ssl_certificate     /etc/letsencrypt/live/cert.pem; # The certificate file
    ssl_certificate_key /etc/letsencrypt/live/privkey.pem; # The private key file
    location / {
        proxy_pass https://<bezeichnungMeinserver>/;
        proxy_ssl_verify off;
        proxy_ssl_server_name off;
        proxy_set_header Host $http_host;
        proxy_set_header X_FORWARDED_PROTO https;
    }
}

das ist alles.

gruß,
andre

[mickym]

@astrakid

Oh die Probleme sind so vielfältig. :(

OK - das mit upstream habe ich nicht eingetragen - aber es geht schon los, wenn ich den admin des iobrokers aufmache und dann die Links auf den Kacheln versuche abzufangen - das bringe ich nicht hin.

Dann muss man quasi jede Anwendung checken - was iobroker betrifft. Ich habe zumindest einigermaßen hingebracht, dass ich den info Adapter, Objekte, Log und Instanzen einigermaßen fehlerfrei sehe.

Ich nutze ja Node-Red - aber den JavaScript bringe ich auch nicht zum Laufen - der hängt eine Ewigkeit in dem Bild

Viele Dinge kann ich im Moment auch nicht darstellen, weil ich momentan eh im Heimnetz bin. Aber auch die Buttons im iobroker werden teilweise nicht richtig dargestellt oder übersetzt und und und.

Ich kann Dir ja mal meine Konf posten - aber ehrlich gesagt bin ich momentan was das betrifft ziemlich gefrustet.

server {
#	listen [::]:1080;
	listen [::]:443 ssl;
#        server_name <MEIN-Server>.internet-dns.de;
        server_name *.internet-dns.de;

		# SSL Konfiguration
        ssl_certificate /etc/nginx/ssl/<MEIN-Server>.crt;
        ssl_certificate_key /etc/nginx/ssl/<MEIN-Server>.key;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers   HIGH:!aNULL:!MD5;

		# root /var/www/<MEIN-Server>.internet-dns.de;
        
        # Authentifizierung
	auth_basic "<MEIN-Server> Server Authentifizierung";
	auth_basic_user_file /etc/apache2/.htpasswd;
        
        # Ganzen Server für Websockets vorbereiten
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
	proxy_set_header Host $host;
	proxy_set_header X-Real-IP $remote_addr;
# ------------------------------------
#		server_name_in_redirect off;
#		port_in_redirect off;
# ------------------------------------

        proxy_cache off;
	proxy_cache_bypass $http_upgrade;
	proxy_set_header Accept-Encoding "";


		location / {

			if ($http_referer ~ "https://<MEIN-Server>.internet-dns.de/iobroker"){
				rewrite ^/(.*) /iobroker/$1;
			}
			if ($http_referer ~ "https://<MEIN-Server>.internet-dns.de/vis"){
				rewrite ^/(.*) /vis/$1;
			}
			if ($http_referer ~ "https://<MEIN-Server>.internet-dns.de/flot"){
				rewrite ^/(.*) /flot/$1;
			} 
			if ($http_referer ~ "https://<MEIN-Server>.internet-dns.de/node-red"){
				rewrite ^/(.*) /node-red/$1;
			} 
			
			rewrite ^(/images/.*)$ /node-red$1;
		 

		
		
		}		
# -------------------------------------      
		
		location  /iobroker/ {
			
			proxy_pass http://<MEIN-Server>.fritz.box:8081/;

		}


#             ------------- End iobroker Admin ---------------------

		location = /vis {
			rewrite ^/(.*) /$1/ last;
		}
		
		location /vis/ {
			proxy_pass http://<MEIN-Server>.fritz.box:8082/;

		}

		location /lib/ {

			proxy_pass http://<MEIN-Server>.fritz.box:8081/lib/;
		}

		location /js/ {

			proxy_pass http://<MEIN-Server>.fritz.box:8081/js/;
		}
		
	        location /adapter {
			proxy_pass http://<MEIN-Server>.fritz.box:8081/adapter;
		}

		location /flot/ {
			proxy_pass http://<MEIN-Server>.fritz.box:8082/flot/;
		}
		
#       --------------------------------------------------

		location /socket.io/ {
			proxy_http_version 1.1;
			proxy_set_header Upgrade $http_ugrade;
			proxy_set_header Connection "upgrade";
			

			proxy_pass http://<MEIN-Server>.fritz.box:8082/socket.io/;
		}	
		
                location /node-red/ {
			proxy_pass http://<MEIN-Server>.fritz.box:1880/;
		}	

                location /node-red/admin {
			return 301 http://<MEIN-Server>.internet-dns.de:26558/node-red/;
		}	



		location /dashboard/ {
			proxy_pass http://<MEIN-Server>.fritz.box:1880/ui/;
		}

		location /shell {
			proxy_pass https://localhost:4200/;
		}

		location /fhem {
	            auth_basic off;

#       -------------------------------------------------------
#			wird ueber proxy_parms global gesetzt !!!
#
#			proxy_set_header Host $http_host;
#			proxy_set_header X-Forwarded-Proto $scheme;
#       -------------------------------------------------------

			proxy_set_header Connection '';
			proxy_read_timeout  90;

			proxy_pass http://<MEIN-Server>.fritz.box:8083;
		}

}

Ich hab inzwischen schon so viel ausprobiert - mich durch 1000 Log Zeilen gewuselt und werde doch nicht schlauer.

Aber mein NodeRed Dashboard läuft wenigstens !!!! - Das ist mir im Moment das Wichtigste - da ich sonst alles via VPN mache.

Ein weiteres Beispiel - wie der VIS Editor ausschaut - ein Grauß und nun rausbekommen, warum die Schaltflächen nicht richtig dargestellt werden:

[astrakid]

@mickym nimm meine Konfiguration und ersetze eine ip:port kombi durch eine serverkonfiguration. die einzelnen verzeichnisse brauchst du nicht extra freigeben - da wird alles 1:1 durchgereicht. es wird nur der lokale name bzw. die lokale ip durch den FQDN ersetzt.
schreib mich mal per PN an, dann können wir das direkt miteinander machen.

gruß,
andre

[Ulfhednir]

Ich muss das Thema hier einmal erneut aufreißen - aus meiner Sicht ist es mit einem "Foren-Beitrag" mit einem Hinweis auf die Gefahren von Port-Freischaltungen nicht getan.
Es existieren derzeit über 700 potentielle, angreifbare Scheunentore. Mit den nötigen Background kann ein Hacker hier problemfrei gesamte Netzwerke übernehmen - und das könnten selbst Skript-Kiddies!

Mir ist bereits ein Fall bekannt, bei dem durch eine falsch gesetzte Port-Freigabe ein NAS kompromittiert und verschlüsselt wurde. Das Einfallstor war an der Stelle der Admin-Adapter. Jetzt kann man natürlich argumentieren, dass derjenige die Portfreigabe eigenhändig angelegt hat... Aber hier sehe ich das System in der Verpflichtung, dass die Selbstgefährdung reduziert wird. Man kann sich hier ein Beispiel an Homematic nehmen. Es wurde von langer Hand auf die Risiken hingewiesen und nicht nur im Forum, sondern im System selbst. Ein Ansatz wäre, dass sicherheitskritische Adapter standardmäßig nur über das interne, vorkonfigurierte Netzwerk aufrufbar wäre. Dann könnte ein Unwissender den Port zwar versuchen freizugeben, der Login würde trotzdem scheitern. Im weiteren Schritt wäre eine "abgespeckte" Firewall für den ioBroker denkbar - ähnlich wie es in Homematic gelöst ist.

[MathiasJ]

@Ulfhednir
und trotzdem macht man es immer wieder:
Port offen
Port offen Part2
Was bringt die schönste Firewall, die vom Benutzer selbst ausgehebelt wird?
Deshalb steckt bei mir das ganze Equipment hinter einer, DMZ, Firewall, VLAN und Radius-Server
Wenn das nicht reicht, dann reicht eh nix mehr. :clown_face:
Gruß,
Mathias

[OliverIO]

@astrakid

zum Thema überschaubares Risiko (auch wenn das schon ein weilchen her ist)
hier sind die aktuellen Sicherheitslücken in Node.
https://www.cvedetails.com/vulnerability-list/vendor_id-12113/Nodejs.html
der ioborker besteht ja nicht nur aus der iobroker software selbst, sondern zu hunderten, wenn nicht gar zu tausenden (hab sie nicht gezählt) benutzen bibliotheken verschiedener versionsstände. zu diesen gibt es immer bereits bekannte, aber nicht gefixte Lücken
und dann sicherlich noch eine menge weiterer Lücken die noch nicht entdeckt oder offiziell dokumentiert wurden.
Auch ein Reverseproxy hilft nicht gegen alles, da die Sicherheitslücken, die mit http requests oder auf andere Ports ausgenutzt werden können, ja trotzdem durchgereicht werden.
wenn ich dadruch dann erst einmal code ausführen kann, dann kommt man meist auch weiter bis man über das Netzwerk auch auf andere Geräte kommt.
Die meisten sind hier keine Netzwerkadministratoren, Security-Spezialisten oder gar Pen-Tester.

[Ulfhednir]

@MathiasJ sagte in [Hinweis] Gefahren durch Port-Freischaltungen:

@Ulfhednir
Was bringt die schönste Firewall, die vom Benutzer selbst ausgehebelt wird?

Das halte ich für den verkehrten Ansatz. Es gilt zunächst eigentlich immer der Grundsatz des Selbstschutzes. Ich nehme mal ein krasses Beispiel: In der Realität haben alle Waffen einen Sicherungsbügel. (Polizei und Militär ausgenommen) Wenn man deinem Grundsatz verfolgen würde, wäre der Sicherheitsbügel grundsätzlich hinfällig. Und warum gibt es diesen? Damit sich kein Schütze versehentlich ins Bein schießt. Was natürlich bei Fahrlässigkeit hin und wieder vorkommen kann. Soviel zum Aushebeln von Sicherheitsbestimmungen.

Es gibt technische Wege die Hürden für den "technisch unversierten" Nutzer höher zu legen bzw. das Risiko einzuschränken. Das beginnt mit einer zwangsweisen Kennworteingabe beim Admin-Adapter. Dann kann man den Zugriffsbereich einschränken (nur Netzwerkbereich von ioBroker + separen Bereich vom VPN-Netz) . Um noch ein Sicherheitsthema aufzureißen: Warum zum Teufel werden Kennwörter in der objects.json im Klartext gespeichert?
Man kann natürlich jetzt argumentieren, dass die Adapter von der Community entwickelt werden - aber auch hier: Warum gibt es kein Standard bzw. Sicherheitsguidelines?

[MathiasJ]

@Ulfhednir
Da hast Du schon recht, aber was bringt es dann, wenn vom DAU Ports im Router
geöffnet werden und kein Admin-Passwort gesetzt ist?
2 Beispiele habe ich ja weiter oben genannt, die doch noch recht aktuell sind.
Dabei ist es wirklich kein Hexenwerk in der Fritzbox eine VPN einzurichten. Mit der App myffritz! geht das recht einfach und schnell.

[Ulfhednir]

@MathiasJ dann verrate mir mal, wo der Dau während des Installationsprozesses darauf achten kann / soll, dass er ein Admin Kennwort zu setzen hat. https://youtu.be/_wRB526QVtM
Es wäre sinnig, dass man nachdem die Lizenzbestimmungen gelesen hat, zunächst ein Kennwort hinterlegen muss. Aber hier wird sogleich während der Installation der Discovery-Adapter gestartet.
Das suggeriert dem Enduser ein "Plug&Play" - er muss sich um nichts mehr kümmern.

Zu deinem Thema FritzBox - du kannst nicht davon ausgehen, dass jeder zu Hause eine FritzBox herumzustehen hat. Da gäbe es noch ausreichend Telekom-Kunden mit einem Speedport und Vodafone Kunden mit einer EasyBox.
Da ist VPN nicht ganz so einfach eingerichtet. Und hier liegt auch das eigentliche Problem: Der Aufwand den Admin-Adapter freizugeben ist geringer als einen VPN aufzubauen.