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)
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.
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.
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…)
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?
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?
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.
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.
Eben zufällig festgestellt, dass ein einmal im WFC registriertes Mobile-Gerät drin bleibt und Push-Nachrichten erhält, unabhängig davon, ob ein Passwort gesetzt oder verändert wurde (IPS V #3426).
KTritt dann auf, wenn man (unwissend/irrtümlich) kein PW im WFC gesetzt hat und sich jemand mit der App auf das WFC geschaltet hat.
Dazu gibt es bis heute (trotz der Diskussionen hier im Thread) keine Erwähnung der Risiken der Fehlkonfiguration in der Doku, im WFC und im WebServer-Modul stehen missverständliche Aussagen drin (Beispiel Webserver/Konfiguration: „Basisauthentifizierung nicht für Webfront/Webserver verwenden“, darunter die Checkbox „Benutze Authentifizierung“)
das ist schon immer so gewesen. Nur hast du seit Version 3.1 die Kontrolle innerhalb der Konsole wer Push-Nachrichten empfängt. Vorher konnte nur jeder selber in der App diese ausschalten. Meines Erachtens ist das ein erhebliche Verbesserung zur Sicherheit und Administrierbarkeit.
Dass eine Registrierung für Push-Nachrichten von einem Kennwortwechsel des Konfigurators unbetroffen bleibt, halte ich für korrekt. Du hast im Reiter „Benachrichtigungen“ jederzeit die vollständige Kontrolle. Wenn du vergisst ein Kennwort zu setzen, hast du meines Erachtens die Pflicht zu schauen, ob sich dort jemand registriert hat. Falls ihr anderer Meinung seid, können wir dort gerne etwas verbessern.
paresy
PS: Ich werde in die Konsole gerne noch einen Hinweis einbauen, dass beim Deaktivieren des Mobil-Zugriffs der Empfang von Push-Nachrichten unabhängig davon deaktiviert werden muss. Und du hast Recht dass dieser „Fallstick“ einen Satz in der Doku verdient hätte.
bei allem Respekt: „…das ist schon immer so gewesen“ kann doch nicht Euer Ernst sein???
Natürlich bin ich als Admin für mein System verantwortlich. Aber wenn ich nicht alle Abhängigkeiten kenne, weil es auch die Doku verschweigt, kann man es sich nicht so einfach machen und alles auf den User abwälzen.
Ich finden den Umgang mit sicherheitsrelevanten Themen in IP-Symcon sehr bedenklich. Ich würde mir wünschen, dass diese Themen sorgsamer und engagierter behandelt würden.
Mein zwischenzeitlich wiedererstarktes Vertrauen ist mal wieder erschüttert. Ich frage mich, auf welche „Baustellen“ wir in Zukunft hoffen dürfen, die „schon immer so waren…“, aber kein Entwickler zu beschreiben wagte…
Warum müssen User immer wieder sehenden Auges gegen die Wand fahren, bis sich was tut (Stichwort: Doku?!?)?
Ich frage mal anders: Hast du eine Idee wie man es besser, einfacher und intuitiver machen kann? Das ist meines Erachtens immer die bessere Lösung als jeden Fallstrick zu dokumentieren. Hab mir aber ein Ticket für die Doku Verbesserung eingerichtet, damit ich einige Sätze zu den möglichen Problem der WebFront Konfiguration schreibe. Ich habe den Bedarf da in der Tat unterschätzt.
Ich hatte dir , als die erste Diskussion in diesem Thread aufkam, ein paar Mails mit Vorschlägen geschickt.
Ich such das bei Gelegenheit nochmal raus.
Und vielleicht meine Sicht nochmal mit etwas niedrigerer Tonlage beschrieben:
Dass solche Dinge passieren, ist m.E. vollkommen normal. Nur entsteht bei mir (und nicht nur bei mir) der Eindruck, als würden diese Hinweise, Warnungen, Vorschläge -aus welchen Gründen auch immer - ignoriert. Manchmal nicht mal das.
Und ich hab auch schon Usermeinungen gehört, die aus diesem Verhalten Arroganz ableiten. Ich persönlich weiß, dass es nicht so ist.
Aber mit etwas mehr Dialogbereitschaft (und konsequenterer Umsetzung) - noch dazu bei solch sensiblen Themen - gäbe es wesentlich weniger Reibung, dafür immens mehr Reputation… Und das ohne große Mühen.
es gibt ja zu diesem Thema einige Threads. Ich habe in einem gelsen, dass in Version 3.3 die Sicherheitsprobleme behoben wurden. Kann ich nun bedenkenlos die Basis-Auth. deaktivieren (Sicherheit IP-Symcon :: Automatisierungssoftware), wenn ich in der Konfigurator-Instanz des jeweiligen Webfront Konfigurator unter Sicherheit ein Kennwort vergeben habe?
@RS - falls es hier zu einer klaren Aussagen kommen sollte, wäre super, wenn du auch deinen Blog-Eintrag aktualisierst - dein Blog ist denke ich ein großer Infoverteiler
Die Frage ist doch, warum willst du sie deaktivieren ? Treten Probleme auf ?
Sie schützt (wenn der Webserver auf den Ordner Webfront zeigt) doch eh nur noch den User Unterordner, und nicht das Webfront.
Michael
