Seguridad : Firewall Cisco IOS

Guía de Aplicación y Diseño de Zone-Based Policy Firewall

25 Agosto 2008 - Traducción manual
Otras Versiones: PDFpdf | Traducción Automática (31 Julio 2013) | Inglés (27 Diciembre 2010) | Comentarios

Contenido

Introducción
Prerrequisitos
      Requisitos
      Componentes Utilizados
      Convenciones
Descripción General de Zone-Based Policy
Modelo de Configuración de Zone-Based Policy
Reglas para Aplicar Zone-Based Policy Firewall
Diseño de Seguridad de Red de Zone-Based Policy
Uso de VPN IPSec con Zone-Based Policy Firewall
Configuración de Cisco Policy Language (CPL)
      Configuración de Class-Maps de Zone-Based Policy Firewall
      Configuración de Policy-Maps de Zone-Based Policy Firewall
      Configuración de Parameter-Maps de Zone-Based Policy Firewall
      Aplicación de Logging para las Políticas de Zone-Based Policy Firewall
      Edición de Class-maps y Policy-Maps de Zone-Policy Firewall
Ejemplos de Configuración
      Stateful Inspection Routing Firewall
      Stateful Inspection Transparent Firewall
      Regulación de Velocidad (Rate Policing) en Zone-Based Policy Firewall
      Inspección de Aplicaciones
      Filtrado de Direcciones URL
      Control de Acceso al Router
Zone-Based Firewall y Wide-Area Application Services
Monitoreo de Zone-Based Policy Firewall con Comandos Show y Debug
Tuning (ajustando) la protección de ZFW contra Negación de Servicio (DoS)
Apéndice
      Apéndice A: Configuración Básica
      Apéndice B: Configuración Final (Completa)
      Apéndice C: Configuración Básica de Zone-Policy Firewall para Dos Zonas
Discusiones relacionadas de la comunidad de soporte de Cisco

Introducción

En Cisco IOS® Software Release 12.4(6)T, se introdujo Zone-Based Policy Firewall (ZFW, Firewall de Políticas Basadas en Zonas), un nuevo modelo de configuración para el conjunto de características de Cisco IOS Firewall. Este nuevo modelo de configuración ofrece políticas intuitivas para routers de varias interfaces, mayor granularity (especificidad) de la aplicación de políticas de firewall y una política predeterminada de deny-all que prohíbe el tráfico entre zonas de seguridad del firewall hasta que se aplica una política explícita para permitir el tráfico deseado.

La nueva interfaz de inspección de políticas basadas en zonas permite utilizar casi todas las características clásicas de Cisco IOS Firewall implementadas antes de Cisco IOS Software Release 12.4(6)T:

  • Inspección de paquetes con estado

  • Cisco IOS Firewall con reconocimiento de VRF

  • Filtrado de direcciones URL

  • Mitigación de Negación de Servicio (DoS)

En Cisco IOS Software Release 12.4(9)T, ZFW también permite utilizar los límites de rendimiento y conexión/sesión por clase, además del control y la inspección de aplicaciones:

  • HTTP

  • Post Office Protocol (POP3), Internet Mail Access Protocol (IMAP), Simple Mail Transfer Protocol/Enhanced Simple Mail Transfer Protocol (SMTP/ESMTP)

  • Remote Procedure Call (RPC) de Sun

  • Aplicaciones de mensajería instantánea (IM):

    • Microsoft Messenger

    • Yahoo! Messenger

    • AOL Instant Messenger

  • Uso compartido de archivos Peer-to-Peer (P2P):

    • Bittorrent

    • KaZaA

    • Gnutella

    • eDonkey

En Cisco IOS Software Release 12.4(11)T, se agregaron estadísticas para facilitar el ajuste de la protección contra DoS.

En ZFW de Cisco IOS Software Release 12.4(15)T, aún no se permite utilizar algunas características y capacidades de Cisco IOS Classic Firewall:

  • Authentication proxy

  • Stateful firewall failover

  • Unified firewall MIB

  • IPv6 stateful inspection

  • TCP out-of-order support

En general, ZFW mejora el rendimiento de Cisco IOS para la mayoría de las actividades de inspección de firewall.

Ni ZFW de Cisco IOS, ni Classic Firewall soportan stateful inspection para el tráfico de multicast.

Prerrequisitos

Requisitos

No existen requisitos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones en cuanto a versiones específicas de software y hardware.

Convenciones

Consulte Cisco Technical Tips Conventions para obtener más información sobre las convenciones del documento.

Descripción General de Zone-Based Policy

La stateful inspection de Cisco IOS Classic Firewall (antes conocida como Context-Based Access Control, Control de Acceso Basado en Contexto o CBAC) utilizaba un modelo de configuración basado en interfaces, en el cual se aplicaba una política de stateful inspection a una interfaz. Todo el tráfico que pasaba a través de esa interfaz recibía la misma política de inspección. Este modelo de configuración limitaba la granularity (especificidad) de las políticas de firewall y causaba confusión en la aplicación adecuada de las políticas de firewall, especialmente en situaciones donde las políticas de firewall se deben aplicar entre varias interfaces.

Zone-Based Policy Firewall (también conocido como Zone-Policy Firewall o ZFW) cambia la configuración de firewall del modelo anterior, basado en interfaces, a un modelo basado en zonas, más flexible y fácil de comprender. Las interfaces se asignan a zonas, y la política de inspección se aplica al tráfico que se mueve entre las zonas. Las políticas entre zonas ofrecen considerable flexibilidad y granularity (especificidad), de modo que se pueden aplicar distintas políticas de inspección a varios grupos de hosts conectados a la misma interfaz del router.

Las políticas de firewall se configuran mediante Cisco® Policy Language (CPL), que utiliza una estructura jerárquica para definir la inspección de los protocolos de red y los grupos de hosts a los cuales se aplicará la inspección.

Modelo de Configuración de Zone-Based Policy

En comparación con Cisco IOS Classic Firewall, ZFW cambia completamente la forma de configurar la inspección de Cisco IOS Firewall.

El primer cambio importante a la configuración del firewall es la introducción de la configuración basada en zonas. Cisco IOS Firewall es la primera característica de defensa contra amenazas de Cisco IOS Software que implementa un modelo de configuración por zonas. Con el tiempo, es posible que otras características adopten el modelo de zonas. Durante un período de tiempo, se mantendrá el modelo de configuración basado en interfaces con stateful inspection (o CBAC) de Cisco IOS Classic Firewall que utiliza el conjunto de comandos ip inspect. Sin embargo, muy pocas o ninguna de las nuevas características son configurables con la Interfaz de la Línea de Comandos (CLI) clásica. ZFW no utiliza la stateful inspection ni los comandos CBAC. Los dos modelos de configuración se pueden utilizar simultáneamente en los routers, pero no combinados en las interfaces. Una interfaz no se puede configurar como miembro de una zona de seguridad y configurarla para ip inspect al mismo tiempo.

Las zonas establecen las fronteras de seguridad de la red. Una zona define un límite donde el tráfico se somete a las restricciones de las políticas al pasar a otra región de la red. La política predeterminada de ZFW entre zonas es la negación total. Si no se configura una política explícitamente, se bloquea todo el tráfico que se mueve entre zonas. Esto es un cambio significativo respecto al modelo de stateful inspection, en el cual el tráfico estaba implícitamente permitido hasta que se bloqueaba explícitamente mediante una lista de control de acceso (ACL).

El segundo cambio importante es la introducción de un nuevo lenguaje de políticas de configuración conocido como CPL. Es posible que los usuarios familiarizados con la CLI de Calidad de Servicio (QoS) modular (MQC) de Cisco IOS Software reconozcan que el formato es similar al uso que hace QoS de los class-maps para especificar qué tráfico se verá afectado por la acción aplicada en un policy-map.

Reglas para Aplicar Zone-Based Policy Firewall

La pertenencia de las interfaces de red del router a las zonas está sujeta a varias reglas que rigen el comportamiento de las interfaces, al igual que el tráfico que se mueve entre las interfaces de los miembros de una zona:

  • Se debe configurar una zona antes de asignarle interfaces.

  • Se puede asignar una interfaz a una sola zona de seguridad.

  • Todo el tráfico hacia y desde una interfaz determinada se bloquea implícitamente cuando se asigna la interfaz a una zona, excepto el tráfico hacia y desde otras interfaces de la misma zona y el tráfico hacia cualquier interfaz del router.

  • Implícitamente, se permite que el tráfico fluya de forma predeterminada entre las interfaces que son miembros de la misma zona.

  • Para permitir el tráfico hacia y desde una interfaz miembro de la zona, se debe configurar una política que permita o inspeccione el tráfico entre esa zona y cualquier otra zona.

  • La única excepción a la política predeterminada de negación total es la self-zone: Se permite todo el tráfico hacia cualquier interfaz del router hasta que se deniega explícitamente el tráfico.

  • El tráfico no puede fluir entre una interfaz miembro de una zona y otra interfaz que no es miembro de una zona. Las acciones Pass, Inspect y Drop sólo se pueden aplicar entre dos zonas.

  • Las interfaces que no se asignaron a una zona funcionan como puertos de router clásicos y aún pueden utilizar la configuración clásica de stateful inspection o CBAC.

  • Si se requiere que una interfaz de la caja no forme parte de la política de zonificación del firewall, de todos modos es posible que sea necesario colocar esa interfaz en una zona y configurar una política de paso total (una especie de política ficticia) entre esa zona y cualquier otra zona a la cual se desea que haya flujo de tráfico.

  • De lo anterior se deduce que, si se desea que el tráfico fluya entre todas las interfaces de un router, todas ellas deben formar parte del modelo de zonas (cada interfaz debe ser miembro de una zona u otra).

  • La única excepción al anterior enfoque predeterminado de negación es el tráfico hacia y desde el router, el cual se permitirá de forma predeterminada. Se puede configurar una política explícita para restringir dicho tráfico.

Diseño de Seguridad de Red de Zone-Based Policy

Se debe configurar una zona de seguridad para cada región de seguridad relativa dentro de la red, de modo que todas las interfaces que se asignan a la misma zona estén protegidas con un nivel de seguridad similar. Por ejemplo, considere un router de acceso con tres interfaces:

  • Una interfaz conectada a la Internet pública.

  • Una interfaz conectada a una red de área local (LAN) privada que no debe ser accesible desde la Internet pública.

  • Una interfaz conectada a una zona desmilitarizada (DMZ) de servicio de Internet, en la que un Webserver, un servidor de Sistema de Nombres de Dominio (DNS) y un servidor de correo electrónico deben ser accesibles desde la Internet pública.

Cada interfaz de esta red se asignará a su propia zona, aunque se puede, si se desea, permitir diversos accesos desde la Internet pública para hosts específicos en la DMZ y diversas políticas de uso de aplicaciones para los hosts de la LAN protegida. (Vea la figura 1).

Figura 1: Topología Básica de Zonas de Seguridad

zone-design-guide1.gif

En este ejemplo, cada zona tiene una sola interfaz. Si se agrega una interfaz adicional a la zona privada, los hosts conectados a la interfaz nueva de la zona pueden pasar tráfico a todos los hosts de la interfaz actual de la misma zona. Además, el tráfico de los hosts hacia los hosts de otras zonas se ve igualmente afectado por las políticas actuales.

Por lo general, la red de ejemplo tendrá tres políticas principales:

  • Conectividad de la zona privada a Internet

  • Conectividad de la zona privada a los hosts de la DMZ

  • Conectividad de la zona de Internet a los hosts de la DMZ

Debido a que la DMZ está expuesta a la Internet pública, los hosts de la DMZ pueden estar sujetos a actividades no deseadas realizadas por individuos maliciosos que pueden lograr comprometer uno o más hosts de la DMZ. Si no se proporciona una política de acceso para que los hosts de la DMZ alcancen los hosts de zonas privadas o de la zona de Internet, los individuos que comprometan los hosts de la DMZ no pueden utilizarlos para realizar otro ataque contra los hosts privados o de Internet. ZFW impone una postura de seguridad prohibitiva predeterminada. Por lo tanto, a menos que a los hosts de la DMZ se les proporcione acceso específicamente a otras redes, las demás redes están protegidas contra todas las conexiones de los hosts de la DMZ. De manera similar, a los hosts de Internet no se les proporciona acceso a los hosts de zonas privadas, de modo que los hosts de zonas privadas están protegidos contra el acceso no deseado por parte de los hosts de Internet.

Uso de VPN IPSec con Zone-Based Policy Firewall

Recientes mejoras a VPN IPSec simplifican la configuración de políticas de firewall para la conectividad VPN. La Interfaz de Túnel Virtual (VTI) IPSec y GRE+IPSec permiten confinar las conexiones de cliente y de sitio a sitio de VPN a una zona de seguridad específica colocando las interfaces de túnel en una zona de seguridad especificada. Si se debe limitar la conectividad según una política específica, se pueden aislar las conexiones en una DMZ de la VPN. O bien, si se confía implícitamente en la conectividad VPN, se puede colocar la conectividad VPN en la misma zona de seguridad confiable de la red interna.

Si no se aplica una VTI IPSec, la política de firewall de conectividad VPN requiere un examen riguroso para mantener la seguridad. Si los hosts seguros se encuentran en una zona que no sea la de la conexión encriptada del cliente VPN al router, la política de zonas debe permitir específicamente el acceso de una dirección IP para hosts o clientes VPN de sitios remotos. Si no se configura correctamente la política de acceso, los hosts que se deben proteger pueden quedar expuestos a hosts no deseados y potencialmente hostiles. Consulte Uso de VPN con Zone-Based Policy Firewall para obtener un análisis más detallado de conceptos y configuraciones.

Configuración de Cisco Policy Language (CPL)

Para configurar ZFW, se puede utilizar el siguiente procedimiento. La secuencia de pasos no es importante, pero algunos eventos se deben completar en orden. Por ejemplo, se debe configurar un class-map antes de asignarlo a un policy-map. De manera similar, no se puede asignar un policy-map a un zone-pair hasta que se configura la política. Si se intenta configurar una sección que depende de otra parte de la configuración que aún no se configuró, el router responde con un mensaje de error.

  1. Defina las zonas.

  2. Defina los pares de zonas.

  3. Defina los class-maps que describen el tráfico al que se debe aplicar una política cuando éste cruza un zone-pair.

  4. Defina los policy-maps para aplicar la acción al tráfico de los class-maps.

  5. Aplique los policy-maps a los pares de zonas.

  6. Asigne las interfaces a las zonas.

Configuración de Class-maps de Zone-Based Policy Firewall

