ISPConfig3 und Sicherheit

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?
 

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.
 

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:

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
 

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:

Till

Administrator
ich sehe gerade, dass der Nutzer seine open_basedir variable sogar via normaler ISPConfig GUI ändern kann

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

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

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

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.

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.

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?

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.
 

cyberus

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

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.
 

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.
 

Werbung

Top