IP : Serviços de endereçamento IP

Protegendo Sua Base: Listas de Controle de Acesso de Proteção de Infraestrutura

1 Julho 2009 - Tradução Manual
Outras Versões: Versão em PDFpdf | Tradução por Computador (29 Julho 2013) | Inglês (21 Outubro 2008) | Feedback

Índice

Introdução
Proteção da Infraestrutura
      Histórico
      Técnicas
Exemplos de ACL
Desenvolvimento de uma ACL de Proteção
ACLs e Pacotes Fragmentados
Avaliação de Risco
Apêndices
      Protocolos IP com Suporte no Cisco IOS Software
      Diretrizes de Implementação
      Exemplos de Implementação
Discussões relacionadas da comunidade de suporte da Cisco

Introdução

Este documento apresenta diretrizes e técnicas de implementação recomendadas para ACLs (listas de controle de acesso) de proteção de infraestrutura. As ACLs de infraestrutura são utilizadas para minimizar o risco e a eficiência de um ataque direto à infraestrutura por meio de permissões explícitas somente do tráfego autorizado ao equipamento de infraestrutura e, ao mesmo tempo, da permissão de todos os outros tráfegos em trânsito.

Proteção da Infraestrutura

Histórico

Para tentar proteger os roteadores contra diversos riscos — tanto acidentais como maliciosos — as ACLs de proteção de infraestrutura devem ser implementadas nos pontos de entrada da rede. Essas ACLs IPv4 e IPv6 ACLs negam o acesso de origens externas a todos os endereços da infraestrutura, como interfaces de roteadores. Ao mesmo tempo, as ACLs permitem que o tráfego em trânsito de rotina flua continuamente e fornecem filtragem antifalsificação, RFC 1918 leavingcisco.com e RFC 3330 leavingcisco.combásicas.

Os dados recebidos por um roteador podem ser divididos em duas categorias abrangentes:

  • o tráfego que passa pelo roteador através do caminho de encaminhamento

  • o tráfego destinado ao roteador através do caminho de recebimento para processamento pelo Route Processor

Em operações normais, a maior parte do tráfego flui simplesmente por um roteador até o seu destino final.

Entretanto, o RP (Route Processor) deve processar certos tipos de dados diretamente, em especial protocolos de roteamento, acesso a roteadores remotos (como SSH [Secure Shell]) e tráfego de gerenciamento de rede, como SNMP (Simple Network Management Protocol). Além disso, protocolos como o ICMP (Internet Control Message Protocol) e opções IP podem exigir o processamento direto pelo RP. Em geral, o acesso direto ao roteador da infraestrutura é necessário somente a partir de origens internas. Algumas exceções relevantes incluem a formação de peers BGP (Border Gateway Protocol) externos, protocolos que terminam no roteador real (como GRE [generic routing encapsulation] ou túneis IPv6 sobre IPv4) e pacotes ICMP limitados potencialmente para teste de conectividade, como mensagens de solicitação de eco ou ICMP que não chegam ao seu destino e mensagens expiradas TTL (time to live) para traceroute.

Nota: Lembre-se de que o ICMP é geralmente utilizado para ataques de DoS (negação de serviço) e só deverá ser permitido a partir de origens externas se necessário.

Todos os RPs apresentam um padrão de desempenho com base no qual operam. O tráfego excessivo destinado ao RP pode sobrecarregar o roteador. Isso acarreta o uso elevado da CPU, resultando em descartes de pacotes e do protocolo de roteamento que ocasionam uma negação de serviço. Com a filtragem do acesso aos roteadores da infraestrutura a partir de origens externas, muitos dos riscos externos associados a um ataque direto ao roteador são reduzidos. Os ataques originados externamente não podem mais acessar o equipamento de infraestrutura. O ataque é descartado nas interfaces de entrada para o AS (sistema autônomo).

As técnicas de filtragem descritas neste documento têm como objetivo filtrar os dados destinados ao equipamento da infraestrutura de rede. Não confunda filtragem da infraestrutura com filtragem genérica. O propósito específico da ACL de proteção de infraestrutura é restringir, em um nível granular, quais protocolos e origens podem acessar o equipamento crítico de infraestrutura.

O equipamento de infraestrutura de rede abrange as seguintes áreas:

  • Todos os endereços de gerenciamento de switches e roteadores, incluindo interfaces de loopback

  • Todos os endereços de links internos: links de roteador a roteador (acesso ponto a ponto e múltiplo)

  • Serviços ou servidores internos que não devem ser acessados a partir de origens externas

