Listas de controle de acesso de trânsito: filtrando na sua borda

Introduction

Este documento apresenta diretrizes e recomenda técnicas de implantação para a filtragem de trânsito e tráfego de borda nos pontos de entrada da rede. Listas de controle de acesso (ACLs) de trânsito são utilizadas para aumentar a segurança da rede permitindo explicitamente apenas o tráfego necessário na(s) rede(s).

Filtros de trânsito

Configuração típica

Na maioria dos ambientes de rede de borda, como um ponto de presença típico da Internet de uma rede corporativa, a filtragem de ingresso deve ser usada para descartar o tráfego não autorizado na borda da rede. Em determinadas implantações de provedores de serviços, essa forma de filtragem de tráfego de borda ou de trânsito também pode ser usada com eficiência para limitar o fluxo de tráfego de trânsito de e para clientes somente para protocolos permitidos específicos. Este documento enfoca um modelo de implementação empresarial.

Este exemplo representa um projeto típico de conectividade corporativa com a Internet. Dois roteadores de borda, IR1 e IR2, fornecem conectividade direta com a Internet. Por trás desses dois roteadores, um par de firewalls (Cisco PIXes neste exemplo) fornece recursos de inspeção stateful e acesso à rede interna e à zona desmilitarizada (DMZ). A DMZ contém serviços voltados ao público, como DNS e Web; essa é a única rede acessível diretamente da Internet pública. A rede interna nunca deve ser acessada diretamente pela Internet, mas o tráfego originado na rede interna deve ter capacidade para alcançar sites da Internet.

Os roteadores de extremidade devem ser configurados de forma a oferecerem primeiro nível de segurança por meio do uso de ACLs de entrada. As ACLs permitem apenas tráfego especificamente permitido para a DMZ e permitem tráfego de retorno para usuários internos que acessam a Internet. Todo o tráfego não autorizado deve ser descartado nas interfaces de entrada.

Seções ACL de transição

Em geral, uma ACL de trânsito é composta de quatro seções.

• Endereço de uso especial e entradas anti-falsificação que não permitem que fontes ilegítimas e pacotes com endereços de origem que pertençam à sua rede entrem na rede a partir de uma fonte externa

  

  Observação: o RFC 1918 define o espaço de endereço reservado que não é um endereço de origem válido na Internet. O RFC 3330 define endereços de uso especial que possam requerer uma filtragem. O RFC 2827 fornece diretrizes anti-falsificação.

• Tráfego de retorno explicitamente permitido para conexões internas com a Internet

• Tráfego de origem externa explicitamente permitido destinado a endereços internos protegidos

• Explícito deny instrução

  

  Observação: embora todas as ACLs contenham uma deny a Cisco recomenda o uso de uma instrução deny declaração, por exemplo, deny ip any any. Na maioria das plataformas, essas instruções mantêm uma contagem do número de pacotes negados que podem ser exibidos usando o comando show access-list comando.

Como desenvolver uma ACL de trânsito

A primeira etapa no desenvolvimento de uma ACL de trânsito é determinar os protocolos necessários em suas redes. Embora cada site tenha requisitos específicos, certos protocolos e aplicativos são amplamente usados e são permitidos com mais frequência. Por exemplo, se o segmento DMZ fornecer conectividade para um servidor Web publicamente acessível, o TCP da Internet para o(s) endereço(s) do servidor DMZ na porta 80 será necessário. Da mesma forma, as conexões internas com a Internet exigem que a permissão da ACL retorne o tráfego TCP estabelecido - o tráfego que tem o conjunto de bits de confirmação (ACK).

Identificar Protocolos Necessários

O desenvolvimento dessa lista de protocolos necessários pode ser uma tarefa assustadora, mas há várias técnicas que podem ser usadas, conforme necessário, para ajudar a identificar o tráfego necessário.

• Revise sua política de segurança local/política de serviço.

  A política do site local deve ajudar a fornecer uma linha de base de serviços permitidos e negados.

