Firmato, es un kit de herramientas para la administración de firewalls, que consiste de los siguientes componentes (ver Figura 10):

Un Modelo de Entidad-Relación, que provee un marco para representar la política de seguridad (independiente del firewall) y la topología de la red. Esto se logra expresando la política de seguridad en términos de roles, que se utilizan para definir capacidades de red. Los roles capturan la esencia de una política independientemente de la topología y del firewall.

Un Lenguaje de Definición de Modelos (MDL), que se utiliza como una interfaz para definir una instancia del modelo de entidad relación.

Un Compilador de Modelos, que traduce una instancia de un modelo en archivos de configuración específicos del firewall. Tales archivos incluyen información de la topología y la base de reglas. La mayoría de los firewall modernos permiten que las funciones de filtrado sean distribuidas en varios dispositivos de interconexión (gateways), en cuyo caso, el compilador debe generar un conjunto separado de archivos de configuración para cada dispositivo.

Un Ilustrador de Reglas, que transforma los archivos de configuración específicos del firewall en una representación gráfica de la política y topología actual. Tal visualización permite una primer evaluación rápida de la viabilidad de una política elegida.

Componentes de Firmato

Figura 10: Componentes de Firmato

Este conjunto de herramientas posee las siguientes propiedades

1. Separa el diseño de la política de seguridad de los detalles específicos del firewall. Esto permite que el administrador de seguridad de la red se enfoque en diseñar la política apropiada para la red sin preocuparse por los aspectos de configuración de bajo nivel presentes al momento de ser implementados. También permite realizar una administración unificada de los componentes de la red de diferentes proveedores y una transición más simple entre productos de diferentes compañías.

2. Separa el diseño de la política de seguridad de la topología de la red. Esta modularización permite al administrador obtener una política consistente frente a cualquier topología y reutilizarla en ambientes de múltiples empresas con diferentes detalles de red.

3. Permite generar los archivos de configuración del firewall automáticamente a partir de la política de seguridad de forma simultanea para varios gateways. Esto reduce la probabilidad de introducir defectos de seguridad por errores de traducción de la política en estos archivos de configuración.

4. Hace posible una depuración de alto nivel de los archivos de configuración. Esto le permite al administrador de seguridad capturar y analizar la información de los archivos de configuración.

Conceptos del modelo

Los aspectos de modelado capturan la parte independiente de la topología de la política de seguridad.

El concepto principal es el de rol. Un rol es una propiedad que puede asumir un host de la red. Cada rol define capacidades de iniciar y aceptar servicios. Por ejemplo, el rol de mail_server define la capacidad de aceptar conexiones TCP en el puerto 25. Un rol como web_enabled puede permitir transmisiones HTTP al exterior (esto permitiría a un host navegar en la Web).

Un rol define esencialmente:

  1. Los servicios permitidos.
  2. Los pares hacia o desde los cuales se aplican estos permisos.

Los pares son expresados igualmente en términos de otros roles. Ya que los roles se asignan a los hosts, la topología real se asocia a la política completa de la red (roles).

Los roles identifican capacidades positivas por lo que implementan una estrategia de que todo aquello que no es permitido es rechazado.

La topología de la red es modelada por un enfoque de entidad-relación (ver Figura 11). Un host modela una máquina de la red con su propio nombre y dirección IP. Un grupo de hosts representa un conjunto de máquinas (ya sea con un rango de direcciones IP o con conjunto de grupos de hosts). Los roles pueden ser también asignados a un grupo de hosts. En este modelo se utiliza el concepto de herencia que determina que los roles asumidos por un host son aquellos roles asignados al grupo de hosts al que pertenece al host.

Ejemplo de un modelo entidad-relación

Figura 11: Ejemplo de un modelo entidad-relación

De esta característica surge una cuestión: un host podría heredar un rol que permita cierto acceso no deseable. Para tratar este problema se utiliza la noción de grupo cerrado de roles: un host que asume un grupo de roles cerrado, no heredará otros roles asignados a cualquier grupo de hosts.

Este mecanismo de grupos de roles cerrados ofrece una forma limitada de expresión negativa, característica principal de la estrategia de permitir todo aquello que no sea expresamente negado. De todas formas, utilizando solo reglas positivas es posible obtener suficiente poder expresivo para definir cualquier política. Esto puede realizarse definiendo todo grupo de hosts de forma que no se solapen entre ellos, con lo que no se daría la herencia de roles. De todas formas el mecanismo de grupos cerrados de roles permite efectuar exclusión de grupos obteniendo una poderosa herramienta para definir una política detallada.

Lenguaje de Definición de Modelos (MDL)

El lenguaje de definición de modelos permite instanciar una política de seguridad y efectuar el mapeo entre la política y la topología. El parser para el lenguaje traduce un programa escrito en MDL en una instancia del modelo de entidad-relación.

El lenguaje dispone de los elementos necesarios para describir una política de seguridad mediante bloques que describen servicios, grupos de servicios, reglas y grupos de reglas.

