Administración de servidores apache

Transcripción

1 Administración de servidores apache Esta obra se publica bajo licencia Creative Commons, para más información: nc/2.5/es/

2 Qué es apache? Apache es un proyecto de la apache software foundation, que a su vez es responsable de algunas decenas de proyectos Open Source, vitales para la comunidad, aparte del servidor web podríamos mencionar: Tomcat: Un contenedor de servlets utilizado en la implementación de referencia de las tecnologías Java Servlets y Java Server Pages (más conocida como JSP) Ant: Una aplicación para la configuración del proceso de construcción de proyectos software, habitualmente utilizada en proyectos J2EE Perl: Un lenguaje de programación que, según si el autor es un detractor o un apasionado del mismo, o tiene la sintaxis más macarrónica de la historia de la programación o es el mejor lenguaje del mundo... Ahí queda eso. Además de varios proyectos relacionados con ámbitos estratégicos para el futuro del desarrollo de aplicaciones, como por ejemplo: web services, struts,... Apache es, concretamente, el servidor http más usado en todo el mundo. Un servidor http es una aplicación que entiende el protocolo http que utilizan, por ejemplo, los navegadores web, y es capaz de contestar a las peticiones de los mismos sirviéndoles los documentos que solicitan. Apache continúa en desarrollo, actualmente, la última versión estable es la Es quizá por esto que haya sufrido algún que otro revés en cuanto al número de usuarios dado que muchos indican que hay otros proyectos que son capaces de ofrecer un mayor rendimiento como, por ejemplo, lighttpd. Sin embargo, la madurez y robustez que ha demostrado en los últimos años sigue haciendo que la mayor parte del contenido que se sirve a diario en internet pase siempre por las manos de éste servidor. Ilustración 1: Estadística de uso de servidores de netcraft Ago1995 Ago2007

3 Versiones de Apache Apache comenzó siendo el servidor web de los sistemas Unix, pero actualmente puede ejecutarse en prácticamente cualquier plataforma: Linux, Unix, FreeBSD, NetBSD, OpenBSD, Amiga, Mac Os X, SunOS, Solaris, HPUX, Windows,... Sin embargo, históricamente ha tenido problemas en alguna de estas plataformas, concretamente en Windows, dónde la bifurcación de procesos hijos se gestiona de manera distinta que en un entorno POSIX. Apache 2 nace con la intención de resolver estos problemas y para ello han implementado los módulos multiproceso. Cada módulo afronta la necesidad de atender más de una llamada simultáneamente de distintas maneras: MPM Prefork Funciona de manera similar a la versión anterior de apache. Simplemente crea un grupo de procesos hijos, cada uno de los cuales ejecuta un único hilo. Cada proceso hijo atiende una solicitud. MPM Threaded Este módulo es el que aporta el soporte de hilos o threads a apache 2. Cuando apache ejecuta este módulo cada proceso hijo mantiene a su vez varios hilos de ejecución. La principal desventaja es que cuando un hilo falla se aborta la ejecución del resto de hilos del mismo proceso hijo. Los hilos conforman una manera más ligera de gestionar la ejecución de tareas, sobrecargan menos al sistema operativo y por tanto son más adecuados en entornos que prevén un escalado importante en el servicio. MPM Perchild Permite la gestión dinámica del número de hilos en cada proceso hijo, la principal singularidad es que cada proceso puede lanzarse con un ID de usuario y de grupo distintos, de modo que se facilita la gestión de sitios web virtuales. MPM Worker Sigue un enfoque híbrido que mezcla el multihilo con el multiproceso. Es capaz de servir muchas peticiones utilizando los hilos de una manera muy estable. MPM WinNT Diseñado específicamente para la plataforma Windows. Es un módulo multihilo. Dispone de un proceso padre y un proceso hijo que gestionará todos los hilos.

4 Requisitos mínimos para la instalación de apache2 Apache puede instalarse como un paquete precompilado, que será la opción que contemplemos en este manual, o también compilando el código fuente desde cero. Esta última manera permite indicar, punto por punto, qué funcionalidades adicionales queremos añadir al fuente base de apache. En determinados entornos, en los que el rendimiento debe afinarse hasta el más mínimo detalle, como en el caso de servidores que pueden recibir cientos de miles de solicitudes, esta posibilidad es realmente interesante. Si bien, en el caso de un servidor corporativo. En cualquier caso, apache requiere la friolera de, aproximadamente, 1MB de espacio en disco para su instalación, aunque deberíamos prever el espacio que ocupan los ficheros de log, cada entrada puede ocupar unos 80 bytes, si tenemos en cuenta que en el fichero access.log se almacena cada acceso al contenido del servidor en un sitio con mucho tráfico podríamos llenar rápidamente casi cualquier disco duro. Sin embargo en las máquinas linux existe la costumbre de utilizar un sistema conocido como logrotate que va comprimiendo los ficheros de log más antiguos en orden y eliminando los que posiblemente no se vayan a utilizar más. Siempre suele ser buena idea montar el directorio /var en una partición o en un disco aparte. Los requisitos mínimos en el ámbito de la disponibilidad de memoria RAM suenan casi irrisorios en el mundo en el que nos movemos, apache necesita 8MB, como mínimo, para funcionar. Siendo justos, esto tampoco nos da una idea de lo que supone mantener un servidor en producción. Para escalar correctamente la memoria RAM del sistema que administremos tendremos que calcular cuanta memoria consume cada uno de los procesos hijos o hilos de apache para después multiplicarlo por el número máximo de procesos en espera que tendrá apache, esto se configura con la opción MaxSpareServers. Por último habría que tener en cuenta el espacio en memoria que puedan consumir los scripts CGI que podamos tener en ejecución. Dos herramientas muy interesantes para realizar estos cálculos son ps, que devuelve la tabla de procesos del sistema y top, que indican el uso de los distintos recursos del sistema por parte de cada proceso. El único parámetro que no hemos contemplado es igual de crítico, si no más, que los anteriores, estamos hablando del, siempre exiguo, ancho de banda. Evidentemente el número de contenidos que nuestro servidor pueda enviar y recibir a la vez dependerá del ancho de banda de que dispongamos, podemos disponer de una ADSL básica y tener alojado nuestro servidor en una pequeña pyme local o podemos tener un servidor dedicado alojado en algún ISP que nos garantice un ancho de banda realmente grande. Antes de comenzar los cálculos tendremos que tener en cuenta algún factor que no suele tenerse en cuenta, además estudiaremos en profundidad el caso que nos es más próximo, el de la ADSL. Ante todo hay que tener claros los conceptos, ADSL son las

