# rm-rf.es

Con la instalación de IonCube loader tendremos la posibilidad de visualizar páginas php con contenido codificado con ionCube. La instalación es sumamente sencilla en Windows (en este caso 2003 Server con php 5.2.X):

En primera instancia descargamos la extensión/módulo desde el sitio web de ioncube:

http://www.ioncube.com/loaders.php

Posteriormente, procedemos a descomprimir el fichero, dentro del cual encontraremos las versiones de los módulos para cada versión de PHP y dos scripts php para testear que la instalación se ha realizado correctamente:

ioncube_loader_win_4.1.dll
ioncube_loader_win_4.2.dll
ioncube_loader_win_4.3.dll
ioncube_loader_win_4.4.dll
ioncube_loader_win_5.0.dll
ioncube_loader_win_5.1.dll
ioncube_loader_win_5.2.dll
ioncube-loader-helper.php
ioncube-encoded-file.php

Bien, llegados a este punto debemos copiar el módulo correspondiente a nuestra versión de php en la carpeta donde guardemos todos los módulos de php, normalmente “ext” dentro de la carpeta PHP.

Posteriormente, llamamos al módulo desde el fichero de configuración php.ini añadiendo la siguiente línea, que hace referencia al módulo comentado antes:

zend_extension_ts = "c:\carpeta_php\ext\ioncube_loader_win_5.2.dll"

Guardamos y testeamos con un navegador si la instalación se ha realizado correctamente, ejecutando el script ioncube-encoded-file.php, tendrá que mostrar lo siguiente:

This file has been successfully decoded. ionCube Loaders are correctly installed.

A estas altura todos conocemos la potencia y versatilidad del lenguaje PHP. Existen no obstante ciertas funciones que utilizadas de forma incorrecta, o con fines maliciosos (exploits, crackeos, etc) comprometan seriamente la seguridad del servidor que está ejecutando el php. Estamos hablando de bugs en una versión de php instalada, bugs en la programación, mala securización de un servidor y muchos más puntos a tener en cuenta y que pueden provocar graves problemas de seguridad en una máquina.

Un buen punto sobre el que comenzar a securizar php, es deshabilitar ciertas funciones potencialmente peligrosas, y que si nuestra programación no utiliza, es 100% recomendable desactivar completamente. Para desactivar funciones, debemos listarla en el fichero de configuración de php (php.ini), utilizando la directiva “disable_functions“. El fichero php.ini normalmente se encuentra en /etc/php.ini, no obstante podéis buscarlo con el comando:

whereis php

Un ejemplo sobre el que podemos comenzar de funciones a deshabilitar es el siguiente:

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

En php.net podéis observar las tareas que desempeña cada una y revisar la viabilidad de su desactivación. En otros sitios web van más allá, y amplian mucho más la lista de funciones a 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"

Aquí ya entran las necesidades de cada uno y la adaptación al entorno de trabajo. Os recomiendo investigar las funciones. Securizar este punto os puede librar de muchos disgustos.

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

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

Puede deshabilitarse a través del fichero .htaccess (servidores apache + cgi como DSO) o en un fichero php.ini personalizado (servidores apache + cgi ó apache + SUPHP), en los dos casos modificando el parámetro session.trans_id.

En .htaccess:

php_flag session.use_trans_sid off

En php.ini:

session.use_trans_sid = off

Es posible que tengáis un servidor Windows 2003 server con IIS funcionando correctamente, los websites ejecutan sin problemas php o perl, pero en el momento que aislamos un website (Application Pool Isolation) tanto PERL como PHP dejan de funcionar, dando normalmente el siguiente error:

HTTP Error 403 – Forbidden: Access is denied

Este problema es debido a que cada identidad de application pool (usuario configurado en la aplicación para ejecución de scripts, php, etc) debe ser miembro del grupo IIS_WPG de modo que nos aseguremos que tenga permisos para ejecutar php o perl.

Realizaremos las siguientes modificaciones en las políticas de seguridad para solventar el problema, iremos a:

START > Administrative Tools > Local Security Policy

