Fortalecer dispositivos IOS

Introdução

Este documento descreve como proteger os dispositivos de sistema Cisco IOS^® e aumentar a segurança geral da sua rede.

Pré-requisitos

Requisitos

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

Componentes Utilizados

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

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Background

Quando você protege os dispositivos do sistema Cisco IOS, a segurança geral da rede aumenta.

A segurança geral da rede é estruturada em torno dos três planos nos quais as funções de um dispositivo de rede podem ser categorizadas. Os três planos funcionais de uma rede são: o plano de gerenciamento, o plano de controle e o plano de dados, cada plano fornece uma funcionalidade diferente que precisa ser protegida. Este documento fornece uma visão geral de cada recurso incluído e referências à documentação relacionada.

• Plano de gerenciamento - O plano de gerenciamento gerencia o tráfego enviado para o dispositivo IOS Cisco e é composto de aplicativos e protocolos, como Secure Shell (SSH) e Simple Network Management Protocol (SNMP).
  
  
• Plano de controle – O plano de controle de um dispositivo de rede processa o tráfego essencial para manter a funcionalidade da infraestrutura de rede. O plano de controle consiste em aplicativos e protocolos entre dispositivos de rede, como o Border Gateway Protocol (BGP), assim como os Interior Gateway Protocols (IGPs). Também estão incluídos o Enhanced Interior Gateway Routing Protocol (EIGRP) e o Open Shortest Path First (OSPF).
  
  
• Plano de dados – O plano de dados encaminha os dados através de um dispositivo de rede. O plano de dados não inclui o tráfego enviado ao dispositivo Cisco IOS local.

Os recursos de segurança abordados neste documento frequentemente fornecem detalhes suficientes para que você configure o recurso descrito. No entanto, quando os detalhes não estiverem disponíveis, o recurso será explicado de forma que você possa avaliar se é necessária atenção adicional ao recurso. Sempre que possível e apropriado, este documento contém recomendações que, se implementadas, ajudam a proteger uma rede.

Fixe operações

As operações de rede seguras são um assunto substancial. Embora a maioria destes documentos seja devotado à configuração segura de um dispositivo IOS Cisco, as configurações apenas não fixam completamente uma rede. Os procedimentos operacionais no uso na rede contribuem tanto quanto à segurança quanto a configuração dos dispositivos subjacentes.

Estes assuntos contêm as recomendações operacionais que você é recomendado executar. Estes assuntos destacam áreas crítica específicas das operações de rede e não são detalhados.

Monitore Recomendações de Segurança da Cisco e respostas

A equipe da resposta de incidentes de segurança de produto Cisco (PSIRT) cria e mantém as publicações, referidas geralmente como informativos psirt, para edições relacionadas à segurança nos produtos da Cisco. O método usado para uma comunicação de edições menos severas é a resposta do Cisco Security. As recomendações e respostas de segurança estão disponíveis em Recomendações de Segurança da Cisco.

A informação adicional sobre estes veículos de uma comunicação está disponível na política da vulnerabilidade do Cisco Security.

Para manter uma rede segura, esteja ciente das recomendações de segurança e respostas da Cisco que foram divulgadas. Você precisa de ter o conhecimento de uma vulnerabilidade antes que a ameaça que possa levantar a uma rede possa ser avaliada. Consulte Triagem de riscos para anúncios de vulnerabilidade de segurança para obter assistência neste processo de avaliação.

Entrega de Autenticação, Autorização e Relatório

A estrutura de autenticação, autorização e contabilização (AAA) é fundamental para proteger os dispositivos de rede. A estrutura AAA fornece a autenticação das sessões de gerenciamento e pode igualmente limitar usuários a comandos específico, definidos pelos administradores e aos comandos all do registro inscritos por todos os usuários. Consulte a seção Autenticação, autorização e contabilização deste documento para obter mais informações sobre como utilizar a estrutura de AAA.

Centralize a coleta de registros e monitore o processo

Para obter conhecimento sobre eventos atuais, emergentes e históricos relacionados a incidentes de segurança, sua empresa deve ter uma estratégia unificada para registros de eventos e correlação. Essa estratégia unificada deve aproveitar os registros de todos os dispositivos de rede e usar recursos de correlação predefinidos e personalizáveis.

Depois que os registros centralizados são implementados, você deve desenvolver uma abordagem estruturada para a análise de registros e rastrear incidentes. Baseado nas necessidades de sua organização, esta aproximação pode variar de uma revisão diligente simples dos dados de registro a análise baseado em regras avançada.

Consulte a seção Práticas Recomendadas de Registro deste documento para obter mais informações sobre como implementar registros em dispositivos de rede Cisco IOS.

Use protocolos seguros quando possível

Vários protocolos são usados para transportar dados confidenciais de gerenciamento de rede. Use protocolos seguros sempre que possível. Uma opção de protocolo seguro inclui o uso de SSH, em vez de Telnet, para que os dados de autenticação e as informações de gerenciamento sejam criptografados. Além disso, use protocolos de transferência de arquivos seguros ao copiar dados de configuração. Um exemplo é o uso do protocolo da cópia segura (SCP) no lugar do FTP ou do TFTP. 

Consulte a seção Proteger sessões interativas de gerenciamento deste documento para obter mais informações sobre o gerenciamento seguro de dispositivos Cisco IOS.

Ganhe a visibilidade do tráfego com NetFlow

O NetFlow permite que você monitore os fluxos de tráfego na rede. Originalmente destinado a exportar informações de tráfego para aplicativos de gerenciamento de rede, o NetFlow também pode ser usado para mostrar informações de fluxo em um roteador. Esta capacidade permite que você considere que tráfego atravessa a rede no tempo real. Independentemente de as informações de fluxo serem exportadas ou não para um coletor remoto, você é recomendado configurar dispositivos de rede para o NetFlow para que ele possa ser usado de forma reativa, se necessário.

Mais informações sobre esse recurso estão disponíveis na seção Identificação de tráfego e Traceback deste documento e no Cisco IOS NetFlow.

Observação: somente usuários registrados da Cisco têm acesso a ferramentas e informações internas.

Gerenciamento de configuração

O gerenciamento de configuração é um processo pelo qual as alterações de configuração são propostas, revistas, aprovadas, e distribuídas. Dentro do contexto de uma configuração de dispositivo IOS Cisco, dois aspectos adicionais do gerenciamento de configuração são críticos: arquivamento de configuração e segurança.

Use arquivos de configuração para reverter as alterações feitas nos dispositivos de rede. Em um contexto de segurança, os arquivos de configuração também podem ser usados para determinar quais alterações de segurança foram feitas e quando essas alterações ocorreram. Juntamente com os dados de registro AAA, essas informações podem auxiliar na auditoria de segurança dos dispositivos de rede.

A configuração de um dispositivo IOS Cisco contém muitos detalhes sensíveis. Nomes de usuário, senhas e o conteúdo das listas de controle de acesso são exemplos dessas informações confidenciais. O repositório usado para arquivar as configurações do dispositivo IOS Cisco precisa ser protegido. O acesso incerto a esta informação pode minar a segurança da toda a rede.

Plano de gerenciamento

O plano de gerenciamento consiste nas funções que conseguem os objetivos da gestão da rede. Isso inclui as sessões interativas de gerenciamento que usam o SSH e a coleta de estatísticas com SNMP ou NetFlow. Quando você considera a segurança de um dispositivo de rede, é essencial que o plano de gerenciamento esteja protegido. Se um incidente de segurança for capaz de minar as funções do plano de gerenciamento, pode ser impossível recuperar ou estabilizar a rede.

Estas seções deste original detalham os recursos de segurança e as configurações disponíveis no Cisco IOS Software que ajudam a fortificar o plano de gerenciamento.

Plano de gerenciamento geral de endurecimento

O plano de gerenciamento é usado para acessar, configurar e gerenciar um dispositivo, bem como monitorar suas operações e a rede na qual ele é implantado. O plano de gerenciamento recebe e envia tráfego para operações dessas funções. Proteja o plano de gerenciamento e o plano de controle de um dispositivo, pois as operações do plano de controle afetam diretamente as operações do plano de gerenciamento. Esses protocolos usados pelo plano de gerenciamento incluem:

• Protocolo simples de gestão de rede
• Telnet
• Protocolo secure shell
• Protocolo de transferência de arquivo
• HyperText Transfer Protocol/Secure HyperText Transfer Protocol

• Protocolo trivial file transfer
• Protocolo da cópia segura
• TACACS+
• RADIUS
• Netflow
• Protocolo de tempo de rede
• Syslog

As etapas devem ser tomadas para assegurar a sobrevivência da gestão e para controlar planos durante incidentes de segurança. Se qualquer um desses planos for explorado com sucesso, todos os planos podem ser comprometidos.

Gerenciamento de senha

Acesso do controle das senhas aos recursos ou aos dispositivos. Isso é feito por meio da senha usada para autenticar solicitações. Quando uma solicitação é recebida para acesso a um recurso ou dispositivo, a solicitação é desafiada para a verificação da senha e da identidade, e o acesso pode ser concedido, negado ou limitado, com base no resultado. Como um melhor prática da segurança, as senhas devem ser controladas com um TACACS+ ou um servidor de autenticação RADIUS. No entanto, uma senha configurada localmente para acesso privilegiado ainda é necessária no caso de falha dos serviços TACACS+ ou RADIUS. Um dispositivo pode igualmente ter a outra informação de senha atual dentro de sua configuração, tal como uma chave NTP, a chave da série de comunidade SNMP, ou do protocolo de roteamento.

O comando enable secret é usado para definir a senha que concede acesso administrativo privilegiado ao sistema Cisco IOS. O comandoenable secretdeve ser usado, em vez do comandoenable passwordmais antigo. O enable passwordusa um algoritmo de criptografia fraco.

Se nenhum enable secret for definido e uma senha for configurada para a linha tty do console, a senha do console poderá ser usada para receber acesso privilegiado, mesmo de uma sessão tty virtual remota (vty). Esta ação é quase certamente indesejável e é uma outra razão para assegurar a configuração de habilitar segredo.

O comando de configuração global service password-encryption direciona o software Cisco IOS para criptografar as senhas, os segredos CHAP (Challenge Handshake Authentication Protocol Protocolo de Autenticação de Handshake de Desafio) e dados semelhantes que são salvos em seu arquivo de configuração. Essa criptografia é útil para impedir que observadores casuais observem senhas, como quando olham para a tela por cima do ombro de um administrador. No entanto, o algoritmo usado pelo service password-encryption comando é uma cifra simples de Vigen re. O algoritmo não é projetado para proteger arquivos de configuração contra a análise séria mesmo por atacantes leve sofisticados e não deve ser usado por esse motivo. Todo o arquivo de configuração IOS Cisco que contiver senhas criptografada deve ser tratado com o mesmo cuidado que é usado para uma lista de texto puro daquelas mesmas senhas.

Embora esse algoritmo de criptografia fraco não seja usado pelo enable secret comando, ele é usado pelo comando de configuração global, bem como pelo enable password comando de configuração de password linha. Esse tipo de senha deve ser eliminado e o enable secret comando ou o recurso Segurança de senha aprimorada precisa ser usado.

O comandoenable secrete o recurso Segurança de senha aprimorada usam o Message Digest 5 (MD5) para o hash de senha. Este algoritmo teve a revisão pública considerável e não é sabido para ser reversível. Contudo, o algoritmo é sujeito aos ataques do dicionário. Em um ataque de dicionário, um invasor tenta cada palavra em um dicionário ou outra lista de senhas candidatas para encontrar uma correspondência. Conseqüentemente, os arquivos de configuração devem firmemente ser armazenados e somente compartilhado com os indivíduos confiados.

Segurança de senha aumentada

O recurso Enhanced Password Security, introduzido no Cisco IOS Software Release 12.2(8)T, permite que um administrador configure o hash MD5 de senhas para ousernamecomando. Antes desta característica, havia dois tipos de senhas: Tipo 0, que é uma senha de texto claro, e Tipo 7, que usa o algoritmo da cifra Vigen re. A característica aumentada da segurança de senha não pode ser usada com protocolos que exigem a senha de texto claro ser recuperável, como o CHAP.

Para criptografar uma senha de usuário com hash MD5, emita o comando de configuração globalusername secret.

!

username <name> secret <password>

!

Fechamento da nova tentativa da senha de login

O recurso Login Password Retry Lockout, adicionado ao software Cisco IOS versão 12.3(14)T, permite bloquear uma conta de usuário local após um número configurado de tentativas de login sem êxito. Uma vez que um usuário é fechado para fora, sua conta é fechada até que você a destrave. Um usuário autorizado configurado com nível de privilégio 15 não pode ser bloqueado com este recurso. Mantenha o número mínimo de usuários com privilégio de nível 15.

Note que os usuários autorizados podem se travar fora de um dispositivo se o número de tentativas de login mal sucedidas é alcançado. Adicionalmente, um usuário malicioso pode criar uma recusa da condição do serviço (DoS) com as tentativas repetidas de autenticar com um nome de usuário válido.

Este exemplo mostra como permitir a característica do fechamento da nova tentativa da senha de login:

!

aaa new-model
aaa local authentication attempts max-fail <max-attempts>
aaa authentication login default local

!

username <name> secret <password>

!

Esse recurso também se aplica a métodos de autenticação, como CHAP e Password Authentication Protocol (PAP).

Recuperação de Senha Sem Serviço

No Cisco IOS Software Release 12.3(14)T e Mais Recente, nenhuma característica da recuperação de senha do serviço não permite que qualquer um com acesso de console alcance incerta a configuração de dispositivo e cancele a senha. Igualmente não permite que os usuários maliciosos mudem o valor do registro de configuração e o acesso NVRAM.

!

no service password-recovery

!

O software Cisco IOS fornece um procedimento de recuperação de senha que depende do acesso ao ROM Monitor Mode (ROMMON) que usa a tecla Break durante a inicialização do sistema. No ROMMON, o software do dispositivo pode ser recarregado para solicitar uma nova configuração do sistema que inclua uma nova senha.

O procedimento de recuperação da senha atual permite qualquer um com acesso de console de alcançar o dispositivo e sua rede. O recurso No Service Password-Recovery impede a conclusão da sequência de tecla Break e a entrada do ROMMON durante a inicialização do sistema.

Se o no service password-recovery estiver ativado em um dispositivo, é recomendável que uma cópia off-line da configuração do dispositivo seja salva e uma solução de arquivamento de configuração seja implementada. Se é necessário recuperar uma vez a senha de um dispositivo IOS Cisco esta característica está permitida, a configuração completa está suprimida.

Consulte Exemplo de configuração segura do ROMMON para obter mais informações sobre esse recurso.

Desabilite serviços não utilizados

Como uma prática recomendada de segurança, desative qualquer serviço desnecessário. Serviços desnecessários, especialmente aqueles que usam o User Datagram Protocol (UDP), são raramente usados para fins legítimos, mas podem ser usados para iniciar DoS e outros ataques que são evitados pela filtragem de pacotes.

Desative os pequenos serviços TCP e UDP. Estes serviços incluem:

• eco (número de porta 7)
  
  
• rejeite (número de porta 9)
  
  
• dia (número de porta 13)
  
  
• chargen (número de porta 19)

Embora o abuso dos pequenos serviços possa ser evitado ou tornado menos perigoso por listas de acesso anti-falsificação, desabilite os serviços em qualquer dispositivo acessível na rede. Por padrão, os serviços pequenos são desabilitados no Cisco IOS Software Releases 12.0 e posteriores. Em softwares anteriores, os comandos de configuração no service tcp-small-servers e no service udp-small-servers global podem ser emitidos para desativá-los.

Os serviços adicionais que devem ser desativados, se não forem usados, incluem:

• Emita o comando de configuração globalno ip fingerpara desativar o serviço Finger. Por padrão, as versões do software Cisco IOS posteriores à 12.1(5) e 12.1(5)T desativam esse serviço.
• Emita o comandono ip bootp serverde configuração global para desativar o Bootstrap Protocol (BOOTP).
• No Cisco IOS Software Release 12.2(8)T e mais recente, emita o comando ip dhcp bootp ignore no modo de configuração global para desativar o BOOTP. Isto deixa serviços do protocolo de configuração dinâmica host (DHCP) habilitados.
• Os serviços DHCP podem ser deficientes se os serviços da transmissão de DHCP não forem exigidos. Emita o comando no service dhcp no modo de configuração global.
• Emita o comando no mop enabled no modo de configuração de interface para desativar o serviço do Protocolo de Operação de Manutenção (MOP - Maintenance Operation Protocol).
• Emita o comando de configuração global no ip domain-lookup para desabilitar os serviços de resolução do Sistema de Nome de Domínio (DNS).
• Emita o comando no service pad no modo de configuração global para desativar o serviço Packet Assembler/Disassembler (PAD), que é usado para redes X.25.
  O servidor HTTP pode ser desativado com o comando no ip http server modo de configuração global, e o servidor Secure HTTP (HTTPS) pode ser desativado com o comando de configuração global no ip http secure-server.
  A menos que os dispositivos IOS Cisco recuperarem configurações da rede durante a partida, o comando de configuração global do no service config deve ser usado. Isso evita que o dispositivo Cisco IOS tente localizar um arquivo de configuração na rede com TFTP.
  O Cisco Discovery Protocol (CDP) é um protocolo de rede usado para descobrir outros dispositivos habilitados para CDP para adjacência de vizinhos e topologia de rede. O CDP pode ser usado por Sistemas de Gerenciamento de Rede (NMS) ou enquanto ocorre o isolamento do problema. O CDP deve ser desabilitado em todas as interfaces conectadas a redes não confiáveis. Isto é realizado com o comando interface do no cdp enable. Alternativamente, o CDP pode ser desabilitada globalmente com o comando de configuração global do no cdp run. Observe que o CDP pode ser usado por um usuário mal-intencionado para reconhecimento e mapeamento de uma rede.
• O LLDP (Link Layer Discovery Protocol) é um protocolo IEEE definido em 802.1AB e é semelhante ao CDP. Contudo, este protocolo permite a interoperabilidade entre os outros dispositivos que não apoiam o CDP. LLDP deve ser tratado da mesma forma como o CDP e desabilitado em todas as relações que conectam às redes não confiáveis. Para fazer isso, emita os comandos de configuração de interface no lldp transmit e no lldp receive. Emita o comando de configuração global no lldp run para desativar o LLDP globalmente. O LLDP também pode ser usado por um usuário mal-intencionado para reconhecimento e mapeamento de uma rede.

• Para switches que suportam inicialização a partir do sdflash, a segurança pode ser aprimorada para inicialização a partir do flash e desabilitar o sdflash com o comando de configuração "no sdflash".

EXEC timeout

Para definir o intervalo, o intérprete do comando EXEC espera a entrada do usuário antes de terminar uma sessão, emita o comando de configuração de linha exec-timeout. Use o comando exec-timeout para encerrar a sessão em linhas vty ou tty que estão inativas. Por padrão, as sessões são desconectadas após dez minutos de inatividade.

!

line con 0
 exec-timeout <minutes> [seconds]
line vty 0 4
 exec-timeout <minutes> [seconds]
!

Keepalives para sessões de TCP

Os comandos de configuração global service tcp-keepalives-in e service tcp-keepalives-out permitem que um dispositivo envie keepalives de TCP para sessões TCP. Use esta configuração para habilitar keepalives TCP em conexões de entrada para o dispositivo e conexões de saída do dispositivo. Isso garante que o dispositivo na extremidade remota da conexão ainda esteja acessível e que as conexões semiabertas ou órfãs sejam removidas do dispositivo IOS Cisco local.

!

service tcp-keepalives-in
service tcp-keepalives-out
!

Uso da interface de gerenciamento

O plano de gerenciamento de um dispositivo é em-faixa ou fora da banda alcançado em um exame ou no Logical Management Interface. Idealmente, o acesso de gerenciamento dentro da banda e fora da banda existe para cada dispositivo de rede para que o plano de gerenciamento possa ser acessado durante interrupções da rede.

Uma das interfaces mais comuns usadas para o acesso em banda a um dispositivo é a interface de loopback lógico. As interfaces de loopback são sempre acima, visto que as interfaces física podem mudar o estado, e a relação podem ser potencialmente não acessíveis. Recomenda-se adicionar uma interface de loopback a cada dispositivo como uma interface de gerenciamento e ser usada exclusivamente para o plano de gerenciamento. Isto permite que o administrador aplique políticas durante todo a rede para o plano de gerenciamento. Uma vez configurada em um dispositivo, a interface de loopback pode ser usada pelos protocolos do plano de gerenciamento, como SSH, SNMP e syslog, para enviar e receber tráfego.

