Mod Security es un módulo para Apache que se encarga de proporcionarle un nivel de seguridad adicional a nuestro servidor web muy potente y personalizable.

Funciona como una barrera entre la red (y/o Internet) y nuestro servidor web, donde mediante un conjunto de reglas podemos establecer una serie de acciones (bloquear, informar en un registro, ignorar, etc...) para eventos de todo tipo.

Es especialmente potente, por tres razones:

Preparación y compilación de mod_security

Antes de comenzar, tenemos que asegurarnos de estar utilizando Apache en su versión 2.x o superior, ya que mod_security2 funciona bajo estas versiones.

Instalación y configuración de modsecurity

Listo. Ya tenemos el ModSecurity eficientemente compilado para nuestra máquina. Sólo nos queda instalarlo.

Es bastante importante seguir las instrucciones anteriores para evitar mensajes de errores como "Invalid command 'SecRuleEngine', perhaps mis-spelled or defined by a module not included in the server configuration" o similares.

Arrancamos de nuevo el servidor Apache con un /etc/init.d/httpd start. Notar que en el paquete de conjunto de reglas de mod_security vienen varios: (configuración base, violaciones de protocolo, políticas HTTP, inyecciones SQL, inyecciones XSS, robots scrappers, etc...), incluir los que el administrador considere necesario, ya que hemos incluído todos los ficheros .conf que tengamos en la carpeta.

Reglas para ModSecurity

Las reglas de este programa son muy potentes y haría falta otro artículo para explicar como construirlas, pero un ejemplo muy básico sería el siguiente:

La directiva SecRule crea una regla que examina las cabeceras, más concretamente la ID del navegador (el User Agent) para comprobar si casa con larbin_2.6.3 (¡Ojo! Esto es una expresión regular). Si es así, avisamos al módulo para que informe en el registro (log) y descarte el acceso (drop).

Por último, si estás interesado en crear tu propio conjunto de reglas, añado algunos enlaces de referencia, ya que si estabas manejando la posibilidad de basarte en los conjutos de reglas por defecto, aviso que las expresiones regulares que utilizan tienen un nivel un poco sofisticado:

Enlaces de interés:

Bit y Byte tienen el honor de presentar Byte-CPU-meter, un medidor de carga del servidor para nuestra página web.

Con él podremos mostrar un pequeño medidor de la carga que está actualmente soportando nuestro servidor y saber en todo momento si está sobrecargado o no.

Requisitos

• Servidor web basado en sistema operativo Unix/Linux.
• PHP4 o superior.
• Permitir el comando shell_exec (privilegios).

El snippet requiere menos de 1Kb de memoria para ejecutarse y tarda muy pocos milisegundos en generar el medidor.

Instalación

Es bastante sencilla. Sólo se necesita descomprimir el siguiente fichero byte-cpu-meter-0.1.zip en la ruta donde tenemos nuestra página web. Luego añadimos el siguiente código PHP donde queremos que aparezca:

include("bytecpumeter.php");

Descarga

• byte-cpu-meter-0.1.zip (Versión 0.1)

Observaciones

El sistema de carga puede inducir a mucha controversia. Este plugin lo que hace es mostrar el porcentaje de carga del servidor respecto a su uptime del último minuto.

El uptime (load average) lo que hace es mostrar el número de procesos en cola del servidor. Así pues, se puede conocer una aproximación a lo ocupado que se encuentra.

He establecido unos valores para servidores compartidos (por defecto) y otros para servidores virtualizados o dedicados. Si tienes un servidor del segundo tipo, debes comentar los anteriores y utilizar estos ultimos.

Si te animas a colocarlo en tu blog, deja constancia en un comentario con tu blog.

Si has llegado hasta este artículo, ¡enhorabuena! Ya tienes las DNS actualizadas con el nuevo servidor de Emezeta. En realidad, estoy de pruebas con este nuevo servidor, pero lo más probable (a no ser que ocurra algún imprevisto) es que me quede con él.

La semana pasada hablaba de Dreamhost Private Server, el nuevo servicio de Dreamhost que estaba estrenando y que al parecer ahora he abandonado, después de hablar maravillas de él.

La explicación es sencilla. Sigo manteniendo que Dreamhost PS es un buen servicio, y sobre todo barato. Es ideal para usuarios que no se quieran «complicar» con la gestión del servidor. Para garantizar el buen funcionamiento del servicio, muchas veces, ciertas características son accesibles al usuario, pero hay que abrir un ticket de soporte para que un administrador lo supervise, como por ejemplo el caso del uso de un firewall como iptables, cosa que para mi venía siendo muy necesaria en estos últimos días.

Sin embargo, en MediaTemple, aunque en un principio partes de un status similar, es posible controlar más el funcionamiento del servidor, incluso para tareas de root, cosa que era imposible en Dreamhost PS.

Antes que nada, dar las gracias a Nacho y Alvy por facilitarme la información que necesitaba acerca de MediaTemple, y esperemos que este nuevo servidor funcione a gusto de todo el personal.

Las DNS pueden tardar de 24 a 48 horas en actualizarse del todo, así que puede que en algunos momentos se vea contenido no actualizado. Si encuentran algún error en la web, agradecería que avisaran mediante el formulario de contacto de la web o por email.

Actualizado: La mayoría de las principales DNS ya han hecho los cambios, aunque aún existen sistemas sin actualizar.

Actualizado: El cambio de servidor ya está prácticamente al 100%. Sólo quedan algunos accesos que aún se mantienen en el antiguo servidor, que desaparecerán en algunas horas.

Después del manual para reducir el consumo de CPU y memoria RAM del servidor, seguimos con los consejos para optimizar nuestro servidor. Uno de los aspectos que más debemos cuidar es el uso de memoria RAM que hacemos a medida que se ejecutan nuestros scripts.

Cuando los visitantes acceden a nuestras páginas, la ejecución de los scripts PHP (o Perl, Ruby...), las consultas SQL a la base de datos, la optimización de la programación y otros factores ayudan o perjudican en el uso de memoria RAM. La mayoría de las veces no tenemos ni idea de cuanta memoria estamos utilizando en cada petición de página, pero vamos a averiguarlo.

PHP 5.2.0

PHP 4.3.2

Con este código PHP (sólo en PHP 4.3.2 o superior) obtendremos la cantidad de memoria que está consumiendo por petición nuestro blog o página web. Pero puede ocurrir que nuestro sistema no esté compilado con esta opción, para ello podemos utilizar la siguiente función. Obviamente, necesitaremos

function memory_get_usage() {
     $pid = getmypid();
     exec("ps -o rss -p $pid", $output);
     return $output[1] *1024;
}

En muchos casos nos resultaría más útil guardar en una variable (recuerda, no debes usar echo al principio si envías cabeceras, obtendrás un error) el consumo de memoria que hay al principio del script:

Así, más tarde lo podríamos imprimir por pantalla para compararlo con el consumo final y conocer el verdadero gasto del script, ya que el consumo final puede estar debido a razones «anteriores» a la petición del script, como el uso del mod_rewrite, gestión de los procesos del apache y muchos otros criterios.

Date cuenta que esta es una buena forma de ver cuánto está consumiendo por petición nuestro Wordpress (o cualquier otro CMS). ¿Y tu blog cuánto consume por petición?