Neste documento, todo o tráfego não destinado à infraestrutura é geralmente designado como em trânsito.

Técnicas

A proteção da infraestrutura pode ser alcançada por meio de várias técnicas:

  • ACLs de Recebimento (rACLs)

    As plataformas Cisco 12000 e 7500 oferecem suporte a rACLs que filtram todo o tráfego destinado ao RP e que não afetam o tráfego em trânsito. O tráfego autorizado deve ser permitido explicitamente e a rACL deve ser implementada em todos os roteadores. Consulte GSR: Listas de Controle de Acesso de Recebimento para obter mais informações.

  • ACLs de roteador salto a salto

    Também é possível proteger os roteadores com a definição de ACLs que permitem somente o tráfego autorizado para as interfaces do roteador e negam todos os demais, com exceção do tráfego em trânsito, que deve ser permitido explicitamente. Essa ACL é semelhante logicamente a uma rACL, mas não afeta o tráfego em trânsito e, portanto, pode ter um impacto negativo no desempenho da taxa de encaminhamento de um roteador.

  • Filtragem da borda via ACLs de infraestrutura

    As ACLs podem ser aplicadas à borda da rede. No caso de um provedor de serviços (SP), essa é a borda do AS. Essa ACL filtra explicitamente o tráfego destinado ao espaço de endereços da infraestrutura. A implementação de ACLs de infraestrutura de borda exige que você defina claramente o espaço de sua infraestrutura e os protocolos necessários/autorizados que acessam esse espaço. A ACL é aplicada na entrada da rede em todas as conexões externas, como conexões de peers, conexões de clientes etc.

    Este documento se concentra no desenvolvimento e na implementação de ACLs de proteção da infraestrutura de borda.

Exemplos de ACL

As listas de acesso IPv4 e IPv6 a seguir fornecem exemplos simples, mas realistas, de entradas típicas necessárias em uma ACL de proteção. Essas ACLs básicas precisam ser personalizadas com detalhes de configuração específicos do site local. Em ambientes IPv4 e IPv6 duais, as duas listas de acesso são implementadas.

Exemplo de IPv4


!--- Entradas anti-falsificação são mostradas aqui.


!--- Negue as origens de endereços de uso especial.
!--- Consulte a RFC 3330 para obter endereços de uso especial adicionais.

access-list 110 deny ip host 0.0.0.0 any
access-list 110 deny ip 127.0.0.0 0.255.255.255 any
access-list 110 deny ip 192.0.2.0 0.0.0.255 any
access-list 110 deny ip 224.0.0.0 31.255.255.255 any

!--- Filtre o espaço da RFC 1918.

access-list 110 deny ip 10.0.0.0 0.255.255.255 any
access-list 110 deny ip 172.16.0.0 0.15.255.255 any
access-list 110 deny ip 192.168.0.0 0.0.255.255 any

!--- Negue seu espaço como origem de entrada em seu AS.
!--- Implemente somente na borda do AS.


access-list 110 deny ip YOUR_CIDR_BLOCK any

!--- Permita o BGP.

access-list 110 permit tcp host bgp_peer host router_ip eq bgp
access-list 110 permit tcp host bgp_peer eq bgp host router_ip

!--- Negue acesso aos endereços da infraestrutura interna.

access-list 110 deny ip any INTERNAL_INFRASTRUCTURE_ADDRESSES

!--- Permita o tráfego de trânsito.

access-list 110 permit ip any any

Exemplo de IPv6

A lista de acesso IPv6 deve ser aplicada como uma lista de acesso nomeada estendida.


!--- Configure a lista de acesso.

ipv6 access-list iacl

!--- Negue seu espaço como origem de entrada em seu AS.
!--- Implemente somente na borda do AS.

 deny ipv6 YOUR_CIDR_BLOCK_IPV6 any

!--- Permita o BGP multiprotocolo.

 permit tcp host bgp_peer_ipv6 host router_ipv6 eq bgp
 permit tcp host bgp_peer_ipv6 eq bgp host router_ipv6

!--- Negue acesso aos endereços da infraestrutura interna.

deny ipv6 any INTERNAL_INFRASTRUCTURE_ADDRESSES_IPV6

!--- Permita o tráfego de trânsito.

 permit ipv6 any any