!
interface Loopback0
 ip address 192.168.1.1 255.255.255.0
!

Notificações do ponto inicial da memória

O recurso de notificação de limite de memória, adicionado ao Cisco IOS Software Release 12.3(4)T, permite que você reduza condições de memória baixa em um dispositivo. Esse recurso usa dois métodos para realizar isso: Notificação de limite de memória e Reserva de memória.

A Notificação de Limite de Memória gera uma mensagem de log para indicar que a memória livre em um dispositivo caiu abaixo do limite configurado. Este exemplo de configuração mostra como permitir esta característica com o comando global configuration memory free low-watermark. Isto permite um dispositivo de gerar uma notificação quando a memória livre disponível cai mais baixo do que o limiar especificado, e outra vez quando a memória livre disponível aumentar cinco por cento a mais alto do que o limiar especificado.

!

memory free low-watermark processor <threshold>
memory free low-watermark io <threshold>
!

A Reserva de Memória é usada para que haja memória suficiente disponível para notificações críticas. Este exemplo de configuração demonstra como habilitar esse recurso para garantir que os processos de gerenciamento continuem a funcionar quando a memória do dispositivo for esgotada.

!

memory reserve critical <value>
!

Refira a notificações do ponto inicial da memória para obter mais informações sobre esta característica.

Notificação do limiar CPU

Introduzido no Cisco IOS Software Release 12.3(4)T, o recurso de Notificação de Limite de CPU permite que você detecte e receba notificação quando a carga de CPU em um dispositivo cruza um limite configurado. Quando o ponto inicial é cruzado, o dispositivo gera e envia um mensagem de armadilha de SNMP. Dois métodos de limite de uso da CPU são suportados no software Cisco IOS: Limite de elevação e Limite de queda.

Esta configuração de exemplo mostra como ativar os Limites de elevação e de queda para disparar uma mensagem de notificação de limite de CPU:

!

snmp-server enable traps cpu threshold
!

snmp-server host <host-address> <community-string> cpu 
!

process cpu threshold type <type> rising <percentage> interval <seconds> 
     [falling <percentage> interval <seconds>]
process cpu statistics limit entry-percentage <number> [size <seconds>]
!

Refira a notificação do limiar de CPU para obter mais informações sobre esta característica.

Memória da reserva para o acesso de console

No Cisco IOS Software Release 12.4(15)T e posterior, o recurso Reservar Memória para Acesso de Console pode ser usado para reservar memória suficiente para garantir o acesso de console a um dispositivo Cisco IOS para fins administrativos e de isolamento de problemas. Esse recurso é especialmente útil quando o dispositivo está com pouca memória. Você pode emitir o comando de configuração global memory reserve console para ativar esse recurso. Este exemplo configura um dispositivo IOS Cisco para reservar 4096 quilobytes por este motivo.

!
memory reserve console 4096
!

Detector de escape de memória

Introduzido no Cisco IOS Software Release 12.3(8)T1, a característica do detector de escape de memória permite que você detecte escapes de memória em um dispositivo. O Detector de Vazamento de Memória pode localizar vazamentos em todos os pools de memória, buffers de pacotes e blocos. Os escapes de memória são estáticos ou as alocações dinâmica da memória que não servem nenhuma finalidade útil. Esta característica centra-se sobre as alocações de memória que são dinâmicas. Você pode usar o comando EXEC show memory debug leaks para detectar se existe uma perda de memória.

Estouro de buffer: detecção e correção da corrupção de Redzone

No Cisco IOS Software Release 12.3(7)T e mais recente, o recurso Buffer Overflow: Detection and Correction of Redzone Corruption pode ser ativado em um dispositivo para detectar e corrigir um estouro de bloco de memória e para continuar as operações.

Comandos de configuração global podem ser usados para ativar esse recurso. Uma vez configurado, o comando show memory overflow pode ser usado para exibir a detecção de estouro de buffer e as estatísticas de correção.

!
exception memory ignore overflow io
exception memory ignore overflow processor
!

Coleção aumentada do arquivo crashinfo (informações de travamento)

A característica aumentada da coleção do arquivo crashinfo (informações de travamento) suprimem automaticamente de arquivos crashinfo (informações de travamento) velhos. Esta característica, adicionada no Cisco IOS Software Release 12.3(11)T, permite que um dispositivo recupere o espaço para criar arquivos crashinfo (informações de travamento) novos quando o dispositivo causa um crash. Esse recurso também permite que o número de arquivos de informação de travamento salvos seja configurado.

!
exception crashinfo maximum files <number-of-files>
!

Protocolo de tempo de rede

O Network Time Protocol (NTP) não é um serviço perigoso, mas qualquer serviço desnecessário pode representar um vetor de ataque. Se o NTP é usado, é importante configurar explicitamente um origem de tempo confiado e usar a autenticação apropriada. Um tempo preciso e confiável é necessário para fins de syslog, como durante investigações forenses de ataques potenciais, bem como para conectividade de VPN bem-sucedida quando dependente de certificados para autenticação da Fase 1.

• Fuso horário do NTP - Quando você configura o NTP, o fuso horário precisa ser configurado para que os carimbos de data/hora possam ser correlacionados com precisão. Há dois métodos típicos para configurar o fuso horário para dispositivos em uma rede com presença global. Um método é configurar todos os dispositivos de rede com o tempo universal coordenado (UTC) (previamente horário de Greenwich (GMT)). O outro método é configurar dispositivos de rede com o fuso horário local. Mais informação nesta característica pode ser encontrada do “no fuso horário pulso de disparo” na documentação de produtos da Cisco.
  
  
• Autenticação NTP – Se você configurar a autenticação NTP, ela garante que as mensagens NTP sejam trocadas entre pares NTP confiáveis.

Este é um exemplo de configuração que usa a autenticação NTP:

Cliente:

(config)#ntp authenticate
(config)#ntp authentication-key 5 md5 ciscotime
(config)#ntp trusted-key 5
(config)#ntp server 172.16.1.5 key 5

Servidor:

(config)#ntp authenticate
(config)#ntp authentication-key 5 md5 ciscotime
(config)#ntp trusted-key 5

Desativar o Smart Install

As melhores práticas de segurança relacionadas ao recurso Cisco Smart Install (SMI) dependem de como o recurso é usado em um ambiente de usuário específico. A Cisco diferencia estes casos de uso:

• Usuários que não usam o recurso SMI.
• Usuários que utilizam o recurso SMI apenas para implantação automatizada.
• Usuários que utilizam o recurso Smart InstallSMI para uma implantação que não requer intervenção manual (gerenciamento de configuração e imagem).

Estas seções descrevem cada cenário detalhadamente:

• Usuários que não usam o recurso SMI.
• Os usuários que não usam o recurso SMI e executam uma versão do Cisco IOS e do software Cisco IOS XE onde o comando está disponível podem desativar o recurso SMI com o comando no vstack.

Observação: o comando vstack foi introduzido no Cisco IOS versão 12.2(55)SE03.

Este é um exemplo de saída do comando show vstack em um Switch Cisco Catalyst com o recurso de cliente SMI desabilitado:

switch# show vstack 
config Role: Client (SmartInstall disabled) 
Vstack Director IP address: 0.0.0.0

Clientes que utilizam o recurso SMI apenas para implantação automatizada

Desative a funcionalidade do cliente SMI depois que a instalação automatizada for concluída ou use o comando no vstack.

Para propagar o comando no vstack na rede, use um destes métodos:

• Insira o comando no vstack em todos os switches clientes, manualmente ou com um script.
• Adicione o comando no vstack como parte da configuração do Cisco IOS que é enviada para cada cliente SMI como parte da instalação automatizada.
• Em versões que não suportam o comando vstack (Cisco IOS Release 12.2(55)SE02 e versões anteriores), aplique uma lista de controle de acesso (ACL) em switches clientes para bloquear o tráfego na porta TCP 4786.

Para habilitar a funcionalidade de cliente SMI posteriormente, insira o comando vstack em todos os switches clientes, manualmente ou com um script.

Clientes que aproveitam o recurso SMI para uma implantação mais do que automatizada

No projeto de uma arquitetura SMI, tenha cuidado para que o espaço de endereço IP da infraestrutura não seja acessível a partes não confiáveis. Em versões que não suportam o comando vstack, assegure-se de que somente o direcionador SMI tenha conectividade TCP para todos os clientes SMI na porta 4786.

Os administradores podem usar as seguintes práticas recomendadas de segurança para implantações de SMI em dispositivos afetados:

• ACLs para interface
• Política de plano de controle (CoPP). Este recurso não está disponível em todas as versões do software Cisco IOS.

Este exemplo mostra uma ACL de interface com o endereço IP do direcionador SMI como 10.10.10.1 e o endereço IP do cliente SMI como 10.10.10.200:

ip access-list extended SMI_HARDENING_LIST
Permit tcp host 10.10.10.1 host 10.10.10.200 eq 4786
deny tcp any any eq 4786
permit ip any any

Essa ACL deve ser implantada em todas as interfaces IP em todos os clientes. Ele também pode ser enviado pelo direcionador quando os switches são implantados pela primeira vez.

Para restringir ainda mais o acesso a todos os clientes na infraestrutura, os administradores podem usar estas práticas recomendadas de segurança em outros dispositivos na rede:

• Listas de controle de acesso para infraestrutura (iACLs)
• Listas de controle de acesso à VLAN (VACLs)

Limitar o acesso à rede com ACLs para infraestrutura

Projetados para impedir a comunicação direta não autorizada com dispositivos de rede, os iACLs são um dos controles de segurança mais críticos implementados nas redes. Um iACL aproveita a ideia de que quase todo o tráfego de rede atravessa a rede e não é destinado à própria rede.

Um iACL é construído e aplicado para especificar conexões dos anfitriões ou das redes que precisam de ser permitidos aos dispositivos de rede. Exemplos comuns desses tipos de conexão são eBGP, SSH e SNMP. Depois que as conexões exigidas foram permitidas, todo tráfego restante à infra-estrutura está negado explicitamente. Todo o tráfego de trânsito que cruza a rede e não é destinado aos dispositivos de infra-estrutura é permitido então explicitamente.

As proteções fornecidas por iACLs são relevantes à gestão e controlam planos. A implementação de iACLs pode ser facilitada através do uso de endereços distintos para dispositivos de infraestrutura de rede. Consulte Uma abordagem orientada à segurança do endereçamento IP para obter mais informações sobre as implicações de segurança dos endereços IP.

Este exemplo de configuração de iACL ilustra a estrutura que deve ser usada como o ponto inicial quando você inicia o processo de implementação de iACL:

!

ip access-list extended ACL-INFRASTRUCTURE-IN
!
!--- Permit required connections for routing protocols and
!--- network management
!

 permit tcp host <trusted-ebgp-peer> host <local-ebgp-address> eq 179
 permit tcp host <trusted-ebgp-peer> eq 179 host <local-ebgp-address>
 permit tcp host <trusted-management-stations> any eq 22
 permit udp host <trusted-netmgmt-servers> any eq 161
!
!--- Deny all other IP traffic to any network device
!

 deny ip any <infrastructure-address-space> <mask>
!
!--- Permit transit traffic
!

 permit ip any any
!

Uma vez que criado, o iACL deve ser aplicado a todas as relações que enfrentam dispositivos da NON-infra-estrutura. Isto inclui as relações que conectam a outros organizações, segmentos do acesso remoto, segmentos do usuário, e segmentos nos centros de dados.

Consulte Protecting Your Core: Infrastructure Protection Access Control Lists para obter mais informações sobre ACLs de infraestrutura.

Filtração do pacote ICMP

O Internet Control Message Protocol (ICMP) é projetado como um protocolo de controle de IP. Como tal, as mensagens que ele transmite podem ter uma interação significativa com os protocolos TCP e IP em geral. Enquanto as ferramentas de rede, ping e traceroute, para solucionar problemas de uso do ICMP, a conectividade externa do ICMP raramente é necessária para a operação de rede adequada.

O Cisco IOS Software fornece a funcionalidade para filtrar especificamente por nome da mensagens ICMP ou para datilografá-los e codificá-los. Este exemplo ACL, o qual deve ser usado com as entradas de controle de acesso (ACE) dos exemplos anteriores, permite a execução do ping das estações de gerenciamento e dos servidores NMS confiados e obstrui todos pacotes ICMP restantes:

!

ip access-list extended ACL-INFRASTRUCTURE-IN
!
!--- Permit ICMP Echo (ping) from trusted management stations and servers
!

 permit icmp host <trusted-management-stations> any echo
 permit icmp host <trusted-netmgmt-servers> any echo
!
!--- Deny all other IP traffic to any network device
!

 deny ip any <infrastructure-address-space> <mask>
!
!--- Permit transit traffic
!

 permit ip any any
!

Filtre fragmentos IP

O processo de filtragem para pacotes IP fragmentados pode ser um desafio para os dispositivos de segurança. Isso ocorre porque as informações da Camada 4 usadas para filtrar pacotes TCP e UDP estão presentes apenas no fragmento inicial. O Cisco IOS Software usa um método específico para verificar fragmentos não iniciais contra a lista do acesso configurado. O software Cisco IOS avalia esses fragmentos não iniciais em relação à ACL e ignora qualquer informação filtrada da Camada 4. Isso faz com que os fragmentos não iniciais sejam avaliados somente na parte da camada 3 de qualquer entrada configurada. 

Nesta configuração de exemplo, se um pacote TCP destinado a 192.168.1.1 na porta 22 estiver fragmentado em trânsito, o fragmento inicial será descartado como esperado pela segunda ACE, com base nas informações da Camada 4 dentro do pacote. No entanto, todos os fragmentos (não iniciais) que permanecem são permitidos pela primeira ACE, com base completamente nas informações de Camada 3 no pacote e na ACE. Este cenário é mostrada nesta configuração:

!

ip access-list extended ACL-FRAGMENT-EXAMPLE
 permit tcp any host 192.168.1.1 eq 80
 deny tcp any host 192.168.1.1 eq 22
!

Devido à natureza não intuitiva do fragmento que segura, os fragmentos IP frequentemente são permitidos inadvertidamente por ACL. A fragmentação é frequentemente usada em tentativas de escapar da detecção por sistemas de detecção de intrusão. Por esses motivos, os fragmentos IP são frequentemente usados em ataques e por que eles devem ser explicitamente filtrados na parte superior de qualquer iACL configurado. Este exemplo de ACL inclui filtragem abrangente de fragmentos IP. A funcionalidade deste exemplo deve ser usada com a funcionalidade dos exemplos anteriores.

!

ip access-list extended ACL-INFRASTRUCTURE-IN
!
!--- Deny IP fragments using protocol-specific ACEs to aid in
!--- classification of attack traffic
!

 deny tcp any any fragments
 deny udp any any fragments
 deny icmp any any fragments
 deny ip any any fragments
!
!--- Deny all other IP traffic to any network device
!

 deny ip any <infrastructure-address-space> <mask>
!
!--- Permit transit traffic
!

 permit ip any any
!

Consulte Listas de controle de acesso e fragmentos IP para obter mais informações sobre como a ACL lida com pacotes IP fragmentados.

Suporte ACL para filtrar opções IP

O Cisco IOS Software Release 12.3(4)T adicionou suporte para o uso de ACLs para filtrar pacotes IP, com base nas opções IP contidas no pacote. As opções IP apresentam um desafio da segurança para dispositivos de rede porque estas opções devem ser processadas como pacotes da exceção. Isso requer um nível de esforço da CPU não exigido para pacotes típicos que atravessam a rede. A presença de opções IP dentro de um pacote também pode indicar uma tentativa de subverter os controles de segurança na rede ou de alterar as características de trânsito de um pacote. Por esses motivos, os pacotes com opções IP devem ser filtrados na borda da rede.

Este exemplo deve ser usado com as ACEs de exemplos anteriores para incluir a filtragem completa de pacotes IP que contêm opções IP:

!

ip access-list extended ACL-INFRASTRUCTURE-IN
!
!--- Deny IP packets containing IP options
!

 deny ip any any option any-options
!
!--- Deny all other IP traffic to any network device
!

 deny ip any <infrastructure-address-space> <mask>
!
!--- Permit transit traffic
!

 permit ip any any
!

Suporte à ACL para filtrar o valor TTL

O Cisco IOS Software Release 12.4(2)T adicionou um filtro de suporte ACL de pacotes IP, com base no valor Time to Live (TTL). O valor TTL de um IP datagrams é decrescido por cada dispositivo de rede como fluxos de pacote de informação da fonte ao destino. Embora os valores iniciais variem de acordo com o sistema operacional, quando o TTL de um pacote chega a zero, o pacote deve ser descartado. O dispositivo que decresce o TTL a zero, e deixa cair conseqüentemente o pacote, é exigido para gerar e enviar um Time Exceeded Message ICMP à fonte do pacote.

A geração e a transmissão destas mensagens são um processo da exceção. Os roteadores podem executar essa função quando o número de pacotes IP que vão expirar for baixo, mas se o número de pacotes que vão expirar for alto, a geração e a transmissão dessas mensagens podem consumir todos os recursos de CPU disponíveis. Isto apresenta um vetor do ataque DoS. Por esse motivo, os dispositivos precisam ser reforçados contra ataques DoS que usam uma alta taxa de pacotes IP, que estão prestes a expirar.

Recomenda-se que as organizações filtrem os pacotes IP com baixos valores TTL na borda da rede. A filtragem completa de pacotes com valores TTL insuficientes para atravessar a rede atenua a ameaça de ataques baseados em TTL.

Este exemplo ACL filtra pacotes com valores TTL menores de seis. Isto fornece a proteção contra ataques da expiração TTL para redes de até cinco saltos na largura.

!

ip access-list extended ACL-INFRASTRUCTURE-IN
!
!--- Deny IP packets with TTL values insufficient to traverse the network
!

 deny ip any any ttl lt 6
!
!--- Deny all other IP traffic to any network device
!

 deny ip any <infrastructure-address-space> <mask>
!
!--- Permit transit traffic
!

 permit ip any any
!

Observação: Alguns protocolos fazem uso legítimo de pacotes com valores TTL baixos. O eBGP é um desses protocolos. Consulte Identificação e mitigação do ataque de expiração TTL para obter mais informações para mitigar ataques baseados em expiração TTL.

Proteger as sessões interativas de gerenciamento

As sessões de gerenciamento para dispositivos oferecem a capacidade de visualizar e coletar informações sobre um dispositivo e suas operações. Se essas informações forem divulgadas a um usuário mal-intencionado, o dispositivo poderá se tornar alvo de um ataque, ser comprometido e usado para realizar ataques adicionais. Qualquer um com acesso de privilegiado a um dispositivo tem a capacidade para o controle administrativo completo desse dispositivo. É essencial proteger as sessões de gerenciamento para evitar a divulgação de informações e o acesso não autorizado.

Proteção do plano de gerenciamento

No Cisco IOS Software Release 12.4(6)T e posterior, o recurso Management Plane Protection (MPP) permite que um administrador imponha restrições em diferentes interfaces para o tráfego de gerenciamento que é recebido por um dispositivo. Isto permite ao administrador o controle adicional sobre um dispositivo e como o dispositivo é alcançado.

Este exemplo mostra como permitir a PMP (produção máxima possível) de permitir somente o SSH e o HTTPS na relação GigabitEthernet0/1:

!

control-plane host
  management-interface GigabitEthernet 0/1 allow ssh https
!

Refira a proteção do plano de gerenciamento para obter mais informações sobre da PMP (produção máxima possível).

Observação: o MPP não suporta IPv6 e é restrito ao caminho de entrada IPv4. Como o IPv6 não é filtrado, use CoPP em ambientes IPv4/IPv6 mistos.

Controle a proteção plana

A Proteção do Plano de Controle (CPPr - Control Plane Protection) baseia-se na funcionalidade da Política do Plano de Controle para restringir e policiar o tráfego plano de controle que é destinado ao processador de rota do dispositivo IOS Cisco. Adicionado no Cisco IOS Software Release 12.4(4)T, o CPPr divide o plano de controle em categorias separadas de plano de controle, conhecidas como subinterfaces. Existem três subinterfaces de plano de controle: Host, Trânsito e CEF-Exceção. Além disso, o CPPr inclui os seguintes recursos de proteção do plano de controle:

• Recurso de filtragem de portas - Permite que o administrador policie ou descarte pacotes que vão para portas TCP e UDP fechadas ou que não estão escutando.
  
  
• Recurso de política de limite de fila - Limita o número de pacotes para um protocolo especificado permitido na fila de entrada IP do plano de controle.

O CPPr permite que um administrador classifique, policie e restrinja o tráfego enviado a um dispositivo para fins de gerenciamento com a subinterface do host. Exemplos de pacotes classificados para a categoria de subinterface de host incluem tráfego de gerenciamento, como SSH ou Telnet e protocolos de roteamento.

Observação: CPPr não suporta IPv6 e é restrito ao caminho de entrada IPv4.

Refira o guia dos recursos de proteção do plano do controle - 12.4T e compreensão da proteção plana do controle para obter mais informações sobre da característica de Cisco CPPr.

Criptografar as sessões de gerenciamento

Como as informações podem ser divulgadas em uma sessão de gerenciamento interativa, esse tráfego deve ser criptografado para que um usuário mal-intencionado não possa obter acesso aos dados transmitidos. A criptografia de tráfego permite uma conexão segura de acesso remoto com o dispositivo. Se o tráfego para uma sessão de gerenciamento é enviado sobre a rede na minuta, um atacante pode obter informações sensíveis sobre o dispositivo e a rede.

Um administrador pode estabelecer uma conexão de gerenciamento de acesso remoto criptografada e segura com um dispositivo usando os recursos SSH ou HTTPS (Secure Hypertext Transfer Protocol). O software Cisco IOS é compatível com o SSH versão 1.0 (SSHv1), SSH versão 2.0 (SSHv2) e HTTPS que usa o Secure Sockets Layer (SSL) e o Transport Layer Security (TLS) para autenticação e criptografia de dados. SSHv1 e SSHv2 não são compatíveis. O SSHv1 é inseguro e não padronizado, por isso não é recomendado usá-lo se o SSHv2 for uma opção.

O software Cisco IOS também suporta o Secure Copy Protocol (SCP), que permite uma conexão criptografada e segura para copiar configurações de dispositivos ou imagens de software. O SCP confia no SSH. Este exemplo de configuração permite o SSH em um dispositivo IOS Cisco:

!

ip domain-name example.com
!

crypto key generate rsa modulus 2048
!

ip ssh time-out 60
ip ssh authentication-retries 3
ip ssh source-interface GigabitEthernet 0/1
!

line vty 0 4
 transport input ssh
!

Este exemplo de configuração permite serviços SCP:

!

ip scp server enable
!

Este exemplo de configuração é para serviços HTTPS:

!

crypto key generate rsa modulus 2048
!

ip http secure-server
!

Refira o Configuring Secure Shell em routeres e em Cisco IOS running de Switches e o Secure Shell (SSH) FAQ para obter mais informações sobre a característica do Cisco IOS Software SSH.

SSHv2

O recurso de suporte SSHv2, introduzido no Cisco IOS Software Release 12.3(4)T, permite que um usuário configure SSHv2. (O suporte a SSHv1 foi implementado em uma versão anterior do software Cisco IOS.) O SSH é executado sobre uma camada de transporte confiável e oferece recursos eficazes de autenticação e criptografia. O único transporte confiável definido para SSH é o TCP. O SSH fornece uma maneira segura de acessar e executar comandos em outro computador ou dispositivo em uma rede. O recurso Secure Copy Protocol (SCP) encapsulado sobre SSH permite a transferência segura de arquivos.

Se o comando ip ssh version 2 não estiver explicitamente configurado, o Cisco IOS ativará a versão 1.99 do SSH. O SSH versão 1.99 permite as conexões SSHv1 e SSHv2. O SSHv1 é considerado inseguro e pode ter efeitos adversos no sistema. Se o SSH estiver habilitado, é recomendável desabilitar o SSHv1 usando o comando ip ssh version 2.

Este exemplo de configuração ativa o SSHv2 (com o SSHv1 desativado) em um dispositivo Cisco IOS:

!
    
hostname router

!

ip domain-name example.com    

!
    
crypto key generate rsa modulus 2048

!

ip ssh time-out 60  
ip ssh authentication-retries 3  
ip ssh source-interface GigabitEthernet 0/1    

!
    
ip ssh version 2

!

line vty 0 4   
transport input ssh    

!
 

Refira o apoio da versão 2 do Secure Shell para obter mais informações sobre do uso de SSHv2.

Realces SSHv2 para chaves RSA

O Cisco IOS SSHv2 suporta teclados-interativos e de métodos de autenticação baseada em senha. Os realces SSHv2 para a característica de chaves RSA igualmente apoiam a autenticação da chave pública dos RSA-estabelecimentos de bases para o cliente e servidor.

Para a autenticação de usuário, a autenticação baseada em RSA usa pares associados privado/chave pública associada com cada usuário para a autenticação. O usuário deve gerar um par privado/chave pública no cliente e configurar uma chave pública no servidor de SSH do Cisco IOS para terminar a autenticação.

Um usuário SSH que tenta estabelecer as credenciais fornece uma assinatura criptografada com a chave privada. A assinatura criptografada e a chave pública do usuário são enviadas ao servidor SSH para autenticação. O servidor de SSH computa uma mistura sobre a chave pública fornecida pelo usuário. O hash é usado para determinar se o servidor tem uma entrada correspondente. Se uma correspondência for encontrada, a verificação de mensagem baseada em RSA será realizada com a chave pública. Daqui, o usuário é autenticado ou o acesso negado é baseado na assinatura criptografada.

Para a autenticação de servidor, o cliente SSH do Cisco IOS deve atribuir uma chave Host para cada servidor. Quando o cliente tenta estabelecer uma sessão SSH com um servidor, recebe a assinatura do server como parte da mensagem das trocas de chave. Se o indicador de verificação de chave de host estrito estiver habilitado no cliente, o cliente verificará se tem a entrada de chave de host que corresponde ao servidor pré-configurado. Se uma correspondência for encontrada, o cliente tentará validar a assinatura com a chave de host do servidor. Se o servidor for autenticado com êxito, o estabelecimento da sessão continuará; caso contrário, ele será encerrado e exibirá uma mensagem de Falha na Autenticação do Servidor.

Este exemplo de configuração permite o uso de chaves RSA com o SSHv2 em um dispositivo Cisco IOS:

!
! Configure a hostname for the device
!

hostname router
!
! Configure a domain name
!

ip domain-name cisco.com
!
! Specify the name of the RSA key pair (in this case, "sshkeys") to use for SSH
!

 ip ssh rsa keypair-name sshkeys
!
! Enable the SSH server for local and remote authentication on the router using 
! the "crypto key generate" command
! For SSH version 2, the modulus size must be at least 768 bits 
!

 crypto key generate rsa usage-keys label sshkeys modulus 2048
!
! Configure an ssh timeout (in seconds) 
!
! The following enables a timeout of 120 seconds for SSH connections
!

ip ssh time-out 120
!
! Configure a limit of five (5) authentication retries
!

ip ssh authentication-retries 5
!
! Configure SSH version 2
!

ip ssh version 2 
!

  

Refira a realces da versão 2 do Secure Shell para chaves RSA para mais informações sobre do uso de chaves RSA com SSHv2.

Este exemplo de configuração permite que o servidor SSH do Cisco IOS realize a autenticação de usuário baseada em RSA. A autenticação de usuário é bem sucedida se a chave pública RSA armazenada no servidor é verificada com os pares de chave públicos ou privados armazenado no cliente.

!
! Configure a hostname for the device
!

hostname router
!
! Configure a domain name
!

ip domain-name cisco.com
!
! Generate RSA key pairs using a modulus of 2048 bits
!

crypto key generate rsa modulus 2048
!
! Configure SSH-RSA keys for user and server authentication on the SSH server
!

ip ssh pubkey-chain
!
! Configure the SSH username
!

        username ssh-user
!
! Specify the RSA public key of the remote peer
!
! You must then configure either the key-string command
! (followed by the RSA public key of the remote peer) or the 
! key-hash command (followed by the SSH key type and version.)
!

Refira a configurar o servidor de SSH do Cisco IOS para executar a autenticação baseados na RSA para obter mais informações sobre do uso de chaves RSA com o SSHv2.

Este exemplo de configuração permite que o cliente SSH do Cisco IOS realize a autenticação de servidor baseada em RSA.

!
!

hostname router
!
ip domain-name cisco.c
!
! Generate RSA key pairs
!

crypto key generate rsa
!
! Configure SSH-RSA keys for user and server authentication on the SSH server
!

ip ssh pubkey-chain
!
! Enable the SSH server for public-key authentication on the router 
!

        server SSH-server-name
!
! Specify the RSA public-key of the remote peer 
!
! You must then configure either the key-string command
! (followed by the RSA public key of the remote peer) or the 
! key-hash <key-type> <key-name> command (followed by the SSH key 
! type and version.)
!
! Ensure that server authentication takes place - The connection will be 
! terminated on a failure
!

ip ssh stricthostkeycheck 
!

Refira configurar o cliente SSH do Cisco IOS para executar a autenticação de servidor dos RSA-Estabelecimentos de bases para obter mais informações sobre do uso de chaves RSA com o SSHv2.

Console e Portas AUX

Nos dispositivos IOS Cisco, o console e as portas auxiliares (AUX) são as linhas assíncronas que podem ser usadas para o acesso local e remoto a um dispositivo. Esteja ciente de que as portas de console nos dispositivos Cisco IOS têm privilégios especiais. Em particular, estes privilégios permitem que um administrador execute o procedimento de recuperação de senha. Para executar a recuperação de senha, um invasor não autenticado precisaria de acesso à porta de console e da capacidade de interromper a alimentação do dispositivo ou fazer com que o dispositivo falhe.

Qualquer método usado para acessar a porta de console de um dispositivo deve ser protegido de forma que seja igual à segurança imposta para acesso privilegiado a um dispositivo. Os métodos usados para proteger o acesso devem incluir o uso de AAA, exec-timeout e senhas de modem (se um modem estiver conectado ao console).

Se a recuperação de senha não for necessária, um administrador pode remover a capacidade de executar o procedimento de recuperação de senha através do comando de configuração global no service password-recovery; no entanto, uma vez que o comando no service password-recovery tenha sido habilitado, um administrador não pode executar a recuperação de senha em um dispositivo.

Na maioria das situações, a porta AUX do dispositivo deve ser desativada para impedir o acesso não autorizado. Uma porta AUX pode ser desativada com estes comandos:

!

line aux 0
 transport input none
 transport output none
 no exec
 exec-timeout 0 1
 no password
!

Control vty e tty Lines

As sessões de gerenciamento interativas no Cisco IOS Software usam um tty ou o tty virtual (vty). Um tty é uma linha assíncrona local a que um terminal pode ser anexado para o acesso local ao dispositivo ou a um modem para o acesso de discagem a um dispositivo. Note que os ttys podem ser usados para conexões às portas de Console dos outros dispositivos. Esta função permite que um dispositivo com linhas tty atue como um servidor de console onde as conexões possam ser estabelecidas através da rede às portas de Console de dispositivo conectadas às linhas tty. As linhas tty para estas conexões reversas sobre a rede devem igualmente ser controladas.

Uma linha vty é usada para todas conexões restantes da rede remota apoiadas pelo dispositivo, apesar do protocolo (o SSH, o SCP, ou o telnet são exemplos). Para garantir que um dispositivo possa ser acessado por uma sessão de gerenciamento local ou remota, os controles apropriados devem ser aplicados nas linhas vty e tty. Os dispositivos Cisco IOS têm um número limitado de linhas vty; o número de linhas disponíveis pode ser determinado com o comando EXEC show line. Quando todas as linhas vty estão em uso, novas sessões de gerenciamento não podem ser estabelecidas, o que pode criar uma condição DoS para acesso ao dispositivo.

O controle de acesso mais simples para um vty ou tty de um dispositivo é através do uso de autenticação em todas as linhas, independentemente da localização do dispositivo na rede. Isso é crítico para linhas vty porque elas são acessíveis pela rede. Uma linha tty conectada a um modem que é usado para acesso remoto ao dispositivo, ou uma linha tty conectada à porta de console de outros dispositivos também é acessível pela rede. Outras formas de controles de acesso vty e tty podem ser aplicadas com os comandos transport input ou access-class, com o uso dos recursos CoPP e CPPr, ou se você aplicar listas de acesso às interfaces no dispositivo.

A autenticação pode ser aplicada com o uso de AAA, que é o método recomendado para acesso autenticado a um dispositivo, com o uso do banco de dados de usuário local, ou por autenticação de senha simples configurada diretamente na linha vty ou tty.

O comando exec-timeout deve ser usado para sessões de logout em linhas vty ou tty que estejam inativas. O comando service tcp-keepalives-in também deve ser usado para ativar keepalives TCP em conexões de entrada para o dispositivo. Isso garante que o dispositivo na extremidade remota da conexão ainda esteja acessível e que as conexões semiabertas ou órfãs sejam removidas do dispositivo Cisco IOS local.

Controle o transporte para linhas vty e tty

Configure um vty e um tty para aceitar apenas conexões de gerenciamento de acesso remoto criptografadas e seguras para o dispositivo ou através do dispositivo se ele for usado como um servidor de console. Esta seção endereça ttys porque tais linhas podem ser conectadas às portas de Console nos outros dispositivos, que permitem que o tty seja acessível sobre a rede. Para evitar a divulgação de informações ou o acesso não autorizado aos dados transmitidos entre o administrador e o dispositivo, use transport input ssh em vez de protocolos de texto claro, como Telnet e rlogin. A configuração transport input none pode ser habilitada em um tty, que desabilita o uso da linha tty para conexões de console reverso.

As linhas vty e tty permitem que um administrador conecte aos outros dispositivos. Para limitar o tipo de transporte que um administrador pode usar para conexões de saída, use o comando de configuração de linha transport output. Se as conexões de saída não forem necessárias, use transport output none. No entanto, se as conexões de saída forem permitidas, aplique um método de acesso remoto criptografado e seguro para a conexão por meio do uso do SSH de saída de transporte.

Observação: o IPSec pode ser usado para conexões de acesso remoto criptografadas e seguras a um dispositivo, se suportado. Se você usa o IPSec, igualmente adiciona a carga adicional de CPU adicional ao dispositivo. No entanto, o SSH ainda deve ser aplicado como o transporte, mesmo quando o IPSec é usado.

Banners de advertência

Em algumas jurisdições legais, pode ser impossível processar e ilegal monitorar usuários mal-intencionados, a menos que eles tenham sido notificados de que não têm permissão para usar o sistema. Um método para fornecer essa notificação é colocar essas informações em uma mensagem de banner configurada com o comando banner login do software Cisco IOS.

Os requisitos de notificação legal são complexos, variam de acordo com a jurisdição e a situação e exigem discussão com o advogado. Mesmo dentro das jurisdições, as opiniões legais podem diferir. Em cooperação com o advogado, um banner pode fornecer algumas ou todas essas informações:

• Observe que o sistema deve ser registrado em ou usada especificamente somente por pessoais autorizados e talvez por informação sobre quem pode autorizar o uso.
  
  
• Observe que toda a utilização não autorizada do sistema é ilegal e pode ser sujeita a civil e às penalidades criminal.
  
  
• Observe que qualquer uso do sistema pode ser registrado ou monitorado sem aviso prévio e que os registros resultantes podem ser usados como evidência em tribunal.
  
  
• Observações específicas exigidas por leis local.

Do ponto de vista da segurança, e não do ponto de vista legal, um banner de login não deve conter nenhuma informação específica sobre o nome, o modelo, o software ou a propriedade do roteador. Esta informação pode ser abusada por usuários maliciosos.

Autenticação, autorização e contabilidade

A estrutura de Autenticação, Autorização e Contabilização (AAA - Authentication, Authorization, and Accounting) é essencial para proteger o acesso interativo a dispositivos de rede. A estrutura AAA fornece um ambiente altamente configurável que pode ser adaptado, com base nas necessidades da rede.

Autenticação TACACS+

O TACACS+ é um protocolo de autenticação que os dispositivos Cisco IOS podem usar para autenticação de usuários de gerenciamento contra um servidor AAA remoto. Esses usuários de gerenciamento podem acessar o dispositivo IOS Cisco por SSH, HTTPS, telnet ou HTTP.

A autenticação TACACS+, ou mais geralmente a autenticação de AAA, fornecem a capacidade para usar o usuário individual esclarecem cada administrador de rede. Quando você não depende de uma única senha compartilhada, a segurança da rede é aumentada e sua responsabilidade é reforçada.

O RADIUS é um protocolo semelhante em propósito ao TACACS+; no entanto, ele somente criptografa a senha enviada pela rede. Por outro lado, o TACACS+ criptografa toda a carga TCP, que inclui o nome de usuário e a senha. Por esse motivo, use TACACS+ em vez de RADIUS quando TACACS+ for suportado pelo servidor AAA. Refira a comparação de TACACS+ e RADIUS para uma comparação mais detalhada destes dois protocolos.

A autenticação TACACS+ pode ser ativada em um dispositivo Cisco IOS com uma configuração semelhante a este exemplo:

!

aaa new-model
aaa authentication login default group tacacs+
!

tacacs-server host <ip-address-of-tacacs-server>
tacacs-server key <key>
!

A configuração anterior pode ser usada como o ponto inicial para um modelo de autenticação AAA específico da organização. 

Uma lista de métodos é uma lista sequencial que descreve os métodos de autenticação a serem consultados para autenticar um usuário. As listas de métodos permitem designar um ou mais protocolos de segurança a serem usados para autenticação e, assim, garantir um sistema de backup para autenticação se o método inicial falhar. O software Cisco IOS usa o primeiro método listado que aceita ou rejeita um usuário com êxito. Os métodos subsequentes são tentados somente se os métodos anteriores falharem devido à indisponibilidade do servidor ou à configuração incorreta.

Reserva da autenticação

Se todos os servidores configurados TACACS+ se tornam não disponíveis, a seguir um dispositivo IOS Cisco pode confiar em protocolos da autenticação secundária. As configurações típicas incluem o uso do local ou permitem a autenticação se todos os server configurados TACACS+ são não disponíveis.

A lista completa das opções para a autenticação do em-dispositivo inclui permite, local, e linha. Cada opção tem suas vantagens. O uso do enable secret é preferível porque o segredo é misturado com um algoritmo unidirecional que é inerentemente mais seguro do que o algoritmo de criptografia usado com as senhas Tipo 7 para a linha ou autenticação local.

Contudo, nos Cisco IOS Software Release que suportam o uso das senhas secundárias para usuários localmente definidos, a reserva à autenticação local pode ser desejável. Isso permite que um usuário definido localmente seja criado para um ou mais administradores de rede. Se o TACACS+ estava completamente indisponível, cada administrador pode usar seu nome de usuário e senha locais. Embora essa ação reforce a responsabilidade dos administradores de rede em interrupções do TACACS+, ela aumenta significativamente a carga administrativa, pois as contas de usuário local em todos os dispositivos de rede devem ser mantidas.

Este exemplo de configuração baseia-se no exemplo de autenticação TACACS+ anterior para incluir a autenticação de retorno para a senha configurada localmente com o enable secret comando:

!

enable secret <password>
!

aaa new-model
aaa authentication login default group tacacs+ enable
!

tacacs-server host <ip-address-of-tacacs-server>
tacacs-server key <key>
!

Uso de senhas tipo 7

Originalmente designado para permitir a decifração rápida de senhas armazenadas, senhas tipo 7 não são um formulário seguro do armazenamento de senha. Há muitas ferramentas disponíveis para descriptografar essas senhas com facilidade. Evite o uso de senhas Tipo 7, a menos que seja exigido por um recurso em uso no dispositivo IOS Cisco.

Use o tipo 9 (criptografar) sempre que possível:

username <username> privilege 15 algorithm-type scrypt secret <secret>

A remoção de senhas desse tipo pode ser realizada pela autenticação AAA e pelo uso do recurso Enhanced Password Security, que permite que senhas secretas sejam usadas com usuários definidos localmente pelo comando de configuração username global. Se você não pode prevenir completamente uso de senhas tipo 7, considere estas senhas confundidas, não cifradas.

