RootForum Community

dodolin wrote:Kannst du mir einen sinnigen Grund sagen, warum statische HTML-Seiten (d.h. also insbesondere sind da keine Passwörter für DBs drin oder so...), die für jeden per HTTP verfügbar sind, nicht auch für andere Benutzer des Systems lesbar sein können? ;)

Weil sie eben möglicherweise doch nicht für jeden per HTTP verfügbar sind (HTTP-Basic-Auth!). Außerdem kann bereits der Aufbau der Verzeichnisstruktur möglicherweise Informationen für Angriffswege liefern, wobei man hier einschränken muss, dass eine Seite grundsätzlich so konzipiert sein sollte, dass auch ein Angreifer mit diesen Informationen keine Chance hat (schließlich ist security by obscurity keine gute Idee).

Das Problem, dass ein Verzeichnis über Authentifizierung geschützt sein kann, ist jedoch ganz real, und man sollte sich als Benutzer auch darauf verlassen können.

auch auf die Gefahr hin, dass ich etwas hier etwas OT bin: hat jemand erfahrung, wie man php als fastcgi einsetzen kann um in etwa die geschwindigkeit von mod_php zu haben, aber (über suexec) die "sicherheit" eines cgi zu haben? eine faq wäre ganz nett. google hat leider nicht weitergeholfen. obwohl als fastcgi kompiliert, liefert php, wie apache meint, keinen gültigen satz an headern aus.

thanx + bye,
alfonz

alfonz wrote:auch auf die Gefahr hin, dass ich etwas hier etwas OT bin: hat jemand erfahrung, wie man php als fastcgi einsetzen kann um in etwa die geschwindigkeit von mod_php zu haben, aber (über suexec) die "sicherheit" eines cgi zu haben? eine faq wäre ganz nett. google hat leider nicht weitergeholfen. obwohl als fastcgi kompiliert, liefert php, wie apache meint, keinen gültigen satz an headern aus.

Hast du PHP auch mit FastCGI-Unterstützung kompiliert (in der Ausgabe von phpinfo() sollte dann bei Server-API CGI/FastCGI stehen)?

soweit komme ich ja gar nicht erst. wenn ich das php-binary in shell aufrufe steht dort etwas von cgi/fastcgi. Also kompiliert sein sollte es ja wohl richtig. Nur scheint apache damit klar zu kommen. ein richtiges howto oder ein manual habe ich nirgends findne können. daher auch meine frage hier im forum unter

php + apache2 + mod_fastcgi - Aufruf endet mit Timeout
http://www.rootforum.org/forum/viewtopic.php?t=20329

da stehen auch die fehlermeldungen aus dem apache-log. ich habe php jetzt wieder als mod_php laufen, zwischendurch noch einiges probiert, ohne howto komme ich aber nicht weiter ...

arty wrote:Hi,

DarkSpirit wrote:Sicher? Also zumindest bei MySQL ist das ziemlich wurscht, unter welchem User das entsprechende Programm (z.b. Apache) läuft, dass die Verbindung aufbauen will, solange beim connecten der angegebene Username mit dem Passwort stimmt, oder verstehe ich da was falsch?

so stehts jedenfalls im PHP Manual: http://www.php.net/manual/de/security.apache.php

bye
arty

Das kommt ganz drauf an wie man die Verbindung aufbauen will. Ein MySQL User hat nichts mit einem Linux-User zu tun, aber:

a) übergibt man beim connect keinen Usernamen/Passwort, versucht MySQL die Verbindung mit dem Username des Apache-Users und ohne Kennwort aufzubauen. Da IMHO niemals ein MySQL User ein leeres Kennwort haben sollte, wird der Zugriff abgelehnt.

b) stellt man die Verbindung über einen Unix Domain Socket her (was nach MySQL und PHP Grundeinstellung eh bei einer Verbindung zum Server "lokalhost" passiert), muss der Apache User die entsprechenden Rechte auf den Socket haben. Da der Socket eh 777 hat, sollte das kein Problem sein.