Nota:  A palavra-chave log pode ser utilizada para fornecer detalhes adicionais sobre a origem e os destinos de determinado protocolo. Embora essa palavra-chave forneça informações importantes sobre os detalhes das ocorrências da ACL, ocorrências em excesso para uma entrada da ACL que use a palavra-chave log aumentam a utilização da CPU. O impacto no desempenho associado ao registro em log varia de acordo com a plataforma. Além disso, o uso da palavra-chave log desativa o switching CEF (Cisco Express Forwarding) dos pacotes que correspondem à instrução access-list. Esses pacotes são comutados rapidamente.

Desenvolvimento de uma ACL de Proteção

Em geral, uma ACL de infraestrutura é composta de quatro seções:

  • Entradas antifalsificação e endereço de uso especial que impedem que origens ilegítimas e pacotes com endereços de origem pertencentes ao AS entrem nele a partir de uma origem externa.

    Nota: A RFC 3330 define os endereços de uso especial IPv4 que podem exigir filtragem. A RFC 1918 define o espaço reservado de endereço IPv4 que não é um endereço de origem válido na Internet. A RFC 3513 define a arquitetura de endereçamento IPv6. A RFC 2827 leavingcisco.com fornece diretrizes de filtragem de entrada.

  • Tráfego externo permitido explicitamente e destinado a endereços de infraestrutura

  • Instruções deny para todos os outros tráfegos externos destinados aos endereços de infraestrutura

  • Instruções permit para todos os outros tráfegos de backbone normais encaminhados a destinos que não sejam de infraestrutura

A última linha da ACL de infraestrutura permite explicitamente o tráfego em trânsito: permit ip any any para IPv4 e permit ipv6 any any para IPv6. Essa entrada garante que todos os protocolos IP sejam permitidos através da infraestrutura base e que os clientes possam continuar a executar os aplicativos sem problemas.

O primeiro passo ao desenvolver uma ACL de proteção de infraestrutura é entender os protocolos necessários. Embora cada site possua requisitos específicos, determinados protocolos são normalmente implementados e devem ser entendidos. Por exemplo, é necessário permitir explicitamente um BGP externo para peers externos. Quaisquer outros protocolos que exijam o acesso direto ao roteador da infraestrutura também precisam ser permitidos explicitamente. Por exemplo, se você encerrar um túnel GRE em um roteador da infraestrutura base, o protocolo 47 (GRE) também precisará ser permitido explicitamente. Da mesma forma, se você encerrar um túnel IPv6 sobre IPv4 em um roteador da infraestrutura base, o protocolo 41 (IPv6 sobre IPv4) também precisará ser permitido explicitamente.

Uma ACL de classificação poderá ser utilizada para ajudar a identificar os protocolos necessários. A ACL de classificação é composta de instruções permit para os diversos protocolos que podem ser destinados a um roteador da infraestrutura. Consulte o apêndice sobre protocolos IP com suporte no Cisco IOS® Software para obter uma lista completa. O uso do comando show access-list command para exibir uma contagem de ocorrências de entradas de controle de acesso (ACE) identifica os protocolos necessários. É importante investigar e compreender resultados suspeitos ou surpreendentes antes de criar instruções permit para protocolos inesperados.

Por exemplo, esta ACL IPv4 ajuda a determinar se o GRE, o IPsec (ESP) e o tunelamento IPv6 (Protocolo IP 41) precisam ser permitidos.

access-list 101 permit GRE any infrastructure_ips
access-list 101 permit ESP any infrastructure_ips
access-list 101 permit 41 any infrastructure_ips
access-list 101 permit ip any infrastructure_ips log


!--- A palavra-chave log fornece mais detalhes
!--- sobre os outros protocolos que não são permitidos de forma explícita.

access-list 101 permit ip any any

interface <int>
 ip access-group 101 in

Esta ACL IPv6 pode ser utilizada para determinar se o GRE e o IPsec (ESP) precisam ser permitidos.

ipv6 access-list determine_protocols
 permit GRE any infrastructure_ips_ipv6
 permit ESP any infrastructure_ips_ipv6
 permit ipv6 any infrastructure_ips_ipv6 log

!--- A palavra-chave log fornece mais detalhes
!--- sobre os outros protocolos que não são permitidos de forma explícita.

 permit ipv6 any any

interface <int>
 ipv6 traffic-filter determine_protocols in

Além dos protocolos necessários, é necessário identificar o espaço de endereços de infraestrutura, pois esse é o espaço protegido pela ACL. Esse espaço contém todos os endereços utilizados para a rede interna e raramente acessados por origens externas, como interfaces de roteador, endereçamento de links ponto a ponto e serviços de infraestrutura críticos. Como esses endereços são utilizados para a parte de destino da ACL de infraestrutura, sua sumarização é muito importante. Sempre que possível, esses endereços devem ser agrupados em blocos CIDR (classless interdomain routing).

