El modelo planteado por el enfoque tradicional funciona bien para redes pequeñas a medianas pero no es aplicable bajo ciertas condiciones, como alta conectividad, líneas de alta velocidad, extranets y otros.
Los firewalls distribuidos pueden tratar las limitaciones de los firewalls convencionales. Bajo este nuevo modelo, la política de seguridad es definida centralmente y distribuida para ser aplicada por cada sistema final de forma independiente.
De todas formas, los firewall convencionales son útiles para proveer alguna medida de seguridad ya que proveen mecanismos para aplicar políticas de seguridad de red. Son el único mecanismo de seguridad aplicable a sistemas "legacy" ya que éstos utilizan protocolos viejos y difíciles de proteger. Adicionalmente, muchos protocolos no poseen características que permitan implementar aspectos de seguridad. Para estos casos, los firewalls convencionales (de perímetro) proveen una barrera como primer medida de protección.
En esta parte se introducirán los aspectos más importantes en la implementación de una solución de firewalls distribuidos y algunas de las tecnologías disponibles para tal fin.
Para implementar un firewall distribuido se necesitan tres componentes:
- un lenguaje para expresar políticas y resolver consultas
- un mecanismo para distribuir de forma segura las políticas de seguridad
- un mecanismo que aplique la política de seguridad en los sistemas finales.
Lenguaje de políticas de seguridad
Existen diferentes tipos de lenguajes disponibles para la definición de políticas de seguridad, cada uno de diferente naturaleza, pero un requisito esencial es que debe ser lo suficientemente poderoso para expresar la política deseada.
Algunos han sido creados como parte de la investigación de grupos de desarrollo para ser utilizados por la comunidad libre de Internet. Estos, por lo general, son diseñados para adaptarse a muchos sistemas y plataformas, es decir tienen la característica de ser portables y abiertos. Permiten ser utilizados como herramienta de desarrollo de otros sistemas para obtener herramientas de amplio uso, ya que estos lenguajes utilizan o están basados sobre estándares reconocidos y de uso común por las aplicaciones basadas en Internet. Un punto en contra para estos lenguajes es que requieren un conocimiento especializado de ciertos aspectos y presentan una complejidad superior a otras soluciones para ser integrados a una solución firewall, pero se pueden obtener soluciones muy eficientes y robustas. Para este fin, existen recomendaciones y guías para el uso de estos lenguajes disponibles de forma abierta.
Por otro lado, muchos productos propietarios proveen sus propios lenguajes de definición de reglas de seguridad, que se encuentran altamente integrados a la solución ofrecida. Es común que estos productos dispongan de interfaces gráficas que facilitan al administrador de la red la especificación la una política integral mediante la interacción con abstracciones de alto nivel, como modelos, esquemas u otros medios, que luego pueden ser traducidos mediante un compilador (también provisto por el sistema) al conjunto de reglas que serán aplicadas en cada sistema final. Una desventaja de estos lenguajes, más allá de las facilidades que provee el sistema que lo contiene, es que no puede ser utilizado en cualquier ambiente o con cualquier otro sistema, y es posible que no pueda aplicarse a una determinada red por no disponer de los dispositivos necesarios para desplegar tal solución.
Una importante consideración para un lenguaje de especificación de políticas de seguridad es la extensibilidad, es decir que pueda funcionar correctamente para una diversidad de aplicaciones sin que deba cambiar su estructura, tanto sintáctica como semántica, más allá de la lógica que presente la aplicación.
Otro aspecto importante relacionado con la política de seguridad es la forma en que son identificados los hosts de la red. Los firewall tradicionales están basados en la topología de red, es por eso que las interfaces son designadas como “interna”, “externa”, “perimetral”, etc. En un firewall distribuido, esa noción no es aplicable ya que son independientes de la topología.
Un identificador de host común en modelos tradicionales es su dirección IP. De esta forma, una dirección específica puede ser confiable, capaz de realizar determinado tipo de comunicaciones. Pero el uso de direcciones IP para la identificación de hosts en firewalls distribuidos ofrece un nivel reducido de seguridad ya que de esta forma se mantiene la dependencia de la topología.
Es preferible, en este caso, el uso de algún esquema de identificación mediante certificados criptográficos que ofrece un identificador único más confiable. Los certificados son independientes de la topología y su propiedad no es fácilmente falsificable (gracias al uso de claves criptográficas). Si a una máquina se le conceden ciertos privilegios basándose en su certificado, esos privilegios pueden aplicarse sin importar dónde está situada físicamente la máquina. Además, dado que los derechos de acceso en un firewall distribuido están ligados al uso de certificados, pueden ser limitados cambiando el conjunto de certificados aceptados. Con el uso de certificados, cada paquete entrante puede ser asociado con un certificado; el acceso concedido a ese paquete es determinado por los derechos concedidos a ese certificado
En la sección de Regulación de Tráfico se presentaron tres alternativas para la especificación de políticas de seguridad: KeyNote, un sistema de administración de confianza que ofrece un lenguaje general de políticas y credenciales; Firmato, un kit de herramientas cuyo principal objetivo es la especificación de políticas de seguridad a un nivel superior de abstracción; y el lenguaje INSPECT, un lenguaje incluido como parte del producto FireWall-1 de la empresa Check Point. Éste último, a diferencia de los anteriores, que están disponibles a la comunidad abierta de Internet, es un lenguaje propietario y solo puede ser utilizado para dicho producto de software.
KeyNote
KeyNote es un sistema de administración de confianza. El enfoque de administración de confianza tiene un numero de ventajas sobre otros mecanismos para especificar y controlar autorizaciones, especialmente cuando la política de seguridad se encuentra distribuida sobre una red. En estos sistemas las políticas son fáciles de distribuir a lo largo de una red, evitando la necesidad de un mecanismo de configuración de políticas distribuidas específico para la aplicación, listas de control de acceso, y traductores e interpretes de certificados.
KeyNote provee un único lenguaje extensible para expresar políticas y credenciales. Las credenciales están asociadas a acciones autorizadas para quien la posea. Estas credenciales son firmadas, por lo que pueden utilizarse protocolos de transferencia de archivos para distribuir las políticas de forma segura. En este esquema, la política de seguridad relevante para un usuario en particular es la composición de la política enviada al host y cualquier credencial obtenida.
Las credenciales utilizan un esquema de versiones que permite controlar la configuración del sistema del usuario. Si el control falla, es decir, si la versión apropiada de los archivos apropiados no estuviera presente, el certificado no permitiría a sí mismo ser utilizado para autenticación. El mecanismo de versión de certificado también protege contra la instalación de nuevas máquinas inseguras en la red. Hasta que se instale el software de filtrado y conjunto de reglas apropiados no se entrega ningún certificado. Hasta ese momento la máquina es una máquina “externa”, sin importar su posición física.
KeyNote también provee un mecanismo de aplicación de las políticas diseñadas para cada sistema final; adicionalmente, las credenciales firmadas proveen un medio de protección de los datos transmitidos que facilitan la implementación del mecanismo de distribución.
Firmato
Firmato es un kit de herramientas de administración de firewalls distribuidos (y no distribuidos), desarrollado en los Laboratorios Bell, cuyo principal componente es un lenguaje para la especificación de políticas independientes de la topología de una red. Responde a un esquema orientado a archivos. Firmato ofrece una interfaz gráfica de usuario para la especificación de políticas con un alto nivel de abstracción representado por un modelo de entidad relación que luego es traducido a un archivo de políticas expresadas en un lenguaje común. Estas políticas pueden ser aplicadas prácticamente por cualquier producto firewall implementando el compilador apropiado para generar las reglas correspondientes en el lenguaje apropiado para cada producto (uno de los trabajos desarrollados en Firmato [] utiliza un compilador para generar reglas para un producto de Check Point, FireWall-1).
Inspect
Inspect es el lenguaje propietario utilizado por FireWall-1 de la empresa Check Point. Es un lenguaje orientado a objetos, además es extensible, permitiendo la incorporación de nuevas aplicaciones, servicios y protocolos. A partir de las políticas definidas en este lenguaje se generan archivos scripts que son los que se utilizan para la aplicación de las reglas en cada sistema final.
Mecanismo de distribución
El mecanismo de distribución dependerá en gran parte del esquema de políticas utilizado. Es necesario implementar un esquema de seguridad en tránsito para las políticas que serán distribuidas. Éste mecanismo puede estar disponible junto con el ambiente de las políticas, en el caso de KeyNote gracias al uso de credenciales firmadas, o ser implementado como parte del mecanismo de distribución, con el uso de algún esquema de claves y/o certificados (Seguridad en Tránsito), necesario para ambientes como el ofrecido por Firmato, que no utiliza mecanismo alguno para la protección de las políticas en transito.
Como mecanismo de distribución pueden utilizarse algunos de los servicios existentes de FTP o HTTP. Es posible que los productos propietarios utilicen puertos configurados especialmente para la distribución de las políticas, pero de eso, el administrador no debe preocuparse porque el sistema de administración lo maneja de forma transparente.
La distribución de la política puede tomar varias formas: puede ser enviada directamente al sistema final que la aplicará, si se utilizan certificados, puede ser provista a los usuarios cuando traten de comunicarse con los hosts, o una combinación de ambos enfoques. Si las políticas son dinámicamente extraídas por los sistemas finales, puede utilizarse un servidor de licencias o un servidor de autorizaciones de seguridad para ser consultados acerca de si cierta comunicación es permitida. Un firewall convencional podría hacer lo mismo, pero carece del conocimiento acerca del contexto de la consulta. Los sistemas finales pueden conocer cosas tales como qué archivos están involucrados y cuáles son sus niveles de seguridad.
La tecnología propuesta por [Impl-DistFw] para estos aspectos es IPsec implementado entre sistema finales. Los protocolos de IPsec pueden utilizarse para proteger el tráfico, autenticar usuarios y distribuir las credenciales. Estas últimas dos funciones son llevadas a cabo como parte de la negociación del Intercambio de Claves de Internet (IKE).
Con el uso de IPsec, los permisos a cada paquete están determinados por los derechos asociados al certificado al cual está asociado el paquete. La tarea de filtrado necesaria es recomendada por la arquitectura de IPsec. La Base de datos de políticas de Seguridad (SPD) de entrada es usada para rechazar paquetes entrantes ilegales, mientras la Base de datos de políticas de Seguridad de salida, puede ser usada para controlar conexiones “salientes”.
La protección a nivel de aplicación puede ser lograda distribuyendo archivos de políticas específicos de cada aplicación. Por ejemplo, el sitio central puede indicarle a un navegador Web que rechace todos los controles ActiveX o Applets Java. Este es un problema serio para un firewall tradicional; haciendo esto, los hosts finales serán más seguros.
Mecanismo de aplicación
El mecanismo de aplicación de políticas puede realizarse a cualquier nivel de granularidad (red, circuito y aplicación). Tanto como para IP y TCP, como para otros protocolos se utilizarán principios similares de control de acceso. Para algunos otros protocolos se requerirán tareas adicionales dependiendo de su naturaleza.
El mecanismo podrá funcionar a nivel del kernel o como un proceso a nivel de usuario. Un enfoque a nivel de usuario requiere que cada aplicación interesada sea enlazada con una librería que provea los mecanismos de seguridad requeridos. De esta forma se tiene la ventaja de la independencia del sistema operativo y por lo tanto no requiere cambios al código del kernel. De todas formas, este esquema no garantiza que la aplicación usará la librería llevando a potenciales problemas de seguridad.
Un enfoque a nivel de kernel, requiere efectuar modificaciones al kernel del sistema operativo. Esto restringe la implementacion a sistemas tales como BSD o Linux (que incluyen el código fuente). La principal ventaja de este enfoque es que el mecanismo de seguridad adicional puede ser aplicado transparentemente a las aplicaciones.
En el caso de KeyNote, se dispone de un comprobador de conformidad que puede ser utilizado como una aplicación independiente, ofreciendo servicios a otras aplicaciones (por ejemplo un demonio), en forma de bibliotecas a las cuales se enlazan las aplicaciones que requieren servicios de autorización o como un servicio local utilizado por las aplicaciones por medio de un mecanismo de comunicación entre procesos (a nivel de kernel).
En el trabajo realizado por Ioannidis, Keromytis, Bellovin y Smith [Impl-DistFw] el mecanismo de aplicación de políticas es implementado en dos partes: un demonio de políticas, que es un proceso a nivel de usuario responsable de tomar las decisiones acerca de aceptar o rechazar una conexión basándose en las políticas que son especificadas por algún administrador y las credenciales obtenidas remotamente o provistas por el kernel; y un dispositivo de políticas, un seudo dispositivo que sirve como medio de comunicación entre el usuario (demonio de políticas) y las llamadas al sistema modificadas en el kernel. Este esquema maximiza la flexibilidad del sistema y permite una fácil experimentación
La comunicación entre el demonio de políticas y el kernel es posible gracias al dispositivo de políticas. El demonio recibe cada solicitud del kernel leyendo este dispositivo. La consulta contiene toda la información relevante a esa conexión. El procesamiento de la consulta se realiza por el demonio usando librerías de KeyNote para obtener una decisión de aceptar o denegar la acción propuesta. Finalmente, el demonio devuelve la respuesta al kernel y espera la siguiente consulta. La información recibida en un mensaje en particular es dependiente de la aplicación involucrada, pero el demonio no tiene conocimiento de la misma. Por eso, puede ser usado para proveer servicios de resolución de políticas para muchas aplicaciones, sin realizar modificaciones al procedimiento.
Escenario de interacción de los componentes
Para dar una idea de la interacción de los componentes más importantes, se presenta un caso de evaluación de una conexión TCP protegida por IPsec.
El host que recibe la conexión es parte de un firewall distribuido, y su política local es la que se muestra en la Fig. 32. Ésta política enuncia que alguna clave administrativa especificará nuestra política, en la forma de una o más credenciales. La falta de un campo de condiciones significa que no hay restricciones impuestas en las políticas especificadas por la clave administrativa.
KeyNote-Version: 2
Authorizer:"POLICY"
Licensees:ADMINISTRATIVE_KEY
Figura 32: Política de seguridad local de un host.
Ya que se utiliza una conexión sobre IPsec, el usuario remoto tendrá establecida una Asociación de Seguridad IPsec con el host local usando IKE. Una credencial KeyNote es entregada al host local como parte del intercambio IKE (ver Figura 33).
KeyNote-Version:2
Authorizer:ADMINISTRATIVE_KEY
Licensees:USER_KEY
Conditions:
(app_domain =="IPsec policy"&&
encryption_algorithm =="3DES"&&
local_address =="158.130.006.141")
->"true";
(app_domain =="Distributed Firewall"&&
@local_port ==23 &&
encrypted =="yes"&&
authenticated =="yes")
->"true";
Signature:...
Figura 33: Una credencial del administrador a algún usuario, autorizándolo a establecer una Asociación de Seguridad IPsec con el host local y conectarse al puerto 23 (telnet) sobre esa SA.
Una vez que la conexión es recibida, el kernel construirá el contexto apropiado que contendrá la dirección y puertos locales y remotos de la conexión, el hecho de que la conexión está protegida con IPsec, y otros datos. Esta información junto con la credencial obtenida mediante IPsec será pasada al demonio de políticas. El demonio realizará la evaluación KeyNote usando la política local y la credencial, y determinará si la conexión debe ser autorizada. En este caso, la respuesta positiva es enviada de regreso al kernel, quien permitirá que continué la conexión TCP. Pueden proveerse más de una credencial durante la negociación IKE (por ejemplo, para delegación de autoridad).
Si KeyNote no autorizara la conexión, el demonio de políticas tratará de adquirir credenciales relevantes contactando a un servidor remoto donde son almacenadas (podría ser un servidor web para un sitio pequeño, pero en redes grandes debería usarse una base de datos distribuida o replicada). El demonio de políticas, utiliza la clave pública del usuario remoto (ya que estará presente si se utilizó IPsec) y la dirección IP del usuario remoto, así como las claves para buscar una credencial, en particular, una credencial donde la clave pública del usuario o la dirección del host remoto aparezcan en el campo de licencias. Estas credenciales son usadas en conjunto con la información provista por el kernel para reevaluar la consulta. Si es denegada nuevamente, la conexión es denegada definitivamente.