20 cosas para volver segura tu configuración de Apache

Os presento una lista que he encontrado de 20 cosas que se pueden hacer para volver más segura tu configuración de Apache:

  • Antes de nada, asegurate de que tienes instalados todos los parches de seguridad.
  • Oculta la versión de Apache y otra información sensible.
  • Asegúrate de que Apache se ejecuta con su usuario propio y su grupo de usuarios.
  • Los ficheros fuera del web root no deben ser accesibles.
  • Desactiva el listado de directorios.
  • Desactiva los server side includes.
  • Desactiva la ejecución de CGIs.
  • No permitir que Apache siga los symbolic links.
  • No permitas opciones de una única vez.
  • Desactiva el soporte a .htaccess.
  • Usa mod_security.
  • Desactiva módulos innecesarios.
  • Asegurate que solo el root tiene acceso al fichero de configuración de Apache y a los binarios.
  • Disminuye el valor del timeout.
  • Limita el tamaño de las requests.
  • Limita el tamaño del cuerpo de un XML.
  • Limita la concurrencia.
  • Restringe el acceso mediante IP.
  • Ajusta las opciones de KeepAlive.
  • Ejecuta Apache en un entorno Chroot.

20 ways to Secure your Apache Configuration

Balanceo de carga con Apache

No sé si se os dará el caso de tener una aplicación en la que se consumen muchos recursos. En estos casos, lo que se suele hacer, cuando la aplicación no se puede optimizar más (o no se sabe), es que se balancee la carga, unas veces se ejecuta en un servidor, otras en otro. Teniendo en cuenta que la base de datos y el servidor de ficheros deben estar compartidos por todos los servidores.
Si necesitas hacer balanceo de carga con Apache, necesitarás usar mod_jk y GlassFish, a parte será necesario tener instalado: Apache 2.0.x, Apache Tomcat Connectors link, Apache Tomcat 5.5.16, Apache Commons Logging 1.0.4, Apache Commons Modeler 1.1 y por supuesto las dos últimas instalaciones de GlassFish V1/V2.
Loadbalancing with mod_jk and GlassFish
Vía / dzone

Agiliza tus páginas mediante htaccess caching

Un artículo extenso y completo que nos muestra como usar dos módulos de Apache para lograr la caché en nuestro servidor. Para ello se necesitan los módulos mod_headers, el cual modifica las cabeceras de las peticiones y respuestas HTTP, y mod_expires

, el cual permite generar las cabeceras HTTP para expiración y control de caché según criterios fijados por el usuario.

Como ejemplos sencillos incluiremos el ejemplo para uso de mod_headers, poniendo un mes de tiempo de caché para imágenes:

<FilesMatch "\.(flv|gif|jpg|jpeg|png|ico|swf)$">
Header set Cache-Control "max-age=2592000"
</FilesMatch>

Para el uso de mod_expires tendremos que añadir lo siguiente:

ExpiresByType image/gif A2592000
ExpiresByType image/png A2592000
ExpiresByType image/jpg A2592000

El artículo es mucho más completo que lo que hemos mencionado, sobre todo la discusión que existe referente al uso de expires, por lo que la lectura es bastante recomendable para quien quiera profundizar en el tema.

Speed Up Sites with htaccess Caching

Vía / del.icio.us

Limita el tamaño de ficheros a subir mediante Apache

El otro día una amiga me escribía bastante agobiada preguntando cómo se podía saber mediante Javascript el tamaño de un fichero que se quería subir, porque si superaba cierto tamaño, no se debía permitir que se subiera (antes de que se intente mandar). Mi respuesta fue un “no se puede hacer desde el cliente” (espero no haberme equivocado).

El problema que tenía es que le obligaban a que fuera en el navegador, supongo que o el cliente (cabezón) o el analista/jefe (más cabezón aún). La solución, que creo que no aceptaban era controlarlo mediante Apache: se añade en el fichero .htaccess la siguiente directiva y ya no hay problemas:

LimitRequestBody tamaño

Siendo tamaño el número de bytes que ponemos como límite para subir ficheros.

