ISPConfig3 und Sicherheit

Dieses Thema im Forum "Installation und Konfiguration" wurde erstellt von cyberus, 15. Juni 2014.

  1. cyberus

    cyberus New Member

    Hi zusammen,

    ich setze ISPConfig 3 nun seit einer weiler unter debian 7 ein. Nun habe ich in einigen HOWTO's gelesen, dass SELinux auf jeden fall deaktiviert werden soll. Unter Debian 7 ist es per default inaktiv - also kein Problem. Allerdings habe ich etwas Sicherheitsbedenken, da es den eingerichtetet Kunden möglich ist aus Ihrem WEB Space heraus auf (z.B via PHP script) auf das Dateisystem vom Server zuzugreifen und somit potentiell geheime Daten zu lesen.

    Daher nun meine Frage:
    wie stellt ihr sicher, dass ein Nutzer nicht einfach aus einem php script heraus "cat /etc/passwd" oder so etwas aufruft. Klar ich könnte der /etc/passwd die leserechte für "all" entziehen. Aber potentiell sind ja auf dem Server tausende Dateien abgespeichert die nicht unbedingt jeder lesen können soll.

    SELinux könnte so etwas verhindern, den apache im chroot laufen lassen sicher auch - aber was ist die beste Lösung?
     
  2. nowayback

    nowayback Well-Known Member

    basedir_restrictions
     
  3. cyberus

    cyberus New Member

    Hi,

    ich nehme an du meinst die open_basedir variable in der php.ini ?

    Das ist aber eine sehr lokale Lösung.

    1. nur für php scripts (cgi scripts?)
    2. Nutzer können die variable mit eigenen config direktiven erweitern

    also wenn ein nutzer in den optionen seines WEB Spaces in den apache direktiven einträgt:
    php_admin_value open_basedir "/etc/:/var/log"

    dann kann er wieder überall rum schnüffeln. mit eigener php.ini im Dateisystem kann er die variable sicher auch manipulieren.
     
  4. cyberus

    cyberus New Member

    ich sehe gerade, dass der Nutzer seine open_basedir variable sogar via normaler ISPConfig GUI ändern kann - also nicht so recht geeignet um dem Nutzer z.B den Zugang zu /etc/passwd zu verwehren.

    PS.:
    sehe ich das richtig, dass die optionen unter /etc/php5/apache2/php.ini irgendwie überschrieben werden? dort habe ich u.a, "disable_functions =exec" und einiges mehr dirn stehen. Das ist natürlich auch ein ganz schön übles Ding :eek:

    zumal open_basedir auch nicht auf exec() wirkt (also exec(cat /etc/passwd/) geht immer, auch wenn /etc/ nicht in der open_basedir erlaubt ist)
     
    Zuletzt bearbeitet: 15. Juni 2014
  5. nowayback

    nowayback Well-Known Member

    Hi,

    open_basedir ist nur eine der vielen Dinge die hier zum Einsatz kommen.

    Jeder Kunde bekommt eine Gruppe (z.b. client1) zugewiesen. Jede angelegt Domain des Kunden bekommt einen User (z.b. web1) zugewiesen und als Gruppe die Gruppe des Kunden. Somit wird schonmal sehr effektiv verhindert, dass ein Kunde auf die Daten des anderen zugreifen kann.
    Hinzu kommt, dass die übergeordneten Verzeichnisse dem root gehören.
    Chmod 710 aufs web Verzeichnis sorgt dafür, dass trotz gleicher Gruppe, die web-Verzeichnisse des Kunden voneinander getrennt sind.
    FastCGI limitiert noch weiter.

    Ich weiß nicht was du suchst, aber hast du mal versucht auf die passwd zuzugreifen nachdem du alle Features/Sicherheitsvorkehrungen in ISPConfig getroffen hast?

    Code:
    disable_functions = apache_child_terminate, apache_get_modules, apache_get_version, apache_getenv, apache_note, apache_setenv, define_syslog_variables, disk_free_space, diskfreespace, dl, error_log, escapeshellarg, escapeshellcmd, exec, ftp_connect, ftp_exec, ftp_get, ftp_login, ftp_nb_fput, ftp_put, ftp_raw, ftp_rawlist, ini_alter, ini_get_all, ini_restore, link, openlog, passthru, pfsockopen, php_uname, phpinfo, popen, posix_getpwuid, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, posix_uname, proc_close, proc_get_status, proc_nice, proc_open, proc_terminate,pcntl_exec , set_time_limit, shell_exec, symlink, syslog, system, tmpfile, virtual
    Quelle: http://www.howtoforge.de/forum/35477-post10.html
     
  6. cyberus

    cyberus New Member

    Hi, erstmal danke für deine antworten und deine Geduld.
    Also das besagte "disable_functions" hatte ich so schon in meiner globalen php.ini

    Problem Nummer 1 ist für mich, dass diese Einstellungen (wie auch immer, ich habe die stelle nicht gefunden) in den ISPConfig WEB Spaces überschrieben werden bzw. Ignoriert werden. Also ein php script welche s exec() aufruft funktioniert noch. Und die openbase_dir restrictions wirken sich nicht auf exec() aus.

    Anscheinend wirken PHP Einstellungen nur wenn man sie über den "Optionen" Reiter des web Space unter PHP direktiven einträgt. Muss man halt wissen. Und so wie ich es nun sehe hat der "Kunden login" keinen Zugriff auf diesen Reiter und kann den nicht manipulieren.

    Problem Nummer 2 ist, dass ich nicht sicher bin ob der Nutzer diese PHP Einstellungen mit einer php.ini die er selbst im WEB space platziert über schreiben kann.

    Also prio 1 ist es natürlich den WEB Space gegen unbekannte dritte zu sichern.
    Aber genauso wichtig ist, dass der eingerichtete unpriviligierte Nutzer nicht einfach PHP Einstellungen geändert bekommt und so an sensible Daten des Servers (die außerhalb des via dateirechten gesicherten /var/www/ liegen und u.U world readable sind) gelangt.

    Darum da hte ich daran den ganzen Apache Prozess vom system zu isolieren (chroot, SELinux) was aber nicht so einfach zu sein scheint. Oder hat da jemand Erfahrungen mit?
     
    Zuletzt bearbeitet: 15. Juni 2014
  7. Till

    Till Administrator

    Nein, das kann er natürlich nicht. Nur Du als admin kannst sie ändern.

    Nein, die werden natürlich auch nicht überschrieben.

    Das kannd er Kunde nicht überschreiben. Außer Du hast es manuell global in der php.ini aktiviert. Default ist aber immer off.

    Wie nowayback bereits erläutert hat, sind die Rechte auf Linux Userebene bereits komplett getrennt zwischen den Webseiten und lesen können die web user nur das, was ihnen gehört oder unter Linux globale Leserechte hat und nicht durch open_basedir geblockt ist.

    Das ist nicht so einfach, sonst würde ispconfig das schon per default machen. Denn wenn Du apache chrootest, dann müsstest Du ja in das chrot auch alles rein tun, was er benötigt. also php, perl, python, alle web user etc. also im Großen und Ganzen das Meiste von dem, was Du auf dem Server hast.
     
  8. cyberus

    cyberus New Member

    ich hatte jetzt irgendwo gelesen, dass ispconfig einen php-fcgi-starter script benutzt, dem die php variablen (aus dem Reiter "Optionen") irgendwie übergeben werden.

    Jedenfalls habe ich festgestellt, dass die Einstellung:

    PHP:
    disable_functions exec
    in der
    /etc/php5/apache2/php.ini

    ignoriert wird (also ich in einem test php script immernoch exec() benutzen kann).

    Erst nachdem ich "disable_functions = exec" im Reiter "Optionen" eingetragen habe wurde die Funktion unterbunden.
     
  9. Till

    Till Administrator

    Die Datei /etc/php5/apache2/php.ini ist die Konfigurationsdatei von mod_php und nicht die von php cgi/fcgi. Wenn Du einen Default für php-fcgi setzen willst, dann musst Du die Datei /etc/php5/cgi/php.ini ändern.
     
  10. cyberus

    cyberus New Member

    Ah, da lag das Problem - danke!
     

Diese Seite empfehlen