• Revise e faça uma auditoria na configuração do seu firewall.

  A configuração de firewall atual deve conter informações permit instruções para serviços permitidos. Em muitos casos, você pode converter essa configuração no formato ACL e usá-la para criar a maior parte das entradas ACL.

  

  Observação: normalmente, os firewalls stateful não têm regras explícitas para retornar o tráfego às conexões autorizadas. Como ACLs de roteador não são stateful, o tráfego de retorno deve ser explicitamente permitido.

• Revise/realize auditorias em seus aplicativos.

  Os aplicativos hospedados na DMZ e os usados internamente podem ajudar a determinar os requisitos de filtragem. Revise os requisitos do aplicativo para fornecer detalhes essenciais sobre o projeto de filtragem.

• Use uma ACL de classificação.

  Uma ACL de classificação é composta de permit instruções para os vários protocolos que poderiam ser destinados à rede interna. (Consulte o Apêndice A para obter uma lista de protocolos e aplicativos usados com frequência.) Use o show access-list para exibir uma contagem de acertos de entrada de controle de acesso (ACE) para identificar os protocolos necessários. Investigue e compreenda quaisquer resultados suspeitos ou surpreendentes antes de criar permit instruções para protocolos inesperados.

• Utilize o recurso de switching Netflow.

  O Netflow é um recurso de comutação que, se habilitado, fornece informações detalhadas de fluxo. Se o Netflow estiver habilitado nos roteadores de borda, o comando show ip cache flow fornece uma lista de protocolos registrados pelo Netflow. O Netflow não pode identificar todos os protocolos, portanto, essa técnica deve ser usada em conjunto com outros.

Identificar tráfego inválido

Além da proteção direta, a ACL de trânsito também deve fornecer uma primeira linha de defesa contra certos tipos de tráfego inválido na Internet.

• Negue o espaço RFC 1918.

• Negue pacotes com um endereço de origem que caia no espaço de endereço de uso especial, conforme definido no RFC 3330.

• Aplique filtros anti-falsificação, de acordo com o RFC 2827; seu espaço de endereço nunca deve ser a origem de pacotes de fora do seu sistema autônomo (AS).

Outros tipos de tráfego a serem considerados incluem:

• Protocolos externos e endereços IP que precisam se comunicar com o roteador de borda

  • ICMP dos endereços IP do provedor de serviços

  • Protocolos de Roteamento

  • VPN IPSec, se um roteador de borda for usado como a terminação

• Tráfego de retorno explicitamente permitido para conexões internas com a Internet

  • Tipos específicos de Protocolo de Mensagem de Controle da Internet (ICMP)

  • Respostas de consulta do Sistema de Nomes de Domínio (DNS) de saída

  • TCP estabelecido

  • User Datagram Protocol (UDP) tráfego de retorno

  • Conexões de dados FTP

  • Conexões de dados TFTP

  • Conexões multimídia

• Tráfego de origem externa explicitamente permitido destinado a endereços internos protegidos

  • Tráfego de VPN

    • Internet Security Association and Key Management Protocol (ISAKMP)

    • Tradução de Endereço de Rede (NAT) Traversal

    • Encapsulamento proprietário

    • Payload de Segurança de Encapsulamento (ESP - Encapsulating Security Payload)

    • Cabeçalho de autenticação (AH)

  • HTTP para servidores Web

  • SSL (Secure Socket Layer) para servidores Web

  • FTP para servidores FTP

  • Conexões de dados de FTP de entrada

  • Conexões de dados passivos (pasv) FTP de entrada

  • SMTP (Simple Mail Transfer Protocol)

  • Outros aplicativos e servidores

  • Consultas de DNS de entrada

  • Transferências de zona DNS de entrada

Aplicar a ACL

