Vorschlag zur Absicherung der CCU gegen Portweiterleitung

[Silverstar]

ich glaube wenn man Portweiterleitungen verhindern möchte reicht das Pop up nicht aus.

Wie wäre es die komplette Programmabarbeitung zu stoppen und ein fettes Overlay über die Oberfläche zu legen bis die Weiterleitung deaktievert wurde ?

Ich denke man muss die User die sowas nicht bedenken oder verstehen maximal behindern.

ciao
Andreas

Ich wollte jetzt nicht in dem Thread wieder abdriften und auch nicht @jmaus ungefragt eine PM schicken, außerdem möchte ich Feedback von anderen ermöglichen.

Was spricht dagegen, dass die CCU Firmware (also erstmal RM bis eq3 das vielleicht übernimmt) standardmäßig eine iptables rule mitbringt, die alle eingehenden Verbindungen blockiert die von außerhalb des LAN (Edit: bzw außerhalb des non-routable address space, dann ist S2S auch kein Problem) kommen, sodass eine Portweiterleitung unwirksam wird?
VPN-Nutzer haben eine lokale IP und alles andere (Mediola etc) baut ja die Verbindung nach außen auf, nicht umgekehrt.
Das könnte man dann nur mit Wissen über iptables wieder raus bauen und wer das rausfindet, ist hoffentlich so versiert, dass er keine Portweiterleitung macht, sondern nur für Site2Site VPN oder ähnliches braucht. (Für diese User muss man das natürlich dokumentieren und kommunizieren, bevor das Update ihm das zerbricht, bzw siehe Edit, nur wenn er Adressen außerhalb des non routable address space nutzt)
Den Portweiterleitungs-DAU sollte das aber aufhalten.

Habe ich etwas übersehen oder müsste das funktionieren?

Noch ein Edit: Im Prinzip müsste das ja dann der Firewall Einstellung in der webui "eingeschränkt" entsprechen und nur mit privaten Subnetzen erlaubt. Das Menü müsste also den Vollzugriff rausgepatcht bekommen und keine Eingabe von Adressen außerhalb des privaten Bereichs zulassen. Wer dann immernoch zwingend einen direkten Zugriff von routable adresses braucht, sollte in der Lage sein, diese selbst per iptables zu erlauben. (Aber warum?)

[Xel66]

Habe ich etwas übersehen oder müsste das funktionieren?

Funktioniert auf den ersten Blick sicher schon, allerdings verhindert es auch den (gewünschten) Zugriff von entsprechenden Diensten wie Cloudmatic aus. Deren VPN hat auch eine andere IP-Range als das Heimnetzwerk. Müsste also auch mit abgebildet werden. Da der Endpunkt dieser VPNs in der CCU selbst ist, ist das ein lösbares Problem, denn die CCU kennt ja ihre Netzwerkanbindungen.

Unabhängig davon halte ich diese Vorgehensweise nicht für dauerhaft zielführend, weil sich wie immer irgendwelche YT-Helfer mit Anleitungen profilieren, die diese Funktion deaktivieren, aber den Hintergrund, warum diese "Hürde" existiert, nicht im ausreichenden Maße erklären. Und ruckzuck existieren wieder die Portweiterleitungen. Anleitungen, wie Sicherheitsfunktionen verschiedenster Geräte ausgehebelt werden, existieren ja zuhauf im Netz. Ferner halte ich solche Art von "Anwenderbevormundung" (mag die Intension noch so sinnvoll sein) für nicht wünschenswert, weil der Normalanwender solche Limitierungen nicht erwartet. Da halte ich permanente Hinweise (Popup) für zielführender, da man hier eine Erklärung im Hinweis gleich mitliefern und so auf die Sicherheitsproblematik hinweisen kann. Aber ich bin mir sicher, es werden sich auch hier YT-Guys finden, die den Anwender anleiten, dieses "nervige" Popup zu beseitigen.

Gruß Xel66

[Silverstar]

Welchen Adressbereich benutzt cloudmatic denn? Wenn das alles in den privaten Bereichen bleibt, ist das ja kein Problem.