Los class-maps definen el tráfico que el firewall selecciona para aplicar las políticas. Los class-maps de capa 4 ordenan el tráfico según los criterios enumerados a continuación. Estos criterios se especifican utilizando el comando match en un class-map:

  • Access-group: Una ACL estándar, extendida o con nombre puede filtrar el tráfico según la dirección IP de origen y de destino y el puerto de origen y de destino.

  • Protocolo: Protocolos de capa 4 (TCP, UDP e ICMP) y servicios de aplicación como HTTP, SMTP, DNS, etc. Se puede especificar cualquier servicio conocido o definido por el usuario para el Port-Application Mapping.

  • Class-map: Se puede anidar un class-map subordinado que proporciona criterios de match adicionales dentro de otro class-map.

  • No: El criterio not especifica que para el class-map se seleccionará todo el tráfico que no coincida con un servicio (protocolo), grupo de acceso o class-map subordinado especificado.

Combinación de Criterios de "Match": "Match-Any" contra "Match-All"

Con los class-maps, se pueden aplicar operadores de match-any o de match-all a fin de determinar cómo aplicar los criterios de match. Si se especifica match-any, el tráfico sólo debe cumplir con uno de los criterios de match del class-map. Si se especifica match-all, el tráfico debe cumplir con todos los criterios del class-map para pertenecer a esa clase determinada.

Si el tráfico debe cumplir con varios criterios, los criterios de match se deben aplicar en orden, del más específico al menos específico. Por ejemplo, considere el siguiente class-map:

class-map type inspect match-any my-test-cmap
 match protocol http
 match protocol tcp

El tráfico HTTP debe encontrar primero el match protocol http para asegurarse de que el tráfico es procesado por las capacidades de servicio específicas de la inspección HTTP. Si se invierten las líneas de match, de modo que el tráfico encuentra la sentencia match protocol tcp antes de comparar con match protocol http, el tráfico simplemente se clasifica como tráfico TCP y se inspecciona según las capacidades del componente de inspección TCP de Firewall. Esto es un problema para ciertos servicios, tales como FTP, TFTP y varios servicios de señalización multimedia y de voz, tales como H.323, SIP, Skinny, RTSP y otros. Estos servicios requieren capacidades de inspección adicionales para reconocer las actividades más complejas de tales servicios.

Aplicación de una ACL como Criterio de Match

Los class-maps pueden aplicar una ACL como uno de los criterios de match para la aplicación de políticas. Si el único criterio de match de un class-map es una ACL y el class-map está asociado con un policy-map que aplica la acción Inspect, el router aplica la inspección TCP o UDP básica a todo el tráfico permitido por la ACL, excepto aquél para el cual ZFW proporciona inspección con reconocimiento de aplicaciones. Esto incluye, entre otros, FTP, SIP, Skinny (SCCP), H.323, Sun RPC y TFTP. Si la inspección de aplicaciones específica está disponible y la ACL permite el canal primario o de control, se permite cualquier canal secundario o de medios asociado con el canal primario o de control, independientemente de que la ACL permita o no el tráfico.

Si un class-map sólo aplica la ACL 101 como criterio de match, aparece una ACL 101 de la siguiente manera:

access-list 101 permit ip any any

El tráfico es permitido en la dirección de la service-policy aplicada a un zone-pair determinado y en la dirección opuesta se permite el tráfico de retorno correspondiente. Por lo tanto, la ACL debe aplicar la restricción para limitar el tráfico a las especificaciones deseadas. Tenga en cuenta que la lista de PAM incluye servicios de aplicaciones tales como HTTP, NetBIOS, H.323 y DNS. Sin embargo, a pesar de que PAM sepa del uso de un puerto determinado para una aplicación específica, el firewall sólo aplica la capacidad suficiente de dicha aplicación específica para admitir los requisitos conocidos del tráfico de esa aplicación. Por lo tanto, el tráfico de aplicaciones simples como Telnet, SSH y otras aplicaciones de canal único se inspeccionan como TCP, y sus estadísticas se combinan en el resultado del comando show. Si se desea visibilidad de una aplicación específica en la actividad de la red, se debe configurar la inspección de servicios por nombre de aplicación (configure "match protocol http", "match protocol telnet", etc.).

Compare las estadísticas disponibles en la salida del comando show policy-map type inspect zone-pair de esta configuración con la política de firewall más explícita que se muestra más adelante en la página. Esta configuración se utiliza para inspeccionar el tráfico de un Cisco IP Phone y de varias estaciones de trabajo que utilizan diversos tráficos, incluidos http, ftp, netbios, ssh y dns:

class-map type inspect match-all all-private
 match access-group 101
!         
policy-map type inspect priv-pub-pmap
 class type inspect all-private
  inspect
 class class-default
!
zone security private
zone security public
zone-pair security priv-pub source private destination public
 service-policy type inspect priv-pub-pmap
! 
interface FastEthernet4
 ip address 172.16.108.44 255.255.255.0
 zone-member security public
!
interface Vlan1
 ip address 192.168.108.1 255.255.255.0
 zone-member security private
!
access-list 101 permit ip 192.168.108.0 0.0.0.255 any

Si bien esta configuración es fácil de definir y admite todo el tráfico que se origina en la zona privada (siempre que el tráfico use los puertos de destino estándar y reconocidos por PAM), proporciona una visibilidad limitada de la actividad de servicios y no ofrece la oportunidad de aplicar límites de sesión y ancho de banda de ZFW para tipos de tráfico específicos. Esta salida del comando show policy-map type inspect zone-pair priv-pub se deriva de la configuración simple anterior que utiliza sólo una definición permit ip [subnet] any ACL entre los pares de zonas. Como se ve, la mayor parte del tráfico de las estaciones de trabajo se cuenta en las estadísticas TCP o UDP básicas:

stg-871-L#show policy-map type insp zone-pair priv-pub
 Zone-pair: priv-pub
 
  Service-policy inspect : priv-pub-pmap
 
    Class-map: all-private (match-all)
      Match: access-group 101
      Inspect
        Packet inspection statistics [process switch:fast switch]
        tcp packets: [413:51589]
        udp packets: [74:28]
        icmp packets: [0:8]
        ftp packets: [23:0]
        tftp packets: [3:0]
        tftp-data packets: [6:28]
        skinny packets: [238:0]
 
        Session creations since subsystem startup or last reset 39
        Current session counts (estab/half-open/terminating) [3:0:0]
        Maxever session counts (estab/half-open/terminating) [3:4:1]
        Last session created 00:00:20
        Last statistic reset never
        Last session creation rate 2
        Maxever session creation rate 7
        Last half-open session total 0
 
    Class-map: class-default (match-any)
      Match: any 
      Drop (default action)
        0 packets, 0 bytes

En comparación, una configuración similar que agrega clases de aplicaciones específicas proporciona control y estadísticas de aplicaciones más detallados, e incluso admite la misma amplitud de servicios que se mostró en el primer ejemplo al definir el class-map de última opción para que coincida sólo con la ACL como última opción del policy-map:

class-map type inspect match-all all-private
 match access-group 101
class-map type inspect match-all private-ftp
 match protocol ftp
 match access-group 101
class-map type inspect match-any netbios
 match protocol msrpc
 match protocol netbios-dgm
 match protocol netbios-ns
 match protocol netbios-ssn
class-map type inspect match-all private-netbios
 match class-map netbios
 match access-group 101
class-map type inspect match-all private-ssh
 match protocol ssh
 match access-group 101
class-map type inspect match-all private-http
 match protocol http
 match access-group 101
!
policy-map type inspect priv-pub-pmap
 class type inspect private-http
  inspect
 class type inspect private-ftp
  inspect
 class type inspect private-ssh
  inspect
 class type inspect private-netbios
  inspect
 class type inspect all-private
  inspect
 class class-default!
zone security private
zone security public
zone-pair security priv-pub source private destination public
 service-policy type inspect priv-pub-pmap
! 
interface FastEthernet4
 ip address 172.16.108.44 255.255.255.0
 zone-member security public
!
interface Vlan1
 ip address 192.168.108.1 255.255.255.0
 zone-member security private
!
access-list 101 permit ip 192.168.108.0 0.0.0.255 any

La configuración más específica proporciona esta salida substancialmente detallada para el comando show policy-map type inspect zone-pair priv-pub:

stg-871-L#sh policy-map type insp zone-pair priv-pub
 Zone-pair: priv-pub

   Service-policy inspect : priv-pub-pmap

     Class-map: private-http (match-all)
       Match: protocol http
       Match: access-group 101
       Inspect
         Packet inspection statistics [process switch:fast switch]
         tcp packets: [0:2193]

         Session creations since subsystem startup or last reset 731
         Current session counts (estab/half-open/terminating) [0:0:0]
         Maxever session counts (estab/half-open/terminating) [0:3:0]
         Last session created 00:29:25
         Last statistic reset never
         Last session creation rate 0
         Maxever session creation rate 4
         Last half-open session total 0

     Class-map: private-ftp (match-all)
       Match: protocol ftp
       Inspect
         Packet inspection statistics [process switch:fast switch]
         tcp packets: [86:167400]
         ftp packets: [43:0]

         Session creations since subsystem startup or last reset 7
         Current session counts (estab/half-open/terminating) [0:0:0]
         Maxever session counts (estab/half-open/terminating) [2:1:1]
         Last session created 00:42:49
         Last statistic reset never
         Last session creation rate 0
         Maxever session creation rate 4
         Last half-open session total 0

     Class-map: private-ssh (match-all)
       Match: protocol ssh
       Inspect
         Packet inspection statistics [process switch:fast switch]
         tcp packets: [0:62]

         Session creations since subsystem startup or last reset 4
         Current session counts (estab/half-open/terminating) [0:0:0]
         Maxever session counts (estab/half-open/terminating) [1:1:1]
         Last session created 00:34:18
         Last statistic reset never
         Last session creation rate 0
         Maxever session creation rate 2
         Last half-open session total 0

     Class-map: private-netbios (match-all)
       Match: access-group 101
       Match: class-map match-any netbios
         Match: protocol msrpc
           0 packets, 0 bytes
           30 second rate 0 bps
         Match: protocol netbios-dgm
           0 packets, 0 bytes
           30 second rate 0 bps
         Match: protocol netbios-ns
           0 packets, 0 bytes
           30 second rate 0 bps
         Match: protocol netbios-ssn
           2 packets, 56 bytes
           30 second rate 0 bps
       Inspect
         Packet inspection statistics [process switch:fast switch]
         tcp packets: [0:236]
 
         Session creations since subsystem startup or last reset 2
         Current session counts (estab/half-open/terminating) [0:0:0]
         Maxever session counts (estab/half-open/terminating) [1:1:1]
         Last session created 00:31:32
         Last statistic reset never
         Last session creation rate 0
         Maxever session creation rate 1
         Last half-open session total 0

     Class-map: all-private (match-all)
       Match: access-group 101
       Inspect
         Packet inspection statistics [process switch:fast switch]
         tcp packets: [51725:158156]
         udp packets: [8800:70]
         tftp packets: [8:0]
         tftp-data packets: [15:70]
         skinny packets: [33791:0]

         Session creations since subsystem startup or last reset 2759
         Current session counts (estab/half-open/terminating) [2:0:0]
         Maxever session counts (estab/half-open/terminating) [2:6:1]
         Last session created 00:22:21
         Last statistic reset never
         Last session creation rate 0
         Maxever session creation rate 12
         Last half-open session total 0
 
     Class-map: class-default (match-any)
       Match: any 
       Drop (default action)
         4 packets, 112 bytes

Como se mencionó anteriormente, otro beneficio que se agrega al utilizar una configuración más detallada de class-maps y policy-maps es la posibilidad de aplicar límites de clases específicas a los valores de sesión y velocidad, y ajustar específicamente los parámetros de inspección aplicando un parameter-map para ajustar el comportamiento de inspección de cada clase.

Configuración de Policy-Maps de Zone-Based Policy Firewall

El policy-map aplica acciones de políticas de firewall a uno o más class-maps para definir la política de servicios que se aplicará a un zone-pair de seguridad. Cuando se crea un policy-map de tipos de inspecciones, al final de la clase se aplica una clase predeterminada denominada clase class-default. La acción de la política predeterminada de la clase class-default es Drop, pero se puede cambiar a Pass. Se puede agregar la opción Log con la acción Drop. No se puede aplicar la acción Inspect en la clase class-default.

Acciones de Zone-Based Policy Firewall

ZFW proporciona tres acciones para el tráfico que viaja de una zona a otra:

  • Drop: Ésta es la acción predeterminada para todo el tráfico ya que la clase class-default está aplicada al final de un policy-map de tipo inspect. También se pueden configurar otros class-maps en un mismo policy-map para descartar el tráfico no deseado. El tráfico manejado por la acción drop es descartado "silenciosamente" por el ZFW (por ejemplo: no se envía ninguna notificación del drop al end-host), contrario al comportamiento de las ACLs que envían un mensaje ICMP "host unreachable" al host que envió el tráfico negado. Por el momento no hay opción de cambiar esta conducta de "silent-drop". Se puede agregar la opción log con la opción drop para enviar una notificación syslog de que el firewall descartó tráfico.

  • Pass: Esta acción permite al router reenviar el tráfico de una zona a otra. La acción pass no realiza un seguimiento del estado de las conexiones o sesiones dentro del tráfico. Pass sólo permite el tráfico en una dirección. Se debe aplicar la política correspondiente para permitir que el tráfico de retorno pase en la dirección opuesta. La acción pass es útil para protocolos como IPSec ESP, IPSec AH, ISAKMP y otros protocolos intrínsicamente seguros y de comportamiento predecible. Sin embargo, en ZFW el tráfico de la mayoría de las aplicaciones se procesa mejor con la acción inspect.

  • Inspect: La acción inspect ofrece un control de tráfico basado en estado. Por ejemplo, si se inspecciona el tráfico de la zona privada a la zona de Internet en la red del ejemplo anterior, el router mantiene la información de conexión o sesión para el tráfico TCP y User Datagram Protocol (UDP). Por lo tanto, el router permite el tráfico de retorno enviado desde los hosts de la zona Internet en respuesta a solicitudes de conexión de la zona privada. Además, la acción inspect puede proporcionar inspección de aplicaciones y control de ciertos protocolos de servicios que pueden transportar tráfico de aplicaciones sensibles o vulnerables. Se puede aplicar audit.-trial con un parameter-map para registrar el inicio, el fin y la duración de la conexión o sesión, el volumen de datos transferidos y las direcciones de origen y destino.

Las acciones se asocian con los class-maps en policy-maps:

conf t
 policy-map type inspect z1-z2-pmap
  class type inspect service-cmap
   inspect|drop|allow [service-parameter-map]

Los parameter-maps ofrecen opciones para modificar los parámetros de conexión para la política de inspección de un class-map determinado.

Configuración de Parameter-Maps de Zone-Based Policy Firewall

