El tráfico WWW es uno de los mayores componentes del uso de Internet hoy en día. Existen una variedad de servidores WWW bastantes populares para Linux, siendo el más famoso el Apache (con más del 50% del mercado). La mayoría de los servidores WWW también tienen la capacidad de utilizar SSL para asegurar las sesiones (para comercio electrónico, etc.). Esta sección se centra en Apache, pero tiene sentido, dado que es el servidor por defecto para casi todas las distribuciones Linux (y *BSD). También estoy escribiendo para la versión 1.3.9 de Apache, que ya no utiliza el fichero access.conf o srm.conf, sino que en su lugar lo ha cambiado por el httpd.conf.

Apache

¿Qué puedo decir acerca de asegurar Apache? En realidad no demasiado. Por defecto Apache se ejecuta como el usuario ‘nobody’, lo cual le da muy poco acceso al sistema, y por lo general el equipo Apache ha hecho un buen trabajo evitando desbordamientos de pila/etc. En general, la mayoría de los servidores www simplemente toman datos del sistema y los envían fuera, los mayores peligros no vienen del Apache sino de programas descuidados que se ejecutan vía Apache (CGI’s, server side includes, etc.).

Si se va a ejecutar Apache, recomendaría utilizar la serie 1.3, a menos que se tengan algún tipo de extraños requerimientos para ceñirse a la 1.2, la versión de desarrollo activa es la 1.3, e incluye muchas características nuevas desde el punto de vista de la seguridad, estabilidad y el rendimiento. La mayoría de los servidores basados en Apache (Red Hat Secure Server, Stronghold, etc.) suelen, en general, estar libres de bugs, pero ocasionalmente se dan problemas.

Hacer chroot del Apache

Si se quiere ser paranoico, sugeriría ejecutar Apache en un entorno de chroot, aunque a veces esto puede dar más problemas de lo que merece la pena. Hacer esto estropeará muchas cosas. También es preciso instalar numerosas bibliotecas, perl y cualquier otra utilidad que vaya a utilizar el Apache, así como cualquier fichero de configuración al que se quiera tener acceso. Cualquier script CGI y otras cosas que interactúen con el sistema serán algo problemáticas y en general, más difíciles de reparar.

La forma más simple de configurar el Apache con chroot es instalarlo y mover/editar los ficheros necesarios. Una buena idea es crear un directorio (como /chroot/apache/), preferiblemente en un sistema de ficheros separado de /, /usr, /etc (enlaces simbólicos, llenado accidental de particiones, etc...) y después crear para el Apache una estructura de ficheros por debajo. Lo siguiente es un ejemplo, simplemente reemplaza /chroot/apache/ por algo de tu elección. Por supuesto que hay que ejecutar estos pasos como root para que funcione. RPM lo soporta mediante la directiva "—root /cualquier/directorio", simplemente hay que instalar Apache y las bibliotecas necesarias utilizando rpm (y de paso ganando soporte de dependecias/etc, haciéndote la vida más fácil). Si no se está en un sistema basado en RPM, simplemente hay que utilizar ldd para encontrar las librerías compartidas que se necesitan, y mover todo lo que se necesite al directorio /chroot/apache

Las peticiones de logs de Apache se hacen internamente, de modo que no hay porqué preocuparse de instalar pseudo-demonios para hacer logging, como holelogd, para que pasen esta información al syslog.

Configuración de Apache

En cuanto a la forma más simple de asegurar Apache y asegurarse de que no tiene acceso innecesario al sistema de ficheros es crear un directorio /www/ o algo similar, y situar por ahí debajo TODOS los sitios web, contenido web, cgi’s, etc. Después sólo es necesario configurar access.conf para que deniegue el acceso a / , y se lo permita a /www/ y sus varios directorios cgi-bin.

Ejemplo de httpd.conf:

Control de Accesos

El acceso a los directorios también se puede controlar con facilidad, el Apache soporta la definición y localización de ficheros (generalmente conocidos como ficheros htaccess) que controlan el acceso basado en nombre de usuario y contraseña, IP de origen, etc. Esto se define en srm.conf:

El formato del este fichero viene desarrollado en la documentación del Apache, y es idéntico a directivas que se colocarían en access.conf (bueno, casi). La autentificación de usuario vía nombre de usuario y contraseña también vien desarrollada en profundidad en http://www.apacheweek.com/features/userauth/

También querrás evitar que la gente vea los ficheros .htaccess, coloca esto en tu srm.conf:

Conseguir Apache

