Resulta que viendo los headers de un sitio que frecuento (curl -i) me di cuenta que corren php-suhosin, el cual es una aproximación similar a mod_security, pero sin los problemas de licenciamiento del mismo, de hecho ya alguien en otro momento me lo había sugerido cuando tuve que dejar atrás mod_security cuando lo dejaron de soportar en Debian, ya que aunque considere el crear mi propio modulo y darle mantenimiento, a la larga veía mayor problema (aún cuando me sigue gustando mas el modo que tiene mod_security de prohibir la ejecución de cadenas especificas como wget algo o bash otro), así que a principio del año me instale suhosin en varias de mis maquinas, esta elección específicamente por que al iniciar el año tenia 2 apache 1.3.x y 1 lighttpd, mod_security para empezar no sirve para mi lighty… así que me pareció mejor idea proteger php que es donde la mayor causa de dolores de cabeza he tenido.
Pues bueno que nada más salio Lenny aproveche para cambiar por lighttpd los apache1.3.x solo me he quedado con un Apache2 que en lo personal no me gusta demasiado, pero que le estoy dando una oportunidad, en esto estaba cuando empece a recibir una alerta del mentado suhosin.
ALERT – script tried to increase memory_limit to 100663296 bytes which is above the allowed value (attacker ‘REMOTE_ADDR not set’, file ‘/usr/share/moodle/lib/setuplib.php’, line 65)
Bueno resulta que la idea esta en que normalmente si uno no corre en safe_mode php los scripts pueden y muchas veces incrementan el uso de memoria, que normalmente está definido en /etc/php5/apache2/php.ini ,leyendo la documentación de suhosin me encontré con que el valor por defecto de suhosin.memory_limit es 0 (parece que alguna vez soporto -1 que seria ilimitado, cosa que ya no soporta/incluye), entonces leyendo en moodle.org y tras una busqueda en google, me encontré que la solución mas rápida es hacer que el valor máximo de memoria en php.ini y en la configuración de suhosin coincidan y así la ejecución normal no debería causar problemas, después de un rato configure:
en /etc/php5/conf.d/suhosin.ini
suhosin.memory_limit = 256M
y memory_limit = 256M
en /etc/php5/apache2/php.ini
Y sin embargo seguía recibiendo alertas cada hora, en un primer momento, como tenia cosas mas importantes que hacer y todo estaba funcionando bien, pues simplemente hice un filtro en mi thunderbird y mande esos logs a una carpeta temporal… así se quedo como un mes, ayer que estaba leyendo desde mutt, donde no tengo definidos filtros, me costo mucho trabajo encontrar un correo que necesitaba y pues me hice a la idea a encontrar el por que seguía mandándome estos errores si los valores estaban ya empatados… lo primero fue aumentar el limite de suhosin y hacer restart de apache2, nada…
Después de un rato de buscar y picar por aquí y allá no encontré el mismo problema que tenia… entonces se me ocurrió algo mas sencillo, ¿por qué no replicar de manera manual lo que estaba ocurriendo? resulta que para que Moodle haga algunas cosas de mantenimiento y tareas periódicas hay que ejecutar un archivo llamado por supuesto cron.php en muchas instalaciones normalmente esto se hace con wget o curl, en ultimas versiones de Moodle se ha notado que esto puede ser convertido en un ataque de denegación de servicio y se puede desactivar o añadir contraseña, sin embargo en Debian desde que estoy trabajando con Moodle se usa un script en /etc/cron.d tal cual llamado moodle:
# Regular cron jobs for the moodle package
00 * * * * www-data [ -f /usr/share/moodle/admin/cron.php ] && /usr/bin/php -f /usr/share/moodle/admin/cron.php > /dev/null
Que efectivamente lo que hace es con php ejecutar cron.php sin necesitar una conexion de red y por lo mismo sin exponer el archivo… y seguro más de uno ya encontró el por que de mi problema, resulta que este es otro paquete, me explico para quien no este trabajando en Debian para utilizar php5 se necesita libapache2-mod-php5 que tiene su configuración en /etc/php5/php.ini , para ejecutar ese crontab se necesita php5-cli que resulta tiene su propio php.ini en /etc/php/cli/php.ini ,este ultimo era el que estaba peleado con suhosin y que estaba causando tanto problema, su limite de memoria estaba en 32M, lo cual es muy por debajo de los 256 que estaba permitiendo… una vez puse los 2 php.ini de acuerdo con suhosin… ya me he deshecho del molesto error
En especial se me ocurrió escribir al respecto, por que vi en moodle.org algunos hilos con preguntas similares, pero ninguno sobre la configuración de Debian en especifico (es decir esta combinación) y no faltara quien no este demasiado familiarizado con la configuración y no va a ser sencillo dar con el problema (bueno ahora tal vez si).
Es posible que puedas utilizar mod_security para servir lighttpd si configuras una instancia mÃnima de Apache que sólo sirva mod_proxy y mod_security.
La idea justo de usar lighttpd fue dejar atrás Apache ;D y pues me funciona hasta donde entiendo el suhosin para php5 aún en mi lighty, claro que si estoy expuesto a que cualquier otro cgi pueda ser explotable..