Com o uso dos protocolos e dos endereços identificados, a ACL de infraestrutura pode ser construída para permitir os protocolos e proteger os endereços. Além da proteção direta, a ACL também proporciona uma primeira linha de defesa contra certos tipos de tráfego inválido na Internet.

  • O espaço do padrão RFC 1918 deve ser negado.

  • Pacotes cujo endereço de origem esteja em um espaço de endereços de uso especial, conforme definido na RFC 3330, devem ser negados.

  • Filtros antifalsificação devem ser aplicados. (Seu espaço de endereços nunca deve ser a origem dos pacotes provenientes de fora do AS).

Essa ACL recém-construída deve ser aplicada internamente a todas as interfaces de entrada. Consulte as seções sobre diretrizes de implementação e exemplos de implementação para obter mais detalhes.

iacl-01.gif

ACLs e Pacotes Fragmentados

As ACLs possuem a palavra-chave fragments que permite o tratamento especializado de pacotes fragmentados. Em geral, os fragmentos não iniciais que correspondem às instruções da Camada 3 (independentemente das informações da Camada 4) em uma ACL são afetados pela instrução permit ou deny da entrada correspondente. Observe que o uso da palavra-chave fragments pode forçar as ACLs a recusar ou permitir fragmentos não iniciais com mais detalhes. Esse comportamento é o mesmo para listas de acesso IPv4 e IPv6.

A filtragem de fragmentos acrescenta uma camada adicional de proteção contra ataques de DoS (negação de serviço) que utilizam somente fragmentos não iniciais (como FO > 0). O uso de uma instrução deny para fragmentos não iniciais no começo da ACL impede que todos esses fragmentos acessem o roteador. Em raras circunstâncias, uma sessão válida poderá exigir fragmentação e, portanto, ser filtrada se existir uma instrução deny fragment na ACL.

Por exemplo, considere esta IPv4ACL parcial:

access-list 110 deny tcp any infrastructure_IP fragments
access-list 110 deny udp any infrastructure_IP fragments
access-list 110 deny icmp any infrastructure_IP fragments
<rest of ACL>

A inclusão dessas entradas no início de uma ACL impede o acesso de quaisquer fragmentos não iniciais aos roteadores base, enquanto pacotes não fragmentados ou fragmentos iniciais passam para as próximas linhas da ACL sem serem afetados pelas instruções deny fragment. O comando ACL anterior também facilita a classificação do ataque uma vez que cada protocolo — UDP (Universal Datagram Protocol), TCP e ICMP — incrementa contadores diferentes na ACL.

Como muitos ataques confiam na inundação de roteadores base com pacotes fragmentados, a filtragem de fragmentos recebidos pela infraestrutura base fornece uma medida adicional de proteção e ajuda a assegurar que um ataque não possa injetar fragmentos simplesmente com a correspondência de regras da camada 3 na ACL de infraestrutura.

Consulte Listas de Controle de Acesso e Fragmentos IP para obter uma descrição detalhada das opções.

Avaliação de Risco

Considere estas duas áreas importantes de risco ao implementar ACLs de proteção de infraestrutura:

  • Verifique se as instruções permit/deny apropriadas estão definidas. Para que a ACL seja eficaz, todos os protocolos necessários devem ser permitidos e o espaço de endereços correto deve ser protegido pelas instruções deny.

  • O desempenho da ACL varia de acordo com a plataforma. Examine as características de desempenho de seu hardware antes de implementar ACLs.

Como sempre, é recomendável testar esse design no laboratório antes da implementação.

Apêndices

Protocolos IP com Suporte no Cisco IOS Software

O Cisco IOS Software oferece suporte aos seguintes protocolos IP:

  • 1 – ICMP

  • 2 – IGMP

  • 3 – GGP

  • 4 – encapsulamento IP em IP

  • 6 – TCP

  • 8 – EGP

  • 9 – IGRP

  • 17 – UDP

  • 20 – HMP

  • 27 – RDP

  • 41 – tunelamento IPv6 em IPv4

  • 46 – RSVP

  • 47 – GRE

  • 50 – ESP

  • 51 – AH

  • 53 – SWIPE

  • 54 – NARP

  • 55 – mobilidade IP

  • 63 – qualquer rede local

  • 77 – Sun ND

  • 80 – ISO IP

  • 88 – EIGRP

  • 89 – OSPF

  • 90 – Sprite RPC

  • 91 – LARP

  • 94 – IP sobre IP compatível com KA9Q/NOS

  • 103 – PIM

  • 108 – compactação IP

  • 112 – VRRP

  • 113 – PGM

  • 115 – L2TP

  • 120 – UTI

  • 132 – SCTP

