* The preview only show first 10 pages of manuals. Please download to view the full documents. Show
Loading preview... Please wait.
Add to bookmark DescriptionDownload Exam CCNA 640 802 - Material Ouro PDF for free. Report "Exam CCNA 640 802 - Material Ouro"About UsWe believe everything in the web must be free. So this website was created for free download documents from the web. Legal NoticeWe are not related with any websites in any case. DisclaimerWe are not liable for the documents. You are self-liable for your save offline. Cookie PolicyThis site utilizes cookies to guarantee you get the best experience on our site. You can learn how to disable cookie here. Privacy PolicyWe are committed to ensuring that your privacy is protected. Copyright/DMCAYou can ask for link removal via contact us. IntroductionEste documento descreve o modelo de configuração do conjunto de recursos do Cisco IOS® Firewall, Zone-based Policy Firewall (ZFW). PrerequisitesRequirementsNão existem requisitos específicos para este documento. Componentes UtilizadosEste documento não se restringe a versões de software e hardware específicas. The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando. ConventionsConsulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos. Informações de ApoioEsse novo modelo de configuração oferece políticas intuitivas para roteadores de várias interfaces, maior granularidade de aplicação de política de firewall e uma política padrão de negação total que proíbe tráfego entre zonas de segurança de firewall até uma política explícita aplicada para permitir o tráfego desejável. Quase todos os recursos clássicos do Cisco IOS Firewall implementados antes da versão de software do Cisco IOS 12.4(6)T são aceitos na nova interface de inspeção de política de acordo com a zona:
O software Cisco IOS versão 12.4(9)T adicionou o suporte ZFW para os limites de taxa de transferência e sessão/conexão por classe, além de controle e inspeção de aplicação:
O software Cisco IOS versão 12.4(11)T adicionou estatísticas para facilitar o ajuste de proteção DoS. Alguns recursos e funcionalidades do firewall clássico do Cisco IOS ainda não são compatíveis em um ZFW no software Cisco IOS versão 12.4(15)T:
O ZFW geralmente melhora o desempenho do Cisco IOS para a maioria das atividades de inspeção do firewall. Nem o Cisco IOS ZFW nem o Classic Firewall incluem suporte à inspeção stateful para tráfego multicast. Resumo da política de acordo com a zonaA inspeção stateful do Cisco IOS Classic Firewall (anteriormente conhecida como controle de acesso baseado em contexto ou CBAC) empregava um modelo de configuração de acordo com a interface, no qual uma política de inspeção stateful era aplicada a uma interface. Todo o tráfego que passa por essa interface recebeu a mesma política de inspeção. Esse modelo de configuração limitou a granularidade das políticas de firewall e ocasionou uma confusão sobre a aplicação adequada de políticas de firewall, especialmente em cenários quando as políticas de firewall devem ser aplicadas entre várias interfaces. O firewall de política de acordo com a zona (também conhecido como firewall de política de zona ou ZFW) altera a configuração de firewall do modelo antigo de acordo com a interface para um modelo baseado em zona mais flexível e fácil de entender. As interfaces são atribuídas a zonas e a política de inspeção é aplicada ao tráfego que se move entre as zonas. As políticas entre as zonas oferecem flexibilidade e granularidade consideráveis; portanto, políticas de inspeção diferentes podem ser aplicadas a vários grupos de hosts conectados à mesma interface do roteador. As políticas de firewall são configuradas com o Cisco Policy Language (CPL), que emprega uma estrutura hierárquica para definir a inspeção de protocolos de rede e os grupos de hosts aos quais a inspeção pode ser aplicada. Modelo de configuração de política de acordo com a zonaO ZFW altera completamente a maneira pela qual você configura uma inspeção do Cisco IOS Firewall, em comparação com o firewall clássico do Cisco IOS. A primeira grande alteração na configuração do firewall é a introdução da configuração de acordo com a zona. O Cisco IOS Firewall é o primeiro recurso de defesa contra ameaças do software Cisco IOS para implementar um modelo de configuração de zona. Outros recursos podem adotar o modelo de zona ao longo do tempo. O modelo de configuração de acordo com a interface da inspeção stateful do Cisco IOS Classic Firewall (ou CBAC) que emprega o conjunto de comandos ip inspect é mantido por um período. No entanto, poucos novos recursos, se houver, são configuráveis com a interface de linha de comando clássica (CLI). O ZFW não usa os comandos de inspeção stateful ou CBAC. Os dois modelos de configuração podem ser usados simultaneamente nos roteadores, porém não combinados em interfaces. Uma interface não pode ser configurada como um membro de zona de segurança e, ao mesmo tempo, configurada para ip inspect . As zonas estabelecem as bordas de segurança da rede. Uma zona define um limite onde o tráfego está sujeito a restrições de política, pois atravessa para outra região da rede. A política padrão ZFW entre regiões é deny all. Se nenhuma política estiver configurada explicitamente, todo o tráfego que se move entre as zonas será bloqueado. Essa é uma partida significativa do modelo de inspeção stateful, em que o tráfego era implicitamente permitido até ser explicitamente bloqueado com uma lista de controle de acesso (ACL). A segunda grande alteração é a introdução de uma nova linguagem de política de configuração conhecida como CPL. Os usuários familiarizados com a CLI de Qualidade de Serviço (QoS - Modular Quality-of-Service) do Software Cisco IOS (MQC - Modular Quality-of-Service) podem reconhecer que o formato é semelhante ao uso de mapas de classe para especificar qual tráfego é afetado pela ação aplicada em um mapa de política. Regras Para Aplicativo De Firewall De Diretiva Baseada Em ZonaAs associações de interface de rede do roteador em zonas estão sujeitas a várias regras que controlam o comportamento da interface, assim como o tráfego que se move entre as interfaces de membro de zona:
Projetar Segurança de Rede com Política Baseada em ZonaUma zona de segurança deve ser configurada para cada região de segurança relativa dentro da rede, para que todas as interfaces atribuídas à mesma zona sejam protegidas com um nível de segurança semelhante. Por exemplo, considere um roteador de acesso com três interfaces:
Cada interface nessa rede é atribuída a sua própria zona, embora você possa permitir acesso variado da Internet pública a hosts específicos na DMZ e políticas de uso de aplicativos variadas para hosts na LAN protegida. (Consulte a Figura 1.) Figura 1: Topologia básica de zona de segurança
Neste exemplo, cada zona contém apenas uma interface. Se uma interface adicional for adicionada à região privada, os hosts conectados à nova interface na região poderão passar o tráfego para todos os hosts na interface atual na mesma região. Além disso, o tráfego de host para hosts em outras zonas é igualmente afetado pelas políticas atuais. Geralmente, a rede do exemplo tem três políticas principais:
Como a DMZ é exposta à Internet pública, os hosts da DMZ podem estar sujeitos a atividades indesejadas de indivíduos mal-intencionados que podem danificar um ou mais hosts da DMZ. Se nenhuma política de acesso for fornecida para que os hosts DMZ acessem os hosts da zona privada ou da zona da Internet, os indivíduos que comprometeram os hosts DMZ não poderão usar os hosts DMZ para realizar ataques adicionais contra hosts privados ou da Internet. O ZFW impõe uma postura de segurança padrão proibitiva. Portanto, a menos que os hosts DMZ tenham especificamente acesso a outras redes, elas são protegidas contra qualquer conexão dos hosts DMZ. Da mesma forma, nenhum acesso é fornecido para os hosts da Internet acessarem os hosts de zona privados; portanto, os hosts de zona privados estão protegidos contra o acesso indesejado dos hosts da Internet. Usar VPN IPSec com firewall de política baseado em zonaMelhorias recentes na VPN IPSec simplificam a configuração de política de firewall para conectividade VPN. A Interface de Túnel Virtual (VTI - Virtual Tunnel Interface) IPSec e o GRE+IPSec permitem o confinamento de conexões de site a site e de cliente VPN a uma zona de segurança específica colocando as interfaces de túnel em uma zona de segurança específica. As conexões poderão ser isoladas em um DMZ de VPN se a conectividade precisar 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, a política de firewall de conectividade VPN exigirá uma análise mais cuidadosa para manter a segurança. A política de zona deve permitir especificamente o acesso por um endereço IP para hosts de local remoto ou clientes VPN se os hosts seguros estiverem em uma zona diferente da conexão criptografada do cliente VPN para o roteador. Se a política de acesso não estiver configurada corretamente, os hosts que devem ser protegidos podem acabar expostos a hosts indesejados e potencialmente hostis. Consulte Uso de VPN com firewall de política de acordo com a zona para obter mais informações sobre o conceito e a configuração. Configuração de linguagem de política da Cisco (CPL)Esse procedimento pode ser usado para configurar um ZFW. A sequência de etapas não é importante, mas alguns eventos devem ser concluídos na ordem. Por exemplo, configure um class-map antes de atribuí-lo a um policy-map. Da mesma forma, você não pode atribuir um policy-map a um zone-pair, até que tenha configurado a política. Se você tentar configurar uma seção que depende de outra parte da configuração não definida, o roteador responderá com uma mensagem de erro.
Configurar Mapas de Classes de Firewall de Política Baseada em ZonaOs class-maps definem o tráfego que o firewall seleciona para a aplicação da política. Os class-maps de Camada 4 classificam o tráfego baseado nos critérios listados aqui. Estes critérios são especificados com o comando match em um mapa de classes:
Combinar Critérios de "Correspondência": "Correspondência-qualquer" versus "correspondência"Os class-maps podem aplicar operadores match-any ou match-all para determinar como aplicar os critérios de correspondência. Se match-any for especificado, o tráfego deverá atender apenas a um dos critérios de correspondência no mapa de classes. Se match-all for especificado, o tráfego deverá corresponder a todos os critérios de mapa de classe para pertencer a essa classe específica. Critérios de correspondência devem ser aplicados a fim de mais específico para menos específico se o tráfego atender 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 deve encontrar o protocolo de correspondência http primeiro para garantir que o tráfego seja tratado pelos recursos específicos de serviço de inspeção de HTTP. Se as linhas de correspondência forem invertidas, o tráfego encontrará a instrução TCP do protocolo de correspondência antes de compará-la ao protocolo http, o tráfego é simplesmente classificado como tráfego TCP e inspecionado com base nas capacidades do componente Firewall TCP Inspection. Esse é um problema para determinados serviços (como FTP, TFTP) e vários serviços de sinalização de voz e multimídia (como H.323, SIP, Skinny, RTSP e outros). Esses serviços exigem recursos adicionais de inspeção para reconhecer as atividades mais complexas deles. Aplicar uma ACL como critério de correspondênciaClass-maps podem aplicar uma ACL como um dos critérios de correspondência para a aplicação da política. Se um mapa de classe corresponder apenas ao critério de uma ACL e o mapa de classe estiver associado a um mapa de política que aplica a ação de inspeção, o roteador aplicará a inspeção básica de TCP ou UDP para todo o tráfego permitido pela ACL, exceto pelo que o ZFW fornece a inspeção com reconhecimento de aplicativos. Isso inclui (mas não se limita a) FTP, SIP, Skinny (SCCP), H.323, Sun RPC e TFTP. Se a inspeção específica da aplicação estiver disponível e a ACL permitir o canal primário ou de controle, qualquer canal secundário ou de mídia associado ao primário/controle será permitido, independentemente de a ACL permitir o tráfego. Se um class-map aplica somente a ACL 101 como critério de correspondência, uma ACL 101 é exibida da seguinte forma: access-list 101 permit ip any any Todo o tráfego é permitido na direção da política de serviço aplicada a um determinado par de zonas, e o tráfego de retorno que corresponde a isso é permitido na direção oposta. Portanto, a ACL deve aplicar a restrição para limitar o tráfego aos tipos desejados específicos. Observe que a lista PAM inclui serviços de aplicativos como HTTP, NetBIOS, H.323 e DNS. No entanto, apesar do conhecimento do PAM sobre o uso de aplicativos específicos de uma determinada porta, o firewall aplica apenas recursos suficientes específicos de aplicativos para acomodar os requisitos bem conhecidos do tráfego de aplicativos. Assim, o tráfego de aplicações simples, como Telnet, SSH, e outras aplicações de canal único, são inspecionados como TCP, e suas estatísticas são combinadas na saída do comando show. Se a visibilidade específica do aplicativo na atividade da rede for desejada, você precisará configurar a inspeção de serviços por nome do 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 diretiva de firewall mais explícita exibida mais adiante na página. Essa configuração é usada para inspecionar o tráfego de um telefone IP Cisco, bem como várias estações de trabalho que usam uma variedade de tráfego, incluindo 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 essa configuração seja fácil de definir e acomodar todo o tráfego originado na zona privada (desde que o tráfego siga as portas de destino reconhecidas por PAM padrão), ela fornece visibilidade limitada na atividade de serviço e não oferece a oportunidade de aplicar limites de largura de banda e de sessão de ZFW para tipos específicos de tráfego. Esta saída de comando show policy-map type inspect zone-pair priv-pub é o resultado de uma configuração simples anterior que usa somente um permit ip [subnet] de qualquer ACL entre pares de zonas. Como você pode ver, a maior parte do tráfego da estação de trabalho é contabilizada nas estatísticas básicas de TCP ou UDP: Por outro lado, uma configuração semelhante que adiciona classes específicas de aplicativos fornece estatísticas e controle de aplicativos mais granulares e ainda acomoda a mesma amplitude de serviços mostrada no primeiro exemplo quando você define o mapa de classes de última oportunidade que corresponde apenas à ACL como a última chance no mapa de políticas: 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 essa saída granular considerável do comando show policy-map type inspect zone-pair priv-pub: Outro benefício adicional quando uma configuração de mapa de classe e mapa de política mais granular é usada, como mencionado anteriormente, é uma oportunidade de aplicar limites específicos de classe em valores de sessão e taxa; e, para ajustar especificamente os parâmetros de inspeção pela aplicação de um mapa de parâmetros para ajustar cada comportamento de inspeção de classe. Configurar Mapas de Políticas de Firewall da Política Baseada em ZonaO mapa de políticas aplica ações de política de firewall a um ou mais mapas de classe para definir a política de serviço que é aplicada a um par de zonas de segurança. Quando um inspect-type policy-map é criado, uma classe padrão denominada class class-default é aplicada no final da classe. A ação de política padrão classe-padrão é descartar, mas pode ser alterada para passar. A opção de registro pode ser adicionada com a ação de descartar. A inspeção não pode ser aplicada em class class-default. Ações de firewall de política de acordo com a zonaO ZFW fornece três ações de tráfego que atravessam de uma zona a outra:
As ações são associadas com class-maps em policy-maps: configure terminal policy-map type inspect z1-z2-pmap class type inspect service-cmap inspect|drop|allow [service-parameter-map] Os mapas de parâmetros oferecem opções para modificar os parâmetros de conexão para uma determinada política de inspeção de mapa de classes. Configurar mapas de parâmetros do firewall de política de zonaOs mapas de parâmetros especificam o comportamento de inspeção para ZFW, para parâmetros como proteção DoS, temporizadores de conexão TCP/UDP e configuração de registro de trilha de auditoria. Os parameter-maps também são aplicados à classe de Camada 7 e aos policy-maps para definir o comportamento específico da aplicação, como objetos HTTP, requisitos de autenticação de POP3 e IMAP e outras informações específicas da aplicação. Os parameter-maps de inspeção para ZFW são configurados como type inspect, semelhante a outra classe de ZFW e policy-objects: Os tipos específicos de parameter-maps especificam os parâmetros aplicados pelas políticas de inspeção de aplicação da camada 7. Os mapas de parâmetros do tipo Regex definem uma expressão regular para uso com a inspeção de aplicativos HTTP que filtra o tráfego com uma expressão regular: parameter-map type regex [parameter-map-name] Os mapas de parâmetros do tipo info do protocolo definem nomes de servidor para uso com a inspeção de aplicativos IM: parameter-map type protocol-info [parameter-map-name] Detalhes completos de configuração para inspeção de aplicações HTTP e IM são fornecidos nas respectivas seções de inspeção de aplicações deste documento. Aplicar log para políticas de firewall de política baseada em zonaO ZFW oferece opções de registro para o tráfego descartado ou inspecionado por padrão, ou para ações de política de firewall configuradas. O registro de audit-trail está disponível para o tráfego que o ZFW inspeciona. A trilha de auditoria é aplicada quando uma trilha de auditoria é definida em um mapa de parâmetros e o mapa de parâmetros com a ação de inspeção é aplicado em um mapa de políticas: configure terminal policy-map type inspect z1-z2-pmap class type inspect service-cmap inspect|drop|allow [parameter-map-name (optional)] O registro de descarte está disponível para o tráfego que o ZFW descarta. O log de descarte é configurado pelo quando você adiciona um log com a ação de descarte em um mapa de políticas: configure terminal policy-map type inspect z1-z2-pmap class type inspect service-cmap inspect|drop|allow [service-parameter-map] Editar mapas de classe e mapas de política do firewall de política de zonaO ZFW não incorpora atualmente um editor que possa modificar as várias estruturas de ZFW, como policy-maps, class-maps e parameter-maps. Para reorganizar as instruções de correspondência em uma aplicação de class-map ou ação para vários class-maps contidos em um policy-map, você precisa concluir estas etapas:
Exemplos de configuraçãoEste exemplo de configuração emprega um Cisco 1811 Integrated Services Router. Uma configuração básica com conectividade IP, configuração de VLAN e ponte transparente entre dois segmentos de LAN Ethernet privados está disponível no Apêndice A. O roteador está separado em cinco zonas:
Figura 2: Detalhes da topologia da zona
Essas políticas são aplicadas, com as zonas de rede definidas anteriormente:
Figura 3: As permissões de serviço de zone-pair a serem aplicadas no exemplo de configuração
Essas políticas de firewall são configuradas em ordem de complexidade:
Como você aplica partes da configuração a diferentes segmentos de rede em momentos diferentes, é importante lembrar que um segmento de rede perde conectividade com outros segmentos quando é colocado em uma zona. Por exemplo, quando a zona privada é configurada, os hosts na zona privada perdem a conectividade com as zonas DMZ e Internet até que suas respectivas políticas sejam definidas. Firewall de roteamento de inspeção statefulConfigurar política privada de InternetA figura 4 ilustra a configuração da política de Internet privada. Figura 4: Inspeção de serviço de zona privada para a zona da Internet
A política de Internet privada aplica a inspeção de Camada 4 à inspeção de HTTP, HTTPS, DNS e Camada 4 para ICMP, da zona privada até a zona da Internet. Isso permite conexões da zona privada com a zona da Internet e permite o tráfego de retorno. A inspeção da camada 7 traz as vantagens de um controle mais rígido do aplicativo, melhor segurança e suporte para aplicativos que exigem correção. No entanto, a inspeção da Camada 7, como mencionado, requer um melhor entendimento da atividade da rede, já que os protocolos da Camada 7 que não estão configurados para inspeção não são permitidos entre zonas.
Configure o zone-pair e aplique o policy-map apropriado. Note: Você só precisa configurar o par de zona de Internet privada no momento para inspecionar conexões originadas na zona privada que viaja para a zona de Internet, mostrada a seguir: configure terminal zone-pair security private-internet source private destination internet service-policy type inspect private-internet-policy Isso conclui a configuração da política de inspeção da Camada 7 no par de zonas da Internet privada para permitir conexões HTTP, HTTPS, DNS e ICMP da zona de clientes para a zona de servidores e aplicar inspeção de aplicações ao tráfego HTTP e garantir que a passagem do tráfego indesejado não seja permitido na porta de serviço do HTTP, TCP 80. Configurar a política DMZ privadaA figura 5 ilustra a configuração da política de DMZ privada. Figura 5: Inspeção de serviço de zona privada para a zona de DMZ
A política de DMZ privada traz mais complexidade, pois requer uma melhor compreensão do tráfego de rede entre as zonas. Essa política aplica a inspeção de Camada 7 da zona privada para a DMZ. Isso permite conexões da zona privada para a DMZ e permite o tráfego de retorno. A inspeção da camada 7 traz as vantagens de um controle mais rígido do aplicativo, melhor segurança e suporte para aplicativos que exigem correção. No entanto, a inspeção da Camada 7, como mencionado, requer um melhor entendimento da atividade da rede, já que os protocolos da Camada 7 que não estão configurados para inspeção não são permitidos entre zonas.
Note: No momento, você só precisa configurar o par de zonas DMZ privadas para inspecionar as conexões originadas na zona privada que trafega para a DMZ, mostrado a seguir: configure terminal zone-pair security private-dmz source private destination dmz service-policy type inspect private-dmz-policy Isso 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 para a zona de servidores. A política não aplica correções para canais subordinados, mas fornece um exemplo de política simples para acomodar a maioria das conexões de aplicativos. Configurar a política de DMZ de InternetA figura 6 ilustra a configuração da política DMZ da Internet. Figura 6: Inspeção de serviço de zona de Internet para a zona de DMZ
Essa política aplica a inspeção de Camada 7 da zona de Internet para a DMZ. Isso permite conexões da zona da Internet com a DMZ e permite o tráfego de retorno dos hosts da DMZ para os hosts da Internet que originaram 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, visando restringir o acesso a serviços específicos em hosts, grupos de hosts ou sub-redes específicos. Para realizar esse aninhamento, um mapa de classe que especifica serviços em outro mapa de classe que faz referência a uma ACL para especificar endereços IP.
Firewall transparente de inspeção statefulConfigurar a política de servidores-clientesA próxima figura ilustra a configuração da política servidor-cliente. Figura 7: Inspeção de serviço da zona de Servidores para a zona de Clientes
A política de servidores-clientes aplica inspeção com um serviço definido pelo usuário. A inspeção da Camada 7 é aplicada da zona de servidores à zona de clientes. Isso permite conexões X Windows a um intervalo de portas específico da zona de servidores à zona de clientes e permite o tráfego de retorno. O X Windows não é um protocolo nativo suportado no PAM, portanto um serviço configurado pelo usuário no PAM deve ser definido para que o ZFW possa reconhecer e inspecionar o tráfego apropriado. Duas ou mais interfaces de roteador são configuradas em um grupo de pontes IEEE para fornecer Integrated Routing and Bridging (IRB) para fornecer bridging entre as interfaces no grupo de pontes e para rotear para outras sub-redes através da Bridge Virtual Interface (BVI). A política de firewall transparente aplica a inspeção de firewall para o tráfego que "atravessa a ponte", mas não para o tráfego que sai do grupo de pontes através do BVI. A política de inspeção só se aplica ao tráfego que atravessa o bridge-group. Portanto, nesse cenário, a inspeção é aplicada apenas ao tráfego que se move entre as zonas de clientes e servidores, que são aninhadas dentro da zona privada. A política aplicada entre a zona privada e as zonas pública e DMZ só entra em cena quando o tráfego deixa o grupo de pontes pelo BVI. Quando o tráfego sai via BVI das zonas de clientes ou servidores, a política de firewall transparente não é chamada.
Configurar a política de clients-serversA Figura 8 ilustra a configuração da política de client-server. Figura 8: Inspeção de serviço da zona de Clientes para a zona de Servidores
A política de cliente-servidores é menos complexa do que as outras. A inspeção da Camada 4 é aplicada da zona de clientes à zona de servidores. Isso permite conexões da zona de clientes para a zona de servidores e permite tráfego de retorno. A inspeção da Camada 4 traz simplifica a configuração do firewall, pois são necessárias apenas algumas regras para permitir a maior parte do tráfego de aplicações. No entanto, a inspeção da Camada 4 também tem duas desvantagens principais:
As duas interfaces do roteador são configuradas em um grupo de pontes IEEE, portanto, essa política de firewall aplica inspeção de firewall transparente. Essa política é aplicada em duas interfaces em um grupo de ponte de IEEE. A política de inspeção aplica-se apenas ao tráfego que atravessa o grupo de bridge. Isso explica por que as zonas clientes e servidores estão aninhadas dentro da zona privada.
Política de Taxa para Firewall de Política Baseada em ZonaAs redes de dados frequentemente se beneficiam com a capacidade de limitar a taxa de transmissão de tipos específicos de tráfego de rede e de limitar o impacto do tráfego de prioridade mais baixa a um tráfego essencial para a empresa. O software Cisco IOS oferece esse recurso com vigilância de tráfego , que limita a taxa nominal de tráfego e o burst. O software Cisco IOS tem a política de tráfego compatível desde o Cisco IOS versão 12.1(5)T. O Cisco IOS Software Release 12.4(9)T aumenta o ZFW com limitação de taxa quando você adiciona a capacidade de policiar o tráfego que se aplica que corresponde às definições de um mapa de classe específico quando ele atravessa o firewall de uma zona de segurança para outra. Isso oferece a conveniência de um ponto de configuração para descrever o tráfego específico, aplicar a política de firewall e vigiar esse consumo de largura de banda de tráfego. O ZFW difere do baseado em interface porque fornece apenas as ações de transmissão para conformidade de política e queda para violação de política. O ZFW não pode marcar o tráfego para DSCP. O ZFW só pode especificar o uso de largura de banda em bytes/segundo, pacote/segundo e a porcentagem de largura de banda não é oferecida. O ZFW pode ser aplicado com ou sem interface-based. Portanto, se forem necessários recursos adicionais, esses recursos podem ser aplicados por interface baseada em. Se o baseado em interface for usado em conjunto com o firewall, certifique-se de que as políticas não entrem em conflito. Configurar política ZFWO policiamento de ZFW limita o tráfego em um mapa de classe de política a um valor de taxa definido pelo usuário entre 8.000 e 2.000.000.000 bits por segundo, com um valor de burst configurável no intervalo de 1.000 a 512.000.000 bytes. A política de ZFW é configurada por uma linha adicional de configuração em policy-map, que é 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ãoA política de ZFW também introduziu o controle de sessão para limitar a contagem de sessão para tráfego em um mapa de política que se aplica que corresponda a um mapa de classe. Isso aumenta a capacidade atual de aplicar a política de proteção contra DoS por mapa de classe. Efetivamente, isso permite o controle granular do número de sessões que se aplicam que corresponde a qualquer mapa de classe fornecido que atravessa um par de zonas. Se o mesmo class-map é usado em vários policy-maps ou zone-pairs, os limites de sessão diferentes podem ser aplicados em vários aplicações de class-map. O controle de sessão é aplicado quando um mapa de parâmetros é configurado e contém o volume de sessão desejado, e o mapa de parâmetros é anexado à ação de inspeção aplicada a um mapa de classes em um mapa de políticas: 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 mapas de parâmetros só podem ser aplicados à ação de inspeção e não estão disponíveis em ações de aprovação ou soltar. As atividades de controle e vigilância de sessão ZFW são visíveis com este comando: show policy-map type inspect zone-pair Inspeção de aplicaçõesA inspeção de aplicações introduz recursos adicionais para o ZFW. As políticas de inspeção de aplicação são aplicadas na Camada 7 do modelo OSI, onde as aplicações do usuário enviam e recebem mensagens que permitem às aplicações oferecerem recursos úteis. Alguns aplicativos podem oferecer recursos indesejados ou vulneráveis, portanto, as mensagens associadas a esses recursos devem ser filtradas para limitar as atividades nos serviços de aplicativos. O ZFW do software Cisco IOS oferece inspeção e controle de aplicações nesses serviços de aplicações:
A inspeção e o controle de aplicações (AIC) variam de acordo com a capacidade por serviço. A inspeção de HTTP oferece filtragem granular em vários tipos de atividade de aplicativos e fornece recursos para limitar o tamanho da transferência, o tamanho do endereço da Web e a atividade do navegador para impor conformidade com padrões de comportamento de aplicativos e para limitar os tipos de conteúdo que são transferidos pelo serviço. O AIC para SMTP pode limitar o tamanho do conteúdo e reforçar a conformidade do protocolo. A inspeção POP3 e IMAP pode ajudar a garantir que os usuários usem mecanismos de autenticação seguros para evitar o comprometimento das credenciais do usuário. A inspeção de aplicativos é configurada como um conjunto adicional de mapas de classe e mapas de política específicos do aplicativo, que são então aplicados aos mapas de classe e mapas de política de inspeção atuais quando você define a política de serviço do aplicativo no mapa de política de inspeção. Inspeção de aplicações HTTPA inspeção de aplicativos pode ser aplicada no tráfego HTTP para controlar o uso indesejado da porta de serviço HTTP para outros aplicativos, como IM, compartilhamento de arquivos P2P e aplicativos de tunelamento que podem redirecionar aplicativos que, de outra forma, teriam firewall por meio do TCP 80. Configure um class-map de inspeção de aplicação para descrever o tráfego que viola o tráfego HTTP permitido: ! configure the actions that are not permitted class-map type inspect http match-any http-aic-cmap match request port-misuse any match req-resp protocol-violation ! define actions to be applied to unwanted traffic policy-map type inspect http http-aic-pmap class type insp http http-aic-cmap reset log ! define class-map for stateful http inspection class-map type inspect match-any http-cmap match protocol http ! define class-map for stateful inspection for other traffic class-map type inspect match-any other-traffic-cmap match protocol smtp match protocol dns match protocol ftp ! define policy-map, associate class-maps and actions 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 na inspeção de aplicações HTTPO Cisco IOS Software Release 12.4(9)T introduz melhorias nos recursos de inspeção de HTTP do ZFW. O firewall Cisco IOS introduziu a inspeção de aplicação HTTP no software Cisco IOS versão 12.3(14)T. O Cisco IOS Software Release 12.4(9)T aumenta as capacidades atuais quando você adiciona:
Exemplos de configuração para melhorias na inspeção de aplicativos HTTP supõem uma rede simples, como mostrado na Figura 9. Figura 9: Inspeção de aplicativos Presume uma rede simples
O firewall agrupa o tráfego em duas classes:
O HTTP é separado para permitir a inspeção específica no tráfego da Web. Isso permite que você configure a vigilância na primeira seção deste documento e a inspeção do aplicação de HTTP na segunda seção. Você pode configurar mapas de classe e mapas de política específicos para o tráfego P2P e IM na terceira seção deste documento. A conectividade é permitida da zona privada para a zona pública. Nenhuma conectividade é fornecida da zona pública para a zona privada. Consulte o Apêndice C para obter uma configuração completa que implementa a política inicial. Configurar Melhorias da Inspeção de Aplicativos HTTPA inspeção de aplicações HTTP (bem como outras políticas de inspeção de aplicações) requer configurações mais complexas que a configuração básica da Camada 4. Você deve configurar a classificação e a política de tráfego da Camada 7 para reconhecer o tráfego específico que deseja controlar e aplicar a ação desejada a tráfegos desejáveis e indesejados. A inspeção de aplicações HTTP (semelhante a outros tipos de inspeção de aplicações) só pode ser aplicada ao tráfego HTTP. Portanto, você deve definir class-maps e policy-maps de Camada 7 para tráfego HTTP específico, depois definir um class-map de Camada 4 especificamente para HTTP e aplicar a política de Camada 7 à inspeção HTTP em um policy-map de Camada 4, dessa forma: !configure the layer-7 traffic characteristics: class-map type inspect http match-any http-l7-cmap match req-resp protocol-violation match request body length gt 4096 ! !configure the action to be applied to the traffic !matching the specific characteristics: policy-map type inspect http http-l7-pmap class type inspect http http-l7-cmap reset log ! !define the layer-4 inspection policy class-map type inspect match-all http-l4-cmap match protocol http ! !associate layer-4 class and layer-7 policy-map !in the layer-4 policy-map: policy-map type inspect private-allowed-policy class type inspect http-l4-cmap inspect service-policy http http-l7-pmap Todas essas características de tráfego de inspeção do aplicação HTTP são definidas em um class-map de Camada 7:
Exemplos de casos de uso
Header length inspection — Esse comando verifica o tamanho de um cabeçalho de solicitação ou de resposta e aplica a ação se o tamanho exceder o limite configurado. Ação permitida ou redefinida. A adição da ação de registro causa uma mensagem syslog: APPFW-4- HTTP_HEADER_LENGTH Uso do comando: Exemplos de casos de uso Configure uma política http appfw para bloquear solicitações e respostas que tenham um tamanho de cabeçalho superior a 4096 bytes. Header count inspection — Esse comando verifica o número de linhas de cabeçalho (campos) em uma solicitação/resposta e aplica uma ação quando a contagem excede o limite configurado. Ação permitida ou redefinida. A adição da ação de registro causa uma mensagem syslog: APPFW-6- HTTP_HEADER_COUNT Uso do comando: Exemplos de casos de uso Configure uma política http appfw para bloquear uma solicitação com mais de 16 campos de cabeçalho. Header field inspection — Esse comando permite permitir/negar/monitorar solicitações/respostas que contêm um campo e um valor de cabeçalho HTTP específico. A ação permitir ou redefinir pode ser aplicada a uma solicitação ou resposta que corresponda aos critérios de mapa de classe. A adição da ação de registro causa uma mensagem syslog: APPFW-6- HTTP_HDR_FIELD_REGEX_MATCHED Uso do comando: Exemplos de casos de uso Configure uma política de inspeção de aplicação http para bloquear Spyware/Adware: Header field length inspection — Esse comando permite limitar o tamanho de uma linha de campo de cabeçalho. A ação permitir ou redefinir pode ser aplicada a uma solicitação ou resposta que corresponda aos critérios de mapa de classe. A adição da ação de registro causa uma mensagem syslog: APPFW-6- HTTP_HDR_FIELD_LENGTH Uso do comando: Exemplos de casos de uso Configure uma política http appfw para bloquear uma solicitação cujo tamanho do campo de cookie e agente de usuário exceda 256 e 128 respectivamente. Inspection of header field repetition — Esse comando verifica se uma solicitação ou resposta tem campos de cabeçalho repetidos. A ação permitir ou redefinir pode ser aplicada a uma solicitação ou resposta que corresponda aos critérios de mapa de classe. Quando ativada, a ação de log causa uma mensagem syslog: APPFW-6- HTTP_REPEATED_HDR_FIELDS Uso do comando: Exemplos de casos de uso Configure uma política http appfw para bloquear uma solicitação ou resposta que tenha várias linhas de cabeçalho de tamanho de conteúdo. Essa é uma das funcionalidades mais úteis usadas para impedir o contrabando de sessão .
APPFW-6-HTTP_METHOD Uso do comando: match request method <method> Exemplos de casos de uso Configure uma política de appfw http que agrupa os métodos HTTP em três categorias: seguro, não seguro e webdav. Eles são mostrados na próxima tabela. Configure as ações de modo que:
URI inspection — Esse comando fornece a capacidade de permitir/negar/monitorar solicitações cujo URI corresponde à inspeção regular configurada. Esse recurso possibilita que um usuário bloqueie URLs e consultas personalizadas. A ação permitir ou redefinir pode ser aplicada a uma solicitação ou resposta que corresponda aos critérios de mapa de classe. A adição da ação de registro causa uma mensagem syslog: APPFW-6- HTTP_URI_REGEX_MATCHED Uso do comando: match request uri regex <parameter-map-name> Exemplos de casos de uso Configure uma política http appfw para bloquear uma solicitação cujo URI corresponda a qualquer uma destas expressões regulares:
Configure uma política http appfw para disparar um alarme sempre que o comprimento de URI de uma solicitação exceder 3076 bytes. Argument inspection — Esse comando oferece uma capacidade de permitir, negar ou monitorar solicitações cujos argumentos (parâmetros) correspondem à inspeção regular configurada. A ação permitir ou redefinir pode ser aplicada a uma solicitação ou resposta que corresponda aos critérios de mapa de classe. A adição da ação de registro causa uma mensagem syslog: APPFW-6- HTTP_ARG_REGEX_MATCHED Uso do comando: match request arg regex <parameter-map-name> Configure uma política http appfw para bloquear uma solicitação cujos argumentos correspondam a qualquer uma destas expressões regulares:
Configure uma política http appfw para gerar um alarme sempre que o comprimento do argumento de uma solicitação exceder 512 bytes.
Configure um http appfw para bloquear uma resposta cujo corpo contenha o padrão .*[Aa][Tt][Tt][Aa][Cc][Kk] Inspeção de comprimento do corpo (conteúdo) — Esse comando verifica o tamanho da mensagem enviada por solicitação ou resposta. A ação permitir ou redefinir pode ser aplicada a uma solicitação ou resposta que corresponda aos critérios de mapa de classe. A adição da ação de registro causa uma mensagem syslog: APPFW-4- HTTP_CONTENT_LENGTH Uso do comando: Exemplos de casos de uso Configure uma política http appfw para bloquear uma sessão http que transporta mais de 10 mil bytes de mensagem em uma solicitação ou resposta. Status line inspection — O comando permite que o usuário especifique uma lista de expressões regulares para corresponder à linha de status de uma resposta. A ação permitir ou redefinir pode ser aplicada a uma solicitação ou resposta que corresponda aos critérios de mapa de classe. A adição da ação de registro causa uma mensagem syslog: APPFW-6-HTTP_STLINE_REGEX_MATCHED Uso do comando: match response status-line regex <class-map-name> Exemplos de casos de uso Configure um appfw http para registrar um alarme sempre que for feita uma tentativa de acessar uma página proibida. Uma página proibida geralmente contém um código de status 403 e a linha de status se parece com HTTP/1.0 403 página proibida\r\n.
Inspeção de mau uso de porta — Este comando é usado para evitar que a porta http (80) seja mal usada para outras aplicações, como IM, P2P, Tunelamento e assim por diante. A ação Permitir ou Redefinir pode ser aplicada a uma solicitação ou resposta que corresponda aos critérios de mapa de classe. A adição da ação de registro causa a mensagem de syslog apropriada: APPFW-4- HTTP_PORT_MISUSE_TYPE_IM APPFW-4-HTTP_PORT_MISUSE_TYPE_P2P APPFW-4-HTTP_PORT_MISUSE_TYPE_TUNNEL Uso do comando: Exemplos de casos de uso Configure uma política http appfw para bloquear uma sessão http usada incorretamente para o aplicativo IM.
Suporte ZFW para mensagens instantâneas e controle de aplicação peer-to-peerO software Cisco IOS versão 12.4(9)T apresentou suporte ZFW para aplicações P2P e de IM.O software Cisco IOS primeiro ofereceu suporte para controle de aplicação de IM no software Cisco IOS versão 12.4(4)T. A versão inicial do ZFW não foi compatível com a aplicação de IM na interface ZFW. Se o controle de aplicação de IM foi desejado, os usuários não conseguiram migrar para a interface de configuração do ZFW. O Cisco IOS Software Release 12.4(9)T introduz o suporte ZFW para Inspeção IM, que suporta o Yahoo! Messenger (YM), MSN Messenger (MSN) e 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 Cisco IOS Firewall para aplicativos de compartilhamento de arquivos P2P. A inspeção de IM e P2P oferece políticas de Camada 4 e Camada 7 para tráfego de aplicações. Isso significa que o ZFW pode fornecer inspeção stateful básica para permitir ou negar o tráfego, bem como controle granular da camada 7 em atividades específicas nos vários protocolos, de modo que certas atividades de aplicativos sejam permitidas, enquanto outras são negadas. Inspeção e controle de aplicação P2PO SDM 2.2 introduziu o controle de aplicação P2P na seção de configuração do firewall. O SDM aplicou uma política de reconhecimento de aplicativo baseado em rede (NBAR) e QoS para detectar e vigiar a atividade de aplicativo P2P a uma taxa de linha de zero e bloquear todo o tráfego P2P. Isso levantou o problema de que os usuários da CLI, que esperavam suporte P2P na CLI do Cisco IOS Firewall, não conseguiram configurar o bloqueio P2P na CLI, a menos que estivessem cientes da configuração necessária de NBAR/QoS. O Cisco IOS Software Release 12.4(9)T introduz o controle P2P nativo na CLI do ZFW, para aproveitar o NBAR para detectar a atividade do aplicativo P2P. Esta versão do software aceita vários protocolos de aplicação P2P:
As aplicações P2P são particularmente difíceis de detectar, como resultado de um comportamento de "salto de porta" e outros truques para evitar a detecção, bem como os problemas introduzidos por alterações e atualizações frequentes em aplicações P2P que modificam os comportamentos dos protocolos. O ZFW combina a inspeção nativa de firewall stateful com os recursos de reconhecimento de tráfego do NBAR para oferecer controle de aplicação P2P na interface de configuração CPL do ZFW. O NBAR oferece dois benefícios excelentes:
Configurar Inspeção P2PComo mencionado anteriormente, a inspeção e o controle P2P oferecem a inspeção stateful de Camada 4 e o controle de aplicação da Camada 7. A inspeção da camada 4 é configurada de forma semelhante a outros serviços de aplicativos, se a inspeção das portas de serviço de aplicativos nativos for 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 no protocolo de correspondência [service-name]. Quando a opção de assinatura é adicionada ao final da instrução do protocolo de correspondência, a heurística de NBAR é aplicada ao tráfego para procurar por indicadores no tráfego que indiquem atividade específica do aplicativo P2P. Isso inclui o salto da porta e outras alterações no comportamento da aplicação para evitar a detecção de tráfego. Esse nível de inspeção de tráfego tem o preço de aumento da utilização da CPU e do recurso de taxa de transferência de rede reduzida. Se a opção de assinatura não for aplicada, a análise heurística baseada em NBAR não será aplicada para detectar o comportamento de salto de porta e a utilização da CPU não sofrerá impacto na mesma extensão. A inspeção de serviço nativo tem a desvantagem de impossibilitar o controle sobre aplicações P2P, caso os "saltos" da aplicação não tenha uma porta de origem e destino, ou se a aplicação for atualizada para iniciar a ação em um número de porta não reconhecido:
Se desejar permitir (inspecionar) o tráfego P2P, você poderá precisar fornecer configuração adicional. Alguns aplicativos podem usar várias redes P2P ou implementar comportamentos específicos que você pode precisar acomodar na configuração do firewall para permitir que o aplicativo funcione:
A Inspeção da Camada 7 (Aplicação) aumenta a Inspeção da Camada 4 com a capacidade de reconhecer e aplicar ações específicas do serviço, como bloquear ou permitir seletivamente recursos de pesquisa de arquivos, transferência de arquivos e bate-papo de texto. Os recursos específicos de serviço variam de acordo com o serviço. A inspeção de aplicação P2P é semelhante à inspeção de aplicação HTTP: !configure the layer-7 traffic characteristics: class-map type inspect [p2p protocol] match-any p2p-l7-cmap match action ! !configure the action to be applied to the traffic !matching the specific characteristics: policy-map type inspect [p2p protocol] p2p-l7-pmap class type inspect p2p p2p-l7-cmap [ reset | allow ] log ! !define the layer-4 inspection policy class-map type inspect match-all p2p-l4-cmap match protocol [p2p protocol] ! !associate layer-4 class and layer-7 policy-map !in the layer-4 policy-map: 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 aplicações P2P oferece recursos específicos da aplicação para um subconjunto de aplicações compatíveis com a inspeção da Camada 4:
Cada um desses aplicativos oferece opções variáveis de critérios de correspondência específicos do 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)# 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 de protocolo P2P ou atualizações para protocolos P2P atuais podem ser carregadas com a funcionalidade de atualização dinâmica de 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 em comandos match protocol para inspeção de tipo de classe. Se o novo protocolo P2P tiver serviços (subprotocolos), os novos tipos de class-map inspecionados da Camada 7, bem como os critérios de correspondência da Camada 7, ficarão disponíveis. Controle e inspeção de aplicação de IMO software Cisco IOS versão 12.4(4)T introduziu a inspeção e o controle de aplicação de IM. O suporte a IM não foi introduzido com o ZFW na versão 12.4(6)T, portanto, os usuários não conseguiram aplicar o controle de IM e ZFW na mesma política de firewall, pois os recursos de firewall e ZFW herdados não podem coexistir em uma determinada interface. O software Cisco IOS versão 12.4(9)T é compatível com inspeção stateful e controle de aplicação para esses serviços de IM:
A inspeção de IM varia um pouco da maioria dos serviços, já que a inspeção de IM controla o acesso a um grupo específico de hosts para cada serviço fornecido. Os serviços de IM geralmente dependem de um grupo relativamente permanente de servidores de diretório, com os quais os clientes devem ser capazes de entrar em contato para acessar o serviço de IM. As aplicações de IM costumam ser muito difíceis de controlar, de um ponto de vista de protocolo ou serviço. A maneira mais eficaz de controlar essas aplicações é limitar o acesso aos servidores de IM fixos. Configurar Inspeção de IMA inspeção e o controle de mensagens instantâneas oferecem inspeção stateful de camada 4 e controle de aplicação da camada 7. A inspeção da Camada 4 é configurada da mesma forma que outros serviços de aplicações: 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 As aplicações de IM podem entrar em contato com seus servidores em várias portas para manter a funcionalidade. Para permitir um determinado serviço de IM com a ação de inspeção, você não pode precisar de uma lista de servidores para definir o acesso permitido aos servidores do serviço de IM. No entanto, quando você configura um mapa de classe que especifica um determinado serviço de IM, como o AOL Instant Messenger, e aplica a ação de soltar no mapa de política associado pode fazer com que o cliente de IM tente localizar uma porta diferente onde a conectividade é permitida para a Internet. Se você não quiser permitir a conectividade com um determinado serviço ou se quiser restringir a capacidade de serviço de IM para o bate-papo por texto, você deve definir uma lista de servidores para que o ZFW possa identificar o tráfego associado à aplicação de IM: !configure the server-list parameter-map: 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 servidor de IM do Yahoo é definida da seguinte forma: parameter-map type protocol-info ymsgr-pmap server name scs.msg.yahoo.com server name scsd.msg.yahoo.com server ip 10.0.77.88 server ip range 172.16.0.77 172.16.0.99 Você precisa 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 em ordem para habilitar a resolução do nome. Os nomes dos servidores de IM são razoavelmente dinâmicos. Você precisa verificar periodicamente se suas listas de servidores de IM configuradas estão completas e corretas. A Inspeção da Camada 7 (Aplicação) aumenta a Inspeção da Camada 4 com a capacidade de reconhecer e aplicar ações específicas do serviço, como bloquear ou permitir seletivamente recursos de bate-papo de texto e negar outros recursos do serviço. A inspeção do aplicações de IM atualmente oferece a capacidade de diferenciar a atividade de bate-papo por texto e todos os outros serviços de aplicações. Para restringir a atividade de IM para o bate-papo por texto, configure uma política de Camada 7: Aplique a política da Camada 7 ao Yahoo! Política do 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 Filtros de URLO ZFW oferece recursos de filtragem de URL para limitar o acesso ao conteúdo da Web ao especificado por uma lista branca ou negra definida no roteador ou encaminhando nomes de domínio para um servidor de filtragem de URL para verificar o acesso a domínios específicos. A filtragem de URL ZFW no software Cisco IOS versões 12.4(6)T a 12.4(15)T é aplicada como uma ação de política adicional, semelhante à inspeção da aplicação. Para a filtragem de URL baseada em servidor, você deve definir um mapa de parâmetros que descreva a configuração do servidor urlfilter: parameter-map type urlfilter websense-parmap server vendor [n2h2 | websense] 10.1.1.1 Se as listas estáticas de permissão ou bloqueio forem preferidas, você poderá definir uma lista de domínios ou subdomínios que sejam especificamente permitidos ou negados, enquanto a ação inversa é aplicada ao tráfego que não corresponde à lista: parameter-map type urlfilter websense-parmap exclusive-domain deny .disallowed.com exclusive-domain permit .cisco.com Se uma lista negra de URL for definida com opções de negação nas definições de domínio exclusivo, todos os outros domínios serão permitidos. Se forem definidas definições de "permissão", todos os domínios permitidos deverão ser explicitamente especificados, de forma semelhante à função das listas de controle de acesso IP. Configure um mapa de classe que corresponda ao tráfego HTTP: class-map type inspect match-any http-cmap match protocol http Defina um policy-map que associa o class-map às açõesinspect e urlfilter: policy-map type inspect http-filter-pmap class type inspect http-cmap inspect urlfilter websense-parmap Isso configura o requisito mínimo para se comunicar com um servidor de filtragem de URL. Várias opções estão disponíveis para definir o comportamento adicional de filtragem de URL. Algumas implantações de rede desejam aplicar a filtragem de URL para alguns hosts ou sub-redes e ignorar a filtragem de URL para outros hosts. Por exemplo, na Figura 9, todos os hosts na zona privada devem ter o tráfego HTTP verificado por um servidor de filtro de URL, exceto pelo host específico 192.168.1.101. Figura 10: Exemplo de topologia de filtragem de URL
Isso pode ser realizado se você definir dois mapas de mapa de classe diferentes:
Ambos os mapas de classe são configurados em um mapa de política, mas somente um recebe 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 Controle o acesso ao roteadorA maioria dos engenheiros de segurança de rede não se sente confortável se expõem as interfaces de gerenciamento do roteador (por exemplo, SSH, Telnet, HTTP, HTTPS, SNMP e assim por diante) à Internet pública e, em determinadas circunstâncias, o controle também é necessário para o acesso da LAN ao roteador. O software Cisco IOS oferece uma série de opções para limitar o acesso às várias interfaces, que inclui a família de recursos de proteção da base de rede (NFP), vários mecanismos de controle de acesso para interfaces de gerenciamento e a zona automática do ZFW. Você deve rever outros recursos, como controle de acesso VTY, proteção do plano de gerenciamento e controle de acesso SNMP para determinar qual combinação de recursos de controle do roteador funciona melhor para seu aplicativo específico. Geralmente, a família de recursos NFP é mais adequada para o controle do 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 os recursos NFP. Se decidir aplicar ZFW para controlar o tráfego de e para os endereços IP no próprio roteador, você deverá entender que a política e os recursos padrão do firewall diferem dos disponíveis para o tráfego de trânsito. O tráfego de trânsito é definido como o tráfego de rede cujos endereços IP origem e destino não correspondem a nenhum endereço IP aplicado a qualquer uma das interfaces do roteador, e o tráfego não faz com que o roteador envie, por exemplo, mensagens de controle de rede como expiração de TTL ICMP ou mensagens de rede/host inalcançável. O ZFW aplica uma política deny-all padrão ao tráfego que se move entre as zonas, exceto, como mencionado nas regras gerais, o tráfego em qualquer zona que flui diretamente 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 da zona for aplicada ao roteador. Se a mesma política de negar tudo afetasse a conectividade diretamente ao roteador, uma configuração completa da política de gerenciamento teria que ser aplicada antes que as zonas fossem configuradas no roteador. Isso provavelmente interromperia a conectividade de gerenciamento, se a política fosse implementada de forma adequada ou aplicada na ordem errada. Quando uma interface é configurada para ser um membro da zona, os hosts conectados à interface são incluídos na zona. No entanto, o tráfego que flui de e para os endereços IP das interfaces do roteador não é controlado pelas políticas de zona (com exceção das circunstâncias descritas na observação na Figura 10). Em vez disso, todas as interfaces IP no roteador são automaticamente parte da zona automática quando o ZFW é configurado. Para controlar o tráfego IP que se move para as interfaces do roteador a partir de várias zonas em um roteador, as políticas devem ser aplicadas para bloquear ou permitir/inspecionar o tráfego entre a zona e a autozona do roteador e vice-versa (consulte a Figura 11). Figura 11: Aplicar política entre zonas de rede e autozona do roteador
Embora o roteador ofereça uma política de permissão padrão entre todas as zonas e a zona automática, se uma política for configurada de qualquer zona para a zona automática e nenhuma política for configurada de zonas autoconectadas à interface configurável pelo usuário do roteador, todo o tráfego originado pelo roteador encontra a política de zona conectada para zona automática em seu retorno ao roteador e é bloqueado. Assim, o tráfego originado no roteador deve ser inspecionado para permitir seu retorno à autozona. Note: O software Cisco IOS sempre usa o endereço IP associado a um host de destino "mais próximo" de interface para tráfego como syslog, TFTP, Telnet e outros serviços de plano de controle e sujeita esse tráfego à política de firewall autozona. No entanto, se um serviço definir uma interface específica como a interface de origem com comandos que incluem, mas não se limitam a, logging source-interface [type number] , ip tftp source-interface [type number] e ip telnet source-interface [type number] , o tráfego estará sujeito à autozona. Nota:Alguns serviços (particularmente os serviços de voz sobre IP dos roteadores) usam interfaces efêmeras ou não configuráveis que não podem ser atribuídas a zonas de segurança. Esses serviços não poderão funcionar corretamente se o tráfego não puder ser associado a uma zona de segurança configurada. Limitações de política de autozonaA política de zona tem funcionalidade limitada, em comparação às políticas disponíveis para transit-traffic zone-pairs:
Configuração de políticaNa maioria das vezes, essas são políticas de acesso desejáveis para os serviços de gerenciamento de roteador:
Um roteador pode aplicar esse tipo de política com a adição de dois zone-pairs para cada zona que deve ser controlada. Cada par de zonas para tráfego de entrada ou saída da autozona do roteador deve ser correspondido pela respectiva política na direção oposta, a menos que o tráfego não seja originado na direção oposta. Um policy-map cada para zone-pairs de entrada e saída pode ser aplicado, descrevendo todo o tráfego, ou os policy-maps específicos por zone-pair podem ser aplicados. A configuração de pares de zonas específicos por mapa de políticas fornece granularidade para visualizar a atividade que corresponde a cada mapa de políticas. Um exemplo de rede 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 de toda a política 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 de autozona não oferece a capacidade de inspecionar transferências TFTP. Assim, o firewall deve transmitir todo o tráfego de entrada e saída do servidor TFTP, se o TFTP precisar passar pelo firewall. Se o roteador terminar conexões VPN IPSec, você também deverá definir uma política para passar IPSec ESP, IPSec AH, ISAKMP e NAT-T IPSec (UDP 4500). Isso depende do que é necessário com base nos serviços que você usa. Essa próxima política pode ser aplicada além da política acima. Observe a alteração nos mapas de política onde um mapa de classe para tráfego VPN foi inserido com uma ação de passagem. Geralmente, o tráfego criptografado é confiável, a não ser que a política de segurança declare que você deve permitir o tráfego criptografado de entrada e saída de endpoints especificados. class-map type inspect match-all crypto-cmap match access-group 123 ! policy-map type inspect to-self-pmap class type inspect crypto-cmap pass class type inspect to-self-cmap inspect class type inspect tftp-in-cmap pass ! policy-map type inspect from-self-pmap class type inspect crypto-cmap pass class type inspect from-self-cmap inspect class type inspect tftp-out-cmap pass ! access-list 123 permit esp any any access-list 123 permit udp any any eq 4500 access-list 123 permit ah any any access-list 123 permit udp any any eq 500 Serviços de firewall de acordo com a zona e aplicação de área remotaConsulte Release Note para Cisco Wide Area Application Services (Versão de Software 4.0.13) - Novos Recursos para a Versão de Software 4.0.13 para obter uma nota de aplicativo que fornece exemplos de configuração e orientação de uso Monitore o firewall de política baseado em zona com os comandos show e debugO ZFW apresenta novos comandos para exibir a configuração da política e monitorar a atividade do firewall. Exibe 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 é incluído, o comando exibe as informações de todas as zonas configuradas. Exibe a zona de origem, a zona de destino e a política conectada ao zone-pair: show zone-pair security [source <source-zone-name>] [destination <destination-zone-name>] Quando nenhuma origem ou destino é especificado, todos os zone-pairs com origem, destino e a política associada são exibidos. Quando apenas a zona de origem/destino é mencionada, todos os zone-pairs que contêm essa zona como origem/destino são exibidos. Router#show zone-pair security zone-pair name zp Source-Zone z1 Destination-Zone z2 service-policy p1 Exibe um mapa de políticas especificado: show policy-map type inspect [<policy-map-name> [class <class-map-name]] Quando o nome de um mapa de políticas não é especificado, ele exibe todos os mapas de políticas do tipo inspect (juntamente com os mapas de políticas da camada 7 que contêm um subtipo). Exibe as estatísticas de mapa de política de tipo de inspeção de tempo de execução atualmente em um par de zonas especificado. show policy-map type inspect zone-pair [zone-pair-name] [sessions] Quando no zone-pair name é mencionado, policy-maps em todos zone-pairs são exibidos. A opção sessions exibe as sessões de inspeção criadas pela aplicação policy-map no zone-pair especificado. A palavra-chave urlfilter exibe as estatísticas relacionadas a urlfilter que pertencem ao policy-map especificados (ou policy-maps em todos os destinos quando o zone-pair name é especificado): show policy-map type inspect zone-pair [zone-pair-name] [urlfilter [cache]] Quando a palavra-chave cache é especificada com urlfilter, ela exibe o cache urlfilter (dos endereços IP). Resumo do comando show policy-map para policy-maps de inspeção: Ajustar a proteção de negação de serviço do firewall de política baseada em zonaO ZFW oferece proteção de DoS para alertar os engenheiros de rede que façam alterações drásticas na atividade da rede e reduzam a atividade indesejada para minimizar o impacto das alterações na atividade da rede. O ZFW mantém um contador separado para cada class-map de policy-map. Assim, se um mapa de classe é usado para dois mapas de política de pares de zonas diferentes, dois conjuntos diferentes de contadores de proteção DoS são aplicados. O ZFW fornece mitigação de ataques de DoS como um padrão nas versões de software Cisco IOS antes de 12.4(11)T. O comportamento de proteção de DoS padrão mudou com o software Cisco IOS versão 12.4(11)T. Consulte Definição de estratégias para proteção contra ataques de negação de serviço de SYN de TCPpara obter mais informações sobre ataques de DoS de SYN de TCP. ApêndicesApêndice A: Configuração básicaip 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 de firewall de política de acordo com a zona para duas zonasEste exemplo fornece uma configuração simples como base para testar recursos para aprimoramentos no Cisco IOS Software ZFW. Essa configuração é uma configuração de modelo para duas zonas, conforme configurado em um roteador 1811. A zona privada é aplicada às portas fixas do switch do roteador, portanto todos os hosts nas portas do switch são conectados à VLAN 1. A zona pública é aplicada à FastEthernet 0 (consulte a Figura 12). Figura 12: Zona pública aplicada em FastEthernet 0
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 Informações Relacionadas
Quais são as funções possíveis de portas a B CED nessa rede habilitada por Rstp?Quais são as funções de porta possíveis para as portas A, B, C e D nesta rede habilitada para RSTP? Explicação: Como S1 é a ponte raiz, B é uma porta designada e as portas raiz C e D. O RSTP oferece suporte a um novo tipo de porta, porta alternativa no estado de descarte, que pode ser a porta A neste cenário.
Qual é o resultado de uma tempestade de broadcast de camada 2?Qual é o resultado de uma tempestade de broadcast da camada 2? Os roteadores assumirão o encaminhamento de quadros à medida que os switches ficarem congestionados. O novo tráfego é descartado pelo switch porque não pode ser processado.
Qual das afirmativas abaixo relacionada a decisões de encaminhamento dos quadros de switch da Ethernet está correta?Qual das afirmativas abaixo, relacionada a decisões de encaminhamento dos quadros de switch da Ethernet, está correta? Resposta: Decisões sobre o encaminhamento de quadros são baseadas em endereços MAC e mapeamentos de porta na tabela CAM.
Quais os três componentes que são combinados para formar um ID de Bridge?Explicação: Os três componentes combinados para formar um ID de ponte são prioridade de ponte, ID de sistema estendido e endereço MAC.
|
Consulte a figura Quais são as funções possíveis de portas a B ced nessa rede habilitada por RSTP
direito autoral © 2024 berikutyang Inc.
