apache virtualhosts cgi

[k33n]

hi,
ich wollte mir mal ein paar tips zur konfiguration von apache einholen.

apache läuft als nobody nogroup.

es gibt mehrere ip based virtualhosts unter /var/apache/domain/htdocs/

nun sollen die user ein eigenes cgi-bin verzeichnis /var/apache/domain/htdocs/cgi-bin erhalten.

wie kann ich das abersichern?
der server äuft im moment nicht in einer chroot umgebung.

wennn ich ihn in einem chroot laufen lasse ist das problem
das ein:

print `ls ../../andere_domain/htdocs´;

wohl immer noch funktionert? oder sehe ich das falsche.

ziel des ganzen soll sein, dass jeder user eigene cgi scripts nutzen kann und das ganze mit maximal möglicher sicherheit fuer den server.

gruesse k33n.

 

[Bummibaer]

Hi,

die einfachste Lösung wird sein, pro Domain / IP / Kunde einen virtuellen Host zu benutzen samt getrenntem Document Root und eigenem cgi-bin Verzeichnis.

Das jeweilige CGI Verzeichnis dann im Virtual Host einfach mittels ScriptAlias /cgi-bin/ /wwwdata/cgi-bin
einbinden.

Das Document Root mittels DocumentRoot "/wwwdata.../ einbinden. Jeden Virtuellen Host unter einem anderen User/Gruppe starten. Dateisystemrechte richtig setzen ...


Gruß Bummibaer

 

[k33n]

schon klar, aber wenn jemand dann in seinem cgi-bin
( /wwwroot1/cgi-bin/ ) folgende datei hat:

print `less /wwwroot2/login.php`

kann er sich immer noch dateien aus anderen webs anzeigen lassen.

k33n

 

[Bummibaer]

Original geschrieben von k33n
schon klar, aber wenn jemand dann in seinem cgi-bin
( /wwwroot1/cgi-bin/ ) folgende datei hat:

print `less /wwwroot2/login.php`

kann er sich immer noch dateien aus anderen webs anzeigen lassen.

k33n

Das würde bei vernünftiger PHP Konfiguration und PHP Code nicht funktionieren. Einmal gibt es die Möglichkeit mittels doc_root und die weit bessere Möglichkeit über open_basedir dem einen Riegel vorzuschieben. Ebenso würde man im 'login.php' prüfungen vornehmen vor der Ausführung.

Open_basedir beschränkt die Dateien, die von PHP geöffnet werden können, auf Dateien im angegebenen Verzeichnisbaum.

Wenn ein Skript versucht, eine Datei mit z.B. fopen oder gzopen zu öffnen, wird der Ort der Datei überprüft. Wenn sich die Datei außerhalb des spezifizierten Verzeichnisses befindet, was hier der Fall wäre, wird PHP sie nicht öffnen. Alle symbolischen Links sind hier mit eingeschlossen, so dass es auch nicht möglich ist, dieses Verbot mittels symlink zu umgehen.

PHP ist mal ganz allgemein betrachtet schlicht und ergreifend in den meisten Serversystemen implementierten Sicherheitseinstellungen, hinsichtlich der Berechtigungen auf Datei- und Verzeichnisebene, abhängig. Sprich bei schlechter Variablenprüfung z.B. kann man sich große Sicherheitslücken einfangen.

Man sollte daher z.B. eingeschränkte Rechte dem PHP Webuser (sprich der Binärdatei) geben. Ebenso sollte man nichts und niemandem vertrauen und ALLE übertragenen Variablen IMMER prüfen. Man sollte ebenfalls immer nach dem Motto arbeiten das alles was nicht explizit erlaubt wurde automatisch verboten ist.

Bei PHP können beim Kompilieren die Konfigurationsoption --enable-force-cgi-redirect und zur Laufzeit die Konfigurationsdirektiven doc_root und user_dir benutzt werden, um bestimmte Angriffe zu verhindern, falls der Verzeichnisbaum des Servers Verzeichnisse mit Zugriffsbeschränkungen beinhaltet.

Denkbar wäre z.B. Zugriff auf Systemdateien (durch ? in der Abfrageinfo alla http://host/cgi-bin/php?/etc/passwd) oder Zugriff auf beliebige Web-Dokumente auf dem Server in Form von http://host/cgi-bin/php/secret/doc.html:

Der Teil der URL-Pfadinformation nach dem Namen der PHP Binärdatei, /secret/doc.html wird im allgemeinen benutzt, um den Namen der Datei zu übergeben, die durch das CGI-Programm geöffnet und interpretiert werden soll.

Normalerweise werden einige Einträge in der Konfigurationsdatei des Webservers benutzt (Apache: Action), um Aufrufe von Dokumenten wie http://host/secret/script.php3 an den PHP-Interpreter umzuleiten. Bei dieser Konfiguration überprüft der Webserver zuerst die Zugriffsrechte im Verzeichnis /secret und erstellt anschließend den umgeleiteten Aufruf http://host/cgi-bin/php/secret/script.php.
Unglücklicherweise wird, wenn der Aufruf bereits in dieser Form geschieht, vom Webserver keine Zugriffsüberprüfung der Datei /secret/script.php, sondern lediglich der Datei /cgi-bin/php vorgenommen. So ist jeder Benutzer, der auf /cgi-bin/php zugreifen darf in der Lage, sich zu jedem geschützten Dokument auf dem Webserver Zugriff zu verschaffen.

Mittel und Wege gibt es immer, ist nur eine Frage der Zeit und der zur Verfügung stehenden Mittel. Der beste Schutz ist eine Kombination sämtlicher technischer Möglichkeiten. 100%igen Schutz wird es wohl nie geben....

Gruß Bummibaer

 

[SadButTrue]

wenn es um php geht gibts mehr möglichkeiten das zu verhindern:

1. secure mode
2. shell_exec und weitere funktionen die nicht verwendet werden dürfen sperren

ob bzw. wie das bei cgi funktioniert weiss ich nicht.

 

[k33n]

es geht um cgi´s , also um perl code.

das ich den php tag fuer das code beispiel gewählt habe ist vielleicht ein bischen unpassend.


k33n