Sri - Tema 4 HTTP Rev 1.16

Tema 4.
Servidores Web (HTTP)
Tema 4. Servidores Web. HTTP.

1. Caractersticas. ...................................................................................... 3
2. Componentes. ........................................................................................ 4
3. Nombres y direcciones. ......................................................................... 4
4. Clientes web (navegadores o exploradores). ........................................ 4
5. Servidores web. ..................................................................................... 5
6. Proxies web. .......................................................................................... 6
7. Protocolo HTTP. ................................................................................... 6
7.1. Mensajes HTTP. ............................................................................................... 7
7.2. Mtodos de peticin. ......................................................................................... 7
7.3. Cabeceras. ......................................................................................................... 8
7.4. Cdigos de estado y error. ................................................................................ 9
7.5. Autentificacin y Seguridad. ............................................................................ 9
8. Protocolo seguros. ............................................................................... 10

8.1. Gestin de certificados en Windows 2003 Server. ......................................... 11
8.2. Gestin de certificados en Linux. ................................................................... 12
9. Alojamiento virtual. ............................................................................ 13

10. Instalacin y configuracin IIS en Windows. ................................... 13
10.1. Instalacin de IIS. ......................................................................................... 13
10.2. Servidor virtual por defecto. ......................................................................... 13
10.3. Configuracin de servidores virtuales. ......................................................... 14
10.3.1. Servidores virtuales por nombre. ..................................................................................... 15
10.4. Directorios virtuales. ..................................................................................... 15

10.5. Servidores virtuales seguros. ........................................................................ 15
11. Instalacin y configuracin de Apache en Linux. ............................ 17

11.1. Instalacin de Apache. .................................................................................. 17
11.2. Servidor virtual por defecto. ......................................................................... 19
11.3. Directivas. ..................................................................................................... 19
11.3.1. DirectoryIndex. ............................................................................................................... 20
11.3.2. Directory y Options Indexes. ........................................................................................... 20
11.3.3. Logs. ................................................................................................................................ 20
11.3.4. Codigos de error. ............................................................................................................. 21
11.4. Directorios virtuales. ..................................................................................... 21
IES Zaidn Vergeles de Granada. Departamento de Informtica.
Tema 4. Servidores Web (Web)
11.5. Configuracin modular. ................................................................................. 22

11.5.1. Mdulo userdir. .............................................................................................................. 22
11.6. Control de acceso por direcciones IP y nombres de dominio........................ 23

11.7. Configuracin de servidores virtuales. .......................................................... 23
11.7.1. Servidores virtuales por nombre. .................................................................................... 23
11.7.2. Servidores virtuales por direccin IP. ............................................................................. 24
11.7.3. Servidores virtuales por puerto. ...................................................................................... 25
11.8. Configuracin de un servidor virtual seguro (https). ..................................... 26

11.8.1. Servidor virtual HTTPS por defecto. .............................................................................. 26
11.8.2. Servidores virtuales HTTPS. ........................................................................................... 26
Tema 4. Servidores Web (HTTP)
Tema 4. Servidores Web (HTTP).

HTTP (Hyper Text Transfer Protocol) es un protocolo de la capa de aplicacin que permite el acceso
a la informacin de hipertexto (HyperText Markup Language) ubicada en servidores usando el modelo
cliente/servidor en una red TCP/IP.
1. Caractersticas.
La llamada Web o WWW (World Wide Web) es un servicio que permite el acceso y distribucin de
informacin (texto, imgenes, audio, video, etc.), las llamadas pginas web, que se encuentran en
servidores disponibles en Internet. Todos estos recursos, identificados por medio de un URL, se conectan
entre s mediante hiperenlaces. Los clientes web (navegadores o exploradores) realizan la conexin a los
sitios web y presentan los recursos solicitados.
Estos contenidos bsicamente pueden ser estticos o dinmicos.
En las llamadas pginas estticas los contenidos simplemente se muestran y la nica interaccin que
se permite por parte de los usuarios es el acceso a otras pginas mediante los hiperenlaces o el relleno de
formularios cuyos datos se envan posteriormente a un servidor.
Las pginas dinmicas son programadas permitiendo a los usuarios interaccionar con ellas
modificando los contenidos a mostrar, as como las respuestas que el servidor enva a los clientes.
Algunas de las tecnologas usadas por las pginas dinmicas son:
PHP (PHP Hypertext Pre-processor). Es un lenguaje de programacin de script que se ejecuta en el

servidor web. Cuando el cliente hace una peticin al servidor para que le enve una pgina web, el
servidor ejecuta el intrprete de PHP. ste procesa el script solicitado que generar el contenido
HTML de manera dinmica. El resultado es enviado por el intrprete de PHP al servidor, quien a su
vez se lo enva al cliente.
ASP (Active Server Page). Es una tecnologa de Microsoft del tipo en el lado del servidor para
pginas web generadas dinmicamente, que ha sido comercializada como un anexo a Internet
Information Services (IIS) usando como lenguajes Visual Basic o C#. Al igual que PHP el cdigo se
ejecuta en el servidor, el resultado HTML se enva al servidor web, el cual lo enva al cliente.
Servlets y applets de Java. Un servlet es un programa Java que se ejecuta en el servidor y que genera
pginas web como respuesta a las peticiones del cliente. Los applets son programas Java que se
descargan del servidor y que se ejecutan en el cliente como parte de la pgina solicitada.
JSP (Java Server Pages). Bsicamente el funcionamiento consiste en un servidor de aplicaciones que
interpreta el cdigo contenido en la pgina JSP para construir el cdigo Java del servlet a generar.
Este servlet ser el que genere el documento (tpicamente HTML) que se presentar en la pantalla
del navegador del usuario.
JavaScript. Es un lenguaje de programacin interpretado que se ejecuta normalmente en el cliente

(navegador) generando pginas dinmicas y una mejor presentacin.
CGI (Common Gateway Interfaz). Es una interfaz de programacin que permite la comunicacin
entre el servidor web y una aplicacin externa (escrita en C, C++, Java, etc.), llamada aplicacin
CGI. Con este sistema, el servidor web pasa las solicitudes del cliente al programa externo cuya
salida es enviada como tipo MIME al cliente, en lugar del archivo esttico tradicional.
AJAX (Asynchronous JavaScrpit And XML). Esta tecnologa permite crear aplicaciones que se
ejecutan en el cliente, mientras se mantiene la comunicacin asncrona con el servidor en segundo
plano. De esta forma es posible realizar cambios sobre las pginas sin necesidad de recargarlas, lo
que significa aumentar la interactividad y la velocidad en las aplicaciones.
2. Componentes.
El servicio web se basa en el modelo cliente-servidor y est formado por los siguientes componentes:
Recursos. Documentos, vdeos, imgenes, audio, aplicaciones, etc., accesibles a travs de
servidores web y conectados mediante hiperenlaces.
Nombres y direcciones (URIs y URLs). En la Web para identificar los recursos y acceder a ellos se
usan cadenas de caracteres que los identifican unvocamente denominados URIs (Uniform
Resource Identifier). Un URL identifica un recurso por su localizacin dentro del sistema.
Clientes web (exploradores o navegadores). Permiten acceder a los recursos disponibles en los
servidores web, estableciendo las conexiones e interpretando la informacin obtenida mostrndola
a los usuarios. Tambin se denominan agentes de usuario.
Servidores web. Atienden las peticiones de los clientes y les envan los recursos solicitados.
Proxies web. Programas que hacen de intermediarios entre los clientes y servidores web actuando
como cortafuegos y/o almacenando en cach los datos para aumentar el rendimiento.
Protocolo HTTP. Normas y reglas que permiten el dilogo entre clientes y servidores web usando
TCP como protocolo de transporte.
Tecnologas web. Utilidades para desarrollar aplicaciones basadas en la Web (HTML, XHTML,
XML, CSS, XSL, DOM, XPath, XQuery, JSON, etc.)
3. Nombres y direcciones.
Como hemos comentado, para localizar en la Web los recursos y acceder a ellos se usan cadenas de
caracteres que los identifican (URI). Un URL (Uniform Resource Locator) es un tipo de URI que
identifica el recurso y adems lo localiza.
El formato de una URL se compone de las siguientes partes:
Esquema o servicio: indica el protocolo que se usa para acceder al servicio. Puede ser: http, https,
ftp, mailto, ldap, file, gopher, telnet, news o data.
// separador.
Servidor: IP o nombre de dominio del servidor que contiene el recurso.
Puerto: nmero de puerto por el que escucha el servidor. Por defecto se usa el puerto 80/TCP.
Ruta del recurso: ruta relativa al directorio raz del servidor que contiene el recurso.
Recurso: el recurso a acceder. Si se omite se buscar un archivo ndice por defecto.
Parmetros y valores enviados al servidor.
Ejemplos:
http://www.pardillos.com/descargas/apuntes/tema1.pdf
https://203.45.121.5:8080/buscador.php?id=comic&personaje=filemon
Cuando un cliente indica una URL en el navegador, una vez resuelta la direccin IP del recurso
mediante DNS, se establece una conexin TCP con el puerto 80 del servidor (puerto por defecto), que
permanece a la escucha de las solicitudes HTTP. Realizada la conexin, el servidor enva el recurso
solicitado o un mensaje de error en forma de pgina web si no existe o no est disponible, mostrndose en
el navegador.
4. Clientes web (navegadores o exploradores).

Los clientes web son aplicaciones que ejecuta el usuario y que permite acceder a los recursos de un
servidor web introduciendo la URL del recurso. Aunque inicialmente se disearon como clientes HTTP,
permiten actuar como clientes de otros protocolos como por ejemplo FTP.
Muchos de ellos son multiplataforma, y la mayora de los sistemas operativos instalan por defecto
clientes web, aunque siempre podemos instalar y usar el que ms nos convenga.
Cada navegador permite establecer ciertos parmetros de configuracin relativos al aspecto,
comportamiento, registro de pginas visitadas, informacin almacenada temporalmente o seguridad.
Mediante la instalacin de complementos (plugins o add-ons) se permite ampliar la funcionalidad de

