Sichere PHP Einstellungen

#1
Hallo,

was in die php.ini reingehört weis ich, aber was nimmt man am besten als PHP? FastCGI, suPHP, CGI oder ModPHP? Hintergrund ist wir haben einige Kunden die mit Joomla und Wordpress unterwegs sind und Ihre Setups nicht regelmässig updaten.

Und warum passiert folgendes, ich habe bei einer Webseite von suPHP auf FastCGI umgestellt. Wenn man die Webseite danach aufruft bekommt man einen 403?

SW
 

Till

Administrator
#2
mod_php ist am unsichersten, da es mkit den rechten des Webservers läuft.

Empfehlenswert ist:

fcgi-php + suexec (für Seiten mit viel Traffic)
cgi-php + suexec oder suphp (für Seiten mit wenig Traffic)


Und warum passiert folgendes, ich habe bei einer Webseite von suPHP auf FastCGI umgestellt. Wenn man die Webseite danach aufruft bekommt man einen 403?
Du musst zusätzlich die Checkbox bei "Suexec" setzen.
 
#3
Hier hat doch mal jemand angefangen ein Wiki für ISP3 zu schreiben.
Ist das Projekt eig. noch aktiv? Wenn ja könnte so etwas da vielleicht auch rein.
 

Till

Administrator
#5
und ich hätte gedacht gerade bei joomla würde sich suphp empfehlen oder liege ich da nun komplett daneben?
Das hängt vom Traffic der Webseite ab.

Für Joomla ist es wichtig, das die Scripte unter dem User des webs laufen. Dies ist bei suphp der Fall, aber auch bei fcgi-php und cgi-php wenn gleichzeitig suexec für das web aktiviert ist.

Also bei Seiten mit wenig traffic, nimmt man suphp oder aber php als cgi + suexec. Bei Seiten mit viel Traffic nummt man fcgi-php + suexec.
 
#6
Genau zu dem Thema hätte ich mal noch ne Frage. Ich dachte eigentlich es sei eine gute Idee alle Seite mit suPHP laufen zu lassen. Das hab ich bei einem Projekt versucht und erhalte dann einen Error 500. Die Inhalte der Webseite gehören alle web20:client3 so wie sie nach dem FTP Upload auch angelegt wurden. Auch die Rechte sollten absolut passen. Versteh also nicht wieso ich diesen Fehler bekomme. Ich hab das jetzt umgestellt auf Fast-CGI ohne suexec und die Seite läuft einwandfrei.

Auf dem alten Server hatte ich immer das Problem, dass alle Webordner unter www-run liefen und dadurch ein Problem entstanden ist wenn ich Dateien per FTP oder / und per Web Formular hoch geladen hab. Denn die Dateien vom FTP gehörten dann dem webx_webmaster:webx und vom Formularupload her dem www-run:www und das beißt sich spätestens bei Save Mode und vor allem auch beim FTP Download oder Löschen.

Wie konfiguriere ich denn nun am besten die Webprojekte auf dem neuen Server damit es egal ist ob ich Daten per FTP hoch lade oder mittels Web Formular z.B. in einer Bildergalerie einfüge? Das muss doch irgendwie möglich sein das es solche Probleme nicht gibt oder?
 

Till

Administrator
#7
Genau zu dem Thema hätte ich mal noch ne Frage. Ich dachte eigentlich es sei eine gute Idee alle Seite mit suPHP laufen zu lassen. Das hab ich bei einem Projekt versucht und erhalte dann einen Error 500. Die Inhalte der Webseite gehören alle web20:client3 so wie sie nach dem FTP Upload auch angelegt wurden. Auch die Rechte sollten absolut passen. Versteh also nicht wieso ich diesen Fehler bekomme.
Schau ins errorlog.

Ich hab das jetzt umgestellt auf Fast-CGI ohne suexec und die Seite läuft einwandfrei.
Das ist eine sehr schlecht Kombination. fastcgi niemals ohne suexec, oder Du hast die gleichen Probleme wie mit mod_php

Wie konfiguriere ich denn nun am besten die Webprojekte auf dem neuen Server damit es egal ist ob ich Daten per FTP hoch lade oder mittels Web Formular z.B. in einer Bildergalerie einfüge? Das muss doch irgendwie möglich sein das es solche Probleme nicht gibt oder?
Siehe #2
 
#8
OK das heißt die beiden Konfigurationen die man eigentlich nehmen sollte ist entweder suPHP ohne suExec oder Fast-CGI mit suExec. Merk ich mir mal.