Vorweg: Ich nutze php 4.3.4 und Apache 1.3.29

Ich habe in meiner httpd.conf folgendes stehen (Auszug, bisher lokal) Also ist der safemode an und ich habe per open_basedir das Verzeichnis eingestellt, was als höchstes im Pfad erreicht werden kann. Stimmt das?

in der php.inii steht folgendes (Auszug) Was ich daraus verstehe ist, dass für den Safe-Mode kein besonder exec und include Pfad gesetzt ist (über open_basedir in der httpd.conf überschrieben), Extensions hinzugeladen werden dürfen und keine Funktionen deaktiviert sind.

Meine Frage dazu:
Kann ich es über obige Einstellungen sicher bekommen? Welche Funktionen sollten deaktiviert werden?

desweiteren: Ist suphp eine Alternative zu apache per suexec? Habe extreme Probleme gehabt, viele Skripte liefen nicht (u.a. phpmyadmin beim export).

Eine Antwort wäre echt nett, da ich mich bisher nicht um die Sicherheit meiner PHP-Umgebung kümmern musste.

MfG
Patrick

desweiteren: Ist suphp eine Alternative zu apache per suexec?

Ja, macht in etwa das gleiche.

also mit safe_mode und open_base_dir müsste man mod_php doch einiger maßen dicht bekommen, oder?

also mit safe_mode und open_base_dir müsste man mod_php doch einiger maßen dicht bekommen, oder?

Darauf war ich bewusst nicht eingegangen, da die Frage IMHO nicht so doll ist. Wirf mal nen Blick auf meine Antwort in diesem Thread:

http://www.rootforum.org/forum/viewtopic.php?t=24454

Danach stelle ich folgende Fragen:
Kannst du "einigermaßen dicht" definieren?
Vor welchen Bedrohungsszenarien willst du dich (bzw. dein PHP) schützen?

Danach kann man sagen, ob dieses Setup dich dafür schützt oder nicht.

Ich persönlich halte nichts von solchen Setups und würde _ausschließlich_ PHP als CGI via suEXEC oder suPHP benutzen, sodass es unter den Rechten des jeweiligen Benutzers läuft. _Alle_ mir bekannten "gescheiten" Webhoster machen das so.

Thema Safe Mode: http://www.dclp-faq.de/q/q-konfiguration-safe-mode.html

safe_mode ist nicht sicher: Ein Fehler in der popen() -Funktion ist erst mit 3.0.14 korrigiert worden, ein weiterer Fehler in der mail() -Funktion erst in 3.0.15. Spätere Versionen von PHP hatten weitere Lücken. Man sollte stattdessen die CGI-Version in einem chroot-Environment verwenden und mit setrlimit noch weitergehende Einschränkungen definieren.

bye
arty

Cybermage wrote:also mit safe_mode und open_base_dir müsste man mod_php doch einiger maßen dicht bekommen, oder?

Ich bin auch dieser Meinung. ich konnte auch noch nirgendwo eine Begründung dafür lesen, warum der safe_mode unsicher sein soll. Wahrscheinlich irre ich mich ja, aber ich würde mich freuen, endlich mal ein konkretes Beispiel zu lesen.

redhatuser wrote:Ich bin auch dieser Meinung. ich konnte auch noch nirgendwo eine Begründung dafür lesen, warum der safe_mode unsicher sein soll. Wahrscheinlich irre ich mich ja, aber ich würde mich freuen, endlich mal ein konkretes Beispiel zu lesen.

safe_mode verknüpft mit open_basedir ist bei richtiger Konfiguration durchaus einigermaßen sicher - das Problem ist allerdings, dass dadurch die Funktionalität massiv eingeschränkt wird, so dass sich einige Anwendungen nicht mehr vernünftig bzw. nicht mehr im vollen Umfang nutzen lassen.