los navegadores y la interpretacin de recursos que no estn en formato HTML, como por ejemplo la
posibilidad de abrir documentos PDF, visualizar animaciones en Flash, vdeos, etc. Si el recurso que
recibe el navegador no lo puede interpretar, normalmente lo redirige a una aplicacin externa que s pueda
hacerlo, o pregunta qu se quiere hacer con l.
Aunque hay cientos de navegadores, la mayora de ellos usan alguno de los principales motores de
renderizado: Gecko (Mozilla, Firefox, K-Meleon, Camino, Flock, ), Webkit (Google Chrome,
Chromiun, Safari, Arora, ), Microsoft Internet Explorer, KHTML (Konqueror), Blink (Opera).
Tambin existen navegadores en modo texto como Lynx, Links, Bobcat o W3m.
5. Servidores web.
Los servidores web o servidores HTTP, son aplicaciones que atienden las peticiones HTTP (por
defecto en el puerto 80/TCP), procesan e interpretan cdigo que puede estar escrito en diferentes
lenguajes y envan a los clientes los recursos solicitados. Puede enviar contenido esttico (archivos en
general) o dinmico (como resultado de ejecutar programas).
Los recursos pueden estar localizados en el mismo equipo donde se ejecuta el servidor web o en otros
equipos de la red a los que el servidor puede acceder usando protocolos adicionales.
Los recursos se almacenan en los servidores en un directorio concreto denominado sitio web donde
se establece una jerarqua de directorios para organizar las pginas y elementos. Si la URL no especifica
ningn recurso, normalmente se accede a la llamada pgina inicial (normalmente index.html) situada en
el directorio raz de la jerarqua, usndose de ndice para el resto de recursos y elementos del sitio.
El contenido a transmitir debera ser tipo MIME (Multipurpose Internet Mail Extension). Los tipos
MIME son una forma abierta y extensible de representar el contenido de los datos. Como su nombre
indica fueron en un primer momento utilizados para extender las caractersticas del correo electrnico,
aunque su uso se ha generalizado. Actualmente define los formatos, tipos de letra y caractersticas de una
pgina para que sea visible por distintos navegadores. Los MIME se componen de un tipo y un subtipo.
Por ejemplo, un archivo que es un documento de texto y que ha sido escrito en HTML, tendr como tipo
MIME: text/html.
El registro de los tipos MIME los controla la IANA (Internet Asigned Numbers Authority), y en su
sitio Web podemos obtener la lista completa y actualizada de los tipos registrados. Es importante el
registro de tipos MIME, esto asegura que dos tipos de contenido distintos no acaban con el mismo
nombre.
Los tipos MIME se usan, por ejemplo para informar al navegador del tipo de datos que recibe,
permitir la negociacin de contenido o encapsular una o ms entidades dentro del cuerpo de mensaje,
mediante los tipos MIME multipart.
Es aconsejable indicar el tipo MIME cuando se crea una pgina, para que los servidores conozcan el
tipo del recurso a servir. Ejemplo:
<meta http-equiv="Content-Type" content="text/html" />
A la hora de gestionar los sitios web, la extensin al protocolo HTTP 1.1 WebDAV (Web-based
Distributed Authoring and Versioning) permite la elaboracin y administracin de sitios web de forma
colaborativa y remota. (Microsoft Office y otras aplicaciones incorporan soporte para WebDAV).
Los servidores web permiten mltiples configuraciones gracias a su arquitectura modular, lo que
permite ampliar o reducir funcionalidades de una forma sencilla. As, aparte del comportamiento bsico
del servidor, ste podr realizar ciertas tareas adicionales dependiendo de los mdulos que estn cargados.
Existen mltiples servidores web siendo los ms utilizados: Apache HTTP Server, IIS (Internet
information Sever), Nginx, Servidor Web de Google, Cherokee, Lighttpd.
En la pgina web www.netcraft.com se pueden obtener informaciones sobre anlisis y comparativas
web, estadsticas de uso de los diferentes servidores web y datos sobre cul es el servidor web que se
ejecuta en un sitio web.
6. Proxies web.
En general la funcionalidad de un proxy es la de permitir a otros equipos conectarse a una red de
forma indirecta a travs de l. As, cuando un equipo de la red desea acceder a una informacin o recurso,
es realmente el proxy quien realiza la comunicacin y a continuacin traslada el resultado al equipo
inicial. Las razones principales para usar un proxy como intermediario son porque a veces la
comunicacin directa no es posible, o bien porque el proxy aade una funcionalidad adicional.
En particular un proxy web aparte de la utilidad general de un proxy, proporciona una cach para las
pginas web y los contenidos descargados, que es compartida por todos los equipos de la red; con la
consiguiente mejora en los tiempos de acceso para consultas coincidentes. Al mismo tiempo libera la
carga de los enlaces hacia Internet.
Los proxies web tambin pueden filtrar el contenido de las pginas web servidas o controlar el acceso
de los usuarios actuando como cortafuegos. Otros tipos de proxy permiten cambiar el formato de las
pginas web para mostrarlas en dispositivos distintos a un monitor, como un telfono mvil o una PDA.
7. Protocolo HTTP.
El protocolo HTTP define las reglas que usan los servidores y clientes para comunicarse entre ellos.
Es un protocolo que no usa una conexin de control y que define los posibles mensajes que los clientes
pueden enviar, as como la estructura y formato de las respuestas. El protocolo define una estructura de
datos llamadas cabeceras que se utilizan tanto en las peticiones como en las repuestas. Actualmente se
utilizan las versiones 1.0 y la 1.1 del protocolo, siendo la 1.2 una versin experimental.
El funcionamiento bsico de comunicacin entre un cliente y un servidor es el siguiente:
El usuario introduce la URL del recurso en la barra del navegador o bien sigue un enlace de un
documento HTML.
El cliente Web descodifica la URL, separando sus diferentes partes. Se identifica el protocolo de
acceso, la direccin DNS o IP del servidor, el posible puerto opcional (el valor por defecto es 80)
y el objeto requerido del servidor.
Se abre una conexin TCP/IP con el servidor, llamando al puerto TCP correspondiente y se
realiza la peticin. Para ello, se enva el mensaje necesario (GET, POST, HEAD,), la direccin
del objeto requerido (el contenido de la URL que sigue a la direccin del servidor), la versin del
protocolo HTTP empleada (casi siempre HTTP/1.0) y un conjunto variable de informacin, que
incluye datos sobre las capacidades del browser, datos opcionales para el servidor,etc.
El servidor devuelve la respuesta al cliente. Consiste en un cdigo de estado y el tipo de dato

MIME de la informacin enviada, seguido de la propia informacin solicitada
Se cierra la conexin TCP/IP.

Importante; cada transaccin HTTP es una comunicacin distinta en donde en cada una de ellas se
intercambian mensajes HTTP. As cuando descargamos una pgina web, en realidad se establecen
decenas de comunicaciones que van descargando los distintos recursos de la pgina.
Por ejemplo, si requiere obtener la pgina web del servidor con IP 192.168.210.210, la forma de
obtenerla sera utilizando los mensajes de peticin del protocolo HTTP. En vez de usar un navegador, que
es lo que normalmente se hace, realizamos una conexin telnet con el servidor web accediendo a su
puerto 80.
#telnet 192.168.210.210 80
Realizada la conexin enviaramos el mensaje de peticin indicando el recurso y el protocolo a usar.

En el ejemplo se solicita la pgina web por defecto del directorio raz del sitio:
GET / HTTP/1.0
El mensaje de respuesta enviado por el servidor estar compuesto de una lnea inicial con el cdigo de
estado, seguida de un encabezado (del que luego explicaremos su formato y significado) y termina con el
cuerpo del mensaje, en este caso con el cdigo HTML de la pgina web del directorio raz del servidor.
7.1. Mensajes HTTP.

Los mensajes HTTP son en texto plano conteniendo las rdenes y parmetros segn la sintaxis
definida en el protocolo. Pueden ser de dos tipos: de peticin y de respuesta.
Los mensajes de peticin estn formados por tres partes:

Lnea inicial de peticin: indica el mtodo de peticin utilizado (GET, POST, ), la URL
solicitada, y opcionalmente la versin del protocolo. Por ejemplo: GET / HTTP/1.0
Lneas de cabecera: conjunto de pares nombre/valor denominados cabeceras o encabezados
que determinan cmo ser procesada la peticin por parte del servidor. Suelen enviar
informacin referente a la solicitud y/o el cliente (identificacin del navegador, sistema
operativo, tipos MIME aceptados, etc.). Cada cabecera se muestra en una lnea, dejando una
lnea en blanco detrs de la ltima cabecera. Por ejemplo la cabecera Accept: text/html indica
que el navegador es capaz de procesar cdigo HTML.
Cuerpo del mensaje (opcional): contiene datos o archivos a enviar al servidor. Debe estar
separado de la cabecera mediante una lnea en blanco.
Los mensajes de respuesta estn formados por tres partes:
La lnea inicial de respuesta (lnea de estado): informa de la versin HTTP usada,

continuando con un cdigo de estado u error que indica al cliente cmo ha sido procesada la
peticin, y termina con un texto explicativo del cdigo de estado. Por ejemplo: HTTP/1.1 200
OK.
Lneas de cabecera: conjunto de pares nombre/valor denominados cabeceras que describen

los datos y la forma en que son enviados al cliente. Cada cabecera se muestra en una lnea,
dejando una lnea en blanco detrs de la ltima cabecera. Por ejemplo la cabecera: ContentLenght: 57 indica que la respuesta tiene un tamao de 57 bytes.
Cuerpo del mensaje (opcional): Quedar determinado por el tipo de recurso solicitado. Por
ejemplo: <html><head></head><body><p>Hola Pepe</p></body></html>
7.2. Mtodos de peticin.

Los mtodos de peticin especifican la operacin que quiere realizar el cliente en el servidor. La
versin HTPP 1.1 contempla 7 mtodos:
Mtodo GET. Es el ms usado y se emplea para obtener cualquier tipo de informacin del
servidor. Se invoca cuando colocamos una URL en el navegador, pinchamos en un enlace o
cuando se enva un formulario mediante GET, lo que permite enviar parmetros (datos) al
servidor en la URL de peticin.
Por ejemplo si en la URL de un navegador usamos www.sitio.com/datos.php?nombre=pepe&edad=21,
la peticin sera:
GET /datos.php?nombre=pepe&edad=21 HTTP/1.0
Host: www.sitio.com
Las peticiones GET no envan cuerpo del mensaje, y no se pueden usar para subir archivos o
elementos pesados al servidor.
Mtodo POST. Se emplea para indicar al servidor que acepte informacin adjunta en una
peticin. POST s enva cuerpo del mensaje y en l se incluyen los parmetros y los datos que se
necesiten enviar. (En este caso los parmetros no son visibles en la URL). Se invoca
normalmente al enviar un formulario POST. Se utilizan en operaciones que no deberan ser
repetidas (los navegadores advierten cuando se refresca una pgina con una peticin POST). No
hay lmites en la cantidad de datos que se envan al servidor.
Si la peticin del ejemplo anterior hubiera POST, sera:
POST /datos.php HTTP/1.1
Host: www.sitio.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 36
nombre=pepe&edad=21
Mtodo OPTIONS. Permite solicitar al servidor informacin sobre qu mtodos de peticin

