Hi,
mir bereitet im derzeitigen IPS4-Konzept die Sicherheit noch etwas Bauchschmerzen.
Meine Webserver-Instanz über die ich auf die WebFronts (und per App) zugreife, läuft auf einem Port der nur innerhalb meines Netzes erreichbar ist. Das soll auch so bleiben - sorry, auch den Connect-Dienst möchte ich nicht nutzen (trotzdem Daumen hoch für die Entwicklung!).
Für einige Spezialfälle wie z.B. Geofency brauche ich aber externe Webhook-Aufrufe - dies habe ich mit der IPS3.x über eine zweite Webserver-Instanz auf anderem Port gemacht, welcher in der Firewall nach außen freigegeben ist. Für diesen zweiten Webserver Basis-Auth aktiviert, separates webfront-verzeichnis, fertig.
Die neue Webhook-Funktion in IPS4 finde ich super! Leider kann ich die o.g. Sicherheiten damit aber nicht umsetzen.
Entweder müsste das Webhook-Control es erlauben, einen separaten Port anzugeben (und somit völlig abgesetzt von den Webserver-Instanzen arbeiten) oder die Webserver-Instanz müsste wieder wie früher abzuschotten sein. Derzeit kann ich ja kein Verzeichnis angeben und die Basis-Auth läuft auch nicht wirklich.
Ist da was geplant?
Erweiterung des Hook-Moduls wäre mein Favorit! Die hook-URL hat ja schießlich sonst auch keinen direkten Zusammenhang mit dem Webserver-Modul. Insb. bei mehreren Webserver-Instanzen wird das sonst ziemlich undurchsichtig.
Authentifizierung ist dort ein wichtiges Thema, welches behandelt wird. So macht es übrigens auch das Geofency Modul.
Die kompletten WebHooks per Kennwort zu sichern halte ich für den falschen Ansatz. Jeder Entwickler eines WebHooks sollte die Wahl haben und auch entsprechend pro Hook Kennwörter vergeben können. So kann man je nach Dienst auch unterschiedliche Kennwörter vergeben.
Übrigens: Wenn du nur /hook/ komplett absichern willst und den Rest nicht erreichbar machen willst, kannst du dir einen ReverseProxy installieren, der nur /hook/ auf einem beliebigen Port anbietet und eine extra Basis Authentifizierung drüber legt. Das bringt echte Sicherheit. Denn: Ruf mal auf deinem 3.4 und speziellen WebServer /api/ auf. Die JSON-RPC API für dein komplettes IP-Symcon ist auf jedem WebServer verfügbar. Ebenso macht die 4.0 es mit den Hooks. Die sind auf jedem WebServer unter /hook/ verfügbar.
paresy
PS: Ich hoffe du nutzt SSL mit einem gültigen Zertifikat?
Paresy,
kurzum: ich denke du hast völlig recht Meine Absicherung im 3.4er war wegen der „offenen“ API auch noch nicht völlig in Ordnung.
Die Doku zum Webhook-Control habe ich gesehen, da geht es aber nur um die Absicherung des Hooks selbst… hilft mir ja nicht, solange ich FÜR den Hook eine komplette Webserver-Instanz aktiv haben muss, die im Web erreichbar ist.
ReversyProxy für die /hook/-URL klingt nach einer guten Idee. Nur eigentlich schade, dass ich dafür eine extra Software drauflegen muss… ich dachte nämlich eben ursprünglich, dass die neue Webhook-Instanz direkt einen eigenen Port konfigurieren könnte und dann auf diesem auch wirklich NUR die /hook/ anbietet…
aber okay, danke trotzdem! Dann fummel ich mir da was mit nem ReverseProxy… (btw: gibts es da Empfehlungen?)
Wir versuchen das mit den WebServer so komfortabel wie möglich für alle Kunden zu gestalten und verzichten dabei in keinem Fall auf die Sicherheit. Wir vertrauen selbst ja auch unsere Sicherheitsmechanismen. (User Demo WebFront ist nämlich auch samt /api/ und /hook/ öffentlich verfügbar. http://www.webfront.info/api/ und http://www.webfront.info/hook/)
Somit wäre dein Wunsch für die meisten Kunden leider nur verwirrend und sehr kompliziert zu verstehen wofür es gut ist.
Aber zurück zur Frage: Ich würde nginx nehmen. Find ich toll und tut seinen Dienst hervorragend.
paresy
PS: Wusstest du das der IP-Symcon WebServer mit SSL bei SSLLabs ein Rating von A hat?
PPS: Ich werde das mit der API und dem WebHooks noch einmal extra in der Doku beim WebServer Thema hinzufügen lassen. Ist tatsächlich ein wichtiger Hinweis.
Reverse proxying via Nginx ist gut, und ich benutze diese Lösung seit einigen Jahren. Daran schätze ich z.B. die soliderer User-Verwaltung.
Bis jetzt habe ich IPS in einige Nginx-Server via JSON-RPC eingebunden, aber geht es auch direkter? Nginx kann ja PHP-Aufrufe an einen beliebigen PHP-Prozessor weitergeben, z.B. mit:
OK, also nicht sinnvoll.
Dennoch: falls jemand Interesse hat, IPS-Funktionen einem nginx-Serverblock hinzu zu fügen, hier ist der nginx-context:
location ~ \.(php|html|htm)$ {
# the next line forces every php and html file to include a reference to the ips wrapper
fastcgi_param PHP_VALUE "auto_prepend_file=/yourfavoritepath/ips_wrapper.php";
fastcgi_pass unix:/run/php-fpm/php-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param AUTH_USER $remote_user;
fastcgi_param REMOTE_USER $remote_user;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_index index.php;
include fastcgi.conf;
}
Ebenso macht die 4.0 es mit den Hooks. Die sind auf jedem WebServer unter /hook/ verfügbar.