Segurança : Cisco IOS Firewall

Guia de Design e Aplicativo de Firewall de Política Baseada em Zonas

17 Julho 2008 - Tradução Manual
Outras Versões: Versão em PDFpdf | Tradução por Computador (29 Julho 2013) | Inglês (27 Dezembro 2010) | Feedback

Índice

Introdução
Pré-requisitos
      Requisitos
      Componentes Utilizados
      Convenções
Visão Geral da Política Baseada em Zonas
Modelo de Configuração de Política Baseada em Zonas
Regras para Aplicação do Firewall de Política Baseada em Zonas
Projetando a Segurança da Rede de Política Baseada em Zonas
Utilizando uma VPN IPSec com o Firewall de Política Baseada em Zonas
Configuração da CPL (Cisco Policy Language)
      Configurando Class-Maps do Firewall de Política Baseada em Zonas
      Configurando Policy-Maps do Firewall de Política Baseada em Zonas
      Configurando Parameter-Maps do Firewall de Política Baseada em Zonas
      Aplicando o Log às Políticas do Firewall de Política Baseada em Zonas
      Editando Policy-Maps e Class-Maps do Firewall de Política Baseada em Zonas
Exemplos de Configuração
      Firewall de Roteamento de Inspeção Stateful
      Firewall Transparente de Inspeção Stateful
      Política de Taxas do Firewall de Política Baseada em Zonas
      Inspeção de Aplicativos
      Filtragem de URL
      Controlando o Acesso ao Roteador
Firewall Baseado em Zonas e Wide-Area Application Services
Monitorando o Firewall de Política Baseada em Zonas com Comandos show e debug
Ajustando a Proteção de Negação de Serviço do Firewall de Política Baseada em Zonas
Apêndice
      Apêndice A: Configuração Básica
      Apêndice B: Configuração Final (Completa)
      Apêndice C: Configuração Básica do Firewall de Política de Zonas para Duas Zonas
Discussões relacionadas da comunidade de suporte da Cisco

Introdução

O Cisco IOS® Software Release 12.4(6)T introduziu o Firewall de Política Baseada em Zonas (ZFW), um novo modelo de configuração do conjunto de recursos do Cisco IOS Firewall. Esse novo modelo de configuração oferece políticas intuitivas para roteadores com várias interfaces, maior granularidade da aplicação de políticas de firewall e uma política de negação total padrão que proíbe o tráfego entre as zonas de segurança do firewall até que uma política explícita seja aplicada para permitir o tráfego desejável.

Praticamente todos os recursos do Cisco IOS Firewall clássico implementados antes do Cisco IOS Software Release 12.4(6)T possuem suporte na nova interface de inspeção de políticas baseada em zonas:

  • Inspeção stateful de pacotes

  • Cisco IOS Firewall com reconhecimento de VRF

  • Filtragem de URL

  • Mitigação de DoS (Negação de Serviço)

O Cisco IOS Software Release 12.4(9)T adicionou o suporte a limites de taxa de transferência e sessão/conexão por classe, bem como à inspeção e ao controle de aplicativos:

  • HTTP

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

  • Sun RPC (Remote Procedure Call)

  • Aplicativos de IM (Mensagens Instantâneas):

    • Microsoft Messenger

    • Yahoo! Messenger

    • AOL Instant Messenger

  • Compartilhamento de Arquivos P2P (Peer-to-Peer):

    • Bittorrent

    • KaZaA

    • Gnutella

    • eDonkey

O Cisco IOS Software Release 12.4(11)T adicionou estatísticas para facilitar o ajuste da proteção de DoS.

Ainda não há suporte para alguns recursos do Cisco IOS Classic Firewall em um ZFW no Cisco IOS Software Release 12.4(15)T:

  • Proxy de autenticação

  • Failover stateful de firewall

  • MIB de firewall unificado

  • Inspeção stateful de IPv6

  • Suporte a pacotes TCP fora de ordem

Em geral, o ZFW melhora o desempenho do Cisco IOS na maioria das atividades de inspeção de firewall.

Nem o ZFW do Cisco IOS nem o Classic Firewall oferecem suporte à inspeção stateful de tráfego de multicast.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

Convenções

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre as convenções de documentos.

Visão Geral da Política Baseada em Zonas

A inspeção stateful do Cisco IOS Classic Firewall (conhecida anteriormente como Controle de Acesso Baseado em Contexto ou CBAC) utilizava um modelo de configuração baseado em interface, no qual uma política de inspeção stateful era aplicada a uma interface. Todo o tráfego que passasse por essa interface recebia a mesma política de inspeção. Esse modelo de configuração limitava a granularidade das políticas de firewall e gerava confusão quanto à aplicação adequada dessas políticas, especialmente nos cenários em que era necessário aplicá-las entre várias interfaces.

O Firewall de Política Baseada em Zonas (também conhecido como Firewall de Política de Zonas ou ZFW) altera a configuração de firewall do antigo modelo baseado em interface para um modelo baseado em zonas mais flexível e de mais fácil compreensão. As interfaces são atribuídas a zonas, e a política de inspeção é aplicada ao tráfego entre as zonas. Como as políticas entre zonas oferecem flexibilidade e granularidade consideráveis, diferentes políticas de inspeção podem ser aplicadas a vários grupos de hosts conectados à mesma interface do roteador.

As políticas de firewall são configuradas com a CPL (Cisco® Policy Language), a qual utiliza uma estrutura hierárquica para definir a inspeção que será aplicada aos protocolos de rede e aos grupos de hosts.

Modelo de Configuração de Política Baseada em Zonas

Com o ZFW, uma inspeção do Cisco IOS Firewall é configurada de maneira totalmente diferente de uma inspeção do Cisco IOS Classic Firewall.

A primeira mudança importante na configuração do firewall é a introdução da configuração baseada em zonas. O Cisco IOS Firewall é o primeiro recurso de defesa contra ameaças do Cisco IOS Software a implementar um modelo de configuração de zonas. É possível que outros recursos venham a adotar o modelo de zonas com o tempo. O modelo de configuração baseado em interface (ou CBAC) da inspeção stateful do Cisco IOS Classic Firewall que utiliza o conjunto de comandos ip inspect será mantido por um certo período. Entretanto, poucos, se houver, novos recursos são configuráveis com a interface de linha de comando (CLI) clássica. O ZFW não utiliza a inspeção stateful nem comandos CBAC. Os dois modelos de configuração podem ser utilizados simultaneamente em roteadores, mas não podem ser combinados em interfaces. Não é possível configurar uma interface como membro de uma zona de segurança e para ip inspect simultaneamente.

As zonas estabelecem os limites de segurança da rede. Elas definem uma fronteira na qual o tráfego estará sujeito às restrições de uma política ao passar para outra área da rede. A política padrão do ZFW entre zonas é a negação total. Se nenhuma política for configurada explicitamente, todo o tráfego entre as zonas será bloqueado. Essa é uma diferença significativa em relação ao modelo de inspeção stateful no qual o tráfego era permitido implicitamente até ser explicitamente bloqueado com uma lista de controle de acesso (ACL).

A segunda mudança importante é a introdução de uma nova linguagem de política de configuração conhecida como CPL. Os usuários que estão familiarizados com a CLI de qualidade de serviço modular do Cisco IOS Software talvez reconheçam que o formato é semelhante ao uso de mapas de classes do QoS para especificar qual tráfego será afetado pela ação aplicada em um mapa de políticas.

Regras para Aplicação do Firewall de Política Baseada em Zonas

A associação das interfaces de rede do roteador em zonas está sujeita a várias regras que controlam o comportamento da interface, e o mesmo ocorre com o tráfego entre as interfaces que são membros da zona:

  • É necessário configurar uma zona antes de atribuir interfaces a ela.

  • Uma interface só pode ser atribuída a uma única zona de segurança.

  • Todo o tráfego de entrada e saída de determinada interface é bloqueado implicitamente quando a interface é atribuída a uma zona; a exceção é o tráfego de entrada e saída de outras interfaces da mesma zona e o tráfego para qualquer interface do roteador.

  • Por padrão, o fluxo de tráfego entre as interfaces membros da mesma zona é permitido implicitamente.

  • Para permitir o tráfego de entrada e saída de uma interface membro da zona, é necessário configurar uma política que permita ou inspecione o tráfego entre essa e qualquer outra zona.

  • A zona "auto" é a única exceção à política padrão de negação total. Todo o tráfego para qualquer interface do roteador é permitido até ser explicitamente negado.

  • Não é permitido o tráfego entre uma interface membro da zona e qualquer interface que não seja membro dessa zona. As ações passar, inspecionar e descartar só podem ser aplicadas entre duas zonas.

  • As interfaces que não tiverem sido atribuídas a uma zona funcionam como as portas clássicas de um roteador e ainda podem utilizar a configuração de CBAC/inspeção stateful clássica.

  • Caso uma interface do roteador não deva fazer parte da política de zonas/firewall, talvez ainda seja necessário colocá-la em uma zona e configurar uma política de passagem total (como uma política fictícia) entre essa e qualquer outra zona para a qual o fluxo de tráfego seja desejado.

  • Com resultado, caso o tráfego deva passar entre todas as interfaces de um roteador, todas elas devem fazer parte do modelo de zonas (cada interface deve ser membro de uma zona ou de outra).

  • A única exceção à abordagem anterior de negação por padrão é o tráfego de entrada e saída do roteador, o qual será permitido por padrão. Uma política explícita poderá ser configurada para restringir esse tráfego.

Projetando a Segurança da Rede de Política Baseada em Zonas

Uma zona de segurança deve ser configurada para cada região de relativa segurança na rede, de modo que todas as interfaces atribuídas à mesma zona sejam protegidas com um nível semelhante de segurança. Por exemplo, considere um roteador de acesso com três interfaces:

  • Uma interface conectada à Internet pública.

  • Uma interface conectada a uma LAN privada que não deve estar acessível na Internet pública.

  • Uma interface conectada a uma zona desmilitarizada (DMZ) de serviços da Internet, onde um servidor Web, um servidor DNS (Sistema de Nomes de Domínio) e um servidor de email devem estar acessíveis à Internet pública.

Cada interface dessa rede será atribuída à sua própria zona, embora você possa permitir diversos tipos de acesso da Internet pública a hosts específicos na DMZ e diversas políticas de uso de aplicativos para hosts na LAN protegida. (Consulte a Figura 1).

Figura 1: Topologia Básica de Zona de Segurança

zone-design-guide1.gif

Neste exemplo, cada zona contém apenas uma interface. Se outra interface for adicionada à zona privada, os hosts conectados à nova interface na zona poderão enviar o tráfego para todos os hosts na interface existente na mesma zona. Além disso, o tráfego dos hosts para hosts em outras zonas é afetado de maneira semelhante pelas políticas existentes.

Normalmente, a rede de exemplo terá três políticas principais:

  • Conectividade da zona privada com a Internet

  • Conectividade da zona privada com os hosts da DMZ

  • Conectividade da zona da Internet com os hosts da DMZ

