En esta entrada vamos a ver unos cuantos puntos que nos servirán para securizar PHP en nuestro servidor web. Nos centramos en la configuración propia de PHP, hay que tener en cuenta que la securización de la capa aplicación es tanto o más importante que la de la configuración del servidor. Hay que tener siempre actualizados a la última versión estable y con los parches de seguridad correctamente aplicados cualquier cms o script de terceros tipo WordPress, Joomla, Oscommerce, etc.

Ocultar la versión de PHP

En su día hice un artículo completo sobre esto, podéis verlo aquí (ocultar la versión de PHP). Básicamente evitamos que con un simple telnet puedan averiguar la versión de PHP que hay corriendo en el servidor:

# telnet servidor 80

Connected to xxx.com (xx.xx.xx.xx).
Escape character is '^]'.
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Fri, 13 Aug 2010 14:18:09 GMT
Server: Apache/1.3.26 (Unix) mod_gzip/1.3.26.1a PHP/5.3.3
Last-Modified: Fri, 12 Feb 2010 12:22:56 GMT
ETag: "44967c-6f-53ca4800"
Accept-Ranges: bytes
Content-Length: 111
Connection: close
Content-Type: text/html

Connection closed by foreign host.

Para evitar esto cambiamos a off la siguiente variable en el fichero de configuración general php.ini:

expose_php Off

Deshabilitar funciones peligrosas

También hice un artículo hace un tiempo: PHP: Deshabilitar funciones peligrosas. Existen funciones que en servidores con aplicaciones estándar rara vez se usan, pero que por contra pueden generar graves problemas de seguridad si el atacante consigue utilizarlas. Es preferible desactivar el mayor número posible y en caso de que una de ellas sea necesario valorar su activación o proponer alternativas.

Las funciones a deshabilitar se añaden en la directiva “disable_functions” en el fichero php.ini. Aquí tenéis un ejemplo con funciones peligrosas que conviene desactivar:

disable_functions = “apache_child_terminate, apache_setenv, define_syslog_variables, escapeshellarg, escapeshellcmd, eval, exec, fp, fput, ftp_connect, ftp_exec, ftp_get, ftp_login, ftp_nb_fput, ftp_put, ftp_raw, ftp_rawlist, highlight_file, ini_alter, ini_get_all, ini_restore, inject_code, mysql_pconnect, openlog, passthru, php_uname, phpAds_remoteInfo, phpAds_XmlRpc, phpAds_xmlrpcDecode, phpAds_xmlrpcEncode, popen, posix_getpwuid, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, posix_setuid, posix_uname, proc_close, proc_get_status, proc_nice, proc_open, proc_terminate, shell_exec, syslog, system, xmlrpc_entity_decode”

O un ejemplo más conservador:

disable_functions ="system,passthru,escapeshellarg,escapeshellcmd,proc_close,proc_open,ini_alter,popen,show_source,pcntl_exec"

deshabilitar session ID en URL

Si queremos que las URL’s de nuestros sitios PHP no muestren los ID de sesiones:

http://ejemplo.com/?PHPSESSID=4kgj577sgabvnmhjgkdiuy1956if6ska

Modificamos la directiva siguiente en el fichero php.ini:

session.use_trans_sid = off

Deshabilitar register_globals

Pese a ser una directiva antigua y que se encuentra en periodo de extinción todavía quedan desarrolladores/programadores que la utilizan. Esta función permite al atacante manipular cualquier variable global definida en la programación. Por defecto está deshabilitada en las versiones actuales de PHP, pero conviene revisarlo por si en algún momento se ha activado:

register_globals = Off

Desactivar acceso a URL remotas en funciones de manejo de ficheros

Funciones como include, fopen o file_get_contents permiten, además de hacer llamadas a ficheros locales, llamar a ficheros vía URL, esto puede provocar graves errores de seguridad invocando a scripts maliciosos que se encuentran fuera de nuestro servidor y su ejecución remota.