DarkSpirit wrote:777 bei Ordnern bedeutet, dass jeder darin Dateien anlegen kann.. ist ebenfalls unschön, auch wenn mir jetzt konkret kein sicherheitskritisches Beispiel einfällt.. die Frage ist einfach, ob es solche Ordner überhaupt braucht. Ich sage nein ;)

Wie realisiere ich dann ein Upload Ordner ?
Ich möchte keine 2MB oder 10MB Dateien in eine DB schreiben...

Gruss
msgbeep

Hallo!

Ich habe hier schon in der Suche und in den FAQ nachgeschaut, aber nichts oder zumindest nichts aktuelles gefunden.

Ã?berall wird erwähnt, dass man PHP besser als CGI beim Apache laufen lassen soll. Da ich einen 1&1 Suse 9.0 Root-Server habe und einige User Shell-Zugriff haben und einige Typo3 benutzen und somit der SafeMode deaktiviert ist, wollte ich dies gerne so umändern, da PHP bei dem 1&1-Suse-Server standardmäßig als CGI läuft.

Leider konnte ich hier im Forum per Suche und den FAQ aber keine genaueren Hinweise finden, wie ich von der Apache/PHP als Modul-Variante auf die Apache/PHP als CGI-Variante umstellen kann.

Sehr wichtig ist auch, dass Confixx (3.0.2 installiert) auf jeden Fall einwandfrei weiterläuft.

Kennt jemand eine Anleitung, die alle wichtigen Punkte beschreibt, wie man sicher "umsteigt"?

Danke im Voraus!

Hi,

PHP als CGI über suPHP für die User und mod_php für Confixx in einem eigenen VHost. Ist in diesem Forum und auch IMHO im DebianHowto beschrieben.

bye
arty

Prokurist wrote:da PHP bei dem 1&1-Suse-Server standardmäßig als CGI läuft.

s/CGI/Modul/

Interessanter Arikel von Ilia Alshanetsky, dem Release Manager von PHP 4.3.x:

http://ilia.ws/archives/18_PHPs_safe_mo ... urity.html

bye
arty

arty wrote: ... PHP bekommt man bei Multi-User-Umgebungen nicht durch den Einsatz des Safe-Mode sicher, sondern nur dadurch, dass man PHP als CGI über suExec oder suPHP laufen lässt und die User in einer chroot-Umgebung lässt.
...

PHP als CGI (bzw. fcgi) über suExec ist klar. Aber wie sperrst Du einzelne User in chroot-Umgebungen?

tomotom wrote:PHP als CGI (bzw. fcgi) über suExec ist klar. Aber wie sperrst Du einzelne User in chroot-Umgebungen?

Mit lighttpd können die einzelnen PHP-Prozesse problemlos in einer chroot-Umgebung gestartet werden (-> man spawn-fcgi). Bei Einsatz des Apache httpd wird das etwas komplizierter. Mit mod_fastcgi war es auch möglich, sich auf bereits vorher erstellte Prozesse zu verbinden, leider wird das Modul nicht mehr weiterentwickelt und mod_fcgid unterstützt dieses Feature nicht.

Hm.. jetzt verstehe ich nicht welches Feature mod_fcgid nicht unterstützt ? PHP als FCGI in einer Chrooted-Umgebung oder dieses Feature mit dem Wiederverbinden?

auf fastcgi.coremail.cn findet man unter "Documentation" folgendes :

This is for suPHP ( UNIX )

LoadModule fcgid_module modules/mod_fcgid.so

<VirtualHost *:80>
ServerName test2.example.com
DocumentRoot /usr/local/apache2/htdocs/test2.example.com/
SuexecUserGroup pqf pqf
</VirtualHost>

<Directory /usr/local/apache2/htdocs/test2.example.com/>
AddHandler fcgid-script .php
Options ExecCGI
allow from all
FCGIWrapper /usr/local/apache2/htdocs/test2.example.com/php .php

# You need mod_fcgid version >= 2.1 to support arguments in FCGIWrapper, if you want
# FCGIWrapper "/usr/local/bin/php -c /etc/" .php

