O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve como proteger os dispositivos de sistema Cisco IOS® e aumentar a segurança geral da sua rede.
Não existem requisitos específicos para este documento.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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 secret
deve ser usado, em vez do comandoenable password
mais antigo. O enable password
usa 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 secret
e 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.
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 ousername
comando. 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 global
.username secret
!
username <name> secret <password>
!
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).
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.
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:
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:
no ip finger
para 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.
no ip bootp server
de configuração global para desativar o Bootstrap Protocol (BOOTP).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]
!
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
!
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
!
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.
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.
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
!
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.
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
!
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>
!
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.
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
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:
Estas seções descrevem cada cenário detalhadamente:
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
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:
Para habilitar a funcionalidade de cliente SMI posteriormente, insira o comando vstack em todos os switches clientes, manualmente ou com um script.
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:
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:
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.
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
!
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.
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
!
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.
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.
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
!
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.
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:
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.
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.
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.
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
!
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.)
!
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
!
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
!
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.
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.
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:
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.
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.
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.
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>
!
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.
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
!
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
!
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:
Consulte para distribuir os server do controle de acesso para mais informação.
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.
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.
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.
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.
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.
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:
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.
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.
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.
É 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/mypass@192.168.1.129/syslog
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.
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
!
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.
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.
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
!
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.
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.
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.
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 configuration mode exclusive
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
!
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.
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.
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.
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.
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.
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
.
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.
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.
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.
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:
Esta lista detalha vários métodos para determinar quais tipos de tráfego devem ser processados pela CPU do dispositivo IOS Cisco:
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.show interface switching
fornece informações sobre o número de pacotes que são comutados por processo por um dispositivo.show ip traffic
fornece informações sobre o número de pacotes IP:show policy-map control-plane
comando.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.
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.
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.
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:
Consulte Compreendendo a Proteção do Plano de Controle (CPPr) para obter mais informações sobre o uso do recurso CPPr.
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.
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.
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.
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>
!
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>
!
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.
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
!
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.
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.
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>
!
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
!
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>
!
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
!
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.
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.
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 drop
todos 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.
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
!
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
!
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
!
É 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.
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
!
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.
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
!
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.
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>
!
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.
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.
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.
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
!
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 .
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.
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:
Para obter mais informações sobre o Endurecimento de Plano de Dados, consulte a seção Endurecimento de Plano de Dados Geral.
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
!
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:
!
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:
!
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.
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.
À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.
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.
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.
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.
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
!
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.
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.
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.
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
!
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
!
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.
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.
Algumas descrições de recurso neste original foram escritas por equipes de desenvolvimento da informação da 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.
Revisão | Data de publicação | Comentários |
---|---|---|
2.0 |
12-Sep-2024 |
Revisão completa dos alertas do CCW, incluindo introdução, tradução automática, requisitos de estilo e dezenas de links atualizados. |
1.0 |
10-Dec-2001 |
Versão inicial |