5 siglas de Asymmetric Digital Suscriber Line o lo que es lo mismo, Línea de abonado digital asimétrica. Posiblemente el detalle que más se pasa por alto es el término asimétrica. En una ADSL no podemos enviar contenidos desde nuestra casa hacia internet y recibirlos desde internet a nuestra casa a la misma velocidad. Por lo general, solemos estar interesados en descargar más información que la que enviamos, de ahí que en una ADSL siembre tengamos un ancho de banda de descarga mayor que el ancho de banda de subida. Por lo tanto no sería significativo hacer cálculos del tipo: Tengo una adsl de un mega así que puedo subir y descargar a la vez 5 ficheros de 20KB. El otro detalle en el que me gustaría hacer incapié es en el de las unidades, qué significa exactamente tener una ADSL de 1 Mega? o formulado de otro modo tengo una ADSL de un mega qué?. Las unidades en las que se miden las conexiones son los kbps Kilo Bits por segundo y no Kilo Bytes por segundo. Cualquier usuario medio está acostumbrado a medir el espacio en disco de sus ficheros en MegaBytes y no en megabits, por lo tanto, si queremos hacernos una idea de cuánto tardaría un fichero de 1 MegaByte en enviarse a través de una adsl de 1Mbps. 1 Megabit por segundo = 1/8 MegaBytes por segundo = MegaBytes por segundo Por tanto un fichero de 1 MegaByte tardará en enviarse: 1/0.125 = 8 segundos Supongo que coincidirán conmigo que no es esta la idea que se tiene a priori no? Bueno, una vez aclarados estos detalles podemos proceder a calcular el ancho de banda promedio que necesitaremos para servir nuestros sitios. El primer paso será calcular el tamaño medio de nuestras páginas webs y sus imágenes. Bastará con sumarlos todos y dividirlos por el número total de archivos. Ahora tendremos que dividir nuestro ancho de banda de subida (porque es contenido que nuestro servidor enviará hacia internet) entre el tamaño medio de nuestros archivos y esto nos dará el número de archivos simultáneos que seremos capaces de enviar cada segundo.

6 El proceso de instalación de apache2 en ubuntu Ubuntu dispone de una versión empaquetada de apache2, lo que hace que la instalación básica sea realmente sencilla. Como siempre, comenzaremos actualizando las listas de paquetes desde los ser vidores presentes en nuestro fichero /etc/apt/sources.list. Para ello utilizaremos la orden >> sudo apt get update Si queremos conocer el gran volumen de paquetes relacionados con apache2, bastará con que consultemos utilizando la orden: >> sudo apt cache search apache2 Finalmente instalaremos, no sólo el paquete de apache2 sino su documentación: >> sudo apt get install apache2 apache2 doc Ilustración 2: Consola con el proceso de instalación de apache Es posible que, tal y como muestra la imagen anterior, se nos solicite en algún punto una confirmación explícita de que deseamos instalar los paquetes. Bastará con que pulsemos S, en mayúsculas, para confirmar y continuar normalmente la instalación. Es importante notar que aparte de los paquetes que hemos solicitados se instalarán otros

7 que son necesarios para el correcto funcionamiento del servidor. Esto es perfectamente normal. Si prestamos atención veremos que, en el momento de escribir este curso, la versión empaquetada disponible en ubuntu es la Es habitual que pase algo de tiempo entre la salida oficial de una nueva versión y el posterior empaquetado oficial para las distintas distribuciones de linux. De cualquier modo, es posible obtener paquetes no oficiales con las últimas versiones prácticamente en el mismo momento de la salida a la calle de cualquier nueva versión, sin embargo, creo que no está de más recordar que es mejor utilizar las versiones estables y oficiales para entornos de producción. Después de unos breves instantes en los que nuestra máquina se descargará todos los paquetes necesarios comenzará el proceso de configuración. En un momento dado encontraremos un mensaje de error, exactamente el siguiente: Ilustración 3: Mensaje de error en la instalación de apache2 en Kubuntu No os preocupéis por él, no es nada importante, se produce por el hecho de que el script de instalación y arranque de apache no es capaz de determinar el nombre de dominio completo de la máquina, cuando esto ocurre establece un valor por defecto, concretamente la dirección ip que corresponde a la interfaz de loopback, es una dirección que siempre apunta al propio servidor.

8 Arranque y parada de un servidor Apache2 en ubuntu. Como cualquier otro servicio en una máquina Linux, apache cuenta con unos scripts de arranque y de parada. De momento nos basta con saber que existen unos scripts en el directorio /etc/init.d/ que siempre reciben el mismo tipo de argumentos y que sirven para arrancar, parar o reiniciar servicios, el script que corresponde a apache2 se llama del mismo modo, es decir, apache2 y utilizarlo es muy sencillo: Para arrancar apache2 tendremos que ejecutar: >> sudo /etc/init.d/apache2 start Para parar el servicio, el equivalente a apagarlo escribiremos: >> sudo /etc/init.d/apache2 stop Para reiniciar el servicio, si por ejemplo, hemos cambiado la configuración: >> sudo /etc/init.d/apache2 restart En líneas generales siempre es conveniente estar monitorizando los log1 relacionados con apache para comprobar que tanto el proceso de arranque como los de parada o reinicio del servicio han hecho lo que nosotros esperábamos. Una manera muy cómoda de llevar a cabo esta monitorización es utilizando el comando tail, que muestra siempre el final del fichero que se le pase como argumento, con el modificador f que le indica que muestre los distintos cambios que se vayan produciendo en este fichero según ocurren. Como las últimas entradas de los ficheros de log siempre se añaden al final tendremos constancia de todos los avisos o errores que hayan podido producirse sobre la marcha. Los ficheros de log que están más directamente relacionados con apache2 cuelgan todos del directorio /var/log/apache2. Con la configuración inicial, los ficheros en los que se almacenan todos los avisos, errores, etc... son: /var/log/error.log y /var/log/access.log. El administrador puede, en cualquier caso, definir nuevos ficheros de log incluso para hosts virtuales individuales, de cualquier modo siempre es buena idea seguir la norma de almacenarlos colgando del directorio /var/log/apache2. 1 Log puede traducirse como bitácora, pero lo cierto es que en el día a día siempre terminamos utilizando el término anglosajón para referirnos a estos archivos. Por este motivo siempre utilizaremos esta terminología.