tiene disponibles para una URL especfico.
Mtodo HEAD. Es como una peticin GET, pero recuperando slo las cabeceras.
Mtodo PUT. Permite enviar recursos, generalmente archivos, al servidor.
Mtodo DELETE. Permite eliminar recursos del servidor.
Mtodo TRACE. Permite obtener la traza de una peticin a travs de proxies y cortafuegos.
7.3. Cabeceras.
Las cabeceras son pares de nombre/valor que se pueden incluir en los mensajes HTTP. Definen
informacin a cerca de los servidores, los clientes y de los datos que se intercambian entre ellos.
Existen muchos tipos de cabeceras y la podemos clasificar en:
Generales. Definen informacin que puede ser de utilidad para los clientes y los servidores. Por
ejemplo informacin de control de la cach, fechas y horas, sistema de cdigos usado en la
transferencia, etc.
De peticin. Usadas por los clientes para enviar informacin al servidor. Como por ejemplo el
tipo de navegador, nombre del servidor al que se le realiza la peticin, tipos MIME soportados,
uso de compresin de datos, idiomas que acepta el navegador, cookies, etc.
De respuesta. La usa el servidor para enviar informacin referente al tipo de servidor como por
ejemplo el TTL de la respuesta, la fecha en la que se espera que est disponible un recurso que en
cierto momento no lo est, el tipo de autentificacin necesaria para acceder el recurso, etc.
De entidad. Es informacin que est relacionada con el recurso a proporcionar al cliente, como
por ejemplo el tipo de codificacin, idioma, longitud, tipo MIME, etc.
La versin HTTP/1.0 define 16 cabeceras, todas ellas opcionales; y la HTTP/1.1 define 46 donde la
nica obligatoria es la cabecera de peticin host si se configuran servidores virtuales por nombre.
Por otro lado, las aplicaciones web pueden definir sus propias cabeceras para aadir informacin
adicional en los mensajes HTTP. Estas cabeceras personalizadas usan por convenio el prefijo X- para
identificarlas. Por ejemplo X-temperatura.
Un ejemplo de cabeceras la tenemos en el siguiente mensaje de respuesta proporcionado por un
servidor web:
HTTP/1.0 400 Bad Request
Server: AkamaiGHost
Mime-Version: 1.0
Content-Type: text/html
Content-Length: 194
Expires: Sat, 21 Apr 2012 17:34:16 GMT
Date: Sat, 21 Apr 2012 17:34:16 GMT
Connection: close
<HTML><HEAD><TITLE>Invalid URL</TITLE></HEAD><BODY><H1>Invalid URL</H1>The requested URL
"/", is invalid.<p>Reference #9.2cffef50.1335029656.1b70c15f </BODY>
</HTML>
Para FireFox existe el complemento Live HTTP Headers que una vez instalado podemos activarlo
desde el men Herramientas. Este complemento permite visualizar y consultar las cabeceras de los sitios
web visitados.
Existen ciertas cabeceras que por su importancia las comentaremos ms detenidamente.
Almacenamiento en cach. De las informaciones que almacena un servidor, algunas de ellas no

cambian durante mucho tiempo. HTTP permite el almacenamiento en cach durante un tiempo para
disminuir el trfico en la red. Las cabecera Cach-Control, Last-Modified, Expires, Age, Etag, If-Match, ifModified-Since permiten controlar qu se almacena en cach, durante cunto tiempo, qu no se puede
almacenar, si hay que actualizar la cach, etc.
Compresin. Los servidores pueden comprimir los recursos solicitados para reducir el trfico en la
red. Para ello los clientes usan en los mensajes de peticin la cabecera Accept-Encoding para indicar
que aceptan compresin; y los servidores la cabecera Content-Encoding para informar al cliente que va
a enviar los datos comprimidos.
Cookies. La conexin entre el cliente y el servidor se libera cuando finaliza la recepcin del recurso
solicitado. En el protocolo HTTP no se describe cmo recordar conexiones anteriores. Es decir, de
una peticin a la siguiente no se conserva ningn tipo de informacin, cada conexin es
independiente y en principio no hay una memoria de conexiones del cliente. Para solventar esta
situacin, aparte de la cach, se crearon las cookies, que son ficheros de texto que intercambian los
clientes y servidores para recordar conexiones anteriores.
Las cookies permiten a los servidores enviar en la cabecera texto en una respuesta HTTP, la cual
podr quedar almacenada en el cliente si la configuracin de ste lo permite. Posteriormente el
navegador podr enviar la cookie al mismo servidor cuando realice una peticin posterior.
Una manera de identificar a los usuarios y conexiones aunque se vayan visitando distintas pginas
web es almacenando cookies en el cliente y luego enviarlas al servidor para ver si sus valores son los
mismos o han cambiado.
Los servidores envan las cookies usando las cabeceras Cookies y Set-Cookie incluyendo informacin
relativa al nombre de la cookie, su valor, fecha de expiracin, ruta donde almacenarse, nombre de
dominio del servidor que la enva, etc.
Cuando el navegador realiza una peticin a un servidor web, consulta las cookies que tiene
almacenadas, y si existe alguna que no haya caducado y cuya ruta y dominio coinciden con los de la
peticin, se las enva al servidor usando las cabeceras Cookies y Set-Cookie.
Es importante recordar que las cookies pueden ser aceptadas, bloqueadas o borradas segn est
configurado el navegador del cliente.
7.4. Cdigos de estado y error.

Los cdigos de estado y error los envan los servidores en las respuestas HTTP con el fin de
informar a los clientes de cmo ha sido procesada la peticin. A continuacin del cdigo se presenta un
texto explicativo del cdigo enviado.
Los cdigos son nmeros de tres cifras que se clasifican en 5 tipos en funcin del primer dgito.
100 199 Son cdigos informativos que indican que el servidor ha recibido la peticin pero que
no ha sido todava procesada.
200 299 Indican xito en la peticin. Por ejemplo el tpico 200 OK.
300 399 De redireccin indicando que la peticin ha sido procesada, pero redirigida a otra
localizacin.
400 499 Errores del cliente debido a un error en la peticin o que sta no se puede conceder
(errores de sintaxis, acceso no autorizado, recurso no disponible, etc.)
500 599 Errores del servidor al recibir la peticin (fallo de configuracin, sobrecarga, etc.)
Para obtener una lista de los cdigos de error y sus significados se puede consultar en la direccin
http://es.wikipedia.org/wiki/Anexo:Cdigos_de_estado_HTTP.
7.5. Autentificacin y Seguridad.

El protocolo HTTP permite mecanismos de autentificacin para controlar los recursos que ofrecen
los servidores. Con la cabecera WWW-Authenticate el servidor pide autentificacin al cliente, y con la
cabecera Authoritation el cliente enva al servidor sus credenciales (usuario y clave de acceso). HTTP
establece dos mecanismos para enviar al servidor los credenciales del cliente de forma codificada:
Basic. El cliente enva al servidor sus credenciales codificados con el algoritmo base64. Este
algoritmo no es seguro y adems es fcil de capturar y descifrar.
Digest. En este caso se enva al servidor un resumen criptogrfico (hash) combinado del usuario, la
peticin y de la contrasea usando el algoritmo MD5. Aunque es ms seguro que el anterior, es
tambin vulnerable.
Los mecanismos de autentificacin anteriores no son seguros, de forma que con ellos no se garantiza
que el cliente es quien dice ser. HTTP no provee mecanismos de autentificacin para los servidores de
forma que realmente no se puede comprobar si el servidor es quien dice ser.
10 Tema 4. Servidores Web (Web)

El uso de cookies para autentificar a usuarios a servidores no es nada seguro. Existe la posibilidad de
falsificar las cookies y los parmetros que se envan mediante una peticin GET en la URL pudindose
suplantar la identidad de los usuarios.
Respecto a la seguridad, HTTP no es nada seguro ya que el intercambio de informacin se realiza en
texto plano y por lo tanto es vulnerable a los ataques de anlisis de trfico de red.
Los propios clientes, servidores y aplicaciones web tienen vulnerabilidades que pueden ser
aprovechadas por atacantes para obtener datos o desestabilizar los sistemas.
Estas carencias en HTTP ha provocado que la autentificacin se establezca mediante aplicaciones web
(se enva los credenciales al servidor mediante un formulario donde se tratan mediante una aplicacin
escrita en PHP, ASP, etc.) y que la seguridad se garantice usando certificados digitales y HTTPS.
8. Protocolo seguros.
S-HTTP (Secure HTTP) es un protocolo que usa extensiones de las cabeceras HTTP para negociar la
seguridad entre cliente y servidor y establecer los algoritmos de encriptacin a usar (normalmente PGP).
La encriptacin se establece slo en las cabeceras, el resto de los datos de la transmisin no van
encriptados. La extensin de los documentos usados con este protocolo es .shttp. Este protocolo ha
tenido poco xito, de hecho muchos navegadores en sus versiones ms recientes ya no lo soportan.
HTTPS (HTTP Secure) es un protocolo que utiliza SSL (Secure Sockets Layer) o TLS (Transport
Layer Security) para encapsular los mensajes HTTP. Estos protocolos proporcionan mecanismos de
encriptacin de la informacin para garantizar la privacidad de la informacin, y el uso de certificados
digitales para asegurar la autenticidad de los servidores. Este protocolo es ampliamente utilizado, y de
hecho los soportan todos los navegadores.
Los servidores web que usan el protocolo HTTPS, escuchan las peticiones de los clientes por el puerto
443/TCP; y los clientes deben indicar en la URL el protocolo https en vez de http.
Como hemos comentado, el uso de certificados permite identificar a las partes que intervienen en una
conexin. Los certificados de servidor permiten acreditar a un servidor web en el sentido de que dicho
certificado asegura que el servidor web es realmente quien dice ser. Un certificado lo emite una autoridad
certificadora (AC), una especie de notario digital, en el cual podemos confiar (o no) en los certificados
que emite. Si un usuario confa en una AC e instala su certificado raz, est asumiendo que confa en
todos los certificados que emita dicha AC.
Por ejemplo, en Espaa, la FNMT (Fbrica Nacional de Moneda y Timbres) es una AC que emite
certificados. La AEAT (la Agencia Tributaria) dispone de servidores web certificados por la FNMT. Si un
usuario instala el certificado raz emitido por la FNMT, quiere decir que confiamos en la FNMT como
AC y por lo tanto en el certificado que nos presente la AEAT emitido por la FNMT.
Si al conectarnos a un sitio web mediante HTTPS nos presenta un certificado, no quiere decir que sea
un sitio seguro, sino que tiene un certificado firmado por una AC, que bien pudiera ser el mismo! Por
eso, los navegadores nos advierten si reciben un certificado emitido por una AC que no es de nuestra
confianza (no tenemos instalado su certificado raz), y nos preguntan si confiamos en dicho certificado y
en la AC que los emiti. En definitiva, es responsabilidad nuestra la decisin de aceptar o no el
certificado.
Las tramitaciones de certificados por algunas AC son costosas. Una alternativa es usar certificados
autofirmados, es decir certificados de servidor emitidos por el propio servidor. Estos certificados se
pueden generar mediante software como Microsoft Certificate u OpenSSL.
Microsoft Certificate permite implantar una AC en un sistema Windows Server que acte como
controlador de dominio, de tal forma que puede emitir certificados que autentifiquen a los objetos del
dominio. Se suele usar slo dentro de organizaciones, de tal forma que los elementos de la organizacin
pertenecientes al dominio confan en los certificados emitidos por la AC instalada en el controlador del
dominio.
OpenSSL es un proyecto de software libre consistente en un paquete de herramientas de
administracin y bibliotecas relacionadas con la criptografa, que suministran funciones criptogrficas a
otros paquetes como OpenSSH y a los navegadores web para acceso seguro a sitios HTTPS. Estas
herramientas ayudan al sistema a implementar los protocolos SSL y TLS y a crear certificados digitales
que pueden usarse para identificar a un servidor web.
11
En las comunicaciones seguras, aparte de los certificados de servidor que autentifique de alguna
manera a los servidores, se necesita que se asegure la privacidad de la informacin transmitida mediante
mecanismo de cifrado.
Los mecanismos de cifrado se basan en la utilizacin de claves para cifrar y descifrar los mensajes. La
criptografa simtrica usa la misma clave para cifrar y descifrar los mensajes, es un sistema rpido de
cifrado pero tiene el inconveniente de que es menos seguro ya que el emisor y el receptor deben
intercambiarse las claves previamente.
En la criptografa asimtrica, la que se usa en SSL y TLS, existen dos claves diferentes: una para
cifrar y otra para descifrar. La clave de cifrado es pblica, esto es, conocida por todo el mundo; la de
descifrado (clave privada) solamente es conocida por su propietario. Ambas constituyen un par de claves.
Para comprender como es el funcionamiento supongamos que tanto Anastasia como Bartolo tienen
un par de claves pblica/privada. Si Anastasia desea enviar un mensaje a Bartolo, los pasos que debe
seguir son los siguientes:
- Anastasia obtiene la clave pblica de Bartolo.
- Anastasia compone el mensaje y lo cifra con la clave pblica de Bartolo.
- Anastasia enva el mensaje cifrado.
- Bartolo recibe el mensaje y le aplica su clave privada obteniendo el mensaje.
Es decir, cualquiera que disponga de la clave pblica de Bartolo, puede cifrar un mensaje y envirselo,
pero solamente l podr descifrar los mensajes que le llegan. Nadie ms; ni siquiera Anastasia podr
descifrar el mensaje que ella misma acaba de cifrar.
La base de la seguridad en los procesos de cifrado est en la fortaleza de los algoritmos de cifrado o
encriptacin. Algunos de ellos son RSA, DES, TDES (Triple DES), AES, X.509.
Volviendo al caso de los servidores web. Los certificados de servidor que emite una AC contienen,
adems de la informacin que identifica al servidor, la clave pblica del servidor. Como hemos dicho,
esta clave es la que permite a los clientes encriptar informacin de forma que solo nuestro servidor web
puede decodificarla con su clave privada.
As que cuando un usuario desde un navegador se conecta a un servidor seguro (que tiene activada la
seguridad), el servidor le manda el certificado. Como este certificado ha sido emitido por una AC, el
navegador verifica si es correcto o no. Si es correcto, utiliza la clave pblica del servidor web que recibi
para encriptar mensajes y comunicarse de forma segura con el servidor.
8.1. Gestin de certificados en Windows 2003 Server.