Como a DMZ está exposta à Internet pública, os hosts da DMZ podem ficar sujeitos à atividade indesejada de indivíduos mal-intencionados que poderiam comprometer um ou mais desses hosts. Se não houver uma política de acesso que permita aos hosts da DMZ se conectarem aos da zona privada ou aos da zona da Internet, os indivíduos que comprometerem os hosts da DMZ não poderão utilizá-los para realizar outros ataques contra hosts privados ou da Internet. O ZFW impõe uma postura de segurança padrão proibitiva. Portanto, a menos que os hosts da DMZ recebam especificamente permissão para acessar outras redes, essas redes estarão protegidas contra quaisquer conexões desses hosts. Da mesma forma, como os hosts da Internet não têm permissão para acessar os da zona privada, esses hosts estão protegidos contra o acesso indesejado dos hosts da Internet.

Utilizando a VPN IPSec com o Firewall de Política Baseada em Zonas

As melhorias introduzidas recentemente na VPN IPSec simplificam a configuração de políticas de firewall para conectividade de VPNs. A VTI (Virtual Tunnel Interface) IPSec e o GRE+IPSec permitem o confinamento de conexões VPN site-a-site e de cliente em uma zona de segurança específica ao colocar as interfaces de túnel em uma zona de segurança especificada. As conexões poderão ser isoladas em uma DMZ da VPN caso a conectividade deva ser limitada por uma política específica. Ou, se a conectividade de VPN for implicitamente confiável, ela poderá ser colocada na mesma zona de segurança que a rede interna confiável.

Se um IPSec não-VTI for aplicado, será necessário um rígido controle da política de firewall de conectividade de VPN a fim de manter a segurança. A política de zonas deverá permitir especificamente o acesso de clientes VPN ou de hosts de sites remotos por um endereço IP se os hosts seguros estiverem em uma zona diferente da conexão criptografada do cliente VPN com o roteador. Se a política de acesso não estiver configurada corretamente, os hosts que devem ser protegidos poderão ficar expostos a hosts indesejados e potencialmente hostis. Consulte Utilizando a VPN com o Firewall de Política Baseada em Zonas para obter uma análise detalhada dos conceitos e da configuração.

Configuração da CPL (Cisco Policy Language)

Este procedimento pode ser utilizado para configurar um ZFW. A seqüência de passos não é importante, mas alguns eventos devem ser concluídos em ordem. Por exemplo, é necessário configurar um class-map antes de atribuí-lo a um policy-map. Da mesma forma, não será possível atribuir um policy-map a um zone pair até que a política seja configurada. Se você tentar configurar uma seção que dependa de outra parte da configuração ainda não definida, o roteador responderá com uma mensagem de erro.

  1. Definir zonas.

  2. Definir zone pairs.

  3. Definir class-maps que descrevam o tráfego ao qual uma política deverá ser aplicada quando ele atravessar um zone pair.

  4. Definir policy-maps a fim de aplicar uma ação ao tráfego dos class-maps.

  5. Aplicar policy-maps aos zone pairs.

  6. Atribuir interfaces às zonas.

Configurando Class-Maps do Firewall de Política Baseada em Zonas

Os class-maps definem o tráfego selecionado pelo firewall para aplicação de uma política. Os class-maps da Camada 4 classificam o tráfego com base nos critérios listados aqui. Esses critérios são especificados com o uso do comando match em um class-map:

  • Access-group — Uma ACL padrão, estendida ou nomeada pode filtrar o tráfego com base no endereço IP de origem e de destino, bem como na porta de origem e de destino.

  • Protocol — Os protocolos da Camada 4 (TCP, UDP e ICMP) e os serviços de aplicativo como HTTP, SMTP, DNS etc. Qualquer serviço conhecido ou definido pelo usuário reconhecido pelo Port-Application Mapping pode ser especificado.

  • Class-map — Um class-map subordinado que fornece critérios adicionais de correspondência que podem ser aninhados em outro class-map.

  • Not — O critério not especifica que qualquer tráfego que não corresponda a um serviço (protocolo), grupo de acesso ou class-map subordinado especificado será selecionado para o class-map.

Combinando Critérios de Correspondência: “Match-Any” versus “Match-All”

Os class-maps podem aplicar operadores match-any ou match-all para determinar como os critérios de correspondência devem ser aplicados. Se match-any for especificado, o tráfego deverá atender somente a um dos critérios de correspondência do class-map. Se match-all for especificado, o tráfego deverá atender a todos os critérios do class-map para pertencer à classe especificada.

Os critérios de correspondência deverão ser aplicados do mais para o menos específico, caso o tráfego atenda a vários critérios. Por exemplo, considere este class-map:

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

O tráfego HTTP deverá encontrar primeiro a instrução match protocol http para que seja tratado pelos recursos específicos de serviço da inspeção de HTTP. Se as linhas de correspondência forem invertidas, de modo que o tráfego encontre a instrução match protocol tcp antes de compará-la com match protocol http, ele será simplesmente classificado como tráfego TCP e inspecionado de acordo com os recursos do componente de Inspeção de TCP do Firewall. Esse é um problema para certos serviços como FTP, TFTP e para vários serviços de multimídia e sinalização de voz, como H.323, SIP, Skinny, RTSP entre outros. São necessários recursos adicionais de inspeção para o reconhecimento das atividades mais complexas desses serviços.

Aplicando uma ACL como Critério de Correspondência

Os class-maps podem utilizar uma ACL como um dos critérios de correspondência para a aplicação de políticas. Se o único critério de correspondência de um class-map for uma ACL, e esse class-map estiver associado a um policy-map que aplique a ação de inspeção, o roteador aplicará a inspeção de TCP ou UDP básica a todo o tráfego autorizado pela ACL, com exceção do tráfego para o qual o ZFW fornece inspeção com reconhecimento de aplicativo. Isso inclui (mas não se limita ao) FTP, SIP, Skinny (SCCP), H.323, Sun RPC e TFTP. Se a inspeção específica de aplicativo estiver disponível, e a ACL permitir o canal primário ou de controle, qualquer canal secundário ou de mídia associado a esse canal será permitido, independentemente de a ACL autorizar ou não o tráfego.

Se um class-map aplicar somente uma ACL 101 como os critérios de correspondência, essa ACL será exibida da seguinte maneira:

access-list 101 permit ip any any

Todo o tráfego na direção da política de serviço aplicada a determinado zone pair será permitido, e o tráfego de retorno correspondente será permitido na direção oposta. Portanto, a ACL deve aplicar a restrição a fim de limitar o tráfego a tipos específicos desejados. Observe que a lista PAM inclui serviços de aplicativo, como HTTP, NetBIOS, H.323 e DNS. Entretanto, embora o PAM tenha conhecimento do uso de determinada porta pelo aplicativo específico, o firewall só aplicará recursos específicos de aplicativo suficientes para acomodar os requisitos conhecidos do tráfego do aplicativo. Portanto, o tráfego de aplicativos simples, como telnet, SSH e outros aplicativos de um único canal, é inspecionado como TCP, e as suas estatísticas são combinadas na saída do comando show. Se a visibilidade específica de aplicativo for desejada na atividade da rede, você precisará configurar a inspeção dos serviços por nome de aplicativo (configurar match protocol http, match protocol telnet etc.).

Compare as estatísticas disponíveis na saída do comando show policy-map type inspect zone-pair desta configuração com a política de firewall mais explícita mostrada mais adiante na página. Esta configuração é utilizada para inspecionar o tráfego de um Cisco IP Phone, bem como de várias estações de trabalho que utilizam diversos tipos de tráfego, como http, ftp, netbios, ssh e 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

Embora esta configuração seja facilmente definida e acomode todo o tráfego originado na zona privada (desde que o tráfego utilize as portas de destino padrão reconhecidas pelo PAM), ela oferece uma visibilidade limitada da atividade dos serviços e não permite aplicar os limites de sessão e largura de banda do ZFW a tipos específicos de tráfego. Esta saída do comando show policy-map type inspect zone-pair priv-pub é o resultado da configuração simples anterior que utiliza somente uma ACL permit ip [subnet] any entre zone pairs. Como você pode observar, a maior parte do tráfego das estações de trabalho é contabilizada nas estatísticas básicas de TCP ou UDP:

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

Por outro lado, uma configuração semelhante que adiciona classes específicas de aplicativo fornece controle e estatísticas mais granulares de aplicativos, além de acomodar a ampla gama de serviços mostrados no primeiro exemplo ao definir o class-map baseado em última chance com somente a ACL como a última chance no 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

A configuração mais específica fornece esta saída granular significativa do 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

Conforme mencionado anteriormente, outro benefício da utilização de uma configuração mais granular de class-map e policy-map é a possibilidade de aplicar limites específicos de classe aos valores de taxas e de sessões e, especificamente, ajustar os parâmetros de inspeção por meio da aplicação de um parameter-map para ajustar o comportamento de inspeção de cada classe.

Configurando Policy-Maps do Firewall de Política Baseada em Zonas

O policy-map aplica as ações da política de firewall a um ou mais class-maps para definir a política de serviços que será aplicada a um zone pair de segurança. Quando um policy-map de tipo de inspeção é criado, uma classe padrão chamada class-default é aplicada ao final da classe. A ação padrão da política da classe class-default é descartar, mas pode ser alterada para passar. A opção de log pode ser adicionada com a ação descartar. A inspeção não pode ser aplicada à classe class-default.

Ações do Firewall de Política Baseada em Zonas

O ZFW fornece três ações para o tráfego que passa de uma zona para outra:

  • Drop — Esta é a ação padrão para todo o tráfego. Além disso, um policy-map pode ser configurado para descartar o tráfego indesejado. O tráfego atribuído à ação descartar é bloqueado pelo ZFW, e a mensagem “host unreachable” do ICMP (Internet Control Message Protocol) é retornada para o host que enviou o tráfego descartado. A opção de log pode ser adicionada com a ação descartar para notificar o syslog de que o tráfego foi descartado pelo firewall.

  • Pass — Esta ação permite que o roteador encaminhe o tráfego de uma zona para outra e não rastreia o estado das conexões nem das sessões no tráfego. Ela permite somente o tráfego em uma direção. Uma política correspondente deve ser aplicada para permitir que o tráfego de retorno flua na direção oposta. A ação de passagem é útil para protocolos, como IPSec ESP, IPSec AH, ISAKMP, e outros protocolos inerentemente seguros com um comportamento previsível. Entretanto, a maior parte do tráfego de aplicativos é melhor gerenciada no ZFW com a ação de inspeção.

  • Inspect — Esta ação permite o controle do tráfego baseado em estado. Por exemplo, se o tráfego da zona privada para a zona da Internet na rede de exemplo anterior for inspecionado, o roteador manterá informações de conexão ou de sessão referentes ao tráfego TCP ou UDP (User Datagram Protocol). Portanto, o roteador permitirá o tráfego de retorno enviado dos hosts da zona da Internet em resposta às solicitações de conexão da zona privada. Além disso, esta ação permite a inspeção e o controle de aplicativos no caso de certos protocolos de serviço que podem transportar tráfego vulnerável ou confidencial de aplicativos. Uma trilha de auditoria poderá ser aplicada com um parameter-map para registrar o início, a interrupção e a duração da conexão/sessão, o volume de dados transferido e os endereços de origem e de destino.