</Directory>

# Please make sure:
# php is configured with --enable-fastcgi option
# copy php execution to /usr/local/apache2/htdocs/test2.example.com/ directory
# make sure all files in /usr/local/apache2/htdocs/test2.example.com/ with right owner and group
# check error_log(with debug level) and suexec_log, if any thing goes wrong

Da ich ähnlich mod_fastcgi betreibe, stellt sich für mich die Frage ob ich auf mod_fcgid umsteigen soll ( da mod_fastcgi anscheinend sowieso nicht weiterentwickelt wird ).

Es gab bereits einige Diskussionen hier, jedoch keine präzise Benchmarks zwischen den verschiedenen Apache-Versionen und diesen beiden Modulen.

mfG
Ice

Wenn du umsteigen willst, dann greif lieber direkt zu LightTPD, der hat von Hause aus Unterstützung für mod_fastcgi und ist massiv performanter als der Indianer.

Gruß
dtdesign

dtdesign wrote:Wenn du umsteigen willst, dann greif lieber direkt zu LightTPD, der hat von Hause aus Unterstützung für mod_fastcgi und ist massiv performanter als der Indianer.

Gruß
dtdesign

Wenn ich mich richtig an die Linux Magazin Benchmarks erinnere spielt der Lighty seine Vorteile nur bei der Übertragung von kleinen statischen Datein aus. Bei dynamischen Seiten die von php erzeugt werden soll Apache schneller sein. Wie sieht es aus wenn php als fast-cgi auf beiden Servern eingebunden ist? Habt Ihr da Erfahrungen? Das fehlende mod_security scheint ja noch ein weiterer Grund gegen den Lighty zu sein ...

tomotom wrote:Das fehlende mod_security scheint ja noch ein weiterer Grund gegen den Lighty zu sein ...

Eben deswegen bin ich noch beim Indiander. ZZ habe ich den 2.0.x Indianer und werde auf einem Vhost mod_fcgid ausprobieren und vielleicht einen kleinen Benchmark machen.

Da ich auf einer sehr alten Machine einen Performance-Boost beim Apache 2.2.3 gesehen habe, möchte ich auf meinem produktiven Server auch den neuen Indianer installieren.

mfG
Ice

Die Performance-Unterschiede zwischen mod_fcgid und mod_fastcgi sind minmal, ich denke nicht spürbar bzw sogar nicht wirklich messbar. Es sind halt nur winzige Wrapper, die zwischen dem Apache und den php-fcgi-Prozessen stehen, mehr nicht.

Vorteil von mod_fcgid ist, dass es aktiv weiterentwickelt wird, und ein wesentlich besseres Prozess-Management hat.

Der Lighty hat mich persönlich auch noch nicht überzeugt. Sicherlich ist er sehr schnell, aber es fehlt einfach noch zu viel, bzw teilweise ist er inkompatibel zum Apache (zB mod_rewrite, oder wurde das "gefixed"?)

Außerdem sieht zumindest der Trac (Bugs und Tickets) sehr nach einem 1-2 Mann Projekt aus, und bei so Dingen bin ich immer äußerst vorsichtig.

kase wrote:bzw teilweise ist er inkompatibel zum Apache (zB mod_rewrite, oder wurde das "gefixed"?)

Wieso sollte er kompatibel sein, ist ein grundlegend anders gestrikter Webserver :P

mod_rewrite funktioniert bei mir tadellos, ohne Probleme.

kase wrote:Außerdem sieht zumindest der Trac (Bugs und Tickets) sehr nach einem 1-2 Mann Projekt aus, und bei so Dingen bin ich immer äußerst vorsichtig.

So weit ich weiss entwickelt das nur Jan Knetschke.

Als Hinweis nebenbei: Wir setzen den LightTPD produktiv ein und das rootforum wird ebenfalls vom lighty ausgeliefert ;)

Gruß
dtdesign