Los parameter-maps especifican el comportamiento de inspección de ZFW para parámetros tales como protección contra Negación de Servicio (DoS), temporizadores de sesión de UDP/conexión TCP y configuración de logs de audit-trial. Los parameter-maps también se aplican con policy-maps y de clases de capa 7 para definir el comportamiento de aplicaciones específicas, por ejemplo, objetos HTTP, requisitos de autenticación POP3 e IMAP y otra información de aplicaciones específicas.

Los parameter-maps de inspección de ZFW están configurados como type inspect, al igual que otros objetos de políticas y clases de ZFW:

stg-871-L(config)#parameter-map type inspect z1-z2-pmap
stg-871-L(config-profile)#?
parameter-map commands:
  alert           Turn on/off alert
  audit-trail     Turn on/off audit trail
  dns-timeout     Specify timeout for DNS
  exit            Exit from parameter-map
  icmp            Config timeout values for icmp
  max-incomplete  Specify maximum number of incomplete connections before
                  clamping
  no              Negate or set default values of a command
  one-minute      Specify one-minute-sample watermarks for clamping
  sessions        Maximum number of inspect sessions
  tcp             Config timeout values for tcp connections
  udp             Config timeout values for udp flows

Los tipos específicos de parameter-maps especifican los parámetros aplicados por las políticas de inspección de aplicaciones de capa 7. Los parameter-maps de tipo regex definen una expresión normal para utilizar con la inspección de aplicaciones HTTP que filtra el tráfico mediante una expresión normal:

parameter-map type regex [parameter-map-name]

Los parameter-maps de tipo información de protocolos definen los nombres de servidores para utilizar con la inspección de las aplicaciones de mensajería instantánea (IM):

parameter-map type protocol-info [parameter-map-name]

Los detalles completos sobre la configuración de la inspección de aplicaciones HTTP e IM se proporcionan en las respectivas secciones de inspección de aplicaciones de este documento.

El ajuste de la protección contra DoS se incluye en una sección posterior de este documento.

La configuración de la inspección de aplicaciones se incluye en una sección posterior de este documento.

Aplicando Logging para las Políticas de Zone-Based Policy Firewall

ZFW ofrece opciones de logging para el tráfico que se descarta o inspecciona de forma predeterminada o las acciones de políticas de firewall configuradas. Audit-trail se aplica definiéndolo en un parameter-map y aplicando el parameter-map con la acción Inspect en un policy-map:

conf t
 policy-map type inspect z1-z2-pmap
  class type inspect service-cmap
   inspect|drop|allow [parameter-map-name (optional)]

Drop logging está disponible para el tráfico que descarta el ZFW. Drop logging se configura agregando un drop logging en un policy-map:

conf t
 policy-map type inspect z1-z2-pmap
  class type inspect service-cmap
   inspect|drop|allow [service-parameter-map]

Edición de Class-maps y Policy-Maps de Zone-Policy Firewall

Actualmente, ZFW no tiene un editor con el cual se puedan modificar las diversas estructuras de ZFW, como los policy-maps, class-maps y parameter-maps. Para reorganizar las sentencias de match en un class-map o la aplicación de una acción a varios class-maps contenidos dentro de un policy-map, se deben completar los siguientes pasos:

  1. Copie la estructura actual a un editor de texto como Microsoft Windows Notepad, o a un editor como vi en las plataformas Linux o Unix.

  2. Quite la estructura actual de la configuración del router.

  3. Modifique la estructura en el editor de texto.

  4. Vuelva a copiar la estructura en la CLI del router.

Ejemplos de Configuración

En este ejemplo de configuración, se utiliza un router Cisco 1811 Integrated Services. En el Apéndice A, se encuentra disponible una configuración básica con conectividad IP, configuración VLAN y bridging transparente entre dos segmentos LAN de Ethernet privada. El router está separado en cinco zonas:

  • La Internet pública está conectada a FastEthernet 0 (zona de Internet).

  • Dos servidores de Internet están conectados a FastEthernet 1 (zona DMZ).

  • El switch Ethernet está configurado con dos VLANs:

    • Las estaciones de trabajo están conectadas a la VLAN1 (zona de clientes).

    • Los servidores están conectados a la VLAN2 (zona de servidores).

    • La zona de clientes y la de servidores están en la misma subred. Se aplicará un firewall transparente entre las zonas, de modo que las políticas entre zonas de esas dos interfaces sólo afectarán el tráfico entre la zona de clientes y la de servidores.

  • Las interfaces VLAN1 y VLAN2 se comunican con otras redes a través de la bridge virtual interface (BVI1). Esta interfaz se asigna a la zona privada. (Vea la figura 2).

Figura 2: Detalle de Topología de Zonas

zone-design-guide2.gif

Las siguientes políticas se aplican utilizando las zonas de red definidas anteriormente:

  • Los hosts de la zona de Internet pueden alcanzar los servicios DNS, SMTP y SSH en un servidor de la DMZ. El otro servidor ofrecerá servicios SMTP, HTTP y HTTPS. La política de firewall restringirá el acceso a los servicios específicos disponibles en cada host.

  • Los hosts de la DMZ no se pueden conectar con los hosts de ninguna otra zona.

  • Los hosts de la zona de clientes se pueden conectar con hosts de la zona de servidores en todos los servicios TCP, UDP e ICMP.

  • Los hosts de la zona de servidores no se pueden conectar con hosts de la zona de clientes, excepto un servidor de aplicación basado en UNIX que puede abrir sesiones de clientes X Windows con servidores X Windows en equipos de escritorio de la zona de clientes, en los puertos 6900 a 6910.

  • Todos los hosts de la zona privada (combinación de clientes y servidores) pueden acceder a los hosts de la DMZ en los servicios SSH, FTP, POP, IMAP, ESMTP y HTTP, y en la zona de Internet en los servicios HTTP, HTTPS y DNS y en ICMP. Además, se aplicará la inspección de aplicaciones en las conexiones HTTP de la zona privada a la zona de Internet para garantizar que no se transporten las aplicaciones soportan mensajería instantánea y P2P en el puerto 80. (Vea la figura 3).

Figura 3: Permisos de Servicios del Zone-Pair para Aplicar en el Ejemplo de Configuración

zone-design-guide3.gif

Estas políticas de firewall se configuran por orden de complejidad:

  1. Inspección de clientes-servidores TCP/UDP/ICMP

  2. Inspección de SSH/FTP/POP/IMAP/ESMTP/HTTP de Zona Privada-DMZ

  3. Inspección restringida por direcciones de hosts de SMTP/HTTP/DNS de Internet-DMZ

  4. Inspección X Windows de servidores-clientes con un servicio de Mapeo port-application (PAM) especificado

  5. HTTP/HTTPS/DNS/ICMP con inspección de aplicación HTTP de zona privada-Internet

Dado que se aplicarán partes de la configuración a distintos segmentos de la red en distintos momentos, es importante recordar que un segmento de red perderá conectividad con los otros segmentos cuando se lo coloque en una zona. Por ejemplo, cuando se configura la zona privada, los hosts de la zona privada perderán conectividad con las zonas DMZ e Internet hasta que se definan las políticas respectivas.

Stateful Inspection Routing Firewall

Configuración de la Política de Zona Privada-Internet

En la figura 4, se muestra la configuración de la política de zona privada-Internet.

Figura 4: Inspección de Servicios de la Zona Privada a la Zona de Internet

zone-design-guide4.gif

La política de zona privada-Internet aplica la inspección de capa 7 a HTTP, HTTPS, DNS y la inspección de capa 4 a ICMP, de la zona privada a la zona de Internet. Esto permite las conexiones de la zona privada a la zona de Internet y permite el tráfico de retorno. La inspección de capa 7 ofrece las ventajas de un control de aplicación más estricto, una mejor seguridad y soporte técnico para las aplicaciones que requieren fixup. Sin embargo, como se mencionó, la inspección de capa 7 requiere una mejor comprensión de la actividad de red, ya que los protocolos de capa 7 que no están configurados para inspección no se permitirán entre zonas.

  1. Defina los class-maps que describen el tráfico que desea permitir entre zonas, según las políticas descritas anteriormente:

    conf t
     class-map type inspect match-any internet-traffic-class
      match protocol http
      match protocol https
      match protocol dns
      match protocol icmp
    
  2. Configure un policy-map para inspeccionar el tráfico en los class-maps que definió:

    conf t
     policy-map type inspect private-internet-policy
      class type inspect internet-traffic-class
       inspect
    
  3. Configure las zonas privada e internet y asigne las interfaces del router a sus respectivas zonas:

    conf t
    zone security private
    zone security internet
    int bvi1            
    zone-member security private
    int fastethernet 0
    zone-member security internet
    
  4. Configure el Zone-Pair y aplique el policy-map correspondiente.

    Nota: En este momento, sólo se debe configurar el zone-pair privada-Internet para inspeccionar las conexiones originadas en la zona privada que viajan a la zona de Internet:

    conf t
     zone-pair security private-internet source private destination internet
      service-policy type inspect private-internet-policy
    

    Con esto se completa la configuración de la política de inspección de capa 7 en el zone-pair privada-Internet para permitir las conexiones HTTP, HTTPS, DNS e ICMP de la zona privada a la zona internet, y para aplicar la inspección de aplicaciones al tráfico HTTP a fin de garantizar que no se permita pasar el tráfico no deseado en TCP 80, el puerto de servicio de HTTP.

Configuración de la Política de Zona Privada-DMZ

En la figura 5, se muestra la configuración de la política de zona privada-DMZ.

Figura 5: Inspección de Servicios de la Zona Privada a la Zona DMZ

zone-design-guide5.gif

La política de zona privada-DMZ agrega complejidad porque requiere una mejor comprensión del tráfico de red entre zonas. Esta política aplica la inspección de capa 7 de la zona privada a la DMZ. Esto permite conexiones de la zona privada a la DMZ y permite el tráfico de retorno. La inspección de capa 7 ofrece las ventajas de un control de aplicación más estricto, una mejor seguridad y soporte técnico para las aplicaciones que requieren fixup. Sin embargo, como se mencionó, la inspección de capa 7 requiere una mejor comprensión de la actividad de red, ya que los protocolos de capa 7 que no están configurados para inspección no se permitirán entre zonas.

  1. Defina los class-maps que describen el tráfico que desea permitir entre zonas, según las políticas descritas anteriormente:

    conf t
     class-map type inspect match-any L7-inspect-class
      match protocol ssh
      match protocol ftp
      match protocol pop
      match protocol imap
      match protocol esmtp
      match protocol http
    
  2. Configure los policy-maps para inspeccionar el tráfico en los class-maps que definió:

    conf t
     policy-map type inspect private-dmz-policy
      class type inspect L7-inspect-class
       inspect
    
  3. Configure las zonas privada y DMZ y asigne las interfaces del router a sus respectivas zonas:

    conf t
    zone security private
    zone security dmz
    int bvi1            
    zone-member security private
    int fastethernet 1
    zone-member security dmz
    
  4. Configure el zone-pair y aplique el policy-map correspondiente.

    Nota: En este momento, sólo se debe configurar el zone-pair privada-DMZ para inspeccionar las conexiones originadas en la zona privada que viajan a la zona DMZ:

    conf t
     zone-pair security private-dmz source private destination dmz
      service-policy type inspect private-dmz-policy
    

    Con esto se completa la configuración de la política de inspección de capa 7 de la DMZ a la zona privada para permitir todas las conexiones TCP, UDP e ICMP de la zona de clientes a la zona de servidores. La política no aplica fixup para canales subordinados, pero proporciona un ejemplo de política simple para admitir las conexiones de la mayoría de las aplicaciones.

Configuración de la Política de Internet-DMZ

En la figura 6, se muestra la configuración de la política de Internet-DMZ.

Figura 6: Inspección de Servicios de la Zona de Internet a la Zona DMZ

zone-design-guide6.gif

Esta política aplica la inspección de capa 7 de la zona de Internet a la DMZ. Esto permite conexiones de la zona de Internet a la DMZ y permite el tráfico de retorno de los hosts de la DMZ a los hosts de Internet que originaron la conexión. La política de Internet-DMZ combina la inspección de capa 7 con los grupos de direcciones definidos por las ACL para restringir el acceso a servicios específicos en hosts específicos, grupos de hosts o subredes. Esto se logra anidando un class-map que especifica los servicios dentro de otro class-map que hace referencia a una ACL para especificar las direcciones IP.

  1. Defina los class-maps y las ACL que describen el tráfico que desea permitir entre zonas, según las políticas descritas anteriormente.

    Se pueden utilizar varios class-maps para servicios, ya que se aplicarán distintas políticas de acceso para el acceso a dos servidores diferentes. En los hosts de Internet se permiten conexiones DNS y HTTP a 172.16.2.2 y conexiones SMTP a 172.16.2.3. Tenga en cuenta la siguiente diferencia en los class-maps. Los class-maps que especifican servicios utilizan la palabra clave match-any para permitir cualquiera de los servicios enumerados. Los class-maps que asocian las ACL con los class-maps de servicios utilizan la palabra clave match-all para requerir que se cumplan ambas condiciones en el class-map a fin de permitir el tráfico:

    conf t
     access-list 110 permit ip any host 172.16.2.2
     access-list 111 permit ip any host 172.16.2.3
     class-map type inspect match-any dns-http-class
      match protocol dns
      match protocol http
     class-map type inspect match-any smtp-class
      match protocol smtp
     class-map type inspect match-all dns-http-acl-class
      match access-group 110
      match class-map dns-http-class
     class-map type inspect match-all smtp-acl-class
      match access-group 111
      match class-map smtp-class
    
  2. Configure los policy-maps para inspeccionar el tráfico en los class-maps que definió:

    conf t
     policy-map type inspect internet-dmz-policy
      class type inspect dns-http-acl-class
       inspect
      class type inspect smtp-acl-class
       inspect
    
  3. Configure las zonas Internet y DMZ y asigne las interfaces del router a sus respectivas zonas. Omita la configuración de la DMZ si la configuró en la sección anterior:

    conf t
    zone security internet
    zone security dmz
    int fastethernet 0            
     zone-member security internet
    int fastethernet 1
     zone-member security dmz
    
  4. Configure el zone-pair y aplique el policy-map correspondiente.

    Nota: En este momento, sólo debe configurar el zone-pair Internet-DMZ para inspeccionar las conexiones originadas en la zona de Internet que viajan a la zona DMZ:

    conf t
     zone-pair security internet-dmz source internet destination dmz
      service-policy type inspect internet-dmz-policy
    

    Con esto se completa la configuración de la política de inspección de capa 7 de direcciones específicas en el zone-pair Internet-DMZ.

Stateful Inspection Transparent Firewall

Configuración de la Política de Servidores-Clientes

En la figura 7, se muestra la configuración de la política de servidores-clientes.

Figura 7: Inspección de Servicios de la Zona de Servidores a la Zona de Clientes

zone-design-guide7.gif

