Trennung der 'Multifunktions' Instanz WebFront Konfigurator und WebServer

Nachdem nun bei vielen IPS-Nutzer das neue Konzept bzgl. API für die APPs, Fernzugriff, Sicherheit der APPs und des Webserver zu verwirrung sorgt; würde ich mir eine Splittung der beteiligeten Instanzen wünschen.

Es ist für reine Nutzer, welche sich nicht Grundlegend mit dem technischen Hinergrund beschäftigen, kaum nachzuvollziehen wie jetzt was und warum zusammenhängt.

Schöner wäre es z.B. :

Webserver 1(IP-Bindung, SSL, Basis Authen für das Verzeichniss)
|
±-Fernzugriff-Instanz (User/Passwort, IP-Bereich welcher Zugriff hat, inkl. eigenen Port)
±-WebFront-Instanz (ohne Mobil, Autostart, Kennworte, WF-Konfig etc…, inkl. Port)
±-App-Instanz (inkl. Push-Benachrichtigung,inkl. Port)

Webserver 2(IP-Bindung, SSL, Basis Authen für das Verzeichniss)
|
±-WebFront-Instanz (ohne Mobil, Autostart, Kennworte, WF-Konfig etc…, inkl. Port)
±-App-Instanz (inkl. Push-Benachrichtigung,inkl. Port)

Wichtig wären m.E. auch die freie Vergabe der Ports je nach Anwendung (kann ja ab Werk alles gleich sein).
Wenn ich den Fernzugriff nicht von außerhalb meines LAN nutzen will, das WF aber schon…

Und auch die Zuordnung von mehreren WebServer Instanzen zu den ‚Untergeräten‘ wäre super.
So kann z.B. auf einem anderen Port bzw IP ein WF laufen (und auch nur eins angezeigt werden in der Auswahl!) welches z.B. Gäste nutzen können. Oder oder oder…

Zumindest wären dann sehr viele Einschränkungen und ‚Sicherheitsprobleme‘ durch falsche/fehlerhafte Konfiguration gelöst.

Michael

Dein Vorschlag bringt doch, wenn ich ihn richtig verstehe, noch eine weitere Verknüpfungsebene mit, über die man einzelne WFCs auf WebServer verteilen kann. Das finde ich ehrlich gesagt noch komplizierter. Oder habe ich es falsch verstanden?

paresy

Höchstens dahingehend das die WF dann auch einen Parent (Webserver) hätten.
Aber wie ist das denn jetzt intern gelöst ? Igendwie hängen doch schon der WebServer und die WF-Konfig zusammen.
Nur so das es halt für die User teilweise nicht nachzuvollziehen ist wie jetzt was sich auswirkt.
Gerade in Anbetracht der Sicherheit (SSL vs. WF-Passwort) wäre hier ein nachvollziehbares System wichtig.

Michael

Ich würde mir wünschen wenn hier doch noch mal über eine Änderung nachgedacht wird.

Stehe aktuell vor dem Problem Sicherheitslücke vs. Komfort (Klar geht Sicherheit vor :smiley: ).
Der Zugriff auf mein WebFront läuft sowohl von extern als auch intern über einen Revese-Proxy.
Somit wird immer das Kennwort abgefragt, egal ob der eigentliche Client über LAN oder aus dem WAN zugreift.
Die Option ‚Erfordere Passwort nur bei externen Verbindungen‘ funktioniert im diesem Kontext ja nicht.

Der Reverse-Proxy weiß sehr wohl ob der Client extern oder intern ist.
Also hatte ich überlegt den Proxy über zwei verschiedene Ports (zwei Webserver-Instanzen) an IPS zu binden.
Geht nicht da ich nicht zuordnen kann an welcher Webserver-Instanz welches WebFront hängt; und dort ja erst die Kennwort & Autostart Regeln definiert werden.

Michael

Auch wenn es an der Stelle Off-Topic ist, würde ich Externe Zugriffe auf die Steuerung nicht ohne einen adäquaten VPN Tunnel gestatten. Der Reverse Proxy mit Passwort, wenn er kein SSL macht, bringt dir Sicherheitstechnisch nichts. Ich tunnel beispielsweise externe Zugriffe auf IPS via OpenVPN mit starker Verschlüsselung, auch vom Smartphone aus. Externe Schnittstellen (bspw. Geofency) auf IPS laufen bei mir über einen Reverse Proxy welcher Zentral mit SSL abgesichert ist und nur auf bestimmte Bereiche von IPS zugreifen kann (es laufen noch andere Services hinter, auf anderen Servern in der DMZ, da macht ein Zentrales SSL Zertifkat Sinn). SSL alleine wäre mir zu heiß, die Schwachstelle bildet dann immernoch der Auth, welchen man mit ausreichend Zeit, Bandbreite, guten Rainbow Tables und Glück überwinden kann. Eventuell erledigt sich die Anfrage dann.