A ACL recém-construída deve ser aplicada na entrada a interfaces voltadas à Internet dos roteadores de extremidade. No exemplo ilustrado na seção Configuração típica, a ACL é aplicada nas interfaces para a Internet em IR1 e IR2.

Consulte as seções sobre diretrizes de implantação e exemplo de implantação para obter mais detalhes.

Exemplo de ACL

Essa lista de acesso fornece um exemplo simples, mas realista, de entradas típicas necessárias em uma ACL de trânsito. É necessário personalizar esse ACL básico com detalhes de configuração específicos de site local.

!--- Add anti-spoofing entries.
!--- Deny special-use address sources.
!--- Refer to RFC 3330 for additional special use addresses.

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
access-list 110 deny ip host 255.255.255.255 any

!--- The deny statement should not be configured
!--- on Dynamic Host Configuration Protocol (DHCP) relays.

access-list 110 deny ip host 0.0.0.0 any

!--- Filter RFC 1918 space.

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

!--- Permit Border Gateway Protocol (BGP) to the edge router.

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

!--- Deny your space as source (as noted in RFC 2827).

access-list 110 deny ip your Internet-routable subnet any

!--- Explicitly permit return traffic.
!--- Allow specific ICMP types.

access-list 110 permit icmp any any echo-reply
access-list 110 permit icmp any any unreachable
access-list 110 permit icmp any any time-exceeded
access-list 110 deny   icmp any any

!--- These are outgoing DNS queries.

access-list 110 permit udp any eq 53  host primary DNS server gt 1023

!--- Permit older DNS queries and replies to primary DNS server.

access-list 110 permit udp any eq 53  host primary DNS server eq 53

!--- Permit legitimate business traffic.

access-list 110 permit tcp any Internet-routable subnet established
access-list 110 permit udp any range 1 1023 Internet-routable subnet gt 1023

!--- Allow ftp data connections.

access-list 110 permit tcp any eq 20 Internet-routable subnet gt 1023

!--- Allow tftp data and multimedia connections.

access-list 110 permit udp any gt 1023 Internet-routable subnet gt 1023

!--- Explicitly permit externally sourced traffic.
!--- These are incoming DNS queries.


access-list 110 permit udp any gt 1023 host <primary DNS server> eq 53

!-- These are zone transfer DNS queries to primary DNS server.

access-list 110 permit tcp host secondary DNS server gt 1023 host primary DNS server eq 53

!--- Permit older DNS zone transfers.

access-list 110 permit tcp host secondary DNS server eq 53  host primary DNS server eq 53

!--- Deny all other DNS traffic.

access-list 110 deny udp any any eq 53
access-list 110 deny tcp any any eq 53

!--- Allow IPSec VPN traffic.

access-list 110 permit udp any host IPSec headend device eq 500
access-list 110 permit udp any host IPSec headend device eq 4500
access-list 110 permit 50 any host IPSec headend device
access-list 110 permit 51 any host IPSec headend device
access-list 110 deny   ip any host IPSec headend device

!--- These are Internet-sourced connections to
!--- publicly accessible servers.

access-list 110 permit tcp any host public web server eq 80
access-list 110 permit tcp any host public web server eq 443
access-list 110 permit tcp any host public FTP server eq 21

!--- Data connections to the FTP server are allowed
!--- by the permit established ACE.
!--- Allow PASV data connections to the FTP server.

access-list 110 permit tcp any gt 1023 host public FTP server gt 1023
access-list 110 permit tcp any host public SMTP server eq 25

!--- Explicitly deny all other traffic.

access-list 101 deny ip any any 

• O log palavra-chave pode ser usada para fornecer detalhes adicionais sobre a origem e os destinos de um determinado protocolo. Embora essa palavra-chave forneça informações valiosas sobre os detalhes dos acessos à ACL, há um excesso de acessos a uma entrada da ACL que usa o comando log palavra-chave para aumentar a utilização da CPU. O impacto de desempenho associado ao registro varia por plataforma.