Para obter mais informações sobre a remoção de senhas Tipo 7, consulte a seção Endurecimento do plano de gerenciamento geral.

Autorização do comando TACACS+

O comando authorization com TACACS+ e AAA fornece um mecanismo que permita ou nega cada comando que é incorporado por um usuário administrativo. Quando o usuário inscreve comandos EXEC, o Cisco IOS envia cada comando ao servidor AAA configurado. O servidor AAA usa suas políticas configuradas para permitir ou negar o comando para esse usuário específico.

Esta configuração pode ser adicionada ao exemplo de autenticação AAA anterior para implementar a autorização do comando:

!

aaa authorization exec default group tacacs none
aaa authorization commands 0 default group tacacs none
aaa authorization commands 1 default group tacacs none 
aaa authorization commands 15 default group tacacs none
!

Contabilidade do comando TACACS+

Quando configurado, o relatório de comando AAA envia informações sobre cada comando EXEC inserido para os servidores TACACS+ configurados. As informações enviadas ao servidor TACACS+ incluem o comando executado, a data em que ele foi executado e o nome de usuário de quem inseriu o comando. A contabilização do comando não é compatível com o RADIUS.

Este exemplo de configuração permite o comando aaa que esclarece os comandos EXEC inscritos nos níveis de privilégio zero, um, e 15. Essa configuração se baseia em exemplos anteriores que incluem a configuração dos servidores TACACS.

!

aaa accounting exec default start-stop group tacacs 
aaa accounting commands 0 default start-stop group tacacs
aaa accounting commands 1 default start-stop group tacacs
aaa accounting commands 15 default start-stop group tacacs
!

Servidores AAA redundantes

Os servidores AAA que são aproveitados em um ambiente podem ser redundantes e implantados de maneira tolerante a falhas. Isto ajuda a assegurar-se de que o acesso de gerenciamento interativo, tal como o SSH, seja possível se um servidor AAA é não disponível.

Ao projetar ou implementar uma solução de servidor AAA redundante, lembre-se destas considerações:

• Disponibilidade de servidores AAA no momento de possíveis falhas de rede
  
  
• Colocação geográfica dispersada dos servidores AAA
  
  
• Carregar em servidores AAA individuais em condições de estado estacionário e de falha
  
  
• Latência da rede entre servidores do acesso de rede e servidores AAA
  
  
• Sincronização das bases de dados do servidor AAA

Consulte para distribuir os server do controle de acesso para mais informação.

Fortalecer o Simple Network Management Protocol

Esta seção destaca vários métodos que podem ser usados para proteger a implantação de SNMP em dispositivos Cisco IOS. É essencial que o SNMP seja protegido adequadamente para proteger a confidencialidade, a integridade e a disponibilidade dos dados da rede e dos dispositivos de rede através dos quais os dados transitam. O SNMP fornece uma grande quantidade de informações sobre a integridade dos dispositivos de rede. Proteja essas informações de usuários mal-intencionados que desejam aproveitar esses dados para realizar ataques contra a rede.

Strings de comunidade SNMP

As strings de comunidade são senhas aplicadas a um dispositivo IOS Cisco para restringir o acesso, somente leitura e leitura-gravação, aos dados SNMP no dispositivo. Essas strings de comunidade, como todas as senhas, são cuidadosamente escolhidas para garantir que não sejam triviais. Altere as strings de comunidade em intervalos regulares e de acordo com as políticas de segurança de rede. Por exemplo, altere as cadeias de caracteres quando um administrador de rede alterar funções ou sair da empresa.

Estas linhas de configuração configuram uma série de comunidade somente leitura e SOMENTE LEITURA e uma série de comunidade de leitura/gravação de DE LEITURA/GRAVAÇÃO:

!

snmp-server community READONLY RO
snmp-server community READWRITE RW  
!

Observação: os exemplos de string de comunidade anteriores foram escolhidos para explicar claramente o uso dessas strings. Para ambientes de produção, escolha as strings de comunidade com cuidado e inclua uma série de símbolos alfabéticos, numéricos e não alfanuméricos. 

Consulte Referência de Comandos SNMP do Cisco IOS para obter mais informações sobre este recurso.

Séries de comunidade snmp com ACL

Além da string de comunidade, aplique uma ACL que restrinja ainda mais o acesso SNMP a um grupo selecionado de endereços IP de origem. Esta configuração restringe o acesso somente leitura SNMP aos dispositivos do host final que residem no espaço de endereços 192.168.100.0/24 e restringe o acesso de leitura/gravação SNMP somente ao dispositivo do host final em 192.168.100.1.

Observação: os dispositivos permitidos por essas ACLs exigem a sequência de comunidade apropriada para acessar as informações SNMP solicitadas.

!

access-list 98 permit 192.168.100.0 0.0.0.255
access-list 99 permit 192.168.100.1
!

snmp-server community READONLY RO 98
snmp-server community READWRITE RW 99
!

Consulte snmp-server community na Referência de comandos de gerenciamento de rede do Cisco IOS para obter mais informações sobre esse recurso.

Infra-estrutura ACL

As ACLs de infraestrutura (iACLs) podem ser implantadas para garantir que somente os hosts finais com endereços IP confiáveis possam enviar o tráfego SNMP para um dispositivo IOS Cisco. Idealmente, um iACL contém uma política que nega pacotes SNMP não autorizados na porta UDP 161.

Veja a seção Limiting Access to the Network with Infrastrucutre ACLs deste documento para mais informações no uso de iACLs.

SNMP Views

Os SNMP Views são uns recursos de segurança que possam permitir ou negar o acesso a determinado SNMP MIB. Uma vez que uma vista está criada e aplicada a um string de comunidade com os comandos global configuration da comunidade snmp-server comunity-string view, se você alcança dados MIB, você está restringido às permissões que são definidas pela vista. Quando apropriado, use exibições para limitar os usuários do SNMP aos dados necessários.

Este exemplo de configuração restringe o acesso SNMP com o string de comunidade LIMITADO aos dados MIB que estão situados no grupo de sistema:

!

snmp-server view VIEW-SYSTEM-ONLY system include
!

snmp-server community LIMITED view VIEW-SYSTEM-ONLY RO
!

Refira aconfigurar o apoio SNMP para mais informação.

SNMP Versão 3

O SNMP versão 3 (SNMPv3) é definido pelo RFC3410 , pelo RFC3411 , pelo RFC3412 , pelo RFC3413 , pelo RFC3414 , e pelo RFC3415 e é um protocolo baseando em padrões interoperáveis para o gerenciamento de rede. O SNMPv3 fornece acesso seguro aos dispositivos, pois autentica e facultativamente criptografa pacotes na rede. Quando suportado, o SNMPv3 pode ser usado para adicionar outra camada de segurança ao implantar o SNMP. O SNMPv3 consiste em três opções de configuração preliminares:

• no auth - Este modo não requer nenhuma autenticação ou criptografia de pacotes SNMP
  
  
• auth – Este modo exige autenticação do pacote SNMP sem criptografia
  
  
• priv – Este modo exige autenticação e criptografia (privacidade) de cada pacote SNMP

Deve existir um ID de mecanismo autoritativo para usar os mecanismos de segurança SNMPv3 - autenticação ou autenticação e criptografia - para manipular pacotes SNMP; por padrão, o ID do mecanismo é gerado localmente. O ID do mecanismo pode ser exibido com o show snmp engineID comando como mostrado neste exemplo:

router#show snmp engineID 
   Local SNMP engineID: 80000009030000152BD35496
   Remote Engine ID          IP-addr    Port

Observação: se o engineID for alterado, todas as contas de usuário SNMP deverão ser reconfiguradas.

A próxima etapa é configurar um grupo SNMPv3. Este comando configura um dispositivo Cisco IOS para SNMPv3 com um grupo de servidores SNMP AUTHGROUP e permite somente a autenticação para este grupo com a palavra-chave auth:

!
snmp-server group AUTHGROUP v3 auth
!

Este comando configura um dispositivo Cisco IOS para SNMPv3 com um grupo de servidores SNMP PRIVGROUP e permite a autenticação e a criptografia para este grupo com a palavra-chave priv:

!
snmp-server group PRIVGROUP v3 priv
!

Este comando configura um usuário SNMPv3 snmpv3user com uma senha de autenticação MD5 authpassword e uma senha de criptografia 3DES de privpassword:

!

snmp-server user snmpv3user PRIVGROUP v3 auth md5 authpassword priv 3des 
     privpassword
!

Saiba que snmp-server user os comandos de configuração não são exibidos na saída de configuração do dispositivo conforme exigido pelo RFC 3414. Conseqüentemente, a senha do usuário não é visualizável da configuração. Para exibir os usuários configurados, insira o show snmp user comando, conforme mostrado neste exemplo:

router#show snmp user 
User name: snmpv3user
Engine ID: 80000009030000152BD35496
storage-type: nonvolatile        active
Authentication Protocol: MD5
Privacy Protocol: 3DES
Group-name: PRIVGROUP

Refira a configurar o suporte SNMP para obter mais informações sobre desta característica.

Proteção do plano de gerenciamento

O recurso MPP (Management Plane Protection, Proteção do plano de gerenciamento) no software Cisco IOS pode ser usado para ajudar a proteger o SNMP, pois ele restringe as interfaces através das quais o tráfego SNMP pode terminar no dispositivo. A característica PMP (produção máxima possível) permite que um administrador designe umas ou várias relações como interfaces de gerenciamento. O tráfego de gerenciamento é permitido para entrar em um dispositivo somente através destas interfaces de gerenciamento. Depois que a PMP (produção máxima possível) é permitida, nenhumas relações a não ser que as interfaces de gerenciamento designadas aceitem o tráfego de gerenciamento de rede que é destinado ao dispositivo.

O MPP é um subconjunto do recurso CPPr e requer uma versão do Cisco IOS que suporte CPPr. Refira a compreendendo a proteção plana do controle para obter mais informações sobre de CPPr.

Neste exemplo, o MPP é usado para restringir o acesso SNMP e SSH somente à interface FastEthernet 0/0:

!
control-plane host
 management-interface FastEthernet0/0 allow ssh snmp 
!

Refira ao guia dos recursos de proteção do plano de gerenciamento para mais informação.

Melhores práticas de registo

Os registros de eventos fornecem visibilidade sobre a operação de um dispositivo IOS Cisco e a rede na qual ele está implantado. O software Cisco IOS fornece várias opções flexíveis de configuração de log do opm que podem ajudar a alcançar os objetivos de gerenciamento de rede e visibilidade de uma organização.

Estas seções fornecem algumas práticas recomendadas básicas de recursos de registro que podem ajudar um administrador a aproveitar as funções de registro com sucesso, com impacto mínimo sobre o recurso de registro em um dispositivo IOS Cisco.

Envie registros a um local central

É recomendado enviar informações de registro a um servidor syslog remoto. Isso possibilita a correlação e a auditoria de eventos de segurança e de rede entre dispositivos de rede com mais eficiência. Note que os mensagens do syslog estão transmitidos incerta pelo UDP e na minuta. Portanto, qualquer proteção que uma rede oferece ao tráfego de gerenciamento (por exemplo, criptografia ou acesso fora de banda) pode ser estendida para incluir o tráfego de syslog.

Este exemplo configura um dispositivo IOS Cisco para enviar informações de registro a um servidor syslog remoto:

!
logging host <ip-address>
!

Consulte Identificação de Incidentes Usando o Firewall e Eventos de Syslog do Roteador Cisco IOS para obter mais informações sobre correlação de logs.

Integrado no Cisco IOS 12.4(15)T e originalmente introduzido no 12.0(26)S, o recurso Logging to Local Nonvolatile Storage (ATA Disk) permite que as mensagens de registro do sistema sejam salvas em um disco flash ATA (advanced technology attachment). As mensagens salvas em uma movimentação ATA persistem depois que um roteador é recarregado.

Essas linhas de configuração configuram 134.217.728 bytes (128 MB) de mensagens de log para o diretório syslog da flash ATA (disk0), com um tamanho de arquivo especificado de 16.384 bytes:

logging buffered
logging persistent url disk0:/syslog size 134217728 filesize 16384

Antes que as mensagens de log sejam gravadas em um arquivo no disco ATA, o Cisco IOS Software verifica se há espaço suficiente em disco. Caso contrário, a mensagem do arquivo de log mais antigo (por timestamp) será excluída e o arquivo atual será salvo. O formato do nome de arquivo é log_month:day:year::time.

Observação: uma unidade flash ATA tem espaço em disco limitado e, portanto, precisa ser mantida para evitar a possibilidade de substituir os dados armazenados.

Este exemplo mostra como copiar mensagens de log do disco flash ATA do roteador para um disco externo no servidor FTP 192.168.1.129 como parte dos procedimentos de manutenção:

copy disk0:/syslog ftp://myuser/[email protected]/syslog

Refira o registo ao armazenamento permanente local (disco ATA) para obter mais informações sobre esta característica.

Nível de registro

A cada mensagem de registro gerada por um dispositivo IOS Cisco é atribuída uma das oito severidades que vão do nível 0, Emergências, até o nível 7, Depuração. A menos que seja especificamente solicitado, é recomendado evitar registros no nível 7. Os registros no nível 7 produzem uma carga de CPU elevada no dispositivo, o que pode levar à instabilidade do dispositivo e da rede.

O nível do comando de configuração global logging trap é usado para especificar quais mensagens de log são enviadas para servidores syslog remotos. O nível especificado indica a mais baixa mensagem da severidade que é enviada. Para logs em buffer, o comando logging buffered level é usado.

Este exemplo de configuração limita as mensagens de log enviadas aos servidores syslog remotos e o buffer de log local às severidades 6 (Informativo) a 0 (Emergências):

!

logging trap 6
logging buffered 6
!

Refira a pesquisa de defeitos, o gerenciamento de defeito, e o registo para mais informação.

Não registre para consolar ou sessões de monitor

Com o software Cisco IOS, é possível enviar mensagens de log para monitorar sessões, que são sessões de gerenciamento interativas nas quais o comando EXEC terminal monitor foi emitido, e para o console. No entanto, isso pode elevar a carga da CPU de um dispositivo IOS Cisco e, portanto, não é recomendado. Em vez disso, envie as informações de log para o buffer de log local que pode ser exibido com o show logging comando.

Use os comandos de configuração global no logging console e no logging monitor para desabilitar logs para o console e para monitorar sessões. Este exemplo de configuração mostra o uso destes comandos:

!

no logging console
no logging monitor
!

Refira a referência do comando management da rede de IOS Cisco para obter mais informações sobre dos comandos global configuration.

Usar Logs Armazenados em Buffer

O software Cisco IOS suporta o uso de um buffer de registro local para que um administrador possa visualizar mensagens de registro geradas localmente. O uso de registros armazenados em buffer é altamente recomendado em comparação com os registros do console ou das sessões do monitor.

Há duas opções de configuração relevantes quando você configura logs em buffer: o tamanho do buffer de log e a severidade da mensagem armazenada no buffer. O tamanho do logging buffer é configurado com o comando de configuração global logging buffered size. . A menor gravidade incluída no buffer é configurada com o comando log buffered severity. Um administrador pode exibir o conteúdo do buffer de registro por meio do comando EXECshow logging.

Este exemplo de configuração inclui a configuração de um buffer de registro de 16.384 bytes, bem como uma severidade de 6, Informativo, que indica que as mensagens nos níveis de 0 (Emergências) a 6 (Informativo) são armazenadas:

!

logging buffered 16384 6
!

Consulte a Referência de Comandos de Gerenciamento de Rede do Cisco IOS para obter mais informações sobre logs de buffer.

Configurar a interface de origem de registo

Para fornecer um nível maior de consistência ao coletar e revisar mensagens de log, é recomendável configurar estaticamente uma interface de origem de log. Isso é realizado pelo comando logging source-interface interface. Uma interface de origem de registro configurada estaticamente garante que o mesmo endereço IP apareça em todas as mensagens de registro enviadas de um dispositivo Cisco IOS individual. Para obter estabilidade adicional, use uma interface de loopback como origem de log.

Este exemplo de configuração ilustra o uso do comando de configuração global logging source-interface interface para especificar o endereço IP da interface loopback 0 a ser usado para todas as mensagens de log:

!
logging source-interface Loopback 0
!

Refira a referência do comando Cisco IOS para mais informação.

Configurar Carimbos de Data/Hora do Log

A configuração dos timestamps de log ajuda a correlacionar eventos entre dispositivos de rede. É importante implementar uma configuração de registro de data e hora de log correta e consistente para garantir que você possa correlacionar os dados de log. Configure os carimbos de data/hora do log para incluir a data e a hora, com precisão de milissegundos, e para incluir o fuso horário em uso no dispositivo.

Este exemplo inclui a configuração de timestamps de log, com precisão de milissegundos, dentro da zona UTC (Coordinated Universal Time):

!
service timestamps log datetime msec show-timezone
!

Se você prefere não registrar as épocas UTC relativas, você pode configurar um fuso horário local específico e configurá-lo que a informação esta presente na mensagens do log gerada. Este exemplo mostra uma configuração de dispositivo para a zona do horário padrão do pacífico (PST):

!

clock timezone PST -8
service timestamps log datetime msec localtime show-timezone
!

Gerenciamento de configuração do Cisco IOS Software

O software Cisco IOS inclui vários recursos para permitir uma forma de gerenciamento de configuração em um dispositivo Cisco IOS. Esses recursos incluem a funcionalidade de arquivar configurações e reverter a configuração para uma versão anterior, bem como criar um log de alteração de configuração detalhado.

Substituir configuração e configuração Rollback

No software Cisco IOS versão 12.3(7)T e posterior, os recursos Configuration Replace e Configuration Rollback permitem arquivar a configuração do dispositivo Cisco IOS no dispositivo. Armazenadas manual ou automaticamente, as configurações neste arquivo podem ser usadas para substituir a configuração atual em execução pelo comando configure replace filename. Isso contrasta com o comando copy filename running-config . O comando configure replace filename substitui a configuração de execução, ao contrário da mesclagem executada pelo copy comando.

Você é recomendado ativar esse recurso em todos os dispositivos Cisco IOS na rede. Uma vez ativado, um administrador pode fazer com que a configuração atual seja adicionada ao arquivo com o archive config EXEC comando. As configurações arquivadas podem ser visualizadas com o show archive EXEC comando.

Este exemplo ilustra a configuração para o arquivo de configuração automática. Este exemplo instrui o dispositivo IOS Cisco a armazenar configurações arquivadas como arquivos chamados archived-config-N no sistema de arquivos disk0:, manter um máximo de 14 backups e arquivar uma vez por dia (1440 minutos) quando um administrador emitir o write memory EXEC comando.

!

archive
 path disk0:archived-config
 maximum 14
 time-period 1440
 write-memory
!

Embora a função de arquivo de configuração possa armazenar até 14 configurações de backup, é recomendável considerar os requisitos de espaço antes de usar o maximum comando.

Configuração Exclusiva de Alteração de Acesso

Adicionado ao Cisco IOS Software Release 12.3(14)T, o recurso Exclusive Configuration Change Access garante que apenas um administrador faça alterações de configuração em um dispositivo Cisco IOS em um determinado momento. Esta característica ajuda a eliminar o impacto indesejado das mudanças simultâneas feitas aos componentes da configuração relacionada. configuration mode exclusive Esse recurso é configurado com o modo de comando de configuração global e opera em um dos dois modos: auto ou manual. No modo automático, a configuração trava automaticamente quando um administrador emite o configure terminal EXEC comando. No modo manual, o administrador usa o configure terminal lock comando para bloquear a configuração quando ela entra no modo de configuração.

Este exemplo ilustra a configuração desta característica para o travamento da configuração automática:

!
configuration mode exclusive auto
!

Configuração resiliente do Cisco IOS Software

Adicionado ao Cisco IOS Software Release 12.3(8)T, o recurso de Configuração Resiliente permite armazenar com segurança uma cópia da imagem do Cisco IOS Software e a configuração do dispositivo usada atualmente por um dispositivo Cisco IOS. Quando esta característica é permitida, não é possível alterar ou remover estes arquivos de backup. Você é recomendado permitir esta característica de impedir tentativas inadvertidas e maliciosas de suprimir destes arquivos.

!
secure boot-image
secure boot-config!