Diretrizes de Implementação

A Cisco recomenda o uso de práticas conservadoras de implementação. Para implementar com êxito ACLs de infraestrutura, os protocolos necessários devem ser bem entendidos e o espaço de endereços deve ser identificado e definido de forma clara. As diretrizes a seguir descrevem um método bem conservador de implementação de ACLs de proteção com o uso de uma abordagem iterativa.

  1. Identifique os protocolos utilizados na rede com uma ACL de classificação.

    Implemente uma ACL que permita todos os protocolos conhecidos que acessam dispositivos de infraestrutura. Essa ACL de descoberta possui o endereço de origem any e um destino que abrange o espaço IP da infraestrutura. O recurso de log pode ser utilizado para desenvolver uma lista de endereços de origem que correspondem às instruções permit do protocolo. É necessária uma última linha que permita ip any any (IPv4) ou ipv6 any any (IPv6) para que o fluxo de tráfego seja autorizado.

    O objetivo é determinar quais protocolos a rede específica utiliza. O recurso de log é utilizado para análise a fim de determinar o que mais pode se comunicar com o roteador.

    Nota: Embora a palavra-chave log forneça informações importantes sobre os detalhes de ocorrências da ACL, ocorrências em excesso para uma entrada de ACL que use essa palavra-chave podem causar um grande número de entradas no log e possivelmente um maior uso da CPU do roteador. Além disso, o uso da palavra-chave log desativa o switching CEF (Cisco Express Forwarding) dos pacotes que correspondem à instrução access-list. Esses pacotes são comutados rapidamente. Utilize a palavra-chave log durante curtos períodos de tempo e somente quando necessário para ajudar a classificar o tráfego.

  2. Examine os pacotes identificados e comece a filtrar o acesso ao RP (route processor).

    Após os pacotes filtrados pela ACL no passo 1 serem identificados e examinados, implemente uma ACL com uma instrução permit any source para os endereços da infraestrutura nos protocolos permitidos. Como no passo 1, a palavra-chave log pode fornecer mais informações sobre os pacotes que correspondem às entradas permit. O uso de deny any no final pode ajudar a identificar os pacotes inesperados destinados aos roteadores. A última linha dessa ACL deverá conter uma instrução permit ip any any (IPv4) ou permit ipv6 any any (IPv6) para permitir que o tráfego em trânsito flua. Essa ACL não oferece proteção básica nem permite que os engenheiros da rede garantam que todo o tráfego necessário seja autorizado.

  3. Restrinja os endereços de origem.

    Depois de entender claramente os protocolos que devem ser permitidos, será possível realizar uma filtragem adicional a fim de permitir apenas as origens autorizadas para esses protocolos. Por exemplo, você pode permitir explicitamente vizinhos BGP externos ou endereços de peers GRE específicos.

    Esse passo reduz o risco sem interromper quaisquer serviços e permite aplicar um controle granular a origens que acessam o equipamento de infraestrutura.

  4. Limite os endereços de destino na ACL. (opcional)

    Alguns provedores de Internet (ISP) podem optar por permitir que apenas determinados protocolos utilizem endereços de destino específicos no roteador. O objetivo desta fase final é limitar o intervalo de endereços de destino que podem aceitar tráfego para um protocolo.

Exemplos de Implementação

Exemplo de IPv4

Este exemplo de IPv4 mostra uma ACL de Infraestrutura que protege um roteador com base no seguinte endereçamento:

  • O bloco de endereços do ISP é 169.223.0.0/16.

  • O bloco de infraestrutura do ISP é 169.223.252.0/22.

  • O loopback do roteador é 169.223.253.1/32.

  • O roteador é um roteador de peer e forma um peer com 169.254.254.1 (para o endereço 169.223.252.1).

A ACL de proteção de infraestrutura exibida é desenvolvida com base nas informações anteriores. A ACL permite a formação do peer BGP externo para o peer externo, oferece filtros antifalsificação e protege a infraestrutura contra todo acesso externo.

!
no access-list 110
!
! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


!--- Fase 1 - Negação pela anti-falsificação
!--- Estas ACEs negam fragmentos, espaço da RFC 1918,
!--- endereços de origem inválidos e falsificações de
!--- espaço interno (espaço como uma origem externa).