• As mensagens ICMP inalcançáveis são geradas para pacotes que são negados administrativamente por uma ACL. Isso poderia causar impacto no roteador e no desempenho do enlace. Considere o uso do no ip unreachables para desabilitar IP inalcançável na interface em que a ACL de trânsito (borda) está implantada.

• Essa ACL pode ser implantada inicialmente com todos os permit para garantir que o tráfego legítimo da empresa não seja negado. Depois que o tráfego legítimo da empresa for identificado e contabilizado, o tráfego deny podem ser configurados.

ACLs e pacotes fragmentados

As ACLs têm um fragments palavra-chave que habilita o comportamento especializado de manipulação de pacotes fragmentados. Em geral, os fragmentos não iniciais que correspondem às instruções da Camada 3 (protocolo, endereço de origem e endereço de destino), independentemente das informações da Camada 4 em uma ACL, são afetados pelo permit or deny instrução da entrada correspondida. Observe que o uso do comando fragments pode forçar as ACLs a negar ou permitir fragmentos não iniciais com mais granularidade.

A filtragem de fragmentos acrescenta uma camada adicional de proteção contra um ataque de negação de serviço (DoS) que usa apenas fragmentos não iniciais (como FO > 0). A utilização de um deny para fragmentos não iniciais no início da ACL impede que todos os fragmentos não iniciais acessem o roteador. Em circunstâncias raras, uma sessão válida pode exigir fragmentação e, portanto, ser filtrada se um deny fragment existe na ACL. As condições que podem levar à fragmentação incluem o uso de certificados digitais para autenticação ISAKMP e o uso de IPSec NAT Traversal.

Por exemplo, considere a ACL parcial mostrada aqui.

access-list 110 deny tcp any Internet routable subnet fragments
access-list 110 deny udp any Internet routable subnet fragments
access-list 110 deny icmp any Internet routable subnet fragments
<rest of ACL>

Adicionar essas entradas ao início de uma ACL nega qualquer acesso de fragmento não inicial à rede, enquanto pacotes não fragmentados ou fragmentos iniciais passam para as próximas linhas da ACL não afetadas pela deny fragment declarações. O trecho de ACL anterior também facilita a classificação do ataque, já que cada protocolo (UDP, TCP e ICMP) incrementa contadores separados na ACL.

Como muitos ataques dependem da inundação com pacotes fragmentados, a filtragem de fragmentos recebidos na rede interna fornece uma medida adicional de proteção e ajuda a garantir que um ataque não possa injetar fragmentos simplesmente combinando as regras da camada 3 na ACL de trânsito.

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

Avaliação de risco

Ao implantar ACLs de proteção de tráfego de trânsito, considere duas áreas-chave de risco.

• Assegurar que os permit/deny estão em vigor. Para que a ACL seja eficaz, você deve permitir todos os protocolos necessários.

• O desempenho da ACL varia de acordo com a plataforma. Antes de implantar ACLs, revise as características de desempenho do hardware.

A Cisco recomenda que você teste esse projeto no laboratório antes da implantação.

Apêndices

Protocolos e aplicativos usados com frequência

Nomes de porta TCP

Esta lista de nomes de porta TCP pode ser usada em vez de números de porta quando você configura a ACL no Cisco IOS^® Software. Consulte o RFC do número atribuído atual para encontrar uma referência a esses protocolos. Os números de porta que correspondem a esses protocolos também podem ser encontrados quando você configura a ACL inserindo um ? no lugar de um número de porta.

bgp	kshell
chargen	login
cmd	lpd
daytime	nntp
discard	pim
domain	pop2
echo	pop3
exec	smtp
finger	sunrpc
ftp	syslog
ftp-data	tacacstalk
gopher	telnet
hostname	time
ident	uucp
irc	whois
klogin	www

Nomes de porta UDP

