phpmyadmin in Third-Party Aplications

[itari]

hi Trolli,

ich habe keine Probleme damit, dass man das gut kommentieren muss oder als Lösung in das spk-Paket einbaut. Ich frage nach dem Sinn eines 'root'-Kennworts im mysqld.

Um von außen auf den mysqld zu kommen, muss man den Port 3306 im Router aufmachen. Wer - bitte schön - macht das wirklich? Mit welchem Sinn? Wir reden ja nicht vom lokalen Netz.

Und von ansonsten: Ich hab hier noch nicht gelesen, dass jemand anders als via PHP auf seine MySQL-Datenbanken zugreift. D. h. also immer per Skript und dort steht dann auch immer das Kennwort drin. Was eine Absicherung mit Kennwort eigentlich sinnlos macht. Alternativ könnte man nur durch einen zweiten mysqld oder ein unkontrolliertes Skript oder selbst geschriebenes Skript auf die MySQL-Datenbanken zugreifen. Das ist eher hypothetisch als real.

Im Moment kann ich mir einfach keine Situation vorstellen (im Rahmen einer DS-Lösung), wo das Absichern des Zugangs zum mysqld per Kennwort irgendwie was sicherer macht. Ich mag mich irren. Aber es würde mich schon sehr interessieren, weil ich da auf dem Schlauch steh.

itari

 

[Trolli]

Ich meinte, dass es bestimmt auch Leute gibt, die den Port 5001 nach draussen geöfnet haben. Und dann hat man natürlich sofort Zugriff auf phpMyAdmin mit dem MySQL root-Benutzer.

Benutzt man das Webinterface nur intern, gibt es in der Tat keinen Grund für ein MySQL root-PW.

Den Fall mit dem weitergeleiteten Port 3306 halte ich auch eher für theoretisch.

Trolli

 

[itari]

Ja, da hast Recht. Ok, dann werd ich mal meine Pläne begraben, dass als spk-Paket zu machen, solange es keine allgemeine Lösung gibt, dass die zusätzlichen Skripte so abgesichert sind, dass man sie auch nur dann ausführen kann, wenn man sich ordentlich angemeldet hat.

itari

 

[Trolli]

Wieso? Stell doch einfach die Authentifizierung auf 'http' - der einzige Unterschied ist dann doch, dass beim Aufruf von phpMyAdmin eine Passwortabfrage erscheint...

 

[jahlives]

Ja, da hast Recht. Ok, dann werd ich mal meine Pläne begraben, dass als spk-Paket zu machen, solange es keine allgemeine Lösung gibt, dass die zusätzlichen Skripte so abgesichert sind, dass man sie auch nur dann ausführen kann, wenn man sich ordentlich angemeldet hat.

itari

Solange es sich um PHP Files handelt kann man so sicherstellen, dass nur angemeldete Benutzer darauf zugreifen können. Funzt leider nur mit PHP Files (also kein cgi Schutz)

 

[Trolli]

Schön. Das ist aber ja keine Methode, die sich zum Einbau in ein .spk Paket von phpMyAdmin eignet, oder?

 

[jahlives]

Schön. Das ist aber ja keine Methode, die sich zum Einbau in ein .spk Paket von phpMyAdmin eignet, oder?

Mit einem spk Paket kann man doch beliebige Dateien anlegen lassen? Braucht nur eine .htaccess Datei und die php-Datei mit dem entsprechenden Code. Das sollte mit 2 Aufrufen vom spk her doch wohl möglich sein...

 

[Trolli]

Möglich schon - aber nicht praktikabel. Die Dateien müssen ja individualisiert angelegt werden. Ein entsprechender Eingabedialog ist ja bei der Paketinstallation nicht vorgesehen...

 

[jahlives]

Möglich schon - aber nicht praktikabel. Die Dateien müssen ja individualisiert angelegt werden. Ein entsprechender Eingabedialog ist ja bei der Paketinstallation nicht vorgesehen...

Und wieso setzt des einen Eingabedialog voraus? Die htaccess Datei muss ins 3rd Party Verzeichnis der Applikation und die PHP Datei kann irgendwo auf dem Server liegen, solange root nur Zugriff darauf hat. Wo die PHP Datei liegt ist egal nur die htaccess Datei muss natürlich den korrekten Pfad eingetragen haben

 

[itari]

Hmm,

es gibt einfach zu viele Komplikationen, wenn man den Port 5001 öffnet ins Web hinein.