!


!--- Negue fragmentos direcionados ao bloco de infraestrutura.

access-list 110 deny tcp any 169.223.252.0 0.0.3.255 fragments
access-list 110 deny udp any 169.223.252.0 0.0.3.255 fragments
access-list 110 deny icmp any 169.223.252.0 0.0.3.255 fragments


!--- Negue as origens de endereços de uso especial.
!--- Consulte a RFC 3330 para obter endereços de uso especial adicionais.

access-list 110 deny ip host 0.0.0.0 any
access-list 110 deny ip 127.0.0.0 0.255.255.255 any
access-list 110 deny ip 192.0.2.0 0.0.0.255 any
access-list 110 deny ip 224.0.0.0 31.255.255.255 any


!--- Filtre o espaço da RFC 1918.

access-list 110 deny ip 10.0.0.0 0.255.255.255 any
access-list 110 deny ip 172.16.0.0 0.15.255.255 any
access-list 110 deny ip 192.168.0.0 0.0.255.255 any


!--- Negue nosso espaço interno como uma origem externa.
!--- Implementado somente na borda do AS.

access-list 110 deny ip 169.223.0.0 0.0.255.255 any
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


!--- Fase 2 - Permissão explícita
!--- Permita somente aplicativos/protocolos cujo endereço de
!--- destino é parte do bloco de IPs de infraestrutura.
!--- A origem do tráfego deve ser conhecida e autorizada.

!


!--- Nota: Este modelo deve ser ajustado para o ambiente de
!--- endereço de origem específico. As variáveis no
!--- modelo devem ser alteradas.


!--- Permita o BGP externo.

access-list 110 permit tcp host 169.254.254.1  host 169.223.252.1  eq bgp
access-list 110 permit tcp host 169.254.254.1  eq bgp host 169.223.252.1
!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


!--- Fase 3 - Negação explícita para proteger a infraestrutura


access-list 110 deny ip any 169.223.252.0 0.0.3.255
!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


!--- Fase 4 - Permissão explícita para o tráfego de trânsito


access-list 110 permit ip any any

Exemplo de IPv6

Este exemplo de IPv6 mostra uma ACL de Infraestrutura que protege um roteador com base no seguinte endereçamento:

  • O bloco de endereços do ISP é 3FFE:B00:C18:::/48.

  • O bloco de infraestrutura do ISP é 3FFE:B00:C18:3::/64.

  • O roteador é um roteador de peer e forma um peer com 3FFE:B00:C19:2:1::F (para o endereço 3FFE:B00:C18:2:1::1).

A ACL de proteção de infraestrutura exibida é desenvolvida com base nas informações anteriores. A ACL permite a formação do peer BGP multiprotocolo externo para o peer externo, oferece filtros antifalsificação e protege a infraestrutura contra todo acesso externo.

no ipv6 access-list iacl
ipv6 access-list iacl
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


!--- Fase 1 - Negação da anti-falsificação e fragmentação
!--- Estas ACEs negam fragmentos e falsificações do
!--- espaço interno como uma origem externa.
!--- Negue fragmentos direcionados ao bloco de infraestrutura.

 deny tcp any 3FFE:B00:C18:3::/64 fragments
 deny udp any 3FFE:B00:C18:3::/64 fragments
 deny icmp any 3FFE:B00:C18:3::/64 fragments


!--- Negue nosso espaço interno como uma origem externa.
!--- Implementado somente na borda do AS.

 deny ipv6 3FFE:B00:C18:::/48 any
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


!--- Fase 2 - Permissão explícita
!--- Permita somente aplicativos/protocolos cujo endereço de
!--- destino é parte do bloco de IPs de infraestrutura.
!--- A origem do tráfego deve ser conhecida e autorizada.



!--- Nota: Este modelo deve ser ajustado para o ambiente de
!--- endereço de origem específico da rede. As variáveis no
!--- modelo devem ser alteradas.



!--- Permita o BGP multiprotocolo.

 permit tcp host 3FFE:B00:C19:2:1::F host 3FFE:B00:C18:2:1::1 eq bgp
 permit tcp host 3FFE:B00:C19:2:1::F eq bgp host 3FFE:B00:C18:2:1::1
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


!--- Fase 3 - Negação explícita para proteger a infraestrutura

 deny ipv6 any 3FFE:B00:C18:3::/64
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


!--- Fase 4 - Permissão explícita para o tráfego de trânsito

 permit ipv6 any any

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: 43920