Weihnachtsangebot 2025! 🎄

[astrakid]

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

Deswegen der Ansatz mit Authentifizierung "am Eingang", nicht "an jedem erreichbaren Objekt"

ja, deshalb auch die idee, fail2ban einzusetzen - dadurch wird herumprobiererei eingeschränkt.

[ikkerus]

Mal so ein paar Security-Aspekte von meiner Seite dazu.

• zusätzlichen User verwenden, am besten einen, den ihr nicht als Pseudonym im Netz einsetzt
• Zugang per SSH via SSH-Key und fail2ban absichern, SSH-Key NICHT in einer Cloud speichern
• Zugang ausschließlich per VPN
• iobroker Benutzerverwaltung aktivieren, damit man sich nicht einfach so anmelden kann

[MathiasJ]

...und von meiner Seite:
SSH-Port ändern
Benutzername "pi" in ein anderes ändern,
Zugang ausschließlich über VPN
Eine vernünftige Firewall einsetzen (ich nutze pfSense)
einen vernünftigen Switch einsetzen, so läßt sich VLAN realisieren,
IObroker Passwort setzen (sollte meiner Meinung nach schon bei der Installation so sein,
wegen Bequemlichkeit einiger Nutzer),
fail2ban wurde schon erwähnt
Im Router gucken, dass auch kein Port geöffnet ist.

[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