La política de servidores-clientes aplica la inspección utilizando un servicio definido por el usuario. La inspección de capa 7 se aplica de la zona de servidores a la zona de clientes. Esto permite conexiones X Windows a un intervalo de puertos específico de la zona de servidores a la zona de clientes y permite el tráfico de retorno. X Windows no es un protocolo nativo soportado en PAM, de modo que se debe definir un servicio configurado por el usuario en PAM para que ZFW pueda reconocer e inspeccionar el tráfico correspondiente.

Se configuran dos o más interfaces de router en un bridge-group IEEE para proporcionar Integrated Routing and Bridging (IRB) a fin de proporcionar bridging entre las interfaces del bridge-group y ruteo a otras subredes a través de la Bridge Virtual Interface (BVI). La política de firewall transparente ofrecerá aplicar la inspección de firewall para el tráfico que "cruza el bridge", pero no para el tráfico que sale del bridge-group a través de la BVI. La política de inspección sólo se aplica al tráfico que cruza el bridge-group. Por lo tanto, en esta situación, la inspección sólo se aplicará al tráfico que se mueve entre la zona de clientes y la de servidores, que están anidadas dentro de la zona privada. La política aplicada entre la zona privada y las zonas pública y DMZ sólo interviene cuando el tráfico sale del bridge-group a través de la BVI. Cuando el tráfico sale a través de la BVI, ya sea de la zona de clientes o de la de servidores, no se invoca la política de firewall transparente.

  1. Configuración de PAM con una Entrada Definida por el Usuario para X Windows

    Los clientes X Windows (donde se alojan las aplicaciones) abren conexiones para mostrar información a los clientes (donde el usuario trabaja) en un intervalo que comienza en el puerto 6900.

    Cada conexión adicional utiliza puertos sucesivos, de modo que si un cliente muestra 10 sesiones diferentes en un host, el servidor utiliza los puertos 6900 a 6909. Por lo tanto, si se inspecciona el intervalo de puertos de 6900 a 6909, las conexiones abiertas a los puertos posteriores al 6909 fallarán:

    conf t
     ip port-map user-Xwindows port tcp from 6900 to 6910
    
  2. Consulte los documentos de PAM para obtener respuestas a las preguntas adicionales sobre PAM o controle la documentación detallada sobre la inspección de protocolos para obtener información sobre los detalles de interoperabilidad entre PAM y la stateful inspection de Cisco IOS Firewall.

  3. Defina los class-maps que describen el tráfico que desea permitir entre zonas, según las políticas descritas anteriormente:

    conf t
     class-map type inspect match-any Xwindows-class
      match protocol user-Xwindows
    
  4. Configure los policy-maps para inspeccionar el tráfico en los class-maps que definió:

    conf t
     policy-map type inspect servers-clients-policy
      class type inspect Xwindows-class
       inspect
    
  5. Configure la zona de clientes y la de servidores y asigne las interfaces del router a sus respectivas zonas.

    Si configuró esas zonas y asignó las interfaces en la sección Configuración de la Política de Clientes-Servidores, puede pasar a la definición del zone-pair. Para que la información esté completa, se proporciona la configuración de bridging IRB:

    conf t
    bridge irb
    bridge 1 protocol ieee
    bridge 1 route ip
    zone security clients
    zone security servers
     int vlan 1
     bridge-group 1
     zone-member security clients
    int vlan 2
     bridge-group 1
     zone-member security servers
    
  6. Configure el zone-pair y aplique el policy-map correspondiente.

    Nota: En este momento, sólo se debe configurar el zone-pair servidores-clientes para inspeccionar las conexiones originadas en la zona de servidores que viajan a la zona de clientes:

    conf t
     zone-pair security servers-clients source servers destination clients
      service-policy type inspect servers-clients-policy
    

    Con esto se completa la configuración de la política de inspección definida por el usuario en el zone-pair servidores-clientes para permitir las conexiones X Windows de la zona de servidores a la zona de clientes.

Configuración de la Política de Clientes-Servidores

En la figura 8, se muestra la configuración de la política de clientes-servidores.

Figura 8: Inspección de Servicios de la Zona de Clientes a la Zona de Servidores

zone-design-guide8.gif

La política de clientes-servidores es menos compleja que las otras. La inspección de capa 4 se aplica de la zona de clientes a la zona de servidores. Esto permite conexiones de la zona de clientes a la zona de servidores y permite el tráfico de retorno. La inspección de capa 4 ofrece la ventaja de la simplicidad de la configuración del firewall, ya que sólo se requieren algunas reglas para permitir el tráfico de la mayoría de las aplicaciones. Sin embargo, la inspección de capa 4 también tiene dos importantes desventajas:

  • Con frecuencia, las aplicaciones tales como FTP o los servicios de flujo de datos de medios negocian un canal subordinado adicional del servidor al cliente. Esta funcionalidad generalmente se admite en una reparación de servicio que supervisa el diálogo en el canal de control y permite el canal subordinado. Esta capacidad no está disponible en la inspección de capa 4.

  • La inspección de capa 4 permite casi todo el tráfico de la capa de aplicaciones. Si se debe controlar el uso de la red de modo que sólo algunas aplicaciones puedan atravesar el firewall, se debe configurar una ACL para el tráfico saliente a fin de limitar los servicios permitidos a través del firewall.

Ambas interfaces del router están configuradas en un bridge group IEEE, de modo que esta política de firewall aplicará la inspección de firewall transparente. Esta política se aplica en dos interfaces de un bridge group IP IEEE. La política de inspección sólo se aplica al tráfico que cruza el bridge group. Esto explica por qué la zona de clientes y la de servidores se anidan dentro de la zona privada.

  1. Defina los class-maps que describen el tráfico que desea permitir entre zonas, según las políticas descritas anteriormente:

    conf t
     class-map type inspect match-any L4-inspect-class
     match protocol tcp
     match protocol udp
     match protocol icmp
    
  2. Configure los policy-maps para inspeccionar el tráfico en los class-maps que definió:

    conf t
     policy-map type inspect clients-servers-policy
     class type inspect L4-inspect-class
      inspect
    
  3. Configure la zona de clientes y la de servidores y asigne las interfaces del router a las zonas respectivas:

    conf t
    zone security clients
    zone security servers
    int vlan 1            
    zone-member security clients
    int vlan 2
    zone-member security servers
    
  4. Configure el zone-pair y aplique el policy-map correspondiente.

    Nota: En este momento, sólo se debe configurar el zone-pair clientes-servidores para inspeccionar las conexiones originadas en la zona de clientes que viajan a la zona de servidores:

    conf t
     zone-pair security clients-servers source clients destination servers
      service-policy type inspect clients-servers-policy
    

    Con esto se completa la configuración de la política de inspección de capa 4 del zone-pair clientes-servidores para permitir todas las conexiones TCP, UDP e ICMP de la zona de clientes a la zona de servidores. La política no aplica fixup para canales subordinados, pero proporciona un ejemplo de política simple para admitir las conexiones de la mayoría de las aplicaciones.

Regulación de Velocidad (Rate Policing) en Zone-Based Policy Firewall

Con frecuencia, las redes de datos se benefician de la capacidad de limitar la velocidad de transmisión de tipos específicos de tráfico de red y de limitar el impacto del tráfico de menor prioridad para priorizar el tráfico crítico. Cisco IOS Software ofrece esta capacidad mediante la regulación de tráfico, la cual limita la velocidad nominal del tráfico, así como los picos ó ráfagas. Cisco IOS Software permite utilizar la regulación de tráfico desde Cisco IOS Release 12.1(5)T.

Cisco IOS Software Release 12.4(9)T mejora el ZFW con la limitación de velocidad (rate-limiting), agregando la capacidad de regular el tráfico que coincide con las definiciones de un class-map específico a medida que atraviesa el firewall de una zona de seguridad a otra. Esto proporciona la conveniencia de ofrecer un punto de configuración para describir el tráfico específico, aplicar la política de firewall y regular el consumo de ancho de banda de dicho tráfico.

La regulación de ZFW difiere de la regulación basada en interfaces en que sólo proporciona las acciones Transmit cuando se cumple con la política y Drop cuando no se cumple con ella. En ZFW, la regulación no puede marcar el tráfico para DSCP. En ZFW, la regulación sólo puede especificar el ancho de banda utilizado en bytes por segundo y no se ofrece la regulación de porcentaje de ancho de banda ni de paquetes por segundo. En ZFW, la regulación se puede aplicar con la regulación basada en interfaces o sin ella. Por lo tanto, si se requieren capacidades de regulación adicionales, estas características se pueden aplicar mediante la regulación basada en interfaces. Si se utiliza la regulación basada en interfaces junto con la regulación del firewall, asegúrese de que las políticas no entren en conflicto.

Configuración de la Regulación de ZFW

En ZFW, la regulación limita el tráfico de un class-map de un policy-map a un valor de velocidad definido por el usuario de 8000 a 2.000.000.000 de bits por segundo, con un valor burst configurable en un intervalo de 1000 a 512.000.000 de bytes.

En ZFW, la regulación se configura mediante una línea adicional de configuración en el policy-map, la cual se aplica después de la acción de la política:

policy-map type inspect private-allowed-policy
 class type inspect http-class
  inspect
  police rate [bps rate value <8000-2000000000>] burst [value in bytes <1000-512000000>]

Control de Sesión

En la regulación de ZFW, también se introdujo el control de sesión para limitar el conteo de sesiones del tráfico de un policy-map que coincide con un class-map. Esto se suma a la capacidad actual de aplicar la política de protección contra DoS por class-map. Efectivamente, esto permite un control detallado de la cantidad de sesiones que coinciden con un class-map determinado y que cruzan un zone-pair. Si se utiliza el mismo class-map en varios policy-maps o pares de zonas, se pueden aplicar diferentes límites de sesiones en las distintas aplicaciones de los class-maps.

El control de sesión se aplica configurando un parameter-map que contiene el volumen de sesiones deseado y agregando el parameter-map a la acción Inspect aplicada a un class-map dentro de un policy-map:

parameter-map type inspect my-parameters
 sessions maximum [1-2147483647]

policy-map type inspect private-allowed-policy
 class type inspect http-class
  inspect my-parameters

Los parameter-maps sólo se pueden aplicar a la acción Inspect y no están disponibles para las acciones Pass o Drop.

Con el siguiente comando, se pueden ver las actividades de regulación y control de sesión de ZFW:

show policy-map type inspect zone-pair

Inspección de Aplicaciones

La inspección de aplicaciones introduce una capacidad adicional al ZFW. Las políticas de inspección de aplicaciones se aplican en la capa 7 del modelo de Interconexión de Sistema Abierto (OSI), donde las aplicaciones de usuario envían y reciben mensajes que permiten a las aplicaciones ofrecer capacidades útiles. Algunas aplicaciones pueden ofrecer capacidades vulnerables o no deseadas, de modo que se deben filtrar los mensajes asociados con estas capacidades para limitar las actividades en los servicios de las aplicaciones.

El ZFW de Cisco IOS Software ofrece control e inspección de aplicaciones en los siguientes servicios de aplicaciones:

  • HTTP

  • SMTP

  • POP3

  • IMAP

  • Sun RPC

  • Tráfico de Aplicaciones P2P

  • Aplicaciones IM

La capacidad de Control e Inspección de Aplicaciones (AIC) varía según el servicio. La inspección de HTTP ofrece un filtrado detallado de varios tipos de actividades de aplicaciones, incluidas capacidades para limitar el tamaño de transferencia, las extensiones de las direcciones web y la actividad del explorador a fin de hacer cumplir los estándares de comportamiento de las aplicaciones y limitar los tipos de contenido que se transfieren a través del servicio. El AIC para SMTP puede limitar la extensión del contenido y hacer cumplir las normas del protocolo. La inspección de POP3 e IMAP puede ayudar a garantizar que los usuarios utilicen mecanismos de autenticación seguros para evitar que se comprometan las credenciales de usuario.

La inspección de aplicaciones se configura como un grupo adicional de class-maps y policy-maps de aplicaciones específicas, los cuales luego se aplican a los actuales class-maps y policy-maps de inspección definiendo la política de servicios de aplicaciones en el policy-map de inspección.

Inspección de Aplicaciones HTTP

La inspección de aplicaciones se puede aplicar al tráfico HTTP para controlar el uso no deseado del puerto de servicio de HTTP para otras aplicaciones, tales como IM, uso compartido de archivos P2P y aplicaciones tuneleadas que puedan esconder aplicaciones restringidas a través de TCP 80.

Configure un class-map de inspección de aplicaciones para describir el tráfico que infringe el tráfico HTTP permitido:

! Configure las acciones que no están permitidas.
class-map type inspect http match-any http-aic-cmap
 match request port-misuse any
 match req-resp protocol-violation 
! Defina las acciones que se aplicarán al tráfico no deseado.
policy-map type inspect http http-aic-pmap
 class type insp http http-aic-cmap
  reset
  log
! Defina el class-map para la inspección http con estado.
class-map type inspect match-any http-cmap
 match protocol http
! Defina el class-map para la stateful inspection para otro tipo de tráfico.
class-map type inspect match-any other-traffic-cmap
 match protocol smtp
 match protocol dns
 match protocol ftp
! Defina el policy-map, asocie los class-maps y las acciones.
policy-map type inspect priv-pub-pmap
 class type inspect http-cmap
  inspect
  service-policy http http-aic-pmap
 class type inspect other-traffic-cmap
  inspect

Mejoras de la Inspección de Aplicaciones HTTP

Cisco IOS Software Release 12.4(9)T introduce mejoras en las capacidades de inspección de HTTP del ZFW. En Cisco IOS Software Release 12.3(14)T, Cisco IOS Firewall introdujo la inspección de aplicaciones HTTP. Cisco IOS Software Release 12.4(9)T mejora las capacidades actuales agregando:

  • Capacidad de permitir, denegar y supervisar peticiones y respuestas según los nombres de encabezado y valores de encabezado. Esto es útil para bloquear peticiones y respuestas que tengan campos de encabezado vulnerables.

  • Capacidad de limitar los tamaños de los distintos elementos de los encabezados de solicitudes y respuestas de HTTP, por ejemplo, la extensión máxima de las direcciones URL, la extensión máxima de los encabezados, la cantidad máxima de encabezados, la extensión máxima de la línea del encabezado, etc. Esto es útil para evitar desbordamientos del buffer (buffer overflows).

  • Capacidad de bloquear peticiones y respuestas que tienen varios encabezados del mismo tipo; por ejemplo, una petición con dos encabezados de extensión de contenido.

  • Capacidad de bloquear peticiones y respuestas con encabezados que contienen caracteres que no sean ASCII. Esto es útil para evitar diversos ataques que utilizan caracteres binarios y otros caracteres que no son ASCII a fin de enviar gusanos y otros contenidos maliciosos a los servidores web.

  • Capacidad de agrupar métodos HTTP en categorías especificadas por el usuario y flexibilidad para bloquear, permitir y supervisar cada método del grupo que se ofrece. El HTTP RFC permite un grupo restringido de métodos HTTP. Algunos de los métodos estándar no se consideran seguros, ya que pueden utilizarse para aprovechar las vulnerabilidades de un servidor web. Muchos de los métodos no estándares no tienen un buen log de seguridad.

  • Método para bloquear Identificadores Uniformes de Recursos (URI) específicos según una expresión regular expression configurada por el usuario. Esta característica permite al usuario bloquear las consultas y los URI personalizados.

  • Capacidad de simular tipos de encabezado (spoofing) (especialmente el tipo de encabezado de servidores) con cadenas de caracteres (strings) personalizadas por el usuario. Esto es útil cuando un atacante analiza las respuestas de un servidor web, obtiene toda la información posible y luego ejecuta un ataque que aprovecha las debilidades de ese servidor web determinado.

  • Capacidad de bloquear una conexión HTTP, o enviar una alerta sobre ella, si uno o más valores de los parámetros HTTP coinciden con los valores ingresados por el usuario como una regular expression. Entre los posibles contextos de valores HTTP se incluyen el encabezado, el cuerpo, el nombre de usuario, la contraseña, el agente de usuario, la línea de petición, la línea de estado y las variables decodificadas de la Interfaz de Gateway Común (CGI).