Para deshabilitarlo modificamos la directiva allow_url_fopen a Off en el php.ini:

allow_url_fopen = Off

Evitar el acceso a la información de PHP

Como ya sabéis con un simple script como el siguiente podemos ver vía URL toda la información de PHP, su compilación, sus módulos activados, versión, directivas de configuración, etc.

<? phpinfo() ?>

Si queremos desactivarlo, únicamente hay que modificar a Off la siguiente directiva en el fichero php.ini:

expose_php = Off

Si en algún momento necesitáis conocer alguna información, siempre podéis averiguarla desde línea de comandos: información sobre PHP desde línea de comandos

Safe Mode

safe_mode = On

Si bien por defecto safe_mode On puede significar una restricción demasiado fuerte en determinados entornos, puede ayudar mucho a incrementar la seguridad de nuestro servidor. Activar safe_mode implica que los scripts PHP únicamente pueden acceder a los ficheros que tienen como propietario el mismo que ellos. De este modo evitamos por ejemplo que tengan acceso de lectura a ficheros de sistema como /etc/passwd entre otros.

Efectivamente, esto puede ser un problema en el momento que necesitamos acceder a información generada por otros usuarios en el sistema (ficheros de otras aplicaciones. La solución es la siguiente:

safe_mode = Off
safe_mode_gid = On

Activamos safe_mode_gid en lugar de safe_mode, de modo que en lugar de revisar el usuario se revisa el grupo. Independientemente del UID del fichero, necesitaremos que estar dentro del grupo para poder acceder al ficheros. El grupo del script PHP deberá ser el mismo que el del fichero a acceder.

Otro punto a tener en cuenta con safe_mode es que no podremos ejecutar binarios. Únicamente aquellos que ubiquemos en el directorio especificado en la configuración:

safe_mode_exec_dir = /directorio

Esto se solaparía con las funciones deshabilitadas anteriormente, como por ejemplo system() o exec().

open_basedir

open_basedir = /directorio

La directiva open_basedir permite configurar que PHP pueda acceder únicamente a los ficheros de un único directorio (y sus subdirectorios). Es una buena forma de enjaular PHP si realmente sólo necesitamos que acceda a un determinado directorio.

Visualización y registro de errores

display_errors = Off
log_errors = On
error_log = /ruta/fichero/log

Con estas tres directivas, evitamos que cualquier error o warning se muestre por pantalla y hacemos que se registren directamente en un log especificado. De este modo podemos evitar que se muestre información sensible por pantalla. También podéis hacer uso de la directiva error_reporting si queréis mostrar por pantalla los errores. Con ella podéis especificar que se muestren únicamente los warning, los notice o lo que queráis.

SQL Injection

En su día se utilizaba magic_quotes para limpiar los datos de entrada de un script PHP, pero es una directiva obsoleta a partir de PHP 5.3 así que no merece la pena hablar de ella. En su defecto, si usáis servidor web Apache, os recomiendo encarecidamente configurar mod_security y habilitar sus reglas que permiten detectar y parar una gran cantidad de ataques de este tipo, y sino, puedes crear tus propias reglas.

Como último apunte, conviene siempre si es posible mantener una versión estable de PHP, libre de bugs y fallos de seguridad. Seguro además que una vez aplicados estos trucos os toca lidiar con los programadores. Se quejarán de algo seguro ;)

También te puede interesar:

• Ocultar la versión de PHP
• Encriptar un filesystem con LUKS y cryptsetup
• Stub Start Error en Oracle iPlanet Web Server: PHP + FastCGI
• Configurar PHP + FastCGI en Oracle iPlanet Web Server

Stub Start Error
This server has encountered an internal error which prevents it from fulfilling your request. The most likely cause is a misconfiguration. Please ask the administrator to look for messages in the server’s error log.

Y al revisar los logs de error de la instancia vemos lo siguiente:

[12/Oct/2011:10:13:28] failure ( 1023): for host 192.168.1.128 trying to GET /test.php, responder-fastcgi reports: FCGI1058: Process creation failure
[12/Oct/2011:10:13:43] failure ( 1023): for host 192.168.1.128 trying to GET /test.php, responder-fastcgi reports: FCGI1058: Process creation failure

El servidor web no es capaz de lanzar los procesos fastcgi de php, esto lo podemos ver porque ni siquiera se crea el log de fastcgi (Fastcgistub.log). Según he visto en este post de un foro es un problema común en máquinas con poca memoria swap configurada. En mi caso estaba claro porque esta prueba estaba siendo realizada sobre una pequeña máquina virtual. La solución es tan simple como aumentar el tamaño del area de intercambio o añadir más. Si no os apetece tocar la swap actual porque está en uso podéis añadir una nueva con zfs:

# zfs create -V 1G rpool/swap-extra
# swap -a /dev/zvol/dsk/rpool/swap-extra
# swap -l
swapfile             dev    swaplo   blocks     free
/dev/zvol/dsk/rpool/swap 171,2         8  1048568  1048568
/dev/zvol/dsk/rpool/swap-extra 171,3         8   819192   819192

Una vez activada la nueva swap los procesos FastCGI deberían arrancar sin problemas y ejecutar los PHP sin errores.

También te puede interesar:

• Configurar PHP + FastCGI en Oracle iPlanet Web Server
• Introducción a SMF (Service Management Facility) en Solaris
• Gestionar el storage en Solaris con zfs y zpool
• Gestión de snapshots en ZFS

Una vez bajado el patch (p12680045_10000_Generic.zip en mi caso), procedemos a descomprimirlo y copiar la carpeta “php” resultante al directorio plugins en la ruta donde hayamos instalado el servidor web:

# cp -Rp /var/tmp/php /opt/iplanet-webserver7/plugins/

Exportamos la variable LD_LIBRARY_PATH con la ruta hacia este directorio:

# export LD_LIBRARY_PATH=/opt/iplanet-webserver7/plugins/php

Ahora, podemos hacer una verificación de que php funciona desde línea de comandos:

# cd /opt/iplanet-webserver7/plugins/php/bin && ./php -v
PHP 5.2.X (cgi-fcgi) (built: Jan XX XXXX 22:31:04)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2011 Zend Technologies

Llegado este punto, únicamente tendríamos que activar php para la instancia en la que queramos usarlo, en este caso en la instancia https-website. Para ello haremos uso del script setupPHP disponible en el directorio “php”:

# cd /opt/webserver7/plugins/php/
# ./setupPHP -instancename=https-website

UPDATED: /opt/iplanet-webserver7/https-www/config/magnus.conf
UPDATED: /opt/iplanet-webserver7/https-www/config/obj.conf
UPDATED: /opt/iplanet-webserver7/https-www/config/mime.types

Como veis en la salida del comando, automáticamente se han actualizado los ficheros de configuración de la instancia, añadiendo los handler de php, las configuraciones y directivas de FastCGI, etc.

Si utilizáis un usuario distinto de root para correr el servidor web, aseguraos de que los propietarios de los tres ficheros anteriores se mantienen bien, sino no arrancará la instancia.

Ya solo quedaría hacer el pull-config con los nuevos cambios de configuración de la instancia y el deploy. Podemos hacerlo a través de la interfaz web de administración de iPlanet Web Server o desde línea de comandos con wadm:

# /opt/iplanet-webserver7/bin/wadm [--user=admin-user] [--password-file=admin-pswd-file] [--host=admin-host] [--port=admin-port]
pull-config --config=www nodo
pull-config --config=website hostname
deploy-config website

También te puede interesar:

• Stub Start Error en Oracle iPlanet Web Server: PHP + FastCGI
• Introducción a SMF (Service Management Facility) en Solaris
• Gestionar el storage en Solaris con zfs y zpool
• Gestión de snapshots en ZFS

Para realizar esta configuración, debemos utilizar la directiva AddType en el fichero .htaccess del website o directamente a nivel general del servidor web en el fichero httpd.conf.

Lo primero que debemos verificar es que tenemos cargado en Apache el módulo mod_mime, que es el encargado de servir la directiva AddType.

# httpd -l | grep mime
  mod_mime.c

Una vez verificado, si quisieramos mapear las extensiones .html para servir contenido PHP, deberíamos añadir la siguiente directiva al fichero .htaccess:

AddType application/x-httpd-php .php .htm .html .shtml

Si tuvierais varias versiones de PHP instaladas en un mismo servidor, es posible que necesitéis especificar la versión del siguiente modo:

AddType application/x-httpd-php5 .php .htm .html .shtml

o

AddType application/x-httpd-php4 .php .htm .html .shtml

Esto lo podemos añadir también a nivel general en Apache, ya sea directamente en el httpd.conf o en el fichero php.conf junto con el resto de configuraciones de PHP. Si lo añadimos en httpd.conf reiniciamos el servicio tras hacerlo:

# /etc/init.d/httpd graceful

Ahora, si hacemos un fichero test.html con el siguiente contenido, al servirlo en el navegador web ejecutará el código PHP en lugar de mostrarlo como si fuera html puro y duro:

<h1>Prueba ejecutar PHP en fichero HTML</h1>
<? phpinfo ?>

También te puede interesar:

• Utilizar .htaccess / php.ini en Apache con suPHP
• 10 trucos para securizar PHP
• Stub Start Error en Oracle iPlanet Web Server: PHP + FastCGI
• Configurar PHP + FastCGI en Oracle iPlanet Web Server