Se puede descargar Apache desde http://www.Apache.org/, y se puede descargar Apache-SSL desde http://www.apache-ssl.org/, de modo que también se necesitará software OpenSSL, disponible desde: http://www.openssl.org. Ten en cuenta que el uso de Apache-SSL es ilegal en USA debido a las patentes que mantiene sobre RSA. El servidor comercial de Apache-SSL más barato es el Red Hat Secure Server, a 100$ USA.

Apache con extensiones SSL

Existen diferentes alternativas gratuitas al Apache con SSL, y varias comerciales. Si se está en los EE.UU., el RSA está patentado, así que hay que utilizar o bien DSA (para el cual es difícil conseguir certificados) o comprar un servidor comercial basado en Apache (como Stronghold). Si se está en Europa, se puede vivir en un país donde el IDEA esté patentado, de modo que asegúrate primero.

Apache-SSL

Es el que uso actualmente (sencillamente porque lo probé antes que Apache con mod_ssl y funcionó). Tienes que conseguir Open-SSL, compilarlo e instalarlo, y después parchear Apache con el parche Apache SSL, compilar Apache, y ya está. El Open-SSL se encuentra disponible en: http://www.openssl.org/, tan sólo hay que conseguir el último tarball, desempaquetarlo y ejecutar:

A mi me ha funcionado siempre. Hay que conseguir el material de Apache-SSL de http://www.apache-ssl.org, desempaquetar el código fuente del Apache en algún lugar, hacer un cd al directorio de nivel superior (/usr/local/src/apache_1.3.9/) y después desempaquetar el material de Apache-SSL dentro (te dice que hagas eso en los docs). Después sólo hay que ejecutar:

Lo cual debería funcionar (si no funciona, lee el README.SSL), después configura el Apache como siempre, y ejecuta make seguido de make install. Sáltate hasta la sección "Crear un certificado".

Apache con mod_ssl

El Apache con mod_ssl se encuentra disponible en http://www.modssl.org Todavía no lo he probado.

Crear un certificado

Esta es la parte fácil, el siguiente paso es crear el conjunto de llaves, y después configurar el httpd.conf para utilizarlo correctamente. Busca dónde está instalado el "openssl" y asegúrate de que está en el path, después haz un cd allí donde quiera que tengas ubicados tus ficheros de configuración del Apache (cualquiera que fuese el prefijo como el raíz de Apache seguido de /conf). Si se necesita crear un certificado de prueba, para uso interno, se puede hacer:

Los navegadores se quejan sobre este certificado, puesto que está creado por la persona que lo firma, y no son fiables. Si quieres generar un certificado, y una petición de certificado para enviar a alguien como Thawte o Verisign, entonces hay que hacer:

También se pueden conseguir certificados reales con un tiempo de vida limitado (generalmente de una o dos semanas) de Verisign, para utilizarlos en un entorno más real.

Se necesitan añadir varias cosas al fichero de configuración de Apache para conseguir que el Apache con extensiones SSL haga algo útil con tus certificados. Habrá que añadir algunas configuraciones globales (ten en cuenta que esto se refiere a la 1.3.9, y que no funcionará con versiones más antiguas de Apache):

Ahora puedes crear un host virtual con SSL habilitado:

<VirtualHost www.example.com:443>

ServerName www.example.com

ServerAdmin example@example.com

Filtrado con el cortafuegos del HTTP / HTTPS

El HTTP se ejecuta en el puerto 80, con tcp, y si es sólo para uso interno (una Intranet, o un mecanismo de control basado en www, para, digamos, un servidor cortafuegos) definitivamente habría que filtrarlo con el cortafuegos.

o en ipchains:

El HTTPS se ejecuta en el puerto 443, con tcp, y si sólo es para uso interno también debería filtrarse con el cortafuegos:

o en ipchains:

Añadidos al Apache

apache-userdirldap

El apache-userdirldap te permite utilizar el directorio LDAP para buscar en los directorios de los usuarios. En otras palabras, si se quiere mover todos los usuarios a un directorio LDAP y hacer toda la autentificación a través de él, no habrá que romper el Apache. Se puede conseguir en: http://horde.net/~jwm/software/apache-userdirldap/

Servidores WWW alternativos

Red Hat Secure Server