Uma vez que esta característica é permitida, é possível restaurar uma configuração ou uma imagem do Cisco IOS Software suprimida. O estado atual desse recurso pode ser exibido com o show secure boot EXEC comando.

Software Cisco assinado Digital

Adicionado no Cisco IOS Software Release 15.0(1)M para os Cisco 1900, 2900 e 3900 Series Routers, o recurso Digital Signed Cisco Software facilita o uso do Cisco IOS Software que é digitalmente assinado e, portanto, confiável, com o uso de criptografia assimétrica segura (chave pública).

Uma imagem digital assinada leva (com uma chave privada) uma mistura criptografada dse. Na verificação, o dispositivo descriptografa o hash com a chave pública associada das chaves que ele tem em seu armazenamento de chaves e também calcula seu próprio hash da imagem. Se a mistura decifrada combina a mistura calculada da imagem, a imagem não foi alterada e pode ser confiada.

As chaves Digitais do software Cisco são identificadas pelo tipo e pela versão da chave. Uma chave pode ser especial, uma produção, ou um tipo chave do derrubamento. Os tipos de chave especiais e de produção têm uma versão de chave associada que é incrementada alfabeticamente quando a chave é revogada e substituída. A imagem ROMMON e a imagem regular do Cisco IOS são assinadas com uma chave especial ou de produção quando você usa o recurso Digitally Signed Cisco Software. A imagem ROMMON pode ser atualizada e deve ser assinada com a mesma chave que a imagem especial ou de produção carregada.

Este comando verifica a integridade da imagem c3900-universalk9-mz.SSA na memória flash com as chaves no armazenamento de chaves do dispositivo:

show software authenticity file flash0:c3900-universalk9-mz.SSA

A característica Digital Assinada do software Cisco foi integrada igualmente na liberação 3.1.0.SG do Cisco IOS XE para a E-Série Switches do Cisco catalyst 4500.

Refira ao software Cisco Digital Assinado para obter mais informações sobre esta característica.

O recurso Key Replacement for Digitally Signed Cisco Software foi introduzido no software Cisco IOS versão 15.1(1)T e posterior. A substituição e a revogação de chaves substitui e remove uma chave usada para uma verificação do software Cisco assinado digitalmente do armazenamento de chaves da plataforma. Somente chaves especiais e da produção podem ser revogadas no caso de um acordo chave.

(Especial ou produção) uma chave nova para a imagem a (especial ou produção) vem na imagem a (produção ou revogação) que é usada para revogar a chave precedente do especial ou da produção. A integridade da imagem de revogação é verificada com uma chave de rollover fornecida na plataforma. Uma chave rollover não muda. Quando você revoga uma chave de produção, depois que a imagem de revogação é carregada, a nova chave que ela transporta é adicionada ao armazenamento de chaves e a chave antiga associada pode ser revogada, desde que a imagem ROMMON seja atualizada e a nova imagem de produção seja inicializada. Quando você revoga uma chave especial, uma imagem de produção é carregada. Esta imagem adiciona a chave especial nova e pode revogar a chave especial velha. Depois de atualizar a imagem ROMMON, a nova imagem especial pode ser inicializada.

Este exemplo descreve a revogação de uma chave especial. Esses comandos adicionam a nova chave especial ao armazenamento de chaves da imagem de produção atual, copiam uma nova imagem ROMMON (C3900_rom-monitor.srec.SSB) para a área de armazenamento (usbflash0:), atualizam o arquivo ROMMON e revogam a chave especial antiga:

software authenticity key add special
copy tftp://192.168.1.129/C3900_rom-monitor.srec.SSB usbflash0:
upgrade rom-monitor file usbflash0:C3900_PRIV_RM2.srec.SSB
software authenticity key revoke special

Uma nova imagem especial (c3900-universalk9-mz.SSB) pode ser copiada para a memória flash a ser carregada e a assinatura da imagem é verificada com a chave especial recém-adicionada (.SSB):

copy /verify tftp://192.168.1.129/c3900-universalk9-mz.SSB flash:

A revogação e a substituição de chaves não são compatíveis com os switches Catalyst 4500 E-Series que executam o software Cisco IOS XE, embora esses switches sejam compatíveis com o recurso Digitally Signed Cisco Software.

Refira a seção assinada Digital da revogação e da substituição da chave do software Cisco da guia Assinatura Digital do software Cisco para obter mais informações sobre esta característica.

Notificação e registo da alteração de configuração

A notificação e os recursos de registro da alteração de configuração, adicionados no Cisco IOS Software Release 12.3(4)T, tornam possível registrar as alterações de configuração feitas a um dispositivo IOS Cisco. O registro é mantido no dispositivo IOS Cisco e contém as informações de usuário do indivíduo que fez a alteração, o comando de configuração inserido e a hora em que a alteração foi feita. logging enable Essa funcionalidade é habilitada com o comando do modo de configuração do logger de alteração de configuração (configuration change logger). Os comandos hidekeys logging size e as entradas opcionais são usados para melhorar a configuração padrão, pois impedem logs de dados de senha e aumentam o comprimento do log de alteração.

Você é recomendado habilitar essa funcionalidade para que o histórico de alteração de configuração de um dispositivo IOS Cisco possa ser mais facilmente entendido. notify syslog Além disso, é recomendável usar o comando de configuração para habilitar a geração de mensagens de syslog quando uma alteração de configuração é feita.

!

archive
 log config
  logging enable
  logging size 200
  hidekeys
  notify syslog
!

Depois que o recurso Notificação e registro de alteração de configuração tiver sido habilitado, o comando EXEC privilegiado show archive log config all pode ser usado para visualizar o registro de configuração.

Controle o plano

As funções planas do controle consistem nos protocolos e nos processos que se comunicam entre dispositivos de rede para mover dados da fonte para o destino. Isso inclui protocolos de roteamento, como o Border Gateway Protocol, bem como protocolos como o ICMP e o Resource Reservation Protocol (RSVP).

É importante que os eventos nos planos da gestão e dos dados não afetem adversamente o plano do controle. Se um evento de plano de dados, como um ataque de DoS, impactar o plano de controle, toda a rede poderá se tornar instável. Esta informação sobre recursos do Cisco IOS Software e configurações pode ajudar a assegurar a superação do plano do controle.

Endurecimento plano do controle geral

A proteção do plano de controle de um dispositivo de rede é crítica porque o plano de controle garante que os planos de gerenciamento e de dados sejam mantidos e operacionais. Se o plano de controle se tornar instável durante um incidente de segurança, pode ser impossível recuperar a estabilidade da rede.

Em muitos casos, você pode desativar a recepção e a transmissão de certos tipos de mensagens em uma interface para minimizar a quantidade de carga de CPU necessária para processar pacotes desnecessários.

Redirecionamentos de IP ICMP

Uma mensagem do redirecionamento de ICMP pode ser gerada por um roteador quando um pacote é recebido e transmitido na mesma relação. Nesta situação, o roteador encaminha o pacote e envia uma mensagem do redirecionamento de ICMP de volta ao remetente do pacote original. Este comportamento permite que o remetente contorneie o roteador e encaminhe pacotes futuros diretamente ao destino (ou a um roteador mais perto do destino). Em uma rede IP de funcionamento correto, um roteador envia reorienta somente aos anfitriões em suas próprias sub-redes local. Em outras palavras, os redirecionamentos de ICMP normalmente nunca vão além de um limite de Camada 3.

Há dois tipos de mensagens de redirecionamento ICMP: redirecionar para um endereço de host e redirecionar para uma sub-rede inteira. Um usuário mal-intencionado pode explorar a capacidade do roteador de enviar redirecionamentos ICMP por transmissão contínua de pacotes ao roteador, o que força o roteador a responder com mensagens de redirecionamento ICMP e resulta em um impacto adverso na CPU e no desempenho do roteador. Para evitar que o roteador transmita redirecionamentos ICMP, use o comando de configuração de interfaceno ip redirects.

ICMP não alcançável

A filtragem com uma lista de acesso de interface provoca a transmissão de mensagens ICMP inalcançáveis de volta à origem do tráfego filtrado. A geração dessas mensagens pode aumentar o uso da CPU no dispositivo. Por padrão, no software Cisco IOS, a geração de ICMP inalcançável é limitada a um pacote a cada 500 milissegundos. A geração de mensagens inalcançáveis ICMP pode ser desativada com o comando de configuração de interface no ip unreachables. O limite de taxa inalcançável ICMP pode ser alterado do padrão com o comando de configuração global ip icmp rate-limit unreachable interval-in-ms.

Proxy ARP

O Proxy ARP é a técnica na qual um dispositivo, geralmente um roteador, responde às solicitações ARP destinadas a outro dispositivo. Por falsificação de sua identidade, o roteador aceita a responsabilidade de rotear pacotes para o destino real. O Proxy ARP pode ajudar as máquinas em uma sub-rede a alcançar sub-redes remotas sem a configuração de rota ou um gateway padrão. O proxy ARP é definido no RFC 1027.

Há desvantagens no uso do proxy ARP. Isso pode resultar em um aumento no volume de tráfego ARP no segmento de rede e no esgotamento de recursos, além de ataques man-in-the-middle. O proxy ARP apresenta um vetor do ataque do esgotamento de recurso porque cada requisição ARP proxied consome uma quantidade pequena de memória. Um invasor pode esgotar toda a memória disponível se enviar um grande número de solicitações ARP.

Os ataques de intermediários (man-in-the-middle) permitem que um host na rede falsifique o endereço MAC do roteador, o que resulta na transmissão inadvertida de tráfego dos hosts para o invasor. O Proxy ARP pode ser desativado com o comando de configuração de interface no ip proxy-arp.

Limitar o impacto do tráfego do plano de controle na CPU

A proteção do plano do controle é crítica. Como o desempenho do aplicativo e a experiência do usuário final podem ser prejudicados sem a presença de dados e tráfego de gerenciamento, a sobrevivência do plano de controle garante que os outros dois planos sejam mantidos e operacionais.

Entender o tráfego do plano de controle

Para proteger corretamente o plano de controle do dispositivo IOS Cisco, é essencial entender os tipos de tráfego que são comutados por processo pela CPU. O tráfego comutado por processo normalmente consiste em dois tipos diferentes de tráfego. O primeiro tipo de tráfego é direcionado para o dispositivo IOS Cisco e deve ser tratado diretamente pela CPU do dispositivo IOS Cisco. Esse tráfego consiste na categoria Recebimento de tráfego de adjacências. Esse tráfego contém uma entrada na tabela Cisco Express Forwarding (CEF), em que o próximo salto do roteador é o próprio dispositivo, que é indicado pelo termo receber na saída da show ip cef CLI. Esta indicação é a caixa para todo o endereço IP que exigir a manipulação direta pelo dispositivo CPU Cisco IOS, que inclui endereços IP da relação, endereço de espaço multicast, e espaço do endereço de broadcast.

O segundo tipo de tráfego tratado pela CPU é tráfego plano de dados - tráfego com um destino além do próprio dispositivo IOS Cisco, que requer processamento especial pela CPU. Embora não seja uma lista exaustiva dos impactos da CPU do tráfego do plano de dados, esses tipos de tráfego são comutados por processo e, portanto, podem afetar a operação do plano de controle:

• Registro da lista de controle de acesso - O tráfego de registro da ACL consiste em todos os pacotes gerados devido a uma correspondência (permitir ou negar) de uma ACE na qual a palavra-chave de registro é usada.
  
  
• Unicast Reverse Path Forwarding (Unicast RPF) - RPF unicast, usado com uma ACL, pode resultar na comutação de processos de determinados pacotes.
  
  
• Opções de IP – Todos os pacotes IP com opções incluídas devem ser processados pela CPU.
  
  
• Fragmentação - Qualquer pacote IP que exija fragmentação deve ser passado à CPU para ser processado.
  
  
• Expiração do Time-to-live (TTL) - Os pacotes com um valor TTL menor ou igual a um exigem que as mensagens de tempo excedido do protocolo ICMP (Tipo 11, Código 0) sejam enviadas, o que resulta no processamento da CPU.
  
  
• ICMP Inalcançável - Os pacotes que resultam em mensagens ICMP inalcançáveis devido à sua rota, MTU ou filtração são processados pela CPU.
  
  
• Tráfego que exige uma solicitação ARP - Os destinos para os quais não existe uma entrada ARP são processados pela CPU.
  
  
• Tráfego não IP – Todo o tráfego não IP é processado pela CPU.

Esta lista detalha vários métodos para determinar quais tipos de tráfego devem ser processados pela CPU do dispositivo IOS Cisco:

• O comando show ip cef fornece as informações do próximo salto para cada prefixo IP contido na tabela CEF. Como indicado previamente, as entradas que contêm recebem como o “salto seguinte” é considerado recebe adjacências e indicam que o tráfego deve ser enviado diretamente ao CPU.
  
  
• O comando show interface switching fornece informações sobre o número de pacotes que são comutados por processo por um dispositivo.
  
  
• O comando show ip traffic fornece informações sobre o número de pacotes IP:
  
  
  • com um destino local (isto é, receba o tráfego da adjacência)
  • com opções
  • isso exige a fragmentação
  • isso é enviado ao espaço do endereço de broadcast
  • isso é enviado ao espaço do endereço de multicast
    
    
• Receba o tráfego da adjacência pode ser identificado com o uso do comando show ip cache flow. Qualquer fluxo destinado ao dispositivo IOS Cisco tem uma interface de destino (DstIf) local.
  
  
• O policiamento do plano de controle pode ser usado para identificar o tipo e a taxa de tráfego que alcança o plano de controle do dispositivo IOS Cisco. O policiamento do plano de controle pode ser executado com o uso de ACLs de classificação granular, logs e o show policy-map control-plane comando.

Infra-estrutura ACL

A infra-estrutura ACL (iACLs) limita uma comunicação externa aos dispositivos da rede. Os iACLs são amplamente abordados na seção Limite de acesso à rede com ACLs de infraestrutura deste documento.

Você é recomendado executar iACLs para proteger o plano do controle de todos os dispositivos de rede.

ACLs de Recebimento

Para plataformas distribuídas, receba ACL (rACL) pode ser uma opção para Cisco IOS Software Release 12.0(21)S2 para os 12000 (GSR), 12.0(24)S para os 7500, e 12.0(31)S para os 10720. O rACL protege o dispositivo do tráfego prejudicial antes do tráfego impacta o processador de rotas. Os rACLs são projetados para proteger apenas o dispositivo no qual ele está configurado e o tráfego de trânsito não é afetado por um rACL. Como resultado, o endereço IP destino "any" usado no exemplo de entradas ACL mostrado refere-se apenas aos endereços IP físicos ou virtuais do roteador. Os rACLs também são considerados uma prática recomendada de segurança de rede e podem ser considerados como um acréscimo de longo prazo à boa segurança de rede.

Este é o trajeto ACL da recepção que é escrito para permitir o tráfego SSH (porta TCP 22) dos host confiável na rede 192.168.100.0/24:

!
!--- Permit SSH from trusted hosts allowed to the device.
!

access-list 151 permit tcp 192.168.100.0 0.0.0.255 any eq 22
!
!--- Deny SSH from all other sources to the RP.
!

access-list 151 deny tcp any any eq 22
!
!--- Permit all other traffic to the device.
!--- according to security policy and configurations.
!

access-list 151 permit ip any any
!
!--- Apply this access list to the receive path.
!

ip receive access-list 151
!

Consulte GSR: Receive Access Control Lists para ajudar a identificar e permitir o tráfego legítimo para um dispositivo e negar todos os pacotes indesejados.

CoPP

O recurso CoPP também pode ser usado para restringir pacotes IP destinados ao dispositivo de infraestrutura. Neste exemplo, somente o tráfego SSH dos host confiável é permitido para alcançar o dispositivo IOS Cisco CPU. 

Observação: o tráfego descartado de endereços IP desconhecidos ou não confiáveis pode impedir que os hosts com endereços IP atribuídos dinamicamente estabeleçam uma conexão com o dispositivo IOS Cisco.

!

access-list 152 deny tcp <trusted-addresses> <mask> any eq 22
access-list 152 permit tcp any any eq 22
access-list 152 deny ip any any
!

class-map match-all COPP-KNOWN-UNDESIRABLE
 match access-group 152
!

policy-map COPP-INPUT-POLICY
 class COPP-KNOWN-UNDESIRABLE
  drop
!

control-plane
 service-policy input COPP-INPUT-POLICY
!

No exemplo anterior do CoPP, as entradas da ACL correspondentes aos pacotes não autorizados com a ação de permissão resultam em um descarte desses pacotes pela função policy-map drop, enquanto os pacotes correspondentes à ação de negação não são afetados pela função policy-map drop.

CoPP está disponível nos trens de Cisco IOS Software Release 12.0S, 12.2SX, 12.2S, 12.3T, 12,4, e 12.4T.

Controle a proteção plana

O CPPr (Control Plane Protection), introduzido no Cisco IOS Software Release 12.4(4)T, pode ser usado para restringir ou policiar o tráfego plano de controle destinado à CPU do dispositivo IOS Cisco. Embora semelhante ao CoPP, o CPPr pode restringir o tráfego com maior granularidade. O CPPr divide o plano de controle agregado em três categorias de plano de controle separadas conhecidas como subinterfaces. Subinterfaces existe para categorias de tráfego do host, do trânsito, e da CEF-Exceção. Além disso, CPPr inclui estes recursos de proteção de planos de controle:

• Recurso de filtragem de portas - Esse recurso permite que os pacotes enviados a portas TCP ou UDP fechadas ou que não estão escutando sejam vigiados e descartados.
  
  
• Recurso de limite de fila - Esse recurso limita o número de pacotes para um protocolo especificado permitido na fila de entrada IP do plano de controle.

Consulte Compreendendo a Proteção do Plano de Controle (CPPr) para obter mais informações sobre o uso do recurso CPPr.

Limitadores da taxa do hardware

O Cisco Catalyst 6500 Series Supervisor Engine 32 e o Supervisor Engine 720 suportam limitadores de taxa baseados em hardware (HWRLs - Rate Limiters) específicos de plataforma para cenários de rede especiais. Estes limitadores da taxa do hardware são referidos como limitadores da taxa do especial-caso porque cobrem um grupo predefinido específico de IPv4, de IPv6, de unicast, e de encenações DoS do multicast. Os HWRLs podem proteger o dispositivo IOS Cisco de uma variedade de ataques que exigem que os pacotes sejam processados pela CPU.

Há vários HWRLs habilitados por padrão. Consulte Configurações padrão do limitador de taxa baseado em hardware PFC3 para obter mais informações sobre HWRLs.

Refira a limitadores com base em hardware da taxa no PFC3 para obter mais informações sobre de HWRLs.

Proteger o BGP

O Border Gateway Protocol (BGP) é a fundação do roteamento da Internet. Como tal, qualquer empresa com requisitos de conectividade mais que modestos geralmente usa o BGP. O BGP é frequentemente alvo de invasores por causa de sua onipresença e da natureza de definir e esquecer das configurações do BGP em organizações menores. Contudo, há muitos recursos de segurança BGP-específicos que podem ser entregues para aumentar a segurança de uma configuração de BGP.

Isso fornece uma visão geral dos recursos de segurança mais importantes do BGP e, quando apropriado, recomendações de configuração são feitas.

As proteções de segurança dos TTL-estabelecimentos de bases

Cada pacote IP contem um campo 1-byte conhecido como o Time to Live (TTL). Cada dispositivo que um pacote IP atravessa decresce o valor por um. O valor inicial do TTL varia de acordo com o sistema operacional e, normalmente, varia de 64 a 255. Um pacote é deixado cair quando seu valor TTL alcança zero.

Conhecida como o Generalized TTL-based Security Mechanism (GTSM) e o BGP TTL Security Hack (BTSH), uma proteção de segurança baseada em TTL aproveita o valor TTL dos pacotes IP para garantir que os pacotes BGP recebidos sejam de um peer diretamente conectado. Esse recurso frequentemente requer coordenação de roteadores pares; no entanto, uma vez habilitado, ele pode derrotar completamente muitos ataques baseados em TCP contra o BGP.

O GTSM para BGP é ativado com a ttl-security opção para o comando de configuração do roteador neighbor BGP. Este exemplo ilustra a configuração desta característica:

!

router bgp <asn>
 neighbor <ip-address> remote-as <remote-asn>
 neighbor <ip-address> ttl-security hops <hop-count>
!

