[Hinweis] Gefahren durch Port-Freischaltungen

astrakid

@MathiasJ wenn du eine firewall einsetzt, dann ist die portweiterleitung im router doch nur schall und rauch - wird an der firewall eh abprallen?

ich bin auch der meinung, dass viele schutzmaßnahmen nicht verkehrt sind.
dennoch soll auch alles möglichst einfach nutzbar sein. die balance ist schwierig und selten eher in richtung sicherheit gehen.
wenn man allerdings seine systeme aktuell hält, nicht mehr als nötig nach außen zugänglich macht und sichere passwörter (ausreichende komplexität und nicht bereits kompromittiert) in kombination mit bruteforce-attack-erkennung paart ist man schon ganz gut gesichert.

gruß,
andre

MathiasJ

@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.

MiGoller

Hallo zusammen,

ich bin voll und ganz bei Euch, die Sicherheit hoch zuhalten, um auch wirklich nur den "Berechtigten" Zugriff auf den ioBroker samt Visualisierung, etc. zu bieten. Aus Erfahrung kenne ich nur leider auch den Effekt, wie Anwender sich verhalten, wenn der Komfort zu sehr leidet: Das Leben findet einen Weg! Hier einen komfortablen und möglichst sicheren Weg zu finden, ist wohl dann unsere Herausforderung.

In diesem Zusammenhang interessiert mich Eure Meinung zur Absicherung der Visualisierung mit Client-Zertifikaten statt Benutzername und Kennwort. Die "externe" Anmeldung an einer Test-Visualisierung habe ich mittels Radius-Authentifizierung realisiert, angereichert um einen zweiten Faktor über DUO Security. Der WAF ist dabei nur leider nicht sehr hoch; dafür habe ich eine deutliche Erwartungshaltung genannt bekommen: Nach Möglichkeit keine Eingabe von Benutzername und Kennwort. Es müsse einfach über das Gerät funktionieren. Kommt das hier irgendjemandem bekannt vor?

Bin auf Euer Feedback gespannt.

BBTown

Ich bin ja ein Fan von FIDO2 in Verbindung mit einem NFC-Security Key wie z.B. der UbiKey 5
Darüber kann bei NFC-konformen Geräten per "touch" eine Authentifizierung erfolgen.

scr2k

@Georgius

So nicht korrekt. Jeder Port ist immer ein potentielles Sicherheitsrisiko. Da kann dahinter alles richtig funktionieren: Jemand mit bösen Absichten wird sich Schwachstellen suchen...

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!
Bild Text

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.
Bild Text

NEWS

[Hinweis] Gefahren durch Port-Freischaltungen

Support us

721
Online

30.7k
Users

77.3k
Topics

1.2m
Posts

NEWS

[Hinweis] Gefahren durch Port-Freischaltungen

Support us

721Online

30.7kUsers

77.3kTopics

1.2mPosts

721
Online

30.7k
Users

77.3k
Topics

1.2m
Posts