Daniel

Wo steht denn das der Proxy kein SSL macht :wink:
Ich glaube kaum das sich jemand so sehr für mein Webfront interessiert und diesen Aufwand zu betreiben.
Michael

Du, das denken sooo viele, und jedes Jahr auf dem Chaos Congress sieht man Dinge die quasi sperrangelweit Offen stehen, sodass man es nicht glaubt. Das Interesse ist nicht gezielt, aber wenn man drüber stolpert…

Wie gesagt, ICH würde es nicht tun, da ich so ein kleines bisschen damit Erfahrung habe :slight_smile:

War nur ein gut gemeinter Rat.

Daniel

Es ging hier nicht um eine Grundsatzdisskusion von Do & Do not.
Sondern darum mehr Transparenz zu schaffen, gerade für nicht so versierte Nutzer bei Netzwerktechniken.
Und ich glaube ich weiß schon was ich mache und das Risiko zu beurteilen.
Außerdem ist der ganze Part von IPS mit Webserver, Webfront etc… die einzigen Instanzen wo es keine Erkennbare 1:n sondern eine n:m Struktur gibt.
Michael

Wenn dein ReverseProxy uns diese Information (Stichwort: X-Forwarded-For oder X-Forwarded-For) weiterleitet, werten wir diese auch aus. D.h. du kannst trotz ReverseProxy die „Benötige kein Kennwort im LAN“ benutzen.

paresy

Sondern darum mehr Transparenz zu schaffen, gerade für nicht so versierte Nutzer bei Netzwerktechniken.

Genau das ist auch mein Problem. Meine Netzwerkkenntnisse sind auch recht beschränkt.
Ich bin damals auch über die Falle gestolpert, dass mein WebFront auf einmal komplett frei zugänglich war.
Thema Basis Authentifizierung …
Ich habe es bis heute nicht wirklich durchschaut, was ich wo und von allem wie absichern kann.

René

@paresy
Ich schau heute abend noch mal nach.
Ich meine das wird übertragen.
Nur was der Inhalt war… öhmm
War wohl zu viel ‚Lübeck Ahoi‘ in der 5. Jahreszeit. :smiley:
Michael

Ist ja gut, beruhig dich. Habe es nur gut gemeint. Am Ende ist es eh deine Verantwortung und dein mögliches Problem.

Und genau aus diesem Grund habe ich es gesagt. Wir haben zumindest dann einmal im Jahr großen Spaß, wegen unversiertem und gedankenlosen Weiterleiten von Ports auf Services. :cool:
Aber gut, mehr sage ich zu diesem Thema nicht mehr, weilMichael Recht hat, es geht um etwas anderes hier.

Sorry den Thread gekapert zu haben!

Daniel

So habe extra noch mal nach gesehen.
Problem wie hier beschrieben:
IP-Symcon Community Forum

‚X-Forwarded-For‘ enthält die IPv6 des Client und da will IPs wohl immer ein Passwort :frowning:

Es geht nur wenn ich im DNS den AAAA-Eintrag des Proxy lösche, weil dann muss der Client ja über IPv4 an den Proxy gehen und ‚X-Forwarded-For‘ enthält die IPv4-Adresse. (Der Proxy ist sowohl extern als auch intern über IPv4 & IPv6 erreichbar.)

Dann will IPs auch kein Kennwort (so wie es sein soll).
Und eine Prüfung ob Client und IPS-Server das gleiche IPv6-Präfix haben ist ja noch nicht implementiert, oder ?

Darum ja mein Wunsch ein WF an einen WebServer zu binden.
Dann könnte man die Option ‚Benötige kein Kennwort im LAN‘ komplett einsparen.
Einfach ein Webserver auf Port_A mit WebFront ohne Kennwort. Und ein zweiten WebServer auf Port_B mit WebFront mit Kennwort.
Zweite Instanz wäre dann auch die, welche später über Connect erreichbar sein könnte…

Ich habe mich doch gar nicht aufgeregt, wieso soll ich mich beruhigen :wink:

Michael