A parte de este ejemplo, mi pobre amiga siempre anda enmarronada con peticiones increibles. Por ello, dos consejos:

  • No dejéis que el cliente imponga lo que le venga en gana, hay cosas que no se pueden/deben hacer y por mucho que se empeñe, seguirán sin poderse/deberse hacer. Entre ellas, siempre se comprueban las cosas en el servidor, nunca únicamente en el cliente, sobre todo por temas de seguridad.
  • El elemento input file es tal cual es, no se le puede cambiar el texto del botón, ni aplicarle filtro, ni que te vaya a la carpeta que quieran, ni cambiar el diseño de la ventana, ni modificar mediante Javascript el fichero que se quiere seleccionar. Aunque parezca mentira siempre acaban pidiéndonos alguna de estas cosas.

Pido disculpas si esta entrada no es la típica, pero es que las tonterías del cliente acaban sacándote de quicio.

| | |

Laboratorio: acceder a contenido dinámico de forma estática (caché)

La verdad es que el título puede ser un tanto difícil de entender. Pero explicando que es lo que quiero decir, supongo que será fácil de entender. En este caso se trata totalmente de “laboratorio”, ya que es una idea que se me ha ocurrido y que su implementación puede que no se pueda necesitar, ya que se trataría de un ejemplo muy a la medida. Aunque bien pensado, se trata de una caché.

El problema de acceder a contenido dinámico (sobre todo pasa en Java) es sobrecargar el acceso a un mismo script (o JSP), a parte de que el acceso a contenido estático es mucho más rápido que el acceso a un contenido dinámico. El problema es cuando queremos acceder a contenido dinámico de forma estática.

Imaginemos un mapa tipo Google Maps, tenemos la Tierra totalmente vectorizada y dividimos el mapa en cuadrículas (x e y). Para acceder a una imagen queremos que sea de forma estática para agilizar la carga de la página y no sobrecargar el servidor, pero la imágen no se puede cargar porque no existe, se tiene que crear dinámicamente.

¿Cual es la solución?, controlar la página de error 404, para que cuando no exista la imagen que deseamos la cree y así la próxima vez ya podamos acceder a ella de forma estática.

Para ello tendremos que modificar el fichero .htaccess para que cuando no encuentre la imagen la cree y la devuelva.

ErrorDocument 404 /sentidoweb/imagenes-estaticas/createimage.php

Y tendremos que crear un script PHP para que cree la imagen y la devuelva. En este caso hemos añadido unas condiciones, y es que la imagen tiene que ser png y que tiene que tener el nombre con el siguiente formato (en expresión regular): /\d{1,2}_\d{1,2}\.png/ .

<?php
$url = $_SERVER["REQUEST_URI"];
// Si es una imagen PNG
if (preg_match("/\.png$/", $url)) {
$nombreImagen = substr($url, strrpos($url, "/")+1);
// Si el nombre de la imagen tiene el formato que deseo
if (preg_match("/^\d{1,2}_\d{1,2}\.png$/", $nombreImagen)) {
// Obtengo que imagen tengo que crear
$aux = substr($nombreImagen, 0, strlen($nombreImagen)-4);
$coords = split("_", $aux);
// Creo la imagen
header("Content-type: image/png");
$img = imagecreate(50, 50);
$cFondo = imagecolorallocate($img, 0, 133, 133);
$cTexto = imagecolorallocate($img, 255, 255, 255);
imagestring($img, 1, 5, 5,  '['.$coords[0].', '.$coords[1].']', $cTexto);
imagepng($img, $nombreImagen);
imagepng($img);
}
}
?>

Está claro que esto no funcionaría para nada si el contenido dinámico se actualiza con frecuencia.

| | |

Laboratorio: búsqueda y reemplazo masivo en ficheros

Debido a la compra de Ideasapiens.com y para no perder el contenido actual, Jose Luis Antunez ha querido migrarlo a ideasapiens.blogsmedia.com.

El problema que se encontró fue tener que editar del código fuente de cada documento web la secuencia de texto www.ideasapiens.com a ideasapiens.blogsmedia.com. De esa forma los enlaces apuntarían al subdominio y accesos internos correspondientes donde ahora se alojarán los contenidos.

Para realizar esa búsqueda y reemplazo masivo, antes de pensar en alguna aplicación de escritorio que lo realizara, pensamos en un script para la shell de Linux que con una simple línea se pudiera hacer. Bueno, tan simple no nos resultó y gracias a la ayuda de Dani lo pudimos sacar (teníamos la shell un tanto oxidada).

find . -type f -name "*.php" -exec sed -i s/www\.ideasapiens\.com/ideasapiens\.blogsmedia\.com/g {} \;

Viendo las complicaciones que estábamos teniendo con la shell (por una tontería, dicha sea la verdad), Gabriel nos pasó el siguiente PHP, obteniendo el mismo resultado.