As ações estão associadas a class-maps em policy-maps:

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

Os parameter-maps oferecem opções para modificar os parâmetros de conexão da política de inspeção de determinado class-map.

Configurando Parameter-Maps do Firewall de Política Baseada em Zonas

Os parameter-maps especificam o comportamento de inspeção do ZFW no caso de parâmetros como proteção de DoS, temporizadores de conexão TCP/sessão UDP e definições de log da trilha de auditoria. Esses mapas também são aplicados com class-maps e policy-maps da Camada 7 para definir o comportamento específico de aplicativo, como objetos HTTP, requisitos de autenticação POP3 e IMAP, além de outras informações específicas de aplicativo.

Os parameter-maps de inspeção do ZFW são configurados como type inspect, de maneira semelhante a outros objetos de política e de classe do 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

Tipos específicos de parameter-maps determinam os parâmetros aplicados pelas políticas de inspeção de aplicativo da Camada 7. Os parameter-maps do tipo regex definem uma expressão regular para uso com a inspeção de aplicativos HTTP que filtra o tráfego por meio de uma expressão regular:

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

Os parameter-maps do tipo protocol-info definem nomes de servidores para uso com a inspeção de aplicativos de mensagens instantâneas:

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

Detalhes completos sobre a configuração da inspeção de aplicativos de IM e HTTP são fornecidos nas respectivas seções de inspeção de aplicativos deste documento.

O ajuste da proteção de DoS é abordado em uma seção posterior deste documento.

A configuração da inspeção de aplicativos é abordada em uma seção posterior deste documento.

Aplicando o Log às Políticas do Firewall de Política Baseada em Zonas

O ZFW oferece opções de log para o tráfego que é descartado ou inspecionado por padrão ou ações configuradas de política de firewall. O log da trilha de auditoria está disponível para o tráfego inspecionado pelo ZFW. A trilha de auditoria é aplicada por meio de sua definição em um parameter-map e da aplicação desse mapa com a ação de inspeção em um policy-map:

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

O log de descarte está disponível para o tráfego descartado pelo ZFW. Esse log é configurado por meio de sua inclusão com a ação de descarte em um policy-map:

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

Editando Class-Maps e Policy-Maps do Firewall de Política de Baseada em Zonas

No momento, o ZFW não incorpora um editor capaz de modificar suas diversas estruturas, como policy-maps, class-maps e parameter-maps. Para reorganizar as instruções de correspondência em um class-map ou a aplicação de ações a diversos class-maps contidos em um policy-map, siga estes passos:

  1. Copie a estrutura existente para um editor de texto como o Microsoft Windows Notepad ou para um editor como o vi nas plataformas Linux/Unix.

  2. Remova a estrutura existente da configuração do roteador.

  3. Edite a estrutura em seu editor de texto.

  4. Copie a estrutura novamente para a CLI do roteador.

Exemplos de Configuração

Este exemplo de configuração utiliza um Cisco 1811 Integrated Services Router. Uma configuração básica com conectividade IP, configuração de VLAN e bridging transparente entre dois segmentos de uma LAN Ethernet privada está disponível no Apêndice A. O roteador está dividido em cinco zonas:

  • A Internet pública está conectada à FastEthernet 0 (zona da Internet)

  • Dois servidores de Internet estão conectados à FastEthernet 1 (zona DMZ)

  • O switch Ethernet está configurado com duas VLANs:

    • As estações de trabalho estão conectadas à VLAN1 (zona de cliente).

    • Os servidores estão conectados à VLAN2 (zona de servidor).

    • As zonas de cliente e de servidor encontram-se na mesma sub-rede. Um firewall transparente será aplicado entre as zonas, de modo que as políticas entre zonas nessas duas interfaces afetarão somente o tráfego entre as zonas de cliente e de servidor.

  • As interfaces VLAN1 e VLAN2 comunicam-se com outras redes através da Bridge Virtual Interface (BVI1). Essa interface é atribuída à zona privada. (Consulte a Figura 2).

Figura 2: Detalhes da Topologia da Zona

zone-design-guide2.gif

Estas políticas são aplicadas com o uso das zonas de rede definidas anteriormente:

  • Os hosts da zona da Internet podem acessar serviços DNS, SMTP e SSH em um servidor da DMZ. O outro servidor oferecerá serviços SMTP, HTTP e HTTPS. A política de firewall restringirá o acesso aos serviços específicos disponíveis em cada host.

  • Os hosts da DMZ não podem se conectar aos de qualquer outra zona.

  • Os hosts da zona de cliente podem se conectar aos da zona de servidor em todos os serviços TCP, UDP e ICMP.

  • Os hosts da zona de servidor não podem se conectar aos da zona de cliente; a única exceção é um servidor de aplicativos baseado em UNIX que pode abrir sessões de cliente X Windows em servidores X Windows, em PCs da zona de cliente, nas portas 6900 a 6910.

  • Todos os hosts da zona privada (combinação de clientes e servidores) podem acessar os hosts da DMZ em serviços SSH, FTP, POP, IMAP, ESMTP e HTTP, e os da zona da Internet em serviços HTTP, HTTPS, DNS e ICMP. Além disso, a inspeção de aplicativos será aplicada às conexões HTTP da zona privada com a zona da Internet, a fim de garantir que os aplicativos de mensagens instantâneas e P2P com suporte não trafeguem pela porta 80. (Consulte a Figura 3.)

Figura 3: Permissões de serviço do zone pair a serem aplicadas ao exemplo de configuração

zone-design-guide3.gif

Estas políticas de firewall estão configuradas em ordem de complexidade:

  1. Inspeção de TCP/UDP/ICMP de clientes-servidores

  2. Inspeção de SSH/FTP/POP/IMAP/ESMTP/HTTP da DMZ privada

  3. Inspeção de SMTP/HTTP/DNS da DMZ da Internet, limitada por endereço do host

  4. Inspeção do Windows X de servidores-clientes, com um serviço especificado pelo PAM (port-application mapping)

  5. Inspeção de HTTP/HTTPS/DNS/ICMP da Internet privada com aplicativo HTTP

Como você aplicará partes da configuração a diferentes segmentos de rede em momentos distintos, é importante lembrar que um segmento perderá conectividade com outros segmentos quando for colocado em uma zona. Por exemplo, quando a zona privada for configurada, os hosts dessa zona perderão conectividade com a DMZ e as zonas da Internet até que suas respectivas políticas sejam definidas.

Firewall de Roteamento de Inspeção Stateful

Configuração da Política da Internet Privada

A Figura 4 ilustra a configuração da política da Internet privada.

Figura 4: Inspeção de serviço da zona privada para a zona da Internet

zone-design-guide4.gif

A política da Internet privada aplica a inspeção da Camada 4 ao HTTP, HTTPS e DNS, bem como ao ICMP da zona privada para a zona da Internet. Isso permite conexões da zona privada com a zona da Internet, bem como o tráfego de retorno. A inspeção da Camada 7 tem como vantagens o controle mais rígido de aplicativos, maior segurança e o suporte a aplicativos que exigem correção. Entretanto, conforme mencionado, essa inspeção requer maior conhecimento da atividade da rede, uma vez que protocolos dessa camada não configurados para inspeção não serão permitidos entre as zonas.

  1. Defina class-maps que descrevam o tráfego que você deseja permitir entre as zonas, de acordo com as 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. camada

    Configure um policy-map para inspecionar o tráfego nos class-maps que você acabou de definir:

    conf t
     policy-map type inspect private-internet-policy
      class type inspect internet-traffic-class
       inspect
    
  3. Configure as zonas privadas e DMZ e atribua interfaces do roteador às 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 o zone pair e aplique o policy-map adequado.

    Nota: No momento, você só precisará configurar o zone pair da Internet privada a fim de inspecionar as conexões originadas da zona privada para a zona da Internet:

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

    Esse procedimento conclui a configuração da política de inspeção da Camada 7 no zone pair da Internet privada para permitir conexões HTTP, HTTPS, DNS e ICMP da zona de clientes com a de servidores, bem como aplicar a inspeção de aplicativos ao tráfego HTTP, a fim de garantir que o tráfego indesejado não tenha permissão de passar pela porta de serviço do HTTP (TCP80).

Configuração da Política da DMZ Privada

A Figura 5 ilustra a configuração da política da DMZ privada.

Figura 5: Inspeção de serviço da zona privada para a zona DMZ

zone-design-guide5.gif

A política da DMZ privada é mais complexa, pois requer maior conhecimento do tráfego de rede entre as zonas. Essa política aplica a inspeção da Camada 7 da zona privada para a DMZ. Isso permite conexões da zona privada com a DMZ, bem como o tráfego de retorno. A inspeção da Camada 7 tem como vantagens o controle mais rígido de aplicativos, maior segurança e o suporte a aplicativos que exigem correção. Entretanto, conforme mencionado, essa inspeção requer maior conhecimento da atividade da rede, uma vez que protocolos dessa camada não configurados para inspeção não serão permitidos entre as zonas.

  1. Defina class-maps que descrevam o tráfego que você deseja permitir entre as zonas, de acordo com as 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 policy-maps para inspecionar o tráfego nos class-maps que você acabou de definir:

    conf t
     policy-map type inspect private-dmz-policy
      class type inspect L7-inspect-class
       inspect
    
  3. Configure as zonas privadas e DMZ e atribua interfaces do roteador às 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 o zone pair e aplique o policy-map adequado.

    Nota: No momento, você só precisará configurar o zone pair DMZ privadas a fim de inspecionar as conexões originadas da zona privada para a DMZ:

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

    Esse procedimento conclui a configuração da política de inspeção da Camada 7 na DMZ privada para permitir todas as conexões TCP, UDP e ICMP da zona de clientes com a de servidores. A política não aplica uma correção aos canais subordinados, mas fornece um exemplo de política simples para acomodar a maioria das conexões de aplicativos.

Configuração da Política da DMZ da Internet

A Figura 6 ilustra a configuração da política da DMZ da Internet.

Figura 6: Inspeção de serviço da zona da Internet para a zona DMZ

zone-design-guide6.gif