Seleccionamost Local Policies > User Rights Assignment

En el listado que aparezca, buscamos Adjust memory quotas for a process y pinchamos en las propiedades. Posteriormente Add User or Group > Object Types marcando la casilla de  Groups y OK the Object Types dialogue. Ahora en la ventana Enter the object names to select introduce IIS_WPG y pincha OK.

El mismo proceso debe ser ejecutado en Replace a process level token. Reiniciaremos la máquina y ya debería funcionar correctamente. Todos los miembros de IIS_WPG pueden ejecutar aplicaciones CGI sin problemas.

Vía | Asimo Support

Ha salido a la luz una nueva versión de php, la PHP 5.2.8, esta versión soluciona un bug encontrado en la reciente versión también publicada 5.2.7 relacionada con el funcionamiento de magic_quotes, bug de seguridad que abría un agujero de seguridad al tener activo “magic_quotes_gpc”

Se recomienda actualizar a dicha versión, y si tienes la versión 5.2.7 y no deseas actualizar aplica el siguiente “parche” a tu php.ini para arreglar el problema de magic_quotes:

“filter.default_flags=0″

Más información en php.net

Los repositorios por defecto de la distribución CentOS no permiten actualizar a php 5 ya que para dicha versión lo máximo (creo recordar) que es php 4.3, lo mismo sucede con, por ejemplo, las versiones de MySQL.

Existe una solución alternativa a tener que instalar los paquetes vía rpm o compilando manualmente y es utilizando temporalmente un repositorio extra que sí disponga de estas actualizaciones. Digo temporalmente porque quizás no nos interese utilizar esos repositorios para todos los paquetes instalados en el sistema (fallos de dependencias, no querer actualizar en updates generales, etc), para ello podemos utilizarlos únicamente para los paquetes que deseamos instalar con el parámetro  “–enablerepo=repositorio“.

Volviendo al tema de php5, si quisieramos actualizarlo podríamos hacerlo del siguiente modo:

yum --enablerepo=centosplus search php*

Esto buscaría los paquetes de php disponibles en todos los repositorios incluido centosplus, que es el repositorio que permite estas actualizaciones. Si vemos correcto los paquetes a actualizar, lo hacemos:

yum --enablerepo=centosplus install php*

Como siempre, atentos a las dependencias que se instalan/actualizan y confirmad que no generen fallos con lo que tengáis instalado actualmente.

En resumen, recordad que podéis utilizar en un momento determinado cualquier respositorio con el parámetro “–enablerepo=repositorio” y que CentOSplus contiene muchísimos y útiles paquetes para actualizar en centOS 4.6 sin tener que pasar a CentOS 5

Si acabáis de montar un servidor apache con suPHP y al tratar de ejecutar cualquier PHP el navegador muestra “Internal Server Error“, y el log de apache muestra “Premature end of script headers” lo más probable es que hayáis instalado la versión cliente (CLI) de php en vez de la versión CGI (php-cgi). Para solventar esto debéis copiar el binario de php CGI en donde se supone debe estar instalado el binario de php (donde vaya apache a buscarlo vamos).

En mi caso, en un servidor CentOS el binario php-cgi estaba aquí:

/usr/bin/php-cgi

Y apache utilizaba el binario de php-cliente:

/usr/bin/php

Bien, entonces he guardado un backup del cliente y he creado un enlace simbólico para que /usr/bin/php sea lo mismo que /usr/bin/php-cgi, podéis también sobreescribirlo, lo que queráis. Con este cambio el problema debería quedar solucionado.

Si bajo un servidor web IIS con PHP, os encontráis con la situación de que las páginas de error 404 funcionan correctamente para archivos .html o .asp, pero no para los .php el problema es el que explico a continuación.

En lugar de aparecer la página de error aparecerá:

“No input file specified”

Bien, esto es debido a que por defecto, en la configuración del website en el que tenemos el problema, no está marcada la opción “check If file exists.”

Para marcarla, acceder al website en cuestión -> Properties -> Home Directory -> Configuration y en la configuración de la extensión .php:

Reiniciamos el website y solucionado.