Zu dem phpMyAdmin-Problem: Der Benutzer 'root' unter Linux ist was anderes als der Benutzer 'root' unter mysqld und der ist total was anderes als der Benutzer 'admin' mit dem man sich beim Disk Station Manager anmeldet. Alle könnten und müßten andere Kennworte haben (und diese jede Woche ändern können, ohne das jemand den Faden verliert ..., sonst ist der Schutz als Zugangsschutz nicht wirklich was Wert, weil wenn er kompromittiert wird, man ja sofort handeln können muss, sprich alle Kennworte neu vergeben können muss.)

Und da fängt mein Problem an, wenn ich das Kennwort für den 'root'-Benutzer des mysqld einführe, dann müsste ich immer alle Skripte nachführen. Das Kennwort für mysqld für die Skripte zentral ablegen, widerspricht mir auch, weil gemäß Domino-Effekt, wenn ein Stein fällt, fallen alle. Also müsste man für jedes Skript einen eigenen mysqld-User anlegen mit eigenem Kennwort. Ob das realistisch ist?

Im Moment tendiere ich dazu, zu sagen, DS-Administration mit 3rd-parties darf nur im 'trusted' LAN erfolgen, alles andere ist nicht sicher. Und im 'trusted' LAN gibt es keine Beschränkungen, also alles ohne Kennworte.

Nur mal so am Rande, sichere Kennworte gibt es erst ab 12 Zeichen, die man alle 7 Tage ändert. Vielleicht führen wir ja auch nur ein Scheingefecht hier, weil wenn eh sich keiner Gedanken um die Sicherheit macht, dann braucht man sie auch nicht.

Ich werde demnächst immer bei meinen Skripten dazu schreiben (fett und rot), dass sie die Sicherheit der DS gefährden und ich auch dazu keine Lösung anbieten kann. Dann ja jeder selbst entscheiden, ob er/sie es einsetzen mag oder nicht.

itari

 

[Trolli]

Und wieso setzt des einen Eingabedialog voraus? Die htaccess Datei muss ins 3rd Party Verzeichnis der Applikation und die PHP Datei kann irgendwo auf dem Server liegen, solange root nur Zugriff darauf hat. Wo die PHP Datei liegt ist egal nur die htaccess Datei muss natürlich den korrekten Pfad eingetragen haben

Gut. Man könnte natürlich den Zugriff auf phpMyAdmin über die .htaccess-Datei generell für alle IP-Adressen erlauben, die für lokale Netzwerke vorgesehen sind. Ansonsten wären die einzutragenden IPs ja für jeden Anwender individuell.

@itari:
Gibt es denn 3rd-Party Apps, die MySQL benutzen? Ansonsten kann doch jeder Passwörter vergeben wie er Lust und Laune hat. Oder sehe ich das eigentliche Problem nicht?

 

[itari]

@itari:
Gibt es denn 3rd-Party Apps, die MySQL benutzen? Ansonsten kann doch jeder Passwörter vergeben wie er Lust und Laune hat. Oder sehe ich das eigentliche Problem nicht?

Ja, gibt es (z. B. die Konnektor-Skripte für Termine und Adressen, das Frontend für das CMS). Und es gibt andere 3rd-party-Anwendungen (z. B. editor, Cronjobs, samba-Konfig usw. ), die auch Tür und Tor aufmachen.

Das Problem ist ja nicht, eine spezielle Anwendung abzusichern, sondern ein allgemeingültiges Prinzip zu haben, damit - falls es kompromittiert wird, nur an einer Stelle geflickt werden kann (ein Kennwort ändern und Ruh ist ...)

itari

 

[jahlives]

Gut. Man könnte natürlich den Zugriff auf phpMyAdmin über die .htaccess-Datei generell für alle IP-Adressen erlauben, die für lokale Netzwerke vorgesehen sind. Ansonsten wären die einzutragenden IPs ja für jeden Anwender individuell.

Die IP-Adressen und mod_rewrite sind ein Teil. In der htaccess Datei kannst du aber zusätzlich über php_flags PHP anweisen jedem PHP File des Verzeichnisses ein bestimmtest PHP File voranzustellen. Dieser Code prüft dann erst ob man als admin (im Webinterface) angemeldet ist und erlaubt den Zugriff nur dann. Ansonsten gibt's nen 403-er und Scriptabbruch (exit)
Damit sind Zugriffe auf 3rd Party Appl (zumindest auf php Files) nur dann erlaubt wenn man als admin am DS-Manager angemeldet ist.
Für mich ist das die sicherste Methode die 3rd Party Appls abzusichern (wenn jemand noch was besseres kennt, dann immer her damit)

Gruss

tobi

 

[Trolli]

OK. Soweit hatte ich das wohl noch nicht verstanden. Gegen euch bin ja auch ein echter Banause was PHP angeht.
Ich finde, das hört sich doch super an. Wäre das nicht ein geeignetes Konzept, Itari?

 