Esta política aplica a inspeção da Camada 7 da zona da Internet para a DMZ. Isso permite conexões da zona da Internet com a DMZ, bem como o tráfego de retorno dos hosts da DMZ para os hosts da Internet que iniciaram a conexão. A política da DMZ da Internet combina a inspeção da Camada 7 com grupos de endereços definidos por ACLs para restringir o acesso a serviços específicos em determinados hosts, grupos de hosts ou sub-redes. Isso é alcançado por meio do aninhamento de um class-map que especifica serviços em outro class-map que faz referência a uma ACL para determinar os endereços IP.

  1. Defina class-maps e ACLs que descrevam o tráfego que você deseja permitir entre as zonas, de acordo com as políticas descritas anteriormente:

    Vários class-maps de serviços devem ser utilizados, uma vez que políticas de acesso diferentes serão aplicadas a dois servidores diferentes. São permitidas conexões DNS e HTTP dos hosts da Internet com 172.16.2.2 e conexões SMTP com 172.16.2.3. Observe a diferença nos class-maps. Os class-maps que especificam serviços utilizam a palavra-chave match-any para permitir quaisquer dos serviços listados. Os class-maps que associam ACLs aos class-maps de serviços utilizam a palavra-chave match-all para exigir que as duas condições do class-map sejam atendidas para que o tráfego seja permitido:

    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 policy-maps para inspecionar o tráfego nos class-maps que você acabou de definir:

    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 as zonas da Internet e DMZ e atribua interfaces do roteador às respectivas zonas: Ignore a configuração da DMZ se a tiver configurado na seção 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 o zone pair e aplique o policy-map adequado.

    Nota: No momento, você só precisará configurar o zone pair DMZ da Internet a fim de inspecionar as conexões originadas da zona da Internet para a DMZ:

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

    Esse procedimento conclui a configuração da política de inspeção da Camada 7 específica de endereço no zone pair DMZ da Internet.

Firewall Transparente de Inspeção Stateful

Configuração da Política de Servidores-Clientes

A Figura 7 ilustra a configuração da política de servidor-cliente.

Figura 7: Inspeção de serviço da zona de servidores para a zona de clientes

zone-design-guide7.gif

A política de servidores-clientes aplica a inspeção utilizando um serviço definido pelo usuário. A inspeção da Camada 7 é aplicada da zona de servidores para a de clientes. Isso permite conexões X Windows com um intervalo específico de portas da zona de servidores para a de clientes, bem como o tráfego de retorno. Como o protocolo X Windows não tem suporte nativo no PAM, um serviço configurado pelo usuário no PAM deve ser definido para que o ZFW possa reconhecer e inspecionar o tráfego adequado.

Duas ou mais interfaces do roteador são configuradas em um grupo de bridges IEEE para fornecer IRB (Integrated Routing and Bridging) a fim de permitir o bridging entre as interfaces do grupo de bridges e o roteamento para outras sub-redes através da BVI (Bridge Virtual Interface). A política de firewall transparente aplicará a inspeção de firewall ao tráfego que “atravessa a bridge”, mas não ao tráfego que sai do grupo de bridges por meio da BVI. A política de inspeção se aplicará somente ao tráfego que atravessa o grupo de bridges. Portanto, neste cenário, a inspeção só será aplicada ao tráfego que passa entre as zonas de clientes e de servidores, as quais estão aninhadas na zona privada. A política aplicada entre a zona privada e as zonas públicas e DMZ só será ativada quando o tráfego sair do grupo de bridges por meio da BVI. Quando o tráfego sair das zonas de clientes ou de servidores por meio da BVI, a política de firewall transparente não será chamada.

  1. Configuração do PAM com uma entrada definida pelo usuário para X Windows.

    Os clientes X Windows (onde os aplicativos estão hospedados) abrem conexões a fim de exibir informações para os clientes (onde o usuário está trabalhando) em um intervalo de portas que inicia na porta 6900.

    Como cada conexão adicional utiliza portas sucessivas, se um cliente exibir 10 sessões diferentes em um host, o servidor utilizará as portas 6900-6909. Portanto, se você inspecionar o intervalo de portas de 6900 a 6909, as conexões abertas com as portas acima de 6909 falharão:

    conf t
     ip port-map user-Xwindows port tcp from 6900 to 6910
    
  2. Examine os documentos do PAM para obter mais informações sobre esse recurso ou verifique a documentação de inspeção granular de protocolos para obter detalhes sobre a interoperabilidade entre o PAM e a inspeção stateful do Cisco IOS Firewall.

  3. Defina class-maps que descrevam o tráfego que você deseja permitir entre as zonas, de acordo com as políticas descritas anteriormente:

    conf t
     class-map type inspect match-any Xwindows-class
      match protocol user-Xwindows
    
  4. Configure policy-maps para inspecionar o tráfego nos class-maps que você acabou de definir:

    conf t
     policy-map type inspect servers-clients-policy
      class type inspect Xwindows-class
       inspect
    
  5. Configure as zonas de cliente e de servidor e atribua interfaces do roteador às respectivas zonas.

    Se tiver configurado essas zonas e atribuído interfaces na seção Configuração da Política de Clientes-Servidores, você poderá ignorar a definição do zone pair. A configuração do IRB de bridging é fornecida para uma descrição mais completa:

    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 o zone pair e aplique o policy-map adequado.

    Nota: No momento, você só precisará configurar o zone pair de servidores-clientes a fim de inspecionar as conexões originadas da zona de servidores para a de clientes:

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

    Esse procedimento conclui a configuração da política de inspeção definida pelo usuário no zone pair de servidores-clientes para permitir conexões X Windows da zona de servidores com a de clientes.

Configuração da Política de Clientes-Servidores

A Figura 8 ilustra a configuração da política de cliente-servidor.

Figura 8: Inspeção de serviço da zona de clientes para a zona de servidores

zone-design-guide8.gif

A política de cliente-servidor é menos complexa do que as outras. A inspeção da Camada 4 é aplicada da zona de clientes para a de servidores. Isso permite conexões da zona de clientes com a de servidores, bem como o tráfego de retorno. A inspeção da Camada 4 tem como vantagem a simplicidade da configuração do firewall, uma vez que apenas algumas regras são necessárias para permitir a maior parte do tráfego de aplicativos. No entanto, essa inspeção também apresenta duas grandes desvantagens:

  • Alguns aplicativos, como FTP, ou serviços de fluxo de mídia freqüentemente negociam um canal subordinado adicional do servidor para o cliente. Essa funcionalidade é normalmente acomodada em uma correção do serviço que monitora a caixa de diálogo do canal de controle e permite o canal subordinado. Esse recurso não está disponível na inspeção da Camada 4.

  • A inspeção da Camada 4 permite praticamente todo o tráfego da camada de aplicativo. Caso o uso da rede deva ser controlado de modo que somente alguns aplicativos possam passar pelo firewall, uma ACL deverá ser configurada no tráfego de saída a fim de limitar os serviços que podem atravessar o firewall.

As duas interfaces do roteador são configuradas em um grupo de bridges IEEE; portanto, essa política aplicará a inspeção de firewall transparente. A política será aplicada a duas interfaces em um grupo de bridges IP IEEE. A política de inspeção se aplicará somente ao tráfego que atravessa o grupo de bridges. Isso explica por que as zonas de clientes e de servidores são aninhadas na zona privada.

  1. Defina class-maps que descrevam o tráfego que você deseja permitir entre as zonas, de acordo com as 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 policy-maps para inspecionar o tráfego nos class-maps que você acabou de definir:

    conf t
     policy-map type inspect clients-servers-policy
     class type inspect L4-inspect-class
      inspect
    
  3. Configure as zonas de clientes e de servidores e atribua interfaces do roteador às respectivas zonas:

    conf t
    zone security clients
    zone security servers
    int vlan 1
    zone-member security clients
    int vlan 2
    zone-member security servers
    
  4. Configure o zone pair e aplique o policy-map adequado.

    Nota: No momento, você só precisará configurar o zone pair de clientes-servidores a fim de inspecionar as conexões originadas da zona de clientes para a de servidores:

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

    Esse procedimento conclui a configuração da política de inspeção da Camada 4 no zone pair de clientes-servidores para permitir todas as conexões TCP, UDP e ICMP da zona de clientes com a de servidores. A política não aplica uma correção aos canais subordinados, mas fornece um exemplo de política simples para acomodar a maioria das conexões de aplicativos.

Política de Taxas do Firewall de Política Baseada em Zonas

Freqüentemente as redes de dados se beneficiam da capacidade de limitar a taxa de transmissão de tipos específicos de tráfego de rede, bem como reduzir o impacto do tráfego de menor prioridade no de maior prioridade. O Cisco IOS Software oferece esse recurso por meio de políticas de tráfego, que limitam a taxa nominal e as intermitências de tráfego. O Cisco IOS Software oferece suporte a políticas de tráfego desde o Cisco IOS Release 12.1(5)T.

O Cisco IOS Software Release 12.4(9)T otimiza o ZFW com a limitação de taxas uma vez que permite controlar o tráfego correspondente às definições de um class-map específico à medida que ele passa de uma zona de segurança para outra através do firewall. Isso é conveniente, pois oferece um só ponto de configuração para descrever o tráfego específico, aplicar a política de firewall e controlar o consumo de largura de banda do tráfego.

As políticas do ZFW diferem das baseadas em interface uma vez que fornecem somente as ações transmitir e descartar para a conformidade e a violação de políticas, respectivamente. As políticas do ZFW não podem marcar o tráfego para DSCP. Elas só podem especificar o uso de largura de banda em bytes/segundo; políticas baseadas na porcentagem de largura de banda e em pacotes/segundo não estão disponíveis. As políticas do ZFW podem ser aplicadas com ou sem políticas baseadas em interface. Portanto, se recursos adicionais de política forem necessários, eles poderão ser aplicados pelas políticas baseadas em interface. Se essas políticas forem utilizadas junto com políticas de firewall, verifique se não há conflitos entre elas.

Configurando Políticas do ZFW

As políticas do ZFW limitam o tráfego em um class-map de um policy-map a um valor de taxa definido pelo usuário entre 8.000 e 2.000.000.000 bits por segundo, com um valor de intermitência configurável no intervalo de 1.000 a 512.000.000 bytes.

As políticas do ZFW são definidas por uma linha adicional de configuração no policy-map, a qual é aplicada após a ação da 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>]

Controle de Sessão

As políticas do ZFW também introduziram o controle de sessão a fim de limitar a contagem de sessões do tráfego em um policy-map que atende a um class-map. Isso otimiza a aplicação da proteção de DoS por class-map. Efetivamente, isso possibilita o controle granular do número de sessões que atravessam um zone pair e que atendem a determinado class-map. Se o mesmo class-map for utilizado em vários policy-maps ou zone pairs, limites de sessão diferentes poderão ser aplicados aos diversos aplicativos de class-map.

Para aplicar o controle de sessão, é necessário configurar um parameter-map que contenha o volume desejado de sessões e, depois, anexar esse mapa à ação de inspeção aplicada a um class-map em um 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

Os parameter-maps só podem ser aplicados à ação de inspeção e não estão disponíveis nas ações passar ou descartar.

As atividades de políticas e controle de sessão do ZFW podem ser observadas com este comando:

show policy-map type inspect zone-pair

Inspeção de Aplicativos

A inspeção de aplicativos introduz mais um recurso no ZFW. As políticas de inspeção de aplicativos são aplicadas na Camada 7 do modelo OSI, onde os aplicativos do usuário enviam e recebem mensagens que lhes permitem oferecer recursos úteis. Como alguns aplicativos podem oferecer recursos não desejados ou vulneráveis, as mensagens associadas a esses recursos devem ser filtradas a fim de limitar as atividades dos serviços de aplicativo.