Ich bin auch kein Freund von erzwungener Bevormundung, ich habe z.B. Google freies, gerootetes Android.
Aber das ist ja keine unüberwindbare Hürde, denn mit ein zwei Zeilen auf der Konsole (oder sogar per system.exec) ist das ja lösbar. Ist ja nicht so, als wäre das System zu gemacht wie die meisten Smartphones.

Wenn dann noch jemand mit YT Videos oder ähnlichem das wieder ausbaut, ... Tja.
Ich behaupte aber Mal die meisten hier machen es aus Unwissenheit und "macht man mit dem Webserver vom NAS ja auch so".
Irgendwas muss man machen meiner Meinung nach, und dass die ccu sicher für Portweiterleitung wird, wird nicht so schnell passieren.

Man muss es wohl einfach so schwer wie möglich machen (ohne es ganz zu verhindern -> Bevormundung), so braucht es wohl der dau.

[rentier-s]

Vorweg muss ich gestehen, ich weiß nicht, bzw. habe bis heute nicht verstanden, über welchen Weg diese Angriffe genau stattfinden.

Aber im Prinzip würde es doch reichen, in den Firewall Einstellungen eine Einstellung für den Zugang auf das WebUI einzufügen, die standardmäßig auf "nur lokale Netzwerke" steht. Sobald man sie auf "Vollzugriff" umstellt, ein Popup mit expliziter Warnung "Schalte Portforwarding aus. Weißt du was das ist und bist du sicher, dass es aus ist?".

Vielleicht würde es Sinn machen, diese vierte Option auch für RPC und Remote Script einzufügen.

Ein Problem an solchen Geschichten ist, dass man natürlich zuverlässig erkennen muss, was lokal ist. Und das nicht nur für IPv4, sondern auch für IPv6 ggf. ohne lokales Prefix. Die iptables Regel müsste sich also dynamisch anpassen, wenn sich irgendetwas an den Adressen der CCU ändert.

[Silverstar]

Den Angriffswege kenne ich auch nicht, aber offenbar reicht der Webserver Port aus.

Die Einstellung gibt es, "eingeschränkt" und unten das Subnetz des LAN eingetragen. Oder eben "Vollzugriff", was eben alles erlaubt.

Lokal ist alles, was aus den IPv4 non-routable Adresse Space kommt oder IPv6 link-local (diese muss immer vorhanden sein, auch wenn eine routable v6 zugewiesen ist).

So muss die Regel nur alles blocken, was außerhalb dieser Bereiche kommt und muss daher nicht bei Änderung der Interfaces geändert werden.

[jmaus]

Was spricht dagegen, dass die CCU Firmware (also erstmal RM bis eq3 das vielleicht übernimmt) standardmäßig eine iptables rule mitbringt, die alle eingehenden Verbindungen blockiert die von außerhalb des LAN (Edit: bzw außerhalb des non-routable address space, dann ist S2S auch kein Problem) kommen, sodass eine Portweiterleitung unwirksam wird?
VPN-Nutzer haben eine lokale IP und alles andere (Mediola etc) baut ja die Verbindung nach außen auf, nicht umgekehrt.
Das könnte man dann nur mit Wissen über iptables wieder raus bauen und wer das rausfindet, ist hoffentlich so versiert, dass er keine Portweiterleitung macht, sondern nur für Site2Site VPN oder ähnliches braucht. (Für diese User muss man das natürlich dokumentieren und kommunizieren, bevor das Update ihm das zerbricht, bzw siehe Edit, nur wenn er Adressen außerhalb des non routable address space nutzt)
Den Portweiterleitungs-DAU sollte das aber aufhalten.

Habe ich etwas übersehen oder müsste das funktionieren?

Prinzipiell hab ich diese Möglichkeit der Einschränkung bzw. des zusätzlichen Schutzes ja bereits auf dem Schirm und hab zu den generellen Sicherheitsproblematiken rund um die CCU auch schon ein extra Enhancement Ticket bei GitHub dazu aufgemacht:

https://github.com/jens-maus/RaspberryMatic/issues/2175

