NEWS
[Hinweis] Gefahren durch Port-Freischaltungen
-
@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.
-
@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.
-
@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.
-
@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 -
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:
-
@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 -
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.
-
@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.
Gruß,
Mathias -
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. -
@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? -
@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. -
@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. -
Ich verstehe nicht, warum die User gezwungen werden immer kompliziertere und aufwändigere Passwörter zu benutzten aber die Loginversuche nicht begrenzt werden können.
Gerade beim iob und auf iobroker.pro nach 15 bewusst falschen Eingaben aufgehört zu probieren.
Warum wird nicht generell fail2ban oder pam_tally2 oder ... aktiviert?
Ein Login der nach jedem Fehlversuch die Eingabezeit stark verzögert oder ganz verhindert ist meiner Meinung nach besser und sicherer als ständig mit immer kryptischeren Passwörtern zu nerven aber die Loginversuche nicht zu begrenzen. -
@Ulfhednir
Das war meine erste Arbeit, ein umständliches Paßwort zu setzen und die Seite ssl verschlüsseln.
Aber eine Eingabebegrenzung falscher Passwörter ist auch nicht schlecht. Wobei man dann bei der nächsten Schwachstelle, dem Paßwort-Manager ist.
Was bringt ein kryptisches Passwort, wenn das Passwort für den Passwort-Manager 1234567890 lautet? Nicht jeder hat eine Fritzbox, ich auch nicht. Aber Dank der Routerfreizügigkeit, die den Netzbetreibern ein Dorn im Auge sind, kann man sich die Hardware eben selber kaufen. Mein Router ist im Übrigen ein Draytek Vigor 2865. -
@MathiasJ
Hi, ich bin so ein DAU glaube ich
Habe "eigentlich" gedacht das iobroker nur über die Fritz VPN erreichbar ist, zumindest habe ich nur diese Myfritz Freigaben unter Internet->Freigaben erstellt.
Dennoch hat mir auch einer über Telegram geschrieben meine iobroker Steuerung wäre offen ich solle meine Ports überprüfen.
Gebe ich jetzt meine tagesaktuelle IP Adresse gefolgt vom iobroker Admin Port ein ist diese Erreichbar. Habe jetzt ein Passwort vergeben aber sollte der Port nicht zu sein und nur über die kryptische VPN Adresse erreichbar sein?
Bin gerade erst auf eine Zotac NUC mit proxmox Installation umgezogen. Muß hier noch extra einen Firewall hin? -
@gcg67
Du kannst bin2fail installieren, dass ist so eine Firewall für Linux. Die überwacht aber nur ssh.
Wenn Du die Fritzbox über VPN erreichen willst, installiere Dir bitte die App myfritz! auf Dein Handy.
Den VPN-Zugang kannst Du nur einrichten, wenn Du zuhause bist und das Handy sich im heimischen WLAN befindet.
Oder wenn Du das Dir nicht zutraust, sende mir bitte eine PN. Dann machen wir das zusammen per Teamviewer
Wenn Du noch einen zweiten Router hast, anschließen! Dann basteln wir zusammen eine DMZ, was noch etwas sicherer ist., -
@MathiasJ Du meinst doch sicherlich fail2ban, oder habe ich da was verpasst?
-
@MathiasJ
Teamviewer
DMZ
fail2ban Firewall?
-
@Meister-Mopper
Ja, habe ich was verwechselt? -
@MathiasJ
Dann aber bitte nix verwechseln, wenn da per Teamviewer sowas eingerichtet werden soll...