En los ejemplos de configuración de las mejoras de la inspección de aplicaciones HTTP, se asume una red simple:

zone-design-guide9.gif

El firewall agrupa el tráfico en dos clases:

  • Tráfico HTTP

  • Todo el resto del tráfico de canal único TCP, UDP e ICMP

El HTTP se separa para permitir la inspección específica del tráfico web. Esto permite configurar la regulación en la primera sección de este documento y la inspección de aplicaciones HTTP en la segunda sección. Los class-maps y los policy-maps específicos para el tráfico P2P e IM se configurarán en la tercera sección de este documento. Se permite la conectividad de la zona privada a la zona pública. No se proporciona conectividad de la zona pública a la zona privada.

En el Apéndice C: Configuración Básica de Zone-Policy Firewall para Dos Zonas, se proporciona una configuración completa en la que se implementa la política inicial.

Configuración de las Mejoras de la Inspección de Aplicaciones HTTP

La inspección de aplicaciones HTTP (al igual que otras políticas de inspección de aplicaciones) requiere una configuración más compleja que la configuración básica de capa 4. Se debe configurar la política y la clasificación de tráfico de capa 7 para reconocer el tráfico específico que se desea controlar y para aplicar la acción requerida al tráfico deseado y no deseado.

La inspección de aplicaciones HTTP (al igual que otros tipos de inspección de aplicaciones) sólo se puede aplicar al tráfico HTTP. Por lo tanto, se deben definir los class-maps y los policy-maps de capa 7 para el tráfico HTTP específico, luego definir un class-map de capa 4 específicamente para HTTP y aplicar la política de capa 7 a la inspección HTTP en un policy-map de capa 4, de la siguiente forma:

!Configure las características del tráfico de capa 7:
class-map type inspect http match-any http-l7-cmap
 match  req-resp protocol-violation
 match  request body length gt 4096
!
!Configure la acción que se aplicará al tráfico 
!que coincide con las características específicas:
policy-map type inspect http http-l7-pmap
 class type inspect http http-l7-cmap
  reset
  log 
!
!Defina la política de inspección de capa 4
class-map type inspect match-all http-l4-cmap
 match protocol http
!
!Asocie la clase de capa 4 y el policy-map de capa 7
!en el policy-map de capa 4:
policy-map type inspect private-allowed-policy
 class type inspect http-l4-cmap
  inspect
  service-policy http http-l7-pmap

Todas estas características del tráfico de la inspección de aplicaciones HTTP se definen en un class-map de capa 7:

  • Header inspection: Este comando proporciona la capacidad de permitir, negar y monitorear solicitudes cuyos URI coincidan con la regular expression configurada. Esto permite al usuario bloquear las consultas y los URLs personalizados. La acción allow o reset se puede aplicar a una solicitud o respuesta que coincida con los criterios del class-map. Si se agrega la acción Log, se genera un mensaje syslog:

    APPFW-6-HTTP_HDR_REGEX_MATCHED
    

    Uso de Comandos:

    match {request|response|req-resp} header regex <parameter-map-name>
    

    Ejemplo de Caso de Uso

    Configure una política http appfw para bloquear las peticiones o respuestas cuyos encabezados contengan caracteres que no son ASCII.

    parameter-map type regex non_ascii_regex
       pattern “[^\x00-\x80]”
    class-map type inspect http non_ascii_cm
       match req-resp header regex non_ascii_regex
    policy-map type inspect http non_ascii_pm
       class type inspect http non_ascii_cm
          reset
    
  • Header length inspection: Este comando controla la extensión del encabezado de una petición o respuesta y aplica la acción si la extensión excede el umbral configurado. La acción es Allow o Reset. Si se agrega la acción Log, se genera un mensaje syslog:

    APPFW-4- HTTP_HEADER_LENGTH
    

    Uso de Comandos:

    match {request|response|req-resp} header length gt <bytes>
    

    Ejemplo de Caso de Uso

    Configure una política http appfw para bloquear peticiones y respuestas que tengan encabezados de más de 4096 bytes.

    class-map type inspect http hdr_len_cm
       match req-resp header length gt 4096
    
    policy-map type inspect http hdr_len_pm
       class type inspect http hdr_len_cm
          reset
    
  • Header count inspection: Este comando verifica la cantidad de líneas de encabezado (campos) de una petición o respuesta y aplica una acción cuando el conteo excede el umbral configurado. La acción es Allow o Reset. Si se agrega la acción Log, se genera un mensaje syslog:

    APPFW-6- HTTP_HEADER_COUNT.
    

    Uso de Comandos:

    match {request|response|req-resp} header count gt <number>
    

    Ejemplo de Caso de Uso

    Configure una política http appfw para bloquear una petición que tenga más de 16 campos de encabezado.

    class-map type inspect http hdr_cnt_cm
       match request header count gt 16
    
    policy-map type inspect http hdr_cnt_pm
       class type inspect http hdr_cnt_cm
          reset
    
  • Header field inspection: Este comando proporciona la capacidad de permitir, denegar y supervisar peticiones y respuestas que contengan un valor y un campo de encabezado HTTP específico. La acción Allow o Reset se puede aplicar a una petición o respuesta que coincida con los criterios del class-map. Si se agrega la acción Log, se genera un mensaje syslog:

    APPFW-6- HTTP_HDR_FIELD_REGEX_MATCHED
    

    Uso de Comandos:

    match {request|response|req-resp} header <header-name>
    

    Ejemplo de Caso de Uso

    Configure una política de inspección de aplicaciones http para bloquear el spyware y el adware:

    parameter-map type regex ref_regex
       pattern “\.delfinproject\.com”
       pattern “\.looksmart\.com”
    
    parameter-map type regex host_regex
       pattern “secure\.keenvalue\.com”
       pattern “\.looksmart\.com”
    
    parameter-map type regex usragnt_regex
       pattern “Peer Points Manager”
    
    class-map type inspect http spy_adwr_cm
       match request header refer regex ref_regex 
       match request header host regex host_regex
       match request header user-agent regex usragnt_regex
    
    policy-map type inspect http spy_adwr_pm
       class type inspect http spy_adwr_cm
          reset
    
  • Header field length inspection: Este comando proporciona la capacidad de limitar la extensión de una línea de campo de encabezado. La acción Allow o Reset se puede aplicar a una petición o respuesta que coincida con los criterios del class-map. Si se agrega la acción Log, se genera un mensaje syslog:

    APPFW-6- HTTP_HDR_FIELD_LENGTH.
    

    Uso de Comandos:

    match {request|response|req-resp} header <header-name> length gt <bytes>
    

    Ejemplo de Caso de Uso

    Configure una política http appfw para bloquear una petición cuya cookie y extensión del campo agente de usuario excedan 256 y 128, respectivamente.

    class-map type inspect http hdrline_len_cm
       match request header cookie length gt 256
       match request header user-agnet length gt 128
    
    policy-map type inspect http hdrline_len_pm
       class type inspect http hdrline_len_cm
          reset
    
  • Inspection of header field repetition: Este comando controla si una petición o respuesta tiene campos de encabezado repetidos. La acción Allow o Reset se puede aplicar a una petición o respuesta que coincida con los criterios del class-map. Si se activa la acción Log, se genera un mensaje syslog:

    APPFW-6- HTTP_REPEATED_HDR_FIELDS.
    

    Uso de Comandos:

    match {request|response|req-resp} header <header-name>
    

    Ejemplo de Caso de Uso

    Configure una política http appfw para bloquear una petición o respuesta que tenga varias líneas de encabezado de extensión de contenido. Ésta es una de las funcionalidades más útiles para evitar el contrabando de sesiones.

    class-map type inspect http multi_occrns_cm
       match req-resp header content-length count gt 1
    
    policy-map type inspect http multi_occrns_pm
       class type inspect http multi_occrns_cm
          reset
    
  • Method inspection: El HTTP RFC permite un grupo restringido de métodos HTTP. Sin embargo, incluso algunos de los métodos estándares no se consideran seguros, ya que se pueden utilizar para aprovechar las vulnerabilidades de un servidor web. Muchos de los métodos no estándares se utilizan frecuentemente para actividades maliciosas. Esto crea la necesidad de agrupar los métodos en diversas categorías y de que el usuario elija la acción para cada categoría. Este comando proporciona al usuario una forma flexible de agrupar los métodos en diversas categorías, tales como métodos seguros, métodos no seguros, métodos webdav, métodos rfc y métodos extendidos. La acción Allow o Reset se puede aplicar a una petición o respuesta que coincida con los criterios del class-map. Si se agrega la acción Log, se genera un mensaje syslog:

    APPFW-6-HTTP_METHOD.
    

    Uso de Comandos:

    match request method <method>
    

    Ejemplo de Caso de Uso

    Configure una política http appfw que agrupe los métodos HTTP en tres categorías: seguros, no seguros y webdav. Estos métodos se muestran en la siguiente tabla. Configure acciones de modo que:

    • Se permitan todos los métodos seguros sin log.

    • Se permitan todos los métodos no seguros con log.

    • Se bloqueen todos los métodos webdav con log.

    Seguros

    No Seguros

    WebDAV

    GET, HEAD, OPTION

    POST, PUT, CONNECT, TRACE

    BCOPY, BDELETE, BMOVE

    http policy:
    
    class-map type inspect http safe_methods_cm
       match request method get
       match request method head
       match request method option
       
    class-map type inspect http unsafe_methods_cm
       match request method post
       match request method put
       match request method connect
       match request method trace
    
    class-map type inspect http webdav_methods_cm
       match request method bcopy
       match request method bdelete
       match request method bmove
    
    policy-map type inspect http methods_pm
       class type inspect http safe_methods_cm
          allow
       class type inspect http unsafe_methods_cm
          allow log
          class type inspect http webdav_methods_cm
          reset log
    
  • URI inspection: Este comando proporciona la capacidad de permitir, denegar y supervisar peticiones cuyos URI coincidan con la inspección normal configurada. Esto permite al usuario bloquear las consultas y los URLs personalizados. La acción Allow o Reset se puede aplicar a una petición o respuesta que coincida con los criterios del class-map. Si se agrega la acción Log, se genera un mensaje syslog:

    APPFW-6- HTTP_URI_REGEX_MATCHED
    

    Uso de Comandos:

    match request uri regex <parameter-map-name>
    

    Ejemplo de Caso de Uso

    Configure una política http appfw para bloquear una solicitud cuyo URI coincida con alguna de las siguientes regular expressions:

    • .*cmd.exe

    • .*sex

    • .*gambling

    parameter-map type regex uri_regex_cm
       pattern “.*cmd.exe”
       pattern “.*sex”
       pattern “.*gambling”
    
    class-map type inspect http uri_check_cm
       match request uri regex uri_regex_cm
    
    policy-map type inspect http uri_check_pm
       class type inspect http uri_check_cm
          reset
    
  • URI length inspection: Este comando verifica la extensión del URI que se envía en una solicitud y aplica la acción configurada cuando la extensión excede el umbral configurado. La acción Allow o Reset se puede aplicar a una solicitud o respuesta que coincida con los criterios del class-map. Si se agrega la acción Log, se genera un mensaje syslog:

    APPFW-6- HTTP_URI_LENGTH.
    

    Uso de Comandos:

    match request uri length gt <bytes>
    

    Ejemplo de Caso de Uso

    Configure una política http appfw para emitir una alarma cuando la extensión del URI de una petición exceda los 3076 bytes.

    class-map type inspect http uri_len_cm
       match request uri length gt 3076
    
    policy-map type inspect http uri_len_pm
       class type inspect http uri_len_cm
          log
    
  • Argument inspection: Este comando proporciona la capacidad de permitir, negar o monitorear solicitudes cuyos argumentos (parámetros) coincidan con la regular expression configurada. La acción allow o reset se puede aplicar a una solicitud o respuesta que coincida con los criterios del class-map. Si se agrega la acción Log, se genera un mensaje syslog:

    APPFW-6- HTTP_ARG_REGEX_MATCHED
    

    Uso de Comandos:

    match request arg regex <parameter-map-name>
    

    Ejemplo de Caso de Uso

    Configure una política http appfw para bloquear una petición cuyos argumentos coincidan con alguna de las siguientes expresiones normales:

    • .*codered

    • .*attack

    parameter-map type regex arg_regex_cm
       pattern “.*codered”
       pattern “.*attack”
    
    class-map type inspect http arg_check_cm
       match request arg regex arg_regex_cm
    
    policy-map type inspect http arg_check_pm
       class type inspect http arg_check_cm
          reset
    
  • Argument length inspection: Este comando verifica la extensión de los argumentos que se envían en una petición y aplica la acción configurada cuando la extensión excede el umbral configurado. La acción Allow o Reset se puede aplicar a una petición o respuesta que coincida con los criterios del class-map. Si se agrega la acción Log, se genera un mensaje syslog:

    APPFW-6- HTTP_ARG_LENGTH.
    

    Uso de Comandos:

    match request arg length gt <bytes>
    

    Ejemplo de Caso de Uso

    Configure una política http appfw para emitir una alarma cuando la extensión del argumento de una petición exceda los 512 bytes.

    class-map type inspect http arg_len_cm
       match request arg length gt 512
    
    policy-map type inspect http arg_len_pm
       class type inspect http arg_len_cm
          log
    
  • Body inspection: Esta CLI permite al usuario especificar una lista de expresiones normales con las cuales debe coincidir el cuerpo de la petición o respuesta. La acción Allow o Reset se puede aplicar a una petición o respuesta que coincida con los criterios del class-map. Si se agrega la acción Log, se genera un mensaje syslog:

    APPFW-6- HTTP_BODY_REGEX_MATCHED
    

    Uso de Comandos:

    match {request|response|reg-resp} body regex <parameter-map-name>
    

    Ejemplo de Caso de Uso

    Configure una política http appfw para bloquear una respuesta cuyo cuerpo contenga el patrón .*[Aa][Tt][Tt][Aa][Cc][Kk].

    parameter-map type regex body_regex
       pattern “.*[Aa][Tt][Tt][Aa][Cc][Kk]”
    
    class-map type inspect http body_match_cm
       match response body regex body_regex
    
    policy-map type inspect http body_match_pm
       class type inspect http body_match_cm
          reset
    
  • Body (Content) length inspection: Este comando verifica el tamaño del mensaje que se envía a través de la petición o respuesta. La acción Allow o Reset se puede aplicar a una petición o respuesta que coincida con los criterios del class-map. Si se agrega la acción Log, se genera un mensaje syslog:

    APPFW-4- HTTP_CONTENT_LENGTH
    

    Uso de Comandos:

    match {request|response|req-resp} body length lt <bytes> gt <bytes>
    

    Ejemplo de Caso de Uso

    Configure una política http appfw para bloquear una sesión http que tenga un mensaje de más de 10K bytes en una petición o respuesta.

    class-map type inspect http cont_len_cm
       match req-resp header content-length gt 10240
    
    policy-map type inspect http cont_len_pm
       class type inspect http cont_len_cm
          reset
    
  • Status line inspection: Este comando permite al usuario especificar una lista de expresiones normales con las cuales debe coincidir la línea de estado de una respuesta. La acción Allow o Reset se puede aplicar a una petición o respuesta que coincida con los criterios del class-map. Si se agrega la acción Log, se genera un mensaje syslog:

    APPFW-6-HTTP_STLINE_REGEX_MATCHED.
    

    Uso de Comandos:

    match response status-line regex <class-map-name>
    

    Ejemplo de Caso de Uso

    Configure una política http appfw para registrar una alarma cuando se intenta acceder a una página prohibida. Una página prohibida generalmente contiene un código de estado 403 y la línea de estado es similar a la siguiente: HTTP/1.0 403 page forbidden\r\n.

    parameter-map type regex status_line_regex
       pattern “[Hh][Tt][Tt][Pp][/][0-9][.][0-9][ \t]+403”
    
    class-map type inspect http status_line_cm
       match response status-line regex status_line_regex
    
    policy-map type inspect http status_line_pm
       class type inspect http status_line_cm
          log
    
  • Content-type inspection: Este comando verifica si el tipo de contenido del encabezado del mensaje está en la lista de tipos de contenido soportados. También verifica que el tipo de contenido del encabezado coincida con el contenido de la parte del cuerpo de la entidad o de los datos del mensaje. Si se configura la palabra clave mismatch, el comando verifica el tipo de contenido del mensaje de respuesta con el valor de campo aceptado del mensaje de petición. La acción Allow o Reset se puede aplicar a una petición o respuesta que coincida con los criterios del class-map. Si se agrega la acción Log, se genera el mensaje syslog correspondiente:

    APPFW-4- HTTP_CONT_TYPE_VIOLATION, 
    APPFW-4- HTTP_CONT_TYPE_MISMATCH, 
    APPFW-4- HTTP_CONT_TYPE_UNKNOWN
    

    Uso de Comandos:

    match {request|response|req-resp} header content-type [mismatch|unknown|violation]
    

    Ejemplo de Caso de Uso

    Configure una política http appfw para bloquear una sesión http que tenga peticiones y respuestas con un tipo de contenido desconocido.

    class-map type inspect http cont_type_cm
       match req-resp header content-type unknown
    
    policy-map type inspect http cont_type_pm
       class type inspect http cont_type_cm
          reset
    
  • Port-misuse inspection: Este comando se utiliza para evitar que el puerto http (80) sea utilizado de manera incorrecta por otras aplicaciones, tales como IM, P2P, tunelización, etc. La acción Allow o Reset se puede aplicar a una petición o respuesta que coincida con los criterios del class-map. Si se agrega la acción Log, se genera el mensaje syslog correspondiente:

    APPFW-4- HTTP_PORT_MISUSE_TYPE_IM
    APPFW-4-HTTP_PORT_MISUSE_TYPE_P2P
    APPFW-4-HTTP_PORT_MISUSE_TYPE_TUNNEL
    

    Uso de Comandos:

    match request port-misuse {im|p2p|tunneling|any}
    

    Ejemplo de Caso de Uso

    Configure una política http appfw para evitar que una sesión http sea utilizada de manera incorrecta por una aplicación IM.

    class-map type inspect http port_misuse_cm
       match request port-misuse im
    
    policy-map type inspect http port_misuse_pm
       class type inspect http port_misuse_cm
          reset
    
  • Strict-http inspection: Este comando activa un control estricto de cumplimiento de protocolos de las peticiones y respuestas HTTP. La acción Allow o Reset se puede aplicar a una petición o respuesta que coincida con los criterios del class-map. Si se agrega la acción Log, se genera un mensaje syslog:

    APPFW-4- HTTP_PROTOCOL_VIOLATION
    

    Uso de Comandos:

    match req-resp protocol-violation
    

    Ejemplo de Caso de Uso

    Configure una política http appfw para bloquear peticiones o respuestas que no cumplan con RFC 2616:

    class-map type inspect http proto-viol_cm 
       match req-resp protocol-violation 
    
    policy-map type inspect http proto-viol_pm 
       class type inspect http proto-viol_cm 
          reset
    
  • Transfer-Encoding inspection: Este comando proporciona la capacidad de permitir, denegar o supervisar peticiones o respuestas cuyo tipo de codificación de transferencia coincida con el tipo configurado. La acción Allow o Reset se puede aplicar a una petición o respuesta que coincida con los criterios del class-map. Si se agrega la acción Log, se genera un mensaje syslog:

    APPFW-6- HTTP_TRANSFER_ENCODING
    

    Uso de Comandos:

    match {request|response|req-resp} header transfer-encoding 
    {regex <parameter-map-name> |gzip|deflate|chunked|identity|all}
    

    Ejemplo de Caso de Uso

    Configure una política http appfw para bloquear una petición o respuesta que tenga una codificación de tipo compresión.

    class-map type inspect http trans_encoding_cm
       match req-resp header transfer-encoding type compress
    
    policy-map type inspect http trans_encoding_pm
       class type inspect http trans_encoding_cm
          reset
    
  • Java Applet inspection: Este comando revisa si una respuesta tiene un applet de Java y aplica la acción configurada al detectar el applet. La acción Allow o Reset se puede aplicar a una solicitud o respuesta que coincida con los criterios del class-map. Si se agrega la acción Log, se genera un mensaje syslog:

    APPFW-4- HTTP_JAVA_APPLET
    

    Uso de Comandos:

    match response body java-applet
    

    Ejemplo de Caso de Uso

    Configure una política http appfw para bloquear los applets de Java.

    class-map type inspect http java_applet_cm
       match response body java-applet
    
    policy-map type inspect http java_applet_pm
       class type inspect http java_applet_cm
          reset
    