À medida que os pacotes BGP são recebidos, o valor TTL é verificado e deve ser maior ou igual a 255, menos a contagem de saltos especificada.

Autenticação do bgp peer com MD5

A autenticação de pares com MD5 cria um resumo MD5 de cada pacote enviado como parte de uma sessão BGP. Especificamente, partes dos cabeçalhos IP e TCP, payload TCP e uma chave secreta são usados para gerar o resumo.

O resumo criado é armazenado então no tipo 19 da opção de TCP, que foi criado especificamente por esse motivo pelo RFC 2385. O alto-falante BGP destinatário usa o mesmo algoritmo e chave secreta para regenerar o resumo da mensagem. Se os resumos recebidos e computados não são idênticos, o pacote está rejeitado.

A autenticação de peer com MD5 é configurada com a password opção para o comando de configuração do roteador neighbor BGP. O uso desse comando está ilustrado aqui:

!

router bgp <asn>
 neighbor <ip-address> remote-as <remote-asn>
 neighbor <ip-address> password <secret>
!

Refira a autenticação do roteador vizinho para obter mais informações sobre da autenticação do bgp peer com MD5.

Configurar os prefixos máximos

Os prefixos BGP são armazenados por um roteador na memória. Quanto mais prefixos um roteador precisar manter, mais memória o BGP consumirá. Em algumas configurações, um subconjunto de todos os prefixos da Internet pode ser armazenado, como em configurações que utilizam apenas uma rota padrão ou rotas para redes de usuários do provedor.

Para evitar o esgotamento da memória, configure o número máximo de prefixos aceitos em uma base por peer. Recomenda-se que um limite esteja configurado para cada BGP peer.

neighbor maximum-prefix Quando você configura esse recurso com o comando de configuração do roteador BGP, um argumento é necessário: o número máximo de prefixos aceitos antes que um peer seja desligado. Opcionalmente, um número de 1 a 100 pode igualmente ser incorporado. Esse número representa a porcentagem do valor máximo de prefixos em relação ao envio de uma mensagem de log.

!

router bgp <asn>
 neighbor <ip-address> remote-as <remote-asn>
 neighbor <ip-address> maximum-prefix <shutdown-threshold> <log-percent>
!

Refira a configurar os recursos de prefixo máximo BGP para obter mais informações sobre os prefixos máximos por peer.

Filtrar os prefixos BGP com listas de prefixos

As listas de prefixos permitem que um administrador de rede permita ou negue prefixos específicos enviados ou recebidos pelo BGP. Use listas de prefixo, quando possível, para garantir que o tráfego de rede seja enviado pelos caminhos pretendidos. Aplique listas de prefixo a cada peer do eBGP nas direções de entrada e saída.

As listas de prefixos configurados limitam os prefixos enviados ou recebidos àqueles especificamente permitidos pela política de rota de uma rede. Se isso não for viável devido ao grande número de prefixos recebidos, configure uma lista de prefixos para bloquear especificamente prefixos inválidos conhecidos. Esses prefixos inválidos conhecidos incluem espaço de endereço IP não alocado e redes reservadas para fins internos ou de teste pelo RFC 3330. Configure listas de prefixos de saída para permitir especificamente apenas os prefixos que uma organização pretende anunciar.

Este exemplo de configuração usa listas de prefixo para limitar as rotas que são instruídas e anunciadas. Especificamente, somente uma rota padrão de entrada é permitida de prefixo BGP-PL-INBOUND, e o prefixo 192.168.2.0/24 é a única rota permitida anunciada por BGP-PL-OUTBOUND.

!

ip prefix-list BGP-PL-INBOUND seq 5 permit 0.0.0.0/0
ip prefix-list BGP-PL-OUTBOUND seq 5 permit 192.168.2.0/24
!

router bgp <asn>
 neighbor <ip-address> prefix-list BGP-PL-INBOUND in
 neighbor <ip-address> prefix-list BGP-PL-OUTBOUND out
!

Consulte Conexão a um provedor de serviços usando BGP externo para obter uma cobertura completa das informações de filtro de prefixo BGP.

Filtrar os prefixos de BGP com listas de acesso do caminho para o sistema autônomo

As listas de acesso de caminho do sistema autônomo (AS) BGP permitem que o usuário filtre prefixos recebidos e anunciados com base no atributo AS-path de um prefixo. Isso pode ser usado com listas de prefixos para estabelecer um conjunto robusto de filtros.

Este exemplo de configuração usa AS listas de acessos para restringir prefixos de entrada àqueles originaram pelo telecontrole AS e os prefixos de partida àqueles originaram pelo sistema autônomo local. Os prefixos originados de todos os outros sistemas autônomos são filtrados e não instalados na tabela de roteamento.

!

ip as-path access-list 1 permit ^65501$
ip as-path access-list 2 permit ^$
!

router bgp <asn>
 neighbor <ip-address> remote-as 65501
 neighbor <ip-address> filter-list 1 in
 neighbor <ip-address> filter-list 2 out
!

Proteger os Interior Gateway Protocols

A capacidade de uma rede de encaminhar adequadamente o tráfego e recuperar-se de alterações ou falhas de topologia depende de uma visão precisa da topologia. Geralmente, você pode executar um IGP (Interior Gateway Protocol) para fornecer essa visualização. Por padrão, os IGP são dinâmicos e descobrem os roteadores adicionais que se comunicam com o IGP particular no uso. Os IGPs também descobrem rotas que podem ser usadas quando um link de rede falha.

Estas subseções fornecem uma vista geral dos recursos de segurança os mais importantes IGP. As recomendações e os exemplos que cobrem a versão 2 do protocolo de informação de roteamento protocolo de informação de roteamento (RIPv2), o protocolo enhanced interior gateway routing (EIGRP), e o caminho mais curto aberto (OSPF) são fornecidos primeiramente quando apropriados.

Autenticação e verificação do protocolo de roteamento com message digest 5

A falha para fixar a troca de informação de roteamento permite que um atacante introduza a informação de roteamento falsa na rede. Use a autenticação de senha com protocolos de roteamento entre roteadores para auxiliar na segurança da rede. Contudo, porque esta autenticação é enviada como a minuta, pode ser simples para que um atacante subverta este controle de segurança.

Quando os recursos de hash MD5 são adicionados ao processo de autenticação, as atualizações de roteamento não contêm mais senhas de texto claro, e todo o conteúdo da atualização de roteamento é mais resistente à violação. No entanto, a autenticação MD5 ainda é susceptível à força bruta e a ataques de dicionário se senhas fracas forem usadas. Você é recomendado usar senhas aleatórias suficientemente. Desde que a autenticação md5 é muito mais segura quando comparada à autenticação de senha, estes exemplos é específica à autenticação md5. O IPSec também pode ser usado para validar e proteger protocolos de roteamento, mas esses exemplos não detalham seu uso.

O EIGRP e o RIPv2 usam Cadeias de Chaves como parte da configuração. Refira a chave para obter mais informações sobre da configuração e do uso das portas-chaves.

Este é um exemplo de configuração para a autenticação do roteador EIGRP que usa MD5:

!

key chain <key-name>
 key <key-identifier>
 key-string <password> 
!

interface <interface>
 ip authentication mode eigrp <as-number> md5
 ip authentication key-chain eigrp <as-number> <key-name>
!

Esta é uma configuração da autenticação de roteador do exemplo MD5 para o RIPv2. O RIPv1 não suporta a autenticação.

!

key chain <key-name>
 key <key-identifier>
 key-string <password> 
!

interface <interface>
 ip rip authentication mode md5
 ip rip authentication key-chain <key-name>
!

Este é um exemplo de configuração para a autenticação do roteador OSPF com MD5. O OSPF não usa cadeias de chaves.

!

interface <interface>
 ip ospf message-digest-key <key-id> md5 <password>
!

router ospf <process-id>
 network 10.0.0.0 0.255.255.255 area 0
 area 0 authentication message-digest
!

Refira configurar o OSPF para mais informação.

Comandos passive-interface

Os vazamentos de informações, ou a introdução de informações falsas em um IGP, podem ser atenuados através do uso do passive-interface comando que auxilia no controle do anúncio de informações de roteamento. Você é aconselhado a não anunciar nenhuma informação a redes fora de seu controle administrativo.

Este exemplo demonstra o uso deste recurso:

!

router eigrp <as-number> 
 passive-interface default
 no passive-interface <interface>
!

Filtragem de rota

Para reduzir a possibilidade de introduzir informações de rota falsas na rede, use a Filtragem de rota. Diferentemente do comando de configuração do passive-interface roteador, o roteamento ocorre nas interfaces quando a filtragem de rota é ativada, mas as informações anunciadas ou processadas são limitadas.

Para EIGRP e RIP, o uso do distribute-list comando com a palavra-chave out limita as informações anunciadas, enquanto o uso da in palavra-chave limita as atualizações processadas. O distribute-list comando está disponível para OSPF, mas não impede que um roteador propague rotas filtradas. Em vez disso, o area filter-list comando pode ser usado.

Este exemplo do EIGRP filtra anúncios de saída com o distribute-list comando e uma lista de prefixos:

!

ip prefix-list <list-name> seq 10 permit <prefix> 
!

router eigrp <as-number>
 passive-interface default
 no passive-interface <interface>
 distribute-list prefix <list-name> out <interface>
!

Este exemplo EIGRP filtra atualizações de entrada com uma lista de prefixo:

!

ip prefix-list <list-name> seq 10 permit <prefix> 
!

router eigrp <as-number>
 passive-interface default
 no passive-interface <interface>
 distribute-list prefix <list-name> in <interface>
!

Este exemplo de OSPF usa uma lista de prefixos com o comando area filter-list command:

!

ip prefix-list <list-name> seq 10 permit <prefix> 
!

router ospf <process-id>
 area <area-id> filter-list prefix <list-name> in 
!

Consumo do recurso do processo de roteamento

Os prefixos do Routing Protocol são armazenados por um roteador na memória e o consumo de recursos aumenta com os prefixos adicionais que um roteador deve manter. Para evitar o esgotamento de recursos, configure o protocolo de roteamento para limitar o consumo de recursos. Isso é possível com o OSPF, se você usar o recurso Link State Database Overload Protection.

Este exemplo demonstra a configuração dos recursos de proteção da sobrecarga do banco de dados de estado de link OSPF:

!

router ospf <process-id>
 max-lsa <maximum-number> 
!

Proteger os First Hop Redundancy Protocols

Os First Hop Redundancy Protocols (FHRPs) fornecem resiliência e redundância para dispositivos que atuam como gateways padrão. Esta situação e estes protocolos são comuns nos ambientes onde um peer de dispositivos da camada 3 fornece a funcionalidade do gateway padrão para um segmento de rede ou um conjunto de vlan que contêm server ou estações de trabalho.

O protocolo da Função de Balanceamento de Carga do Gateway (GLBP), o protocolo de roteador de Standby Recente (HSRP), e o protocolo de redundância de roteador virtual (VRRP) são todo o FHRPs. Por padrão, esses protocolos usam comunicações não autenticadas. Esse tipo de comunicação pode permitir que um invasor se apresente como um dispositivo compatível com FHRP para assumir a função de gateway padrão na rede. Essa transferência permite que um invasor execute um ataque de intermediários e intercepte todo o tráfego de usuário que sai da rede.

Para evitar esse tipo de ataque, todos os FHRPs suportados pelo software Cisco IOS incluem um recurso de autenticação com MD5 ou strings de texto. Devido à ameaça levantada por FHRPs não-autenticado, recomenda-se que os exemplos destes protocolos usam a autenticação md5. Este exemplo de configuração demonstra o uso da autenticação md5 GLBP, HSRP, e VRRP:

!

interface FastEthernet 1
 description *** GLBP Authentication ***
 glbp 1 authentication md5 key-string <glbp-secret>
 glbp 1 ip 10.1.1.1
!

interface FastEthernet 2
 description *** HSRP Authentication ***
 standby 1 authentication md5 key-string <hsrp-secret>
 standby 1 ip 10.2.2.1
!

interface FastEthernet 3
 description *** VRRP Authentication ***
 vrrp 1 authentication md5 key-string <vrrp-secret> 
 vrrp 1 ip 10.3.3.1
!

Plano dos dados

Embora o plano de dados seja responsável por mover dados da origem para o destino, dentro do contexto de segurança, o plano de dados é o menos importante dos três planos. Por esse motivo, é importante proteger os planos de gerenciamento e controle de preferência sobre o plano de dados quando você protege um dispositivo de rede .

Contudo, dentro do plano próprio dos dados, há muitas características e opções de configuração que podem ajudar o tráfego seguro. Estas seções detalham os recursos e as opções para que você possa proteger sua rede com mais facilidade.

Endurecimento do plano dos dados gerais

A grande maioria do tráfego plano de dados flui pela rede, conforme determinado pela configuração de roteamento da rede. Contudo, a funcionalidade da rede IP existe para alterar o trajeto dos pacotes através da rede. Os recursos, como as opções de IP, especificamente a opção de roteamento de origem, formam um desafio de segurança nas redes atuais.

O uso de ACLs de trânsito também é relevante para fortalecer o plano de dados.

Para obter mais informações, consulte a seção Filtrar tráfego de trânsito com ACLs de trânsito.

Queda seletiva das opções IP

Há dois interesses de segurança apresentados por opções IP. O tráfego que contém as opções IP deve ser comutado por processo pelos dispositivos Cisco IOS, o que pode levar a uma carga de CPU elevada. As opções de IP também incluem a funcionalidade para alterar o caminho que o tráfego percorre pela rede, o que potencialmente permite subverter os controles de segurança.

Devido a essas preocupações, o comando de configuração global ip options {drop | ignore} foi adicionado aos Cisco IOS Software Releases 12.3(4)T, 12.0(22)S e 12.2(25)S. Na primeira forma desse comando, ip options droptodos os pacotes IP que contêm opções IP recebidas pelo dispositivo IOS Cisco são descartados. Isto impede a carga de CPU elevado e a subversão possível dos controles de segurança que as opções IP podem permitir.

A segunda forma desse comando, ip options ignore, configura o dispositivo IOS Cisco para ignorar as opções IP contidas nos pacotes recebidos. Embora isso atenue as ameaças relacionadas às opções de IP para o dispositivo local, é possível que os dispositivos de downstream possam ser afetados pela presença de opções de IP. Por esse motivo, a drop forma desse comando é altamente recomendável. Como demonstrado neste exemplo de configuração:

!
ip options drop
!

Alguns protocolos, por exemplo o RSVP, fazem uso legítimo de opções IP. A funcionalidade destes protocolos é impactada por este comando.

Depois que a queda seletiva das opções de IP for ativada, o show ip traffic EXEC comando poderá ser usado para determinar o número de pacotes que serão descartados devido à presença de opções de IP. Esta informação esta presente no contador de queda forçado.

Desabilite o roteamento do origem de IP

O roteamento de origem de IP aproveita as opções Rota de origem solta e Rota de registro, em tandem; ou a Rota de origem estrita, junto com a opção Rota de registro para permitir que a origem do datagrama de IP especifique o caminho de rede que um pacote toma. Essa funcionalidade pode ser usada em tentativas de rotear o tráfego em torno de controles de segurança na rede.

Se as opções de IP não tiverem sido completamente desativadas pelo recurso IP Options Selective Drop (Descarte seletivo de opções de IP), é importante que o roteamento de origem de IP seja desativado. O roteamento de origem IP, que é ativado por padrão em todas as versões do software Cisco IOS, é desativado pelo comando de configuração no ip source-route global. Este exemplo de configuração ilustra o uso deste comando:

!
no ip source-route
!

Desabilite o redirecionamentos de ICMP

Os redirecionamentos de ICMP são usados para informar um dispositivo de rede de um melhor caminho para um destino IP. Por padrão, o Cisco IOS Software envia uma reorientação se recebe um pacote que deva ser roteado através da relação que foi recebido.

Em algumas situações, pode ser possível para um invasor fazer com que o dispositivo IOS Cisco envie muitas mensagens de redirecionamento de ICMP, o que resulta em uma carga de CPU elevada. Por esse motivo, recomenda-se que a transmissão de redirecionamentos ICMP seja desativada. Os redirecionamentos de ICMP são desativados com o no ip redirects comando de configuração de interface, como mostrado neste exemplo de configuração:

!

interface FastEthernet 0
 no ip redirects
!

Desabilite ou limite broadcasts direto de IP

Os broadcasts direto de IP tornam possível enviar um pacote da transmissão IP a uma sub-rede do IP remoto. Quando o pacote chega à rede remota, o dispositivo IP de encaminhamento envia o pacote como um broadcast de Camada 2 para todas as estações na sub-rede. Essa funcionalidade de broadcast direcionada foi aproveitada como uma amplificação e auxílio à reflexão em vários ataques, que incluem o ataque smurf.

Por padrão, as versões atuais do software Cisco IOS têm essa funcionalidade desabilitada; no entanto, ela pode ser habilitada pelo comando de configuração da ip directed-broadcast interface. Por padrão, as versões do software Cisco IOS anteriores à 12.0 têm essa funcionalidade habilitada.

Se uma rede exigir absolutamente a funcionalidade de broadcast direcionada, controle seu uso. Isso é possível com o uso de uma ACL como opção para o ip directed-broadcast comando. Este exemplo de configuração limita broadcasts direcionados para pacotes UDP que se originam em uma rede confiável, 192.168.1.0/24:

!

access-list 100 permit udp 192.168.1.0 0.0.0.255 any
!

interface FastEthernet 0
 ip directed-broadcast 100
!

Filtrar o tráfego em trânsito com ACLs de trânsito

É possível controlar o tráfego que transita pela rede com o uso de ACLs de trânsito (tACLs). Isso contrasta com os iACLs que buscam filtrar o tráfego destinado à própria rede. O filtro fornecido pelas tACLs é benéfico quando o objetivo é filtrar o tráfego para um grupo específico de dispositivos ou tráfego que transita pela rede.

Tradicionalmente, os firewalls executam esse tipo de filtro. No entanto, há casos em que pode ser benéfico executar esse filtro em um dispositivo IOS Cisco na rede. Por exemplo, onde a filtragem deve ser executada, mas nenhum firewall está presente.

Os tACLs também são um local apropriado para implementar proteções antifalsificação estáticas.

Para obter mais informações, consulte a seção Proteções anti-falsificação.

Consulte Listas de Controle de Acesso de Trânsito: Filtragem em Sua Borda para obter mais informações sobre tACLs.

Filtração do pacote ICMP

O protocolo Protocolo de controle de mensagens de Internet (ICMP) foi projetado como um protocolo de controle para o IP. Como tal, as mensagens que ele transmite podem ter ramificações significativas nos protocolos TCP e IP em geral. O ICMP é usado pelas ferramentas ping e traceroute, para solucionar problemas da rede, bem como pela Path MTU Discovery. No entanto, a conectividade externa ICMP raramente é necessária para a operação adequada da rede.

O Cisco IOS Software fornece a funcionalidade para filtrar especificamente por nome da mensagens ICMP ou para datilografá-los e codificá-los. Este exemplo de ACL permite o ICMP de redes confiáveis, enquanto bloqueia todos os pacotes ICMP de outras origens:

!

ip access-list extended ACL-TRANSIT-IN
!
!--- Permit ICMP packets from trusted networks only
!

 permit icmp host <trusted-networks> any 
!
!--- Deny all other IP traffic to any network device
!

 deny icmp any any
!

Filtre fragmentos IP

Conforme detalhado anteriormente na seção Limite de acesso à rede com ACLs de infraestrutura deste documento, o filtro de pacotes IP fragmentados pode representar um desafio para os dispositivos de segurança.

Devido à natureza não intuitiva do controle de fragmentos, os fragmentos IP são geralmente permitidos inadvertidamente por ACLs. A fragmentação é frequentemente usada nas tentativas de iludir a detecção pelo Intrusion Detection Systems. Por esses motivos, os fragmentos IP são frequentemente usados em ataques e podem ser filtrados explicitamente na parte superior de qualquer tACL configurado. O exemplo de ACL listado inclui um filtro abrangente de fragmentos IP. A funcionalidade ilustrada neste exemplo deve ser usada com a funcionalidade dos exemplos anteriores:

!

ip access-list extended ACL-TRANSIT-IN
!
!--- Deny IP fragments using protocol-specific ACEs to aid in 
!--- classification of attack traffic
!

 deny tcp any any fragments
 deny udp any any fragments
 deny icmp any any fragments
 deny ip any any fragments