Esta lista de nomes de porta UDP pode ser usada em vez de números de porta quando você configura a ACL no Cisco IOS Software. Consulte o RFC do número atribuído atual para encontrar uma referência a esses protocolos. Os números de porta que correspondem a esses protocolos também podem ser encontrados quando você configura a ACL inserindo um ? no lugar de um número de porta.

biff	ntp
bootpc	pim-auto-rp
bootps	rip
discard	snmp
dnsix	snmptrap
domain	sunrpc
echo	syslog
isakmp	tacacs
mobile-ip	talk
nameserver	tftp
netbios-dgm	time
netbios-ns	who
netbios-ss	xdmcp

Diretrizes de implantação

A Cisco recomenda práticas conservadoras de implantação. Você deve ter uma compreensão clara dos protocolos necessários para implantar com êxito ACLs de trânsito. Essas diretrizes descrevem um método muito conservador para a implantação de ACLs de proteção que usam abordagem iterativa.

1. Identificar os protocolos usados na rede com uma ACL de classificação.

   Implante uma ACL que permita todos os protocolos conhecidos usados na rede. Essa descoberta, ou classificação, ACL deve ter um endereço origem de any e um destino de um endereço IP ou de toda a sub-rede IP roteável pela Internet. Configure uma última entrada que permita ip any any log para ajudar a identificar protocolos adicionais que você precisa permitir.

   O objetivo é determinar todos os protocolos necessários que estão em uso na rede. Use o registro para análise a fim de determinar o que mais pode se comunicar com o roteador.

   

   Nota: Embora a log fornece informações valiosas sobre os detalhes de acertos da ACL, o excesso de acertos em uma entrada da ACL que usa essa palavra-chave pode resultar em um número esmagador de entradas de log e possivelmente no alto uso da CPU do roteador. Use o log por curtos períodos e somente quando necessário para ajudar a classificar o tráfego.

   Observe que a rede está em risco de ataque enquanto uma ACL que consiste em todos os permit está em vigor. Execute o processo de classificação o mais rápido possível para que os controles de acesso apropriados possam ser colocados em prática.

2. Revise os pacotes identificados e comece a filtrar o acesso à rede interna.

   Após identificar e revisar os pacotes filtrados pelo ACL no passo 1, atualize o ACL de classificação para responder pelos protocolos e endereços de IP recém-identificados. Adicione entradas ACL para anti-falsificação. Se necessário, substitua deny entradas para permit instruções na ACL de classificação. Você pode usar o comando show access-list para monitorar deny as entradas podem ser monitoradas quanto à contagem de ocorrências. Isso fornece informações sobre tentativas de acesso a redes proibidas sem que seja necessário habilitar o registro em entradas de ACL. A última linha da ACL deve ser um deny ip any any. Mais uma vez, a contagem de ocorrências em relação a essa última entrada pode fornecer informações sobre tentativas de acesso proibido.

3. Monitore e atualize a ACL.

   Monitore a ACL completa para garantir que os protocolos obrigatórios recém-introduzidos sejam adicionados de maneira controlada. Se você monitorar a ACL, ela também fornecerá informações sobre tentativas de acesso à rede proibidas que podem fornecer informações sobre ataques iminentes.

Exemplo de implantação

Este exemplo mostra uma ACL de trânsito que protege uma rede com base nesse endereçamento.

• O endereço IP do roteador do ISP é 10.1.1.1.

  O endereço IP para a Internet do roteador de borda é 10.1.1.2.

  A sub-rede roteável de Internet é 192.168.201.0 255.255.255.0.

  O fim do cabeçalho VPN é 192.168.201.100.

  O servidor Web é 192.168.201.101.

  O servidor FTP é 192.168.201.102.

  O servidor de SMTP é 192.168.201.103.

  O servidor DNS primário é 192.168.201.104.

  O servidor DNS secundário é 172.16.201.50.