Wenn ich aber besagtes Webprojekt auf suPHP stelle erhalte ich laut Log folgende Meldung
domain.de:80 127.0.0.1 - - [23/Jun/2010:15:16:17 +0200] "GET /index.php HTTP/1.1" 500 829 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.4) Gecko/20100611 Firefox/3.6.4"
domain.de:80 127.0.0.1 - - [23/Jun/2010:15:16:18 +0200] "GET /index.php HTTP/1.1" 500 829 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.4) Gecko/20100611 Firefox/3.6.4"
domain.de:80 127.0.0.1 - - [23/Jun/2010:15:17:04 +0200] "GET /index.php HTTP/1.1" 500 829 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.4) Gecko/20100611 Firefox/3.6.4"
domain.de:80 127.0.0.1 - - [23/Jun/2010:15:17:11 +0200] "GET /index.php HTTP/1.1" 500 829 "http://www.domain.de/" "Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.4) Gecko/20100611 Firefox/3.6.4"
Und das ist für mich jetzt nicht wirklich aussagekräftig oder? Ich seh halt den Error 500 aber das ich den hab weiß ich auch ohne Log ;)

Im Error Log steht übrigens nichts! Folgendes steht im errorlog zu genau der gleichen Zeit bzw. kurz vor dem anderen.
[Wed Jun 23 15:16:01 2010] [notice] Graceful restart requested, doing restart
[Wed Jun 23 15:16:05 2010] [notice] mod_fcgid: process /var/www/aganfo.de/web/index.php(29020) exit(shutting down), terminated by calling exit(), return code: 0
[Wed Jun 23 15:16:05 2010] [notice] Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny8 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g configured -- resuming normal operations
[Wed Jun 23 15:16:05 2010] [warn] long lost child came home! (pid 28633)
 

Till

Administrator
#9
Die Meldungen im error.log sind ok, die stammen von der Umschaltung fastcgi auf suphp. Poste doch bitte mal die suphp.conf Datei.
 
#10
Hier mal meine suphp.conf
[global]
;Path to logfile
logfile=/var/log/suphp/suphp.log

;Loglevel
loglevel=info

;User Apache is running as
webserver_user=www-data

;Path all scripts have to be in
docroot=/var/www

;Path to chroot() to before executing script
;chroot=/mychroot

; Security options
allow_file_group_writeable=false
allow_file_others_writeable=false
allow_directory_group_writeable=false
allow_directory_others_writeable=false

;Check wheter script is within DOCUMENT_ROOT
check_vhost_docroot=true

;Send minor error messages to browser
errors_to_browser=false

;PATH environment variable
env_path=/bin:/usr/bin

;Umask to set, specify in octal notation
umask=0022

; Minimum UID
min_uid=100

; Minimum GID
min_gid=100


[handlers]
;Handler for php-scripts
x-httpd-suphp=php:/usr/bin/php-cgi

;Handler for CGI-scripts
x-suphp-cgi=execute:!self
umask=0022
 

Till

Administrator
#11
1) Haben die Web user und client Gruppen eine uid bzw. gid > 100 in /etc/passwd und /etc/group? Wenn nein, musst Du min_uid und min_gid in der suphp.conf verringern.

2) Gibt es das PHP Binary mit dem Pfad: /usr/bin/php-cgi

3) Ändere mal:

x-httpd-suphp=php:/usr/bin/php-cgi

in:

x-httpd-suphp="php:/usr/bin/php-cgi"

4) Irgendwelche Fehlermeldungen im log /var/log/suphp/suphp.log?
 
#12
Also die Web User und Groups haben ID's jenseits von 1000 (5005 z.B.) von daher sollte das genügen

Das PHP Binary gibt es und liegt exakt dort wie angegeben

Die Änderung von x-httpd-suphp="php:/usr/bin/php-cgi" hab ich gemacht, aber hat nicht geholfen

Im Log von suPHP steht nichts interessantes drin bis auf die Zugriffe eben aber keine Fehlermeldung oder sonst irgendwas das er was nicht findet oder sonstiges.

Ich meine letztenendes ist mir das egal auf meinem Server laufen ca. 30 Projekte wovon höchstens 6 oder 7 erwähnenswerte Belastungen zustande bringen und ich hab den EQ6 von Hetzner mit dem Core i7 und so der wird denk ich mal so bald nicht ausgelastet sein egal wie ich PHP laufen lasse.

Ich hatte nur irgendwo mal gelesen man soll in jedem Fall suPHP nehmen weil das das einzig wahre sein soll im Bereich Tempo und Sicherheit. Kann natürlich auch falsch sein was ich gelesen hab.
 

Till

Administrator
#13
Ich hatte nur irgendwo mal gelesen man soll in jedem Fall suPHP nehmen weil das das einzig wahre sein soll im Bereich Tempo und Sicherheit. Kann natürlich auch falsch sein was ich gelesen hab.
Das war zumindest im Bezug auf Geschwindigkeit komplett falsch. Bei suphp wird bei jedem Seitenaufruf ein neuer cgi php Prozess gestartet. Suphp ist also genauso langsam wie cgi php. fcgi-php hingegen verwendet einen oder mehrere permanent laufende PHP Prozesse. Das ist deutlich schneller (in etwa so schnell wie mod_php), braucht aber halt mehr Speicher im leerlauf.
 

Werbung

Top