Como hemos comentado, W2003S se puede configurar como una entidad emisora de certificados
mediante los Servicios de Certificate Server. Dicha entidad emisora de certificados podr ser de dos tipos:
de empresa o de tipo independiente.
Para ello el servidor debe ser un Controlador de Dominio ya que las entidades emisoras de
certificados de empresa u organizacin, dependen de Active Directory. La entidad certificadora del
servidor Windows 2003 Server slo tendr validez en el mbito del Dominio que gestione el servidor en
el cual ha sido instalada dicha entidad certificadora. Esto nos permitir expedir certificados de servidor
para disponer de pginas web seguras accesibles por el protocolo HTTPS en los sitios web que creemos
en nuestro servidor.
Para proceder a la instalacin de la entidad certificadora en el equipo W2003S accederemos al "Panel
de Control" -> "Agregar o quitar programas" -> "Agregar o quitar componentes de Windows" y
activaremos la casilla "Servicios de Certificate Server".
A continuacin se nos avisar de que el equipo no podr cambiar de nombre ni ser agregado o quitado
de un dominio. Posteriormente pasar a ejecutarse el asistente de instalacin de la entidad certificadora.
En la primera ventana dejaremos activado el botn de radio "Entidad emisora raz de la empresa". En la
siguiente ventana del asistente indicaremos como nombre de la entidad certificadora el nombre de nuestro
equipo servidor, dejando el resto de opciones tal cual nos las ofrecen por defecto el asistente.
A continuacin indicaremos la ruta donde se almacenarn los datos de la base de datos de los
certificados, dando por vlidas en nuestro caso las ofertadas por defecto. Tras llevar a cabo la accin
anterior, se nos presentar un mensaje que indica que debe detenerse el servidor IIS, pulsaremos sobre el

botn "S" para proceder y
certificadora.
en este momento comenzar el proceso de instalacin de la entidad
El proceso de instalacin nos solicitar el CD de "Windows 2003 Server" y es posible que durante el
proceso de instalacin se muestre una ventana que nos informa de la necesidad de activar "Active Server
Pages" (ASP) en nuestro IIS, en cuyo caso pulsaremos sobre el botn "S".
Una vez completado el proceso de instalacin del servidor de certificados, aparecer un nuevo acceso
directo "Entidad emisora de certificados" en las "Herramientas administrativas". Este enlace nos permitir
realizar peticiones de certificados para los sitios web del servidor Internet Information Server (IIS).
8.2. Gestin de certificados en Linux.

Si necesitamos configurar un servidor web seguro en Linux, tendremos que definir en el servidor
carpetas seguras que mediante el protocolo SSL proporcionen el cifrado de los datos que se intercambian
entre el servidor web y el cliente.
Como ya comentamos, debemos disponer de un certificado de seguridad que puede ser expedido por
una AC con el consiguiente coste econmico, o bien crear y utilizar nuestra propia AC que expedir
certificados vlidos en nuestro mbito de actuacin.
El paquete OpenSSL para Linux se encarga de la implementacin del protocolo SSL para llevar a cabo
transferencias seguras y de la creacin de certificados.
Una vez realizada la instalacin del paquete
$ sudo apt-get install openssl
deberemos configurarlo editando el archivo /etc/ssl/openssl.cnf. En dicho archivo nicamente vamos a