Un servicio es especificado indicando su nombre seguido del protocolo sobre el cual está basado y el puerto de origen y destino utilizados para el servicio (este último opcionalmente). Todos los servicios son agrupados en bloque encabezado por el identificador SERVICES (ver Figura 12).

Los servicios pueden ser agrupados indicando un nombre de grupo, y a continuación los nombres de los servicios que forman el grupo. Los grupos se especifican en un bloque encabezado por el identificador SERVICE_GROUPS (ver Figura 13).

<service-name> =
      <protocol-base> [ <Dest-Port-No-Range> , <Src-Port-No-Range> ]

Ej.

SERVICES {
  smtp = TCP [25]
  ssh = TCP [22]
  ping = ICMP [8,0]
  https = TCP [443]
  all_tcp = TCP [*]
}

Figura 12: Especificación de Servicios en MDL

<srv-grp-name> = { <service-name1> , <service-name2> , ...}

Ej.

SERVICE_GROUPS {
  admin_to_gtwy = {ssh, ping}
  gtwy_to_admin = {ssh, https}
}

Figura 13: Especificación de Grupos de Servicios en MDL

Para especificar un rol, se indican los servicios permitidos con otros roles y la dirección permitida de ese servicio, que puede ser unidireccional como bidireccional. Los roles son agrupados en bloques encabezados por el identificador ROLE_DEFINITIONS (ver Figura 14). En el ejemplo de la fig. 14, los roles gateway_in y gateway_out modelan las capacidades de las interfaces de los gateways en cada dirección, entrada y salida; el rol mail_server permite una comunicación bidireccional con cualquier rol mediante el protocolo SMTP.

Los roles pueden ser agrupados indicando un nombre para el grupo y a continuación los roles que forman parte del grupo (ver Figura 15).

<role-name> arrow <role(-grp)-name> : <srv-grp-name>
arrow == <- || -> || <->

Ej.

ROLE_DEFINITIONS {
    mail_server <-> *
        : smtp
    internal_mail_server <-> mail_server
        : smtp
    gateway_in <- fw_admin
        : admin_to_gtwy
    gateway_out -> fw_admin
        : gtwy_to_admin
    intranet_machine -> all_tcp
        : *
}

Figura 14: Especificación de Roles en MDL

<role-grp-name> = { <role-name1> , <role-name2> , ... }

Ej.

ROLE_GROUPS {
   gateway = << gateway_in , gateway_out >>
}

Figura 15: Especificación de Grupos de Roles en MDL

Para indicar que el grupo es cerrado, se reemplazan los ‘{’ y ‘}’ por ‘<<’ y ‘>>’.

Adicionalmente a estos elementos, el lenguaje dispone de otros elementos usados para describir la topología de la red y el mapeo de la política de seguridad con la topología.

Un host puede ser especificado por una dirección IP identificándolo con un nombre y asignándole un rol (o grupo de roles). En el caso de la especificación de un grupo de hosts se utiliza un rango de direcciones IP en lugar de una única dirección. Los hosts son agrupados en bloques encabezados por el identificador HOST (ver Figura 16).

<host-name> = [ <IP-Addr> ] : <role(-grp)-name>

<host-grp-name> = [ <IP-Range> ] : <role(-grp)-name>

Ej.

HOST {
    untrusted = [ 111.222.100.6 ]
        : mail_server
    trusted = [ 111.222.1.3 ]
        : internal_mail_server
}

Figura 16: Especificación de Hosts y Grupos de Hosts en MDL

También es posible definir gateways identificando todas sus interfaces de conexión, es decir, todas sus identidades (hosts) con las que aparece en cada red a la cual se conecta. Los gateways son agrupados en bloques encabezados por el identificador GATEWAYS (ver Figura 17).

<gateway-name> = { <host-name1> , <host-name2> , ... }

Ej.

HOST {
    payroll_gw_interface1 =
        [ 111.222.26.226 ] : gateway
    payroll_gw_interface2 =
        [ 111.222.24.210 ] : gateway
}
GATEWAYS {
    payroll_gw = { payroll_gw_interface1 , payroll_gw_interface2 }
}

Figura 17: Especificación de Gateways en MDL

Es posible definir zonas de la red identificando las interfaces gateway a las que se conectan todos los hosts en esa zona (ver Figura 18).

En el ejemplo de la fig. 18, también se define el grupo de hosts conectados a cada zona.

 

<zone-name> : { <gtwy-interface-name1> , <gtwy-interface-name2> , .. }

Ej.

ZONES {
payroll_zone : {payroll_gw_interface1}
corp_zone : {payroll_gw_interface2, ...}
}

HOST_GROUPS {
    manhattan_office =
        [111.222.0.0-111.222.255.255]
        : intranet_machine
    payroll_zone =
        [111.222.26.0-111.222.26.255]
        : payroll_machine
    corp_zone =
        [111.222.24.0-111.222.24.255]
        : non_payroll_machine
}

Figura 18: Especificación de Zonas en MDL

Vie, 24/11/2006 - 12:08