# pecl install -R /usr/lib/php oauth
WARNING: channel "pecl.php.net" has updated its protocols, use "pecl channel-update pecl.php.net" to update
downloading oauth-1.1.0.tgz ...
Starting to download oauth-1.1.0.tgz (44,731 bytes)
............done: 44,731 bytes
6 source files, building
running: phpize
Configuring for:
PHP Api Version:         20041225
Zend Module Api No:      20060613
Zend Extension Api No:   220060519
building in /var/tmp/pear-build-root/oauth-1.1.0
running: /usr/lib/php/root/tmp/pear/oauth/configure
checking for egrep... grep -E
checking for a sed that does not truncate output... /bin/sed
checking for cc... cc
checking for C compiler default output file name... a.out
checking whether the C compiler works... configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
ERROR: `/usr/lib/php/root/tmp/pear/oauth/configure' failed

El error nos indica que no podemos ejecutar la compilación, en este caso es debido a que tenemos securizada la partición /tmp y no permitimos la ejecución en ella, pecl compila ahí de forma temporal el módulo.

# mount | grep ^/tmp
/tmp on /var/tmp type ext3 (rw,noexec,nosuid,bind)

Lo que vamos a hacer es una solución temporal, montamos /tmp con los requerimientos para poder hacer la compilación y después revertimos el cambio:

# mount -o remount,exec,suid /tmp
# pecl install -R /usr/lib/php oauth
# mount -o rw,noexec,nosuid,bind /tmp

Otra opción más segura y que evita tener que modificar el sistema de archivos /tmp es la que Santi nos ofrece en su comentario, exportamos la variable TMP a un lugar dentro de una partición con exec permitido e instalamos:

# mkdir -p /root/temporal
# export TMP=/root/temporal
# pecl install oauth

También te puede interesar:

• configure: error: libpng.(a|so) not found (compilando PHP con 64 bits)
• Cómo compilar Apache y PHP en Linux
• Instalar módulo OAuth de PHP en cPanel/WHM
• DB_File.xs:101: db.h: No such file or directory

). Lo primero que tenemos que hacer es verificar que tenemos instalados los paquetes devel de libpng y libjpeg. Podéis instalarlos por apt o yum según la distribución:

$ yum install libpng-devel.x86_64
$ yum install libjpeg-devel.x86_64

Nota: quizás también sea necesario instalar el devel de GD, ahora no lo recuerdo.

Si pese a instalar estos paquetes seguís recibiendo el mismo error, probablemente es porque a la hora de hacer el configure no encuentra el lugar donde están las librerías (por ser de 64 bits). Entonces la solución será especificar que es un sistema de 64 bits y sus librerías con el parámetro

Quedaría algo así (+ los módulos que instaléis además de GD):

$ ./configure --with-gd --with-libdir=lib64

También te puede interesar:

• pecl: configure: error: cannot run C compiled programs
• Cómo compilar Apache y PHP en Linux
• DB_File.xs:101: db.h: No such file or directory
• Elegir el compilador correcto para Perl en Solaris

Lo primero que tenemos que comprobar es que tengamos instalados los compiladores necesarios (C / C++…) para poder empezar a trabajar, en RHEL y CentOS podemos instalarlos por yum, y en Debian y similar por apt:

# yum install gcc gcc-c++ autoconf make automake

Compilar Apache

Para compilar Apache lo primero que debemos hacer es bajarnos las fuentes de la versión que queramos instalar. En este caso vamos a bajar la última versión estable de la rama 2.2, la 2.2.17:

# wget http://apache.rediris.es//httpd/httpd-2.2.17.tar.gz

Descomprimimos (podéis hacerlo en el directorio /usr/src/ destinado a las fuentes o en donde más rabia os dé):

#  tar -xzvf httpd-2.2.17.tar.gz

Nos ubicamos en la ruta donde hayamos descomprimido las fuentes:

# cd /usr/src/httpd-2.2.17

Ya estamos listos para comenzar a configurar nuestra instalación. El primer paso de toda compilación es el script configure, básicamente es el momento en el que podemos personalizar como queramos nuestra instalación (lugar donde instalar apache, módulos a compilar, cómo cargar esos módulos, etc) también se realizan ciertos chequeos para verificar que la compilación se puede realizar correctamente.

Para ver todas las posibilidades que nos ofrece la configuración, siempre tendremos que ejecutar la ayuda, resultaría tedioso explicar aquí todas las opciones de compilación así que nos vamos a centrar en una instalación básica, para personalizar vuestras instalaciones:

# ./configure --help

Bien, en nuestro caso la línea de configure va a ser la siguiente:

# ./configure --prefix=/usr/local/apache --enable-headers --enable-rewrite --enable-expires --enable-so --disable-authz-default

• –prefix=<ruta> será la ruta en la que vamos a instalar Apache, en este caso /usr/local/apache.
• –enable-MODULO: para la activación de módulos utilizamos este parámetro. En la línea de configuración vemos que hemos activado mod_rewrite, mod_headers y mod_expires. Si no especificamos nada, los módulos se cargan de forma estática, para cargarlos de forma dinámica (DSO, explicado en el siguiente punto) utilizamos –enable-MODULO=shared.
• –enable-so Permitimos a Apache cargar módulos compartidos (Dynamic Shared Object (DSO)), php será uno de ellos. Esta opción también nos permitirá añadir nuevos módulos sin necesidad de recompilar y de forma dinámica (añadiendo simplemente el módulo mediante “Load Module” en la configuración). Los modulos que añadamos a través de esta línea de compilación, y sin especificar shared se instalarán de forma estática.
• –disable-MODULO: He puesto un ejemplo de deshabilitar un módulo en la línea de compilación para que veáis que se pueden deshabilitar módulos (por defecto Apache carga algunos módulos que quizás no te interesen), en el ejemplo desactivamos authz-default

Una vez que tengamos claro que queremos y que no queremos instalar, podemos construir nuestra compilación, para ello simplemente ejecutamos make (según la cantidad de módulos que hayas configurado le puede costar un rato, puedes ir a tomar un café mientras ;) ):

# make

Y una vez que haya terminado, finalizamos la compilación e instalamos apache:

# make install

Cuando haya terminado ya podemos probar nuestra instalación de apache, lo arrancamos:

# /usr/local/apache/bin/apachectl start

Si accedemos vía web, por ejemplo desde la IP del servidor o el host que tenga configurado, deberíamos visualizar lo siguiente:

It works!

Cómo actualizar Apache

La actualización por compilación de fuentes es bastante sencilla. Simplemente tendríamos que seguir este mismo proceso, pero en el punto del configure apache nos lo pone más fácil. En la ruta /usr/local/apache/build encontraréis un fichero llamado config.nice que guarda vuestros parámetros de compilación, con lo que podéis usar dicho fichero en lugar de crear un nuevo configure. El proceso sería entonces, bajar las fuentes de la nueva versión y:

# ./config.nice
# make
# make install

Nota: Los ficheros de configuración, logs y documentos no se sobreescribirán durante la actualización.

Compilar PHP

Ahora que ya tenemos Apache funcionando, es hora de instalar PHP. Vamos a seguir el mismo procedimiento que para compilar Apache. En este caso vamos a instalar PHP con soporte para MySQL y algún otro módulo que veremos más adelante.

Empezamos descargando las fuentes desde el sitio web de PHP. En este caso la última versión estable de la rama 5.3, la 5.3.6. De nuevo nos colocamos en el directorio src o donde queráis trabajar mientras instalamos:

# cd /usr/sr
# wget http://es2.php.net/get/php-5.3.6.tar.gz/from/es.php.net/mirror

Descomprimimos y nos colocamos dentro del directorio:

# tar -xzvf php-5.3.6.tar.gz
# cd php-5.3.6

Ahora, al igual que con Apache llega el momento de crear la línea de configuración, el configure. Del mismo modo podemos seleccionar la ruta de instalación, los módulos y una buena cantidad de parámetros para personalizar nuestra instalación. Es imprescindible pues revisar la ayuda:

# ./configure --help

Una vez que tenemos claro que y como queremos instalar, comenzamos con el configure:

# ./configure --prefix=/usr/local/php --with-config-file-path=/usr/local/php --with-apxs2=/usr/local/apache/bin/apxs --with-mysql --enable-ftp --disable-pdo --disable-ctype

Pasamos a explicar esta línea de configure:

• –prefix: al igual que con Apache especificamos la ruta en la que instalaremos php.
• –with-config-file-path: especificamos la ruta donde se encontrará el fichero de configuración php.ini.
• –with-apxs2: como vamos a compilar php como módulo dinámico (DSO) updatede apache especificamos la ruta a apxs.
• –with-libxml2: para evitar el error provocado porque la compilación no encuentra xml2-config necesitaremos tener instalado libxml2-devel (yum install libxml2-devel. El error es configure: error: xml2-config not found. Please check your libxml2 installation.
• –with-mysql: habilitamos soporte para MySQL. Por supuesto, antes de habilitar cualquier extensión, si depende de algún programa hay que instalarlo antes, en este caso el cliente MySQL y las headers (paquete devel):

  yum install mysql mysql-devel

• –enable-ftp: habilitamos soporte para FTP. Podemos habilitar cualquier otro módulo con –enable-MODULO
• –disable-pdo: deshabilitamos el soporte para PDO. Podemos deshabilitar cualquier otro módulo con –disable-MODULO

Una vez seleccionados los módulos a instalar y las opciones correspondientes podemos comenzar a compilar (puede tardar un rato):

# make

Si todo ha ido bien y no hemos recibido errores podemos finalizar la instalación:

# make install

Una vez instalado automáticamente habrá añadido la carga del módulo en nuestra configuración de apache (fichero httpd.conf):

LoadModule php5_module modules/libphp5.so

Ahora solo nos queda indicar a Apache como tiene que interpretar los ficheros php, tenemos que añadir la siguiente línea dentro del fichero httpd.conf. Podemos añadirla junto a los demás AddType, buscadlos y colocadla debajo:

AddType application/x-httpd-php .php

Ahora solo queda reiniciar apache y verificar el funcionamiento de php. Antes comprobamos que la sintaxis del fichero de configuración httpd.conf es correcta:

# /usr/local/apache/bin/apachectl configtest
Syntax OK

Reiniciamos apache:

# /usr/local/apache/bin/apachectl restart

Podemos crear un fichero de pruebas en php para verificar todos los parámetros y módulos de la instalación de php, el contenido es el siguiente:

<? phpinfo(); ?>

Lo colocamos en el DocumentRoot por defecto, en nuestro caso es /usr/local/apache/htdocs y lo ejecutamos desde el navegador, el resultado es el siguiente, ya tenemos Apache y php operativo:

También te puede interesar:

• pecl: configure: error: cannot run C compiled programs
• configure: error: libpng.(a|so) not found (compilando PHP con 64 bits)
• Activar pcntl para PHP en cPanel (easyapache)
• suPHP: “Premature end of script headers” en el error_log

Si recibís el siguiente error en el proceso de compilación, tendréis que instalar pcre y pcre devel, en CentOS y RHEL:

/usr/include/php/ext/pcre/php_pcre.h:29:18: error: pcre.h: No such file or directory

# yum install pcre-devel.i386 pcre.i386

Otra opción, es hacerlo desde línea de comandos:

# pecl install -R /usr/lib/php oauth

También te puede interesar:

• pecl: configure: error: cannot run C compiled programs
• 10 trucos para securizar PHP
• Stub Start Error en Oracle iPlanet Web Server: PHP + FastCGI
• Configurar PHP + FastCGI en Oracle iPlanet Web Server

Todos recibían un error 500 (Internal Server Error), típico de suPHP, y en los logs se volcaba la siguiente información:

[Sun Oct 17 19:08:03 2010] [error] [client XX.XX.XXX.XX] SecurityException in Application.cpp:511: Unknown Interpreter: php
[Sun Oct 17 19:08:03 2010] [error] [client XX.XX.XXX.XX] Premature end of script headers: index.php

En este momento ya había entrado en modo pánico, pero rebuscando por Internet información sobre esta versión, he visto que había un pequeño cambio o bug (bueno, pequeño…) por el cual, en el fichero de configuración de suPHP (/etc/suphp.conf) los handlers tenían que ir entre comillas:

Antes:

;Handler for php-scripts
x-httpd-php=php:/usr/bin/php-cgi

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

Después:

;Handler for php-scripts
x-httpd-php="php:/usr/bin/php-cgi"

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

Tras este cambio, y reiniciar apache todo ha vuelto a funcionar a la normalidad.

También te puede interesar:

• suPHP: “Premature end of script headers” en el error_log
• Utilizar .htaccess / php.ini en Apache con suPHP
• 10 trucos para securizar PHP
• Stub Start Error en Oracle iPlanet Web Server: PHP + FastCGI

La solución es recurrir al repositorio testing de Centos 5, donde podemos instalar las versiones disponibles para 5.2.9 y 5.2.10 respectivamente que sí que son compatibles.

Instalar php-mcrypt con yum:

# yum --enablerepo=c5-testing install php-mcrypt

Instalar php-mbstring con yum:

# yum --enablerepo=c5-testing install php-mbstring



También te puede interesar:

• Instalar php 5.2.10 a través de YUM en CentOS
• Centos 4.6: Actualizar php4 a php5 con yum
• Cómo crear un repositorio local de yum
• 6 trucos útiles del gestor de paquetes yum