!

Consulte Listas de controle de acesso e fragmentos IP para obter mais informações sobre como a ACL lida com pacotes IP fragmentados.

Suporte ACL para filtrar opções IP

No Cisco IOS Software Release 12.3(4)T e posterior, o Cisco IOS Software suporta o uso de ACLs para filtrar pacotes IP, com base nas opções IP contidas no pacote. A presença de opções IP dentro de um pacote pode indicar uma tentativa de subverter os controles de segurança na rede ou de alterar as características de trânsito de um pacote. Por esses motivos, os pacotes com opções de IP são recomendados para serem filtrados na borda da rede.

Use este exemplo, junto com o conteúdo dos exemplos anteriores para incluir um filtro completo para pacotes IP que contêm opções IP:

!

ip access-list extended ACL-TRANSIT-IN
!
!--- Deny IP packets containing IP options
!

 deny ip any any option any-options
!

Proteções anti-falsificação

Muitos ataques usam o spoofing do endereço IP de origem para serem eficazes ou para ocultar a verdadeira origem de um ataque e impedir um rastreamento preciso. O Cisco IOS Software fornece o unicast RPF e a proteção de origem de IP (IPSG) para intimidar os ataques que confiam na falsificação do endereço IP de origem. Além disso, os ACL e o roteamento nulo são frequentemente distribuídos como meios manuais da prevenção da falsificação.

O IPSG funciona para minimizar o spoofing para redes sob controle administrativo direto pelo desempenho da porta do switch, do endereço MAC e da verificação do endereço de origem. O Unicast RPF fornece verificação de rede de origem e pode reduzir ataques falsificados de redes que não estão sob controle administrativo direto. A segurança de porta pode ser usada para validar endereços MAC na camada de acesso. A Dynamic Address Resolution Protocol (ARP) Inspection (DAI) mitiga os vetores de ataque que usam envenenamento ARP nos segmentos locais.

Unicast RPF

O unicast RPF permite que um dispositivo verifique o endereço de origem de um pacote encaminhado pode ser alcançado através da interface que recebeu o pacote. Não confie no RPF unicast como a única proteção contra falsificação. Os pacotes falsificado poderiam incorporar a rede através de uma relação das RPF-possibilidades do unicast se uma rota do retorno apropriada ao endereço IP de origem existe. O Unicast RPF depende de você para ativar o Cisco Express Forwarding em cada dispositivo e é configurado de acordo com a interface.

O RPF unicast pode ser configurado em um de dois modos: solto ou estrito. Nos casos onde há um roteamento assimétrico, o modo fraco é preferido porque o modo restrito é conhecido para deixar cair pacotes nestas situações. Durante a configuração do comando de configuração da ip verify interface, a palavra-chave any configura o modo solto enquanto a palavra-chave rx configura o modo estrito.

Este exemplo ilustra a configuração desta característica:

!

ip cef
!

interface <interface>
  ip verify unicast source reachable-via <mode>
!

Refira a compreendendo o Unicast Reverse Path Forwarding para obter mais informações sobre da configuração e do uso do unicast RPF.

Proteção de origem de IP

A proteção de origem de IP é os significados efetivo da prevenção da falsificação que podem ser usados se você tem o controle sobre interfaces de camada 2. O IP Source Guard usa informações do rastreamento de DHCP para configurar dinamicamente uma lista de controle de acesso à porta (PACL) na interface de Camada 2, negando qualquer tráfego de endereços IP que não estejam associados na tabela de ligação de origem de IP.

O IP Source Guard pode ser aplicado às interfaces de Camada 2 que pertencem às VLANs habilitadas para rastreamento de DHCP. Esta espião dos comandos enable DHCP:

!

ip dhcp snooping
ip dhcp snooping vlan <vlan-range>
!

Depois que a espião DHCP é permitida, estes comandos enable IPSG:

!
interface <interface-id>
   ip verify source 
!

A segurança de porta pode ser habilitada com o comando de configuração de interfaceTip verify source port security. Isso exige o comando de configuração global ip dhcp snooping information option; , além disso, o servidor DHCP deve suportar a opção 82 do DHCP.

Refira configurar características e proteção de origem de IP DHCP para obter mais informações sobre esta característica.

Segurança da porta

A segurança de porta é usada para reduzir a falsificação de endereço MAC na interface de acesso. A segurança de porta pode usar endereços (pegajosos) dinâmicamente instruídos MAC para facilitar na configuração inicial. Quando a segurança de porta determina uma violação de MAC, pode usar um dos quatro modos de violação. Esses modos são: proteger, restringir, desligar e desligar VLAN. Nos casos em que uma porta fornece acesso apenas para uma única estação de trabalho com o uso de protocolos padrão, um número máximo de um pode ser suficiente. Os protocolos que aproveitam os endereços MAC virtuais, como o HSRP, não funcionam quando o número máximo é definido como um.

!

interface <interface> 
  switchport
  switchport mode access 
  switchport port-security
  switchport port-security mac-address sticky
  switchport port-security maximum <number>
  switchport port-security violation <violation-mode>
!

Consulte Configuração da segurança de porta para obter mais informações sobre a configuração da segurança de porta.

Inspeção ARP dinâmica

A Dynamic ARP Inspection (DAI) pode ser usada para mitigar ataques de envenenamento ARP em segmentos locais. Um ataque do envenenamento ARP é um método em que um atacante envia a informação falsificada ARP a um segmento local. Esta informação é projetada corromper o cache ARP dos outros dispositivos. Frequentemente, um invasor usa envenenamento ARP para realizar um ataque man-in-the-middle.

DAI intercepta e valida o relacionamento de endereço do IP-à-MAC de todos os pacotes ARP em portas não-confiáveis. Em ambientes DHCP, a DAI usa os dados gerados pelo recurso DHCP snooping. Os pacotes ARP são recebidos em interfaces confiáveis e não são validados e os pacotes inválidos em interfaces não confiáveis são descartados. Em ambientes do não-DHCP, o uso de ARP ACL é exigido.

Esta espião dos comandos enable DHCP:

!
ip dhcp snooping
ip dhcp snooping vlan <vlan-range>
!

Uma vez que a espião DHCP foi permitida, estes comandos habilitam DAI:

!
ip arp inspection vlan <vlan-range> 
!

Em ambientes não-DHCP, as ACLs ARP são necessárias para ativar o DAI. Este exemplo demonstra a configuração básica de DAI com ARP ACL:

!

arp access-list <acl-name>
 permit ip host <sender-ip> mac host <sender-mac>
!

ip arp inspection filter <arp-acl-name> vlan <vlan-range>
!

A DAI também pode ser ativada de acordo com a interface, onde quer que seja compatível.

ip arp inspection limit rate <rate_value> burst interval <interval_value>

Refira a configurar a inspeção ARP dinâmica para obter mais informações sobre de como configurar DAI.

ACL anti-falsificação

As ACLs configuradas manualmente podem fornecer proteção antispoofing estática contra ataques que usam o espaço de endereço não utilizado e não confiável. Geralmente, estes ACL anti-falsificação são aplicados ao tráfego de ingresso em limites de rede como um componente de um ACL maior. As ACLs anti-falsificação exigem intervalos de monitoramento regulares, pois podem ser alteradas com frequência. O spoofing pode ser minimizado no tráfego originado na rede local, se você aplicar ACLs de saída que limitam o tráfego a endereços locais válidos.

Este exemplo demonstra como usar ACLs para limitar a falsificação de IP. Este ACL é de entrada aplicado na interface desejada. Os ACE que compõe este ACL não são completos. Se você configurar esses tipos de ACL, procure uma referência atualizada que seja conclusiva.

!

ip access-list extended ACL-ANTISPOOF-IN
 deny	ip 10.0.0.0 0.255.255.255 any
 deny	ip 192.168.0.0 0.0.255.255 any
!

interface <interface>
 ip access-group ACL-ANTISPOOF-IN in
!

Refira a configurar IP de uso geral ACL para obter mais informações sobre de como configurar lista de controle de acesso.

A lista oficial de endereços do Internet não alocada é mantida pela equipe Cymru. Informações adicionais sobre como filtrar endereços não utilizados estão disponíveis na Página de Referência de Bogon .

Limitar o impacto do tráfego do plano de dados na CPU

O propósito principal dos roteadores e dos interruptores é enviar avante pacotes e quadros através do dispositivo aos destinos finais. Estes pacotes, que transitam pelos dispositivos distribuíram durante todo a rede, podem impactar funcionamentos CPU de um dispositivo. Proteja o plano de dados, que consiste no tráfego que transita pelo dispositivo de rede, para garantir a operação dos planos de gerenciamento e controle. Se o tráfego de trânsito pode fazer com que um dispositivo processe o tráfego do switch, o plano de controle de um dispositivo pode ser afetado, o que leva a uma interrupção operacional.

Características e tipos de tráfego que impactam o CPU

Embora não exaustiva, esta lista inclui tipos de tráfego de plano de dados que exigem um processamento especial de CPU e são processos comutados pela CPU:

• Log de ACL - O tráfego de log de ACL consiste em todos os pacotes gerados devido a uma correspondência (permitir ou negar) de uma ACE na qual a palavra-chave log é usada.
  
  
• Unicast RPF - O unicast RPF usado com uma ACL pode resultar na comutação de processos de determinados pacotes.
  
  
• Opções de IP – Todos os pacotes IP com opções incluídas devem ser processados pela CPU.
  
  
• Fragmentação – Qualquer pacote IP que exija fragmentação deve ser passado para a CPU para processamento.
  
  
• Expiração Time-to-Live (TTL) – Os pacotes que têm um valor TTL menor ou igual a um exigem o envio de mensagens Internet Control Message Protocol Time Exceeded (ICMP Tipo 11, Código 0), o que resulta no processamento da CPU.
  
  
• ICMP Inalcançável - Os pacotes que resultam em mensagens ICMP inalcançáveis devido à sua rota, MTU ou filtração são processados pela CPU.
  
  
• O tráfego que requer uma solicitação ARP - Os destinos para os quais não existe uma entrada ARP são processados pela CPU.
  
  
• Tráfego não IP – Todo o tráfego não IP é processado pela CPU.

Para obter mais informações sobre o Endurecimento de Plano de Dados, consulte a seção Endurecimento de Plano de Dados Geral.

Filtrar o valor TTL

Você pode usar o recurso Suporte ACL para filtragem no valor TTL, introduzido no Cisco IOS Software Release 12.4(2)T, em uma lista de acesso IP estendida para filtrar pacotes com base no valor TTL. Esse recurso pode proteger um dispositivo que recebe tráfego de trânsito onde o valor TTL é zero ou um. O filtro de pacotes baseado em valores TTL também pode ser usado para garantir que o valor TTL não seja inferior ao diâmetro da rede, isto protege o plano de controle dos dispositivos de infraestrutura downstream de ataques de expiração TTL.

Algumas aplicações e ferramentas, como traceroute o uso de pacotes de expiração TTL para fins de teste e diagnóstico. Alguns protocolos, tais como o IGMP, usam legìtimamente um valor TTL de um.

Este exemplo de ACL cria uma política que filtra os pacotes IP onde o valor TTL é menor do que o 6.

!
!--- Create ACL policy that filters IP packets with a TTL value
!--- less than 6
!

ip access-list extended ACL-TRANSIT-IN
 deny ip any any ttl lt 6
 permit ip any any
!
!--- Apply access-list to interface in the ingress direction
!

interface GigabitEthernet 0/0
 ip access-group ACL-TRANSIT-IN in 
!

Consulte Identificação e mitigação do ataque de expiração TTL para obter mais informações sobre como filtrar pacotes com base no valor TTL.

Refira ao apoio ACL filtrando no valor TTL para obter mais informações sobre desta característica.

No software Cisco IOS versão 12.4(4)T e posterior, o Flexible Packet Matching (FPM) permite que um administrador corresponda em bits arbitrários de um pacote. Esta política de FPM descarta pacotes com um valor de TTL inferior a 6.

!

load protocol flash:ip.phdf
!

class-map type access-control match-all FPM-TTL-LT-6-CLASS
 match field IP ttl lt 6
!

policy-map type access-control FPM-TTL-LT-6-DROP-POLICY
 class  FPM-TTL-LT-6-CLASS
  drop
!

interface FastEthernet0
 service-policy type access-control input FPM-TTL-LT-6-DROP-POLICY
!

Filtrar a presença das opções de IP

No Cisco IOS Software Release 12.3(4)T e Mais Recente, você pode usar o apoio ACL para a característica de filtração das opções IP em uma lista de acesso IP nomeada estendido para filtrar pacotes IP com as opções IP atuais. O filtro de pacotes IP com base na presença de opções IP também pode ser usado para evitar que o plano de controle dos dispositivos de infraestrutura da necessidade de processar esses pacotes no nível da CPU.

O recurso Suporte ACL para opções IP de filtragem pode ser usado somente com ACLs nomeadas e estendidas. RSVP, Engenharia de Tráfego Multiprotocol Label Switching, IGMP Versões 2 e 3 e outros protocolos que usam pacotes de opções IP não podem funcionar corretamente se os pacotes desses protocolos forem descartados. Se esses protocolos estiverem em uso na rede, o suporte ACL para opções IP de filtragem poderá ser usado. No entanto, o recurso de Descarte Seletivo de Opções de IP da ACL pode descartar esse tráfego e esses protocolos não podem funcionar corretamente. Se não houver protocolos em uso que exijam opções IP, o recurso ACL IP Options Selective Drop é o método preferencial para descartar esses pacotes.

Este exemplo de ACL cria uma política essa os pacotes IP dos filtros que contêm todas as opções IP:

!

ip access-list extended ACL-TRANSIT-IN
 deny ip any any option any-options
 permit ip any any
!

interface GigabitEthernet 0/0
 ip access-group ACL-TRANSIT-IN in 
!

Este exemplo ACL demonstra uma política essa pacotes IP dos filtros com cinco opções IP específicas. Os pacotes que contêm estas opções são negadas:

• 0 extremidades da lista de opções (eool)
  
  
• 7 Rota do registro (registro-rota)
  
  
• 68 Selo de tempo (timestamp)
  
  
• 131 - Rota de origem fraca (lsr)
  
  
• 137 - Rota de origem restrita (ssr)

!

ip access-list extended ACL-TRANSIT-IN
 deny ip any any option eool
 deny ip any any option record-route
 deny ip any any option timestamp
 deny ip any any option lsr
 deny ip any any option ssr
 permit ip any any
!

interface GigabitEthernet 0/0
 ip access-group ACL-TRANSIT-IN in 
!

Consulte a seção Endurecimento do Plano de Dados Geral deste documento para obter mais informações sobre o Descarte Seletivo de Opções IP ACL.

Consulte Listas de Controle de Acesso de Trânsito: Filtragem em Sua Borda para obter mais informações sobre como filtrar o tráfego de trânsito e borda.

Outro recurso do software Cisco IOS que pode ser usado para filtrar pacotes com opções IP é o CoPP. No software Cisco IOS versão 12.3(4)T e posterior, o CoPP permite que um administrador filtre o fluxo de tráfego de pacotes do plano de controle. Um dispositivo que suporta CoPP e suporte ACL para opções IP de filtragem, introduzido no Cisco IOS Software Release 12.3(4)T, pode usar uma política de lista de acesso para filtrar pacotes que contenham opções IP.

Esta política de CoPP deixa cair os pacotes de trânsito que estão recebidos por um dispositivo quando todas as opções IP estão presentes:

!

ip access-list extended ACL-IP-OPTIONS-ANY
 permit ip any any option any-options
!

class-map ACL-IP-OPTIONS-CLASS
 match access-group name ACL-IP-OPTIONS-ANY
!

policy-map COPP-POLICY
 class ACL-IP-OPTIONS-CLASS
  drop
!

control-plane
 service-policy input COPP-POLICY
!

Esta política de CoPP deixa cair os pacotes de trânsito recebidos por um dispositivo quando estas opções IP estão presentes:

• 0 extremidades da lista de opções (eool)
  
  
• 7 Rota do registro (registro-rota)
  
  
• 68 Selo de tempo (timestamp)
  
  
• 131 Rota de origem fraca (lsr)
  
  
• 137 Rota de origem restrita (ssr)

!

ip access-list extended ACL-IP-OPTIONS
 permit ip any any option eool
 permit ip any any option record-route
 permit ip any any option timestamp
 permit ip any any option lsr
 permit ip any any option ssr
!

class-map ACL-IP-OPTIONS-CLASS
 match access-group name ACL-IP-OPTIONS
!

policy-map COPP-POLICY
 class ACL-IP-OPTIONS-CLASS
  drop
!

control-plane
 service-policy input COPP-POLICY
!

Nas políticas anteriores de CoPP, as entradas da lista de controle de acesso (ACEs) que correspondem a pacotes com a ação de permissão resultam no descarte desses pacotes pela função de queda do mapa de política, enquanto os pacotes que correspondem à ação de negação (não mostrada) não são afetados pela função de queda do mapa de política.

Controle a proteção plana

No Cisco IOS Software Release 12.4(4)T e posterior, a Proteção do Plano de Controle (CPPr - Control Plane Protection) pode ser usada para restringir ou policiar o tráfego do plano de controle pela CPU de um dispositivo Cisco IOS. Embora semelhante ao CoPP, o CPPr pode restringir ou policiar o tráfego com maior granularidade que o CoPP. CPPr divide o plano de controle agregado em três categorias de plano de controle separadas conhecidas como subinterfaces: Host, Trânsito e CEF. Existem subinterfaces de exceção.

Esta política de CPPr deixa cair os pacotes de trânsito recebidos por um dispositivo onde o valor TTL seja menos do que 6 e pacotes do trânsito ou de não-trânsito recebidos por um dispositivo onde o valor TTL seja zero ou um. A política de CPPr igualmente deixa cair pacotes com as opções IP selecionadas recebidas pelo dispositivo.

!

ip access-list extended ACL-IP-TTL-0/1
 permit ip any any ttl eq 0 1
!

class-map ACL-IP-TTL-0/1-CLASS
 match access-group name ACL-IP-TTL-0/1
!

ip access-list extended ACL-IP-TTL-LOW
 permit ip any any ttl lt 6
!

class-map ACL-IP-TTL-LOW-CLASS
 match access-group name ACL-IP-TTL-LOW
!

ip access-list extended ACL-IP-OPTIONS
 permit ip any any option eool
 permit ip any any option record-route
 permit ip any any option timestamp
 permit ip any any option lsr
 permit ip any any option ssr
!

class-map ACL-IP-OPTIONS-CLASS
 match access-group name ACL-IP-OPTIONS
!

policy-map CPPR-CEF-EXCEPTION-POLICY
 class ACL-IP-TTL-0/1-CLASS
  drop
 class ACL-IP-OPTIONS-CLASS
  drop
!

!-- Apply CPPr CEF-Exception policy CPPR-CEF-EXCEPTION-POLICY to
!-- the CEF-Exception CPPr sub-interface of the device

!

control-plane cef-exception
 service-policy input CPPR-CEF-EXCEPTION-POLICY
!

policy-map CPPR-TRANSIT-POLICY
 class ACL-IP-TTL-LOW-CLASS
  drop
!

control-plane transit
 service-policy input CPPR-TRANSIT-POLICY
!

Na política anterior de CPPr, as entradas da lista de controle de acesso que correspondem a pacotes com o resultado da ação de permissão era que esses pacotes eram descartados pela função de queda do mapa de política, enquanto os pacotes que correspondiam à ação de negação (não mostrada) não eram afetados pela função de queda do mapa de política.

Refira a compreendendo a proteção plana do controle e controle a proteção plana para obter mais informações sobre da característica de CPPr.

Trafique a identificação e o retorno de monitoramento

Às vezes, você pode precisar de identificar rapidamente e tráfego de rede do retorno de monitoramento, especialmente durante a resposta do incidente ou o desempenho da rede deficiente. O NetFlow e as ACLs de classificação são dois métodos principais para realizar isso com o software Cisco IOS. O NetFlow pode fornecer a visibilidade em todo o tráfego na rede. Adicionalmente, o NetFlow pode ser executado com coletores que podem fornecer a tensão do prazo e a análise automatizada. A classificação ACL é um componente dos ACL e exige o PRE-planeamento identificar o tráfego e a intervenção manual específicos durante a análise. Estas seções fornecem uma breve visão geral de cada característica.