O ZFW do Cisco IOS Software oferece a inspeção e o controle de aplicativos nos seguintes serviços:

  • HTTP

  • SMTP

  • POP3

  • IMAP

  • Sun RPC

  • Tráfego de Aplicativos P2P

  • Aplicativos de IM

A inspeção e o controle de aplicativos (AIC) varia quanto aos recursos oferecidos por serviço. A inspeção de HTTP oferece filtragem granular de diversos tipos de atividade de aplicativos, com recursos para limitar o tamanho de transferência, os tamanhos dos endereços da Web e a atividade do navegador, a fim de aplicar a conformidade com padrões de comportamento de aplicativos, bem como limitar os tipos de conteúdo transferidos através do serviço. O AIC para SMTP pode limitar o tamanho do conteúdo e aplicar a conformidade dos protocolos. A inspeção de POP3 e IMAP pode ajudar a garantir que os usuários utilizem mecanismos seguros de autenticação para evitar que suas credenciais sejam comprometidas.

A inspeção de aplicativos é configurada como um conjunto adicional de class-maps e policy-maps específicos de aplicativo, que são aplicados aos class-maps e policy-maps de inspeção existentes, por meio da definição da política de serviço de aplicativo no policy-map de inspeção.

Inspeção de Aplicativos HTTP

A inspeção de aplicativos pode ser aplicada ao tráfego HTTP para controlar o uso indesejado da porta de serviço do HTTP por outros aplicativos, como IM, compartilhamento de arquivos P2P e aplicativos de Tunneling, os quais podem redirecionar, através da porta TCP 80, aplicativos protegidos por firewall.

Configure um class-map de inspeção de aplicativos para descrever o tráfego que viola o tráfego HTTP permitido:

! Configura as ações que não são permitidas
class-map type inspect http match-any http-aic-cmap
 match request port-misuse any
 match req-resp protocol-violation
! Define ações que serão aplicadas a tráfego indesejado.
policy-map type inspect http http-aic-pmap
 class type insp http http-aic-cmap
  reset
  log
! Define o mapa de classes para a inspeção stateful
class-map type inspect match-any http-cmap
 match protocol http
! Define o mapa de classes para a inspeção stateful de outro tráfego
class-map type inspect match-any other-traffic-cmap
 match protocol smtp
 match protocol dns
 match protocol ftp
! Define o mapa de políticas, associa mapas de classe e ações
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

Melhorias da Inspeção de Aplicativos HTTP

O Cisco IOS Software Release 12.4(9)T introduz melhorias nos recursos de inspeção de HTTP do ZFW. O Cisco IOS Firewall introduziu a Inspeção de Aplicativos HTTP no Cisco IOS Software Release 12.3(14)T. O Cisco IOS Software Release 12.4(9)T otimiza os recursos existentes ao adicionar:

  • Capacidade de permitir, negar e monitorar solicitações e respostas com base no nome e nos valores de cabeçalho. Isso é útil para bloquear solicitações e respostas que contêm campos de cabeçalho vulneráveis.

  • Capacidade de limitar os tamanhos dos diferentes elementos nos cabeçalhos de solicitações e respostas HTTP, como o tamanho máximo do URL, tamanho máximo do cabeçalho, número máximo de cabeçalhos, tamanho máximo da linha de cabeçalho etc. Isso é útil para evitar excessos de buffer.

  • Capacidade de bloquear solicitações e respostas que contêm vários cabeçalhos do mesmo tipo; por exemplo, uma solicitação com dois cabeçalhos de tamanho de conteúdo.

  • Capacidade de bloquear solicitações e respostas com cabeçalhos não-ASCII. Isso é útil para evitar diversos ataques que utilizam caracteres binários e outros caracteres não-ASCII a fim de introduzir worms e outros conteúdos prejudiciais em servidores Web.

  • Capacidade de agrupar os métodos HTTP em categorias especificadas pelo usuário e flexibilidade para bloquear/permitir/monitorar cada um dos grupos oferecidos. A RFC do HTTP permite um conjunto restrito de métodos HTTP. Alguns dos métodos padrão são considerados não seguros porque podem ser utilizados para explorar as vulnerabilidades de um servidor Web. Vários dos métodos não-padrão têm um registro de segurança ruim.

  • Um método para bloquear URIs específicos com base em uma expressão regular configurada pelo usuário. Esse recurso permite que o usuário bloqueie consultas e URIs personalizados.

  • Capacidade de falsificar tipos de cabeçalho (especialmente um tipo de cabeçalho de servidor) com seqüências personalizáveis pelo usuário. Isso é útil quando um invasor analisa as respostas de um servidor Web, obtém o máximo possível de informações e, depois, inicia um ataque que explora as vulnerabilidades desse servidor.

  • Capacidade de bloquear ou emitir um alerta em uma conexão HTTP se um ou mais valores de parâmetros HTTP corresponderem aos valores inseridos pelo usuário como uma expressão regular. Alguns dos possíveis contextos de valores HTTP incluem cabeçalho, corpo, nome de usuário, senha, agente de usuário, linha de solicitação, linha de status e variáveis CGI decodificadas.

Os exemplos de configuração das melhorias na inspeção de aplicativos HTTP baseiam-se em uma rede simples:

zone-design-guide9.gif

O firewall agrupa o tráfego em duas classes:

  • Tráfego HTTP

  • Todo o restante do tráfego ICMP, UDP e TCP de canal único

O HTTP é separado para possibilitar uma inspeção específica do tráfego da Web. Isso permite que você configure as políticas na primeira seção deste documento e a Inspeção de Aplicativos HTTP na segunda seção. Você configurará class-maps e policy-maps específicos para o tráfego de IM e P2P na terceira seção deste documento. A conectividade da zona privada com a zona pública é permitida. Nenhuma conectividade é permitida na direção inversa.

Uma configuração completa que implementa a política inicial é fornecida no Apêndice C, Configuração Básica do Firewall de Política de Zonas para Duas Zonas.

Configurando Melhorias na Inspeção de Aplicativos HTTP

A Inspeção de Aplicativos HTTP (bem como outras políticas de inspeção de aplicativos) requer uma configuração mais complexa do que a configuração básica da Camada 4. É necessário configurar a política e a classificação do tráfego da Camada 7 para reconhecer o tráfego específico a ser controlado e aplicar a ação desejada ao tráfego desejável e indesejável.

--A Inspeção de Aplicativos HTTP (semelhante a outros tipos de Inspeção de Aplicativos) só pode ser aplicada ao tráfego HTTP. Portanto, você deve definir class-maps e policy-maps da Camada 7 para o tráfego HTTP específico, depois definir um class-map da Camada 4 especificamente para HTTP e aplicar a política da Camada 7 à inspeção de HTTP em um policy-map da Camada 4, da seguinte maneira:

! Configura as características do tráfego da camada 7:
class-map type inspect http match-any http-l7-cmap
 match  req-resp protocol-violation
 match  request body length gt 4096
!
! Configura a ação que será aplicada ao tráfego
! que corresponde às características específicas:
policy-map type inspect http http-l7-pmap
 class type inspect http http-l7-cmap
  reset
  log
!
! Define a política de inspeção da camada 4
class-map type inspect match-all http-l4-cmap
 match protocol http
