Servidores WWW

Hoy en día las conexiones a servidores web son sin duda las más extendidas entre usuarios de Internet, hasta el punto de que muchas personas piensan que este servicio (HTTP, puerto 80 TCP) es el único que existe en la red - junto al IRC -. Lo que en un principio se diseñó para que unos cuantos físicos intercambiaran y consultaran artículos fácilmente, en la actualidad mueve a diario millones de dólares y es uno de los pilares fundamentales de cualquier empresa: es por tanto un objetivo muy atractivo para cualquier pirata.

Los problemas de seguridad relacionados con el protocolo HTTP se dividen en tres grandes grupos en función de los datos a los que pueden afectar ([GS97]):

Seguridad en el servidor.
Es necesario garantizar que la información almacenada en la máquina servidora no pueda ser modificada sin autorización, que permanezca disponible y que sólo pueda ser accedida por los usuarios a los que les esté legítimamente permitido.
Seguridad en la red.
Cuando un usuario conecta a un servidor web se produce un intercambio de información entre ambos; es vital garantizar que los datos que recibe el cliente desde el servidor sean los mismos que se están enviando (esto es, que no sufran modificaciones de terceros), y también garantizar que la información que el usuario envía hacia el servidor no sea capturada, destruida o modificada por un atacante. Esto es especialmente importante si la información en tránsito es secreta, como en el caso de los passwords que el usuario teclea para autenticarse en el servidor, o en el comercio electrónico y el intercambio de números de tarjetas de crédito.
Seguridad en el cliente.
Por último es necesario garantizar al usuario que lo que descarga de un servidor no va a perjudicar a la seguridad de su equipo; sin llegar a extremos de applets maliciosos o programas con virus, si simplemente el navegador del usuario `se cuelga' al acceder al visitar las páginas de una organización, seguramente esa persona dejará de visitarlas, con la consecuente pérdida de imagen - y posiblemente de un futuro cliente - para esa entidad.

Asegurar el servidor implica - aparte de las medidas habituales para cualquier máquina Unix - medidas excepcionales dedicadas al demonio servidor de web y su entorno de trabajo; estas medidas son propias para cada programa servidor, por lo que aquí no entraremos en detalles concretos sobre cada uno de ellos. No obstante, y sea cual sea el servidor utilizado (Apache, NCSA, Netscape...), es necesario seguir un consejo básico: minimizar el número de usuarios en la máquina y minimizar el número de servicios ofrecidos en ella; aunque lo normal es que una máquina dedicada a cualquier tarea con decenas - o con miles - de usuarios sea también el servidor web, es recomendable que dicho servidor sea un equipo dedicado a esa tarea.

Los problemas relacionados con servidores web suelen proceder de errores de programación en los CGIs ubicados en el servidor. Un CGI (Common Gateway Interface) es un código capaz de comunicarse con aplicaciones del servidor, de forma que desde una página se invoque a dichas aplicaciones pasándoles argumentos y el resultado se muestre en el navegador de un cliente; cuando rellenamos un formulario, vemos una imagen sensible, o simplemente incrementamos el contador de cierta página, estamos utilizando CGIs. Esta capacidad del CGI para comunicarse con el resto del sistema que alberga las páginas es lo que le otorga su potencia, pero también lo que causa mayores problemas de seguridad: un fallo en estos programas suele permitir a cualquier visitante de las páginas ejecutar órdenes en el sistema. Los errores más habituales en un CGI provienen de los datos recibidos desde el navegador del cliente: un simple formulario, en el que el visitante rellena ciertos campos, puede ser una puerta de acceso a nuestro sistema; es necesario comprobar la validez de todos y cada uno de los datos leídos antes de que sean procesados. Por ejemplo, imaginemos un CGI que pida un nombre de usuario por teclado y a continuación ejecute un finger contra ese nombre de usuario y muestre el resultado en el navegador; >que sucedería si el visitante introduce como nombre de usuario `toni;cat /etc/passwd'? Es posible que se ejecute el finger a toni, pero a continuación se vuelque el fichero de contraseñas simplemente porque no se ha tenido la precaución de ignorar los caracteres especiales para el shell (recordemos que un `;' en Unix separa varias órdenes en una misma línea); este ejemplo, que hoy en día parece absurdo, ha estado presente en algunos servidores durante mucho tiempo. Cualquier CGI es susceptible de presentar problemas de seguridad sin importar el lenguaje en que se haya escrito ([Gun96]); por tanto, es muy importante preocuparse de mantener actualizado el árbol de CGIs (no copiarlo completamente al actualizar la versión de demonio), e incluso revisar los programas más importantes en busca de posibles bugs. Otra medida de seguridad básica es ejecutar el demonio servidor bajo la identidad de un usuario con privilegios mínimos para que todo funcione correctamente, pero nunca como root; generalmente, el usuario nobody suele ser más que suficiente: recordemos que los CGIs se ejecutan bajo la identidad del usuario propietario del demonio, por lo que si ese propietario es el administrador un potencial atacante podría ejecutar cualquier aplicación como root del sistema.

Para garantizar la seguridad de los datos que circulan entre un cliente y el servidor es casi obligatorio cifrar dichos datos (otras medidas, como asegurar físicamente la red, suelen ser impracticables) mediante SSL (Secure Socket Layer), un protocolo desarrollado por Netscape Communications para cifrar información al enviarla por la red y descifrarla antes de ser utilizada en el cliente; en la actualidad, se está viendo relegado a un segundo plano a causa de los certificados digitales, aunque sigue siendo una excelente opción para administración remota y para transmitir información confidencial en redes de propósito general.

En último lugar es necesario hablar de la seguridad desde el punto de vista del cliente que visita páginas web; para el usuario, un servidor es seguro si protege la información que recibe y envía hacia él, manteniendo su privacidad, y si no conduce al usuario a descargar programas maliciosos - generalmente virus - en su equipo; si sucede lo contrario, la compañía responsable de las páginas se enfrenta a una importante pérdida de imagen - aparte de posibles problemas judiciales - de cara a sus usuarios: simplemente imaginemos que salta a los medios un fallo de seguridad en la versión electrónica de cierto banco; será difícil que todos sus usuarios sigan manteniendo la suficiente confianza en él como para guardar allí su dinero. También es necesario hablar de los applets hostiles - o simplemente de los mal diseñados - que en muchas ocasiones llegan a detener todas las copias del navegador en memoria; aunque sus implicaciones de seguridad no suelen ser muy graves, la pérdida de imagen de la compañía es también considerable en estos casos.

En muy pocas máquinas se pueden permitir el lujo de deshabilitar este servicio, ya que como hemos dicho es de los más utilizados actualmente; no obstante, por alguna extraña razón - personalmente no la llego a comprender - en algunos clones de Unix (por ejemplo, ciertas variantes de Linux) el servicio HTTP está activado por defecto aún a sabiendas de que muchos de los usuarios de este sistema van a utilizarlo en su casa o como estación de trabajo independiente, donde evidentemente no es habitual - ni necesario en la mayoría de ocasiones - ofrecerlo. Por supuesto, en estos casos es importante detener el demonio httpd y evitar que se vuelva a iniciar con el arranque de la máquina, modificando el script correspondiente. Siempre hemos de recordar que hemos de ofrecer sólo los servicios imprescindibles en cada sistema.