9 Ilustración 4: Un ejemplo de fichero error.log de apache2 en el que se muestra una parada y un inicio del servicio. La configuración de Apache2 En las distribuciones de Linux basadas en Debian todos los ficheros de configuración de Apache2 se encuentran en el directorio /etc/apache2 La configuración de Apache2 en los distintos sabores derivados de Debian es algo distinta a la que suele abordarse en la mayoría de la bibliografía recomendada. En la mayoría de implantaciones se utiliza un fichero denominado httpd.conf en el que se almacenan todas las directivas de configuración. En el ámbito de las distribuciones basadas en Debian se suele utilizar como fichero principal de configuración aquel denominado como apache2.conf, a pesar de que existe httpd.conf suele estar vacío. Nosotros nos centraremos en el contenido de este fichero así como en el de los directorios mods* y sites* Cómo se configura Apache? Para configurar Apache se deben añadir directivas a los ficheros de configuración, de ese modo, vamos estableciendo el comportamiento esperado del servidor. El fichero de configuración principal, apache2.conf, en nuestro caso, sólo se lee cuando arranca el servicio. En el arranque apache también lee el contenido del fichero mime.types que

10 establece los tipos mime que es capaz de procesar. Ilustración 5: Contenido del directorio /etc/apache2 Sintaxis de los ficheros de configuración de apache Los ficheros de configuración contienen una directiva por cada línea, la barra inclinada \ puede utilizarse como el último carácter en una línea para indicar que la directiva continúa en la línea inferior, en este caso no puede haber otro carácter ni siquiera un espacio en blanco entre la barra inclinada y el salto de línea. Las directivas, es decir, los nombres de las mismas, no son sensibles al cambio entre mayúsculas y minúsculas, pero su contenido si puede serlo. Las líneas que comienzan con un carácter # se consideran comentarios y no se procesan, por otro lado este carácter no debe aparecer en ninguna línea después de una directiva de configuración. En ubuntu podemos comprobar si la sintaxis de los ficheros de configuración es correcta utilizando el comando apache2ctl t Los módulos Apache es un servidor altamente modularizado, lo único que se ha implementado en el núcleo del servidor son las funciones más básicas. Las características más específicas se pueden cargar en tiempo de compilación seleccionándolas explícitamente.

11 En cualquier caso el servidor puede compilarse con soporte para la carga dinámica de módulos y es así como se empaqueta en ubuntu. En este caso pueden añadirse módulos a posteriori en función de las necesidades del administrador sin tener que recompilar todos los fuentes del servidor. Para cargar dinámicamente un módulo basta con utilizar la directiva <LoadModule> además se pueden aplicar directivas de manera condicional sujetas a la circunstancia de que un módulo este cargado o no mediante la directiva <IfModule> Se pueden comprobar los módulos que están compilados en el servidor utilizando el comando apache2ctl con el modificador l >> apache2ctl l Ámbito de las directivas Dependiendo del entorno en el que escribamos determinadas directivas de configuración, éstas afectarán al comportamiento del servidor en general, sólo a un directorio de la raíz de documentos, a un sitio virtual,... Las directivas que aparecen directamente en el fichero principal de configuración afectarán al funcionamiento general del servidor, si lo que se necesita es afectar sólo a un ámbito concreto del servidor habrá que colocar las directivas dentro de las secciones <Directory>, <DirectoryMatch>, <Files>, <FilesMatch>, <Location> o <LocationMatch>. Estas secciones limitan la aplicación de las directivas que engloban a directorios dentro del sistema de ficheros o URL's. Estas secciones pueden aparecer unas dentro de otras dando la posibilidad de obtener un control muy fino. Un único servidor apache puede servir más de un sitio web a la vez, a esto se le denomina hosting virtual, las directivas que se encuentran dentro de una sección <VirtualHost> sólo se aplicarán a este sitio virtual. Aunque la mayoría de las directivas pueden aparecer en cualquier sección hay algunas que no tienen sentido en determinados contextos. Los archivos.htaccess En la línea de conseguir una gestión descentralizada de la configuración apache pone a nuestra disposición unos ficheros especiales que deben aparecer dentro del árbol de directorios de nuestro sitio web. Estos archivos suelen denominarse.htaccess, aunque ese nombre no es obligatorio, puede modificarse cambiando el valor en la directiva AccessFileName. Las directivas presentes en los ficheros.htaccess tendrán efecto sobre el directorio en el que se encuentre el fichero y todos sus subdirectorios. Como estos ficheros se leen en cada petición, los cambios establecidos se aplicarán inmediatamente.