!
! Associa a classe da camada 4 e o mapa de políticas da camada 7
! no mapa de classes da camada 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 do tráfego da Inspeção de Aplicativos HTTP são definidas em um class-map da Camada 7:

  • Header inspection — Este comando pode ser utilizado para permitir/negar/monitorar solicitações ou respostas cujo cabeçalho corresponde à expressão regular configurada. A ação permitir ou redefinir pode ser aplicada a uma solicitação ou resposta que atenda aos critérios do class-map. A adição da ação de log gera uma mensagem do syslog:

    APPFW-6-HTTP_HDR_REGEX_MATCHED
    

    Uso do comando:

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

    Exemplo Prático de Uso

    Configure uma política appfw http para bloquear uma solicitação ou resposta cujo cabeçalho contém caracteres não-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 verifica o tamanho do cabeçalho de uma solicitação ou resposta e aplica a ação se o tamanho exceder o limite configurado. A ação é permitir ou redefinir. A adição da ação de log gera uma mensagem do syslog:

    APPFW-4- HTTP_HEADER_LENGTH
    

    Uso do comando:

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

    Exemplo Prático de Uso

    Configure uma política appfw http para bloquear as solicitações e respostas cujo cabeçalho é maior que 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 o número de linhas de cabeçalho (campos) em uma solicitação/resposta e aplica a ação quando a contagem excede o limite configurado. A ação é permitir ou redefinir. A adição da ação de log gera uma mensagem do syslog:

    APPFW-6- HTTP_HEADER_COUNT.
    

    Uso do comando:

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

    Exemplo Prático de Uso

    Configure uma política appfw http para bloquear uma solicitação que contenha mais de 16 campos de cabeçalho.

    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 pode ser utilizado para permitir/negar/monitorar as solicitações/respostas que contêm um valor e um campo de cabeçalho HTTP específico. A ação permitir ou redefinir pode ser aplicada a uma solicitação ou resposta que atenda aos critérios do class-map. A adição da ação de log gera uma mensagem do syslog:

    APPFW-6- HTTP_HDR_FIELD_REGEX_MATCHED
    

    Uso do comando:

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

    Exemplo Prático de Uso

    Configure uma política de inspeção de aplicativos http para bloquear spyware/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 permite limitar o tamanho de uma linha do campo de cabeçalho. A ação permitir ou redefinir pode ser aplicada a uma solicitação ou resposta que atenda aos critérios do class-map. A adição da ação de log gera uma mensagem do syslog:

    APPFW-6- HTTP_HDR_FIELD_LENGTH.
    

    Uso do comando:

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

    Exemplo Prático de Uso

    Configure uma política appfw http para bloquear uma solicitação cujo cookie e campo de agente de usuário excedem os tamanhos 256 e 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 verifica se uma solicitação ou resposta contém campos de cabeçalho repetidos. A ação permitir ou redefinir pode ser aplicada a uma solicitação ou resposta que atenda aos critérios do class-map. Quando ativada, a ação de log gera uma mensagem do syslog:

    APPFW-6- HTTP_REPEATED_HDR_FIELDS.
    

    Uso do comando:

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

    Exemplo Prático de Uso

    Configure uma política appfw http para bloquear uma solicitação ou resposta que contenha várias linhas de cabeçalho de tamanho de conteúdo. Essa é uma das funcionalidades mais úteis para evitar a invasão de sessões.

    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 — A RFC do HTTP permite um conjunto restrito de métodos HTTP. No entanto, mesmo alguns métodos padrão são considerados não seguros porque podem ser utilizados para explorar as vulnerabilidades de um servidor Web. Muitos dos métodos não-padrão são freqüentemente utilizados para atividade mal-intencionada. Como resultado, é necessário agrupar os métodos em várias categorias e fazer com que o usuário escolha a ação de cada categoria. Este comando proporciona ao usuário uma forma flexível de agrupar os métodos em várias categorias, como métodos seguros, não seguros, webdav, rfc e estendidos. A ação permitir ou redefinir pode ser aplicada a uma solicitação ou resposta que atenda aos critérios do class-map. A adição da ação de log gera uma mensagem do syslog:

    APPFW-6-HTTP_METHOD.
    

    Uso do comando:

    match request method <method>
    

    Exemplo Prático de Uso

    Configure uma política appfw http que agrupe os métodos HTTP em três categorias: seguro, não seguro e webdav. Essas categorias são mostradas na tabela. Configure as ações de modo que:

    • todos os métodos seguros sejam permitidos sem log

    • todos os métodos não seguros sejam permitidos com log

    • todos os métodos webdav sejam bloqueados com log.

    Seguro

    Não seguro

    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 pode ser utilizado para permitir/negar/monitorar as solicitações cujo URI corresponde à expressão regular configurada. Isso permite que o usuário bloqueie URLs e consultas personalizadas. A ação permitir ou redefinir pode ser aplicada a uma solicitação ou resposta que atenda aos critérios do class-map. A adição da ação de log gera uma mensagem do syslog:

    APPFW-6- HTTP_URI_REGEX_MATCHED
    

    Uso do comando:

    match request uri regex <parameter-map-name>
    

    Exemplo Prático de Uso

    Configure uma política appfw http para bloquear uma solicitação cujo URI corresponde a uma destas expressões regulares:

    • .*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 o tamanho do URI enviado em uma solicitação e aplica a ação configurada quando o tamanho excede o limite configurado. A ação permitir ou redefinir pode ser aplicada a uma solicitação ou resposta que atenda aos critérios do class-map. A adição da ação de log gera uma mensagem do syslog:

    APPFW-6- HTTP_URI_LENGTH.
    

    Uso do comando:

    match request uri length gt <bytes>
    

    Exemplo Prático de Uso

    Configure uma política appfw http para disparar um alarme sempre que o tamanho do URI de uma solicitação exceder 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 pode ser utilizado para permitir, negar ou monitorar as solicitações cujos argumentos (parâmetros) correspondem à expressão regular configurada. A ação permitir ou redefinir pode ser aplicada a uma solicitação ou resposta que atenda aos critérios do class-map. A adição da ação de log gera uma mensagem do syslog:

    APPFW-6- HTTP_ARG_REGEX_MATCHED
    

    Uso do comando:

    match request arg regex <parameter-map-name>
    

    Exemplo Prático de Uso

    Configure uma política appfw http para bloquear uma solicitação cujos argumentos correspondem a uma destas expressões regulares:

    • .*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 o tamanho dos argumentos enviados em uma solicitação e aplica a ação configurada quando o tamanho excede o limite configurado. A ação permitir ou redefinir pode ser aplicada a uma solicitação ou resposta que atenda aos critérios do class-map. A adição da ação de log gera uma mensagem do syslog:

    APPFW-6- HTTP_ARG_LENGTH.
    

    Uso do comando:

    match request arg length gt <bytes>
    

    Exemplo Prático de Uso

    Configure uma política appfw http para disparar um alarme sempre que o tamanho do argumento de uma solicitação exceder 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 que o usuário especifique uma lista de expressões regulares que deverá ser comparada com o corpo da solicitação ou resposta. A ação permitir ou redefinir pode ser aplicada a uma solicitação ou resposta que atenda aos critérios do class-map. A adição da ação de log gera uma mensagem do syslog:

    APPFW-6- HTTP_BODY_REGEX_MATCHED
    

    Uso do comando:

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

    Exemplo Prático de Uso

    Configure uma política appfw http para bloquear uma resposta cujo corpo contenha o padrão .*[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 o tamanho da mensagem enviada através de uma solicitação ou resposta. A ação permitir ou redefinir pode ser aplicada a uma solicitação ou resposta que atenda aos critérios do class-map. A adição da ação de log gera uma mensagem do syslog:

    APPFW-4- HTTP_CONTENT_LENGTH
    

    Uso do comando:

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

    Exemplo Prático de Uso

    Configure uma política appfw http para bloquear uma sessão http que contenha uma mensagem com mais de 10K bytes em uma solicitação ou resposta.

    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 que o usuário especifique uma lista de expressões regulares que deverá ser comparada com a linha de status de uma resposta. A ação permitir ou redefinir pode ser aplicada a uma solicitação ou resposta que atenda aos critérios do class-map. A adição da ação de log gera uma mensagem do syslog:

    APPFW-6-HTTP_STLINE_REGEX_MATCHED.
    

    Uso do comando:

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

    Exemplo Prático de Uso

    Configure uma política appfw http para registrar um alarme sempre que houver uma tentativa de acessar uma página proibida. Normalmente, uma página proibida contém o código de status 403 e a linha de status é semelhante a esta 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 se o tipo de conteúdo do cabeçalho da mensagem está na lista de tipos de conteúdo com suporte. Ele também verifica se o tipo de conteúdo do cabeçalho corresponde ao conteúdo da parte do corpo da entidade ou de dados da mensagem. Se a palavra-chave mismatch for configurada, o comando verificará o tipo de conteúdo da mensagem da resposta em relação ao valor de campo aceito da mensagem da solicitação. A ação permitir ou redefinir pode ser aplicada a uma solicitação ou resposta que atenda aos critérios do class-map. A adição da ação de log gera uma mensagem do syslog:

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

    Uso do comando:

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

    Exemplo Prático de Uso

    Configure uma política appfw http para bloquear uma sessão http que contenha solicitações e respostas com tipo de conteúdo desconhecido.

    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 é utilizado para evitar o uso indevido da porta http (80) por outros aplicativos, como IM, P2P, Tunneling etc. A ação permitir ou redefinir pode ser aplicada a uma solicitação ou resposta que atenda aos critérios do class-map. A adição da ação de log gera uma mensagem do syslog:

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

    Uso do comando:

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

    Exemplo Prático de Uso

    Configure uma política appfw http para bloquear uma sessão http utilizada de maneira indevida por um aplicativo de 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 permite a verificação estrita da conformidade de protocolo em solicitações e respostas HTTP. A ação permitir ou redefinir pode ser aplicada a uma solicitação ou resposta que atenda aos critérios do class-map. A adição da ação de log gera uma mensagem do syslog:

    APPFW-4- HTTP_PROTOCOL_VIOLATION
    

    Uso do comando:

    match req-resp protocol-violation
    

    Exemplo Prático de Uso

    Configure uma política appfw http para bloquear solicitações ou respostas que violem a 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 pode ser utilizado para permitir, negar ou monitorar as solicitações/respostas cujo tipo de codificação de transferência corresponde ao tipo configurado. A ação permitir ou redefinir pode ser aplicada a uma solicitação ou resposta que atenda aos critérios do class-map. A adição da ação de log gera uma mensagem do syslog:

    APPFW-6- HTTP_TRANSFER_ENCODING
    

    Uso do comando:

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

    Exemplo Prático de Uso

    Configure uma política appfw http para bloquear uma solicitação ou resposta cujo tipo de codificação seja compactação.

    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 verifica se uma resposta tem um applet Java e aplica a ação configurada após a detecção do applet. A ação permitir ou redefinir pode ser aplicada a uma solicitação ou resposta que atenda aos critérios do class-map. A adição da ação de log gera uma mensagem do syslog:

    APPFW-4- HTTP_JAVA_APPLET
    

    Uso do comando:

    match response body java-applet
    

    Exemplo Prático de Uso

    Configure uma política appfw http para bloquear applets 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
    

Suporte do ZFW ao Controle de Aplicativos de Mensagens Instantâneas e Peer-to-Peer

O Cisco IOS Software Release 12.4(9)T introduziu o suporte do ZFW a aplicativos de IM e P2P.

Primeiramente, o Cisco IOS Software oferecia suporte ao controle de aplicativos de IM no Cisco IOS Software Release 12.4(4)T. A release inicial do ZFW não oferecia suporte a Aplicativos de IM na interface do ZFW. Se o controle de aplicativos de IM fosse desejado, os usuários não poderiam migrar para a interface de configuração do ZFW. O Cisco IOS Software Release 12.4(9)T introduziu o suporte do ZFW à Inspeção de IM, incluindo o Yahoo! Messenger (YM), o MSN Messenger (MSN) e o AOL Instant Messenger (AIM).

O Cisco IOS Software Release 12.4(9)T é a primeira versão do Cisco IOS Software que oferece suporte nativo do IOS Firewall a aplicativos de compartilhamento de arquivos P2P.

Tanto a inspeção de IM como de P2P oferecem políticas das Camadas 4 e 7 para o tráfego de aplicativos. Isso significa que o ZFW fornece uma inspeção stateful básica para permitir ou negar o tráfego, bem como oferece o controle granular da Camada 7 de atividades específicas nos diversos protocolos, de modo que determinadas atividades de aplicativo sejam permitidas e outras negadas.

Inspeção e Controle de Aplicativos P2P

O SDM 2.2 introduziu o controle de Aplicativos P2P em sua seção de configuração de Firewall. O SDM aplicava uma política de QoS e NBAR (Network-Based Application Recognition) para detectar e controlar a atividade de aplicativos P2P até uma taxa de linha zero, bloqueando todo o tráfego P2P. Como resultado, os usuários da CLI, que esperavam ter o suporte a aplicativos P2P na CLI do IOS Firewall, não podiam configurar o bloqueio desses aplicativos na CLI, a menos que conhecessem a configuração necessária de NBAR/QoS. O Cisco IOS Software Release 12.4(9)T introduz o controle nativo de aplicativos P2P na CLI do ZFW, permitindo que o NBAR detecte a atividade desses aplicativos. Essa release do software oferece suporte a vários protocolos de aplicativo P2P:

  • BitTorrent

  • eDonkey

  • FastTrack

  • Gnutella

  • KaZaA / KaZaA2

  • WinMX

A detecção de aplicativos P2P é particularmente difícil, como resultado do comportamento de “salto entre portas” e de outros truques utilizados para evitar a detecção; além disso, os problemas introduzidos por alterações e atualizações freqüentes nesses aplicativos, as quais modificam os comportamentos dos protocolos, também dificultam sua detecção. O ZFW combina a inspeção stateful do firewall nativo com os recursos de reconhecimento de tráfego do NBAR para oferecer o controle de aplicativos P2P em sua interface de configuração CPL. O NBAR oferece duas excelentes vantagens:

  • Reconhecimento opcional de aplicativos baseado em heurística para reconhecer os aplicativos apesar de seu comportamento complexo e de difícil detecção

  • Infra-estrutura extensível oferecendo um mecanismo de atualização para manter-se a par das atualizações e modificações dos protocolos

Configurando a Inspeção de Aplicativos P2P

Conforme mencionado anteriormente, a inspeção e o controle de aplicativos P2P oferecem Inspeção Stateful da Camada 4 e Controle de Aplicativos da Camada 7.

A inspeção da Camada 4 será configurada de maneira semelhante a outros serviços de aplicativo, caso a inspeção das portas nativas do serviço de aplicativo seja adequada:

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]