Soporte de ZFW para el control de aplicaciones Instant-Messaging y Peer-to-Peer

Cisco IOS Software Release 12.4(9)T introdujo el soporte de ZFW con las aplicaciones IM y P2P.

Cisco IOS Software permitió por primera vez utilizar el control de aplicaciones IM en Cisco IOS Software Release 12.4(4)T. La versión inicial de ZFW no permitía utilizar las aplicaciones IM en la interfaz de ZFW. Si se deseaba utilizar el control de aplicaciones IM, los usuarios no podían migrar a la interfaz de configuración de ZFW. Cisco IOS Software Release 12.4(9)T permite utilizar ZFW para la inspección de IM, incluidos Yahoo! Messenger (YM), MSN Messenger (MSN) y AOL Instant Messenger (AIM).

Cisco IOS Software Release 12.4(9)T es la primera versión de Cisco IOS Software que ofrece soporte nativo de IOS Firewall para las aplicaciones de uso compartido de archivos P2P.

La inspección de IM y P2P ofrece políticas de capa 4 y de capa 7 para el tráfico de aplicaciones. Esto significa que ZFW puede proporcionar inspección básica con estado para permitir o denegar el tráfico, además del control detallado de capa 7 para las actividades específicas de los distintos protocolos, a fin de permitir ciertas actividades de las aplicaciones y denegar otras.

Control e Inspección de Aplicaciones P2P

SDM 2.2 introdujo el control de aplicaciones P2P en la sección de configuración de firewall. El SDM aplicaba una política de QoS y Network-Based Application Recognition (Reconocimiento de Aplicaciones Basadas en Red, NBAR) para detectar y regular la actividad de las aplicaciones P2P a una velocidad de línea de cero, con lo cual se bloqueaba todo el tráfico P2P. Esto generaba un problema para los usuarios de la CLI, quienes esperaban poder utilizar P2P en la CLI de IOS Firewall pero no podían configurar el bloqueo de P2P en la CLI, a menos que conocieran la configuración de NBAR y QoS necesaria. Cisco IOS Software Release 12.4(9)T introduce el control nativo de P2P en la CLI de ZFW y aprovecha el NBAR para detectar la actividad de las aplicaciones P2P. Esta versión de software permite utilizar varios protocolos de aplicaciones P2P:

  • BitTorrent

  • eDonkey

  • FastTrack

  • Gnutella

  • KaZaA / KaZaA2

  • WinMX

Las aplicaciones P2P son especialmente difíciles de detectar debido al comportamiento de "cambio de puertos" (port-hopping) y otros trucos utilizados para evitar la detección, además de los problemas introducidos por los frecuentes cambios y actualizaciones de las aplicaciones P2P que modifican los comportamientos de los protocolos. ZFW combina la inspección nativa con estado del firewall con las capacidades de reconocimiento de tráfico de NBAR para realizar el control de aplicaciones P2P en la interfaz de configuración del CPL de ZFW. El NBAR ofrece dos excelentes beneficios:

  • Reconocimiento opcional de aplicaciones basado en la heurística para reconocer aplicaciones a pesar del comportamiento complejo y difícil de detectar.

  • Infraestructura extensible que ofrece un mecanismo de actualización para mantenerse al día de las actualizaciones y modificaciones de los protocolos.

Configuración de la Inspección P2P

Como se mencionó anteriormente, el control y la inspección de P2P ofrecen stateful inspection de capa 4 y control de aplicaciones de capa 7.

La inspección de capa 4 se configura de manera similar a otros servicios de aplicaciones, si se adecuara la inspección de los puertos de servicio de la aplicación nativa:

class-map type inspect match-any my-p2p-class
match protocol [bittorrent | edonkey | fasttrack | gnutella | kazaa | kazaa2 | winmx ] 
[signature (optional)]
!
policy-map type inspect private-allowed-policy
 class type inspect my-p2p-class
  [drop | inspect | pass]

Tenga presente la opción signature en match-protocol adicional en service-name. Al agregar la opción signature al final de la sentencia de match-protocol, la heurística del NBAR se aplica al tráfico para buscar delatores en el tráfico que indiquen actividad específica de aplicaciones P2P. Esto incluye los cambios de puertos y otros cambios del comportamiento de las aplicaciones para evitar la detección de tráfico. Este nivel de inspección de tráfico demanda una mayor utilización del CPU y reduce la capacidad de rendimiento de la red. Si no se aplica la opción signature, no se aplicará el análisis heurístico basado en el NBAR para detectar el comportamiento de cambio de puertos, y la utilización de CPU será menor.

La inspección de servicios nativa tiene la desventaja de no poder mantener el control sobre las aplicaciones P2P en el caso de que la aplicación "cambie" a un puerto de origen y de destino no estándar, o si la aplicación se actualiza para comenzar su acción en un número de puerto no reconocido:

Aplicación

Puertos Nativos (reconocidos por la lista de PAM 12.4(15)T)

bittorrent

TCP 6881-6889

edonkey

TCP 4662

fasttrack

TCP 1214

gnutella

TCP 6346-6349

TCP 6355,5634

UDP 6346-6348

kazaa2

Dependiente de PAM

winmx

TCP 6699

Si se desea permitir (inspeccionar) el tráfico P2P, es posible que se deba proporcionar una configuración adicional. Algunas aplicaciones pueden utilizar varias redes P2P o implementar comportamientos específicos que puede ser necesario admitir en la configuración del firewall para permitir que la aplicación funcione:

  • Los clientes BitTorrent generalmente se comunican con "rastreadores" (servidores de directorios de pares) a través de http ejecutado en un puerto no estándar. Por lo general, el puerto es TCP 6969, pero es posible que deba verificar el puerto del rastreador específico de Torrent. Si desea permitir BitTorrent, el mejor método para admitir el puerto adicional es configurar HTTP como uno de los protocolos de match y agregar TCP 6969 a HTTP utilizando el comando ip port-map:

    ip port-map http port tcp 6969
    

    Deberá definir http y bittorrent como los criterios de match aplicados en el class-map.

  • Aparentemente, eDonkey inicia conexiones que se detectan como eDonkey y Gnutella.

  • La inspección de KaZaA depende completamente de la detección de NBAR signatures.

La inspección (de aplicaciones) de capa 7 mejora la inspección de capa 4 con la capacidad de reconocer y aplicar acciones de servicios específicos, tales como permitir o bloquear de forma selectiva la búsqueda de archivos, la transferencia de archivos y las capacidades de conversación de texto. Las capacidades de servicios específicos varían según el servicio.

La inspección de aplicaciones P2P es similar a la inspección de aplicaciones HTTP:

!Configure las características del tráfico de capa 7:
class-map type inspect [p2p protocol] match-any p2p-l7-cmap
 match action
!
!Configure la acción que se aplicará al tráfico 
!que coincide con las características específicas:
policy-map type inspect [p2p protocol] p2p-l7-pmap
 class type inspect p2p p2p-l7-cmap
  [ reset | allow ]
  log
!
!Defina la política de inspección de capa 4
class-map type inspect match-all p2p-l4-cmap
 match protocol [p2p protocol]
!
!Asocie la clase de capa 4 y el policy-map de capa 7
!en el policy-map de capa 4:
policy-map type inspect private-allowed-policy
 class type inspect p2p-l4-cmap
  [ inspect | drop | pass ]
  service-policy p2p p2p-l7-pmap

La inspección de aplicaciones P2P ofrece capacidades de aplicaciones específicas para un subgrupo de las aplicaciones que la inspección de capa 4 permite utilizar:

  • edonkey

  • fasttrack

  • gnutella

  • kazaa2

Cada una de estas aplicaciones ofrece distintas opciones de criterios de match de aplicaciones específicas:

edonkey