12 Cada vez que se produce una petición el servidor busca los archivos que tengan alguno de los nombres especificados en AccessFileName en el path hacia el documento que ha solicitado el visitante. De todos modos el administrador de un servidor web puede forzar las directivas que se aplican sobre un sitio, directorio, etc... A pesar de que exista un archivo.htaccess si en los ficheros de configuración principal establece que no se permite que se sobreescriban los permisos que él establezca, del siguiente modo: <Directory /> AllowOverride None </Directory> Contenedores de sistemas de archivos (Filesystem Containers) Las directivas <Directory> y <Files> junto con sus contrapartidas basadas en expresiones regulares permiten aplicar directivas de configuración de apache a apartes concretas del sistema de ficheros. Las directivas encapsuladas dentro de los contenedores <Directory> se aplican al directorio que apuntan y a todos sus subdirectorios, el mismo efecto puede conseguirse con un archivo.htaccess colocado en la raíz del árbol de directorios a partir de la cual esperamos que sea efectiva la nueva configuración. <Directory /var/www/default site> Options +Indexes </Directory> Con la directiva anterior estamos especificando que queremos que se generen índices automáticos para el directorio /var/www/default site y todos los subdirectorios que cuelgan de él. Esto significa que si en cualquiera de estos directorios no existe un archivo de índice por defecto, comunmente denominado index.html, apache generará un listado de los archivos que contiene el directorio. Hay que ser especialmente cuidadoso con esta carácterística para no permitir que usuarios malintencionados accedan a contenidos que no deberían poder ver. Es importante notar que el directorio en el que se hacen efectivas estas directivas debe expresarse como una ruta absoluta dentro del sistema de ficheros y que además no tiene un carácter / al final. La directiva <Directory> también admite comodines para establecer a qué directorios se aplican las configuraciones que se establecen en su interior. Haciendo uso de esta característica, podemos, por ejemplo, aplicar configuraciones a más de un directorio de una sola vez.