Read More “Laboratorio: búsqueda y reemplazo masivo en ficheros”

| | |

Nueva versión de WAMP5

wamp.pngHa salido una nueva version de WAMP 1.6.4, una aplicación que te instala Apache, PHP5, MySQL, PHPmyadmin y SQLitemanager en tu ordenador, la cual recomiendo sin lugar a dudas.
La nueva versión permite limitar el acceso al servidor web desde internet, que solo se pueda acceder desde localhost, y hacer lo mismo para PHPmyadmin y SQLitemanager. También añade las Zend Optimizer add-ons.
WAMP5
Vía / dzone

| |

Laboratorio: multilenguaje mediante Apache

Leyendo un comentario en una entrada de Minid.net, en el que preguntaba cómo redirigir a una url específica según el idioma del navegador, se nos ha ocurrido explicarlo según lo haríamos nosotros.

Se trata de que la url se redirija a otro directorio según el idioma que nos viene por la cabecera HTTP, por ejemplo: si accedemos a www.dominio.com y nuestro lenguaje es el español, que nos redirija a www.dominio.com/es, y si el idioma es el inglés que acceda a www.dominio.com/en. En nuestro caso, si el idioma no está en la lista de idiomas disponibles accederemos a un idioma por defecto (en).

Read More “Laboratorio: multilenguaje mediante Apache”

|

Simular dominio en localhost con Apache

Una cosa que siempre me ocurre cuando estoy trabajando en mis propios proyectos, es que me creo una carpeta para cada uno de los proyectos dentro del raíz (root) y no puedo usar paths absolutos ya que en el servidor real no usaré ese directorio.

Por ejemplo, estoy creando un nuevo proyecto llamado proyecto1 y para trabajar en local tengo la ruta siguiente: http://localhost:8080/proyecto1, pero cuando lo suba al servidor, será http://proyecto1.com. Voy a tener problemas si quiero usar los paths sean absolutos (“/imagenes/fondo.png”), porque en local debería tener antes el directorio del proyecto (“/proyecto1/imagenes/fondo.png”). Lógicamente, no puedo estar trabajando con paths relativos y luego pasarlos a absolutos cuando lo suba al servidor, puedo liar una buena.

¿Qué solución me queda?, pues una de ellas es la que uso desde hace tiempo, quizás no la más limpia, pero si es bastante sencilla.

Primero tengo que acceder al fichero hosts, que suele encontrarse en la ruta C:\windows\system32\drivers\etc, y añadir la siguiente línea:

127.0.0.1 proyecto1

Con esto lo que conseguimos es que se reconozca el dominio proyecto1 como nuestra propia máquina (127.0.0.1).

Y lo siguiente que tenemos que hacer es modificar el fichero de configuración de Apache (httpd.conf) e incluir el nuevo host.

NameVirtualHost proyecto1:8080
<VirtualHost proyecto1:8080>
DocumentRoot "C:/proyectos/proyecto1"
ServerName proyecto1
</VirtualHost>
<Directory "C:/proyectos/proyecto1">
Allow from all
</Directory>

Modificar Apache cuando mudemos nuestro blog

Leyendo el artículo De mudanza con tu blog, se nos ocurrió ampliar la información con una parte técnica.

Para ello es necesario modificar el archivo .htaccess que se encuentre en el directorio raíz.

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} !dominionuevo.com$ [NC]
RewriteRule ^(.*)$ http://dominionuevo.com/$1 [L,R=301]

El código 301 es para informar que es de forma permanente.

Si queremos modificar las URLs, ya que por ejemplo hemos cambiado de path del Movable Type, tendremos que modificar tambien el .htaccess de la siguiente manera.

RewriteRule ^path-mt/mt-tb.cgi/([0-9])+/$ mt-tb.cgi/$1

Y si lo que queremos es pasar de una url del tipo /pagina.php?id=n a una que sea /titulo-de-la-pagina-n.php, tendremos que escribir una regla para cada página.

RewriteRule /pagina.php?id=1 /bienvenidos.php
RewriteRule /pagina.php?id=2 /google-compra-microsoft.php
RewriteRule /pagina.php?id=3 /como-meter-la-pata-con-facilidad.php
...
RewriteRule /pagina.php?id=n /me-voy-a-mudar-de-blog.php

Actualización: Este ejemplo no estaba del todo claro y ha sido corregido.

Más información