router(config)#class-map type inspect edonkey match-any edonkey-l7-cmap
router(config-cmap)#match ?
  file-transfer     Match file transfer stream
  flow              Flow based QoS parameters
  search-file-name  Match file name
  text-chat         Match text-chat

fasttrack

router(config)#class-map type inspect fasttrack match-any ftrak-l7-cmap
router(config-cmap)#match ?
  file-transfer  File transfer stream
  flow           Flow based QoS parameters

gnutella

router(config)#class-map type inspect gnutella match-any gtella-l7-cmap
router(config-cmap)#match ?
  file-transfer  Match file transfer stream
  flow           Flow based QoS parameters

kazaa2

router(config)#class-map type inspect kazaa2 match-any kazaa2-l7-cmap
router(config-cmap)#match ?
  file-transfer  Match file transfer stream
  flow           Flow based QoS parameters

Las definiciones nuevas del protocolo P2P o las actualizaciones para los protocolos P2P actuales se pueden cargar utilizando la funcionalidad de actualización dinámica de PDLM de NBAR. El siguiente es el comando de configuración para cargar el PDLM nuevo:

ip nbar pdlm <file-location>

El protocolo nuevo está disponible en los comandos match protocol... para la inspección de tipos de clases. Si el protocolo P2P nuevo tiene servicios (subprotocolos), los nuevos tipos de class-maps de inspección de capa 7 y los criterios de match de capa 7 estarán disponibles.

Control e Inspección de Aplicaciones IM

Cisco IOS Software Release 12.4(4)T introdujo el control y la inspección de aplicaciones IM. La versión 12.4(6)T no permitía utilizar IM con ZFW, de modo que los usuarios no podían aplicar el control de IM y ZFW en la misma política de firewall, ya que ZFW y las características de firewall heredadas no pueden coexistir en una interfaz determinada.

Cisco IOS Software Release 12.4(9)T permite utilizar la stateful inspection y el control de aplicaciones para los siguientes servicios de IM:

  • AOL Instant Messenger

  • MSN Messenger

  • Yahoo! Messenger

La inspección de IM es ligeramente diferente de la mayoría de los servicios, ya que depende del control del acceso a un grupo específico de hosts de cada servicio determinado. Por lo general, los servicios de IM dependen de un grupo de servidores de directorios relativamente permanente, al cual los clientes se deben poder contactar para acceder al servicio de IM. Las aplicaciones de IM suelen ser muy difíciles de controlar desde el punto de vista de un servicio o un protocolo. La forma más efectiva de controlar estas aplicaciones es limitar el acceso a los servidores de IM fijos.

Configuración de la Inspección de IM

El control y la inspección de IM ofrece stateful inspection de capa 4 y control de aplicaciones de capa 7.

La inspección de capa 4 se configura de manera similar a otros servicios de aplicaciones:

