passwort Abfrage webserver?

Hallo,

ich habe bei der Authentifizierung ein Problem bzw hab ich da was falsch konfiguriert:
Ich habe einen Webserver auf Port 443 angelegt, mit SSL verschlüsselung und Authentifizierung. Weiters hab ich noch das Webfront auf Port 82 ohne Passwortabfrage. Im Router hab ich das Port 443 freigegeben, das auf den IPS Server Port 443 weitergeleitet wird.
bis jetzt dachte ich, dass das wunderbar funktioniert. Intern konnte ich ohne Password auf Port 82 zugreifen, und extern hat er immer nach dem Password gefragt (egal ob browser oder ifront).

Nun hab ich die neue Version der IOS App installiert, und ich komme von Außen ohne Password auf Port 443 auf mein IPS! :confused:

Das versteh ich jetzt nicht ganz, wieso dass ohne Password funktioniert

gruß garfi

Kann ich bestätigen. Ist mir gestern aufgefallen, bei Androidapp gibt es nicht mal mehr die Abfrage " Standard Authentifizierung benutzen". War geschockt als mein Sohn mir sagte er kommt mit den App`s ohne PW rein. :eek:

Beim einloggen über FF oder Chrome von Außerhalb werde ich nach Benutzer und PW gefragt.

Kennwörter wurden schon immer über den WebFront Konfigurator eingerichtet. Pro WebFront kann ein Kennwort vergeben werden. Dort ist auch die Option vorhanden, dass im internen Netzwerk keine Kennwörter erfordert werden.

paresy

Ja das ist klar, habe es auch im WFC so eingerichtet (schon immer so) nur wenn ich die App installiere (auch von Unterwegs über dyndns) kann ich sofort drauf zugreifen ohne das nach einem Benutzer oder PW gefragt wird.

Im WFC ist Benutzer und PW eingerichtet, und musste bis dato im App immer eine Benutzer und PW eingeben. Nur jetzt nicht mehr.

Für was gibt es dann die Basis Authentifizierung?
Da könnte dann ein Hinweis sein, dass das für nichts ist. Wird zwar im Browser abgefragt, man kann aber auch ohne Passwort rein.

Eben noch mal getestet, komplett alles gelöscht. Dann neu installiert DYNDNS Adresse eingegeben und siehe da Zugriff ohne PW.

Wenn jemanden der dyndns bekannt ist und dieser nur die Basis-Authentifizierung hat ist er offen wie ein Scheunentor. Hier hilft nur ein wenig das Kennwort für den Editor.

Sent from my iPhone using Tapatalk

Ok das wusste ich nicht, ich hab irgendwann mal das mit ssl und Basis-Authentifizierung eingestellt, in der Meinung das wäre halbwegs sicher. Dann stell ich halt wieder auf VPN um, und lass kein port extern offen.

gruß garfi

@Werner

Hier hilft nur ein wenig das Kennwort für den Editor.

Klar ist das ne Möglichkeit, aber auch blödsinnig. Für was haben wir denn die Basis Authentifizierung:confused:
Vor allem muss ich dann ja jedesmal wenn ich die App öffne das PW eintragen:mad:

Dafür gibt es doch den OK & Speichern button?

paresy

@Paresy

ja habe es eben getestet, funktioniert. Aber trotzdem Blödsinn. Vor allem wenn man nichts davon weis. Eine Wichtige Sache
wie das, einfach so zu ändern ohne es mitzuteilen ist schon der Hammer. Kann doch nicht sein das man jedesmal nach einem Update alle Sicherheiten überprüfen muss. Ist so schon schlimm genug was man alles machen muss wenn es denn ein Update gibt.

Bei mir läuft grad der interne Kessel Gefahr, zu platzen!

Jeder verantwortungsvolle und professionelle Softwarehersteller gibt sofort ne Warnung an alle User raus, wenn eine schwere Sicherheitslücke entdeckt wurde. Und er erklärt den Usern auch, was zu tun ist, um (weiteren) Schaden zu vermeiden.
Und zwar sofort.
Und er setzt dieses Thema sofort auf Pio 0, um das Problem zu lösen. Und dann informiert er sofort alle User a) dass das Problem gefixt wurde und b) was der user zu tun hat, um das Thema bei sich zu lösen.

Sorry, aber so wie hier mit diesem Thema umgegangen wird, scheint mir das Ausmaß des Problems nicht begriffen worden zu sein.

PS: ich hab vorhin meine WFE’s auf Grund dieses Threads für mobile Darstellung deaktiviert (mit Basis-Authentifizierung auf Port 443). Sekunden später bekam ich von einem - nennen wir ihn plakativ „Angreifer“ - folgenden Screenshot:

Der Screenshot ist doch genau das, was passieren soll. Es gibt eine Auflistung der WebFronts und diese sind deaktiviert. Du hast keinerlei Zugriff darauf. Es gibt keinerlei Sicherheitslücke. Ein WebFront ohne Passwort ist auch ein WebFront ohne Passwort.

Die Auflistung, die keinem wehtut, zeigt dem User der das WebFront nicht für Mobil konfiguriert hat, dass es korrekt vorhanden ist, aber eben noch nicht für die Mobile-Apps konfiguriert wurde.

Wenn du die WebFront Konfigurator Instanz versteckst, dann wird diese auch nicht in der Liste angezeigt.

paresy

Wenn die Basis-Authentifizierung aktiv ist (und das ist sie grundsätzlich bei mir), dürfte ich erst gar nicht bis zur Liste der WFE’s kommen, weil vorher User und PW abgefragt wird. Im Browser ist es ja schon ewig so.
M.E. ist das ein erhebliches problem, falls man im dedizierten WFC nicht zusätzlich noch ein PW gesetzt hat (was bei mir der Fall ist).
Ich hatte das aber früher nie gemacht, und ich kann mir gut vorstellen,dass es jetzt noch reichlich User gibt, die sich - mit Recht - auf die Basis-Authentifizierung verlassen. Wenn das kein Sicherheitsproblem ist…

Hallo, habe noch eine Bitte zur Angabe des Internen Netzwerks. Dort kann ja ein Subnetz anfegeben werden. Nun würde ich dort gerne auch meine Dyn-DNS Adresse angeben können. Grund ist der, dass ich meine Firewall so konfiguriert habe, dass ich Zuhause auch immer mit der Dyn-DNS Adresse auf die Webseite zugreife. Jedoch werde ich immer nach dem Passwort gefragt.
Gewünscht ist nun, in den Dialog für das interne Netzwerk die Dyn-DNS Adresse eintragen zu können, sodass diese dann auch nicht nach dem Passwort frägt.
Eintrag kann ich diese jetzt schon, jedoch ohne Erfolg.

Grüße Florian

Uwe.

Das war nicht als „die Lösung“ gedacht sondern als Notlösung.

Mir gefällt das genau so wenig wie allen Anderen…

Man stelle sich vor es nutzt jemand den IPS-Webserver noch für andere Dinge als das Mobile…

…wer weiß wie sicher der Server dann noch ist.

Ich habe die Befürchtung das das eine gemeine Sicherheitslücke ist. Wenn die mobilen Versionen ohne Basis-Authentifizierung rein kommen was dann noch?

@paresy…Ist es wirklich so kompliziert den alten Sicherheitsstandard wieder herzustellen?

Mag alles nur subjektiv sein, aber es haben viele hier Bauchschmerzen damit.

Sent from my iPad using Tapatalk.

Liebe IP-Symcon Entwickler,

ich bin erst über die Seite des geschätzten IPS Users Raketenschnecke auf dieses Thema gestoßen.
Mir ist ehrlich gesagt der Kitt aus der Brille gefallen. Wenn ich bei einem Webservice die Basis Authentifizierung aktiviere war ich bisher der Ansicht, dass die selbige bei jeder Web-Anfrage auch durchgeführt wird. Eure neue Mobil App kommt aber ohne Basic Authentifizierungs Hürde an das Webfront. (http://www.ip-symcon.de/forum/threads/24532-passwort-Abfrage-webserver)

Der Mechanismus, wie die Mobile App es umgeht, lässt sich mit einem Network Sniffer ermitteln. Und was dann?

Bitte nehmt zur Kenntnis, dass manche User neben IPS auch andere Webkomponenten verwenden.
Ich nutze z.B. einen Reverse Proxy um mit verschiedenen Hostnamen auf meine internen Webserver zuzugreifen. Durch den Reverse Proxy kann ich leider auch nicht die Funktion „Erfordere Password nur bei externen Zugriff (Internet)“ nutzen, da ihr „X-Forwarded-For“ für diese Funktion nicht auswertet und der Reverse Proxy aufgrund der IP als Internes Device betrachtet wird.
Ich kann in meinem Setup dieses Sicherheitsproblem nur mit ein Password für alle WebFront Zugriffe (Intern & Extern) oder durch komplette deaktivieren des IPS-Remotezugriffs lösen.

Hallo Leute, so könnt Ihr dass nicht lassen! Das ist Eurer IPS Heartbleed!

Ich hab es mal in das andere Thema geschoben. Ich muss dir leider unrecht geben. Nur weil du dir mit deinem Reverse-Proxy ein Loch in unsere Sicherheitsmechanismen machen kannst, hat IP-Symcon noch lange keine Sicherheitslücke. Das ist, als wenn du behauptest, dass OpenSSL unsicher ist, weil du nach Heartbleed kein neues Zertifikat beantragt hast.

Die App umgeht nichts. Wirf bitte den Sniffer an, bevor du plakativ mutmaßt und leider daneben liegst.

Seit IP-Symcon 3.0/3.1 gibt es die JSON-RPC API. Dessen Authentifizierung erfolgt über den Fernzugriff. Der WebFront Teil der JSON-RPC API erfolgt über den jeweiligen WebFront Konfigurator. Die Sicherheit ist vollständig gegeben und ist seit IP-Symcon 3.0 genau so realisiert. Raketenschnecke hat sicherlich ein Sonderfall gefunden, der bei entsprechender Misskonfiguration eine Sicherheitslücke darstellt - Diesen gibt es dann aber bereits seit mindestens 3.0 und der Hinweis im WebServer, dass die Basis Authentifizierung nicht für WebFronts verwendet werden soll, ist anscheinend völlig unberücksichtigt worden.

paresy

Bild 10.png

Anbei noch eine Kopie des Textes, der demnächst im Entwicklerbereich der JSON-RPC Doku stehen wird. Vielleicht hilft es ja dem einen oder anderen das Sicherheitskonzept dahinter zu verstehen. Fragen dazu sind jederzeit erwünscht.

Die seit IP-Symcon 3.0 verfügbare JSON-RPC API ist standardmäßig über den Port 3777 erreichbar. Dabei ist der Port 3777 nur am lokalen System gebunden und erfordert keinerlei Authentifizierung. Weiterhin ist die JSON-RPC API auf jedem in IP-Symcon eingerichteten WebServer aktiv. Dadurch können auf jeder Host/Port/SSL Konfiguration das WebFront und die Mobilen Apps einen Zugriff zu IP-Symcon bekommen. Die JSON-RPC API wird über den Lizenz-Benutzernamen und das ++Fernzugriff++ Kennwort authentifiziert. Wenn kein Kennwort angegeben wird, so wird keinerlei Zugriff gewährt. Ein Sonderfall sind einige WFC_* Funktionen, welche über das Kennwort des jeweiligen WebFront-Konfigurators authentifiziert werden. In diesem Fall wird als Benutzername ‚webfront‘ verwendet. Diese Funktionen ermöglichen den isolierten Zugriff auf die vom Konfigurator definierten Teilbereiche des Objektbaums. Ausschließlich die WFC_GetConfigurators Funktion wird ohne jegliche Authentifizierung zur Verfügung gestellt. Diese ist erforderlich, um die Auflistung der WebFront-Konfiguratoren für das WebFront und die Mobilen Apps zu ermöglichen. Zusätzlich wird dadurch die IP-Adressen Autostart Funktion realisiert. Übertragen werden in dieser Funktion nur die ID/Titel/Icon/Position/Editierbarkeit des jeweiligen Konfigurators, ob ein Kennwort erforderlich ist und ob dieser Konfigurator für die Mobile Apps aktiviert wurde. Standardmäßig ist die Nutzung für Mobile Apps im Konfigurator deaktiviert, um ein Sicherheitsproblem auf den Basis-Baum (ID = 0) zu vermeiden. Die im WebServer angebotene Basis-Authentifizierung gilt für alle Inhalte, die innerhalb des WebServer-Verzeichnisses liegen (z.B. alle HTML, JavaScript und Bild-Dateien) - jedoch nicht für die JSON-RPC API, da diese den vorher genannten Authentifizierungsregeln unterliegt.

paresy

Servus paresy

der Text, bzw. die Sicherheitsregeln sollten noch in einer „Endkundentauglichen“ Variante an prominenter Stelle verfügbar sein.
Also für jemanden geschrieben sein der grad mal im Router Ports forwarden kann.
Ein kurz und bündiges Do &Dont.

gruß
bb