Seh ich auch so. Wollte grad etwas Ähnliches schreiben
Toni
Werde ich noch einmal probieren das zu formulieren. Ich werde auch noch intern absprechen, wie wir den Hinweis, dass ein WebFront ohne Kennwort im Konfigurator völlig offen ist, irgendwie im nächsten Newsletter unterbringen können. Die Basis Authentifizierung sichert nur die Dateien ab, die das WebFront darstellen (also wie geschrieben HTML, JavaScript…)
paresy
Ok, Heartbleed war ein unpassender Vergleich. Bei dem Reverse Proxy muss ich aber wiedersprechen. Zum einem wird dadurch der interne Webserver nicht direkt kontaktiert und zum anderen ist dies die einzige Möglichkeit hinter einer einzigen öffentlichen IP mehrere Webservice zu betreiben. HTTPS Traffic auf Port 443 wird per Wildcard Zertifikat am Reverse Proxy terminiert und als HTTP ins interne Netz weitergeleitet. Basierend auf dem Hostnamen ips.meinedomain.de, webcam1.meinedomain.de usw. kann ich dann zu unterschiedlichen Webservern verzweigen. Ich denke das viele User genau dieses Scenario einsetzen. (z.B. Sophos UTM Private Edition)
Habe ich gemacht.
Browser URL:
https://ips.meinedomain.de:443 geht per Reverse Proxy intern auf http://ip-symcon-ip:82/ und ich bekomme eine Basic Authentication Anforderung. -> ok
Alte Android App:
https://ips.meinedomain.de:443 geht per Reverse Proxy intern auf http://ip-symcon-ip:82/data/ios.php und ich bekomme eine Basic Authentication. -> ok
Neue Android App:
https://ips.meinedomain.de:443 geht per Reverse Proxy intern auf http://ip-symcon-ip:82/api/ und ich bekomme keine
Authentication und das ist nicht gut!
Die JSON-RPC API ist doch über ein Kennwort geschützt. Wieso kann ich mit der neuen Mobile App nur über https://ips.meinedomain.de:443 auf mein IPS ohne irgendein Password zugreifen?
Ich möchte nicht ausschliessen, dass es vorher auch schon so ging, aber mit der neuen App ist dieser Zustand aufgefallen. (glücklicherweise!)
Also, was ist falsch an meiner Konfiguration bzw. meinem Konzept HTTPS an Reverse Proxy der Sophos UTM zu terminieren und intern als HTTP weiterzuleiten?
Hallo Paresy,
ich denke nun verstanden zu haben, dass zukünftig der Zugriffsschutz am Password des WebFront Configurators hängt und nicht mehr an der Basic Authentication des Webservers. Ich habe auch keine Probleme mit diesem Konzept.
Der einzige Kritikpunkt wäre die Erkennung des externen Zugriff. Ein Reverse Proxy hat eine interne IP und kann daher von IPS nicht als externer Zugriff erkannt werden.
Es sollte doch aber ohne grossen Aufwand möglich sein, dem WebFront Configurator eine Konfigurationsmöglichkeit für interne IP-Adressen mit erzwungenem Passwordschutz vorzusehen.
Optisch könnte das wie folgende Fotomontage aussehen:
Würdest Du sowas einbauen?
Wir werten den X-Forwarded-For Header dafür aus. Sendet dein Proxy dem korrekt?
paresy
Hallo, die gleiche Anfrage hatte ich auch schon in die Gegenrichtung. D. H. auch wenn ich zu Hause bin, greife ich mit der externen IP Adresse auf die Webseite zu.
Leider muss ich mich immer anmelden.
Für mich wäre es hier eine Lösung, wenn man den Namen der Dyn-DNS in der Liste der internen IPs aufnehmen könnte.
Wäre es möglich, das in IPSymcon aufzunehmen?
Florian
Der Reverse Proxy in der Sophos UTM nutzt HTTP_X_FORWARDED_FOR. Für mich wäre das schon OK.
Hi,
das Problem mit der Erkennung eines Externen Zugriff über einen Reverse Proxy ist mit der Auswertung des „HTTP_X_FORWARDED_FOR“ Headers in der neuen IPS Beta erledigt.
Es verbleibt für mich jetzt noch ein kleines Verständnisproblem:
Ich kann einen WebService für das webfront Verzeichnis nicht ohne Basis Authentifizierung ins Internet hängen wie z.B. die Demo von IPS: http://www.webfront.info
Warum?
Weil dadurch sämtliche Inhalte in und unter dem WebFront Verzeichnis ungeschützt sind. Wenn ich den Namen und Pfad einer Resource kenne, kann ich sie direkt aufrufen z.B.: http://www.webfront.info/img/dwd.svg
Viele beliebte Scripts aus dem Forum nutzen /webfront/user/ zur Datenaufbereitung. Dort finden sich z.B. RSDB_Analyzer.html oder IPSCam\ImageCurrent.jpg. Das sind alles Informationen die ich ungerne unauthorisierten Leuten zeigen möchte.
Also „Basic Authentication“ einschalten!
Aber wie kommt dann die neue Mobile App an diese Daten, wenn ich z.B. eine HTML Tabelle mit aufbereiteten Daten anzeigen will? Ich kann in der App keine Basic Authentifizierung mehr konfigurieren. 
Der zweite unschöne Aspekt ist die dann erforderliche doppelte Authentifizierung für die Nutzung des WebFront. Ich muss mich erst an der Basic Authentifizierung anmelden und dann nochmal am WebFront, da ich dieses wegen der API nicht mehr Passwortfrei lassen kann. (Ok, für diesen Punkt war die Auswertung von „HTTP_X_FORWARDED_FOR“ kontraproduktiv)
Kann ich/man das nicht besser lösen?
Wir werden die Apps aktualisieren, sodass bei einer aktivierten Basis Authentifizierung die App diese auch korrekt handhaben kann.
paresy
Peinlich… Jetzt geht der Newsletter raus und die Passage für das Konfigurator Kennwort fehlt 
Will nur kurz Bescheid geben, dass wir nach dem Wochenende einen weiteren Newsletter aufsetzen werden der diese Problematik aufgreift. Bis dahin ist vielleicht auch das HighCharts + Basis Authentifizierung Problem gelöst.
paresy
Hallo Heimgeist,
Ich verstehe den Ärger und verstehe die Sache nach ein mal lesen auch nicht komplett (obwohl ich vom Fach bin).
Aber wie ich merke hab ich wohl auch kein Problem, denn mein Reverse Proxy ist SSL-Endpunkt, übernimmt die Authentifizierung und reagiert sowieso nur auf ein speziellen Host-Header.
Vielleicht hilft das dem ein oder anderen - Beispiel-Config für nginx kann ich bei Bedarf gerne posten.
Grüsse, Axel
Gesendet von meinem iPhone mit Tapatalk
Hallo Axel,
die Auswertung für „X-Forwarded-For“ hat Paresy in der neuen IPS Beta bereits implementiert. nginx kann ja auch die reale Client-IP über diese Variable weiterreichen. „REMOTE_HOST“ hat dann die interne IP des reverse Proxy und in „HTTP_X_FORWARDED_FOR“ steht dann die externe (Internet) IP des anfragenden Clients. Wenn diese Variable gefüllt ist nutzt IPS zur Unterscheidung Intern/Extern diese IP.
Wenn Du auch nginx auch zur Authentifizierung verwendest brauchst Du natürlich die IPS interne Authentifizierung nicht. Allerdings musst Du für /api/ eine entsprechende Ausnahmen definieren. Wenn du z.b. auf /api/ eine Basic Authentifizierung über nginx aktivierst, wirst Du bei externen Zugriffen vor die Wand laufen.
/api/ nutzt, wie ich in diesem Thread jetzt gelernt habe, eine eigene Authentifizierung mit dem user „webfront“ und Password des WebFront Configurators bzw. den Lizenz-Benutzernamen mit dem dort gewählten PW.
Ich bin momentan noch in der „Findungsphase“ wie ich zukünftig den externen IPS Zugriff realisiere.
Da ich auch nur HTTPS:443 Zugriffe aus dem Internet zulasse und es am Reverse Proxy ohne passenden Hostheader und passender Subdomain nicht weitergeht, habe ich keine Probleme bei Netzwerksniffern aus dem Internet.
Das Passwort des WebFront Configurators wäre ohne Basic Authentication dann eigentlich ausreichend. Ich würde ohne aktivierte Basic Authentifizierung dann allerdings die Webfront-Resourcenamen und Pfade von Scripten aus dem Forum ändern, damit man nicht mit meinem IPS Hostnamen durch Anhängen des entsprechenden (bekannten) Pfades und Dateinamen an den Inhalt kommt.
Also ich mit der auswertung des HTTP_X_FORWARDED_FOR super zufrieden.
Bei mir ist es ein Indianer welcher ReversProxy spielt. Und somit ist der Funktionswunsche, welchen ich vor über einem Jahre schon mal gestellt hatte, endlich wirklichkeit 
(Welchen ich nicht mehr wiederfinde…)
Danke dafür.
Michael
Ich hänge mich hier mal mit dran.
Ich haben im Webfrontend unter Sicherheit ein Passwort definiert. Für die mobile App funktioniert das auch, intern funktioniert es auch, da es dort nicht abgefragt wird.
Will ich nun mit dem Browser von extern auf mein Webfront zugreifen, so kann ich das Passwort ewig eingeben, ich komme nicht rein. Selbst wenn ich ein einfaches Kennwort, ohne Sonderzeichen verwende, funktioniert es nicht.
Ich habe zwar den Webserver an sich nochmal mit Benutzername und Passwort abgesichert, aber das sollte ja keinen Einfluss haben.
Was mache ich denn falsch?
Gruß Daniel
Ich habe zwar den Webserver an sich nochmal mit Benutzername und Passwort abgesichert, aber das sollte ja keinen Einfluss haben.
Doch, tut es. Nur der Chrome unterstützt diese doppelte Absicherung.
paresy
paresy, auf grund des letzten Statements verstehe ich das Konzept dann jetzt doch nicht. Bitte nochmal für Dummies.
Ich dachte die Basis-Auth sollte ich aktivieren, um meine Skripte im webfront/user-Verzeichnis zu schützen.
Lasse ich aber die Kennwörter für die Webfronts weg, sind meine Webfronts/MobileApps offen wie ein Scheunentor (wegen der neuen API).
Aktiviere ich nun aber beide Sicherheitsmechanismen zusammen, komme ich nur noch mit Chrome aufs Webfront. Das ist doch… hmmm… Quatsch? 
Kommt hier noch etwas?
In dem gerade versendeten Newsletter wurde nun auf die erforderliche Konfiguration hingewiesen.
Hi,
vielen Dank für den Hinweis im Newsletter.
Leider adressiert das immer noch nicht meinen zuletzt genannten Hinweis:
-In der aktuellen Version werde ich aus Sicherheitsgründen „gezwungen“ die Webfronts mit Passwort zu schützen (siehe Newsletter)
-damit ich die Webfronts dann aber noch im IE, Firefox etc. aufrufen kann, MUSS ich die Basis-Authentifizierung ABSCHALTEN
-somit liegen alle meine Skripte im Webserver-Verzeichnis wie hinter 'nem offenen Scheunentor. Kritisch sind z.B. GeofencyInfo oder auch alle anderen Skripte die von extern angetriggert werden um irgendeine Aktion in IPS auszulösen.
Hallo zusammen,
also ich komme eigtl. aus der Softwareentwicklungsecke und betreibe auch nebenher ein Netzwerk mit einem SBS incl. Exchange Server. Ein wenig kenne ich mich in der Technik schon aus, auch wenn ich es nicht so kompliziert mit Reverse-Proxy mache und auch nicht in der Web-Entwicklung zuhause bin. Trotzdem beunruhigt mich dieser Thread schon etwas, weil ich das Gefühl bekomme, ein System zu betreiben, das nach außen offen wie ein Scheunentor ist und nur ich durch irgendwelche Passwörter in der Benutzung und Entwicklung ausgebremst werde, aber jeder der sich in dem Thema auskennt geradezu durchspaziert.
Ihr seht vlt. an meiner Beschreibung, dass ich kein Freak bin und mich eigtl. schon darauf verlasse, dass ihr, die diese tollen Tools programmiert, für meine Datensicherheit sorgt bzw. mir deutlich macht, was ich tun muss, um diese Sicherheit zu erlangen.
Ich denke auch, dass IPS eigentlich auch für solche Leute interessant sein sollte, die technisch noch unbelesener sind als ich und dafür wäre es aus meiner Sicht erforderlich ist, allen eine Beschreibung zu Verfügung zu stellen, die jeder versteht und umsetzen kann.
Sollte dies inzwischen existieren und ich habe es nur verpasst oder übersehen, bitte ich das zu entschuldigen.
Grüße chrissiboy