Ein Punkt darunter ist genau das was du hier beschreibst/vorschlägst. Eben das beschränken der Zugriff auf Port 80/443 aus dem lokalen Netzwerk heraus. Das würde dann in der Tat den Zugriff von außen (z.B. via Port-Forwarding) entsprechend unterbinden. Man könnte das ganze dann aber natürlich noch beliebig weiterspinnen und hier ggf. sogar sich sowas wie ein Proxy ausdenken oder einführen der bei Zugriff von außen alles via HTTP Basic Auth oder so zusätzlich absichert oder einfach nur eine Alarmierung stattfindet wenn z.B. ein Zugriff von außen festgestellt wird. D.h. ich könnte etwas einbauen das im Webserver nachschaut ob Zugriff von ausserhalb des lokalen Netzwerkes stattfinden, diese dann blockiert und zusätzlich eine WebUI Alarmierung stattfindet mit dem Hinweis das der Zugriff blockiert wurde und das ggf. auf Grund eines Port-Forwarding bzw. eine zu schwachen Firewall im Router der Fall sein kann. Muss man aber halt alles auch irgendwie umsetzen, etc. und da wäre es schön wenn nicht nur ich immer hier das ganze machen müsste

[botti]

Die Angriffsvektoren der CCU gehen ja in verschiedene Richtungen. Soweit ich das alles verstanden habe sind das folgende:

- Webserver lighttpd und damit vermutlich auch indirekt TCL über XML RPC
- Die Webpage WebUI als solche
- JSON API
- Remote HM Script über Port 8181
- XML-RPC Ports 2000-2002
- Add-On Software z.B. XML-API und andere die ohne Anmeldung und Verschlüsselung funktionieren.
- Man made problems, wie offene Homematic Firewall, Autologon aktiv, keine https Umleitung, keine XML-RPC API Authentifizierung

Hab ich was vergessen?

Scheinbar ist es möglich, die Anmeldemaske zu umgehen durch einen sicherheitsrelevanten Bug in der Webpage an sich oder lighttpd, da wird ja hier ein Geheimnis drum gemacht. Der größte Vektor ist aber vermutlich die durch User selbst verursachte Dinge, wie Öffnung der Firewall und installierter add-ons. Damit kann man dann hinter die WebUI greifen. Leider fördern solche Apps wie z.B. Tinymatic so ein vorgehen. Der User klickt so lange bis es irgendwie geht. Und als letztes kommt dann noch die Portweiterleitung oben drauf; .

Deswegen wird es vermutlich einfacher sein, den Host zu schützen, wie z.B. mit IPtables, so dass man alle Endpoint der CCU erstmal zu macht. Sonst muss man ja das ganze "Ökosystem" der CCU ändern und die viele Community Feature fallen durch Raster.

Man könnte so vorgehen, dass man es dem User mit einen add-on einfacher macht, seine CCU zu veröffentlichen (z.B. mit einem reverse proxy oder IPtables). Ich glaube das beides Themen wichtig sind. Proxy für das blöde Thema Port Weiterleitung, IPtables für die interne Sicherheit.
Alle internes Services dürften nur mit dem localhost reden. Alle anderen externen Dienste müssen durch IPtables durch, am besten noch durch eine Vorauthentifizierung.
So bräuchte man auch die ganzen add-on Entwickler nicht mitnehmen und auffordern, das add-on sicherer zu machen.

Hätte man sowas und ein add-on das z.B. IPtables über eine kleine UI parametrierbar macht, so das man z.B. sagen kann: MAC/IP Adresse "x" darf nur mit "y" reden, wäre aus meiner Sicht schon viel gewonnen.

Klar, kann man dann immer noch viel falsch machen, aber mit ein paar einfach nachstellbaren Tutorials kriegt man das sicher in den Griff. Man kann die User ja nicht vor dem Leben beschützen.

[shartelt]

aber mit ein paar einfach nachstellbaren Tutorials kriegt man das sicher in den Griff. Man kann die User ja nicht vor dem Leben beschützen.

Du meinst wie sowas was ettliche Leute in ihren Signaturen verlinkt haben?
Rote große Warnhinweise in Einstellungen?

Joa...könnte man machen, verlinkst Du die dann hier bitte, eventuell nehme ich sowas in meine Signatur mit auf...
Wie das gelesen/beachtet wird, sehen wir ja jeden Tag....