A ACL de proteção de trânsito foi desenvolvida com base nessas informações. A ACL permite o peering eBGP para o roteador ISP, fornece filtros anti-falsificação, permite tráfego de retorno específico, permite tráfego de entrada específico e nega explicitamente qualquer outro tráfego.

no access-list 110

!--- Phase 1 – Add anti-spoofing entries.
!--- Deny special-use address sources.
!--- See RFC 3330 for additional special-use addresses.

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
access-list 110 deny   ip host 255.255.255.255 any

!--- This deny statement should not be configured 
!--- on Dynamic Host Configuration Protocol (DHCP) relays.

access-list 110 deny   ip host 0.0.0.0 any

!--- Filter RFC 1918 space.

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

!--- Permit BGP to the edge router.

access-list 110 permit tcp host 10.1.1.1 gt 1023 host 10.1.1.2 eq bgp
access-list 110 permit tcp host 10.1.1.1 eq bgp host 10.1.1.2 gt 1023

!--- Deny your space as source (as noted in RFC 2827).

access-list 110 deny   ip 192.168.201.0 0.0.0.255 any

!--- Phase 2 – Explicitly permit return traffic.
!--- Allow specific ICMP types.

access-list 110 permit icmp any any echo-reply
access-list 110 permit icmp any any unreachable
access-list 110 permit icmp any any time-exceeded
access-list 110 deny   icmp any any

!--- These are outgoing DNS queries.

access-list 110 permit udp any eq domain host 192.168.201.104 gt 1023

!--- Permit older DNS queries and replies to primary DNS server.

access-list 110 permit udp any eq domain host 192.168.201.104 eq domain

!--- Permit legitimate business traffic.

access-list 110 permit tcp any 192.168.201.0 0.0.0.255 established
access-list 110 permit udp any range 1 1023 192.168.201.0 0.0.0.255 gt 1023

!--- Allow FTP data connections.

access-list 110 permit tcp any eq ftp-data 192.168.201.0 0.0.0.255 gt 1023

!--- Allow TFTP data and multimedia connections.

access-list 110 permit udp any gt 1023 192.168.201.0 0.0.0.255 gt 1023

!--- Phase 3 – Explicitly permit externally sourced traffic.
!--- These are incoming DNS queries.

access-list 110 permit udp any gt 1023 host 192.168.201.104 eq domain

!--- Zone transfer DNS queries to primary DNS server.

access-list 110 permit tcp host 172.16.201.50 gt 1023 host 192.168.201.104 eq domain

!--- Permit older DNS zone transfers.

access-list 110 permit tcp host 172.16.201.50 eq domain host 192.168.201.104 eq domain

!--- Deny all other DNS traffic.

access-list 110 deny   udp any any eq domain
access-list 110 deny   tcp any any eq domain

!--- Allow IPSec VPN traffic.

access-list 110 permit udp any host 192.168.201.100 eq isakmp
access-list 110 permit udp any host 192.168.201.100 eq non500-isakmp
access-list 110 permit esp any host 192.168.201.100
access-list 110 permit ahp any host 192.168.201.100
access-list 110 deny   ip any host 192.168.201.100


!--- These are Internet-sourced connections to
!--- publicly accessible servers.

access-list 110 permit tcp any host 192.168.201.101 eq www
access-list 110 permit tcp any host 192.168.201.101 eq 443
access-list 110 permit tcp any host 192.168.201.102 eq ftp



!--- Data connections to the FTP server are allowed 
!--- by the permit established ACE in Phase 3.
!--- Allow PASV data connections to the FTP server.

access-list 110 permit tcp any gt 1023 host 192.168.201.102 gt 1023
access-list 110 permit tcp any host 192.168.201.103 eq smtp

!--- Phase 4 – Add explicit deny statement.

access-list 110 deny   ip any any

Edge-router(config)#interface serial 2/0
Edge-router(config-if)#ip access-group 110 in

Informações Relacionadas

• Solicitações de Comentários (RFCs)
• Suporte Técnico e Documentação - Cisco Systems