Академический Документы
Профессиональный Документы
Культура Документы
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:
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.
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.
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.
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.
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 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.
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 HEAD. Es como una peticin GET, pero recuperando slo las cabeceras.
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.
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.
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.
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.
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.
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).
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
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.
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.
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.
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
2.
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.
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.
17
6.
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
localhost
ubup.aula.izv ubup
Adems,como suele suceder en la mayora de los servicios, el equipo servidor deber tener una IP fija.
/etc/apache2/apache2.conf.
/etc/apache2/envars.
/etc/apache2/conf.d.
19
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.
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.
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
Options Indexes FollowSymLinks MultiViews
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>
ErrorLog
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.
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.
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.
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
Options Indexes FollowSymLinks MultiViews
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
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
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
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/"
23
indica a quin no le permitiremos el acceso a un recurso y usa las mismas opciones que Allow.
Order
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
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
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:
# Archivo /etc/apache2/sites-available/asir-web
<VirtualHost 192.168.210.212:80>
</VirtualHost>
# Archivo /etc/apache2/sites-available/bd-web
<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
</VirtualHost>
# Archivo /etc/apache2/sites-available/bd-web
<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
Para probar el servidor debemos usar el protocolo HTTPS en la URL del navegador de la forma
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.
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
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.
Para probar el servidor debemos usar el protocolo HTTPS en la URL del navegador de la forma
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.