Servidores

20. Apache - Instalación y administración de SSL


1. Introducción

  • Apache ofrece soluciones para la comunicación segura mediante canales SSL a través del software gratuito de código abierto openssl (http://www.openssl.org).
  • Para ello es preciso compilar Apache con las opciones:
./configure --enable-ssl --with-ssl=ruta_hacia_openssl

(la ruta hacia openssl es /usr/local/ssl en la instalación predeterminada de openssl).


2.1 Emisión de un certificado de servidor.

  • Mediante openssl, generamos una clave privada:

openssl genrsa -out servidor.key 1024

  • Creamos una solicitud de certificado:

openssl req -new -key servidor.key -out servidor.csr

  • Ahora podemos elegir entre enviar nuestra solicitud de firma de certificado (Certificate Signing Request) a una entidad emisora de certificados (Thawte, Entrust, Verisign, etc.) o firmarlo nosotros mismos mediante openssl:

openssl x509 -req -days 365 -in servidor.csr -signkey servidor.key –out servidor.crt


2.2 Instalación de un certificado de servidor

  • Para indicar a Apache que utilice un certificado de servidor para conexiones SSL, simplemente hay que utilizar las siguientes directivas, indicando la ruta hacia el certificado y hacia la clave privada:
    • SSLEngine On
    • SSLCertificateFile ruta_al_certificado
    • SSLCertificateKeyFile ruta_a_la_clave_privada

Nota: estas funciones son propias del mod_ssl de Apache.


2.3 Configuración de Apache con SSL

Un ejemplo de servidor configurado con SSL:
	
	NameVirtualHost *
	<VirtualHost *:80>
		ServerName www.servidor1.com
		DocumentRoot /www/servidor1
	</VirtualHost><
	
	VirtualHost *:80>
		ServerName www.servidor2.com
		DocumentRoot /www/servidor2
	</VirtualHost><
	
	VirtualHost *:443>
		SSLEngine On
		SSLCertificateFile /www/ssl/ssl.crt
		SSLCertificateKeyFile /www/ssl/ssl.key
		ServerName www.servidor-seguro.com
		DocumentRoot /www/servidor-seguro
	</VirtualHost>
	

2.4 Indicaciones

  • No hay que olvidar que todos los puertos por los que escucha Apache hay que indicarlos con la directiva Listen. Por ejemplo:
Listen 80
Listen 443
  • Por la definición del protocolo https, no se puede emplear la etiqueta Hostname para discriminar peticiones seguras, de modo que un servidor, por cada dirección IP y puerto sólo admite un servidor virtual.
  • Si deseamos que el acceso al contenido de un directorio esté prohibido a menos que se realice mediante una conexión segura, podemos incluir SSLRequireSSL en un bloque Directory o una directiva .htaccess
vidalmb_admin – Mar, 24/07/2007 – 14:31

19. Apache - Instalación y administración de PHP


1. Indicaciones previas

  • Con las versiones actuales de PHP y Apache, se recomienda instalar PHP con MPMs no multihebra. En sistemas Unix/Linux, por ejemplo, utilizar prefork (el MPM predeterminado) y no worker, dado que PHP integra componentes y librerías de terceras partes, y añadir múltiples hebras de ejecución por cada proceso es incluir un elemento desestabilizador en el marco de ejecución de PHP.
  • Para ejecutar configure en la distro de Linux que estemos usando, será necesario tener instalado:
    • El procesador de macros M4, bison y flex, todos ellos descargables desde http://www.gnu.org
    • Los paquetes zlib1g-dev y libxml2-dev.

2. Pasos para habilitar la ejecución de PHP en Apache

  • Descargar y descomprimir el código fuente completo de PHP de http://www.php.net
  • En el directorio en el que se hayan extraído los archivos:
    • Ejecutar ./configure --with-apxs2=/usr/local/apache2/bin/apxs, modificando la ruta hacia apxs si no es ésa.
    • Ejecutar make.
    • Ejecutar sudo make install.
  • El programa de instalación crea una copia del archivo httpd.conf e incluye la siguiente línea (que se encarga de cargar el módulo de php5 de forma dinámica al arrancar el servidor):
LoadModule php5_module modules/libphp5.so
  • Para asociar la extensión .php al módulo de PHP, incluimos una directiva de servidor, servidor virtual, Directory y .htaccess; esto sería de la siguiente forma:
AddType application/x-httpd-php.php
  • Reiniciamos el servicio de Apache.
  • Verificamos el correcto funcionamiento de PHP ejecutando una página .php que contenga:
<? phpinfo(); ?>
  • Ubicamos la copia de la versión de php.ini que deseemos (php.ini-recommended o php.ini-dist) en el directorio en el que -según la página phpinfo-, lo está buscando el módulo de php.

3. Apache y PHP

PHP incluye algunas funciones específicas para Apache, al igual que ocurre con otros programas de código abierto como por ejemplo mysql. Del mismo modo, Apache incluye directivas específicas para PHP.

Por ejemplo: php_flag engine on|off habilita o deshabilita la ejecución de código php en el ámbito de una directiva Directory, Files, Location, de servidor, de servidor virtual o en un archivo .htaccess:

	

php_flag engine off
AddHandler php-deshabilitado.php
Action php-deshabilitado /cgi-bin/php-off.cgi

Siendo el contenido de php-off.cgi:

	

echo “Content-type: text/plain; charset=utf-8”
echo
echo “La ejecución de páginas php está deshabilitada.”


vidalmb_admin – Dom, 22/07/2007 – 12:28

18. Apache - Tareas comunes

1.1 Establecer el directorio raíz

  • El directorio raíz de un sitio web se determina mediante la directiva DocumentRoot <ruta_de_directorio> (ámbito: sv)
  • Su valor predeterminado es el directorio htdocs en el directorio de instalación de Apache.
  • Si la ruta de directorio no es absoluta, se toma como relativa al valor de la directiva ServerRoot (directorio de instalación de Apache)
  • Es importante reflejar en el grupo Directory correspondiente cualquier modificación en el valor de esta directiva.
  • Leyenda:

s: configuración de servidor
d: directory
v: servidor virtual
h: .htaccess


1.2 Directorios virtuales

  • Mediante la directiva Alias ruta_URL ruta_física (ámbito: sv) podemos acceder a contenido ubicado fuera del directorio indicado en DocumentRoot. Las peticiones a la ruta URL indicada serán aplicadas al directorio físico indicado (ej: Alias /dirVirtual /www/virtual)
  • Otro posible uso de esta directiva es acceder al mismo contenido mediante URLs distintas.
  • La directiva AliasMatch es similar, pero emplea expresiones regulares ( Ej: AliasMatch ^/document(os|acion)(.*) /www/htdocs/documentacion$2 )
  • También es posible acceder a contenido fuera del directorio indicado en DocumentRoot mediante enlaces simbólicos (si lo permite la directiva Options mediante su valor FollowSymLinks), pero se desaconseja, ya que:
    • se tiene un menor control sobre estos enlaces existentes a contenido externo (no se ven reflejados en los archivos de configuración)
    • no precisa establecer permisos mediante directivas Directory sobre el contenido externo.

1.3 Redirección a otro servidor

  • Para redirigir al cliente a una URL distinta empleamos Redirect status ruta_URL URL_destino (ámbito: svdh)
    • ruta_URL es una url absoluta con respecto al directorio raíz (comienza con /)
    • URL_destino es una URL completa (http://...)
    • status puede ser:
      • permanent: indica que el recurso ha sido definitivamente reubicado en la nueva URL indicada.
      • temp: redirección temporal (status predeterminado).
      • seeother: indica que la url ya no es válida y remite a una dirección en la que poder encontrar el contenido que ha reemplazado al anterior.
      • gone: indica que el recurso ha sido eliminado definitivamente.
  • Podemos emplear RedirectMatch de forma análoga utilizando expresiones regulares.

Ej: RedirectMatch (.*)\.gif$ http://www.otroServidor.com$1.jpg


1.4 URLs insensibles a mayúsculas

  • Mediante la directiva CheckSpellingon|off (ámbito: svdh), que se incluye en el módulo mod_speling, al activarla indicamos al servidor que antes de servir un error de “archivo no encontrado”, intente realizar comparaciones con el nombre del recurso solicitado y los existentes en el mismo directorio ignorando mayúsculas y minúsculas y permitiendo un error tipográfico (una letra omitida o de más, o 2 caracteres traspuestos).

1.5 Documento predeterminado

  • Mediante DirectoryIndex documento [documento] … [documento] (ámbito: svdh) podemos especificar los nombres de los documentos predeterminados para mostrar cuando se recibe una petición que apunta a un directorio, sin especificar archivo.

1.6 Mensajes de error personalizados

  • Con ErrorDocument código_de_error documento (ámbito: svdh) podemos emitir mensajes de error personalizados.
  • Ejemplo:
    • ErrorDocument 404 /www/errores/mapaWeb.html
    • ErrorDocument 404 “Objeto no encontrado”.

1.7 Permisos de acceso al contenido

  • Mediante las directivas Order, Allow y Deny (ámbito: dh) se determina el acceso al contenido según IP, nombre del host o cualquier característica del cliente capturada en variables de entorno.
  • Order determina el orden en que son evaluadas las directivas:
    • Order Deny,Allow indica que se evalúan primero las directivas de denegación de permisos.
    • Order Allow,Deny indica que se evalúan primero las directivas de concesión de permisos.
  • Allow|Deny from all|host|env=var [host|env=var]
  • Ejemplo:

		  Allow from 192.168.1.10
		  Allow from 192.168
		  Allow from laboratorio.es


1.8 Operaciones sobre el contenido

  • Mediante la directiva Options[+|-]option [[+|-]option] ...(ámbito: svdh) definimos las operaciones permitidas sobre el contenido.
    • All: (PREDETERMINADO): todas las opciones permitidas, excepto MultiViews.
    • None: ninguna opción permitida.
    • ExecCGI: permite la ejecución de scripts CGI.
    • FollowSymLinks: Se permite seguir enlaces simbólicos.
    • Includes: Se permiten las funciones Server-side includes de mod_include.
    • IncludesNOEXEC: Las funciones Server-side includes están permitidas, excepto #exec cmd y #exec cgi, que están deshabilitadas.
    • Indexes: Muestra un listado del contenido del directorio como respuesta a una url que apunta a un directorio sin documento predeterminado.
    • MultiViews: Se permiten vistas múltiples según el contenido, a través del módulo mod_negotiation.
    • SymLinksIfOwnerMatch: Se seguirán los enlaces simbólicos en los casos en los que el propietario del enlace y del destino sean el mismo.
  • Si en todas las opciones utilizadas anteponemos un signo + o – (según si queremos aplicar o denegar cada opción), en lugar de sobreescribirse, las opciones se fusionarán:

<Directory /www/htdocs>
Options Indexes
FollowSymLinks
</Directory>

<Directory/www/htdocs/dir>
Options Includes
</Directory>

<Directory /www/htdocs >
Options Indexes

FollowSymLinks
</Directory>

<Directory /www/htdocs/dir>
Options +Includes –Indexes
</Directory>

Sobre /www/htdocs/dir se aplica: Includes

Sobre /www/htdocs/dir se aplican: Includes, FollowSymLinks


1.9 Directorios web personales

  • Empleando la directiva UserDir (ámbito: sv) podemos definir directorios web para los usuarios del sistema.
  • Si después de UserDir aparece:
    • ruta_relativa: se asume que es relativa al directorio home de cada usuario (ej: UserDir www traduciría http://servidor/~usuario/archivo.html a /home/usuario/www/archivo.html
    • ruta_absoluta: se busca un directorio con el nombre del usuario en esa ruta (ej: UserDir /www/usuarios traduciría http://servidor/~usuario/archivo.html a /www/usuarios/usuario/archivo.html
    • ruta_absoluta con *: se traduce el * por el nombre del usuario (ej: UserDir /www/usuarios/*/htdocs traduciría http://servidor/~usuario/archivo.html a /www/usuarios/usuario/htdocs/archivo.html
  • Se pueden restringir los usuarios afectados por esta directiva:
    • UserDir disabled: deshabilita todas las traducciones de nombre de usuario a directorio excepto para aquellos usuarios explícitamente mencionados en UserDir enabled.
    • UserDir disabled <usuario> [<usuario>] … [<usuario>]: los usuarios que aparezcan en esta lista nunca tendrán traducción a directorio, aunque aparezcan en UserDir enabled.
    • UserDir enabled <usuario> [<usuario>] … [<usuario>]: los usuarios que aparezcan en esta lista tendrán traducción a directorio aunque un UserDir disable global esté en vigor, pero no si aparecen explícitamente en una lista de UserDir disabled.
vidalmb_admin – Sáb, 21/07/2007 – 21:35

17. Apache - Configuración

1.1 Archivos de configuración

  • Apache se configura mediante directivas ubicadas en archivos de texto.
  • El principal de estos archivos es httpd.conf
  • La ubicación de este archivo se determina durante la configuración de la instalación (en/conf por defecto), pero se puede especificar con el parámetro –f al iniciar el servicio.
  • Se puede incluir un número indefinido de archivos adicionales de configuración mediante la directiva Include.
  • Los cambios en los archivos de configuración sólo tienen efecto tras reiniciar el servicio.
  • Otros archivos en los que se pueden almacenar algunos tipos de directivas descentralizadas en cualquier directorio de contenido son los archivos .htaccess:
    • Se deben llamar así de forma predeterminada, pero su nombre se puede especificar mediante la directiva AccessFileName.
    • Se pueden ubicar en cualquier directorio de un sitio web.
    • Las directivas en estos archivos afectan a todos los archivos y directorios a partir del directorio en el que se encuentran.
    • Tienen efecto inmediato (no es preciso reiniciar el servicio).

 

1.2 Sintaxis de configuración

  • Los comentarios se marcan con una # inicial.
  • Cada línea admite una sola directiva
  • Se puede emplear una barra invertida \ como último carácter de una línea para indicar que continúa en la siguiente.
  • Se ignoran las líneas en blanco y los espacios iniciales.
  • Si una directiva aparece en el mismo ámbito más de una vez, prevalece el valor de la última aparición.

 

2.1 Ámbito de las directivas I

  • La parte inicial de httpd.conf está dedicada a las directivas de configuración del servidor, como:
    • ServerRoot: indica la ruta de instalación del servidor, donde se ubican los directorios de configuración y logs.
    • Listen: determina la dirección (o direcciones) IP y el / los puertos que atiende el servidor.
    • User, Group: identidad con la que se ejecutarán los procesos hijo.
    • LoadModule: permite cargar módulos adicionales dinámicamente, sin necesidad de recompilar y reinstalar el servicio.

 

2.2 Ámbito de las directivas II

  • A continuación, las directivas del servidor principal, por ejemplo:
    • ServerName: nombre con que se identifica el servidor.
    • ServerAdmin: dirección de correo electrónico del administrador del sitio web.
    • DocumentRoot: indica el directorio raíz del sitio web.
    • DirectoryIndex: archivo(s) predeterminado(s).
    • AccessFileName: indica el nombre de los archivos con directivas locales de directorios.

 

2.3 Ámbito de las directivas III

  • La directiva <Directory ruta_de_directorio>(se cierra con </Directory>) se emplea para delimitar un conjunto de directivas que se aplicarán al directorio físico indicado y a sus subdirectorios.
  • Está orientada, por tanto, al sistema de archivos.
  • Pueden emplearse en la ruta del directorio comodines de comandos:
    • ? representa un carácter cualquiera
    • * representa un conjunto cualquiera de caracteres
  • No se pueden anidar las directivas Directory, prevaleciendo siempre la más interna en caso de coincidencia.

En el caso:

			<Directory /www>
					DirectoryIndex index.html 
			<Directory>
	
			<Directory /www/menu>
					DirectoryIndex inicio.html 
			<Directory>

Una petición a /www/menu/ buscaría como documento predeterminado inicio.html

  • La directiva DirectoryMatch es equivalente a Directory, pero la ruta del directorio se expresa mediante expresiones regulares y son procesadas en último lugar, dentro de las directivas <Directory>

 

2.4 Ámbito de las directivas IV

  • La directiva <Files nombre_de_archivo> (se cierra con </Files>) delimita directivas aplicables a cualquier archivo cuyo nombre coincida con el indicado.
  • Está orientada al sistema de archivos.
  • Se puede limitar el alcance de esta directiva anidándola en una directiva <Directory>, de manera que sólo afectará a los archivos coincidentes en el directorio y subdirectorios indicados por la directiva contenedora.
  • La directiva <FilesMatchExprReg> es análoga, pero indica el nombre del archivo mediante expresiones regulares.

Un ejemplo de uso de esta directiva lo tenemos en el archivo httpd.conf inicial de Apache, empleándose para impedir el acceso a los archivos .htaccess y .htpasswd:

			<FilesMatch "^\.ht">
					Order allow,deny
					Deny from all
			</Files>

 

2.5 Ámbito de las directivas V

  • Los archivos .htaccess se pueden ubicar en cualquier directorio y las directivas que contienen son aplicables a todo el contenido del directorio en el que se encuentran.
  • Su aplicación se encuentra supeditada a la directiva AllowOverride que se les pueda aplicar contenida en directivas <Directory>.
  • Su uso se desaconseja a menos que sea inevitable, ya que:
    • Se pueden sustituir por directivas <Directory> directamente en el archivo de configuración.
    • Se dispersa la configuración del servicio en múltiples archivos.
    • Son procesados en cada petición, lo que afecta al rendimiento.

 

2.6 Ámbito de las directivas VI

  • La directiva <Location URL> (se cierra con </Location>) permite definir directivas aplicables a rutas web –en lugar de físicas.
  • Está, por tanto, orientado a URLs.
  • Es procesada después que las directivas <Directory> y <Files> y los archivos .htaccess
  • La directiva análoga <LocationMatch> permite el empleo de expresiones regulares en la URL.

Un ejemplo de aplicación de esta directiva (si se tiene instalado el módulo mod_status):

			<Location /status>
					SetHandler server-status
			</Location>

 

2.7 Ámbito de las directivas VII

  • Existen, además directivas condicionales, que se aplican si se satisface una condición:
    • <IfDefine test> … </IfDefine> donde test puede ser:
        • nombre_de_parámetro
        • nombre_de_parámetro
        con nombre_de_parámetro definido al arrancar el servicio con –D.

Ejemplo:

	<IfDefine app1FueraDeServicio>
			RedirectMatch /app1Web/(.*) http://localhost/fueraDeServicio
	</IfDefine>
    • <IfModule test>...</IfModule> define de forma análoga una condición según si un módulo está cargado o no.
    • <IfVersion [[!]operador] versión> ... </IfVersion> define una condición basándose en la versión del servidor Apache, donde operador puede ser =, ==, <, <=, >, >=.

Ejemplo:

	<IfVersion >= 2.0>
			# directivas aplicables a versiones posteriores a la 2.0.0
	</IfVersion>

 

2.8 Ámbito de las directivas VIII

  • La directiva VirtualHost permite definir servidores virtuales:
    • La sintaxis es <VirtualHost dirección[:puerto] [dirección[:puerto]] ...> ... </VirtualHost>
    • El puerto debe estar incluido en la directiva de Servidor Listen

Ejemplo:

			NameVirtualHost *:80
			
			<VirtualHost *:80>
				DocumentRoot /www/root1
				ServerName www.servidor1.com
				# Directivas de configuración
				# Éste sería el sitio web predeterminado
			</VirtualHost>
		
			<VirtualHost *:80>
				DocumentRoot /www/root2
				ServerName www.servidor2.com
				# Directivas de configuración
			</VirtualHost>

 

2.9 Ámbito de las directivas IX

  • Orden de aplicación de las directivas (prevalecen las últimas):
      1. <Directory> (excepto con expresiones regulares) y archivos .htaccess (con los .htaccess, si están permitidos, prevaleciendo sobre <Directory>)
      2. <DirectoryMatch>
      3. <Files> y <FilesMatch>
      4. <Location> y <LocationMatch>

Excepto <Directory>, cada grupo de directivas es procesado en el orden en que aparecen en el archivo de configuración.

En los grupos <Directory> en conflicto, se ejecuta la ruta más larga al final (<Directory /www/dir1/dir2> prevalecerá sobre <Directory /www/dir1>).

Las directivas de otros archivos de configuración incorporadas mediante la directiva Include se procesan como si figurasen en el archivo de configuración que contiene la directiva Include.

Las directivas dentro de un bloque <VirtualHost> se procesan después que las directivas de primer nivel. Así se consigue que la directiva del Host virtual prevalezca sobre la que está definida en el servidor principal.

 

Fichero pdf para descargar aquí.

vidalmb_admin – Mar, 22/08/2006 – 16:17

16. Apache - Inicio del servidor

1. Script de control

  • Una vez instalado Apache, las tareas de arranque, reinicio y parada del servicio se realizan mediante el script /bin/apachectl, que admite los siguientes parámetros:
    • start: inicia el servicio web httpd.
    • stop: detiene el servicio web httpd.
    • restart: reinicia el servicio web httpd.
    • graceful: reinicia el servicio web, esperando a que los procesos hijo atiendan las peticiones en curso. El proceso padre carga de nuevo la configuración, inicia una nueva sesión de registro de actividad y conforme van terminándose los procesos hijo anteriores, se generan otros nuevos que comienzan inmediatamente a atender peticiones.
    • graceful-stop: detiene el servicio web, esperando a que los procesos hijo terminen de atender las peticiones en curso.

 

2. Iniciar y detener Apache con el sistema

  • Para iniciar el servicio web de Apache con el arranque del sistema:
    • Determinamos el nivel de ejecución por defecto ejecutando el comando runlevel.
    • Creamos un vínculo simbólico a apachectl desde /etc/init.d
    • En el directorio /etc/rcN.d (donde N es el nivel de ejecución predeterminado) creamos un vínculo simbólico al enlace en /etc/init.d respetando la nomenclatura SNN<nombre_del_enlace_en_init.d> donde NN indica el orden de ejecución con respecto a los demás scripts de ese directorio. De este modo, siempre que el servidor arranque con el runlevel predeterminado, se iniciará el servicio web Apache.
    • Análogamente, en los directorios /etc/rc0.d y /etc/rc6.d creamos vínculos simbólicos al enlace en /etc/init.d respetando la nomenclatura KNN<nombre_del_enlace_en_init.d> para que el servicio se detenga al apagar y reiniciar el servidor.

 

Fichero pdf para descargar aquí.

vidalmb_admin – Mar, 22/08/2006 – 16:14

15. Apache - Introducción e Instalación

1. Origen de Apache

  • El NCSA (National Centre for Supercomputing Applications) de EE.UU. desarrolló un servidor web que se convirtió en el más extendido y empleado a comienzos de 1995.
  • Fue entonces cuando el principal desarrollador del NCSA Web Server abandonó el NCSA y el proyecto comenzó a estancarse.
  • Los usuarios del programa servidor comenzaron a desarrollar sus propios parches y ampliaciones hasta que finalmente surgió el Grupo Apache como punto de encuentro, de gestión de modificaciones en el código fuente y de publicación de actualizaciones y nuevas versiones.
  • La versión 1.0 del servidor Apache se hizo pública en diciembre de 1995, y en sólo 3 años lideraba el sector de servidores web. La última versión disponible actualmente es la 2.2.

 

2. El servidor web más popular

Apache se ejecuta en 50.588.433 sitios web de los 80.655.992 existentes en abril de 2006, lo que supone un 62,72 % del total.

 

3. Características de Apache

  • Servidor web compatible con el protocolo HTTP/1.1
  • De estructura completamente modular, tanto por su filosofía como por su desarrollo y propósito multiplataforma.
  • Altamente configurable y adaptable.
  • Extensible de forma particular mediante el desarrollo de módulos propios usando la API para módulos de Apache.
  • Gratuito y de código abierto.

 

4. Arquitectura de Apache

  • A partir de la versión 2.0 de Apache se produjo un gran cambio en su arquitectura, surgiendo el concepto de los Módulos de Multiprocesamiento (MPMs – MultiProcessing Modules).
  • En la versión 1.3 y anteriores, un proceso central generaba otros procesos hijo que atendían las peticiones. El proceso padre simplemente monitorizaba, generaba y finalizaba los procesos hijo según las peticiones.
  • Existen los siguientes esquemas de MPM, sólo uno de los cuales puede instalarse y emplearse en un servidor Apache:
      • beos: módulo optimizado para BeOS.
      • event: versión experimental de worker.
      • mpm_netware: módulo optimizado para Novell Netware.
      • mpmt_os2: módulo multi-proceso y multi-hebra optimizado para OS/2.
      • prefork: módulo multi-proceso NO multi-hebra.
      • mpm_winnt: módulo optimizado para Windows, empleando funciones nativas. Sólo crea un proceso hijo con múltiples hebras de ejecución.
      • worker: módulo multi-proceso y multi-hebra.
  • Según el sistema operativo, el MPM instalado por defecto es:
      • BeOS:beos
      • Netware: mpm_netware
      • OS/2:mpmt_os2
      • Unix / Linux:prefork
      • Windows: mpm_winnt
  • Además de las directivas indicadas en cada caso, existen 2 propias del servidor a las que puede asignarse un valor distinto del predeterminado, pero que en tal caso deben figurar antes que las directivas propias del MPM:
      • ServerLimit: determina el número máximo de procesos hijo. Su valor predeterminado es:
        • 256 en mpm_prefork.
        • 16 en los casos restantes.
      • ThreadLimit: determina el número máximo de hebras de ejecución por proceso hijo. Su valor predeterminado es:
        • 1920 en mpm_winnt.
        • 64 en los casos restantes.
  • prefork:
      • Sólo una hebra de ejecución
      • Cada proceso gestiona sólo una petición simultáneamente, de manera que el impacto por fallo en una petición es mínimo.
      • Similar a la estructura empleada por versiones anteriores de Apache.

Se crea un proceso padre que gestiona los procesos hijo que atenderán las peticiones, procurando que siempre haya alguno libre para poder atender las nuevas peticiones rápidamente.

Este MPM se adapta por lo general a los recursos del sistema, de manera que requiere escaso trabajo de configuración, pero sí es importante ajustar sus directivas (en <directorio de apache>/conf/extra/httpd-mpm.conf).

      • StartServers: número inicial de procesos hijo (5).
      • MinSpareServers: número mínimo deseado de procesos hijo desocupados (5).
      • MaxSpareServers: número máximo de procesos hijo desocupados (10).
      • MaxClients: número máximo de procesos hijo. Debe tener un valor adecuado, de manera que sea suficientemente elevado para responder a las peticiones existentes, pero suficientemente bajo para asegurar la memoria física necesaria para todos los procesos (256). Si elevamos este número por encima de 256, también hay que asignar el mismo valor a ServerLimit.
      • MaxRequestsPerChild: número de peticiones que atenderá un proceso hijo (0 = ilimitado).

El proceso padre se crea asociado al puerto 80 por defecto, de modo que debe ser lanzado como root. Los procesos hijo se generan con el usuario y el grupo indicados por las directivas de servidor user y group en httpd.conf.

  • worker:
      • Sistema híbrido multi-proceso y multi-hebra.
      • Es capaz de atender un mayor número de peticiones con el mismo número de procesos y los mismos recursos.
      • Del mismo modo, un proceso que se vea bloqueado por una petición afectará a todas las demás peticiones que estaban siendo atendidas por ese mismo proceso.

Un único proceso padre de control crea los procesos hijo, cada uno con un número determinado de hebras de ejecución. El proceso de control procura que siempre haya un determinado número de hebras disponibles. Sus directivas son:

      • StartServers: número inicial de procesos (2)
      • MaxClients: número máximo de conexiones simultáneas de clientes (150)
      • MinSpareThreads: número mínimo de hebras de ejecución desocupadas (25)
      • MaxSpareThreads: número máximo de hebras de ejecución desocupadas (75)
      • ThreadsPerChild: número de hebras de ejecución constantes en cada proceso hijo (25)
      • MaxRequestsPerChild: número máximo de peticiones que atiende un proceso (0)

Por tanto, el número máximo de procesos será MaxClients / ThreadsPerChild, y hay que tener en cuenta el límite predeterminado de 16 que indica ServerLimit.

Al igual que con el modelo prefork, el proceso padre se crea asociado al puerto 80 por defecto, de modo que debe ser lanzado como root. Los procesos hijo se generan con el usuario y el grupo indicados por las directivas de servidor user y group en httpd.conf.

 

5. Instalación de Apache

  • Requisitos del sistema:
      • 50 MBs libres de espacio en disco.
      • Compilador ANSI-C y capacidad para generar ejecutables. Se aconseja el GNU C Compiler (GCC).
      • Recomendado: intérprete de PERL versión 5.003 ó superior. No es imprescindible para el funcionamiento del servidor, sólo para la ejecución de algunos scripts.
  • Proceso de instalación:
      • Descargar el código fuente de la última versión disponible de http://www.apache.org (o el mirror más próximo).
      • Descargar la firma digital del código fuente y el archivo de claves públicas de los desarrolladores de Apache.
      • Para comprobar la autenticidad del código:
      • Importamos las firmas: gpg --import KEYS
      • Verificamos el código: gpg --verify httpd-2.2.0.tar.gz.asc
      • Descomprimimos el código fuente.
      • gzip –d httpd-2.2.0.tar.gz
      • tar xvf httpd-2.2.0.tar
      • Ejecutamos el script configure
      • ./configure --prefix=directorio de instalación (valor predeterminado: /usr/local/apache2 )
      • podemos añadir posteriormente opciones de configuración ejecutando ./config.status
      • Compilamos el código fuente:
      • make
      • Y realizamos la instalación:
      • make install
      • Para arrancar el servicio HTTP de Apache:
      • <directorio de Apache>/bin/apachectl start

Módulos habilitados por defecto: algunos módulos se instalan de forma predeterminada, a menos que se indique lo contrario mediante el script configure. Podemos ver los módulos instalados en el servidor con bin/apachectl –l o bin/httpd -l

  • core: núcleo de Apache, siempre está instalado.
  • prefork: por defecto, en un sistema Unix o Linux se escoge este esquema de MPM.
  • mod_actions: habilita eventos lanzados por peticiones, que son tratados por scripts.
  • mod_alias: permite el preprocesamiento de la URL, estableciendo relaciones entre direcciones en la URL y rutas en el sistema de archivos.
  • mod_asis: permite el envío de archivos que incluyen sus propias cabeceras, de manera que Apache no las incluye.
  • mod_auth_basic: habilita la autenticación básica, como texto sencillo sin encriptar.
  • mod_authn_file: provee a los módulos de autenticación de un repositorio de contraseñas en archivos de texto.
  • mod_authn_default: sin otros métodos de autenticación, como mod_authn_basic, este módulo nos permite transferir la autenticación a otros módulos de bajo nivel.
  • mod_authz_host: gestiona autorizaciones de acceso en grupo según criterios según nombre del host o dirección IP.
  • mod_authz_groupfile: autorizaciones de acceso según grupos definidos en un archivo de texto.
  • mod_authz_user: autorizaciones de acceso según el usuario.
  • mod_authz_default: sin otros módulos de autenticación, como mod_authz_groupfile o mod_authz_user, permite indicar otros métodos de autenticación de bajo nivel.
  • mod_include: filtro que procesa las respuestas antes de ser enviadas al cliente y permite las tareas típicas de Server Side Includes, como incluir archivos, control condicional, imprimir o establecer variables de entorno, ejecutar scripts, etc.
  • mod_filter: permite un control inteligente de los filtros de salida, de manera que el contenido es procesado sólo por los filtros pertinentes.
  • mod_autoindex: permite la visualización del listado de un directorio si no existe un documento predeterminado.
  • mod_cgi: cuando se utiliza un MPM NO multi-hebra, como prefork, mod_cgi permite la ejecución de scripts CGI.
  • mod_cgid: cuando se utiliza un MPM multi-hebra, como worker, mod_cgid permite la ejecución de scripts CGI. Este módulo emplea un demonio externo dedicado a la ejecución de scripts CGI.
  • mod_log_config: registra las peticiones recibidas en el servidor.
  • mod_env: controla las variables de entorno manejadas por los scripts CGI y por los SSI.
  • mod_setenvif: permite establecer variables de entorno según características de la petición (por ejemplo, según la dirección IP del cliente o el navegador que esté empleando).
  • mod_mime: asocia las extensiones de los archivos con el procesamiento que recibirán y la especificación del contenido.
  • mod_status: suministra información del rendimiento del servidor.
  • mod_negotiation: permite la negociación del contenido, según las especificaciones del protocolo HTTP/1.1, para ofrecer al cliente la versión del archivo que más se adapte a sus preferencias, si es posible.
  • mod_dir: controla la asignación de un documento predeterminado y la adición automática del carácter “/” al final de una url que apunta a un directorio.
  • mod_userdir: permite la asignación de directorios a usuarios mediante urls del tipo http://servidor.dominio/~usuario
  • mod_so: permite cargar módulos en Apache en tiempo de ejecución mediante el mecanismo DSO (Dynamic Shared Object).

 

Fichero pdf para descargar aquí.

vidalmb_admin – Mar, 22/08/2006 – 13:30

14. Seguridad en IIS 6 - Permisos y Autenticación

1. Niveles de permisos

Con IIS 6, manejamos 2 niveles de permisos:

    • Permisos NTFS: son los del sistema de archivos del sistema y determinan el nivel de acceso a cada archivo o directorio para cada usuario.
    • Permisos Web: permisos especiales propios de IIS que determinan el nivel de acceso de un cliente web o FTP sobre un determinado contenido: si tiene acceso a un directorio virtual, si puede leer un determinado archivo, o mostrar el contenido de un directorio, por ejemplo.

Los permisos NTFS son característicos del sistema de archivos de Windows y los gestiona el sistema operativo, mientras que los permisos Web son característicos de HTTP y los gestiona IIS.

Al recibir el servidor una petición, en primer lugar, se comprueban los permisos IIS, y después se comprueban los permisos NTFS.

 

2.1 Permisos NTFS – nivel de acceso

Los parámetros que determinan el nivel de acceso sobre un determinado directorio o archivo son:

    • Recorrer carpeta / ejecutar archivo:
      • Para carpetas: permite o deniega el movimiento por las carpetas para llegar a otros archivos o carpetas, incluso si el usuario no tiene permisos para las carpetas recorridas.
      • Para archivos: el permiso Ejecutar archivo permite o deniega la ejecución de archivos de programa.
    • Listar carpeta / leer datos:
      • Para carpetas: permite o deniega ver nombres de archivos y subcarpetas de la carpeta.
      • Para archivos: permite o deniega la vista de datos de archivo en archivos.
    • Atributos de lectura: permite o deniega la vista de los atributos NTFS de un archivo o carpeta, como sólo lectura y oculto.
    • Atributos extendidos de lectura: permite o impide que el usuario vea los atributos extendidos de un archivo o de una carpeta. Los atributos extendidos pueden definirse por programas y pueden variar de uno a otro.
    • Crear archivos / Escribir datos:
      • Para carpetas: permite o impide al usuario crear archivos en la carpeta.
      • Para archivos: permite o impide que el usuario haga cambios en el archivo y sobrescriba contenido existente.
    • Crear carpetas / Anexar datos:
      • Para carpetas: permite o impide al usuario crear carpetas en la carpeta.
      • Para archivos: permite o impide que el usuario haga cambios en el final del archivo pero que no cambie, elimine ni sobrescriba datos existentes.
    • Atributos de escritura: permite o impide el cambio de los atributos NTFS de un archivo o de una carpeta, como sólo lectura y oculto.
    • Atributos extendidos de escritura: permite o impide que el usuario cambie los atributos extendidos de un archivo o de una carpeta.
    • Eliminar subcarpetas y archivos (este permiso se aplica sólo a las carpetas): permite o impide que el usuario elimine subcarpetas y archivos, incluso aunque no se haya concedido el permiso Eliminar para la subcarpeta o el archivo.
    • Eliminar: permite o impide que el usuario elimine el archivo o la carpeta.
    • Leer permisos: permite o impide que el usuario lea permisos de seguridad del archivo o carpeta.
    • Cambiar permisos: permite o impide que el usuario cambie permisos de seguridad del archivo o de la carpeta.
    • Tomar posesión: permite o impide que el usuario tome posesión del archivo o de la carpeta. El propietario de un archivo o de una carpeta puede cambiar los permisos correspondientes, cualesquiera que sean los permisos existentes que protegen el archivo o la carpeta.

 

2.2 Agrupación de permisos NTFS

Nota: los grupos o los usuarios a los que se concede Control total para una carpeta pueden eliminar cualquier archivo de dicha carpeta, cualesquiera que sean los permisos que protegen al archivo.

Nota: aunque parece que Mostrar el contenido de la carpeta y Leer y ejecutar tienen los mismos permisos especiales, estos permisos se heredan de manera diferente. Mostrar el contenido de la carpeta lo heredan las carpetas, pero no los archivos, y sólo aparece al ver los permisos de carpetas. Leer y ejecutar lo heredan tanto los archivos como las carpetas.

 

2.3 Permisos NTFS en un directorio Web

El sistema asigna por defecto permisos de escritura al usuario anónimo de IIS.

Por eso, a menos que se requieran permisos adicionales (creación de archivos, por ejemplo), es muy aconsejable restringir los permisos NTFS en el directorio raíz de un sitio web (tabla en la siguiente página).

 

3. Permisos web

    • Lectura: permite ver o descargar archivos del directorio.
    • Escritura: permite a los usuarios colocar archivos en el directorio o modificarlos.
    • Examen de directorios: permite mostrar un listado del directorio cuando no se encuentra un documento predeterminado en el directorio. Normalmente, se tendrá deshabilitada esta opción para no publicar el contenido de un directorio.
    • Acceso al código fuente de secuencias de comandos: permite a los usuarios acceder al código fuente de páginas de script –como ASP o PHP- en lugar de recibir el resultado de su ejecución. Esta opción sólo debe estar seleccionada cuando sea necesario (por ejemplo por estar utilizando webDAV) y siempre en entornos controlados, teniendo en cuenta el contenido que puede estar viajando por la red.

 

4.1 Métodos de autenticación

    • IIS 6 incluye distintos métodos de autenticación de usuarios:
    • Acceso anónimo
    • Autenticación de Windows integrada
    • Autenticación de texto implícita para servidores de dominio Windows
    • Autenticación básica
    • Autenticación de .NET Passport

Todos estos métodos están disponibles para los sitios web, mientras que los sitios FTP sólo disponen de Acceso anónimo y Autenticación básica. 

 

4.2 Características

 

5. Mecanismos de seguridad

    • Absolutamente prioritario: mantener el servidor al día de actualizaciones críticas.
    • Restricciones por IP y por dominio:
      • IIS 6 ofrece la posibilidad de restringir el acceso para cada elemento de un sitio web según criterios de dirección IP y/o pertenencia a un dominio.
        • Es preferible emplear criterios de dirección IP, ya que el servidor recibe la dirección IP del cliente, y averiguar la pertenencia a un dominio obliga a realizar una búsqueda de DNS inversa.
      • Emplear estos mecanismos siempre que nos sea posible, es una buena medida de seguridad, aunque no infalible, ya que las direcciones IP se pueden falsear.
    • Identidad de los procesos de trabajo:
      • Un proceso de trabajo, cuando procesa la petición de un cliente, adquiere la identidad del usuario asociado al cliente. Sin embargo, requiere de una identidad inicial propia, ya que debe existir siempre en un contexto de seguridad.
      • De las 3 opciones que nos ofrece IIS por defecto como identidad inicial de los procesos de trabajo de una aplicación, la mejor –por tener el menor número de permisos- es Servicio de red-, que es la predeterminada.
    • Identidad de los grupos de aplicaciones:
      • Podemos independizar las identidades de los grupos de aplicaciones entre sí, creando para cada uno una cuenta de usuario con contraseña compleja y haciéndola miembro del grupo IIS_WPG.
      • De esta manera, los compromisos de seguridad derivados de una aplicación no afectarán a las aplicaciones en otros grupos y así incluimos el plano de seguridad entre los niveles de aislamiento proporcionados por los grupos de aplicaciones.
    • No instalar componentes que no sean necesarios:
      • Si no se va a emplear el servicio SMTP, o FTP, no instalarlo. No sólo consume recursos, sino que abrimos opciones a posibles vulnerabilidades.
    • Proteger cmd.exe:
      • No emplear cuentas de usuario que tengan permiso de ejecución sobre el intérprete de comandos para aplicaciones web.
    • Mantener el mínimo de permisos web necesarios.
    • Desvincular las extensiones ISAPI que no se utilicen:
      • Como por ejemplo .idc o las de server-side includes.
    • Ocultar el uso de scripts:
      • Si, por ejemplo, asociamos la extensión htm al motor de scripts asp.dll, podríamos incluir código ASP en archivos con extensión htm, que sería procesado igualmente.
    • Gestión adecuada de las cuentas de usuario:
      • Emplear contraseñas fuertes.
      • Bloquear tras un número de intentos fallidos de validación.
      • Cambiar periódicamente.

     

Fichero pdf para descargar aquí.
vidalmb_admin – Mar, 22/08/2006 – 13:13

13. Seguridad en IIS 6 - SSL

1.1 Introducción

La enorme ventaja que supone Internet en cuanto a difusión y acceso a la información puede convertirse en inconveniente cuando manejamos información sensible que requiere de ciertas garantías de seguridad.

Algunos conceptos fundamentales a este respecto son:

    • Confidencialidad: asegurarnos de sólo el destinatario va a tener acceso a la información.
    • Autenticidad: garantizar la procedencia de la información.
    • Integridad: la información no ha sido manipulada durante su tránsito.

 

1.2 Claves y cifrados

Los certificados emplean un sistema de claves para encriptar la información.

  • Una clave es una secuencia de datos empleada en el proceso de cifrado.
  • Un mecanismo de cifrado es un algoritmo matemático que, empleando claves, es capaz de encriptar y desencriptar información.

 

1.3 Cifrado con claves simétricas

  • Se emplea la misma clave para encriptar y desencriptar la información
  • Es un mecanismo eficiente, ya que se considera segura una clave de 128 bits.
  • proporciona un cierto nivel de seguridad, ya que el destinatario debe conocer la clave, pero si ésta se ve comprometida, cualquiera puede encriptar datos (y por lo tanto suplantar al emisor de la información) y desencriptarlos.

 

1.4 Cifrado con claves asimétricas

  • Se emplean 2 claves: una pública que se distribuye libremente y otra privada, de tal manera que lo que se cifra con una de ellas sólo se puede descifrar con la otra. De esta manera un servidor utiliza su clave privada para encriptar la información y el cliente utiliza la clave pública para desencriptarla y comprobar al mismo tiempo la autenticidad de la procedencia del mensaje.
  • Es un mecanismo menos eficiente: hoy en día se considera segura una clave de 1024 bits.
  • Los algoritmos de cifrado de este tipo que emplea IIS son DH (por Diffie-Hellman) y RSA (por Rivest, Shamir y Adleman). Éste último es el más popular.

Nota: Este tipo de cifrado con clave pública está cada vez más extendido y se emplea en los esquemas de seguridad corporativos, apareciendo así el concepto de PKI: Public Key Infraestructure.

 

1.5 Hash

Una función Hash nos permite obtener un resumen a partir de un mensaje.

Dicho resumen:

    • es mucho más pequeño que el mensaje original (entre 128 y 160 bits).
    • no permite la reconstrucción del mensaje original a partir de él
    • y cualquier mínima variación en el mensaje original genera un hash distinto.

 

1.6 Firmas digitales

La finalidad de la firma digital es la de poder garantizar la autoría y la integridad de los datos firmados, y puede expresarse como producto de la combinación de 2 de las técnicas que acabamos de describir. Si a una cierta información:

      1. Le aplicamos una función hash.
      2. Ciframos dicho resumen o hash con nuestra clave privada.

y enviamos en un mensaje la información junto con el hash encriptado (nuestra firma), obtenemos un mensaje cuyo hash cualquiera, con nuestra clave pública, puede desencriptar –verificando así la autoría del mensaje- y con el hash comprobar la integridad de la información recibida.

 

1.7 Certificados y CAs

Un certificado es esencialmente una clave pública y un identificador, firmados digitalmente por una autoridad certificadora (CA: Certificate Authority), y su utilidad es demostrar que una clave pública pertenece a un usuario concreto.

El formato de certificado X.509 es el más común y extendido en la actualidad.

Estos certificados se estructuran de forma jerárquica, de tal forma que nosotros podemos verificar la autenticidad de un certificado comprobando la firma de la autoridad que lo emitió, que a su vez tendrá otro certificado expedido por otra autoridad de rango superior. De esta forma vamos subiendo en la jerarquía hasta llegar al nivel mas alto, a la llamada entidad emisora de certificados raíz , que deberá estar ocupado por un certificado que goce de la confianza de toda la comunidad.

 

1.8 Tipos de certificados

IIS 6 emplea certificados digitales para proporcionar la seguridad necesaria a través del protocolo SSL (Secure Socket Layer).

Algunos de los tipos más comunes de certificados digitales empleados en Internet son:

    • Certificados de servidor: proporcionan mecanismos de encriptación para la transmisión de información y autentican al servidor.
    • Certificados personales: empleados para identificar a los usuarios, por ejemplo desde un navegador web, en un correo electrónico o mediante una tarjeta digital.
    • Certificados para firma de código: empleados para firmar digitalmente el software y verificar la autenticidad de su origen.
    • Certificados de entidades emisoras: son los que identifican a las propias compañías emisoras de certificados.

 

1.9 Entidades emisoras de certificados

Algunas entidades emisoras de certificados comerciales que cobran por emitir certificados y ofrecen a cambio responder de la veracidad de nuestra clave pública son:

    • Verisign
    • GeoTrust
    • GlobalSign
    • Thawte
    • IT Institute

 

2.1 Instalar una entidad emisora de certificados.

Dentro de los componentes de Windows 2003, encontramos Servicios de Certificate Server, que nos permiten emitir certificados.

Podemos instalar una CA de 2 tipos:

    1. De empresa: requiere directorio activo y está orientada a proporcionar certificados para su uso en intranets, ya que propaga su certificado al almacén de certificados Entidad emisora de certificados raíz de confianza para todos los usuarios y equipos que integran el dominio.
    2. Independiente: no requiere directorio activo y se suele emplear para emitir certificados para su uso en Internet.

Dentro de cada uno de estos tipos, una entidad emisora puede ser:

    • Raíz: en la estructura jerárquica de emisores de certificados que forman parte de una misma entidad, es el elemento único superior, y el único que se certifica a sí mismo. Normalmente, sólo se emplea para emitir certificados para CAs subordinadas.
    • Subordinada: la que ha recibido un certificado de otra CA de la organización. Puede emitir certificados para usos específicos (de servidor, de cliente,…) y para otras CAs subordinadas.

 

2.2 Proceso de emisión de un certificado

Cómo se emite un certificado

  1. Generación de la clave: Quien solicita la certificación (el solicitante, no la entidad emisora) genera pares de claves públicas y privadas.
  2. Coincidencia de información de directivas: El solicitante empaqueta la información adicional necesaria para que la entidad emisora emita el certificado (como prueba de identidad, número de identificación fiscal, dirección de correo electrónico, etc.). La definición precisa de esta información es responsabilidad de la Entidad emisora de certificados.
  3. Enviar las claves públicas y la información: El solicitante envía las claves públicas y la información (a menudo, se cifra con la clave pública de la entidad emisora) a la Entidad emisora de certificados.
  4. Comprobación de la información: La Entidad emisora de certificados aplica las reglas de directivas que necesite para comprobar que el solicitante debe recibir un certificado.
  5. Creación del certificado: La Entidad emisora de certificados crea un documento digital que contiene la información apropiada (clave pública, fecha de caducidad y otros datos) y lo firma con la clave privada de la entidad emisora.
  6. Enviar y publicar el certificado: La Entidad emisora de certificados puede enviar el certificado al solicitante o publicarlo si resulta más apropiado.
  7. El certificado se carga en el equipo de una persona.

 

2.3 Solicitar un certificado para un sitio web (I): generación de la solicitud.

  • Desde el Administrador de IIS, accedemos a las propiedades del sitio web.
  • En Seguridad de directorios, pulsamos Certificado de servidor…
  • Seleccionamos Crear un certificado nuevo
  • Elegimos Preparar la petición ahora, pero enviarla más tarde (la opción de Enviar la solicitud inmediatamente… sólo está disponible para entidades emisoras de certificados de empresa, y requiere directorio activo).
  • Elegimos un nombre y una longitud en bits para la clave.
  • Introducimos información de la organización.
  • Introducimos el nombre del sitio web (importante que coincida exactamente).
  • Introducimos información geográfica.
  • Seleccionamos dónde se guardará la petición como archivo de texto.

 

2.4 Solicitar un certificado para un sitio web (II): envío a la entidad emisora.

  • Enviamos nuestra solicitud, los datos y la documentación que se requiera (según la entidad emisora) a la entidad emisora de certificados.
    • En el caso de Windows 2003 actuando como entidad emisora de certificados, nos conectamos a http://nombre_del_servidor/CertSrv y tramitamos la solicitud, siguiendo las instrucciones.
    • Como CA, desde Herramientas administrativas > Entidad emisora de certificados gestionamos las solicitudes pendientes, pudiendo emitir o denegar cada petición recibida.
  • Seguimos los trámites necesarios y obtenemos nuestro certificado.

 

2.5 Solicitar un certificado para un sitio web (III): instalación del certificado.

Una vez obtenido el certificado de la entidad emisora:

  1. Accedemos a las propiedades del sitio web > Seguridad de directorios > Certificado de servidor…
  2. Seleccionamos Procesar la petición pendiente e instalar el certificado.
  3. Seleccionamos el archivo correspondiente al certificado emitido.
  4. Indicamos el puerto SSL asociado, teniendo en cuenta que este valor, al contrario que ocurría con el puerto TCP, no puede ir asociado a un encabezado de host, luego debe ser único en el servidor.
  5. Debemos instalar en nuestro servidor –si no existían ya- los certificados de la cadena de entidades emisoras que han intervenido en la emisión de nuestro certificado.

 

2.6 Encriptación mediante SSL

  • IIS 6, a través de SSL, nos proporciona mecanismos para acceder de forma segura a sitios web.
  • Obteniendo un certificado, podremos emplear nuestro sistema de clave pública-clave privada para encriptar la información y garantizar una comunicación segura.
  • Dado que la encriptación con clave simétrica es mucho más eficiente, con SSL:
    • se emplea el cifrado con clave asimétrica en la fase inicial de la conexión entre el cliente y el servidor (handshaking).
    • se genera entre ambos una clave simétrica confidencial (más pequeña e igualmente eficaz, y con menor penalización en el rendimiento) que emplearán en el resto de la sesión.

 

2.7 Caducidad de certificados

  • Tiempo de vida de claves
    • Una clave nunca debería usarse por tiempo indefinido. Debe tener una fecha de caducidad, por las siguientes razones:
    • Cuanto más tiempo se usa una clave, aumenta la probabilidad de que se comprometa (la pérdida de una clave por medios no criptoanalíticos se denomina compromiso).
    • Cuanto más tiempo se usa una clave, mayor será el daño si la clave se compromete, ya que toda la información protegida con esa clave queda al descubierto.
    • Cuanto más tiempo se usa una clave, mayor será la tentación de alguien para intentar desbaratarla.
    • En general es más fácil realizar criptoanálisis con mucho texto cifrado con la misma clave.
  • Por este motivo, los certificados emitidos rara vez suelen superar los 5 años de validez, y en la mayoría de los casos se emiten por un período de 1 a 3 años.

 

2.8 Exportación de certificados

  • Para exportar un certificado de servidor:
    • Desde las propiedades del sitio web en el que está el certificado, elegimos Seguridad de directorios > Certificado de servidor… y seleccionamos Exportar el certificado actual a un archivo .pfx.
    • Es preciso tener en cuenta que en este archivo se encuentran tanto el certificado como la clave privada, por lo que hay que tomar las medidas de seguridad pertinentes.
  • Para exportar un certificado personal:
    • Primeramente, un certificado personal será exportable sólo si se solicitó que lo fuese en el momento de su creación. Para ello, es preciso elegir en IIS 6 la solicitud avanzada de certificado y activar la casilla Marcar claves como exportables.
    • Ejecutando mmc, añadimos el complemento Certificados con la opción de usuario actual, y en la categoría Personal, seleccionamos Todas las tareas > Exportar… sobre el certificado.

 

3. Revocación de certificados

  • Una entidad emisora de certificados (C.A.) puede tener que revocar un certificado emitido, de manera que no sea válido a partir de ese momento.
  • Por esta razón, las CAs publican periódicamente CRLs (Certificate Revocation List) en las que anuncian los certificados que han sido revocados.
  • En el caso de IIS, para publicar las CRLs se emplea el directorio http://nombre_del_servidor/CertEnroll, creado en el Sitio Web Predeterminado al instalar los Servicios de Certificate Server.
    • IIS permite publicar CRLs completas e incrementales.
    • Estas opciones se configuran en Herramientas administrativas > Entidad emisora de certificados > Certificados revocados > Propiedades
    • Se puede publicar manualmente la lista en Certificados revocados > Todas las tareas > Publicar

 

Fichero pdf para descargar aquí.

vidalmb_admin – Mar, 22/08/2006 – 13:11

12. Monitorización y optimización de IIS 6

1. Introducción

La optimización de la configuración de nuestro servidor puede ser un factor decisivo en la consecución de un buen rendimiento del sistema.

Teniendo en cuenta que muchos usuarios no están dispuestos a esperar más que unos segundos a que se les muestre una página web, o que un error HTTP puede minar la confianza en un sitio web dedicado al comercio electrónico, un buen tiempo de respuesta y un alto grado de fiabilidad son factores tan importantes como el propio desarrollo de los contenidos de un servidor.

La monitorización de distintos parámetros del sistema y el estudio de la respuesta del servidor ante situaciones de estrés nos permitirán analizar la configuración vigente y los aspectos en los que pueda mejorarse.

 

2.1 Modo de aislamiento

  • El modo de aislamiento en el que se ejecuta IIS es clave, tanto desde el punto de vista de la programación de páginas dinámicas, como de la configuración del servidor.
    • Modo aislado de IIS 5: el modo de aislamiento alto (high) de aplicaciones incurre en una considerable penalización en el rendimiento debido a los costosos mecanismos RPC para la comunicación entre procesos.
    • Modo de aislamiento de procesos de trabajo: A la mejora arquitectural que suponen los grupos de aplicaciones y los procesos de trabajo se unen sus características de reciclaje, tiempo de espera de inactividad, limitación de uso de CPU, web gardens, monitorización de estado, protección contra errores rápidos, o tiempos límite de inicio y finalización, que nos brindan multitud de parámetros y opciones con los que ajustar al máximo el rendimiento y la fiabilidad de nuestro servidor.
  • En cualquiera de los dos casos, podemos beneficiarnos de características como limitación del número de conexiones y del ancho de banda, tiempos de espera, compresión HTTP o conexiones HTTP abiertas.

 

2.2 Reciclaje de los procesos de trabajo

  • En la configuración de los grupos de aplicaciones se especifican las normas de reciclaje de los procesos de trabajo según criterios de:
    • Tiempo transcurrido
    • Solicitudes atendidas
    • Hora del día
    • Memoria utilizada
  • El reciclaje puede ocurrir además con o sin solapamiento: por defecto, IIS generará los procesos de trabajo de reemplazo antes de que desaparezcan los existentes para que no se produzca pérdida interna de servicio; pero puede no ser así, por ejemplo debido a ausencia de recursos de memoria o CPU, o a que un proceso de trabajo se ha quedado bloqueado.
    • Si programamos el reciclaje a una hora concreta (por ejemplo durante una ventana de mantenimiento), debemos tener en cuenta el consumo de recursos que supone. En el caso de un web garden con múltiples procesos de trabajo, puede ser mejor opción seguir un criterio de número de solicitudes atendidas.
    • Si tenemos aplicaciones con fallos que producen bloqueos con el tiempo, se pueden establecer puntos temporales de reciclaje a lo largo del día.
    • En el caso de aplicaciones con pérdidas de memoria, el mejor criterio puede ser el de memoria empleada por el proceso de trabajo.

No existiendo un criterio único universal, la configuración óptima dependerá de nuestra situación y de las aplicaciones que estamos gestionando.

 

2.4 Tiempo de espera de inactividad

  • Ajustar el tiempo de espera de inactividad puede ayudar a liberar recursos que no están siendo utilizados, por ejemplo si hemos optado por una distribución de aplicaciones en muchos grupos de aplicaciones, cada grupo tiene asignado al menos 1 proceso de trabajo.
  • Podemos rebajar el tiempo predeterminado de 20 minutos, por ejemplo en grupos de aplicaciones con peticiones poco frecuentes.
  • En cualquier caso, debemos procurar que este parámetro no sea inferior al tiempo de espera de inactividad de las propias aplicaciones (ASP, PHP o ASP.net), ya que de lo contrario pueden producirse pérdidas de datos y servicios.

 

2.5 Límite de la cola de peticiones

  • La cola de peticiones (que nutre HTTP.sys) de un grupo de aplicaciones, tiene una capacidad predeterminada de 1000 peticiones.
  • Si la cola está llena, el servidor contestará a las peticiones entrantes con un mensaje de HTTP 503—Servicio no disponible.
  • En una cola con excesiva capacidad, se acumularán las peticiones, dando a los usuarios sensación de lentitud en el servicio. Si no podemos permitirnos asignar más procesos de trabajo al grupo de aplicaciones, puede ser preferible un mensaje de Servicio no disponible para que el usuario intente acceder posteriormente.

 

2.6 Monitor de estado

  • El Web Administration Service puede controlar la “salud” de los procesos de trabajo haciéndoles un ping a intervalos regulares de tiempo.
  • Si el proceso de trabajo no contesta, IIS puede realizar dos acciones:
    • Reciclar el proceso, terminándolo y sustituyéndolo por otro.
    • Aislarlo, manteniéndolo en memoria, pero sin atender peticiones (crea un proceso huérfano), y generar otro proceso de trabajo para sustituirlo. Para esto, es necesario configurar algunos parámetros de la Metabase:
      • OrphanWorkerProcess: debe tomar el valor TRUE (es false de forma predeterminada).
      • OrphanActionExe: indica el ejecutable que se lanzará cuando se cree un proceso huérfano.
      • OrphanActionParams: permite pasar parámetros al ejecutable indicado por OrphanActionExe.

Estos parámetros se pueden configurar tanto a nivel de todos los grupos de aplicaciones (/LM/W3SVC/AppPools) como dentro de cada grupo de aplicaciones particular (/LM/W3SVC/AppPools/nombre_del_grupo_de_aplicaciones).

  • Hay que tener en cuenta que los procesos huérfanos pueden acumularse y consumir recursos de memoria, luego no conviene habilitar esta opción a menos que realmente se vaya a hacer un seguimiento de estos procesos y a liberar los recursos que emplean una vez se hayan analizado.
  • Una manera de conseguir esto es utilizando las Debugging Tools, disponibles en el sitio web de Microsoft. Instalando estas herramientas en nuestro sistema, dispondremos de un mecanismo para volcar al disco duro la memoria de un proceso huérfano para su posterior estudio, y eliminar el proceso. Suponiendo que hemos instalado las Debugging Tools en C:\debuggers, crearíamos en ese directorio el archivo huerfano.cmd, con el siguiente contenido:

@if "%_echo%"=="" echo off

setlocal

set WORKINGDIR=c:\debuggers

set FILENAME=%WORKINGDIR%\crash.dmp

set LOG=%WORKINGDIR%\log.txt

set COMMAND=c:\debuggers\cdb.exe -c ".dump /o /mhf /u %FILENAME%;q" -p %1

echo %COMMAND% > %LOG%

%COMMAND%

Endlocal

  • Después, asignamos los siguientes valores a los parámetros de la Metabase:
    • OrphanWorkerProcess=“TRUE”
    • OrphanActionExe=“C:\Debuggers\huerfano.cmd”
    • OrphanActionParams=“%%1%%”
  • De esta manera, cada vez que –en los grupos de aplicaciones configurados- surja un proceso de trabajo huérfano, volcaremos a disco la memoria del proceso y lo terminaremos.

 

2.9 Características de Calidad de Servicio (QoS)

  • Mantenimiento de conexiones HTTP abiertas.
  • Compresión HTTP.
  • Límite de conexiones simultáneas.
  • Tiempo de espera de la conexión.
  • Límite de ancho de banda.

 

2.10 Parámetros del Registro de Windows

  • En diversas ramas del Registro de Windows se pueden configurar múltiples valores de parámetros que afectan al rendimiento de IIS 6 relacionados con varios aspectos como gestión de cachés, registros y conexiones.

Nota: ver archivo complementario IIS 6 - Global Registry entries.pdf

 

2.11 Otros parámetros del servidor

  • Memoria RAM: por lo general, la ampliación más rentable en cuanto a componentes físicos del servidor, es la memoria RAM.
  • Maximizar el rendimiento para aplicaciones de red: por defecto, Windows 2003 se instala favoreciendo el rendimiento para compartir archivos. Podemos cambiar este parámetro en Propiedades de la Conexión de red > Propiedades de Compartir impresoras y archivos para redes Microsoft.
  • Desfragmentación de discos: es conveniente desfragmentar periódicamente los discos duros del servidor para optimizar el rendimiento del subsistema de archivos.
  • Archivo de paginación: establecer desde el principio un tamaño fijo suficiente para el archivo de paginación, de manera que se cree contiguo y no se fragmente con cada ampliación automática.
  • Evitar aplicaciones CGI: utilizar extensiones ISAPI de servidor para no incurrir en la penalización de ejecución intrínseca al esquema de las aplicaciones CGI.
  • Evitar el uso de FTP aislado: en el caso de tener muchos (cientos) de usuarios, gestionar todos los directorios asociados a las cuentas supone una carga considerable para el servidor. Si esta configuración es necesaria, dedicar si es posible un servidor en exclusiva a esta tarea.
  • No abusar de los registros: el registro de actividad de un servidor con cientos o miles de sitios web puede ocupar un espacio en disco y generar un volumen de actividad considerables. Si es preciso, habilitar el formato binario de los archivos de registro asignando al parámetro CentralBinaryLoggingEnabled de la Metabase el valor True.

Los archivos de registro se generarán entonces en binario con la extensión *.ibl (Internet Binary Log) y en un solo archivo se registrará toda la actividad del servidor. Esto también puede ser útil en el caso de un servidor que hospede multitud de sitios web a la hora de generar informes estadísticos de actividad, ya que se concentra toda la información en un punto en lugar de en cientos o miles de archivos.

  • Evitar el registro remoto: aunque la posibilidad de que los archivos de registro se almacenen en una unidad de red ofrece la ventaja de un repositorio de registro unificado, si la conexión del servidor con el punto remoto de almacenamiento no es buena puede resentirse el rendimiento. Además, la información viaja a priori sin encriptar, lo cual puede ser no deseable, y aunque pueda encriptarse el tráfico con IPSec, la encriptación siempre es una tarea que demanda CPU.
  • Deshabilitar la indexación: en aquellos sitios web en los que no se empleen páginas de búsqueda en el contenido, es conveniente deshabilitar la indexación para liberar la CPU de una tarea no productiva.

 

3.1 Herramientas de monitorización

  • La herramienta que proporciona Windows 2003 para monitorizar el sistema se ejecuta desde Inicio > Herramientas administrativas > Rendimiento.
  • Está formado por:
    • Monitor de sistema: muestra gráficamente información de múltiples parámetros del sistema.
    • Registros y alertas de rendimiento: permite registrar la información monitorizada en archivos para su posterior análisis y la definición de mecanismos ante situaciones de alerta según los valores alcanzados por determinados parámetros.
  • Otras herramientas que podemos emplear son:
    • Administrador de tareas: nos permite ver las aplicaciones en ejecución, los procesos cargados en memoria y los recursos que consumen y diversos datos de rendimiento y nivel de saturación del sistema.
    • Monitor de red: mayormente empleado para monitorizar conexiones y servicios de red y para generar estadísticas de uso de la red.
    • Microsoft Web Application Stress Tool (WAST): una herramienta para someter a un servidor a pruebas de rendimiento simulando peticiones de clientes en un entorno controlado.

 

3.2 Monitorizar el rendimiento

  • Analizar el servidor ante cargas de trabajo controladas nos permitirá descubrir los cuellos de botella en nuestro esquema, que son limitaciones en la configuración que afectan al rendimiento.
  • Estas limitaciones pueden darse tanto en la parte hardware (CPU, memoria, conexión de red, velocidad del subsistema de almacenamiento) como en el software (aplicaciones, bases de datos…).
  • Las acciones que se deban emprender pueden actuar directamente sobre la parte cuello de botella (añadir más CPUs o memoria RAM, revisar el código de las aplicaciones o emplear sistemas gestores de bases de datos más rápidos), o bien ajustando la configuración de IIS.

 

3.4 Proceso de optimización

  • Es importante modificar un parámetro cada vez y analizar las consecuencias de dicha modificación.
  • Muchas veces, deshacer un cuello de botella nos revela otro: traslada el problema a otra parte, aunque se trata de ir mejorando el rendimiento en cada paso.
  • Una vez monitorizado y optimizado el servidor en un entorno controlado, se debe seguir el proceso en el entorno de producción: esto nos permitirá tener en perspectiva las posibles exigencias de nuestro servidor de cara a mantener el rendimiento conforme vayan aumentando las peticiones.

 

4.1 Contadores

  • Cuando se monitorice el sistema, siempre deben incluirse contadores de las 4 áreas principales:
    • Memoria
    • Procesador
    • Disco
    • Red

 

4.2 Memoria

  • MBytes disponibles (available Mbytes): debe estar por encima de 20.
  • Bytes de caché (Cache bytes): si empieza a disminuir, IIS puede estar quedándose sin memoria.
  • Bytes comprometidos (committed bytes): son los bytes asignados en la memoria virtual. Se deben mantener por debajo del 75% de la memoria virtual.
  • Páginas/s (Pages/sec): errores de página que provocan lecturas o escrituras de página en disco. Es un indicador primario del tipo de errores que causan retraso en todo el sistema. Debe mantenerse por debajo de 20. Si toma un valor elevado (>= 80) debe añadirse más memoria RAM.
  • Bytes de bloque no paginado (Pool nonpaged bytes): tamaño del área la memoria del sistema (memoria física usada por el sistema operativo) para objetos que no se pueden escribir en el disco, pero deben permanecer en la memoria física tanto tiempo como estén asignados. Un aumento paulatino a lo largo del tiempo puede indicar una “fuga” de memoria debida a programación defectuosa.

 

4.3 Procesador

  • % de tiempo de procesador (% Processor Time): si se mantiene habitualmente elevado –por encima del 80%-, pero los indicadores de red y de disco son bajos, puede indicar un cuello de botella en el procesador.

 

4.4 Disco

  • % Tiempo de disco (% Disk time): mantener tan bajo como sea posible. Un valor elevado indica que se debe optimizar la utilización del disco (particionamiento adecuado, desfragmentación…) o adquirir unidades de disco más rápidas.
  • Media de bytes/transferencia (Avg. Disk Bytes/Transfer): debe mantenerse lo más alto posible.
  • Long. media de la cola de disco (Avg. Disk Queue Length): debería ser <= 4.

 

4.5 Interfaz de red

  • Total de bytes/s (Bytes Total/sec): comparar con el ancho de banda de la conexión de la tarjeta de red para averiguar si se está produciendo un cuello de botella en este subsistema.

 

4.6 Otros contadores

  • Sistema:
    • Longitud de la cola del procesador (Processor Queue Length): si de forma permanente muestra un valor >= 2, puede ser síntoma de un cuello de botella en el procesador.
  • Archivo de paginación:
    • % Uso (% Usage): el tamaño del archivo de paginación debe ser suficiente (de 1,5 a 2 veces el tamaño total de la memoria RAM del sistema). Si este porcentaje es elevado continuamente, el sistema necesita más memoria RAM.
  • Servicio Web:
    • Total de bytes/s. (Bytes Total/Sec): debería ser lo más alto posible.
  • Memoria caché del servicio Web:
    • Porcentaje de aciertos en la memoria caché de archivos (File Cache %): muestra la frecuencia con que IIS encuentra archivos en la caché. Si es un valor bajo, se puede considerar rediseñar las aplicaciones buscando mejorar este aspecto.
    • Aciertos de la memoria caché de archivos (File Cache Hits): debe ser lo más alto posible si se tiene mucho contenido estático, pero puede ser bajo si el valor de Núcleo: aciertos de caché de URI % (Kernel: URI Cache Hits %) es elevado.
  • Páginas Active Server:
    • Tiempo de espera de petición (Request Wait Time): tiempo en milisegundos de esperade la petición más reciente en la cola. Debe ser bajo.
    • Nº de peticiones en la cola (Requests Queued): debe mantenerse bajo. Tener en cuenta el límite de la cola del grupo de aplicaciones correspondiente.

Nº de peticiones/s (Requests/Sec): si se aprecia un descenso de este parámetro en situaciones de alta demanda, puede haber un cuello de botella en la aplicación.

 

Fichero pdf para descargar aquí.

vidalmb_admin – Lun, 21/08/2006 – 12:03

11. Administración remota de IIS 6

1. Introducción

El concepto de administración remota surge ante la necesidad de tener los servidores en lugares físicamente seguros, aislados y protegidos, y de que un mismo administrador pueda gestionar distintos servidores ubicados en lugares distantes.

Veremos a continuación algunas maneras de gestionar un servidor IIS de forma remota.

 

2.1 Microsoft Management Console (MMC)

  • Desde la consola de administración de IIS
    • Inicio > Herramientas administrativas > Administrador de Internet Information Services
    • Inicio > Ejecutar > inetmgr

Se puede elegir entre una de ambas formas de acceder a la consola de administración.

También podemos conectarnos con Acción > conectar… a otros servidores y administrarlos.

Nota: esta técnica es válida para otras instancias de MMC, como en la Administración de equipos. El problema que podemos tener al administrar otros servidores Windows 2003 es no tener instalado el componente necesario de la MMC (por ejemplo si deseamos administrar un servidor IIS desde un servidor que no lo tiene instalado).

Para solventar este inconveniente, podemos instalar el Administration Tools Pack: en el CD de instalación de Windows 2003, buscamos el archivo i386\adminpak.msi,hacemos clic con el botón derecho del ratón y seleccionamos Instalar…

De este modo instalamos todos los componentes de administración de la MMC, incluso los de los servicios que no estén instalados en nuestro servidor.

 

2.2 Escritorio Remoto

  • Podemos lanzar el cliente de conexión al escritorio remoto de dos maneras:
    • Inicio > Programas > Accesorios > Comunicaciones > Conexión a Escritorio remoto
    • Inicio > Ejecutar > mstsc

Desde el cliente podemos configurar distintas opciones de visualización, ejecución y rendimiento y acceder a todas las funcionalidades del servidor, exactamente como si nos encontrásemos ante la consola.

El cliente de escritorio remoto se conecta a los servicios de Terminal Server en el puerto TCP 3389.

Nota: para poder establecer una conexión de Escritorio remoto con un servidor, debe marcarse la casilla Permitir a los usuarios conectarse remotamente a este equipo en Mi PC > propiedades > Acceso remoto. Esta opción está deshabilitada por defecto.

 

2.3 Escritorio Remoto vía web

  • Existe un componente de Windows 2003 –un subcomponente del servicio World Wide Web llamado Conexión Web a Escritorio remoto- que nos permite establecer conexiones de escritorio remoto mediante un control ActiveX instalado en Internet Explorer 5 o superior.

Una vez instalado este control ActiveX, utilizando el sitio web en un mismo servidor Windows 2003 podemos establecer conexiones de Escritorio remoto a cualquier equipo.

La url de acceso es: http://nombre_del_servidor/tsweb

 

2.4 Sitio web de Administración

  • Si hemos instalado el subcomponente del Servicio World Wide Web Administración remota (HTML), podremos acceder al sitio web de administración del servidor con Internet Explorer a través de la url:

https://nombre_del_servidor:8098

  • Este sitio web aparece como Administration en la consola de administración de IIS, y por defecto sólo podemos conectarnos con SSL a través del puerto 8098.
  • Las tareas de administración que podemos realizar son múltiples y no se restringen a IIS, sino que abarcan el servidor completo: cambiar el nombre del servidor, gestionar usuarios y contraseñas y apagar o reiniciar el servidor son algunos ejemplos.

Desde este sitio web también podemos establecer una conexión de Escritorio remoto.

 

Fichero pdf para descargar aquí.

vidalmb_admin – Lun, 21/08/2006 – 11:42
Syndicate content