class-map type inspect match-any my-im-class
match protocol [aol | msnmsgr | ymsgr ]
!
policy-map type inspect private-allowed-policy
 class type inspect my-im-class
  [drop | inspect | pass

Las aplicaciones de IM pueden contactarse con los servidores en varios puertos para mantener su funcionalidad. Si se desea permitir un servicio de IM determinado aplicando la acción Inspect, es posible que no se necesite una lista de servidores para definir el acceso permitido a los servidores del servicio de IM. Sin embargo, si se configura un class-map que especifica un servicio de IM determinado, tal como AOL Instant Messenger, y se aplica la acción Drop en el policy-map asociado, el cliente IM puede intentar ubicar un puerto diferente donde se permita la conectividad a Internet. Si no se desea permitir la conectividad a un servicio determinado, o si se desea restringir la capacidad del servicio de IM a la conversación de texto, se debe definir una lista de servidores para que el ZFW pueda identificar el tráfico asociado con la aplicación de IM:

!configure el parameter-map de la lista de servidores:
parameter-map type protocol-info <name>
  server name <name> 
  server ip a.b.c.d
  server ip range a.b.c.d a.b.c.d

Por ejemplo, la lista de servidores de IM de Yahoo se define de la siguiente forma:

parameter-map type protocol-info ymsgr-pmap
  server name scs.msg.yahoo.com
  server name scsd.msg.yahoo.com
  server ip 66.77.88.99
  server ip range 103.24.5.67 103.24.5.99

Deberá aplicar la lista de servidores a la definición de protocolos:

class-map type inspect match-any ym-l4-cmap
 match protocol ymsgr ymsgr-pmap

Debe configurar los comandos ip domain lookup y ip name-server ip.ad.re.ss para activar la resolución de nombres.

Los nombres de los servidores de IM son bastante dinámicos. Deberá verificar periódicamente que las listas de servidores de IM configurados estén completas y correctas.

La inspección (de aplicaciones) de capa 7 mejora la inspección de capa 4 con la capacidad de reconocer y aplicar acciones de servicios específicos, tales como permitir o bloquear de forma selectiva las capacidades de conversación de texto y denegar otras capacidades del servicio.

Actualmente, la inspección de aplicaciones de IM ofrece la capacidad de diferenciar entre la actividad de conversación de texto y todos los demás servicios de la aplicación. Para restringir la actividad de IM a la conversación de texto, configure una política de capa 7:

class-map type inspect ymsgr match-any ymsgr-text-cmap
  match service text-chat

class-map type inspect ymsgr match-any ymsgr-default-cmap
  match service any

policy-map type inspect im ymsgr-l7-pmap
  class type inspect im ymsgr-text-cmap
    allow
    [log]
  class type inspect im ymsgr-text-cmap
    reset
    [log]

Aplique la política de capa 7 a la política de Yahoo! Messenger configurada anteriormente:

class-map type inspect match-any my-im-class
match protocol ymsgr
!
policy-map type inspect private-allowed-policy
 class type inspect my-im-class
  inspect
  service-policy im ymsgr-l7-pmap

Filtrado de Direcciones URL

ZFW ofrece capacidades de filtrado de direcciones URL para limitar el acceso al contenido web según lo especificado en una lista blanca o negra definida en el router, o reenviar nombres de dominio a un servidor de filtrado de direcciones URL para verificar el acceso a dominios específicos. El filtrado de direcciones URL de ZFW en Cisco IOS Software Releases 12.4(6)T a 12.4(15)T se aplica como una acción de política adicional, similar a la inspección de aplicaciones.

Para el filtrado de direcciones URL basado en el servidor, se debe definir un parameter-map que describa la configuración del servidor urlfilter:

parameter-map type urlfilter websense-parmap
 server vendor [n2h2 | websense] 10.1.1.1

Si se prefieren listas blancas o negras estáticas, se puede definir una lista de dominios o subdominios que se permitan o denieguen específicamente, mientras que la acción inversa se aplica al tráfico que no coincide con la lista:

parameter-map type urlfilter websense-parmap
 exclusive-domain deny .disallowed.com
 exclusive-domain permit .cisco.com

Si se define una lista negra de direcciones URL utilizando opciones de negación en las definiciones de dominios exclusivos, se permitirán todos los otros dominios. Si se utilizan definiciones "Allow", se deben especificar explícitamente todos los dominios que se permitirán, de forma similar a la función de las listas de control de acceso IP.

Configure un class-map que coincida con el tráfico HTTP:

class-map type inspect match-any http-cmap
 match protocol http

Defina un policy-map que asocie el class-map con las acciones inspect y urlfilter:

policy-map type inspect http-filter-pmap
 class type inspect http-cmap
  inspect 
  urlfilter websense-parmap

Esto configura el requisito mínimo para comunicarse con un servidor de filtrado de direcciones URL. Existen varias opciones para definir un comportamiento adicional de filtrado de direcciones URL.

En algunas implementaciones de red, se puede desear aplicar el filtrado de direcciones URL para algunos hosts o algunas subredes y omitir el filtrado de direcciones URL para otros hosts. Por ejemplo, en la figura 9, un servidor de filtrado de direcciones URL debe controlar el tráfico HTTP de todos los hosts de la zona privada, a excepción del host específico 192.168.1.101.

Figura 9: Topología de Ejemplo de Filtrado de Direcciones URL

zone-design-guide10.gif

Esto se puede lograr definiendo dos class-maps diferentes:

  • Un class-map que sólo busque coincidencias del tráfico HTTP para el grupo mayor de hosts, que recibirá el filtrado de direcciones URL.

  • Un class-map para el grupo menor de hosts, que no recibirá el filtrado de direcciones URL. El segundo class-map buscará coincidencias del tráfico HTTP, además de una lista de hosts que se excluirán de la política de filtrado de direcciones URL.

Ambos class-maps están configurados en un policy-map, pero sólo uno recibirá la acción urlfilter:

class-map type inspect match-any http-cmap
 match protocol http
class-map type inspect match-all http-no-urlf-cmap
 match protocol http
 match access-group 101
!
policy-map type inspect http-filter-pmap
 class type inspect http-no-urlf-cmap
  inspect
 class type inspect http-cmap
  inspect 
  urlfilter websense-parmap
!
access-list 101 permit ip 192.168.1.101 any

Control de Acceso al Router

A la mayoría de los ingenieros especializados en seguridad de redes no les agrada la idea de exponer las interfaces de administración de un router (por ejemplo, SSH, Telnet, HTTP, HTTPS, SNMP, etc.) a la Internet pública y, en algunas circunstancias, también puede ser necesario controlar el acceso de las LAN al router. Cisco IOS Software ofrece varias opciones para limitar el acceso a las distintas interfaces, las cuales incluyen la familia de características Network Foundation Protections (NFP), diversos mecanismos de control de acceso para las interfaces de administración y la self-zone de ZFW. Se recomienda considerar otras características, tales como el control de acceso a terminales virtuales (VTY), la protección de planos de administración y el control de acceso a SNMP, para determinar la combinación de características de control de routers que funcionará mejor para su aplicación específica.

Por lo general, la familia de características de NFP es la mejor opción para el control del tráfico destinado al router. Consulte Descripción General de Seguridad de Planos de Control en Cisco IOS Software para obtener información sobre la protección de routers mediante las características de NFP.

Si decide aplicar ZFW para controlar el tráfico hacia y desde las direcciones IP del router, debe comprender que la política y las capacidades predeterminadas del firewall difieren de aquéllas disponibles para el tráfico de tránsito. El tráfico de tránsito se define como el tráfico de red cuyas direcciones IP de origen y destino no coinciden con ninguna dirección IP aplicada a ninguna de las interfaces del router, y el tráfico no hará que el router envíe, por ejemplo, mensajes de control de red tales como ICMP TTL expiration or network/host unreachable.

ZFW aplica una política predeterminada de negación total al tráfico que se mueve entre zonas, excepto, como se mencionó en las reglas generales, el tráfico de cualquier zona que fluye directamente a las direcciones de las interfaces del router, el cual está implícitamente permitido. Esto garantiza que se mantenga la conectividad a las interfaces de administración del router cuando se aplica una configuración de firewall por zonas al router. Si la misma política de negación total afectara la conectividad directa al router, se debería aplicar una configuración de política de administración completa antes de configurar las zonas en el router. Es probable que esto afecte la conectividad de administración si la política no se implementa apropiadamente o no se aplica en el orden correcto.

Cuando se configura una interfaz para ser miembro de una zona, los hosts conectados con la interfaz se incluyen en la zona. Sin embargo, el tráfico que fluye hacia y desde las direcciones IP de las interfaces del router no se controla según las políticas de zonas (a excepción de las circunstancias descritas en la nota posterior a la figura 10). En cambio, cuando se configura ZFW, todas las interfaces IP del router pasan a formar parte automáticamente de la self-zone. Para controlar el tráfico IP que se mueve hacia las interfaces del router desde las distintas zonas del router, se deben aplicar políticas para bloquear o permitir/inspeccionar el tráfico entre la zona y la self-zone del router y viceversa. (Vea la figura 10).

Figura 10: Aplicación de una Política entre las Zonas de Red y la Self-Zone del Router

zone-design-guide11.gif

Si bien el router ofrece una política predeterminada de permiso entre todas las zonas y la self-zone, si se configura una política de cualquier zona a la self-zone y no se configura una política de la self-zone a las zonas del router conectadas por interfaces configuradas por el usuario, todo el tráfico originado en el router se encuentra con la política de zonas conectadas a la self-zone durante su regreso al router y se bloquea. Por lo tanto, se debe inspeccionar el tráfico originado en el router para permitir su retorno a la self-zone.

Nota: Cisco IOS Software siempre utiliza la dirección IP asociada con la interfaz "más cercana" a los hosts de destino para el tráfico como syslog, tftp, Telnet y otros servicios de planos de control, y somete este tráfico a la política de firewall de la self-zone. Sin embargo, si un servicio define una interfaz específica como la interfaz de origen utilizando comandos que incluyen, entre otros, logging source-interface [type number], ip tftp source-interface [type number] e ip telnet source-interface [type number], el tráfico se somete a la política de firewall de zona a zona para la zona de la interfaz de origen y la zona de seguridad del host de destino. Si se configura un servicio para utilizar una interfaz que se asigna a una zona de seguridad específica, no se aplica la política de self-zone al tráfico de ese servicio.

Nota: Algunos servicios (especialmente los servicios de voz por IP de los routers) utilizan interfaces efímeras o no configurables que no se pueden asignar a las zonas de seguridad. Es posible que estos servicios no funcionen correctamente si no se puede asociar el tráfico con una zona de seguridad configurada. Si se configura el servicio para utilizar una de las interfaces físicas o virtuales configurables del dispositivo, el tráfico se debe procesar según la política de la zona de seguridad correspondiente a esa interfaz.

Limitaciones de la Política de Self-Zone

La política de self-zone tiene una funcionalidad limitada en comparación con las políticas disponibles para los pares de zonas de tráfico en tránsito:

  • Al igual que ocurría con la stateful inspection clásica, el tráfico generado por el router está limitado a TCP, UDP, ICMP y la inspección de protocolos complejos para H.323.

  • La inspección de aplicaciones no está disponible para las políticas de self-zone.

  • La limitación de sesión y velocidad no se puede configurar en las políticas de self-zone.

Configuración de la Política de Self-Zone

En la mayoría de las circunstancias, se recomiendan las siguientes políticas de acceso para los servicios de administración de routers:

  • Deniegue toda la conectividad Telnet, ya que el protocolo de texto sin encriptar de Telnet expone fácilmente las credenciales de usuario y otros datos confidenciales.

  • Permita las conexiones de Secure Shell (SSH) de cualquier usuario en cualquier zona. SSH encripta las credenciales de usuario y los datos de sesión, lo cual brinda protección contra usuarios maliciosos que utilicen herramientas de captura de paquetes para indagar la actividad del usuario y comprometer las credenciales de usuario u otros datos confidenciales, como la configuración del router. La versión 2 de SSH brinda una protección más fuerte y soluciona las vulnerabilidades específicas de la versión 1 de SSH.

  • Permita la conectividad HTTP al router desde las zonas privadas, si la zona privada es confiable. De lo contrario, si la zona privada pudiera permitir que usuarios maliciosos comprometan la información, HTTP no utiliza encriptado para proteger el tráfico de administración y se pueden revelar datos confidenciales, tal como la configuración o las credenciales de usuario.

  • Permita la conectividad HTTPS desde cualquier zona. Al igual que SSH, HTTPS encripta los datos de sesión y las credenciales de usuario.

  • Restrinja el acceso SNMP a una subred o un host específicos. SNMP se puede utilizar para modificar la configuración del router y revelar información sobre la configuración. SNMP se debe configurar con control de acceso en las distintas comunidades.

  • Bloquee las peticiones ICMP de la Internet pública a la dirección de zona privada (asumiendo que la dirección de zona privada es ruteable). Si es necesario, se pueden exponer una o más direcciones públicas para el tráfico ICMP a fin de resolver problemas de red. Se pueden utilizar varios ataques de ICMP para saturar los recursos de router o reconocer la topología y la arquitectura de la red.

Un router puede aplicar este tipo de política con la incorporación de dos pares de zonas para cada zona que se debe controlar. Cada zone-pair para el tráfico entrante o saliente de la self-zone del router debe coincidir con la política respectiva en la dirección opuesta, a menos que no se origine tráfico en la dirección opuesta. Se puede aplicar un policy-map para los pares de zonas entrantes y salientes, en el cual se describa todo el tráfico, o se pueden aplicar policy-maps específicos para cada zone-pair. La configuración de pares de zonas específicos por policy-map proporciona granularity (especificidad) para ver la actividad que coincide con cada policy-map.

Considerando un ejemplo de red con una estación de administración SNMP en 172.17.100.11 y un servidor TFTP en 172.17.100.17, esta salida proporciona un ejemplo de toda la política de acceso de interfaces de administración:

class-map type inspect match-any self—service-cmap
 match protocol tcp
 match protocol udp
 match protocol icmp
 match protocol h323
!
class-map type inspect match-all to-self-cmap
 match class-map self—service-cmap
 match access-group 120
!
class-map type inspect match-all from-self-cmap
 match class-map self—service-cmap
!
class-map type inspect match-all tftp-in-cmap
 match access-group 121
!
class-map type inspect match-all tftp-out-cmap
 match access-group 122
!
policy-map type inspect to-self-pmap
 class type inspect to-self-cmap
  inspect
 class type inspect tftp-in-cmap
  pass
!
policy-map type inspect from-self-pmap
 class type inspect from-self-cmap
  inspect
 class type inspect tftp-out-cmap
  pass
!
zone security private
zone security internet
zone-pair security priv-self source private destination self
 service-policy type inspect to-self-pmap
zone-pair security net-self source internet destination self
 service-policy type inspect to-self-pmap
zone-pair security self-priv source self destination private 
 service-policy type inspect from-self-pmap
zone-pair security self-net source self destination internet
 service-policy type inspect from-self-pmap

!
interface FastEthernet 0/0
 ip address 172.16.100.10
 zone-member security internet
!
interface FastEthernet 0/1
 ip address 172.17.100.10
 zone-member security private
!
access-list 120 permit icmp 172.17.100.0 0.0.0.255 any
access-list 120 permit icmp any host 172.17.100.10 echo
access-list 120 deny icmp any any
access-list 120 permit tcp 172.17.100.0 0.0.0.255 host 172.17.100.10 eq www
access-list 120 permit tcp any any eq 443
access-list 120 permit tcp any any eq 22
access-list 120 permit udp any host 172.17.100.10 eq snmp
access-list 121 permit udp host 172.17.100.17 host 172.17.100.10 
access-list 122 permit udp host 172.17.100.10 host 172.17.100.17

Lamentablemente, la política de self-zone no ofrece la capacidad de inspeccionar las transferencias TFTP. Por lo tanto, el firewall debe pasar todo el tráfico desde y hacia el servidor TFTP si el TFTP debe pasar a través del firewall.

Si el router finalizará conexiones VPN IPSec, también se debe definir una política para pasar IPSec ESP, IPSec AH, ISAKMP y NAT-T IPSec (UDP 4500). Esto depende de lo que se necesite según los servicios que se utilizarán. Además de la política anterior, se puede aplicar la siguiente política. Tenga presente el cambio realizado en los policy-maps en los que se insertó un class-map para el tráfico VPN con una acción pass. Por lo general, el tráfico encriptado es confiable, a menos que la política de seguridad establezca que se debe permitir el tráfico encriptado desde y hacia puntos finales especificados.

class-map type inspect match-all crypto-cmap
 match access-group 123
!
policy-map type inspect to-self-pmap
 class type inspect crypto-cmap
  pass
 class type inspect to-self-cmap
  inspect
 class type inspect tftp-in-cmap
  pass
!
policy-map type inspect from-self-pmap
 class type inspect crypto-cmap
  pass
 class type inspect from-self-cmap
  inspect
 class type inspect tftp-out-cmap
  pass
!
access-list 123 permit esp any any
access-list 123 permit udp any any eq 4500
access-list 123 permit ah any any 
access-list 123 permit udp any any eq 500

Zone-Based Firewall y Wide-Area Application Services

Consulte Nota de Versión de Cisco Wide Area Application Services (Versión de Software 4.0.13): Nuevas Características de la Versión de Software 4.0.13 para obtener una nota sobre la aplicación que proporciona ejemplos de configuración y una guía de uso.

Monitoreo de Zone-Based Policy Firewall con Comandos Show y Debug

ZFW introduce nuevos comandos para ver la configuración de políticas y supervisar la actividad del firewall.

Para mostrar la descripción de la zona y las interfaces contenidas en una zona especificada:

show zone security [<zone-name>]

Cuando no se incluye el nombre de la zona, el comando muestra la información de todas las zonas configuradas.

Router#show zone security z1
zone z1
  Description: this is test zone1
  Member Interfaces:
    Ethernet0/0

Para mostrar la zona de origen, la zona de destino y la política adjunta al zone-pair:

show zone-pair security [source <source-zone-name>] [destination <destination-zone-name>]

Cuando no se especifica el origen ni el destino, se muestran todos los pares de zonas con origen, destino y política asociada. Cuando sólo se menciona la zona de origen o destino, se muestran todos los pares de zonas que contienen esta zona como origen o destino.

Router#show zone-pair security        
zone-pair name zp
  Source-Zone z1  Destination-Zone z2 
  service-policy p1

Para mostrar un policy-map especificado:

show policy-map type inspect [<policy-map-name> [class <class-map-name]]

Cuando no se especifica el nombre de un policy-map, se muestran todos los policy-maps del tipo Inspect (incluidos los policy-maps de capa 7 que contienen un subtipo).

Router#show policy-map type inspect p1
 Policy Map type inspect p1
   Class c1
    Inspect

Para mostrar las estadísticas de policy-maps del tipo Inspect en tiempo de ejecución que existen en un zone-pair especificado.

show policy-map type inspect zone-pair [zone-pair-name] [sessions]

Cuando no se menciona no zone-pair name, se muestran los policy-maps de todos los pares de zonas.

La opción sessions muestra las sesiones de inspección creadas por la aplicación del policy-map en el zone-pair especificado.

Router#show policy-map type inspect zone-pair zp
 Zone-pair: zp

  Service-policy : p1

    Class-map: c1 (match-all)
      Match: protocol tcp
      Inspect
        Session creations since subsystem startup or last reset 0
        Current session counts (estab/half-open/terminating) [0:0:0]
        Maxever session counts (estab/half-open/terminating) [0:0:0]
        Last session created never
        Last statistic reset never
        Last session creation rate 0
        Last half-open session total 0   

    Class-map: c2 (match-all)
      Match: protocol udp
      Pass
        0 packets, 0 bytes

    Class-map: class-default (match-any)
      Match: any
      Drop
        0 packets, 0 bytes

La palabra clave urlfilter muestra las estadísticas relacionadas con el filtro de direcciones URL que corresponden al policy-map especificado (o de los policy-maps de todos los destinos cuando no se especifica un nombre de zone-pair):

show policy-map type inspect zone-pair [zone-pair-name] [urlfilter [cache]]

Cuando se especifica la palabra clave cache junto con urlfilter, se muestra la memoria caché de urlfilter (de las direcciones IP).

Resumen del comando show policy-map para los policy-maps Inspect:

show policy-map type inspect inspect { <policy name> [class <class name>] |
                      zone-pair [<zone-pair name>] [sessions | urlfilter cache] }

Tuning (ajustando) la protección de ZFW contra Negación de Servicio (DoS)

ZFW ofrece protección contra DoS para alertar a los ingenieros de red sobre cambios importantes en la actividad de la red y para mitigar la actividad no deseada a fin de reducir el impacto de los cambios en la actividad de la red. ZFW mantiene un contador separado para cada class-map del policy-map. Por lo tanto, si se utiliza un class-map para dos policy-maps de distintos pares de zonas, se aplicarán dos grupos diferentes de contadores de protección contra DoS.

ZFW proporciona mitigación de ataques de DoS de forma predeterminada en versiones anteriores a Cisco IOS Software Release 12.4(11)T. El comportamiento de protección contra DoS predeterminado cambió en Cisco IOS Software Release 12.4(11)T. Consulte Ajuste de la Protección contra Negación de Servicio (DoS) en Cisco IOS Firewall para obtener más información y el procedimiento para ajustar la protección contra DoS en ZFW.

Consulte Definición de Estrategias para Protegerse contra los Ataques de Negación de Servicio TCP SYN para obtener más información sobre los ataques de DoS TCP SYN.

Apéndice

Apéndice A: Configuración Básica

ip subnet-zero
ip cef
!
bridge irb
!
interface FastEthernet0
 ip address 172.16.1.88 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet1
 ip address 172.16.2.1 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet2
 switchport access vlan 2
!
interface FastEthernet3
 switchport access vlan 2
!
interface FastEthernet4 
 switchport access vlan 1
!
interface FastEthernet5 
 switchport access vlan 1
!
interface FastEthernet6 
 switchport access vlan 1
!
interface FastEthernet7 
 switchport access vlan 1
!
interface Vlan1
 no ip address
 bridge-group 1
!
interface Vlan2
 no ip address
 bridge-group 1
!
interface BVI1
 ip address 192.168.1.254 255.255.255.0
 ip route-cache flow
!
ip classless
ip route 0.0.0.0 0.0.0.0 172.16.1.1
!
bridge 1 protocol ieee
bridge 1 route ip
!
end

Apéndice B: Configuración Final (Completa)

ip subnet-zero
ip cef
!
ip port-map user-Xwindows port tcp from 6900 to 6910
!
class-map type inspect match-any L4-inspect-class
 match protocol tcp
 match protocol udp
 match protocol icmp
class-map type inspect match-any L7-inspect-class
  match protocol ssh
  match protocol ftp
  match protocol pop
  match protocol imap
  match protocol esmtp
  match protocol http
class-map type inspect match-any dns-http-class
 match protocol dns
 match protocol http
class-map type inspect match-any smtp-class
 match protocol smtp
class-map type inspect match-all dns-http-acl-class
 match access-group 110
 match class-map dns-http-class
class-map type inspect match-all smtp-acl-class
 match access-group 111
 match class-map smtp-class
class-map type inspect match-any Xwindows-class
 match protocol user-Xwindows
class-map type inspect match-any internet-traffic-class
 match protocol http
 match protocol https
 match protocol dns
 match protocol icmp
class-map type inspect http match-any bad-http-class
 match  port-misuse all
 match  strict-http
!
policy-map type inspect clients-servers-policy
 class type inspect L4-inspect-class
  inspect
policy-map type inspect private-dmz-policy
  class type inspect L7-inspect-class
   inspect
policy-map type inspect internet-dmz-policy
 class type inspect dns-http-acl-class
  inspect
 class type inspect smtp-acl-class
  inspect
policy-map type inspect servers-clients-policy
 class type inspect Xwindows-class
  inspect
policy-map type inspect private-internet-policy
  class type inspect internet-traffic-class
   inspect
  class type inspect bad-http-class
   drop
!
zone security clients
zone security servers
zone security private
zone security internet
zone security dmz
zone-pair security private-internet source private destination internet
  service-policy type inspect private-internet-policy
zone-pair security servers-clients source servers destination clients
  service-policy type inspect servers-clients-policy
zone-pair security clients-servers source clients destination servers
  service-policy type inspect clients-servers-policy
zone-pair security private-dmz source private destination dmz
  service-policy type inspect private-dmz-policy
zone-pair security internet-dmz source internet destination dmz
  service-policy type inspect internet-dmz-policy
!
bridge irb
!
interface FastEthernet0
 ip address 172.16.1.88 255.255.255.0
 zone-member internet
!
interface FastEthernet1
 ip address 172.16.2.1 255.255.255.0
 zone-member dmz
!
interface FastEthernet2
 switchport access vlan 2
!
interface FastEthernet3
 switchport access vlan 2
!
interface FastEthernet4 
 switchport access vlan 1
!
interface FastEthernet5 
 switchport access vlan 1
!
interface FastEthernet6 
 switchport access vlan 1
!
interface FastEthernet7 
 switchport access vlan 1
!
interface Vlan1
 no ip address
 zone-member clients 
 bridge-group 1
!
interface Vlan2
 no ip address
 zone-member servers
 bridge-group 1
!
interface BVI1
 ip address 192.168.1.254 255.255.255.0
 zone-member private
!
ip classless
ip route 0.0.0.0 0.0.0.0 172.16.1.1
!
access-list 110 permit ip any host 172.16.2.2
access-list 111 permit ip any host 172.16.2.3
!
bridge 1 protocol ieee
bridge 1 route ip
!
End

Apéndice C: Configuración Básica de Zone-Policy Firewall para Dos Zonas

En este ejemplo, se proporciona una configuración simple como base para probar las características de las mejoras introducidas en el ZFW con Cisco IOS Software. Esta configuración es un modelo de configuración para dos zonas, configuradas en un router 1811. La zona privada se aplica a los puertos de switch fijos del router, de modo que todos los hosts de los puertos de switch se conectan a la VLAN 1. La zona pública se aplica a FastEthernet 0.

zone-design-guide12.gif

class-map type inspect match-any private-allowed-class
 match protocol tcp
 match protocol udp
 match protocol icmp
class-map type inspect match-all http-class
 match protocol http
!
policy-map type inspect private-allowed-policy
 class type inspect http-class
  inspect my-parameters
 class type inspect private-allowed-class
  inspect
!
zone security private
zone security public
zone-pair security priv-pub source private destination public
 service-policy type inspect private-allowed-policy
!
interface fastethernet 0
 zone-member security public
!
Interface VLAN 1
 zone-member security private

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Document ID: 98628