configurar los valores por defecto de nuestra organizacin para que el resto de aplicaciones y programas
que usen OpenSSL tomen dichos valores por defecto de forma automtica. Dichos valores debemos
configurarlos en la seccin [req_distinguished_name]. En el resto de secciones no es necesario que
modifiquemos nada ya que nos sirve con las opciones configuradas por defecto.
[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = ES
countryName_min = 2
countryName_max = 2
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Granada
localityName = Granada
0.organizationName = Organization Name (eg, company)
0.organizationName_default = IES Zaidin-Vergeles
# we can do this but it is not needed normally
#1.organizationName = Second Organization Name (eg, company)
#1.organizationName_default = World Wide Web Pty Ltd
organizationalUnitName = Dpto Informatica
#organizationalUnitName_default =
commonName = yomismo
commonName_max = 64
emailAddress = yomismo@aula.izv
emailAddress_max = 64
Para que nuestro servidor pueda servir pginas seguras con el protocolo HTTPS, necesita un
certificado. En nuestro caso generaremos un certificado autofirmado ejecutando el comando:
$ make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /etc/ssl/certs/aula.pem
Durante la ejecucin de comando make-ssl-cert, nos preguntar por el nombre del servidor a certificar,
el pas donde se encuentra, la organizacin a la que pertenece, etc. crendose el archivo
/etc/ssl/certs/aula.pem con el certificado de servidor.
Para ver el contenido del certificado podemos usar el comando
$ sudo openssl x509 -in /etc/ssl/certs/aula.pem -noout -text
Informndonos de quin certifica, la validez del certificado, qu se certifica, la clave pblica y la

firma del certificado.
13
9. Alojamiento virtual.
El alojamiento virtual de sitios web (virtual hosting) consiste en simular que existen varios equipos
con sus respectivos sitios web sobre un nico servidor web. Por ejemplo se podran alojar los sitios web
www.infor.es y apuntes.infor.es en una misma mquina o equipo.
El uso de servidores web virtuales permite reducir el nmero de mquinas fsicas para alojar los
sitios web y aprovechar mejor los recursos (CPU, memoria) de los equipos.
El alojamiento virtual se puede implementar de tres formas:
Alojamiento virtual basado en IPs. El equipo servidor tendr tantas direcciones IP como
servidores web virtuales. Para ello el servidor deber tener varias tarjetas de red, o bien asignar
varias IP (alias o interfaces virtuales) a una misma tarjeta de red. Este tipo de alojamiento es
muy limitado debido a la necesidad de usar tantas IP como sitios web.
Alojamiento virtual basado en nombres. Se permite alojar varios nombres de dominio sobre la
misma IP, donde cada servidor virtual atiende las peticiones de un nombre de dominio. Para
ello hay que configurar un servidor DNS que asocie los diferentes nombres de dominio con la
misma direccin IP y que soporte el protocolo HTTP/1.1 (o el HTTP/1.0 con extensiones) que
permite identificar el servidor al que se quiere acceder por nombre a travs de la lnea de
cabecera Host. Este mtodo es el ms usado.
Alojamiento virtual basado en puertos. Cada servidor virtual atiende por una misma direccin
IP pero por un puerto diferente.
Los tipos anteriores se pueden combinar, todo depende de que el software del servidor permita este
tipo de configuraciones mixtas.
10. Instalacin y configuracin IIS en Windows.

Los servicios de Internet Information Server (IIS), permiten la creacin, configuracin y
administracin de sitios web, adems de permitir otras funciones de Internet gracias a que soporta los
protocolos Network News Transport Protocol (NNTP), o protocolo de transferencia de noticias a travs
de la red, File Transfer Protocol (FTP) o protocolo de transferencia de archivos, Post Office Protocol
(POP) o protocolo de Oficina de Correos, as como Simple Mail Transfer Protocol (SMTP) o protocolo
simple de transferencia de correo.
Los servicios de Internet Information Server 6.0 (IIS) de Windows 2003 Server facilitan la
publicacin de informacin en una Intranet o en Internet, as como comunicaciones seguras mediante el
protocolo SSL. Adems, utilizando los componentes y secuencias de comandos de servidor, se pueden
crear contenidos dinmicos mediante lenguajes de script como Page Active Server (ASP) o PHP.
10.1. Instalacin de IIS.

La instalacin de IIS se puede realizar mediante el Asistente para configurar su servidor de la
Herramientas administrativas; o a travs de la utilidad Agregar componentes de Windows ->
Componentes de Windows -> Servidor de Aplicaciones -> Instalar IIS.
Durante la instalacin se pedir que seleccionemos los elementos de IIS a instalar. Para el servicio
HTTP los ms importantes son el Servicio de administracin de IIS y el Servicio World Wide Web.
Cuando se finalice el proceso de instalacin, se crear dentro de Herramientas Administrativas el
acceso directo Administrador de IIS el cual cuando se active mostrar la ventana de administracin de
los servicios de IIS.
10.2. Servidor virtual por defecto.

En el panel izquierdo del administrador de IIS se presentan los equipos a administrar. En principio
slo aparece la mquina local, pero se puede realizar una conexin a otro servidor y administrar los
servicios web de dicho servidor si tenemos cuenta de administrador en l.
Expandiendo el icono que representa el servidor, aparecen carpetas con los nombres de los servicios
instalados, y entre ellas Sitios Web. Si expandimos esta carpeta aparece otra con el nombre Sitio Web
predeterminado, la cual contiene la informacin de configuracin de dicho sitio web.

Si ubicados sobre dicho sitio web "Sitio web predeterminado" pulsamos sobre el mismo con el botn
derecho del ratn y elegimos la opcin "Propiedades" en el desplegable correspondiente, pasar a ser
mostrada una ventana en la que si nos situamos sobre la pestaa "Directorio particular", podremos
comprobar como la ruta del directorio raz este sitio web es C:\inetpub\wwwroot.
Normalmente no se suele usar este sitio web que por defecto instala el servidor IIS, bsicamente
porque el mismo ha sido creado con fines administrativos para gestionar aplicaciones tales como el
acceso web de Escritorio remoto, o el acceso web a las impresoras del equipo.
Para comprobar el funcionamiento de este sitio web, desde el propio equipo servidor, escribimos en la
URL del navegador localhost, presentndose la pgina por defecto de dicho sitio ( default.htm). Tambin
responder si usamos la direccin IP del servidor o su nombre de dominio siempre que un servidor DNS
lo resuelva.
10.3. Configuracin de servidores virtuales.

El servidor IIS permite la administracin de varios sitios web (servidores virtuales). Para crear un
nuevo sitio web debemos seleccionar el icono del servicio y posteriormente activar la opcin del men
Accin - > Nuevo. Esta operacin lanza un asistente al cual le deberemos proporcionar las siguientes
informaciones:
Nombre o descripcin del sitio para su identificacin.
Direcciones IP del servidor por las que se atender las peticiones y el puerto de acceso. Por
defecto atender por cualquier direccin IP y por el puerto 80 para HTTP y 443 para HTTPS. Si
se utiliza HTTPS, se puede especificar el certificado SSL a utilizar.
Directorio local o remoto donde se alojar la jerarqua de pginas y subdirectorios del sitio web.
Permisos de acceso sobre los usuarios que acceden al sitio.
Si el sitio web creado con el asistente usa la misma IP y puerto que el servidor web predeterminado,
no se permitir acceder a ambos simultneamente. Debemos detener uno de ellos e iniciar el otro. Para
detener o iniciar un servidor web podemos hacerlo a travs de las opciones correspondientes del men
contextual del icono que representa a dicho servidor web.
Para probar el servidor web creado con el asistente debemos detener el servidor web predeterminado e
iniciar el recin creado. Por defecto, el sitio web creado deber alojar un archivo de nombre default.htm o
index.htm en el directorio raz del servidor para que se presente dicha pgina cuando se acceda a dicho
sitio mediante localhost en la URL del navegador.
Una vez creado un sitio web, se pueden establecer otros muchos parmetros a travs de la opcin
Propiedades del men contextual del sitio web creado. Estos parmetros se agrupan en diversas pestaas
segn su funcionalidad. Algunos de ellos son:
Sitio Web. Permite configurar la direccin IP y puerto de escucha de las peticiones, as como el
tiempo de espera determinado para las conexiones y llevar un registro de acceso de los usuarios.
Rendimiento. Permite establecer el ancho de banda de la conexin y el nmero mximo de clientes.
Directorio particular. Establece el directorio raz del sitio web y los privilegios de los usuarios.
Documentos. Se indican los documentos en orden de preferencia que pueden actuar como ndice del
sitio. Se pueden agregar, eliminar o cambiar el orden de preferencia de los documentos.
Errores personalizados. Se indican los cdigos de error y las pginas web con los mensajes de error
asociados. Se puede modificar esta asociacin a otro documento con un nuevo mensaje.
Encabezados HTTP. Permite establecer los tiempos en que las pginas se mantendrn en cach,
definir encabezados personalizados que el servidor enviar a los clientes cuando stos hagan
peticiones al servidor, y asociar extensiones de archivos a tipos MIME.
Seguridad de directorios. Permite restringir los equipos, grupos de equipos o dominios a los que se
les conceder o negar conexin al servidor. Habilitar o no el acceso annimo y pedir autentificacin
a los clientes. Tambin permite habilitar la utilizacin de un canal seguro SSL y la creacin de un
certificado de servidor.
15
10.3.1. Servidores virtuales por nombre.

Como ya comentamos IIS permite disponer de varios servidores virtuales por IP, por puerto o por
nombres. Para configurar servidores virtuales por nombres, una vez creados los servidores usando el
asistente, debemos mediante sus propiedades, en la ficha Sitio web de cada uno de ellos, sustituir el
contenido del cuadro de texto Direccion IP Ninguna asignada por la direccin IP de la mquina.
A continuacin, activamos el botn Avanzadas y seleccionamos la nica identidad que aparece en la
ventana de identidades. Mediante el botn Modificar escribiremos en el cuadro de texto valor de
encabezado de host (nombre de host), el nombre de dominio por el que responder el servidor virtual.
Esta operacin habr que realizarla para cada uno de los servidores virtuales.
As por ejemplo podemos tener dos servidores virtuales sw1.aula.izv y sw2.aula.izv en la misma
direccin IP y puerto. Evidentemente debe haber un servidor DNS que resuelva los nombres de dominio
de los servidores con la direccin IP de la mquina donde se ubican.
Adems, un mismo servidor virtual puede responder usando diferentes nombres. Slo es necesario
aadir en la ventana de identidades del servidor una nueva identidad con los mismos valores para la
direccin IP y puerto, pero con un valor de encabezado de host (nombre de host) distinto.
10.4. Directorios virtuales.

Un directorio virtual no es un directorio que como tal est incluido dentro del sitio, sino que opera al
estilo de un acceso directo. Aunque se incluye dentro del sitio web, realmente se hace referencia a un
directorio local o remoto que est ubicado fuera de la jerarqua de directorios del sitio web.
Para crearlos, una vez seleccionado el sitio web, se elije la opcin del men contextual Nuevo ->
Directorio Virtual. Un asistente solicitar el nombre o alias para este directorio virtual, la carpeta a la que
se har referencia, y los permisos de acceso al directorio.
10.5. Servidores virtuales seguros.

W2003S se puede configurar como una entidad emisora de certificados mediante los Servicios de
Certificate Server, pero para ello el servidor debe ser un Controlador de Dominio.
Otra opcin es crear nuestra propia AC, usando el software OpenSSL en su versin para Windows de
manera que se nos permitir emitir y firmar certificados. La versin win32 ya compilada la podemos
obtener de http://slproweb.com/products/Win32OpenSSL.html, pero antes debemos instalar en el sistema
un conjunto de libreras que permitan ejecutar cdigo escrito en Visual C++. Desde
http://www.microsoft.com/en-us/download/details.aspx?id=29 podemos descargarlas.
Una vez instalado el The Microsoft Visual C++ 2008 Redistributable Package (x86) y OpenSSL en
su versin win32, (suponemos que OpenSSL se ha instalado en la carpeta por defecto C:\OpenSSLWin32), mediante el asistente de IIS crearemos un servidor virtual por nombre y lo llamaremos
seg.aula.izv. Una vez creado, los pasos para hacer que este servidor web sea seguro son:
1.
Peticin de certificado digital con IIS.

En las propiedades del sitio web, seleccionamos la pestaa Seguridad de directorios y a
continuacin pulsamos el botn Certificado de servidor. Se lanzar un asistente donde lo
primero que haremos es elegir la opcin Crear un certificado nuevo como mtodo para asignar un
certificado a un sitio web.
A continuacin prepararemos una peticin de certificado pero seleccionando la opcin de envo ms
tarde, ya que de momento no contamos con una AC a la cual envirsela. En la peticin se nos pedir
una serie de datos: nombre descriptivo del certificado, nmero de bits usados para generar la clave
(dejaremos 1024), la organizacin (por ejemplo izv), la unidad organizativa (la llamaremos aula), el
nombre del servidor web (seg.aula.izv), datos geogrficos y el nombre de archivo donde se guardar la
peticin del certificado. Supondremos que el archivo de peticin generado se denomina certreq.txt y
que se aloja en C:\OpenSSL-Win32\bin.
2.
Generacin de claves de la AC.

Seguidamente generaremos una clave privada RSA de 1024 bits para la AC. Con la clave privada de
la AC firmaremos la informacin que enva el servidor Web a los clientes (descripcin del sitio y

clave pblica del servidor). As, cuando un cliente reciba la clave pblica del servidor, puede verificar
que es correcta gracias a que esta firmada por la AC. Para ello ejecutamos la orden:
C:\OpenSSL-Win32\bin>openssl genrsa -des3 -out servidor.key 1024 -config openssl.cfg
Loading 'screen' into random state - done
Generating RSA private key, 1024 bit long modulus
.....................................++++++
......................................................++++++
e is 65537 (0x10001)
Enter pass phrase for server.key: ******
Verifying - Enter pass phrase for server.key: ******
Vemos como nos pide una contrasea para protegerla, la cual habr que repetir. La clave generada se
ha almacenado en el archivo servidor.key.
3.
Creacin del certificado raz de la AC.

Para crear el certificado raz de la AC empleando la clave generada anteriormente, ejecutamos:
C:\OpenSSL-Win32\bin>openssl req -new -key servidor.key -x509 -out servidor.crt
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
Country Name (2 letter code) [AU]:ES
State or Province Name (full name) [Some-State]:Granada
Locality Name (eg, city) []:Granada
Organization Name (eg, company) [Internet Widgits Pty Ltd]:IES Zaidin-Vergeles
Organizational Unit Name (eg, section) []:Dpto. Informatica
Common Name (e.g. server FQDN or YOUR name) []:yomismo
Email Address []:yomismo@gmail.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:******
An optional company name []:IESZV
En este comando debemos indicar cual es nuestro fichero con la clave privada generada en el paso
anterior (servidor.key), el nombre del archivo que contendr el certificado raz (servidor.crt) y dar los
datos que queremos que aparezcan en el certificado raz de la AC; es decir los de entidad emisora.
4.
Firma de la peticin del certificado por la AC.

La peticin de certificado que generamos en IIS en el paso 1, y que guardamos en el archivo
certreq.txt, la firmaremos con el certificado anterior. Con esto conseguiremos la emisin del certificado
de servidor firmado por nuestra AC, y que guardaremos en iis.crt. Para ello ejecutamos el comando:
C:\OpenSSL-Win32\bin>openssl x509 -req -days 365 -in certreq.txt -CA servidor.crt -CAkey servidor.key
-CAcreateserial -out iis.crt
Signature ok
subject=/C=ES/ST=Granada/L=Granada/O=izv/OU=aula/CN=seg.aula.izv
Getting CA Private Key

5.
17
Instalacin el certificado en IIS.

Para la instalacin del certificado, volvemos a seleccionar del sitio web la pestaa Seguridad de
directorios y a continuacin pulsamos el botn Certificado de servidor. Ahora el asistente nos
comunica que tenemos una peticin de certificado de servidor pendiente. Seleccionamos la opcin
que permite continuar con la peticin e instalar el certificado.
A continuacin nos pide el archivo con el certificado de servidor que generamos anteriormente
(iis.crt) y nos presenta los datos de identificacin del servidor que dimos cuando pedimos la emisin
del certificado para ver si son correctos.
Terminado el asistente, podemos ver el certificado que se ha instalado en IIS desde el botn Ver
certificado de la pestaa Seguridad de directorios del sitio web.
6.
Prueba del servidor seguro.

En la configuracin del servidor seguro hemos posibilitado su acceso mediante HTTPS, pero todava
podemos seguir accediendo usando HTTP. Para obligar a que slo se pueda acceder a travs de
HTTPS, deberemos, en las propiedades del sitio web de la consola de administracin del IIS,
seleccionar la pestaa Seguridad de directorios y pulsar el botn Modificar del apartado
"Comunicaciones seguras" y marcar la casilla "Requerir canal seguro (SSL)".
Para probar el servidor debemos usar el protocolo HTTPS en la URL del navegador de la forma
https://seg.aula.izv suponiendo que seg.aula.izv es el nombre de dominio del servidor web que hemos
configurado.
El navegador nos presentar un mensaje de aviso diciendo que la conexin no es segura ya que la
identidad del servidor no puede ser verificada. Esto ya la sabemos porque el certificado no est
emitido por una AC de confianza para el navegador (no tiene instalado su certificado raz).
Tendremos que aadir una excepcin y confirmarla para poder acceder al sitio web.
11. Instalacin y configuracin de Apache en Linux.

Apache Software Foundation (http://www.apache.org) es una fundacin que patrocina y colabora en
mltiples desarrollos software, siendo uno de ellos el servidor web open source. El servidor web Apache
es uno de los ms usados a nivel mundial existiendo versiones para diferentes sistemas operativos (Unix,
BSD, Linux, Windows, Macintosh, etc.).
Apache est desarrollado de forma modular, lo que permite ampliar la funcionalidad mediante la
instalacin de mdulos especficos. Por otra parte las posibilidades de configuracin son muy numerosas,
aunque como veremos, nada ms instalado es completamente funcional.
11.1. Instalacin de Apache.

La instalacin del servidor web se realiza mediante:
$ sudo apt-get install apache2
Cuando termina la instalacin, se inicia el servidor pero puede adems mostrar un mensaje de
advertencia indicando que no es capaz de determinar cul es el nombre de dominio completo del equipo.
En este caso debemos editar los archivos /etc/hosts y /etc/hostname y configurar el FQDN del equipo.
Por ejemplo el contenido de un fichero /etc/hostname:
ubup
Y el contenido del fichero /etc/hosts:

127.0.0.1
127.0.1.1
localhost
ubup.aula.izv ubup
# The following lines are desirable for IPv6 capable hosts

::1
ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
Adems,como suele suceder en la mayora de los servicios, el equipo servidor deber tener una IP fija.

Terminada la instalacin debemos comprobar que Apache est en ejecucin, y que el servicio est a la
escucha en el puerto 80. Para ello ejecutamos:
$ ps ef | grep apache
$ netstat ltun
Al finalizar la instalacin, aparte de crear los archivos de configuracin, se crean

-
El usuario www-data incluido en el grupo www-data. Este usuario es el propietario de los

procesos hijos de Apache que se encargan de atender las peticiones de los clientes.
El directorio /var/www, cuyo propietario y grupo es root. Es el directorio raz del servidor virtual
por defecto y contiene el archivo index.html, el cual se sirve cuando acedemos a http://localhost,
http://127.0.0.1 o http://IP_del_equipo_servidor.
Apache se configura editando directivas en los archivos de configuracin ubicados en /etc/apache2.

Los archivos principales son:
/etc/apache2/apache2.conf.
/etc/apache2/ports.conf. Aqu se especifica la posibilidad de usar servidores virtuales por nombre

(por defecto si lo est), y se definen las interfaces de red (direcciones IP y puertos) por los que
escuchar el servidor.
/etc/apache2/envars.
En este archivo se determina el comportamiento general del servidor.

Aqu encontramos entre otras las directivas ServerRoot, User, Group, Timeout, KeepAlive,
ErrorLog. Las directivas que no se especifiquen en este archivo de configuracin toman el valor
por defecto. Desde este archivo se incluyen (usando la directiva include) otros ficheros de
configuracin.
Se definen variables de entorno para el comando apache2ctl.
Adems de estos archivos, existen otros ubicados en subdirectorios contenidos en /etc/apache2.
Directorios de configuracin de mdulos.

o
configuracin bsica para iniciar dicho mdulo.

/etc/apache2/mods-enabled. Es el directorio de configuracin de los mdulos habilitados.
Contiene enlaces simblicos a los archivos del directorio mods-available de forma que los
enlaces que se encuentre en este directorio sern los mdulos a cargar al iniciar Apache.
Directorios de configuracin de servidores virtuales.

o
/etc/apache2/mods-available. Es el directorio de configuracin de los mdulos disponibles.

Contiene archivos .load y .conf. Los archivos .load contienen lo necesario para cargar un
mdulo en concreto; y los archivos .conf asociados a los anteriores, contiene la
/etc/apache2/sites-available. Es el directorio de configuracin de sitios virtuales disponibles.

Cada archivo del directorio contiene la configuracin de un sitio virtual disponible. Por
defecto est creado el archivo default con la configuracin del servidor virtual por defecto.
/etc/apache2/sites-enabled. Es el directorio de configuracin de sitios virtuales habilitados.
Contiene enlaces simblicos a los ficheros del directorio sites-availables, de forma que los
enlaces que se encuentren en este directorio sern los servidores virtuales que estn
habilitados. Por defecto est creado el archivo 000-default que es un enlace simblico al
archivo default del directorio sites-available.
Directorios de configuraciones locales

o
/etc/apache2/conf.d.
Permite configuraciones relacionadas con la internacionalizacin de los

mensajes de error. Tambin algunas aplicaciones web cuando se instalan, suelen incluir su
configuracin en este directorio.
Si se realizan cambios en los archivos de configuracin de Apache, deberemos reiniciar el servicio:

$ sudo /etc/init.d/apache2 stop
$ sudo /etc/init.d/apache2 start
Tambin se puede usar el comando apache2ctl

$ sudo apache2ctl stop
$ sudo apache2ctl start
19
11.2. Servidor virtual por defecto.

Apache diferencia entre el servidor principal y los servidores virtuales. Si no se configuran servidores
virtuales, el servidor principal es el que atiende las peticiones. Pero si se activan servidores virtuales, el
servidor principal no tiene efecto.
Ojo! La instalacin de la versin 2.2 de Apache para distribuciones tipo Debian, genera una
configuracin predeterminada para usar servidores virtuales por nombre por lo que el servidor principal
est anulado. Podemos comprobarlo editando el archivo /etc/apache2/ports.conf y observando cmo existe
la directiva NameVirtualHost *:80 la cual habilita los servidores virtuales por nombre en todas las
direcciones IP y en el puerto 80.
El archivo /etc/apache2/sites-available/default es el que contiene la configuracin del servidor virtual por
defecto. Este servidor est habilitado ya que en /etc/apache2/sites-enabled existe el archivo 000-default que
es un enlace simblico al archivo default.
Si editamos el archivo default podemos ver entre otras las siguientes directivas:
<VirtualHost *:80> Define el comportamiento del servidor virtual por defecto. Este servidor virtual
escucha en todas las direcciones IP (por eso el *) y por el puerto 80. La configuracin y
comportamiento de cada uno de los servidores virtuales se realizan mediante directivas
<VirtualHost> para cada uno de ellos.
DocumentRoot permite indicar cul es el directorio raz del servidor, siendo en este caso /var/www.
La directiva contenedora <Directory> se utiliza para determinar y configurar cmo se servirn los
contenidos de los directorios especificados.
La directiva ErrorLog indica el archivo de logs del servidor virtual por defecto.
Para comprobar el funcionamiento del servidor virtual por defecto podemos realizar las siguientes
operaciones:
1. Crear en /var/www el archivo sri.html.
2. Crear el directorio /var/www/datos y dentro de l, un archivo, por ejemplo datos1.html.
3. Probar el funcionamiento del servidor accediendo a las pginas anteriores.
4. Configurar el servidor DNS para acceder al servidor por su nombre de dominio.
11.3. Directivas.
Las directivas permiten la configuracin del servidor. Segn donde se escriban afectarn al servidor
en general, a un servidor virtual, a un directorio concreto, a un archivo, etc.
Existen directivas, como <VirtualHost>, <Directory>, <Files>, que actan como contenedores de otras
directivas permitiendo configurar mbitos del servidor concretos.
Como ya comentamos, el archivo /etc/apache2/apache2.conf define la configuracin general del
servidor, e incluye (mediante directivas include) los archivos ya comentados anteriormente. Las directivas
que aparecen en /etc/apache2/apache2.conf se pueden clasificar en tres tipos, las cuales pueden aparecer
mezcladas, desordenadas o ubicadas en otros archivos de configuracin.
Directivas globales. Definen los aspectos globales del servidor. Por ejemplo, nmero mximo de
clientes simultneos, tiempo de cancelacin de conexin por falta de respuesta (Timeout),
directorios de los archivos de configuracin (ServerRoot), si se permiten conexiones persistentes
(KeepAlive http://systemadmin.es/2008/11/conexiones-keepalive-de-apache), etc.
Directivas de funcionamiento del servidor principal. Agrupa las directivas que define el
comportamiento del servidor principal, y por ende se define el comportamiento por defecto de
todos los servidores virtuales, en particular el servidor virtual por defecto.
Directivas de configuracin de los servidores virtuales.
Importante. Hay que tener en cuenta que las directivas se heredan, de forma que las establecidas para
el servidor principal se heredan en los servidores virtuales, salvo que en stos se especifiquen otras.
Comentaremos algunas de las directivas ms usuales.

11.3.1. DirectoryIndex.
En los archivos de configuracin de los servidores virtuales (como por ejemplo default) dentro de la
directiva que indica cmo servir el contenido de un directorio (<Directory>) se puede indicar una directiva
para indicar cules son los archivos a servir cuando no se especifica ninguno. Por defecto, si no se indica
nada, est establecido de forma general que sea el archivo index.html, pero podemos cambiarlo. Por
ejemplo podemos editar el archivo default, y dentro de la directiva <Directory /var/www> escribir:
<Directory /var/www/>
DirectoryIndex sri.html
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>
Ahora si accedemos a http://localhost se nos servir el archivo sri.html en lugar del archivo index.html.
11.3.2. Directory y Options Indexes.
La directiva <Directory> contiene a otras que determinan cmo Apache sirve el contenido de un
directorio. Todos los directorios contenidos en uno, heredan la configuracin de ste, salvo que usemos
otra directiva <Directory> que la sobrescriba. Por ejemplo, en el servidor virtual por defecto, todos los
directorios que estn contenidos en /var/www heredarn su configuracin, y /var/www hereda y sobrescribe
la configuracin del directorio raz (/).
Qu sucedera si pido http://localhost/datos?. En principio, como no existe el archivo sri.html en el
directorio /var/www/datos, el servidor nos dara un error, pero como por herencia de /var/www est activada
la opcin Indexes, se mostrar un listado con el contenido del directorio /var/www/datos.
Ahora bien, si en el caso anterior no existiera la opcin Indexes en /var/www/, nos encontraramos en la
situacin de que en /var/www/datos ni existe el archivo a mostrar, ni se permite el listado del contenido del
directorio; en esta situacin el servidor retornar el cdigo 403 Forbbiden.
Cambiemos el contenido del archivo default aadiendo una directiva <Directory> que defina
explcitamente como definir el directorio /var/www/datos
<Directory /var/www/>
DirectoryIndex sri.html
AllowOverride None
Order allow,deny
allow from all
</Directory>
<Directory /var/www/datos>
DirectoryIndex datos1.html
Options FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>
Qu sucedera ahora cuando solicitemos http://localhost/datos?.

11.3.3. Logs.
En los archivos de configuracin existen directivas que permiten configurar los asuntos relacionados
con los logs del servicio. Estas directivas son:
ErrorLog
permite indicar el archivo de logs de errores.
LogLevel
indica el nivel de prioridad. (Mostrar slo los errores, los errores y advertencias, etc.)
CustomLog
LogFormat
permite indicar cul es el archivo que almacenar el registro con logs de acceso.
indica el formato del archivo de logs. Si no se especifica ninguno con LogFormat, se

usar el formato especificado en apache2.conf para el servidor principal.
En el archivo default de configuracin del servidor virtual por defecto encontramos:
21
ErrorLog /var/log/apache2/error.log
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
CustomLog /var/log/apache2/access.log combined
#mediante combined se almacena la URL pedida por el cliente e informacin del navegador que la realiza.
11.3.4. Codigos de error.

La directiva ErrorDocument permite configurar el texto o el documento que se presentar cuando se
produzca un error en el servidor. Por ejemplo, se puede aadir al archivo default la directiva
ErrorDocument 404 "Pgina no encontrada en el servidor"
O bien se puede indicar que se enve al cliente una pgina concreta en vez de un mensaje de error:
ErrorDocument 404 /error404.html
Para ello tendramos que crear el documento /var/www/error404.html para que pudiera ser mostrado.
11.4. Directorios virtuales.

Los directorios virtuales son directorios accesibles mediante el sitio web, pero que estn fuera del
directorio raz (DocumentRoot) del servidor. Se pueden crear mediante la directiva Alias, o creando enlaces
simblicos con FollowSymLinks dentro del directorio raz del servidor para que apunten a otro directorio.
Usando la directiva Alias. En esta directiva se especifica la ruta ficticia, es decir la que
indicaramos en el navegador a continuacin del nombre del servidor, y luego se indica la ruta
real (lugar en el disco donde se encuentra realmente los archivos del sitio).
Por ejemplo supongamos que el directorio /home/manolo/wiki contiene una pgina de nombre
index.html de forma que cuando se acceda con el navegador con http://localhost/wiki obtenemos la
pgina /home/manolo/wiki/index.html. Para ello debemos usar la directiva Alias de la forma:
Alias /wiki /home/manolo/wiki
As por ejemplo, si queremos crea este directorio virtual en el servidor virtual por defecto,
editaramos el archivo default aadiendo:
Alias /wiki /home/manolo/wiki
<Directory /home/manolo/wiki>
DirectoryIndex index.html
AllowOverride None
Order allow,deny
Allow from all
</Directory>
La opcin Options FollowSymLinks permite indicar en el directorio raz del servidor si se deben
seguir los enlaces simblicos desde los directorios virtuales a los reales. Para ello se deben crear
con anterioridad los enlaces simblicos con el comando Linux ln.
Por ejemplo supongamos que el directorio /home/manolo/blog contiene una pgina de nombre
index.html de forma que cuando se acceda con el navegador con http://localhost/blog obtenemos la
pgina /home/manolo/blog/index.html. Si queremos implementar este directorio virtual en el servidor
virtual por defecto, lo primero sera crear el enlace simblico:
$ sudo ln s /home/manolo/blog /var/www/blog
A continuacin editamos el archivo default aadiendo:

<Directory /var/www/blog>
AllowOverride None
Order allow,deny
Allow from all
</Directory>
Y lo ms importante: hemos de asegurarnos que en la configuracin del directorio /var/www est

definida la opcin Options FollowSymLinks.
11.5. Configuracin modular.

Como ya comentamos anteriormente Apache es un servidor modular permitindose aadir nuevas
funcionalidades aadiendo mdulos adicionales. Cada mdulo agrupa un conjunto de funcionalidades y
directivas para configurarlas. El nmero de mdulos y sus funcionalidades son muy amplias pudindose
consultar en http://httpd.apache.org/docs/2.2/es/mod.
Existen dos tipos de mdulos: estticos (se aaden cuando se compila Apache) y dinmicos (se cargan
de forma dinmica cuando se inicia el servidor).
Para conocer cules son los mdulos estticos cargados se usa la orden:
$ apache2ctl -l
Los mdulos dinmicos se cargan con la directiva LoadModule; y mediante la directiva <IfModule
se permite especificar directivas que se tendrn en cuenta slo si el mdulo indicado est
cargado.
nombremodulo>
Para comprobar cuales son los mdulos que se han cargado dinmicamente al arrancar el servidor,
slo debemos mirar el contenido del directorio /etc/apache2/mods-enabled. Estos archivos son enlaces
simblicos a archivos .load y .conf del directorio /etc/apache2/mods-available.
Por ejemplo, el archivo alias.load contiene la directiva
LoadModule alias_module /usr/lib/apache2/modules/mod_alias.so
que indica cul y dnde est el mdulo con el cdigo a cargar.

El archivo alias.conf contiene la directiva <IfModule alias_module> la cual incluye las directivas que se
ejecutarn si se carga dicho mdulo.
Para deshabilitar un mdulo, es decir, borrar el enlace simblico del directorio mods-enabled se usa el
comando a2dismod de la forma
$ sudo a2dismod nombre_modulo
Y para habilitar un mdulo, mediante el comando a2enmod.

$ sudo a2enmod nombre_modulo
En el directorio /usr/lib/apache2/modules se pueden ver los mdulos disponibles para carga.

Mediante el siguiente comando
$ sudo apt-cache search libapache2-mod
podemos mostrar los paquetes disponibles en los repositorios de Ubuntu que permiten instalar
mdulos adicionales para Apache.
11.5.1. Mdulo userdir.
La activacin del mdulo userdir permite que cualquier usuario cree su propio sitio web en un
directorio dentro de su home. Si editamos el archivo /etc/apache2/mods-available/userdir.conf podemos
observar que en la configuracin por defecto del mdulo se habilita el uso de directorios personales
(excepto para root) y que public_html es el nombre del directorio que pueden crear los usuarios en su home
para poner sus pginas personales (pudiera ser otro directorio).
Para comprobar el uso de directorios personales en el servidor virtual por defecto, deberamos
primeramente habilitar el mdulo:
$ sudo a2enmod userdir
A continuacin se puede crear el directorio /home/manolo/public_html y colocar en l una pgina

El acceso a la pgina sera:
index.html.
http://localhost/~manolo
Si queremos, se puede establecer un alias para evitar el smbolo ~ en la URL de acceso. Para ello en el
archivo /etc/apache2/mods-available/alias.conf le aadimos el alias de la forma
Alias /manolo/ "/home/manolo/public_html/"
De esta forma podramos usar directamente http://localhost/manolo
23
11.6. Control de acceso por direcciones IP y nombres de dominio.

Se puede definir desde qu direcciones IP y/o nombres de dominios se puede acceder a un servidor
web a travs de las directivas Order, Allow y Deny.
Cuando se realiza una conexin, el servidor comprueba si el acceso al recurso est autorizado, y si no
lo est, devuelve un cdigo de error del tipo 403 Forbbiden.
Allow permite especificar quin tendr autorizacin para acceder a un recurso. Se pueden especificar
direcciones IP, nombres de mquina, fragmentos del nombre o de direccin. Existe la palabra clave "all"
que indica todos los clientes.
Deny
indica a quin no le permitiremos el acceso a un recurso y usa las mismas opciones que Allow.
Order
permite afinar el funcionamiento de las anteriores directivas. Existen 2 opciones:
Order allow,deny. Por defecto se deniega el acceso y slo podrn acceder aquellos clientes que
cumplan las especificaciones de allow y no cumplan las especificaciones de deny.
Order deny,allow. Por defecto se permite el acceso y slo podrn acceder los clientes que no
cumplan las especificaciones de deny o s cumplan las especificaciones de allow.
Por ejemplo, para poder acceder al sitio web slo desde el equipo local y desde el equipo
escribiramos en el archivo de configuracin:
192.168.109.212,
Order allow,deny
Allow from 127.0.0.1 localhost
Allow from 192.168.210.212
11.7. Configuracin de servidores virtuales.

Apache permite servir varios sitios web mediante un nico software servidor. Se pueden crear
diferentes dominios virtuales por IP, nombre y puerto. Apache fue de los primeros servidores que soport
servidores virtuales sin necesidad de distinguir por IP, sino en funcin de nombre. Esta capacidad
simplifica enormemente la administracin de los servidores, y supone un ahorro de direcciones IP.
Los servidores virtuales que se distinguen por nombre son perfectamente transparentes para el cliente,
con la excepcin de aquellos navegadores antiguos que no enven la cabecera "host:" con cada peticin.
Aunque no es necesario, es conveniente por simplicidad en la configuracin de los servidores
virtuales, usar archivos de configuracin independientes para cada uno de ellos. Por ejemplo, si queremos
configurar dos servidores virtuales por nombre asir.aula.izv y bd.aula.izv crearamos dos archivos de
configuracin (asir-web y bd-web) en el directorio /etc/apache2/sites-available.
Para habilitar un servidor virtual es necesario crear un enlace en /etc/apache2/sites-enabled al archivo
creado previamente en /etc/apache2/sites-available/. Esta operacin se realiza mediante la orden a2ensite.
Por ejemplo, las rdenes:
/etc/apache2/sites-available$ sudo a2ensite asir-web
/etc/apache2/sites-available$ sudo a2ensite bd-web
habilitara los servidores cuyos archivos de configuracin se denominan asir-web y bd-web.

Los servidores virtuales se pueden deshabilitar rompiendo el enlace existente mediante la orden
a2dissite archivo_configuracion
11.7.1. Servidores virtuales por nombre.

Para atender a varios servidores virtuales por nombre utilizando una misma direccin IP para todos
ellos, debe estar habilitada la directiva NameVirtualHost. (Recordar que en la configuracin por defecto de
Apache, en el archivo /etc/apache2/ports.conf ya existe la directiva NameVirtualHost *:80 indicando que los
servidores virtuales por nombre estn habilitados en todas las direcciones IP por el puerto 80.)
Posteriormente con la directiva <VirtualHost>, definimos cada uno de los servidores virtuales.
Por ejemplo si queremos configurar dos servidores virtuales por nombre asir.aula.izv y bd.aula.izv
crearamos los dos archivos de configuracin siguientes:

# Archivo /etc/apache2/sites-available/asir-web
<VirtualHost *:80>
ServerName asir.aula.izv
DocumentRoot /var/www/asir
<Directory /var/www/asir>
AllowOverride None
Order allow,deny
Allow from all
</Directory>
ErrorLog ${APACHE_LOG_DIR}/asir.error.log
LogLevel warn
CustomLog ${APACHE_LOG_DIR}/asir.access.log combined
</VirtualHost>
Para usar la variable de entorno APACHE_LOG_DIR debemos comprobar si est definida. Si no lo

estuviera, deberamos editar el archivo /etc/apache2/envvars y definirla mediante:
export APACHE_LOG_DIR=/var/log/apache2
# Archivo /etc/apache2/sites-available/bd-web
<VirtualHost *:80>
ServerName bd.aula.izv
DocumentRoot /var/www/bd
<Directory /var/www/bd>
AllowOverride None
Order allow,deny
Allow from all
</Directory>
ErrorLog ${APACHE_LOG_DIR}/bd.error.log
LogLevel warn
CustomLog ${APACHE_LOG_DIR}/bd.access.log combined
</VirtualHost>
El ejemplo define dos servidores web, cada uno de ellos con un nombre diferente establecido
mediante la directiva ServerName y con su propio directorio raz indicado en DocumentRoot. Adems cada
uno de ellos dispone sus archivos de logs de errores y accesos.
Es muy comn usar la directiva ServerAlias hostname [hostname] ... para indicar otros nombres que se
pueden usar para acceder al sitio. Se pueden usar * y ? en hostname para establecer patrones de nombres.
Por supuesto debe haber un servidor DNS que asocie los nombres de dominio asir.aula.izv y bd.aula.izv a
la misma direccin IP del servidor.
Por otro lado, en la directiva <VirtualHost> se puede utilizar una direccin IP concreta en lugar de *, lo
cual permite asignar, por ejemplo, un grupo de servidores virtuales por nombre a esta IP concreta, y otro
grupo de servidores virtuales por nombre a otra IP distinta.
11.7.2. Servidores virtuales por direccin IP.
Desde que los servidores web implementaron la posibilidad de usar servidores virtuales por nombre,
los servidores virtuales por direccin IP dejaron prcticamente de usarse. Los motivos principales son la
escasez de direcciones IP y la complejidad de tener que tener instaladas varias interfaces de red en el
servidor.
Si no tenemos como mnimo dos tarjetas de red instaladas en la mquina, cada una con su IP,
deberemos usar la nica tarjeta disponible configurndola mediante subinterfaces.
Una subinterfaz es una divisin de una interfaz fsica en mltiples interfaces lgicas. Por ejemplo, se
pueden configurar la interfaz eth0 y las subinterfaces eth0:0, eth0:1 eth0:2, etc. Para ello se necesita
editar el archivo /etc/network/interfaces y aadirle la configuracin de la subinterfaz:
25
# the loopback network interface

auto lo
iface lo inet loopback
# the primary network interface
auto eth0
iface eth0 inet static
address 192.168.210.212
netmask 255.255.255.0
gateway 192.168.210.254
broadcast 192.168.210.255
auto eth0:0
iface eth0:0 inet static
address 192.168.210.222
netmask 255.255.255.0
gateway 192.168.210.254
broadcast 192.168.210.255
Luego deberemos reiniciar el servicio de red:

$ /etc/init.d/networking restart
Para atender servidores virtuales por IP, en el archivo /etc/apache2/ports.conf deben estar habilitadas
tantas directivas NameVirtualHost IP:puerto como servidores por puerto. Posteriormente se usa la directiva
de configuracin <VirtualHotst IP:puerto> para definir una configuracin y direccin IP para cada uno de
los servidores virtuales.
Por ejemplo, para tener dos servidores virtuales por diferentes IP escuchando por el mismo puerto 80:
<VirtualHost 192.168.210.212:80>
</VirtualHost>
<VirtualHost 192.168.210.222:80>
</VirtualHost>
Por ltimo en el servidor DNS tendremos que asociar los nombres de dominio asir.aula.izv a la
direccin 192.168.210.212 y bd.aula.izv a la direccin 192.168.210.222, si queremos acceder a los servidores
por un nombre de dominio en vez de usar directamente sus IP.
11.7.3. Servidores virtuales por puerto.
Los servidores virtuales por puerto permiten configurarlos de forma que cada uno de ellos usa un
puerto diferente de escucha.
Para ello deberemos editar el archivo /etc/apache2/ports.conf he indicar los puertos de escucha de los
servidores. Por ejemplo:
NameVirtualHost 192.168.210.212:80
NameVirtualHost 192.168.210.212:555
Listen 80
Listen 555
Posteriormente se utiliza la directiva de configuracin <VirtualHotst IP:Puerto> para definir una

configuracin, direccin IP y puerto para cada uno de los servidores.
Por ejemplo, para tener dos servidores virtuales por la misma IP y diferentes puertos haramos:
<VirtualHost 192.168.210.212:80>
</VirtualHost>
<VirtualHost 192.168.210.212:555>
</VirtualHost>
Por ltimo en el servidor DNS tendremos que asociar los dos nombres de dominio asir.aula.izv y
a la misma direccin IP 192.168.210.212.
bd.aula.izv
11.8. Configuracin de un servidor virtual seguro (https).

Ya sabemos que para que un servidor pueda servir pginas seguras con el protocolo HTTPS, necesita
poseer un certificado de servidor.
11.8.1. Servidor virtual HTTPS por defecto.
Apache dispone de un servidor virtual seguro por defecto. Para usarlo deberemos realizar una serie
de tareas.
Primero deshabilitaremos todos los servidores virtuales creados anteriormente mediante el

comando a2dissite.
Aadiremos el mdulo que da soporte para SSL:

$ sudo a2enmod ssl
Consultamos el archivo /etc/apache2/ports.conf y comprobamos que si se habilita el mdulo ssl,

el servidor escuchar en el puerto 443. Podemos verificarlo con netstat ltn.
Comprobamos que en el directorio /etc/apache2/sites-availables existe el archivo default-ssl que

contiene la configuracin por defecto de un servidor HTTPS.
Habilitamos el servidor virtual ssl por defecto de Apache:

$ sudo a2ensite default-ssl
Reiniciamos el servidor para que tengan efecto los cambios.
Si editamos el archivo /etc/apache2/sites-availables/default-ssl podremos observar en su

configuracin cules son las directivas que habilitan SSL e indican el nombre del archivo que
contiene el certificado digital del servidor.
SSLEngine. Activa/desactiva el protocolo SSL/TLS en un servidor virtual. (Por defecto est
deshabilitado tanto para el servidor principal como para todos los servidores virtuales.)
SSLCertificateFile. Indica el nombre del archivo que contiene el certificado de servidor.
Como podemos comprobar, el servidor virtual seguro por defecto usa un certificado
autofirmado que se cre cuando se realiz la instalacin de Apache.
https://localhost.
El navegador nos presentar un mensaje de aviso diciendo que la conexin no es segura ya que
la identidad del servidor no puede ser verificada. Esto ya la sabemos, porque el certificado no
est emitido por una AC de confianza para el navegador (no tiene instalado su certificado raz).
Tendremos que aadir una excepcin y confirmarla para poder acceder al sitio web.
11.8.2. Servidores virtuales HTTPS.

Vamos a crear un servidor virtual seguro con nombre de dominio webseg.aula.izv. Necesitaremos
definir el servidor virtual y generar un certificado digital. En nuestro caso generaremos un certificado
autofirmado con OpenSSL.
Los pasos para crear un servidor virtual seguro son:
Instalar y configurar, si no lo est ya, el paquete OpenSSL.
Deshabilitar el servidor virtual ssl disponible por defecto

$ sudo a2dissite default-ssl
Aadir, si no lo est ya, el mdulo que da soporte para a SSL:

$ sudo a2enmod ssl
Crearemos el certificado autofirmado que guardaremos por ejemplo en /etc/apache2/ssl (crear

antes el subdirectorio ssl ) mediante la orden:
$ sudo make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /etc/apache2/ssl/cer-apache.pem
El archivo cer-apache.pem contendr el certificado del servidor y su clave pblica.
Nos aseguramos en /etc/apache2/ports.conf que se va a escuchar por el puerto 443 (directiva

Listen) cuando Apache cargue el mdulo ssl.
Creamos el directorio raz del servidor seguro (por ejemplo /var/www/websegura) y dentro un
archivo index.html con el contenido de la pgina principal.
27
Creamos en /etc/apache2/sites-available el archivo de configuracin del servidor, al cual le

llamaremos websegura, con el contenido siguiente:
# Archivo /etc/apache2/sites-available/websegura
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName webseg.aula.izv
DocumentRoot /var/www/websegura
<Directory /var/www/websegura>
SSLRequireSSL
AllowOverride None
Order allow,deny
Allow from all
</Directory>
ErrorLog ${APACHE_LOG_DIR}/websegura.error.log
LogLevel warn
CustomLog ${APACHE_LOG_DIR}/websegura.access.log combined
SSLEngine On
SSLCertificateFile /etc/apache2/ssl/cer-apache.pem
</VirtualHost>
</IfModule>
El significado de la directiva SSLRequireSSL es prohibir el acceso al directorio salvo que se use el

protocolo HTTPS.
Habilitamos el servidor web seguro y reiniciamos el servicio

$ sudo a2ensite websegura
$ sudo /etc/init.d/apache2 restart
Para poder resolver el nombre de dominio del servidor, se necesitar registrar dicho nombre de
dominio en el servidor DNS y reiniciar posteriormente el servicio DNS.
https://webseg.aula.izv.
Ya sabemos que el navegador nos presentar un mensaje de aviso diciendo que la conexin no
es segura ya que la identidad del servidor no puede ser verificada.

Sri - Tema 4 HTTP Rev 1.16

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Sri - Tema 4 HTTP Rev 1.16

Transféré par

Droits d'auteur :

Formats disponibles

Tema 4.

Servidores Web (HTTP)

Tema 4. Servidores Web. HTTP.

8. Protocolo seguros. ............................................................................... 10

9. Alojamiento virtual. ............................................................................ 13

10.4. Directorios virtuales. ..................................................................................... 15

11. Instalacin y configuracin de Apache en Linux. ............................ 17

11.4. Directorios virtuales. ..................................................................................... 21

IES Zaidn Vergeles de Granada. Departamento de Informtica.

Tema 4. Servidores Web (Web)

11.5. Configuracin modular. ................................................................................. 22

11.6. Control de acceso por direcciones IP y nombres de dominio........................ 23

11.8. Configuracin de un servidor virtual seguro (https). ..................................... 26

IES Zaidn Vergeles de Granada. Departamento de Informtica.

Tema 4. Servidores Web (HTTP)

Tema 4. Servidores Web (HTTP).

PHP (PHP Hypertext Pre-processor). Es un lenguaje de programacin de script que se ejecuta en el

JavaScript. Es un lenguaje de programacin interpretado que se ejecuta normalmente en el cliente

IES Zaidn Vergeles de Granada. Departamento de Informtica.

Tema 4. Servidores Web (Web)

Servidor: IP o nombre de dominio del servidor que contiene el recurso.

Recurso: el recurso a acceder. Si se omite se buscar un archivo ndice por defecto.

Parmetros y valores enviados al servidor.

4. Clientes web (navegadores o exploradores).

IES Zaidn Vergeles de Granada. Departamento de Informtica.

Tema 4. Servidores Web (HTTP)

Mediante la instalacin de complementos (plugins o add-ons) se permite ampliar la funcionalidad de

IES Zaidn Vergeles de Granada. Departamento de Informtica.

Tema 4. Servidores Web (Web)

El servidor devuelve la respuesta al cliente. Consiste en un cdigo de estado y el tipo de dato

Se cierra la conexin TCP/IP.

Realizada la conexin enviaramos el mensaje de peticin indicando el recurso y el protocolo a usar.

IES Zaidn Vergeles de Granada. Departamento de Informtica.

Tema 4. Servidores Web (HTTP)

7.1. Mensajes HTTP.

Los mensajes de peticin estn formados por tres partes:

Los mensajes de respuesta estn formados por tres partes:

La lnea inicial de respuesta (lnea de estado): informa de la versin HTTP usada,

Lneas de cabecera: conjunto de pares nombre/valor denominados cabeceras que describen

7.2. Mtodos de peticin.

IES Zaidn Vergeles de Granada. Departamento de Informtica.

Tema 4. Servidores Web (Web)

Mtodo OPTIONS. Permite solicitar al servidor informacin sobre qu mtodos de peticin

Mtodo PUT. Permite enviar recursos, generalmente archivos, al servidor.

Mtodo DELETE. Permite eliminar recursos del servidor.

Almacenamiento en cach. De las informaciones que almacena un servidor, algunas de ellas no

IES Zaidn Vergeles de Granada. Departamento de Informtica.

Tema 4. Servidores Web (HTTP)

7.4. Cdigos de estado y error.

7.5. Autentificacin y Seguridad.

IES Zaidn Vergeles de Granada. Departamento de Informtica.

10 Tema 4. Servidores Web (Web)

IES Zaidn Vergeles de Granada. Departamento de Informtica.

Tema 4. Servidores Web (HTTP)

8.1. Gestin de certificados en Windows 2003 Server.

IES Zaidn Vergeles de Granada. Departamento de Informtica.

12 Tema 4. Servidores Web (Web)

en este momento comenzar el proceso de instalacin de la entidad

8.2. Gestin de certificados en Linux.

deberemos configurarlo editando el archivo /etc/ssl/openssl.cnf. En dicho archivo nicamente vamos a

Informndonos de quin certifica, la validez del certificado, qu se certifica, la clave pblica y la

IES Zaidn Vergeles de Granada. Departamento de Informtica.

Tema 4. Servidores Web (HTTP)