13 <Directory /home/*/public_html> AllowOverride None </Directory> En el ejemplo anterior estamos deshabilitando el uso de ficheros.htaccess en los directorios de publicación html de TODOS los usuarios del sistema. Las directivas encerradas dentro de una sección <Files> se aplican exclusivamente a los ficheros que tengan el nombre especificado en la apertura de la sección, se encuentren dónde se encuentren. <Files private.html> Order allow, deny Deny from all </Files> El ejemplo anterior, si se sitúa en el fichero principal de configuración de apache, en nuestro caso en apache2.conf, denegaría el acceso a cualquier fichero con nombre private.html, estuviera donde estuviese. Para referirnos a archivos que se encuentran en partes determinadas del sistema de ficheros podemos combinar las secciones <Directory> y <Files> de modo que nos permite establecer permisos con una granularidad más fina. <Directory /var/www/default> <Files private.html> Options allow, deny Deny from all </Files> </Directory> El ejemplo anterior prohíbe el acceso a los ficheros de nombre private.html que puedan encontrarse en el directorio /var/www/default o cualquiera de sus subdirectorios.

14 Contenedores de espacio web (Webspace containers) La directiva <Location> así como su contrapartida basada en expresiones regulares cambia la configuración del contenido en espacio web, esto quiere decir que no tiene absolutamente nada que ver con el sistema de ficheros, sino, exclusivamente con el contenido de las URL que llegan al servidor como parte de las solicitudes. <Location /private> Options allow, deny Deny from all </Location> El ejemplo anterior deniega el acceso al contenido que pudiera colgar de cualquier path dentro de la URL que comience por /private, ejemplos del tipo de paths a los que se deniega el acceso podrían ser: Así como cualquier otro path que comience por la cadena /private La Directiva <Location> permite el uso de comodines, pero hay que tener en cuenta que ningún comodín sustituirá nunca al carácter /, por tanto estos deben colocarse de manera explícita. Como muestra de que la directiva <Location> no tiene nada que ver con los archivos que almacenamos en nuestro sistema de ficheros, mostramos el siguiente ejemplo: <IfModule mod_status.c> <Location /server status> SetHandler server status </Location> </IfModule> La primera línea comprueba si nuestro servidor apache ha cargado el módulo mod_status, que nos devuelve información del sistema, si no fuera así, simplemente ignoraría el contenido encerrado dentro de la sección <IfModule>. Si el módulo está cargado, cada vez que un usuario pretenda acceder a un sitio cuyo path comience por /server status, redirigirá la solicitud hacia una web generada automáticamente por apache con información sobre el estado del servidor.

15 Una vez más, la recomendación es que sean cuidadosos con esta posibilidad, hay mucha gente malintencionada y dispuesta a atacar nuestro servidor cuando estemos de vacaciones en una playa paradisíaca, cuanta más información tengan sobre el estado del mismo, más fácil lo tendrán para atacarnos. Comodines y expresiones regulares Las directivas <Directory>, <Files> y <Location> admiten el uso de comodines del tipo de los utilizados en la línea de comandos. Un * sustituye a una cadena de cualquier longitud, un? sustituye un único carácter y [seq] sustituye cualquier carácter que se encuentre en la lista entre los corchetes. El carácter / no será sustituido por ningún comodín, por tanto hay que ponerlos explícitamente. Es posible que se requieran maneras de establecer correspondencias mucho más flexibles, cualquiera de los contenedores anteriores dispone de su contrapartida basada en expresiones regulares, concretamente <DirectoryMatch>, <FilesMatch> y <LocationMatch> que permiten la utilización de expresiones regulares compatibles con perl. El uso de estas directivas basadas en expresiones regulares puede alterar la manera en que se aplican las configuraciones. Hablaremos de esto un poco más adelante. <FilesMatch \.(?i:gif jpe?g png)$> Order allow, deny Deny from all </FilesMatch> El ejemplo anterior prohíbe el acceso a cualquier archivo cuya extensión sea igif, gif, jpg, jpeg o png. La potencia de las expresiones regulares hace de ellas una herramienta muy utilizada, pero también son más complicadas de utilizar. Otros contenedores Existen, al menos, tres contenedores más que trataremos en más profundidad un poco más adelante. Son <VirtualHost> y <Proxy> con su contrapartida orientada a expresiones regulares <ProxyMatch>. Como su propio nombre indica nos permiten establecer directivas para Hosts o sitios virtuales dentro del mismo servidor y para proxies respectivamente. Qué directivas se permiten en cada sección? No todas las directivas de configuración tienen sentido dentro de todos los contenedores, es por eso que existen algunas pequeñas excepciones.

16 La norma general es que cualquier directiva que pueda aplicarse dentro de un contenedor <Directory> podrá aplicarse dentro de los contenedores <DirectoryMatch>, <Files>, <FilesMatch>, <Location>, <LocationMatch>, <Proxy> y <ProxyMatch>. Las excepciones son: La directiva AllowOverride sólo se admite dentro de secciones <Directory> Las opciones FollowSymLinks and SymLinksIfOwnerMatch funcionan sólo dentro de las secciones <Directory> o en archivos.htaccess La directiva Options no puede usarse en secciones <Files> ni en <FilesMatch> Orden de aplicación de directivas Las directivas se aplican en un orden un tanto peculiar, esto puede tener efectos no deseados si no se tiene en cuenta, por eso es importante entender cómo funciona: El orden de aplicación es: 1. Las directivas que se encuentran dentro de secciones <Directory> y en archivos.htaccess se aplican simultáneamente (Si se permite que las directivas contenidas dentro de los ficheros.htaccess sobreescriban las propias de la sección <Directory> se hace así) 2. En segundo lugar se aplican las directivas encontradas dentro de secciones <DirectoryMatch> o <Directory ~> 3. En tercer lugar se aplican las directivas englobadas en secciones <Files> y <FilesMatch> de manera simultánea. 4. En cuarto lugar se aplicarán las directivas que se encuentren situadas dentro de secciones <Location> y <LocationMatch> también de manera simultánea. Cualquier grupo de directivas, salvo las que se encuentren dentro de secciones <Directory> se aplicarán en el orden en el que se encuentren en el fichero de configuración. Sin embargo las directivas que se encuentran englobadas dentro de una sección <Directory> se aplicarán siguiendo el orden de menor camino de directorios a mayor camino de directorios. Es decir, se aplicarán antes directivas que se encuentren en una sección: <Directory /var/www/site1>... </Directory> Que las que se encuentren dentro de una sección:

17 <Directory /var/www/site1/subdir>... </Directory> Aunque este segundo grupo de directivas se encuentre antes que el anterior en los ficheros de configuración. Si existen muchas secciones <Directory> que se refieren al mismo directorio del sistema de ficheros, se procesarán en el orden en el que aparezcan en los ficheros de configuración. Las configuraciones que se añaden al fichero de configuración utilizando la directiva Include se tratarán como si se encontraran en el mismo fichero, justo en el lugar en el que aparece al directiva Include. Las secciones que se definan dentro de un contenedor <VirtualHost> se aplicarán después de que se apliquen sus equivalentes fuera del mismo. Esto permite que los host virtuales sobreescriban la configuración del servidor principal. Cuando las solicitudes de los clientes son servidas a través del módulo mod_proxy, el contenedor <Proxy> toma el lugar de <Directory> en la lista anterior. Un ejemplo: Suponiendo que todas las secciones se aplican a la solicitud en curso, las directivas de este ejemplo se aplicarán en el orden A > B > C > D > E <Location /> E </Location> <Files f.html> D </Files> <VirtualHost *> <Directory /a/b> B </Directory> </VirtualHost> <DirectoryMatch "^.*b$"> C </DirectoryMatch> <Directory /a/b> A </Directory>

18 Un ejemplo adicional, como los contenedores <Location> se evalúan después de los contenedores <Directory>, en el caso siguiente todas las directivas de seguridad que se establecen en la sección <Directory> quedan sobreescritas por las de la sección <Location> <Location /> Order deny,allow Allow from all </Location> # Woops! This <Directory> section will have no effect <Directory /> Order allow,deny Allow from all Deny from badguy.example.com </Directory>

19 Autenticación, autorización y control de acceso Comenzamos esta sección con un par de definiciones importantes: Autenticación: Proceso por el cual se comprueba que alguien es quien dice ser. Autorización: Proceso a partir del cual se permite ir a alguien a donde pretende ir u obtener la información que solicita. Hay tres tipos distintos de módulos involucrados en el proceso de autenticación y autorización. Por lo general se necesitará, al menos, un módulo de cada grupo: Tipo de autenticación: El tipo de autenticación se establece haciendo uso de la directiva AuthType. Esta directiva sólo puede encontrarse dentro de los contenedores <Directory> o en los archivos.htaccess. Sólo puede tomar los valores Basic y Digest. El tipo de autenticación es gestionado por los módulos mod_auth_basic y mod_auth_digest. La versión Digest, según la documentación de apache está marcada aún como experimental. El proveedor del sistema de autenticación: Es el módulo a quien consultamos para verificar la personalidad del usuario que intenta autenticarse. En apache disponemos de los siguientes módulos para este cometido: mod_authn_alias mod_authn_anon mod_authn_dbd mod_authn_dbm mod_authn_default mod_authn_file mod_authnz_ldap Finalmente, el proceso de autorización se gestiona utilizando los módulos: mod_authnz_ldap mod_authz_dbm mod_authz_default mod_authz_groupfile mod_authz_owner mod_authz_user

20 Hay módulos que nos permiten, incluso, la autorización basada en nombre de host o ip, como es el caso de mod_autz_host. El proceso final de autorización se establece utilizando la directiva Require que sólo puede aparecer en contenedores <Directory> o en archivos.htaccess. Esta directiva indica qué usuarios, previamente autenticados pueden acceder a un recurso del servidor. Los módulos de autorización más utilizados, mod_authz_user y mod_authz_groupfile permiten la siguiente sintaxis: Require user userid [userid]... Que sólo permite el acceso al recurso a los usuarios listados Require group group name [ group name]... Que sólo permite el acceso al recurso a usuarios de los grupos de la lista Require valid user Todos los usuarios autenticados pueden utilizar el recurso. Otros módulos de autorización como pueden ser: mod_authnz_ldap o mod_authz_dbm,... Implementan otras opciones para la directiva Require. Para que funcione correctamente la directiva Require debe acompañarse de las directivas AuthName y AuthType, así como de las directivas AuthUserFile y AuthGroupFile La directiva AuthName toma como valor una cadena de texto, que debe adjuntarse entre comillas dobles, para aclarar al usuario en qué ámbito de autenticación se encuentra, ya que será la cadena que aparecerá en el diálogo de nombre de usuario y contraseña, para que, de ese modo, sepa que nombre de usuario y contraseña debe introducir. Por ejemplo: AuthName Grupo de administradores secretos Mostramos a continuación un ejemplo completo del uso de la autenticación en apache: AuthType Basic AuthName "Restricted Resource" AuthUserFile /web/users AuthGroupFile /web/groups Require group admin Es importante hacer notar en el ejemplo anterior que los path hacia los ficheros que contienen los usuarios y grupos válidos son relativos al ServerRoot, no absolutos dentro del sistema de ficheros. A continuación hablaremos de cómo se generan estos ficheros, pero antes hay que reseñar otro detalle importante. El control de acceso que se lleva a cabo mediante las directivas del ejemplo

21 anterior es efectivo para todos los métodos de solicitud o envío de datos al servidor. Si quisiéramos que sólo los métodos GET o PUT fueran los que tuvieran que seguir el proceso de control de acceso tendríamos que encuadrarlos dentro de una directiva <Limit>, pero esto no es lo habitual. Haciéndolo funcionar en Apache2 Todo lo indicado a continuación funciona sólo en un fichero de configuración dentro de un contenedor <Directory> o en un archivo.htaccess Para utilizar las herramientas de control de acceso de Apache en los ficheros.htaccess, antes hay que especificar en el fichero de configuración que se permite hacer esto explícitamente, por tanto en un contenedor <Directory> que apunte al directorio que queremos utilizar tendremos que añadir la directiva AllowOverride tal y como se muestra a continuación: AllowOverride AuthConfig Lo que indica a apache que vamos a permitir que las directivas de autenticación y autorización presentes en el fichero.htaccess, se apliquen aunque vayan en contra de lo especificado en el contenedor <Directory> Protección básica de un directorio mediante password Lo primero que hay que hacer es crear un archivo de contraseñas, para esto, el paquete de instalación de apache2 nos ofrece la utilidad htpasswd. Para crear un archivo de contraseñas bastará con que ejecutemos: htpasswd c /var/apache passwords/password usuario El modificador c indica a htpasswd que si el fichero no existe debe crearlo, si el fichero ya existe lo truncaría y almacenaría sólo la nueva contraseña, el segundo argumento es el path hasta el archivo que queremos crear y por último el nombre del usuario. Htpasswd creará un archivo de texto plano con el nombre de usuario y la contraseña encriptada utilizando el método crypt(), se puede configurar para utilizar otros métodos de encriptación. Para añadir usuarios a posteriori bastará con que utilicemos la misma línea anterior pero eliminando el modificador c El siguiente paso, una vez creado el fichero de contraseñas es configurar el servidor para que sólo permita el acceso al recurso a los usuarios adecuados. Si queremos proteger el contenido del directorio /var/www/sitio1/secreto tendremos que escribir en el fichero de configuración correspondiente lo siguiente:

22 <Directory /var/www/sitio1/secreto> AuthType Basic AuthName Acceso restringido AuthUserFile /var/apache passwords/password Require user usuario1 </Directory> Tras reiniciar el servidor y ver que todo funciona correctamente habría que probar que se muestra el diálogo de autenticación. Ilustración 6: Imagen de un diálogo de autenticación Como ya habíamos mencionado la directiva AuthType selecciona el método usado para autenticar al usuario. El método más común es Basic, sin embargo, este tipo de autenticación envía el password desde el cliente al servidor sin encriptar, por tanto no debe utilizarse para información altamente sensible salvo que se acompañe del uso del módulo mod_ssl. Apache soporta otro método conocido como Digest, es mucho más seguro y lo soportan los navegadores más recientes. Si queremos utilizar Digest debemos seguir los mismos pasos que en el caso anterior salvo porque al generar la contraseña utilizaremos htdigest del siguiente modo. htdigest c /var/apache passwd/password.md5 Acceso Restringido usuario1 Nótese que hay un argumento más, concretamente Acceso Restringido a este argumento se le conoce como Realm y debe coincidir exactamente con el contenido de la directiva AuthName.

23 La configuración quedaría como sigue: <Directory /var/www/sitio1/secreto> AuthType Digest AuthName "Acceso Restringido" AuthUserFile /var/apache passwords/password.md5 Require user usuario1 </Directory> Como ya hemos comentado la directiva AuthName establece el Realm que se utilizará en la autenticación. El Realm cumple con dos objetivos básicos: muestra información adicional al usuario en el diálogo de autenticación y sirve al usuario para identificar qué password enviar para cada área de acceso restringido. Por ejemplo, una vez que el cliente se ha autenticado contra el área Acceso restringido, intentará automáticamente reutilizar el mismo password para cualquier área del servidor marcada como Acceso restringido. Esto nos da la posibilidad de no estar molestando constantemente al usuario con diálogos de contraseñas si hacemos que zonas restringidas compartan el mismo Realm. En cualquier caso, por razones de seguridad, el usuario tendrá que volver a enviar la contraseña cada vez que cambie el hostname del servidor. La directiva AuthBasicProvider es opcional (de hecho no aparece en los ejemplos) por que el valor file se establece por defecto, pero sería necesaria si utilizásemos otros módulos para la autenticación, como por ejemplo: mod_authn_dbm o mod_authn_dbd. Finalmente la directiva AuthUserFile establece el path hacia el fichero de contraseñas que hayamos creado con htpasswd o htdigest. Hay que ser muy cuidadoso con la situación de este fichero en el sistema de ficheros, debe mantenerse siempre fuera del DocumentRoot del servidor. Si utilizásemos los módulos de acceso a bases de datos rápidas de usuario como mod_authn_dbm tendríamos que utilizar AuthDBMUserFile en vez de AuthUserFile, además tendríamos que generar las contraseñas utilizando la utilidad dbmmanage. Existen muchas otras opciones de autenticación que pueden consultarse en el sitio web de apache. Finalmente la directiva Require establece la parte de autorización indicando a qué usuario se permite el acceso a esta parte del servidor. Permitiendo el acceso a más de un usuario El ejemplo anterior permite el acceso a un único usuario y es cierto que podríamos indicar una lista de usuarios en el mismo fichero de configuración tal y como se indica a continuación, en el ejemplo permitimos el acceso a dos usuarios: usuario1 y manuel.

24 <Directory /var/www/sitio1/secreto> AuthType Basic AuthName "Acceso Restringido" AuthUserFile /var/apache passwords/password Require user usuario1 manuel </Directory> El ejemplo anterior tiene dos problemas, no es práctico para servidores con muchos usuarios y por otro lado, al estar en el fichero de configuración principal, tendremos que rearrancar una vez tras otra el servidor cada vez que añadamos un usuario. Para solucionar el problema anterior apache pone a nuestra disposición la directiva AuthGroupFile que nos permite agrupar a usuarios en grupos, lo único que necesitamos añadir es un archivo de definición de grupos que tiene una sintaxis muy sencilla: GroupName: usuario1, usuario2, usuario3 En el ejemplo que nos ocupa tendríamos que generar un fichero de grupos con el siguiente contenido: usuariosweb: usuario1, manuel Y cambiar el contenedor para que en vez de requerir usuarios, el proceso de autorización requiera grupos. <Directory /var/www/sitio1/secreto> AuthType Basic AuthName "Acceso Restringido AuthUserFile /var/apache passwords/password AuthGroupFile /var/apache passwords/grupos Require group usuariosweb </Directory> Creo que sobra comentar que los usuarios que aparecen en el fichero de grupos deben añadirse al fichero de contraseñas utilizando htpasswd o htdigest. Esta manera de trabajar nos permite ir añadiendo usuarios al fichero de usuarios e irlos agrupando en el fichero de grupos sin tener que reiniciar una vez tras otra el servicio.

25 Por último podríamos permitir el acceso a más de un usuario de una manera menos específica permitiendo el acceso a cualquier usuario válido utilizando la directiva: Require valid user Problemas de este enfoque del control de acceso Por el enfoque que se utiliza en la autenticación básica de usuarios, el nombre de usuario y contraseña debe comprobarse una vez tras otra directamente en un fichero de texto plano, además hay que recorrer secuencialmente el fichero, por tanto, a medida que crece el fichero las búsquedas serán más lentas. Hay que tener en cuenta que a pesar de que el navegador automatice el reenvío de la contraseña de manera transparente al usuario, este proceso tendrá lugar con cada solicitud, por lo que el rendimiento se resiente claramente. Es por eso que existen maneras alternativas de almacenar los nombres de usuario y contraseñas en bases de datos de acceso rápido. Apache dispone de los módulos mod_authn_dbm y mod_authn_dbd. A continuación mostramos el código de una posible utilización de estos módulos: <Directory /www/docs/private> AuthName "Private" AuthType Basic AuthBasicProvider dbm AuthDBMUserFile /www/passwords/passwd.dbm Require valid user </Directory> Recordamos una vez más que para generar los ficheros de contraseñas tendremos que utilizar dbmmanage. Otros medios de control de acceso El módulo de control de acceso de uso más habitual es, sin duda, mod_authz_host que permite restringir el acceso a zonas del servidor por dirección ip o nombre de host, aunque no es poco común el uso de mod_rewrite o mod_setenvif. Control de acceso por host Se utiliza para controlar el acceso a zonas de nuestro servidor a clientes con direcciones ip o nombres de dominio concretos. Las directivas Allow y Deny dan la posibilidad de permitir o denegar el acceso a zonas del servidor, siempre se utilizan junto con la directiva Order. La manera de utilizar las directivas Allow y Deny es la siguiente:

26 Allow from direccion Deny from direccion Dónde dirección es una dirección ip, una dirección ip parcialmente especificada, un nombre de dominio completamente especificado o un nombre de dominio parcialmente especificado. Por ejemplo, si hemos recibido peticiones repetitivas y molestas desde la ip podemos añadir la siguiente línea a nuestro fichero de configuración: Deny from Si conociéramos el nombre del dominio desde el que nos están generando peticiones molestas podríamos utilizarlo. Deny from navegantes.malvados.com También podríamos bloquear el acceso a un dominio completo o a un rango de direcciones: Deny from Deny from phishers.malvados.com otrospesados.ejemplo.com Deny from ke También podemos especificar pares de direcciones/máscara de red, lo que nos permite filtrar de una manera bastante fina los accesos al servidor. Por ejemplo: Allow from / # O con especificación CIDR Allow from /16 Del mismo modo pueden utilizarse direcciones o subredes IPV6: Allow from 2001:db8::a00:20ff:fea7:ccea Allow from 2001:db8::a00:20ff:fea7:ccea/10 La directiva Order La directiva Order controla el estado de acceso por defecto y el orden en el que se evaluan las directivas Allow y Deny. Order sólo puede tomar uno de los siguientes valores: Deny, Allow: Las directivas Deny se evalúan antes de las Allow. Se permite el acceso por defecto. Cualquier cliente que no concuerde con una directiva Deny o concuerde con una directiva Allow podrá acceder al servidor. Allow, Deny: La directiva Allow se evalúan antes que las Deny. El acceso se

27 deniega por defecto. Cualquier cliente que no concuerde con una directiva Allow o que concuerde con una directiva Deny no podrá acceder al servidor. Mutual failure: Sólo los hosts que aparezcan en la directiva Allow y que no aparezcen en la directiva Deny tendrán acceso. Tiene el mismo efecto que Allow, Deny y se recomienda que vaya dejando de usarse. Ejemplos: Order Deny,Allow Deny from all Allow from apache.org Se permite el acceso a todos los host del dominio apache.org y al resto se les deniega el acceso. Order Allow,Deny Allow from apache.org Deny from foo.apache.org En este caso se permite el acceso a todos los host del dominio apache.org, salvo los host del subdominio foo.apache.org. Cualquier host fuera del dominio apache tiene denegado el acceso, ya que es el estado por defecto. Si se hubiera establecido Order Deny, Allow se hubiera permitido el acceso a todos los host. Esto sucede porque Allow from apache.org se evaluará al final y sobreescribirá la directiva Deny from foo.apache.org Todos los host fuera del dominio apache.org podrían acceder, porque en este caso el estado por defecto es Allow. La presencia de una directiva Order puede afectar al acceso de una parte del servidor, incluso si no está acompañado por directivas Allow o Deny, ya que establece un estado por defecto. Por ejemplo: <Directory /www> Order Allow,Deny </Directory>

28 Denegará el acceso a /www porque el estado por defecto es Deny. Las directivas Allow o Deny que se encuentran en un contenedor <Location> siempre se aplicarán después de las que se encuentren en contenedores <Directory> o en archivos.htaccess sea cual sea el valor de la directiva Order.

29 Host Virtuales El término host virtual se refiere a la práctica de tener más de un sitio web (por ejemplo y alojado a la vez en una única máquina. Los host virtuales pueden dividirse en dos categorías: Host virtuales basados en ip: Que significa que cada sitio web alojado tiene su propia ip. Host virtuales basados en nombres: Que significa que podemos tener muchos sitios web con nombres distintos en cada dirección ip. En el caso de los host virtuales el hecho de que todos los sitios web estén alojados en el mismo servidor es completamente transparente a los clientes. Apache fue uno de los primeros servidores en soportar este tipo de alojamiento de páginas web, de hecho lo soporta desde la versión 1.1 Hosts virtuales basados en ip Como su propio nombre indica el servidor debe tener una dirección ip diferente para cada host virtual basado en ip. Esto se puede conseguir de dos maneras: Si la máquina dispone de varias conexiones físicas de red, o utilizando interfaces de red virtuales que soporta casi cualquier sistema operativo moderno. Hay dos posibilidades a la hora de ejecutar el servidor, o ejecutas un demonio servidor por cada host virtual o ejecutas un único demonio que de soporte a todos los host virtuales. Como norma general: Utiliza múltipes demonios si: Hay cuestiones relativas al particionado del servidor del tipo de que un usuario de la compañía1 no quiere que nadie de la compañía2 pueda leer sus datos salvo a través de la web. En este caso podrías tener dos demonios cada uno corriendo con distinta configuración de User, Group, Listen y ServerRoot Si puedes permitirte los requisitos de memoria y la necesidad de descriptores de ficheros de escuchar cada ip alias de la máquina. Sólo es posible escuchar a la interfaz comodín o a una dirección específica. Por eso si tienes que escuchar a una dirección específica, sea cual sea el motivo, entonces tendrás que escuchar a todas las direcciones específicas, aunque un demonio escuche N 1 direcciones y otro a la dirección restante.

30 Usa un único demonio cuando: Se puede barajar la opción de compartir la configuración entre varios hosts virtuales. Si el servidor tiene que atender gran número de peticiones y la pérdida de rendimiento debida a la ejecución de demonios separados es significativa. Configuración de un demonio por cada sitio. En este caso hay que crear una instalación distinta por cada host virtual y especificar la dirección a la que escucha utilizando la directiva Listen en cada demonio. Listen Siempre se recomienda que no se utilicen nombres de dominio sino direcciones ip. Configuración de un demonio con hosts virtuales En este caso se utiliza la directiva <VirtualHost> para establecer los valores de ServerAdmin, ServerName, DocumentRoot, ErrorLog y TrasferLog o CustomLog para que se adecuen a las necesidades de distintos sitios web. <VirtualHost ServerAdmin webmaster@mail.smallco.com DocumentRoot /groups/smallco/www ServerName ErrorLog /groups/smallco/logs/error_log TransferLog /groups/smallco/logs/access_log </VirtualHost> <VirtualHost ServerAdmin webmaster@mail.baygroup.org DocumentRoot /groups/baygroup/www ServerName ErrorLog /groups/baygroup/logs/error_log TransferLog /groups/baygroup/logs/access_log </VirtualHost> Una vez más, se deberían sustituir los nombres de dominio dentro de la etiqueta de apertura <VirtualHost> por las direcciones ip correspondientes.

31 Host Virtuales basados en nombres Este tipo de hosting presenta algunos problemas: Cuando se utiliza este tipo de alojamiento necesitamos que las solicitudes que envía el navegador del cliente incluyan el hostname. Los navegadores más antiguos no tienen esta característica, de modo que no podríamos servirles contenido. También da problemas con con servidores SSL por la propia naturaleza de los mismos. Algunos sistemas operativos y elementos de red implementan técnicas de regulación del ancho de banda que no permiten diferenciar hosts salvo que se referencien directamente mediante la dirección ip. Sin embargo, la escasez de direcciones ip y la facilidad de configuración de este tipo de hosting hacen que sea realmente común. Para utilizar hosts virtuales basados en nombres lo primero que hay que hacer es indicar la dirección ip y en algunos casos el puerto en los que estará escuchando el servidor. En el caso de que cualquiera de las direcciones ip del servidor pueda usarse se puede utilizar * como argumento. de la directiva NameVirtualHost. Si la idea es utilizar múltiples puertos, por ejemplo en el caso de que se piense utilizar ssl, debe añadirse el puerto al argumento de este modo *:80. El hecho de indicar una dirección en la directiva NameVirtualHost no hace que el servidor escuche automáticamente en esa IP. El siguiente paso es crear un bloque <VirtualHost> para cada host distinto que se quiera servir. El argumento de <VirtualHost> debe ser el mismo que el contenido de NameVirtualHost. Dentro de cada <VirtualHost> debe encontrarse, al menos, una directiva ServerName que designe la dirección a la que queremos atender y una directiva DocumentRoot para indicar en qué parte del sistema de ficheros se almacena el contenido que se desea servir. Si estamos añadiendo un host virtual a un servidor que ya tenía alojado un sitio deberemos incluir el sitio original en otro host virtual de manera que el ServerName y el DocumentRoot de este nuevo host virtual coincidan con los del servidor inicial. Si queremos que el mismo sitio web sea accesible desde distintos nombres de dominio podemos utilizar la directiva ServerAlias. ServerAlias dominio.es *.dominio.es