Red Hat Secure Server es un producto basado en Apache de (adivina quien) software Red Hat. En esencia es un Apache de fábrica con módulos de cifrado RSA (que es por lo que en realidad estás pagando) y también puede servir peticiones de http standard sin cifrado. Sólo se puede vender en USA y en Canadá, y es la mejor opción (en mi opinión) en cuanto a servidores www seguros que sean de uso legal en US (debido a las patentes RSA). En cuanto a la seguridad, lee la sección anterior sobre Apache / Apache-SSL, todo es aplicable. Red Hat Secure Server cuesta 100$ USA y se consigue un descuento de 25$ en el sitio de certificación Thawte (de modo que el certificado de sitio sólo cuesta 100$). Personalmente me gusta bastante, pues está basado en un software que se ejecuta en más de la mitad de los sitios www del mundo, y como tal es fácil conseguir soporte/actualizaciones/etc. Red Hat Secure Server se puede comprar en: http://store.Redhat.com/commerce/

Roxen es otro servidor comercial de www capaz de hacer https y tiene licencia GPL. Se puede descargar gratuitamente si se está en la Unión Europea o en Australia, Canadá, Japón, Nueva Zelanda, EE.UU. o Suiza. Se puede descargar una versión con criptografía "débil" (40 bits) sin ningún problema y desde cualquier país. Roxen es un producto extremadamente sólido y está disponible en: http://www.roxen.com

Ya lo sé, parece extraño pero es cierto. El AOL es un servidor www gratuito, con código fuente disponible. No sólo eso, sino que soporta SSL y otras características avanzadas. Definitivamente merece ser tenido en cuenta. Se puede conseguir en: http://aolserver.com/

Hay más trabajo en asegurar tu servidor www que instalar el Apache y configurarlo correctamente. La mayoría de los servidores necesitan permitir acceso a sus sistemas de ficheros, de forma que los usuarios puedan subir y modificar ficheros del servidor. Para ello existen 4 métodos que lo cubren en detalle:

Webfs es un servidor ligero de www que implementa funcionalidad básica y se encuentra disponible en: http://www.in-berlin.de/User/kraxel/webfs.html

Un servidor www ligero y rápido, se puede conseguir en: http://www.cs.rice.edu/~vivek/flash/

Acceso a los ficheros del servidor WWW

En algún momento habrá que acceder a los ficheros del servidor para actualizarlos. Hacer un logging y utilizar un editor de texto como el emacs no suele ser una sabia decisión a largo plazo, si valoras tu tiempo. Hay varios paquetes de autoría de HTML que pueden acceder al website vía FTP o compartición de ficheros de Windows.

Este es el método clásico de garantizar acceso a los usuarios a los servidores ftp, las preocupaciones habituales incluyen que los usuarios puedan verse sus ficheros entre sí, que vean ficheros del sistema que no deberían, etcétera. Hacer un chroot de las sesiones de los usuarios resolverá la mayoría de estos problemas, sin embargo el principal problema que existe con el FTP es que cifrar el nombre de usuario y la contraseña no suele ser posible debido al hecho de que la mayoría de la gente está utilizando clientes FTP de Windows. Recomendaría el ProFTPD antes que el WU-FTPD para una aplicación de este tipo, el ProFTPD tiene mejores controles de acceso.

El Samba es bastante útil para compartir directorios www con clientes Windows, se pueden mantener los nombres de usuarios y contraseñas separados del sistema (utilizando smbpasswd en vez del passwd del sistema) y el cifrado de logins no es ningún problema. Simplemente hay que hacer los directorios compartidos no visibles, y utilizar la directiva "valid users" para restringir qué usuarios pueden ver los datos compartidos. Por ejemplo:

configurará un directorio compartido bastante seguro del directorio "/www/www.example.org/" al que sólo podrá acceder el usuario "example".

El FrontPage es uno de los programas más famosos para edición de HTML entre los usuarios de Windows (qué caramba, incluso yo lo utilizo). Puede comunicarse directamente con los servidores WWW y descargar / subir ficheros de un sitio (llamado el "sitio Frontpage") si el servidor soporta extensiones FrontPage. Las extensiones FrontPage se encuentran disponibles para diferentes plataformas UNIX, gratuitamente, en Ready To Run Software: http://www.rtr.com En el pasado, las extensiones FrontPage de RTR para UNIX han sido un tanto desastrosas. Sin embargo existen alternativas comerciales, una es el Instant ASP, disponible en: http://www.halcyonsoft.com

El RearSite es un programa cgi que proporciona a los usuarios acceso a sus directorios vía un navegador normal. Se puede conseguir en: http://listes.cru.fr/rs/fd

Fast Webpage Exchanger

El Fast Webpage Exchanger mantiene sincronizados los ficheros utilizando un interesante fichero de configuración en el que se especifica todo. Se puede descargar desde: http://www.enjoy.ne.jp/~gm/program/iew_en.html

Volver