Netflow

O NetFlow identifica atividades de rede anômalas e relacionadas à segurança pelo controle dos fluxos de rede. Os dados do NetFlow podem ser visualizados e analisados pela CLI ou podem ser exportados para um coletor NetFlow comercial ou freeware para agregação e análise. Os coletores do NetFlow, através de tendências de longo prazo, podem fornecer comportamento de rede e análise de uso. O NetFlow realiza a análise de atributos específicos dentro de pacotes IP e cria fluxos. A versão 5 é a versão mais usada do NetFlow; no entanto, a versão 9 é mais extensível. Os fluxos NetFlow podem ser criados com os dados de tráfego amostrados em ambientes de volume elevado.

O CEF, ou CEF distribuído, é um pré-requisito para ativar o NetFlow. O NetFlow pode ser configurado em roteadores e em interruptores.

Este exemplo ilustra a configuração básica do NetFlow. Em versões anteriores do software Cisco IOS, o comando para ativar o NetFlow em uma interface é ip route-cache flow em vez de ip flow {ingress | egress}.

!

ip flow-export destination <ip-address> <udp-port>
ip flow-export version <version>
!

interface <interface> 
 ip flow <ingess|egress> 
!

Este é um exemplo do NetFlow output do CLI. O atributo de SrcIf pode ajudar no retorno de monitoramento.

router#show ip cache flow
IP packet size distribution (26662860 total packets):
   1-32   64   96  128	160  192  224  256  288  320  352  384	416  448  480
   .741 .124 .047 .006 .005 .005 .002 .008 .000 .000 .003 .000 .001 .000 .000

    512  544  576 1024 1536 2048 2560 3072 3584 4096 4608
   .000 .000 .001 .007 .039 .000 .000 .000 .000 .000 .000

IP Flow Switching Cache, 4456704 bytes
  55 active, 65481 inactive, 1014683 added
  41000680 ager polls, 0 flow alloc failures
  Active flows timeout in 2 minutes
  Inactive flows timeout in 60 seconds
IP Sub Flow Cache, 336520 bytes
  110 active, 16274 inactive, 2029366 added, 1014683 added to flow
  0 alloc failures, 0 force free
  1 chunk, 15 chunks added
  last clearing of statistics never
Protocol	 Total	  Flows   Packets Bytes  Packets Active(Sec) Idle(Sec)
--------	 Flows	   /Sec     /Flow  /Pkt     /Sec     /Flow     /Flow
TCP-Telnet	 11512	    0.0        15    42      0.2      33.8      44.8
TCP-FTP 	  5606	    0.0 	3    45      0.0      59.5      47.1
TCP-FTPD	  1075	    0.0        13    52      0.0       1.2      61.1
TCP-WWW 	 77155	    0.0        11   530      1.0      13.9      31.5
TCP-SMTP	  8913	    0.0 	2    43      0.0      74.2      44.4
TCP-X		   351	    0.0 	2    40      0.0       0.0      60.8
TCP-BGP 	   114	    0.0 	1    40      0.0       0.0      62.4
TCP-NNTP	   120	    0.0 	1    42      0.0       0.7      61.4
TCP-other	556070	    0.6 	8   318      6.0       8.2      38.3
UDP-DNS 	130909	    0.1 	2    55      0.3      24.0      53.1
UDP-NTP 	116213	    0.1 	1    75      0.1       5.0      58.6
UDP-TFTP	   169	    0.0 	3    51      0.0      15.3      64.2
UDP-Frag	     1	    0.0 	1  1405      0.0       0.0      86.8
UDP-other	 86247	    0.1       226    29     24.0      31.4      54.3
ICMP		 19989	    0.0        37    33      0.9      26.0      53.9
IP-other	   193	    0.0 	1    22      0.0       3.0      78.2
Total:	       1014637	    1.2        26    99     32.8      13.8      43.9

SrcIf	      SrcIPaddress    DstIf	    DstIPaddress    Pr SrcP DstP Pkts
Gi0/1	      192.168.128.21  Local	    192.168.128.20  11 CB2B 07AF   3
Gi0/1	      192.168.150.60  Gi0/0	    10.89.17.146    06 0016 101F  55
Gi0/0	      10.89.17.146    Gi0/1	    192.168.150.60  06 101F 0016   9
Gi0/1	      192.168.150.60  Local	    192.168.206.20  01 0000 0303  11
Gi0/0	      10.89.17.146    Gi0/1	    192.168.150.60  06 07F1 0016   1

Refira ao NetFlow do Cisco IOS para obter mais informações sobre das capacidades do NetFlow.

Refira a introdução ao NetFlow do Cisco IOS - uma visão geral técnica para uma visão geral técnica do NetFlow.

Classificação ACL

A classificação ACL fornece a visibilidade no tráfego que atravessa uma relação. A classificação ACL não altera a política de segurança de uma rede e é construída tipicamente para classificar protocolos, endereços de origem, ou destinos individuais. Por exemplo, um ACE que permitisse todo o tráfego poderia ser separado em protocolos específicos ou em portas. Essa classificação mais granular do tráfego em ACEs específicos pode ajudar a fornecer visibilidade do tráfego de rede, pois cada categoria de tráfego tem seu próprio contador de ocorrências. Um administrador também pode separar a negação implícita no final de uma ACL em ACEs granulares para ajudar a identificar os tipos de tráfego negados.

Um administrador pode agilizar uma resposta a incidentes usando as ACLs de classificação com os comandos show access-list e clear ip access-list counters EXEC.

Este exemplo mostra a configuração de uma ACL de classificação para identificar o tráfego SMB antes de uma negação padrão:

!

ip access-list extended ACL-SMB-CLASSIFY
 remark Existing contents of ACL
 remark Classification of SMB specific TCP traffic 
 deny	tcp any any eq 139
 deny	tcp any any eq 445
 deny	ip any any 
!

Para identificar o tráfego que usa uma ACL de classificação, use o show access-list EXEC comando. Os contadores da ACL podem ser limpos com o clear ip access-list counters EXEC comando.

router#show access-list ACL-SMB-CLASSIFY 
Extended IP access list ACL-SMB-CLASSIFY
    10 deny tcp any any eq 139 (10 matches)
    20 deny tcp any any eq 445 (9 matches)
    30 deny ip any any (184 matches) 

Consulte Entendendo o Log da Lista de Controle de Acesso para obter mais informações sobre como habilitar os recursos de log nas ACLs.

Controle de acesso com mapas VLAN e lista de controle de acesso da porta

As lista de controle de acesso VLAN (VACL), ou os mapas VLAN e a porta ACL (PACL), fornecem a capacidade para reforçar o controle de acesso no tráfego não-roteado que é mais perto dos dispositivos de ponto final do que as lista de controle de acesso que são aplicadas às interfaces roteada.

Estas seções fornecem uma visão geral dos recursos, benefícios e possíveis cenários de uso de VACLs e PACLs.

Controle de acesso com mapas VLAN

As VACLs, ou mapas de VLAN que se aplicam a todos os pacotes, que entram na VLAN, fornecem a capacidade de impor o controle de acesso no tráfego entre VLANs. Isso não é possível com ACLs em interfaces roteadas. Por exemplo, um mapa de VLAN pode ser usado para impedir que os hosts contidos na mesma VLAN se comuniquem uns com os outros, o que reduz as oportunidades para que os invasores locais ou worms explorem um host no mesmo segmento de rede. Para negar o uso de um mapa de VLAN, crie uma lista de controle de acesso (ACL) que corresponda ao tráfego e, no mapa de VLAN, defina a ação como drop. Uma vez que um mapa VLAN é configurado, todos os pacotes que incorporam o LAN estão avaliados sequencialmente contra o mapa do VLAN configurado. Os mapas de acesso da VLAN suportam listas de acesso IPv4 e MAC; no entanto, eles não suportam logs ou ACLs IPv6.

Este exemplo usa uma lista de acesso nomeada estendida que ilustra a configuração desse recurso:

!

ip access-list extended <acl-name>
 permit <protocol> <source-address> <source-port> <destination-address>
     <destination-port>
!

vlan access-map <name> <number>
 match ip address <acl-name>
 action <drop|forward>
!

Este exemplo demonstra o uso de um mapa de VLAN para negar as portas TCP 139 e 445, bem como o protocolo vines-ip:

!

ip access-list extended VACL-MATCH-ANY
 permit ip any any
!

ip access-list extended VACL-MATCH-PORTS
 permit tcp 192.168.1.0 0.0.0.255 192.168.1.0 0.0.0.255 eq 445
 permit tcp 192.168.1.0 0.0.0.255 192.168.1.0 0.0.0.255 eq 139
!

mac access-list extended VACL-MATCH-VINES
 permit any any vines-ip
!

vlan access-map VACL 10
 match ip address VACL-MATCH-VINES 
 action drop
!

vlan access-map VACL 20 
 match ip address VACL-MATCH-PORTS
 action drop
!

vlan access-map VACL 30
 match ip address VACL-MATCH-ANY
 action forward
!

vlan filter VACL vlan 100 
!

Refira a configurar a segurança de rede com os ACL para obter mais informações sobre da configuração de mapas VLAN.

Controle de acesso com PACL

Os PACL podem somente ser aplicados à direção de entrada em interfaces física da camada 2 de um interruptor. Similar aos mapas VLAN, os PACL fornecem o controle de acesso em não-roteado ou tráfego na Camada 2. A sintaxe para a criação de PACLs, que tem precedência sobre os mapas de VLAN e as ACLs do roteador, é a mesma das ACLs do roteador. Se um ACL é aplicado a uma interface de camada 2, a seguir está referido como um PACL. A configuração envolve a criação de uma ACL de IPv4, IPv6 ou MAC e sua aplicação à interface de camada 2.

Este exemplo usa uma lista de acesso nomeada estendida para ilustrar a configuração deste recurso:

!

ip access-list extended <acl-name>
 permit <protocol> <source-address> <source-port> <destination-address> 
     <destination-port>
!

interface <type> <slot/port>
 switchport mode access
 switchport access vlan <vlan_number>
 ip access-group <acl-name> in 
!

Refira a seção ACL da porta de configurar a segurança de rede com os ACL para obter mais informações sobre da configuração dos PACL.

Controle de acesso com MAC

As listas de controle de acesso MAC ou listas estendidas podem ser aplicadas em uma rede IP com o uso deste comando no modo de configuração de interface:

Cat6K-IOS(config-if)#mac packet-classify

Observação: as listas de controle de acesso MAC classificam os pacotes da camada 3 como pacotes da camada 2. O comando é apoiado no Cisco IOS Software Release 12.2(18)SXD (para Sup720) e nos Cisco IOS Software Release 12.2(33)SRA ou Posterior.

Esse comando de interface deve ser aplicado à interface de entrada e instrui o mecanismo de encaminhamento a não inspecionar o cabeçalho IP. O resultado é que você pode usar uma lista de acesso MAC no ambiente IP.

Uso de VLAN privada

As VLANs privadas (PVLANs) são um recurso de segurança da camada 2 que limita a conectividade entre estações de trabalho ou servidores em uma VLAN. Sem PVLANs, todos os dispositivos em uma VLAN de camada 2 podem se comunicar livremente. Existem situações em que a segurança pode ser auxiliada pela limitação da comunicação entre dispositivos em uma única VLAN. Por exemplo, as PVLANs são frequentemente usadas para proibir a comunicação entre servidores em uma sub-rede publicamente acessível. Se um único servidor for comprometido, a falta de conectividade com outros servidores devido à aplicação de PVLANs pode ajudar a limitar o comprometimento para um servidor.

Há três tipos de VLANs privadas: VLANs isoladas, VLANs de comunidade e VLANs primárias. A configuração dos PVLAN utiliza preliminar e VLAN secundários. O VLAN principal contem todas as portas misturadas, que são descritas mais tarde, e inclui uns ou vários VLAN secundários, que podem ser isolados ou VLAN de comunidade.

Vlan isolado

A configuração de uma VLAN secundária como uma VLAN isolada impede completamente a comunicação entre dispositivos na VLAN secundária. Pode haver apenas uma VLAN isolada por VLAN principal e somente portas misturadas podem se comunicar com portas em uma VLAN isolada. As VLANs isoladas podem ser usadas em redes não confiáveis, como redes que suportam convidados.

Este exemplo de configuração configura o VLAN 11 como um VLAN isolado e associa-o ao VLAN principal, VLAN 20. Este exemplo também configura a interface FastEthernet 1/1 como uma porta isolada na VLAN 11:

!

vlan 11
 private-vlan isolated
!

vlan 20
 private-vlan primary
 private-vlan association 11
!

interface FastEthernet 1/1
 description *** Port in Isolated VLAN ***
 switchport mode private-vlan host 
 switchport private-vlan host-association 20 11
!

VLAN de comunidade

Uma VLAN secundária configurada como uma VLAN de comunidade permite a comunicação entre membros da VLAN e com quaisquer portas misturadas na VLAN principal. Contudo, nenhuma comunicação é possível entre todos os dois VLAN de comunidade ou de um VLAN de comunidade a um VLAN isolado. As VLANs de comunidade devem ser usadas para agrupar servidores que precisam de conectividade entre si, mas onde a conectividade para todos os outros dispositivos na VLAN não é necessária. Esse cenário é comum em uma rede publicamente acessível ou em qualquer lugar onde os servidores forneçam conteúdo a clientes não confiáveis.

Este exemplo configura um único VLAN de comunidade e configura os FastEthernet 1/2 da porta de switch como um membro desse VLAN. O VLAN de comunidade, VLAN 12, é um VLAN secundário ao VLAN principal 20.

!

vlan 12
 private-vlan community
!

vlan 20
 private-vlan primary
 private-vlan association 12
!

interface FastEthernet 1/2
 description *** Port in Community VLAN ***
 switchport mode private-vlan host 
 switchport private-vlan host-association 20 12
!

Portas misturadas

As portas de switch colocadas na VLAN principal são conhecidas como portas promíscuas. As portas promíscuas podem se comunicar com todas as outras portas nas VLANs primária e secundária. Roteadores ou as interfaces de firewall são os dispositivos mais comuns encontrados nestes VLAN.

Este exemplo de configuração combina os exemplos precedentes isolado e do VLAN de comunidade e adiciona a configuração dos FastEthernet 1/12 da relação como uma porta misturada:

!

vlan 11
 private-vlan isolated
!

vlan 12
 private-vlan community
!

vlan 20
 private-vlan primary
 private-vlan association 11-12
!

interface FastEthernet 1/1
 description *** Port in Isolated VLAN ***
 switchport mode private-vlan host 
 switchport private-vlan host-association 20 11
!

interface FastEthernet 1/2
 description *** Port in Community VLAN ***
 switchport mode private-vlan host 
 switchport private-vlan host-association 20 12
!

interface FastEthernet 1/12
 description *** Promiscuous Port ***
 switchport mode private-vlan promiscuous
 switchport private-vlan mapping 20 add 11-12
!

Quando você implementa PVLANs, é importante garantir que a configuração da Camada 3 em vigor suporte as restrições impostas por PVLANs e não permita que a configuração de PVLAN seja subvertida. Um filtro de Camada 3 com uma ACL de Roteador ou firewall pode impedir a subversão da configuração da PVLAN.

Refira os VLAN privados (os PVLAN) - Promíscuo, isolado, a comunidade, encontrado no homepage da Segurança para LAN, para obter mais informações sobre do uso e da configuração dos VLAN privados.

Conclusão

Este documento fornece uma visão geral ampla dos métodos que podem ser usados para proteger um dispositivo de sistema Cisco IOS. Se você proteger os dispositivos, aumentará a segurança geral das redes que você gerencia. Nesta visão geral, a proteção da gestão, o controle, e os planos dos dados são discutidos, e as recomendações de configuração são fornecidos. Sempre que possível, detalhes suficientes são fornecidos para a configuração de cada característica associada. Contudo, as referências detalhadas são fornecidas em todos os casos para fornecê-lo com a informação necessária para uma avaliação adicional.

Reconhecimentos

Algumas descrições de recurso neste original foram escritas por equipes de desenvolvimento da informação da Cisco.

Apêndice: Lista de verificação de fortalecimento do dispositivo IOS Cisco

Esta lista de verificação é uma coleção de todas as etapas para fortalecer os dispositivos apresentadas neste guia. Os administradores podem usá-la enquanto um lembrete de todo o endurecimento caracteriza usado e considerado para um dispositivo IOS Cisco, mesmo se uma característica não foi executada porque não se aplicou. É recomendável que os administradores avaliem cada opção em relação ao possível risco antes de implementá-la.

Plano de gerenciamento

• Senhas
  
  
  • Permita o hashing MD5 (opção secreta) para senhas habilitadas e de usuários locais.
  • Configurar o fechamento da nova tentativa da senha
  • Desabilite a recuperação de senha (considere o risco)
    
    
• Desabilite serviços não utilizados
  
  
• Configurar manutenções de atividade TCP para sessões de gerenciamento
  
  
• Ajuste a memória e as notificações de threshold de CPU
  
  
• Configurar
  
  
  • Notificações da memória e de threshold de CPU
  • Memória da reserva para o acesso de console
  • Detector de escape de memória
  • Detecção do excesso de buffer
  • Coleção aumentada do crashinfo
    
    
• Use iACLs para restringir o acesso de gerenciamento
  
  
• Filtre (considere o risco)
  
  
  • Pacotes ICMP
  • Fragmentos IP
  • Opções IP
  • Valor TTL nos pacotes
    
    
• Controle a proteção plana
  
  
  • Configurar filtragem de porta
  • Configurar pontos iniciais da fila
    
    
• Acesso de gerenciamento
  
  
  • Use a proteção do plano de gerenciamento para restringir interfaces de gerenciamento
  • Ajuste o intervalo do executivo
  • Use um protocolo de transporte cifrado (tal como o SSH) para o acesso CLI
  • Controle o transporte para as linhas vty e o tty (opção da classe do acesso)
  • Avisar com o uso de banners
    
    
• AAA
  
  
  • Use o AAA para a autenticação e a reserva
  • Use AAA (TACACS+) para o comando authorization
  • Usar AAA para fins de conta
  • Use servidores AAA redundantes
    
    
• SNMP
  
  
  • Configurar as comunidades SNMPv2 e aplique ACL
  • Configurar o SNMPv3
    
    
• Registro
  
  
  • Configurar logs centralizados
  • Definir níveis de log para todos os componentes relevantes
  • Set log source-interface
  • Configurar granularidade do carimbo de data/hora do log
    
    
• Gerenciamento de configuração
  
  
  • Substitua e rollback
  • Configuração Exclusiva de Alteração de Acesso
  • Configuração de resiliência do software
  • Notificações da alteração de configuração

Controle o plano

• Desabilitar (considere o risco)
  
  
  • Redirecionamentos de ICMP
  • ICMP não alcançável
  • Proxy ARP
    
    
• Configurar a autenticação do NTP se o NTP for usado
  
  
• Configurar Políticas/Proteção do Plano de Controle (filtros de porta, limiares de fila)
  
  
• Fixe protocolos de roteamento
  
  
  • BGP (TTL, MD5, prefixos máximos, listas de prefixo, trajeto ACL do sistema)
  • IGP (MD5, interface passiva, filtros de rota, consumo de recursos)
    
    
• Configurar limitadores da taxa do hardware
  
  
• Fixe os primeiros protocolos da redundância de salto (GLBP, HSRP, o VRRP)

Plano dos dados

• Configurar a queda seletiva das opções IP
  
  
• Desabilitar (considere o risco)
  
  
  • Rotas de origem IP
  • Broadcasts direto de IP
  • Redirecionamentos de ICMP
    
    
• Broadcasts direto de IP do limite
  
  
• Configurar tACLs (considere o risco)
  
  
  • Filtre o ICMP
  • Filtre fragmentos IP
  • Filtre opções IP
  • Filtre valores TTL
    
    
• Configure proteções anti-falsificação exigidas
  
  
  • ACLs
  • Proteção de origem de IP
  • Inspeção ARP dinâmica
  • Unicast RPF
  • Segurança da porta
    
    
• Controle a proteção plana (a CEF-exceção do controle plano)
  
  
• Configurar o NetFlow e a classificação ACL para a identificação do tráfego
  
  
• Configure exigiu o controle de acesso ACL (mapas VLAN, PACL, o MAC)
  
  
• Configurar VLAN privados