Versi�n 2.0 del Servidor HTTP Apache
Este documento puede resumirse en la siguiente frase: no configure Apache de manera que el an�lisis sint�ctico de los ficheros de configuraci�n tenga que confiar en resoluciones DNS. Si Apache necesita de resoluciones DNS para analizar los ficheros de configuraci�n, entonces su servidor puede no funcionar correctamente (por ejemplo, podr�a no iniciarse), o sufrir ataques de denegaci�n o robo de servicio (incluyendo que otas web puedan "robar" peticiones de otras web).
<VirtualHost www.abc.dom>
ServerAdmin [email protected]
DocumentRoot /www/abc
</VirtualHost>
Para que Apache funcione correctamente, es imprescindible
conocer dos aspectos sobre cada host virtual: el valor de la
directiva ServerName
y al
menos una direcci�n IP en la que servidor escuchar� y
responder� a las peticiones que se produzcan. El ejemplo
mostrado arriba no incluye la direccion IP, de manera que Apache
tiene que usar una resoluci�n DNS para encontrar la
direcci�n IP correspondiente a www.abc.dom
. Si
por alguna raz�n la resoluci�n DNS no est�
disponible en el momento en que su servidor est� analizando
sint�nticamente su fichero de configuraci�n, entonces
este host virtual no se configurar� y no
ser� capaz de responder a ninguna de las peticiones que se
hagan a ese host virtual (en las versiones de Apache anteriores a
la 1.2 el servidor ni siquiera se iniciaba).
Suponga que www.abc.dom
tiene como direcci�n
IP la 10.0.0.1. Considere la siguiente configuraci�n:
<VirtualHost 10.0.0.1>
ServerAdmin [email protected]
DocumentRoot /www/abc
</VirtualHost>
Ahora Apache necesita hacer una b�squeda DNS inversa para
encontrar el ServerName
de este host virtual. Si esta
b�squeda inversa falla entonces el host virtual se
desactivar� parcialmente (en las versiones de Apache
anteriores a la 1.2 el servidor ni siquiera se iniciaba). Si el
host virtual est� basado en el nombre, entonces se
desactivar� completamente, pero si est� basado en la
direcci�n IP, entonces funcionar� para la mayor parte de
las cosas. Sin embargo, si Apache tiene que generar en alg�n
momento una URL completa que incluya el nombre del servidor, no
ser� capaz de generar una URL v�lida.
Aqu� tiene una forma de evitar ambos problemas:
<VirtualHost 10.0.0.1>
ServerName www.abc.dom
ServerAdmin [email protected]
DocumentRoot /www/abc
</VirtualHost>
Hay (al menos) dos formas de que ocurra una denegaci�n de
servicio. Si est� ejecutando una versi�n de Apache
anterior a la 1.2, entonces su servidor no se iniciar� si una
de las dos b�squedas de DNS mencionadas arriba falla para
cualquiera de sus hosts virtuales. En algunos casos estas
b�squedas DNS puede que no est�n bajo su control; por
ejemplo, si abc.dom
es uno de sus clientes y ellos
controlan su propia DNS, pueden forzar a su servidor (pre-1.2) a
fallar al iniciarse simplemente borrando el registro
www.abc.dom
.
Otra formas pueden ser bastante m�s complicadas. F�jese en esta configuraci�n:
<VirtualHost www.abc.dom>
ServerAdmin [email protected]
DocumentRoot /www/abc
</VirtualHost>
<VirtualHost www.def.com>
ServerAdmin [email protected]
DocumentRoot /www/def
</VirtualHost>
Suponga que ha asignado la direcci�n 10.0.0.1 a
www.abc.dom
y 10.0.0.2 a
www.def.com
. Todav�a m�s, suponga que
def.com
tiene el control de sus propias DNS. Con esta
configuraci�n ha puesto def.com
en una
posici�n en la que puede robar todo el trafico destinado a
abc.dom
. Para conseguirlo, todo lo que tiene que
hacer es asignarle a www.def.com
la direcci�n
10.0.0.1. Como ellos controlan sus propias DNS no puede evitar que
apunten el registro www.def.com
a donde quieran.
Las peticiones dirigidas a la direcci�n 10.0.0.1
(inclu�das aquellas en las los usuarios escriben URLs de tipo
http://www.abc.dom/whatever
) ser�n todas
servidas por el host virtual def.com
. Comprender por
qu� ocurre esto requiere una discusi�n m�s profunda
acerca de como Apache asigna las peticiones que recibe a los hosts
virtuales que las servir�n. Puede consultar aqu� un documento que trata el
tema.
El que Apache soporte hosting
virtual basado en nombres desde la version 1.1 hace que sea
necesario que el servidor conozca la direcci�n (o
direcciones) IP del host que httpd
est�
ejecutando. Para tener acceso a esta direcci�n puede usar la
directiva global ServerName
(si est� presente) o llamar a la funci�n de C
gethostname
(la cu�l debe devolver el mismo
resultado que devuelve ejecutar por l�nea de comandos
"hostname"). Entonces se produce una b�squeda DNS de esa
direcci�n. Actualmente, no hay forma de evitar que se
produzca esta b�squeda.
Si teme que esta b�squeda pueda fallar porque su servidor
DNS est� desactivado entonces puede insertar el nombre de
host en /etc/hosts
(donde probablemente ya lo tiene
para que la m�quina pueda arrancar
correctamente). Aseg�rese de que su m�quina est�
configurada para usar /etc/hosts
en caso de que esa
b�squeda DNS falle. En funci�n del sistema operativo que
use, puede conseguir esto editando /etc/resolv.conf
,
o puede que /etc/nsswitch.conf
.
Si su servidor no tiene que ejecutar b�squedas DNS por
ninguna otra raz�n entonces considere ejecutar Apache
especificando el valor "local" en la variable de entorno
HOSTRESORDER
. Todo esto depende del sistema operativo
y de las librer�as de resoluci�n que use. Esto
tambi�n afecta a los CGIs a menos que use
mod_env
para controlar el entorno. Por favor,
consulte las p�ginas de ayuda o la secci�n de Preguntas
M�s Frecuentes de su sistema operativo.
VirtualHost
Listen
ServerName
<VirtualHost _default_:*>
que no tenga p�ginas que servir.La situaci�n actual respecto a las b�squedas DNS est� lejos de ser la deseable. En Apache 1.2 se intent� hacer que el servidor al menos se iniciara a pesar de que fallara la b�squeda DNS, pero puede que esa no sea la mejor soluci�n. En cualquier caso, requerir el uso de direcciones IP expl�citas en los ficheros de configuraci�n no es ni mucho menos una soluci�n deseable con la situaci�n actual de Internet, donde la renumeraci�n es una necesidad.
Una posible soluci�n a los ataques de robo de servicio descritos m�s arriba, ser�a hacer una b�squeda DNS inversa de la direcci�n IP devuelta por la b�squeda previa y comparar los dos nombres -- en caso de que sean diferentes, el host virtual se desactivar�a. Esto requerir�a configurar correctamente DNS inverso (una tarea con la que suelen estar familiarizados la mayor�a de los administradores de sistemas).
En cualquier caso, no parece posible iniciar en las condiciones apropiadas un servidor web alojado virtualmente cuando DNS ha fallado a no ser que se usen direcciones IP. Soluciones parciales tales como desactivar partes de la configuraci�n podr�an ser incluso peores que no iniciar el servidor en absoluto, dependiendo de las funciones que se espera que realice el servidor web.
Como HTTP/1.1 est� ampliamente extendido y los navegadores
y los servidores proxy empiezan a usar la cabecera
Host
, en el futuro ser� posible evitar el uso de
hosting virtual basado en direcciones IP completamente. En ese
caso, un servidor web no tiene ninguna necesidad de hacer
b�squedas de DNS durante la configuraci�n. Sin embargo,
en Marzo de 1997 esas funcionalidades no estaban lo
suficientemente implantadas como para ponerlas en uso en
servidores web que realizaban tareas de importancia
cr�tica.