[itari]

Die IP-Adressen und mod_rewrite sind ein Teil. In der htaccess Datei kannst du aber zusätzlich über php_flags PHP anweisen jedem PHP File des Verzeichnisses ein bestimmtest PHP File voranzustellen. Dieser Code prüft dann erst ob man als admin (im Webinterface) angemeldet ist und erlaubt den Zugriff nur dann. Ansonsten gibt's nen 403-er und Scriptabbruch (exit)
Damit sind Zugriffe auf 3rd Party Appl (zumindest auf php Files) nur dann erlaubt wenn man als admin am DS-Manager angemeldet ist.
Für mich ist das die sicherste Methode die 3rd Party Appls abzusichern (wenn jemand noch was besseres kennt, dann immer her damit)

Gruss

tobi

Das mit der Anmeldungs-Prüfung ist leider keine gute Sache. Weil das als Session in einer bestimmte Zeit verfällt und wenn du dann eine Page refreshst, darfst dich erstmal wieder neu anmelden ... den Spaß hatten wir auch schon diskutiert und leider gibt es da auch keine gute Lösung für, es sei denn du greifst in den Code der DS ein.

Ich steh allerdings auf dem Standpunkt, dass ich nur dann in den Code der DS eingreife (z. B. ein ipkg installiere oder im Java-Skript herumpfusche), wenn es keine Alternative dazu gibt und es auch sein muss. Denn du musst das ja bei jedem Firmware-Update nachbauen. Ich versuche ja gerade mit den spk-Paketen zu Lösungen zu kommen, die so wenig wie möglich beim Firmware-Update an Nacharbeit auskommen. Am liebsten wäre es mir, die Synology-Entwickler hätten schon alles eingebaut

itari

 

[jahlives]

Das mit der Anmeldungs-Prüfung ist leider keine gute Sache. Weil das als Session in einer bestimmte Zeit verfällt und wenn du dann eine Page refreshst, darfst dich erstmal wieder neu anmelden ... den Spaß hatten wir auch schon diskutiert und leider gibt es da auch keine gute Lösung für, es sei denn du greifst in den Code der DS ein.

Ich steh allerdings auf dem Standpunkt, dass ich nur dann in den Code der DS eingreife (z. B. ein ipkg installiere oder im Java-Skript herumpfusche), wenn es keine Alternative dazu gibt und es auch sein muss. Denn du musst das ja bei jedem Firmware-Update nachbauen. Ich versuche ja gerade mit den spk-Paketen zu Lösungen zu kommen, die so wenig wie möglich beim Firmware-Update an Nacharbeit auskommen. Am liebsten wäre es mir, die Synology-Entwickler hätten schon alles eingebaut

itari

@itari
Wird denn durch den Aufruf von authenticate.cgi das Timeout nicht verlängert? Kann man auf der DS irgendwo kontrollieren ob das Timeout verlängert wird durch den Aufruf?

 

[Trolli]

Denke ich auch. Bei Aufruf oder Neuladen einer Seite im Station Manager wird das Timeout auf jeden Fall verlängert. Wenn man eine Seite hat, die sich automatisch refresht (Download Station, Backupfortschritt,...), bekommt man nie einen Timeout.

 

[itari]

@itari
Wird denn durch den Aufruf von authenticate.cgi das Timeout nicht verlängert?

Nicht das ich wüsste - so wie es gesehen habe, schaut er in ein Session-Cookie

Kann man auf der DS irgendwo kontrollieren ob das Timeout verlängert wird durch den Aufruf?

Keine Ahnung. Bei Backups und Formatierung und Raid-Geschichten wird per AJAX der Balken aktualisiert und man muss sich bei dem ein oder anderen Menüpunkt keine Gedanken machen, dass die Zeit verfällt. Aber ich hab nocht nicht herausbekommen, ob und wie man das Timeout durch eine Aufruf wieder neu startet. Bei kurzem Studium der extjs-Bibliothek habe ich zur Session-Verwaltung noch nichts gefunden.

Es ist auch hier so eine Sache, wie man damit umgehen soll. Es ist ja ein Sicherheits-Feature, dass es ein Session-Timeout gibt. Das nun wieder außer Kraft setzen, ist ja nur bedingt sinnvoll.

itari

 

[jahlives]

Also ich habe es mal probiert. Habe ständig zwischen verschiedenen 3rd Party Appls hin und hergeklickt und seit 55 Minuten keinen Timeout mehr erhalten Scheint also zu funzen, dass der Timeout über den Aufruf von authenticate.cgi verlängert wird.

Gruss

tobi

 

[QTip]

solange du nur 3rd-party apps anwählst bekommst auch kein Timeout