Observe a opção de assinatura adicional na instrução match protocol [service-name]. Quando essa opção é adicionada ao final da instrução match protocol, a heurística NBAR é aplicada ao tráfego para procurar sinais que indiquem a atividade específica de aplicativos P2P. Isso inclui o salto entre portas e outras alterações no comportamento dos aplicativos para evitar a detecção do tráfego. Esse nível de inspeção do tráfego resulta em maior utilização de CPU e menor taxa de transferência da rede. Se a opção de assinatura não for aplicada, a análise heurística baseada no NBAR não será aplicada para detectar o comportamento de salto entre portas, e haverá menor impacto na utilização de CPU.

A desvantagem da inspeção de serviço nativo é que não será possível manter o controle dos aplicativos P2P caso o aplicativo “salte” para uma porta de origem e de destino não-padrão ou se ele for atualizado para iniciar sua ação em um número de porta não reconhecido:

Aplicativo

Portas Nativas (reconhecidas pela lista 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

Dependente do PAM

winmx

TCP 6699

Se você desejar permitir (inspecionar) o tráfego P2P, uma configuração adicional poderá ser necessária. É possível que alguns aplicativos utilizem várias redes P2P ou implementem comportamentos específicos que precisem ser acomodados na configuração do firewall para que o aplicativo funcione:

  • Os clientes do BitTorrent geralmente se comunicam com “rastreadores” (servidores de diretório peer) via http executado em uma porta não-padrão. Normalmente essa porta é a TCP 6969, mas talvez você precise verificar a porta rastreadora específica do BitTorrent. Se desejar permitir o BitTorrent, o melhor método para acomodar a porta adicional é configurar o HTTP como um dos protocolos de correspondência e adicionar a porta TCP 6969 ao HTTP com o comando ip port-map:

    ip port-map http port tcp 6969
    

    Você precisará definir http e bittorrent como os critérios de correspondência aplicados no class-map.

  • Aparentemente o eDonkey inicia conexões que são detectadas como eDonkey e Gnutella.

  • A inspeção do KaZaA depende totalmente da detecção de assinatura do NBAR.

A Inspeção (de Aplicativo) da Camada 7 otimiza a Inspeção da Camada 4 ao permitir o reconhecimento e a aplicação de ações específicas de serviço, como o bloqueio seletivo ou recursos de pesquisa de arquivo, transferência de arquivo e bate-papo baseado em texto. Os recursos específicos de serviço variam de acordo com o serviço.

A Inspeção de Aplicativos P2P é semelhante à Inspeção de Aplicativos HTTP:

! Configura as características do tráfego da camada 7:
class-map type inspect [p2p protocol] match-any p2p-l7-cmap
 match action
!
! Configura a ação que será aplicada ao tráfego
! que corresponde às características específicas:
policy-map type inspect [p2p protocol] p2p-l7-pmap
 class type inspect p2p p2p-l7-cmap
  [ reset | allow ]
  log
!
! Define a política de inspeção da camada 4
class-map type inspect match-all p2p-l4-cmap
 match protocol [p2p protocol]
!
! Associa a classe da camada 4 e o mapa de políticas da camada 7
! no mapa de classes da camada 4.
policy-map type inspect private-allowed-policy
 class type inspect p2p-l4-cmap
  [ inspect | drop | pass ]
  service-policy p2p p2p-l7-pmap

A Inspeção de Aplicativos P2P oferece recursos específicos de aplicativo para um subconjunto de aplicativos com suporte na Inspeção da Camada 4:

  • edonkey

  • fasttrack

  • gnutella

  • kazaa2

Cada um desses aplicativos oferece diversas opções de critérios de correspondência específicos de aplicativo:

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

Novas definições ou atualizações dos protocolos P2P existentes podem ser carregadas por meio da funcionalidade de atualização dinâmica pdlm do NBAR. Este é o comando de configuração para carregar o novo PDLM:

ip nbar pdlm <file-location>

O novo protocolo está disponível nos comandos match protocol ... para inspeção do tipo de classe. Se o novo protocolo P2P contiver serviços (sub-protocolos), os novos tipos de class-map de inspeção da Camada 7, bem como os critérios de correspondência dessa camada, ficarão disponíveis.

Inspeção e Controle de Aplicativos de IM

O Cisco IOS Software Release 12.4(4)T introduziu a Inspeção e o Controle de Aplicativos de IM. Como o suporte a IM não foi introduzido com o ZFW no 12.4(6)T, os usuários não podiam aplicar o controle de IM e o ZFW na mesma política de firewall, uma vez que o ZFW e os recursos de firewall legados não podem coexistir na mesma interface.

O Cisco IOS Software Release 12.4(9)T oferece suporte à inspeção stateful e ao controle de aplicativos nestes serviços de IM:

  • AOL Instant Messenger

  • MSN Messenger

  • Yahoo! Messenger

A inspeção de IM é um pouco diferente da maioria dos serviços, pois depende do controle do acesso a um grupo específico de hosts em cada serviço. Geralmente, os serviços de IM utilizam um grupo relativamente permanente de servidores de diretório, os quais os clientes devem ser capazes de contatar para acessar o serviço. Geralmente, o controle de aplicativos de IM do ponto de vista do protocolo ou do serviço é muito difícil. A maneira mais eficiente de controlar esses aplicativos é limitar o acesso aos servidores de IM fixos.

Configurando a Inspeção de IM

A inspeção e o controle de IM oferecem Inspeção Stateful da Camada 4 e Controle de Aplicativos da Camada 7.

A inspeção da Camada 4 é configurada de maneira semelhante a outros serviços de aplicativo:

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

Os aplicativos de IM são capazes de contatar seus servidores em várias portas para manter sua funcionalidade. Se desejar permitir um serviço de IM específico aplicando a ação de inspeção, talvez você não precise de uma lista de servidores para definir o acesso permitido aos servidores desse serviço. Entretanto, a configuração de um class-map que especifique um determinado serviço de IM, como o AOL Instant Messenger, e a aplicação da ação descartar ao policy-map associado poderá fazer com que o cliente de IM tente e consiga localizar uma outra porta onde a conectividade com a Internet seja permitida. Se não desejar permitir a conectividade com determinado serviço ou se desejar restringir o recurso de serviço de IM ao bate-papo baseado em texto, você deverá definir uma lista de servidores para que o ZFW possa identificar o tráfego associado ao aplicativo de IM:

! Configura o mapa de parâmetros da 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 exemplo, a lista de servidores de IM do Yahoo é definida da seguinte maneira:

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

Você precisará aplicar a lista de servidores à definição de protocolo:

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

Você deve configurar os comandos ip domain lookup e ip name-server ip.ad.re.ss para ativar a resolução de nomes.

Os nomes de servidores de IM são muito dinâmicos. Você precisará verificar periodicamente se as listas de servidores de IM configuradas estão completas e corretas.

A Inspeção (de Aplicativo) da Camada 7 otimiza a Inspeção da Camada 4 ao reconhecer e aplicar ações específicas de serviço, como o bloqueio seletivo, ou ao permitir recursos de bate-papo baseado em texto e, ao mesmo tempo, negar outros recursos de serviços.

Atualmente, a Inspeção de Aplicativos de IM permite diferenciar entre a atividade de bate-papo baseado em texto e todos os outros serviços de aplicativo. Para restringir a atividade de IM ao bate-papo baseado em texto, configure uma política da Camada 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 a política da Camada 7 à política do 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

Filtragem de URL

O ZFW oferece recursos de filtragem de URL para que o acesso ao conteúdo da Web seja limitado ao especificado por uma lista de URLs confiáveis ou não confiáveis definida no roteador ou encaminhando os nomes de domínios a um servidor de filtragem de URL a fim de verificar o acesso a domínios específicos. A filtragem de URL do ZFW no Cisco IOS Software Releases 12.4(6)T a 12.4(15)T é aplicada como uma ação de política adicional, de forma semelhante à inspeção de aplicativos.

Para a filtragem de URL baseada em servidor, você deve definir um parameter-map que descreva a configuração do servidor urlfilter:

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

Se preferir listas estáticas de URLs confiáveis ou não confiáveis, você poderá definir uma lista de domínios ou subdomínios cujo acesso é especificamente permitido ou negado, enquanto a ação inversa é aplicada ao tráfego não correspondente à lista:

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

Se a lista de URLs não confiáveis for definida com opções de negação nas definições de domínio exclusivo, todos os outros domínios serão permitidos. Se definições “permit” forem configuradas, todos os domínios permitidos deverão ser explicitamente especificados, de forma semelhante à função das listas de controle de acesso IP.

Configure um class-map que fará a correspondência do tráfego HTTP:

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

Defina um policy-map que associe o seu class-map às ações inspect e urlfilter:

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

Esse procedimento configura os requisitos mínimos para a comunicação com um servidor de filtragem de URL. Há várias opções disponíveis para definir o comportamento adicional de filtragem de URL.

É possível que algumas implementações de rede apliquem a filtragem de URL a alguns hosts ou sub-redes, ignorando-a em outros hosts. Por exemplo, na Figura 9, todos os hosts da zona privada devem ter o tráfego HTTP verificado por um servidor de filtragem de URL, com exceção do host 192.168.1.101.

Figura 9: Topologia de exemplo de Filtragem de URL

zone-design-guide10.gif

Para que isso seja possível, é necessário definir dois class-maps diferentes:

  • Um class-map que faça a correspondência somente do tráfego HTTP referente ao grupo maior de hosts, que receberá a filtragem de URL.

  • Um class-map para o grupo menor de hosts, que não receberá a filtragem de URL. O segundo class-map fará a correspondência do tráfego HTTP, bem como de uma lista de hosts à qual política de filtragem de URL não será aplicada.

Ambos os class-maps são configurados em um policy-map, mas somente um receberá a ação 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

Controlando o Acesso ao Roteador

A maioria dos engenheiros de segurança de rede não se sente confortável em expor as interfaces de gerenciamento do roteador (por exemplo, SSH, Telnet, HTTP, HTTPS, SNMP etc.) à Internet pública e, em determinadas circunstâncias, também poderá ser necessário controlar o acesso da LAN ao roteador. O Cisco IOS Software oferece várias opções para limitar o acesso às diversas interfaces, incluindo a família de recursos NFP (Network Foundation Protection), vários mecanismos de controle de acesso às interfaces de gerenciamento e a zona "auto" do ZFW. Você deve examinar outros recursos, como controle de acesso VTY, proteção do plano de gerenciamento e controle de acesso SNMP, a fim de determinar qual combinação de recursos de controle do roteador será mais adequada ao seu aplicativo específico.

Geralmente, a família de recursos NFP é a mais adequada para controlar o tráfego destinado ao próprio roteador. Consulte Visão Geral da Segurança do Plano de Controle no Cisco IOS Software para obter informações que descrevem a proteção do roteador com recursos NFP.

Se decidir aplicar o ZFW para controlar o tráfego enviado e recebido dos endereços IP no próprio roteador, você deverá compreender que a política e os recursos padrão do firewall são diferentes dos disponíveis para o tráfego em trânsito. Esse tráfego é definido como o tráfego de rede cujos endereços IP de origem e de destino são diferentes dos aplicados a quaisquer interfaces do roteador, e não fará com que o roteador envie, por exemplo, mensagens de controle da rede, como mensagens de expiração de TTL do ICMP ou de rede/host inacessível.

O ZFW aplica uma política padrão de negação total ao tráfego entre zonas, exceto, conforme mencionado nas regras gerais, quando o tráfego que flui diretamente de uma zona para os endereços das interfaces do roteador é permitido implicitamente. Isso garante que a conectividade com as interfaces de gerenciamento do roteador seja mantida quando uma configuração de firewall de zonas for aplicada ao roteador. Se a mesma política de negação total afetasse a conectividade direta com o roteador, uma configuração completa de política de gerenciamento precisaria ser aplicada antes de as zonas serem configuradas no roteador. Isso provavelmente interromperia a conectividade de gerenciamento se a política fosse implementada de forma inadequada ou aplicada na ordem errada.

Quando uma interface é configurada como um membro da zona, os hosts conectados a essa interface são incluídos na zona. Entretanto, o fluxo de tráfego de entrada e saída dos endereços IP das interfaces do roteador não é controlado pelas políticas da zona (com exceção das circunstâncias descritas na nota após a Figura 10). Em vez disso, todas as interfaces IP do roteador tornam-se automaticamente parte da zona "auto" quando o ZFW é configurado. Para controlar o fluxo de tráfego IP para as interfaces do roteador a partir de suas diversas zonas, devem ser aplicadas políticas a fim de bloquear ou permitir/inspecionar o tráfego entre a zona e a zona "auto" do roteador, e vice-versa. (Consulte a Figura 10).

Figura 10: Aplicar a política entre as zonas da rede e a zona "auto" do roteador

zone-design-guide11.gif

Embora o roteador ofereça uma política de permissão padrão entre todas as zonas e a zona "auto", se for configurada uma política de qualquer zona para essa zona, e nenhuma política for configurada da zona "auto" para as zonas conectadas às interfaces do roteador configuráveis pelo usuário, todo o tráfego de origem do roteador encontrará a política da zona conectada para a zona "auto" quando retornar ao roteador e será bloqueado. Portanto, o tráfego originado no roteador deverá ser inspecionado para que possa retornar à zona "auto".

Nota: O Cisco IOS Software sempre utiliza o endereço IP associado aos hosts de destino “mais próximos” de uma interface para o tráfego, como syslog, tftp, telnet e outros serviços de plano de controle, e submete esse tráfego à política de firewall da zona "auto". Entretanto, se um serviço definir uma interface específica como a interface de origem por meio de comandos que incluam, mas não se limitem a, logging source-interface [type number], ip tftp source-interface [type number] e ip telnet source-interface [type number], o tráfego estará sujeito à política de firewall entre a zona da interface de origem e a zona de segurança do host de destino. Se um serviço for configurado para utilizar uma interface atribuída a uma zona de segurança específica, a política da zona "auto" não se aplicará ao tráfego desse serviço.

Nota: Alguns serviços (especialmente os serviços de voz sobre IP dos roteadores) utilizam interfaces efêmeras ou não configuráveis que não podem ser atribuídas a zonas de segurança. É possível que esses serviços não funcionem corretamente se o respectivo tráfego não puder ser associado a uma zona de segurança configurada. Se o serviço for configurado para utilizar uma das interfaces físicas ou virtuais configuráveis no dispositivo, o tráfego deverá ser tratado pela política da zona de segurança relevante para essa interface.

Limitações da Política da Zona "Auto"

A política da zona "auto" tem uma funcionalidade limitada quando comparada às políticas disponíveis para os zone pairs tráfego em trânsito:

  • Como na inspeção stateful clássica, o tráfego gerado pelo roteador é limitado à inspeção de TCP, UDP, ICMP e de protocolo complexo para H.323.

  • A Inspeção de Aplicativos não está disponível para políticas da zona "auto".

  • Não é possível configurar a limitação de sessões e de taxas nas políticas da zona "auto".

Configuração da Política da Zona "Auto"

Na maioria das circunstâncias, estas são as políticas de acesso desejáveis para os serviços de gerenciamento do roteador:

  • Negar toda a conectividade Telnet, uma vez que o protocolo de texto sem formatação do Telnet expõe facilmente as credenciais do usuário e outras informações confidenciais.

  • Permitir conexões SSH de qualquer usuário em qualquer zona. O SSH criptografa as credenciais do usuário e os dados de sessões, fornecendo proteção contra usuários mal-intencionados que utilizam ferramentas de captura de pacotes para espionar a atividade do usuário e comprometer suas credenciais ou informações confidenciais, como a configuração do roteador. O SSH Versão 2 fornece maior proteção e trata das vulnerabilidades específicas inerentes ao SSH Versão 1.

  • Permitir conectividade HTTP com o roteador a partir das zonas privadas, se essas zonas forem confiáveis. Caso contrário, se a zona privada oferecer o risco de que usuários mal-intencionados comprometam as informações, o HTTP não utilizará criptografia para proteger o tráfego de gerenciamento e poderá revelar informações confidenciais, como a configuração ou as credenciais do usuário.

  • Permitir a conectividade HTTPS a partir de qualquer zona. De maneira semelhante ao SSH, o HTTPS criptografa os dados de sessões e as credenciais do usuário.

  • Restringir o acesso SNMP a um host ou a uma sub-rede específica. O SNMP pode ser utilizado para modificar a configuração do roteador e revelar informações de configuração. O SNMP deve ser configurado com o controle de acesso nas diversas comunidades.

  • Bloquear as solicitações ICMP da Internet pública para o endereço da zona privada (pressupondo que esse endereço seja roteável). Um ou mais endereços públicos podem ser expostos ao tráfego ICMP para o troubleshooting da rede, se necessário. Vários ataques ICMP podem ser utilizados para sobrecarregar os recursos do roteador ou investigar a topologia e a arquitetura da rede.

Um roteador poderá aplicar esse tipo de política com a adição de dois zone pairs para cada zona a ser controlada. Cada zone pair para o tráfego de entrada ou de saída da zona "auto" do roteador deve ser atendido pela respectiva política na direção oposta, a menos que o tráfego não seja originado nessa direção. Um policy-map para cada zone pair de entrada e de saída poderá ser aplicado descrevendo todo o tráfego ou poderão ser aplicados policy-maps específicos por zone pair. A configuração de zone pairs específicos por policy-map fornece granularidade para exibição da atividade correspondente a cada policy-map.

Tomando como base uma rede de exemplo com uma estação de gerenciamento SNMP em 172.17.100.11 e um servidor TFTP em 172.17.100.17, esta saída fornece um exemplo da política completa de acesso da interface de gerenciamento:

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

Infelizmente, a política da zona "auto" não permite inspecionar as transferências TFTP. Portanto, o firewall deverá permitir todo o tráfego de entrada e saída do servidor TFTP, caso o TFTP deva passar pelo firewall.

Se o roteador encerrar as conexões VPN IPSec, você também deverá definir uma política para passar o IPSec ESP, o IPSec AH, o ISAKMP e o NAT-T IPSec (UDP 4500). Isso dependerá de qual deles será necessário com base nos serviços que você utilizará. A política a seguir pode ser aplicada, além da política acima. Observe a alteração nos policy-maps, onde um class-map para o tráfego VPN foi inserido com uma ação de passagem. Normalmente, o tráfego criptografado será confiável, a menos que a política de segurança determine que o tráfego criptografado enviado e recebido dos pontos finais especificados deva ser permitido.

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

Firewall Baseado em Zonas e Wide-Area Application Services

Consulte a Release Note do Cisco Wide Area Application Services (Versão 4.0.13 do Software) - Novos Recursos da Versão 4.0.13 do Software para obter uma nota do aplicativo com exemplos de configuração e orientação sobre uso.

Monitorando o Firewall de Política Baseada em Zonas com Comandos show e debug

O ZFW introduz novos comandos para exibir a configuração de políticas e monitorar a atividade do firewall.

Exiba a descrição da zona e as interfaces contidas em uma zona especificada:

show zone security [<zone-name>]

Quando o nome da zona não for incluído, o comando exibirá as informações de todas as zonas configuradas.

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

Exiba a zona de origem, a zona de destino e a política associada ao zone pair:

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

Quando não for especificada uma origem ou um destino, todos os zone pairs com a origem, o destino e a política associada serão exibidos. Quando somente a zona de origem/destino for mencionada, todos os pares de zona que contiverem essa zona como origem/destino serão exibidos.

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

Exibe um policy-map especificado:

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

Quando o nome de um policy-map não for especificado, o comando exibirá todos os policy-maps cujo tipo for inspeção (incluindo os policy-maps da Camada 7 que contêm um subtipo).

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

Exibe estatísticas de tempo de execução dos policy-maps de tipo de inspeção existentes em um zone pair especificado.

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

Quando no zone-pair name é mencionado, os policy-maps de todos os zone pairs são exibidos.

A opção sessions exibe as sessões de inspeção criadas pela aplicação do policy-map no 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

A palavra-chave urlfilter exibe estatísticas relacionadas a urlfilter pertencentes ao policy-map especificado (ou aos policy-maps em todos os destinos quando nenhum nome de zone pair for especificado):

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

Quando a palavra-chave cache é especificada junto com urlfilter, o comando exibe o cache urlfilter (de endereços IP).

Resumo do comando show policy-map para policy-maps de inspeção:

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

Ajustando a Proteção de Negação de Serviço do Firewall de Política Baseada em Zonas

O ZFW oferece proteção de DoS para alertar os engenheiros de rede sobre alterações drásticas na atividade da rede, bem como minimizar a atividade indesejada a fim de reduzir o impacto das alterações na atividade da rede. O ZFW mantém um contador separado para o class-map de cada policy-map. Portanto, se um class-map for utilizado para os policy-maps de dois zone pairs diferentes, dois conjuntos diferentes de contadores de proteção de DoS serão aplicados.

O ZFW permite a mitigação de ataques de DoS como padrão nas releases do Cisco IOS Software anteriores à 12.4(11)T. O comportamento padrão da proteção de DoS foi alterado no Cisco IOS Software Release 12.4(11)T. Consulte Ajustando a Proteção de Negação de Serviço do Cisco IOS Firewall a fim de obter mais detalhes e um procedimento para ajustar a proteção de DoS do ZFW.

Consulte Definindo Estratégias para Proteger Contra Ataques de Negação de Serviço SYN de TCP para obter mais informações sobre ataques de DoS SYN de TCP.

Apêndice

Apêndice A: Configuração 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: Configuração 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: Configuração Básica do Firewall de Política de Zonas para Duas Zonas

Este exemplo fornece uma configuração simples como base para testar as melhorias introduzidas no ZFW do Cisco IOS Software. Essa é uma configuração de modelo de duas zonas, conforme definido em um roteador 1811. A zona privada é aplicada às portas fixas do switch do roteador, de modo que todos os hosts nessas estão conectados à VLAN 1. A zona pública é aplicada à 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

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Document ID: 98628