IP : Serviços de endereçamento IP

Cisco guia para endurecer dispositivos IOS Cisco

29 Julho 2013 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Tradução Manual (7 Abril 2008) | Inglês (7 Junho 2011) | Feedback


Índice


Introdução

Este documento contem a informação para ajudá-lo a fixar seus dispositivos de sistema do ® do Cisco IOS, que aumenta a segurança total de sua rede. Estruturado em torno dos três planos em que as funções de um dispositivo de rede podem ser categorizadas, este original fornece uma vista geral de cada característica incluída e referências à documentação relacionada.

Os três planos funcionais de uma rede, o plano de gerenciamento, plano do controle, e o plano de dados, cada um fornece uma funcionalidade diferente que precisa de ser protegida.

  • Plano de gerenciamento - O plano de gerenciamento controla o tráfego que é enviado ao dispositivo IOS Cisco e composto das aplicações e dos protocolos tais como o SSH e o SNMP.

  • Plano do controle - O plano do controle de um dispositivo de rede processa o tráfego que é primordial a manter a funcionalidade da infra-estrutura de rede. O plano do controle consiste em aplicações e em protocolos entre dispositivos de rede, que inclui o Border Gateway Protocol (BGP), assim como os protocolos Interior Gateway Protocols (IGP) como o Enhanced Interior Gateway Routing Protocol (EIGRP) e o Open Shortest Path First (OSPF).

  • Plano de dados - O plano de dados encaminha dados através de um dispositivo de rede. O plano dos dados não inclui o tráfego que é enviado ao dispositivo local IOS Cisco.

A cobertura dos recursos de segurança neste documento fornece frequentemente bastante detalhes para que você configure a característica. Contudo, nos casos onde não faz, a característica é explicada de tal maneira que você pode avaliar se a atenção adicional à característica está exigida. Sempre que possível e apropriado, este documento contém as recomendações que, se executadas, ajudam a fixar a rede.

Pré-requisitos

Requisitos

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

Componentes Utilizados

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

Convenções

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos. Alguns exemplos da linha de comando neste original são envolvidos para aumentar a legibilidade.

Fixe operações

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

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

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

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

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

A fim manter uma rede segura, você precisa de estar ciente das Recomendações de Segurança da Cisco e das respostas que foram liberadas. Você precisa de ter o conhecimento de uma vulnerabilidade antes que a ameaça que possa levantar a uma rede possa ser avaliada. Refira a triagem do risco para anúncios da vulnerabilidade de segurança para o auxílio a este processo de avaliação.

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

A estrutura de autenticação, autorização e relatório (AAA) é vital para fixar 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. Veja a seção de utilização do autenticação, autorização e relatório deste documento para obter mais informações sobre de leveraging AAA.

Centralize a coleção e a monitoração do registro

A fim de ganhar uma compreensão da existência, emergência, e os eventos históricos relacionados aos incidentes de segurança, sua organização precisa de ter uma estratégia unificada para o logging de evento e a correlação. Esta estratégia deve entregar o registo de todos os dispositivos de rede e usar capacidades pré-embaladas e customizáveis da correlação.

Depois que o registo centralizado é executado, você deve desenvolver uma aproximação estruturada para registrar o seguimento da análise e do incidente. 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.

Veja a seção de registo dos melhores prática deste documento para obter mais informações sobre de como executar dispositivos de abertura da rede de IOS Cisco.

Use protocolos seguros quando possível

Muitos protocolos são usados a fim levar dados de gerenciamento de redes sensíveis. Você deve usar protocolos seguros sempre que possível. Uma escolha segura do protocolo inclui o uso do SSH em vez do telnet de modo que os dados de autenticação e a informação de gerenciamento sejam cifrados. Além, você deve usar protocolos de transferência de arquivo seguros quando você copia dados de configuração. Um exemplo é o uso do protocolo da cópia segura (SCP) no lugar do FTP ou do TFTP.

Veja a seção interativa de fixação das sessões de gerenciamento deste documento para obter mais informações sobre da gestão segura dos dispositivos IOS Cisco.

Ganhe a visibilidade do tráfego com NetFlow

O NetFlow permite-o de monitorar fluxos de tráfego na rede. Pretendeu originalmente exportar a informação de tráfego para aplicativos de gerenciamento de rede, NetFlow pode igualmente ser usado a fim mostrar a informação de fluxo em um roteador. Esta capacidade permite que você considere que tráfego atravessa a rede no tempo real. Apesar da informação de fluxo ser exportada para um coletor remoto, é recomendado configurar dispositivos de rede para o NetFlow de modo que possa ser usado de forma reativa, se necessário.

Mais informação sobre esta característica está disponível na seção da identificação e do retorno de monitoramento do tráfego deste documento e em http://www.cisco.com/en/US/products/ps6601/products_ios_protocol_group_home.html (somente clientes registrados).

Gerenciamento de configuração

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

Você pode usar arquivos de configuração para rolar para trás as mudanças que são feitas aos dispositivos de rede. Em um contexto de segurança, os arquivos de configuração podem igualmente ser usados a fim determinar que alterações de segurança foram feitas e quando estas mudanças ocorreram. Conjuntamente com dados de registro AAA, esta informação pode ajudar no exame de segurança dos dispositivos de rede.

A configuração de um dispositivo IOS Cisco contém muitos detalhes sensíveis. Os nomes de usuário, as senhas, e os índices de lista de controle de acesso são exemplos deste tipo de informação. O repositório que você usa a fim arquivar configurações do dispositivo IOS Cisco precisa de ser fixado. O acesso incerto a esta informação pode minar a segurança da toda a rede.

Plano de gerenciamento

O plano de gerenciamento consiste nas funções que conseguem os objetivos da gestão da rede. Isto inclui as sessões de gerenciamento interativas que usam o SSH, assim como o estatística-recolhimento com SNMP ou NetFlow. Quando você considera a segurança de um dispositivo de rede, é crítico que o plano de gerenciamento esteja protegido. Se um incidente de segurança pode minar as funções do plano de gerenciamento, pode ser impossível para você recuperar ou estabilizar a rede.

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

Plano de gerenciamento geral de endurecimento

O plano de gerenciamento é usado a fim alcançar, configurar, e controlar um dispositivo, assim como monitora suas operações e a rede em que é distribuído. O plano de gerenciamento é o plano que recebe e envia o tráfego para operações destas funções. Você deve fixar o plano de gerenciamento e o plano do controle de um dispositivo, porque os funcionamentos do plano do controle afetam diretamente funcionamentos do plano de gerenciamento. Esta lista de protocolos é usada pelo plano de gerenciamento:

  • Protocolo simples de gestão de rede

  • Telnet

  • Protocolo secure shell

  • Protocolo de transferência de arquivo

  • Protocolo trivial file transfer

  • Protocolo da cópia segura

  • TACACS+

  • RADIUS

  • Netflow

  • Protocolo de tempo de rede

  • Syslog

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

Gerenciamento de senha

Acesso do controle das senhas aos recursos ou aos dispositivos. Isto é realizado com a definição uma senha ou um segredo que sejam usados a fim autenticar pedidos. Quando um pedido é recebido para o acesso a um recurso ou a um dispositivo, o pedido está desafiado para a verificação da senha e da identidade, e o acesso pode ser concedido, negado, ou limitado baseado 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. Contudo, note que uma senha localmente configurada para o acesso de privilegiado é ainda seja necessário no caso da falha do TACACS+ ou dos serviços de raio. 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 a fim ajustar a senha que concede o acesso administrativo privilegiado ao sistema do Cisco IOS. O comando enable secret deve ser usado, ao invés do comando enable password mais veho. O comando enable password usa um algoritmo de criptografia fraco.

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

O service password-encryption de configuração global dirige o Cisco IOS Software para criptografar as senhas, Challenge Handshake Authentication Protocol (CHAP) segredos, e os dados similares que são salvas no arquivo de configuração. Tal criptografia é útil a fim impedir observadores ocasionais das senhas da leitura, como quando olham a tela sobre o agrupamento de um administrador. Contudo, o algoritmo usado pelo comando service password-encryption é 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.

Quando este algoritmo de criptografia fraco não for usado pelo comando enable secret, está usado pelo comando global configuration da senha da possibilidade, assim como pelo comando password line configuration. As senhas deste tipo devem ser eliminadas e o comando enable secret ou a característica aumentada da segurança de senha precisam de ser usados.

O comando enable secret e a característica aumentada da segurança de senha usam o Message Digest 5 (MD5) para o hashing da 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 do dicionário, um atacante tenta cada palavra em um dicionário ou a outra lista de senhas do candidato a fim de encontrar uma combinação. Conseqüentemente, os arquivos de configuração devem firmemente ser armazenados e somente compartilhado com os indivíduos confiados.

Segurança de senha aumentada

A segurança de senha aumentada característica, introduzida no Cisco IOS Software Release 12.2(8)T, permite que um administrador configure o hashing MD5 das senhas para o comando username. 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 de 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.

A fim cifrar uma senha do usuário com hashing MD5, emita o comando global configuration do username secreto.


!

username <name> secret <password>

!

Refira a segurança de senha aumentada para obter mais informações sobre desta característica.

Fechamento da nova tentativa da senha de login

A característica do fechamento da nova tentativa da senha de login, adicionada no Cisco IOS Software Release 12.3(14)T, permite-o para travar para fora uma conta de usuário local após um número configurado de tentativas de login mal sucedidas. Uma vez que um usuário é fechado para fora, sua conta é fechada até que você a destrave. Um usuário autorizado que seja configurado com nível de privilégio 15 não pode ser fechado para fora com esta característica. O número de usuários com nível de privilégio 15 deve ser mantido a um mínimo.

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>

!

Esta característica igualmente aplica-se aos métodos de autenticação tais como a CHAP e o protocolo password authentication (PAP).

Refira o fechamento da nova tentativa da senha de login para obter mais informações sobre desta característica.

Recuperação de Senha Sem Serviço

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


!

no service password-recovery

!

O Cisco IOS Software fornece um procedimento de recuperação de senha que confie no acesso ao modo ROMMON usando a tecla break durante a inicialização do sistema. No modo ROMMON, o software do dispositivo pode ser recarregado para alertar uma configuração de sistema nova que inclua uma senha nova.

O procedimento de recuperação da senha atual permite qualquer um com acesso de console de alcançar o dispositivo e sua rede. Nenhuma característica da recuperação de senha do serviço impede a conclusão da seqüência de tecla break e entrar do modo ROMMON durante a inicialização do sistema.

Se nenhuma recuperação de senha do serviço é permitida em um dispositivo, recomenda-se que uma cópia autônoma da configuração de dispositivo salvar e que uma configuração que arquiva a solução esteja executada. Se é necessário recuperar uma vez a senha de um dispositivo IOS Cisco esta característica está permitida, a configuração completa está suprimida.

Refira a nenhuma recuperação de senha do serviço e fixe o exemplo de configuração ROMMON para obter mais informações sobre esta característica.

Desabilite serviços não utilizados

Como uma melhor prática da segurança, todo o serviço desnecessário deve ser deficiente. Estes serviços desnecessários, especialmente aqueles que usam UDP (protocolo de datagrama de usuário), raramente são usados para propósitos legítimos, mas podem ser usados a fim lançar o DoS e outros ataques que são impedidos de outra maneira pela filtragem de pacote de informação.

Os serviços pequenos TCP e UDP devem ser deficientes. Estes serviços incluem:

  • eco (número de porta 7)

  • rejeite (número de porta 9)

  • dia (número de porta 13)

  • chargen (número de porta 19)

Embora o abuso dos serviços pequenos possa ser evitado ou feito menos perigoso por listas de acesso anti-falsificação, os serviços devem ser deficientes em todo o dispositivo acessível dentro da rede. Os serviços pequenos são deficientes por padrão nos Cisco IOS Software Release 12.0 e Mais Recentes. No software anterior, o no service tcp-small-servers e no service udp-small-servers comandos de configuração global podem ser emitidos a fim de desabilitá-los.

Esta é uma lista de serviços adicional que devem ser deficientes se não no uso:

  • Não emita o no ip fingercomando global configuration a fim de desabilitar o serviço Finger. Cisco IOS Software Release posteriores ao 12.1(5) e 12.1(5)T desabilitam este serviço por padrão.

  • Emita o comando global configuration do no ip bootp server a fim desabilitar o protocolo de bootstrap (BOOTP).

  • No Cisco IOS Software Release 12.2(8)T e posterior, emita o comando ignore BOOTP DHCP IP no modo de configuração global a fim desabilitar o BOOTP. Isto deixa serviços do protocolo de configuração dinâmica host (DHCP) habilitados.

  • Os serviços DHCP podem ser deficientes se os serviços da transmissão de DHCP não forem exigidos. Emita o comando no service dhcp no modo de configuração global.

  • Não emita nenhum comando mop enabled no modo de configuração da interface a fim desabilitar o serviço de Protocolo de Manutenção de Operação (MOP).

  • Emita o no ip domain-lookup comando de configuração global a fim desabilitar serviços da resolução do Domain Name System (DNS).

  • Emita o no service pad command no modo de configuração global a fim desabilitar o serviço pacote de montagem/desmontagem (PAD), o qual é usado para as redes X.25.

  • O Server do HTTP pode ser deficiente com o comando no ip http server no modo de configuração global, e o server seguro HTTP (HTTPS) pode ser deficiente com no ip http secure-server comando de configuração global .

  • A menos que os dispositivos IOS Cisco recuperarem configurações da rede durante a partida, o comando de configuração global do no service config deve ser usado. Isto impede que o dispositivo IOS Cisco tente encontrar um arquivo de configuração na rede usando o TFTP.

  • O protocolo cisco discovery (CDP) é um protocolo de rede usado a fim de descobrir outros dispositivos permitidos CDP para a adjacência vizinha e a topologia de rede. O CDP pode ser usado por sistemas de gerenciamento de rede (NMS) ou durante o Troubleshooting. O CDP deve ser deficiente em todas as relações que são conectadas às redes não confiáveis. Isto é realizado com o comando interface do no cdp enable. Alternativamente, o CDP pode ser desabilitada globalmente com o comando de configuração global do no cdp run. Note que o CDP pode ser usado por um usuário malicioso para o reconhecimento e o traço da rede.

  • O protocolo de descoberta da camada de enlace (LLDP) é um protocolo de IEEE definido em 802.1AB. LLDP é similar ao CDP. Contudo, este protocolo permite a interoperabilidade entre os outros dispositivos que não apoiam o CDP. LLDP deve ser tratado da mesma forma como o CDP e desabilitado em todas as relações que conectam às redes não confiáveis. A fim realizar isto, emita o no lldp transmit e no lldp receive comandos configuração de interface. Emita o comando no lldp run global configuration a fim de desabilitar o LLDP global. LLDP pode igualmente ser usado por um usuário malicioso para o reconhecimento e o traço da rede.

EXEC timeout

A fim de ajustar o intervalo o intérprete do comando exec espera a entrada de usuário antes que termine uma sessão, emita o comando exec-timeout linha de configuração. O comando exec-timeout deve ser usado a fim de terminar sessões nas linhas vty ou tty que são deixadas inativas. Por padrão, as sessões são desconectadas após minutos 10 de inatividade.


!

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

!

Keepalives para sessões de TCP

O tcp-keepalive- do serviço e service tcp-keepalive-out comandos de configuração global para enviar o TCP keepalives para sessões de TCP. Esta configuração deve ser usada a fim permitir manutenções de atividade TCP em conexões de entrada ao dispositivo e às conexões externas do dispositivo. Isto assegura-se de que o dispositivo na extremidade remota da conexão seja ainda acessível e que as conexões entreabertas ou órfãs são removidas do dispositivo IOS Cisco local.


!

service tcp-keepalive-in
service tcp-keepalive-out

!

Usando interfaces de gerenciamento

O plano de gerenciamento de um dispositivo é em-faixa ou fora da banda alcançado em um exame ou no Logical Management Interface. Idealmente, ambos os gerenciamentos de acesso em-banda e fora de banda existem para cada dispositivo de rede de modo que o plano de gerenciamento possa ser alcançado durante paradas de rede.

Uma das relações as mais comuns usadas para o acesso em-faixa a um dispositivo é a interface lógica de loopback. 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 isso seja usado 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 que a interface de loopback é configurada em um dispositivo, pode ser usada por protocolos do plano de gerenciamento, tais como o SSH, o SNMP, e o syslog, a fim de enviar e receber tráfego.

Notificações do ponto inicial da memória

A notificação do ponto inicial da memória da característica, adicionada no Cisco IOS Software Release 12.3(4)T, permite que você abrande condições de memória baixa em um dispositivo. Esta característica usa dois métodos para realizar esta: Notificação do ponto inicial da memória e reserva da memória.

A notificação do ponto inicial da memória gera um mensagem de registro a fim indicar que a memória livre em um dispositivo caiu mais baixo do que o limiar 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 da memória é usada de modo que a memória suficiente esteja disponível para notificações críticas. Este exemplo de configuração demonstra como habilitar esta característica. Isto assegura que os processos de gerenciamento continuem a funcionar quando a memória do dispositivo é esgotada.


!

memory reserve critical <value>

!

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

Notificação do limiar CPU

Introduzido no Cisco IOS Software Release 12.3(4)T, a característica da notificação do limiar CPU permite que você detecte e seja notificado quando a carga de CPU em um dispositivo cruza um limiar configurado. Quando o ponto inicial é cruzado, o dispositivo gera e envia um mensagem de armadilha de SNMP. Dois métodos do limiar da utilização CPU são apoiados no Cisco IOS Software: Limiar de elevação e limiar de queda.

Este exemplo de configuração mostra como permitir os limiares de elevação e de queda que provocam um mensagem de notificação do limiar de CPU:


!

snmp-server enable traps cpu threshold

!

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

!

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

!

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

Memória da reserva para o acesso de console

No Cisco IOS Software Release 12.4(15)T e Posterior, a memória da reserva para a característica do acesso de console pode ser usada a fim de reservar bastante memória para assegurar o acesso de console a um dispositivo IOS Cisco para administrativo e propósitos de Troubleshooting. Esta característica é especialmente benéfica quando a memória do dispositivo esteja baixa. Você pode emitir o comando global configuration do console da reserva da memória a fim de permitir esta característica. Este exemplo configura um dispositivo IOS Cisco para reservar 4096 quilobytes por este motivo.


!

memory reserve console 4096

!

Refira a memória da reserva para o acesso de console para obter mais informações sobre esta característica.

Detector de escape de memória

Introduzido no Cisco IOS Software Release 12.3(8)T1, a característica do detector de escape de memória permite que você detecte escapes de memória em um dispositivo. O detector de escape de memória pode encontrar escapes em todos os conjuntos de memória, buffers de pacotes, e pedaços. 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 show memory debug leaks EXEC para detectar se existem vazamentos de memória.

Refira ao detector de escape de memória para obter mais informações sobre esta característica.

Excesso de buffer: Detecção e correção da Redzone de corrupção

No Cisco IOS Software Release 12.3(7)T e Mais Recente, o excesso de buffer: A detecção e correção da característica da corrupção de Redzone pode ser permitida sobre por um dispositivo a fim detectar e corrigir um excesso do bloco de memória e continuar operações.

Estes comandos de configuração global podem ser usados a fim de permitir esta característica. Uma vez que configurado, o comando do excesso da memória da mostra pode ser usado a fim indicar as estatísticas da detecção e correção do excesso de buffer.


!

exception memory ignore overflow io
exception memory ignore overflow processor

!

Refira ao excesso de buffer: Detecção e correção da corrupção de Redzone para obter mais informações sobre esta característica.

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

A característica aumentada da coleção do arquivo crashinfo (informações de travamento) suprimem automaticamente de arquivos crashinfo (informações de travamento) velhos. Esta característica, adicionada no Cisco IOS Software Release 12.3(11)T, permite que um dispositivo recupere o espaço para criar arquivos crashinfo (informações de travamento) novos quando o dispositivo causa um crash. Esta característica igualmente permite que a configuração do número de arquivos crashinfo (informações de travamento) sido salvar.


!

exception crashinfo maximum files <number-of-files>

!

Refira a coleção aumentada do arquivo crashinfo (informações de travamento) para obter mais informações sobre desta característica.

Protocolo de tempo de rede

O protocolo Network Time Protocol (NTP) é um não serviço especialmente perigoso, mas todo o serviço unneeded pode representar um vetor do ataque. Se o NTP é usado, é importante configurar explicitamente um origem de tempo confiado e usar a autenticação apropriada. A hora exata e segura for exigida para finalidades syslog, como durante investigações judiciais dos ataques potenciais, assim como para a conectividade de VPN bem sucedida quando segundo certificados para a autenticação da fase 1.

  • Zona de hora (fuso horário) NTP - Ao configurar o NTP a zona de hora (fuso horário) precisa de ser configurada de modo que os timestamps possam exatamente ser correlacionados. Há geralmente duas aproximações a configurar a zona de hora (fuso horário) para dispositivos em uma rede com uma presença global. Um método é configurar todos os dispositivos de rede com o tempo universal coordenado (UTC) (previamente horário de Greenwich (GMT)). A outra aproximação é configurar dispositivos de rede com o fuso horário local. Mais informação nesta característica pode ser encontrada do “no fuso horário pulso de disparo” na documentação de produtos da Cisco.

  • Autenticação de NTP - Configurar a autenticação de NTP oferece a garantia que os mensagens de NTP estão trocados entre peers NTP de confiança. Refira ao NTP autenticam e a autenticação-chave NTP para obter mais informações sobre de como configurar a autenticação de NTP.

Limitando o acesso à rede com infra-estrutura ACL

Planejado para impedir uma comunicação direta desautorizada aos dispositivos de rede, as lista de controle de acesso da infra-estrutura (iACLs) são um dos controles de segurança os mais críticos que podem ser executados nas redes. A infra-estrutura ACL leverage a ideia que quase todo o tráfego de rede atravessa a rede e não está destinado à rede própria.

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. Os exemplos comuns destes 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 aplicação dos iACLs pode ser facilitada com o uso do endereçamento distinto para dispositivos da infra-estrutura de rede. Refira uma aproximação orientada segurança ao endereçamento de IP para obter mais informações sobre das implicações de segurança do endereçamento de IP.

Esta configuração do iACL do exemplo ilustra a estrutura que deve ser usada como um ponto de início quando você começa o processo de implementação do 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 Proteção de Sua Base: Lista de controle de acesso da proteção de infra-estrutura para obter mais informações sobre da infra-estrutura ACL.

Filtração do pacote ICMP

O Internet Control Message Protocol (ICMP) é projetado como um protocolo de controle de IP. Como tal, as mensagens que transporta podem ter ramificação de grande envergadura ao TCP e aos protocolos IP em geral. Quando as ferramentas de Troubleshooting da rede executarem o ping e traceroute use o ICMP, a conectividade externa do ICMP é raramente necessária para a operação apropriada de uma 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 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

!

Fragmentos de filtração IP

A filtração de pacotes IP fragmentados pode ser um desafio aos dispositivos de segurança. Isto é porque a informação da camada 4 que é usada a fim de filtrar o TCP e os pacotes de UDP está presente somente 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 Cisco IOS Software avalia estes fragmentos não iniciais contra o ACL e ignora toda a informação de filtragem da camada 4. Isto faz com que os fragmentos não iniciais sejam avaliados unicamente na camada 3 parcelas de todo o ACE configurado.

Neste exemplo de configuração, se um pacote de TCP destinado a 192.168.1.1 na porta 22 é fragmentads no trânsito, o fragmento inicial é deixado cair como esperado pelo segundo ACE baseado na informação da camada 4 dentro do pacote. Contudo, os fragmentos (não-iniciais) todos os restantes são permitidos pelo primeiro ACE baseado completamente na informação da camada 3 no pacote e no 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 nas tentativas de iludir a detecção pelo Intrusion Detection Systems. É por estas razões que os fragmentos IP são usados frequentemente nos ataques, e porque devem explicitamente ser filtrados na parte superior de todos os iACLs configurados. Este exemplo ACL inclui a filtração detalhada de fragmentos IP. A funcionalidade deste exemplo deve ser usada conjuntamente 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

!

Refira a lista de controle de acesso e fragmentos IP para obter mais informações sobre a manipulação ACL de pacotes IP fragmentados.

Apoio ACL para opções IP de filtração

Apoio adicionado Cisco IOS Software Release 12.3(4)T para o uso dos ACL a filtrar os pacotes IP baseados nas opções IP que são 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. Isto exige um nível do esforço da CPU que não é exigido para os pacotes típicos que atravessam a rede. A presença de opções IP dentro de um pacote pode igualmente indicar uma tentativa de subverter controles de segurança na rede ou de alterar de outra maneira as características do trânsito de um pacote. É por estas razões que os pacotes com opções IP devem ser filtrados na borda da rede.

Este exemplo deve ser usado com os ACE dos exemplos anteriores a fim de incluir a filtração completa dos 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

!

Refira ao apoio ACL para opções IP de filtração para obter mais informações sobre esta funcionalidade.

Apoio ACL para filtrar no valor TTL

Apoio adicionado Cisco IOS Software Release 12.4(2)T ACL para os pacotes IP de filtração baseados no valor do 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 pelo sistema operacional, quando o TTL de um pacote alcança zero, o pacote deve ser deixado cair. 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 esta função quando o número de pacotes IP de expiração é baixo, mas se o número de pacotes de expiração é alto, a geração e a transmissão destas mensagens podem consumir todos os recursos do CPU disponíveis. Isto apresenta um vetor do ataque DoS. É por esta razão que os dispositivos precisam ser endurecidos contra os ataques DoS que utilizam uma taxa alta de pacotes IP de expiração.

Recomenda-se que as organizações filtrem os pacotes IP com baixos valores TTL na borda da rede. Os pacotes de filtragem completos com os valores TTL insuficientes para atravessar a rede abrandam a ameaça dos ataques dos estabelecimentos de base 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

!

Note que alguns protocolos fazem o uso legítimo dos pacotes com baixos valores TTL. o eBGP é um tal protocolo. Refira a identificação e a mitigação do ataque da expiração TTL para obter mais informações sobre mitigar ataques de expiração-estabelecimentos de bases TTL.

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

Fixando sessões de gerenciamento interativas

As sessões de gerenciamento aos dispositivos permitem a capacidade para ver e recolher a informação sobre um dispositivo e suas operações. Se esta informação é divulgada a um usuário malicioso, o dispositivo pode transformar-se o alvo de um ataque, comprometido, e usado a fim de executar ataques adicionais. Qualquer um com acesso de privilegiado a um dispositivo tem a capacidade para o controle administrativo completo desse dispositivo. Fixar sessões de gerenciamento é imperativa impedir a divulgação e o acesso não autorizado da informação.

Proteção do plano de gerenciamento

Começando com o Cisco IOS Software Release 12.4(6)T, a proteção do plano de gerenciamento da característica (PMP (produção máxima possível)) permite que um administrador restrinja em que tráfego de gerenciamento das relações pode ser recebido por um dispositivo. Isto permite ao administrador o controle adicional sobre um dispositivo e como o dispositivo é alcançado.

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


!

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

!

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

Controle a proteção plana

Controle construções planas da proteção (CPPr) na funcionalidade do policiamento plano do controle a fim o tráfego plano restringir e de controle de polícia que é destinado ao processador de rotas do dispositivo de IOS. CPPr, adicionado no Cisco IOS Software Release 12.4(4)T, divide o plano do controle nas categorias separadas do plano do controle que são sabidas como subinterfaces. Três subinterfaces planas do controle existem: Host, trânsito e CEF-Exceção. Além disso, CPPr inclui estes recursos de proteção adicionais do plano do controle:

  • Característica da Porta-filtração - Esta característica prevê o policiamento ou deixar cair dos pacotes que vão a fechado ou à não-escuta TCP e às portas UDP.

  • Recursos de política Fila-iniciais - Esta característica limita o número de pacotes para um protocolo especificado que são permitidos na fila de entrada do plano IP do controle.

CPPr permite que um administrador classifique, policie, e restrinja o tráfego que é enviado a um dispositivo para propósitos do gerenciamento usando a subinterface do host. Os exemplos de pacotes que são classificados para a categoria da subinterface do host incluem o tráfego de gerenciamento tal como o SSH ou o telnet e os protocolos de roteamento.

Note que CPPr não apoia o IPv6 e está restringido ao trajeto da entrada do 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.

Sessões de gerenciamento de criptografia

Porque a informação pode ser divulgada durante uma sessão de gerenciamento interativa, este tráfego deve ser cifrado de modo que um usuário malicioso não possa aceder aos dados que estão sendo transmitidos. Criptografar o tráfego permite uma conexão de acesso remoto seguro ao 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 a conexão de gerenciamento do acesso remoto criptografado e fixo a um dispositivo usando as características SSH ou HTTPS (protocolo secure hypertext transfer). O Cisco IOS Software apoia a versão de SSH 1,0 (SSHv1), a versão de SSH 2,0 (SSHv2), e o HTTPS que se usa fixa a camada de soquetes (SSL) e o Transport Layer Security (TLS) para a autenticação e a criptografia de dados. Note que SSHv1 e SSHv2 não são compatíveis.

O Cisco IOS Software também apoia o protocolo da cópia segura (SCP), que permite uma conexão criptografada e segura para configurações de dispositivo ou imagens do software de cópia. 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 é um 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.

Refira o HTTPS - Server do HTTP e cliente com o guia de função do 3.0 SSL - 12.2T e guia de função seguro da Nota Técnica HTTP de Cisco (HTTPS) - 12.1E para obter mais informações sobre da característica do Cisco IOS Software HTTPS.

Refira o guia de função da cópia segura de Cisco (SCP) - 12.2T para obter mais informações sobre da característica do Cisco IOS Software SCP.

SSHv2

A característica do apoio SSHv2 introduzida no Cisco IOS Software Release 12.3(4)T permite que um usuário configure SSHv2. (O apoio SSHv1 foi executado em uma versão anterior do Cisco IOS Software.) o SSH é executado sobre uma camada de transporte confiável e fornece forte autenticação e capacidade de criptografia. O único transporte confiável que é definido para o SSH é TCP. O SSH fornece meios para alcançar firmemente e executar firmemente comandos em um outro computador ou dispositivo sobre uma rede. A característica do protocolo da cópia segura (SCP) que é em túnel sobre o SSH permite a transferência segura dos arquivos.

A configuração do exemplo a seguir permite SSHv2 (com SSHv1 desabilitado) em um dispositivo Cisco IOS:


!
    
hostname router

!

ip domain-name example.com    

!
    
crypto key generate rsa modulus 2048

!

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

!
    
ip ssh version 2

!

line vty 0 4   
transport input ssh    

!
 

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

Realces SSHv2 para chaves RSA

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

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

Um usuário SSH que tenta estabelecer as credenciais fornece uma assinatura cifrada usando a chave privada. A assinatura e a chave pública do usuário são enviadas ao servidor de SSH para a autenticação. O servidor de SSH computa uma mistura sobre a chave pública fornecida pelo usuário. A mistura está usada para determinar se o servidor tem uma entrada de compatibilidade. Se uma combinação é encontrada, a verificação da mensagem dos RSA-estabelecimentos de bases está executada usando 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 a chave Host restrita que verifica a bandeira é permitida no cliente, o cliente verifica se tenha a entrada da chave Host corresponder ao servidor préconfigurado. Se uma combinação é encontrada, o cliente tenta validar a assinatura usando a chave do host de servidor. Se o servidor é autenticado com sucesso, o estabelecimento de sessão continua; se não é terminado e mostra a mensagem “falha de autenticação de servidor”.

A configuração do exemplo a seguir permite o uso de chaves RSA com SSHv2 em um dispositivo IOS Cisco:


!
! Configure a hostname for the device
!

hostname router

!
! Configure a domain name
!

ip domain-name cisco.com

!
! Specify the name of the RSA key pair (in this case, "sshkeys") to use for SSH
!

 ip ssh rsa keypair-name sshkeys

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

 crypto key generate rsa usage-keys label sshkeys modulus 2048

!
! Configure an ssh timeout (in seconds) 
!
! The following enables a timeout of 120 seconds for SSH connections
!

ip ssh time-out 120

!
! Configure a limit of five (5) authentication retries
!

ip ssh authentication-retries 5

!
! Configure SSH version 2
!

ip ssh version 2 

!

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

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


!
! Configure a hostname for the device
!

hostname router

!
! Configure a domain name
!

ip domain-name cisco.com

!
! Generate RSA key pairs using a modulus of 2048 bits
!

crypto key generate rsa modulus 2048

!
! Configure SSH-RSA keys for user and server authentication on the SSH server
!

ip ssh pubkey-chain

!
! Configure the SSH username
!

        username ssh-user

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

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

A configuração do exemplo a seguir permite o cliente SSH do Cisco IOS de executar a autenticação de servidor dos RSA-estabelecimentos de bases.

	 

!
!

hostname router

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

crypto key generate rsa

!
! Configure SSH-RSA keys for user and server authentication on the SSH server
!

ip ssh pubkey-chain

!
! Enable the SSH server for public-key authentication on the router 
!

        server SSH-server-name

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

ip ssh stricthostkeycheck 

!

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

Console e Portas AUX

Nos dispositivos IOS Cisco, o console e as portas auxiliares (AUX) são as linhas assíncronas que podem ser usadas para o acesso local e remoto a um dispositivo. Você deve estar ciente que as portas de Console em dispositivos IOS Cisco têm privilégios especiais. Em particular, estes privilégios permitem que um administrador execute o procedimento de recuperação de senha. A fim de executar a recuperação de senha, um atacante não-autenticado precisaria de ter o acesso à porta de Console e à capacidade para interromper a potência ao dispositivo ou fazer com que o dispositivo cause um crash.

Todo o método usado a fim de alcançar a porta de Console de um dispositivo deve ser fixado de um modo que seja igual à segurança que é reforçada para o acesso de privilegiado a um dispositivo. Os métodos usados para acesso seguro deve incluir o uso do AAA, do EXEC-intervalo, e das senhas de modem se um modem é anexado ao console.

Se a recuperação de senha não é exigida, a seguir um administrador pode remover a capacidade para executar o procedimento de recuperação de senha usando o no service pasword-recovery comando de configuração global; contudo, uma vez que o comando no service password-recovery foi habilitado, um administrador não poderá executar a recuperação de senha em um dispositivo.

Na maioria das situações, a porta auxiliar de um dispositivo deve ser desabilitada ou para impedir o acesso não autorizado. Uma porta auxiliar pode ser desabilitada usando estes comandos:


!

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

!

Control vty e tty Lines

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

Uma linha vty é usada para todas conexões restantes da rede remota apoiadas pelo dispositivo, apesar do protocolo (o SSH, o SCP, ou o telnet são exemplos). A fim de assegurar que um dispositivo possa ser alcançado através de uma sessão de gerenciamento local ou remota, os controles apropriados devem ser reforçados em linhas vty e tty. Os dispositivos IOS Cisco têm um número limitado de linhas vty; o número de linha disponível pode ser determinado usando o comando show line exec. Quando todas as linhas vty estão no uso, as sessões de gerenciamento novas não podem ser estabelecidas, criando uma condição DoS para o acesso ao dispositivo.

O formulário mais simples de controle de acesso a um vty ou do tty de um dispositivo é com o uso da autenticação em todas as linhas apesar do lugar do dispositivo dentro da rede. Isto é crítico para linhas vty porque são acessíveis através da rede. Uma linha tty que seja conectada a um modem que está sendo usado para o acesso remoto ao dispositivo, ou uma linha tty que seja conectada à porta de Console dos outros dispositivos são igualmente acessíveis através da rede. Outros formulários de controles de acesso vty e tty podem ser reforçados usando os comandos configuration da entrada de transporte ou access-class, usando as características de CoPP e de CPPr, ou aplicando listas de acessos às relações no dispositivo.

A autenticação pode ser reforçada com o uso do AAA, que é o método recomendada para o acesso autenticado a um dispositivo, usando a base de dados de usuário local, ou pela autenticação de senha simples configurada diretamente na linha vty ou tty.

O comando exec-timeout deve ser usado a fim de terminar sessões nas linhas vty ou tty que são deixadas inativas. O comando service TCP-keepalive-in deve igualmente ser usado a fim permitir manutenções de atividade TCP em conexões recebidas ao dispositivo. Isto assegura de que o dispositivo na extremidade remota da conexão seja ainda acessível e que as conexões entreabertas ou órfãs estão removidas do dispositivo de IOS local.

Controle o transporte para linhas vty e tty

Um vty e um tty devem ser configurados para aceitar cifrado somente e para fixar conexões de gerenciamento do acesso remoto ao dispositivo, ou através do dispositivo se está sendo 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. Em um esforço para impedir a divulgação ou o acesso não autorizado da informação aos dados que são transmitidos entre o administrador e o dispositivo, o transport input ssh deve ser usado em vez dos protocolos da minuta, tais como o telnet e o rlogin. A configuração entrada de transporte nenhum pode ser permitida em um tty, que desabilite a utilização da linha tty para conexões console-reverso.

As linhas vty e tty permitem que um administrador conecte aos outros dispositivos. A fim de limitar o tipo de transporte que um administrador pode usar para conexões de saída, use o comando configuração da linha de saída do transporte. Se as conexões de saída não são necessários, então o saída de transporte nenhum deve ser usado. Contudo, se as conexões de saída são permitidas, a seguir o método de acesso remoto criptografado e seguro para a conexão deve ser reforçada com o uso do ssh da saída do transporte.

Note que o IPSec pode ser usado para cifrado e fixar conexões de acesso remoto a um dispositivo, se apoiado. Se você usa o IPSec, igualmente adiciona a carga adicional de CPU adicional ao dispositivo. Contudo, o SSH deve ainda ser reforçado como o transporte mesmo quando o IPSec é usado.

Banners de advertência

Em algumas jurisdições legais pode ser impossível processar e ilegal monitorar usuários maliciosos a menos que forem notificados que não estão permitidos para usar o sistema. Um método para fornecer esta notificação é colocar esta informação em um mensagem de banner que seja configurado com o comando banner login do Cisco IOS Software.

Os requisitos de notificação legais são complexos, variam pela jurisdição e pela situação, e devem ser discutidos com o advogado. Mesmo dentro das jurisdições, as opiniões legais podem diferir. Em colaboração com o conselho, uma bandeira pode fornecer algum ou toda a esta informação:

  • Observe que o sistema deve ser registrado em ou usada especificamente somente por pessoais autorizados e talvez por informação sobre quem pode autorizar o uso.

  • Observe que toda a utilização não autorizada do sistema é ilegal e pode ser sujeita a civil e às penalidades criminal.

  • Observe que todo o uso do sistema pode ser registrado ou monitorado sem aviso futuro e que os log resultante podem ser usados como a evidência no tribunal.

  • Observações específicas exigidas por leis local.

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

Usando a autenticação, autorização e relatório

A estrutura de autenticação, autorização e relatório (AAA) é crítica a fixar o acesso interativo aos dispositivos de rede. A estrutura AAA fornece um ambiente altamente configurável que possa ser costurado segundo as necessidades da rede.

Autenticação TACACS+

O TACACS+ (Terminal Access Controller Access Control System mais) é um protocolo de autenticação que os dispositivos IOS Cisco possam usar para a autenticação de usuários da gestão contra um servidor AAA remoto. Estes usuários da gestão podem alcançar o dispositivo de IOS através do SSH, do HTTPS, do telnet, ou do 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. Em remover a dependência em uma única senha compartilhada, a segurança da rede é melhorada e sua responsabilidade é reforçada.

O RADIUS (Remote Access Dial-In User Service) é um protocolo similar na finalidade ao TACACS+, contudo, ele somente faz a criptografia da senha enviada através da rede. Ao contrário, o TACACS+ cifra o payload de TCP inteiro que inclui ambos o nome de usuário e senha. Por este motivo, o TACACS+ deve ser usado de preferência ao RADIUS quando o TACACS+ é 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 permitida em um dispositivo IOS Cisco usando uma configuração similar 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 precedente pode ser usada como um ponto de início para um molde organização-específico da autenticação de AAA. Refira a autenticação, autorização, e relatórios para mais informação sobre a configuração do AAA.

Uma lista de método é uma lista seqüencial que descreve os métodos de autenticação a ser perguntados a fim de autenticar um usuário. As listas de método permitem-no de designar uns ou vários protocolos de segurança a ser usados para a autenticação, assim assegurando um sistema de backup para a autenticação caso que o método inicial falha. O Cisco IOS Software usará o primeiro método alistado que com sucesso aceita ou rejeita um usuário. Os métodos subseqüentes são tentados somente nos casos onde uns métodos mais adiantados falham devido à indisponibilidade ou à configuração incorreta do servidor. Refira a listas de método nomeadas para a autenticação para obter mais informações sobre da configuração de listas de método nomeadas.

Reserva da autenticação

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

A lista completa das opções para a autenticação do em-dispositivo inclui permite, local, e linha. Cada um destas opções tem vantagens. O uso do habilitar segredo é preferido porque o segredo é picado usando um algoritmo de sentido único que seja inerentemente mais seguro do que o algoritmo de criptografia que é usado com a senha tipo 7 para a linha ou a 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. Isto permite para um usuário definido localmente ser criado para um ou vários administradores de rede. Se o TACACS+ deve se tornar completamente não disponível, cada administrador pode usar seu nome de usuário local e senha. Embora esta ação aumente a responsabilidade dos administradores de rede durante indisponibilidade TACACS+, aumenta significativamente a sobrecarga administrativa porque as contas de usuário local em todos os dispositivos de rede devem ser mantidas.

Construções deste exemplo de configuração em cima do exemplo precedente da autenticação TACACS+ para incluir a autenticação da reserva à senha que é configurada localmente com o comando enable secret:


!

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>

!

Refira a configurar a autenticação para obter mais informações sobre do uso da autenticação da reserva com AAA.

Uso de senhas tipo 7

Originalmente designado para permitir a decifração rápida de senhas armazenadas, senhas tipo 7 não são um formulário seguro do armazenamento de senha. Há muitas ferramentas disponíveis que podem facilmente decifrar estas senhas. O uso de senhas tipo 7 deve ser evitado a menos que exigido por uma característica que esteja no uso no dispositivo IOS Cisco.

A remoção das senhas deste tipo pode ser facilitada com a autenticação de AAA e o uso da característica aumentada da segurança de senha, que permite que as senhas secundárias sejam usadas com usuários que são definidos localmente através do comando global configuration username. Se você não pode prevenir completamente uso de senhas tipo 7, considere estas senhas confundidas, não cifradas.

Veja o plano de gerenciamento geral endurecer a seção deste original para obter mais informações sobre da remoção de senhas tipo 7.

Autorização do comando TACACS+

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

Esta configuração pode ser adicionada ao exemplo precedente da autenticação de AAA a fim executar o comando authorization:


!

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

!

Refira a configurar a autorização para obter mais informações sobre do comando authorization.

Contabilidade do comando TACACS+

Quando configurado, a contabilidade do comando aaa envia a informação sobre cada comando EXEC que é inscrito nos servidores configurados TACACS+. A informação enviada ao server TACACS+ inclui o comando executado, a data onde foi executado, e o username do usuário que incorpora o comando. A contabilidade do comando não é apoiada usando 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. Construções desta configuração em cima dos exemplos anteriores que incluem a configuração dos servidores de 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

!

Refira a configurar relatórios para mais informação em relação à configuração da contabilidade AAA.

Servidores AAA redundantes

Os servidores AAA que leveraged em um ambiente devem ser redundantes e distribuídos em uma maneira falha-tolerante. 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.

Quando você projeta ou executa uma solução redundante do servidor AAA, tenha estas considerações em mente:

  • Disponibilidade dos servidores AAA durante falhas da rede potencial

  • Colocação geográfica dispersada dos servidores AAA

  • Carregue em servidores AAA individuais durante de estado estacionário e condições de falha

  • Latência da rede entre servidores do acesso de rede e servidores AAA

  • Sincronização das bases de dados do servidor AAA

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

Fortificando o protocolo Simple Network Management

Esta seção destaca diversos métodos que podem ser usados a fim fixar o desenvolvimento do SNMP dentro dos dispositivos de IOS. É crítico que o SNMP esteja fixado corretamente para proteger o segredo, a integridade, e a disponibilidade dos dados de rede e dos dispositivos de rede com que estes dados transitam por. O SNMP fornece-o uma riqueza de informação na saúde dos dispositivos de rede. Esta informação deve ser protegida dos usuários maliciosos que querem entregar estes dados para executar ataques contra a rede.

Strings de comunidade SNMP

Os string de comunidade são as senhas que são aplicadas a um dispositivo de IOS para restringir o acesso, de leitura apenas e o acesso de leitura/gravação, aos dados SNMP no dispositivo. Estes strings de comunidade, como com todas as senhas, devem com cuidado ser escolhidos se assegurar de que não sejam triviais. Os strings de comunidade devem ser mudados em intervalos regulares e de acordo com políticas de segurança de rede. Por exemplo, as cordas devem ser mudadas quando um administrador de rede muda papéis ou deixa a 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  

!

Note que os exemplos de comunidade string precedentes foram escolhidos para explicar claramente o uso destas cordas. Para ambientes de produção, os strings de comunidade devem ser escolhidos com cuidado e devem consistir em uma série de símbolos alfabéticos, numéricos, e não-alfanuméricos. Refira a recomendações para criar senhas elaboradas para obter mais informações sobre da seleção de senhas não-triviais.

Refira a referência do comando SNMP IO para obter mais informações sobre desta característica.

Séries de comunidade snmp com ACL

Além do que o string de comunidade, um ACL deve ser aplicado que restrinja mais o acesso SNMP a um grupo seleto 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.

Note que os dispositivos que são permitidos por estes ACL exigem o string de comunidade apropriado alcançar a informação de SNMP solicitada.


!

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

!

Refira a comunidade do servidor snmp no Cisco IOS Network Management Command Reference e mais informações sobre esta característica.

Infra-estrutura ACL

A infra-estrutura ACL (iACLs) pode ser distribuída para assegurar-se de que somente os host finais com endereços IP confiados possam enviar o tráfego SNMP a um dispositivo de IOS. Um iACL deve conter uma política que negue pacotes SNMP não autorizados na porta 161 UDP.

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

SNMP Views

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

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


!

snmp-server view VIEW-SYSTEM-ONLY system include

!

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

!

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

SNMP Versão 3

O SNMP versão 3 (SNMPv3) é definido pelo RFC3410 , pelo RFC3411 , pelo RFC3412 , pelo RFC3413 , pelo RFC3414 , e pelo RFC3415 e é um protocolo baseando em padrões interoperáveis para o gerenciamento de rede.leavingcisco.com leavingcisco.com leavingcisco.com leavingcisco.com leavingcisco.com leavingcisco.com O SNMPv3 fornece o acesso seguro aos dispositivos autenticando e opcionalmente aos pacotes de criptografia sobre a rede. Onde suportado, o SNMPv3 pode ser usado a fim de adicionar uma outra camada de segurança quando distribuindo o SNMP. O SNMPv3 consiste em três opções de configuração preliminares:

  • no auth - Este modo não exige nenhuma autenticação nem nenhuma criptografia dos pacotes SNMP

  • auth - Este modo exige a autenticação do pacote SNMP sem criptografia

  • priv - Este modo exige a autenticação e a criptografia (privacidade) de cada pacote SNMP

Um Engine ID competente deve existir para usar os mecanismos de segurança SNMPv3 - autenticação ou autenticação e criptografia - para segurar pacotes SNMP; por padrão, o Engine ID é gerado localmente. O Engine ID pode ser indicado com o comando show snmp engineID segundo as indicações deste exemplo:

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

Note que se o engineID é mudado, todas as contas de usuário SNMP devem ser reconfiguradas.

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


!

snmp-server group AUTHGROUP v3 auth

!

Este comando configura um dispositivo IOS Cisco para o SNMPv3 com um grupo PRIVGROUP do servidor SNMP e permite a autenticação e a criptografia para este grupo usando as palavras-chave privadas:


!

snmp-server group PRIVGROUP v3 priv

!

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


!

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

!

Note que os comandos da configuração do usuário servidor snmp não estão indicados nas saídas de configuração do dispositivo segundo as exigências do RFC 3414; conseqüentemente, a senha do usuário não é visualizável da configuração. A fim de ver os usuários configurados, inscreva o comando show snmp user segundo as indicações deste exemplo:

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

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

Proteção do plano de gerenciamento

A característica Management Plane Protection (PMP) no software Cisco IOS pode ser usada a fim ajudar o SNMP seguro restringindo as relações através do qual 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.

Note que a PMP (produção máxima possível) é um subconjunto da característica da proteção do plano do controle (CPPr) e exige uma versão de IOS que apoia CPPr. Refira a compreendendo a proteção plana do controle para obter mais informações sobre de CPPr.

Neste exemplo, a PMP (produção máxima possível) é usada a fim de restringir o acesso SNMP e SSH somente à relação do FastEthernet0/0:


!

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

!

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

Melhores práticas de registo

O logging de evento fornece-lhe a visibilidade na operação de um dispositivo IOS Cisco e da rede em que é distribuída. O Cisco IOS Software fornece diversas opções de registro flexíveis que podem ajudar a conseguir os objetivos do gerenciamento de rede e da visibilidade de uma organização.

Estas seções fornecem alguns melhores prática de registo básicos que podem ajudar um administrador a leverage o registo com sucesso ao minimizar o impacto de entrar um dispositivo IOS Cisco.

Envie registros a um local central

É recomendado enviar a informação de registro a um servidor de SYSLOG remoto. Ao fazê-lo, torna-se possível correlacionar mais eficazmente e rede de auditoria e eventos de segurança através dos dispositivos de rede. Note que os mensagens do syslog estão transmitidos incerta pelo UDP e na minuta. Por este motivo, todas as proteções que uma rede tiver recursos para ao tráfego de gerenciamento (por exemplo, criptografia ou acesso out-of-band) devem ser estendidas para incluir o tráfego syslog.

Este exemplo de configuração configura um dispositivo IOS Cisco para enviar a informação de registro a um servidor de SYSLOG remoto:


!

logging host <ip-address>

!

Refira a identificação de incidentes usando eventos de syslog do guarda-fogo e do IOS Router para obter mais informações sobre da correlação do registro.

Integrado em 12.4(15)T e introduzido originalmente em 12.0(26)S, o registo à característica local do armazenamento permanente (disco ATA) permite mensagens do logging do sistema de ser salvar em um disco flash do acessório da tecnologia avançada (ATA). As mensagens salvas em uma movimentação ATA persistem depois que um roteador é recarregado.

As seguintes linhas de configuração configuram 134.217.728 bytes (128 MB) dos mensagens de registro ao diretório syslog do flash ATA (disco 0), especificando um tamanho do arquivo de 16.384 bytes:

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

Antes que os mensagens de registro estejam redigidos a um arquivo no disco ATA, o Cisco IOS Software verifica para considerar se há o espaço de disco suficiente. Se não, o arquivo o mais velho das mensagens de registro (pelo timestamp) é suprimido, e o arquivo atual é salvo. O formato do nome de arquivo é log_month: dia: ano:: tempo. Note que uma movimentação do flash ATA limitou o espaço de disco e assim precisa ser mantido para evitar sobrepor dados armazenados. O exemplo seguinte mostra como copiar mensagens de registro do disco flash ATA do roteador a 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

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

Nível de registro

Cada mensagem de registro que é gerado por um dispositivo IOS Cisco é atribuído uma de oito gravidades que variam do nível 0, emergências, através do nível 7, Debug. A menos que especificamente exigido, você é recomendado evitar registrar a nível 7. que registra a nível 7 produz uma carga de CPU elevado no dispositivo que pode conduzir ao dispositivo e à instabilidade de rede.

O nível de armadilha de registro do comando global configuration é usado a fim especificar que mensagens de registro são enviados aos servidores de SYSLOG remotos. O nível especificado indica a mais baixa mensagem da severidade que é enviada. Para o registo protegido, o comando logging buffered level é usado.

Este exemplo de configuração limita os mensagens de registro que são enviados aos servidores de SYSLOG remotos e ao buffer de registro local às gravidades 6 (informativo) com 0 (emergências):


!

logging trap 6
logging buffered 6

!

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

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

Com Cisco IOS Software, é possível enviar mensagens de registro às sessões de monitor - as sessões de monitor são as sessões de gerenciamento interativas em que o monitor terminal do comando exec foi emitido - e ao console. Contudo, fazer assim pode elevar a carga de CPU de um dispositivo de IOS e conseqüentemente não é recomendado. Em lugar de, você é recomendado enviar a informação de registro ao buffer de registro local, que pode ser visto usando o comando show logging.

Use os comandos global configuration nenhum console de registro e no logging monitor desabilitar o registo ao console e às sessões de monitor. Este exemplo de configuração mostra o uso destes comandos:


!

no logging console
no logging monitor

!

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

Use o registo protegido

O Cisco IOS Software apoia o uso de um buffer de registro local de modo que um administrador possa ver localmente mensagens do log gerado. O uso do registo protegido é altamente recomendado contra o registo ao console ou às sessões de monitor.

Há duas opções de configuração que são relevantes ao configurar o registo protegido: o tamanho de logging buffer e as gravidades da mensagem que é armazenado no amortecedor. O tamanho do logging buffer é configurado com o comando global configuration que registra o tamanho protegido. A mais baixa severidade incluída no amortecedor é configurada usando o comando protegido registrar da severidade. Um administrador pode ver os índices do logging buffer através do comando show logging exec.

Este exemplo de configuração inclui a configuração de um logging buffer de 16384 bytes, assim como uma severidade 6, informativo, indicando que as mensagens a níveis 0 (emergências) com 6 (informativo) estão armazenadas:


!

logging buffered 16384 6

!

Refira a referência do comando management da rede de IOS Cisco para obter mais informações sobre do registo protegido.

Configurar a interface de origem de registo

A fim de fornecer um nível aumentado da consistência ao recolher e ao rever mensagens de registro, você é recomendado configurar estaticamente uma interface de origem de registo. Realizado através do comando interface de registo da fonte-relação, estaticamente configurar uma interface de origem de registo assegura-se de que o mesmo endereço IP apareça em todos os mensagens de registro que são enviados de um dispositivo IOS Cisco individual. Para a estabilidade adicionada, é recomendado usar uma interface de loopback como a fonte de registo.

Este exemplo de configuração ilustra o uso do comando global configuration de registo da relação da fonte-relação especificar que o endereço IP da relação do loopback0 esteja usado para todos os mensagens de registro:


!

logging source-interface Loopback 0

!

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

Configurar data/hora de registro

A configuração de data/hora de registro ajuda-o a correlacionar eventos através dos dispositivos de rede. É importante executar uma configuração correta e consistente de data/hora de registro assegurar-se de que você possa correlacionar dados de registo. A data/hora de registro devem ser configurados para incluir a data e hora com precisão do milissegundo e para incluir a zona de hora (fuso horário) no uso no dispositivo.

Este exemplo inclui a configuração de data/hora de registro com precisão do milissegundo dentro da zona do tempo universal coordenada (UTC):


!

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

!

Refira aos rótulos de tempo de serviço e cronometro do fuso horário para obter mais informações sobre estes comandos.

Gerenciamento de configuração do Cisco IOS Software

O Cisco IOS Software inclui diversas características que podem permitir um formulário do gerenciamento de configuração em um dispositivo IOS Cisco. Tais características incluem a funcionalidade para arquivar as configurações e ao rollback a configuração a uma versão anterior assim como para criar um registro da mudança de configuração detalhada.

Substituir configuração e configuração Rollback

Começando no Cisco IOS Software Release 12.3(7)T, a configuração substitui e as características do Rollback da configuração permitem arquivar a configuração do dispositivo IOS Cisco no dispositivo. Armazenado manualmente ou automaticamente, as configurações neste arquivo podem ser usados a fim de substituir a configuração em execução atualmente que usa configurar substituir comando filename. Isto é em contraste com o copiar nome de arquivo comando running-config. O comando configurar substituir nome de arquivo substitui a configuração running ao contrário da fusão executada pelo comando copy.

Você é recomendado permitir esta característica em todos os dispositivos IOS Cisco na rede. Uma vez que permitido, um administrador pode fazer com que a configuração em execução atualmente seja adicionada ao arquivo usando o comando privileged exec da configuração do arquivo. As configurações arquivadas podem ser vistas usando o comando exec do show archive.

Este exemplo ilustra a configuração de arquivo da configuração automática. Este exemplo instrui o dispositivo IOS Cisco para armazenar configurações arquivadas como os arquivos nomeados arquivar-configuração-n no disco 0: sistema de arquivos, para manter um máximo de 14 apoios, e para arquivá-lo uma vez pelo dia (1440 minutos) e quando um administrador emitir o comando exec da memória da escrita.


!

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

!

Embora a funcionalidade do arquivo de configuração possa armazenar até 14 configurações de backup, você é recomendado considerar as requisições de espaço antes de usar o comando máximo.

Refira a configuração substituir e configuração Rollback para mais informação.

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

Adicionado ao Cisco IOS Software Release 12.3(14)T, os recursos de acesso exclusivos da alteração de configuração asseguram que somente um administrador faça alterações de configuração a um dispositivo IOS Cisco em um dado momento. Esta característica ajuda a eliminar o impacto indesejado das mudanças simultâneas feitas aos componentes da configuração relacionada. Esta característica é configurada usando o modo exclusivo do modo de configuração do comando global configuration e opera-se em um de dois modos: automático e manual. No auto-MODE, a configuração trava automaticamente quando um administrador emite o comando exec do terminal configurar. No modo manual, o administrador usa o comando lock terminal configurar travar a configuração ao incorporar o 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

!

Refira ao acesso exclusivo da alteração de configuração (fechamento da configuração) para mais informação.

Configuração resiliente do Cisco IOS Software

Adicionado no Cisco IOS Software Release 12.3(8)T, a característica de configuração resiliente torna possível armazenar firmemente uma cópia da imagem do Cisco IOS Software e da configuração de dispositivo que está sendo usada atualmente por um dispositivo IOS Cisco. 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 de execução atual desta característica pode ser indicado usando o comando exec seguro da bota da mostra.

Refira a configuração resiliente do Cisco IOS para obter mais informações sobre esta característica.

Software Cisco assinado Digital

Adicionado no Cisco IOS Software Release 15.0(1)M para Cisco 1900, 2900, e 3900 Series Router, a característica assinada Digital do software Cisco facilita o uso do Cisco IOS Software que é assinado digital e confiado assim, usando a criptografia assimétrica segura (da chave pública).

Uma imagem digital assinada leva (com uma chave privada) uma mistura criptografada dse. Em cima da verificação, o dispositivo decifra a mistura usando a chave pública correspondente das chaves que tem em sua loja chave e igualmente calcula sua própria mistura 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. A produção e os tipos chaves especiais têm uma versão chave associada que incremente alfabeticamente sempre que a chave é revogada e substituída. ROMmon e as imagens IOS Cisco regulares são assinados com uma chave especial ou da produção ao usar a característica Digital do software Cisco. A imagem de ROMMON pode fazer upgrade e precisa de ser assinada com a mesma chave que o especial ou a imagem de produção que serão carregados.

O comando seguinte verificará a integridade da imagem c3900-universalk9-mz.SSA no flash usando as chaves na loja da chave 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.

Começando no Cisco IOS Software Release 15.1(1)T, a substituição chave para o software Cisco Digital Assinado foi introduzida. A substituição e a revogação de chaves substituem e removem uma chave que seja usada para uma verificação assinada Digital do software Cisco do armazenamento chave de uma 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 da revogação é verificada usando uma chave rollover que venha gravado na plataforma. Uma chave rollover não muda. Ao revogar uma chave da produção, depois que a imagem da revogação é carregada, a chave que nova leva é adicionado à loja chave e a chave velha correspondente pode ser revogada enquanto a imagem de ROMMON é promovida e a imagem de produção nova está carregada Ao revogar uma chave especial, uma imagem de produção é carregada. Esta imagem adiciona a chave especial nova e pode revogar a chave especial velha. Após ter promovido ROMmon, a imagem especial nova pode ser carregada.

O exemplo seguinte descreve a revogação de uma chave especial. Estes comandos adicionarão a chave especial nova à loja chave da imagem de produção em execução, copiam uma imagem de ROMMON nova (C3900_rom-monitor.srec.SSB) à área de armazenamento (usbflash0:), promovem o arquivo de ROMmon, e revogam a chave especial velha:

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 imagem especial nova (c3900-universalk9-mz.SSB) pode então ser copiada para piscar para ser carregado e a assinatura da imagem é verificada usando a chave especial recentemente adicionada (.SSB):

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

A revogação e a substituição chaves não são apoiadas em software running do Cisco IOS XE de Switches da E-Série do Catalyst 4500, embora estes interruptores apoiem a característica assinada Digital do software Cisco.

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

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

A notificação e os recursos de registro da alteração de configuração, adicionados no Cisco IOS Software Release 12.3(4)T, tornam possível registrar as alterações de configuração feitas a um dispositivo IOS Cisco. O registro é mantido no dispositivo IOS Cisco e contem a informação sobre o usuário do indivíduo que fez a mudança, o comando configuration inscrito, e o tempo que a mudança foi feita. Esta funcionalidade é permitida usando o habilitar registo o comando configuration mode do registador da alteração de configuração. Os comandos opcionais hidekeys e as entradas de registo do tamanho são usados a fim de melhorar a configuração padrão impedindo o registo de dados da senha e o aumento do comprimento do registro da mudança.

Você é recomendado permitir esta funcionalidade de modo que a história da alteração de configuração de um dispositivo IOS Cisco possa ser de mais fácil compreensão. Adicionalmente, é recomendado usar o comando configuration syslog da notificação para permitir a geração de mensagens do syslog quando uma alteração de configuração é feita.


!

archive
 log config
  logging enable
  logging size 200
  hidekeys
  notify syslog

!

Após a notificação e os recursos de registro da alteração de configuração serem habilitados, a configuração do log de arquivo do privileged exec command show pode ser usado a fim ver o registro da configuração.

Refira a notificação da alteração de configuração e o registo para obter mais informações sobre esta característica.

Controle o plano

As funções planas do controle consistem nos protocolos e nos processos que se comunicam entre dispositivos de rede para mover dados da fonte para o destino. Isto inclui protocolos de roteamento tais como o Border Gateway Protocol, assim como protocolos como o ICMP e o protocolo de reserva do recurso (RSVP).

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

Endurecimento plano do controle geral

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

Em muitos casos, desabilitar a recepção e a transmissão dos determinados tipos de mensagens em uma relação pode minimizar a quantidade de carga de CPU que é exigida para processar pacotes desnecessários.

Redirecionamentos de IP ICMP

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

Há dois tipos de mensagens do redirecionamento de ICMP: reoriente para um endereço de host e reoriente para uma sub-rede inteira. Um usuário malicioso pode explorar a capacidade do roteador para enviar o redirecionamentos de ICMP continuamente enviando pacotes ao roteador, forçando o roteador a responder com mensagens do redirecionamento de ICMP, tendo por resultado um impacto adverso no CPU e no desempenho do roteador. A fim de impedir que o roteador envie redirecionamentos de ICMP, use o comando interface configuration do no ip redirects.

Refira o redirecionamento de ICMP IP para obter mais informações sobre dos redirecionamentos de ICMP.

ICMP não alcançável

Filtrar com uma lista de acessos da relação induz a transmissão dos mensagens que não chega a seu destino do ICMP de volta à fonte do tráfego filtrado. Gerar estas mensagens pode aumentar a utilização CPU no dispositivo. No Cisco IOS Software, a geração do ICMP não alcançável é limitada a um pacote a cada 500 milissegundos por padrão. A geração do mensagem que não chega a seu destino do ICMP pode ser deficiente usando o no ip unreachables do comando interface configuration. A limitação da taxa do ICMP não alcançável pode ser mudada da opção usando o intervalo-em-MS inacessível do taxa-limite ICMP do global configuration command ip.

Proxy ARP

O proxy ARP é a técnica em qual dispositivo, geralmente um roteador, as requisições ARP das respostas que são pretendidas para um outro dispositivo. “Falsificando” sua identidade, o roteador aceita a responsabilidade para pacotes de roteamento ao destino real. O Proxy ARP pode ajudar máquinas em uma sub-rede a alcançar sub-redes remotas sem configurar o roteamento ou um gateway padrão. O proxy ARP é definido no RFC 1027.leavingcisco.com

Há diversas desvantagens a utilizar o proxy ARP. Utilizar o proxy ARP pode conduzir a um aumento na quantidade de tráfego ARP no segmento de rede e o esgotamento de recurso e os ataques que envolva pessoas. 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 atacante pode poder esgotar toda a memória disponível enviando um grande número requisições ARP.

Os ataques que envolva pessoas permitem um host na rede ao spoof o MAC address do roteador, tendo por resultado os anfitriões confiantes que enviam o tráfego ao atacante. O proxy ARP pode ser deficiente usando o no ip proxy-arp do comando interface configuration.

Refira a possibilidade do proxy ARP para obter mais informações sobre esta característica.

Limitando o impacto CPU do tráfego plano do controle

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

Compreendendo o tráfego plano do controle

Para proteger corretamente o plano do controle do dispositivo IOS Cisco, ele é essencial compreender os tipos de tráfego que é processo comutado pelo CPU. O tráfego comutado do processo consiste normalmente em dois tipos de tráfego diferentes. O primeiro tipo de tráfego é dirigido ao dispositivo IOS Cisco e deve ser segurado diretamente pelo dispositivo IOS Cisco CPU. Este tráfego consiste nesta categoria:

  • Receba o tráfego da adjacência - Este tráfego contem uma entrada no Cisco express forwarding (CEF) tabela por meio de que o salto seguinte do roteador é o dispositivo próprio, que é indicado pelo termo recebe na interface de linha do comando show ip cef (CLI) output. 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 que é segurado pelo CPU é tráfego plano de dados - trafique com um destino além do dispositivo IOS Cisco próprio - que exige o processamento especial pelo CPU. Embora não uma lista exaustiva do tráfego plano de impacto dos dados CPU, estes tipos de tráfego seja processo comutado e pode conseqüentemente afetar o funcionamento do plano do controle:

  • Registo do Access Control List - O tráfego do logging ACL consiste em todos os pacotes que forem gerado devido a uma combinação (permit or deny) de um ACE em que a palavra-chave do registro é usada.

  • Unicast Reverse Path Forwarding (unicast RPF) - O unicast RPF, usado conjuntamente com um ACL, pode conduzir à comutação do processo de determinados pacotes.

  • Opções IP - Todos os pacotes IP com as opções incluídas devem ser processados pelo CPU.

  • Fragmentação - Todo o pacote IP que exigir a fragmentação deve ser passada ao CPU para processamento.

  • Expiração do tempo ao vivo (TTL) - Os pacotes que têm um valor TTL inferior ou igual a 1 para exigir o tempo do protocolo Protocolo de control de mensajes de Internet (ICMP) excederam (tipo 11 ICMP, código 0) as mensagens a ser enviadas, que conduz ao processamento de CPU.

  • ICMP não alcançável - Os pacotes que conduzem aos mensagens que não chega a seu destino do ICMP devido à distribuição, o MTU, ou a filtração são processados pelo CPU.

  • Tráfego que exige uma requisição ARP - Os destinos para que uma entrada de ARP não existe exigem o processamento pelo CPU.

  • Tráfego não-IP - Todo o tráfego não-IP é processado pelo CPU.

Esta lista detalha diversos métodos para determinar que tipos de tráfego estão sendo processados pelo dispositivo CPU Cisco IOS:

  • O comando show ip cef fornece a informação do salto seguinte para cada prefixo IP que é contido na tabela de CEF. Como indicado previamente, as entradas que contêm recebem como o “salto seguinte” é considerado recebe adjacências e indicam que o tráfego deve ser enviado diretamente ao CPU.

  • O comando show interface switching fornece a informação no número de pacotes que são processo comutado por um dispositivo.

  • O comando show ip traffic fornece a informação no número de pacotes IP:

    • com um destino local (isto é, receba o tráfego da adjacência)

    • com opções

    • isso exige a fragmentação

    • isso é enviado ao espaço do endereço de broadcast

    • isso é enviado ao espaço do endereço de multicast

  • Receba o tráfego da adjacência pode ser identificado com o uso do comando show ip cache flow. Todos os fluxos que forem destinados ao dispositivo Cisco IOS têm uma interface de destino (DstIf) do local.

  • O policiamento do plano do controle pode ser usado a fim identificar o tipo e a taxa de tráfego que alcança o plano do controle do dispositivo Cisco IOS. O policiamento do plano do controle pode ser executado com o uso da classificação granular ACL, registo, e o uso do comando do controle plano do mapa de política da mostra.

Infra-estrutura ACL

A infra-estrutura ACL (iACLs) limita uma comunicação externa aos dispositivos da rede. A infra-estrutura ACL é coberta extensivamente no acesso de limitação à rede com a seção da infra-estrutura ACL deste documento.

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

ACLs de Recebimento

Para plataformas distribuídas, receba ACL (rACL) pode ser uma opção para Cisco IOS Software Release 12.0(21)S2 para os 12000 (GSR), 12.0(24)S para os 7500, e 12.0(31)S para os 10720. O rACL protege o dispositivo do tráfego prejudicial antes do tráfego impacta o processador de rotas. Receba ACL são projetados proteger somente o dispositivo em que é configurado e o tráfego de trânsito não é afetado por um rACL. Em conseqüência, o endereço IP de destino que é usado nas entradas ACL do exemplo abaixo refere somente os endereços IP físicos ou virtuais do roteador. Receba ACL igualmente são considerados uma melhor prática da segurança de rede e deve ser considerada como uma adição a 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: Receba lista de controle de acesso a fim ajudar a identificar e permitir o tráfego legitimado a um dispositivo e a negar todos os pacotes indesejados.

Políticas de plano de controle

A característica de policiamento de controle plano (CoPP) pode igualmente ser usada a fim restringir os pacotes IP que são destinados ao dispositivo de infra-estrutura. Neste exemplo, somente o tráfego SSH dos host confiável é permitido para alcançar o dispositivo IOS Cisco CPU.

Note isso tráfego deixando cair de desconhecido ou os endereços IP não confiáveis podem impedir que os anfitriões com endereços IP das dinâmico-atribuições conectem ao 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 precedente de CoPP, as entradas ACL que combinam os pacotes não autorizados com a ação da licença conduzem a um descarte destes pacotes pela função da queda do mapa de política, quando os pacotes que combinam a ação da negação não forem afetados pela função da queda do mapa de política.

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

Refira ao plano de distribuição do controle que policia para obter mais informações sobre da configuração e do uso da característica de CoPP.

Controle a proteção plana

Controle a proteção plana (CPPr), introduzida no Cisco IOS Software Release 12.4(4)T, possa ser usado a fim o tráfego plano restringir ou de controle de polícia que é destinado ao CPU do dispositivo Cisco IOS. Quando similar a CoPP, CPPr tem a capacidade para restringir o tráfego com granularidade mais fina. CPPr divide o plano agregado do controle em três categorias separadas do plano do controle 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:

  • Característica da Porta-filtração - Esta característica prevê policiando e deixando cair dos pacotes que são enviados a fechado ou à não-escuta TCP ou às portas UDP.

  • Característica do Fila-thrresholding - Esta característica limita o número de pacotes para um protocolo especificado que são permitidos na fila de entrada do controle plano IP.

Refira a proteção e a compreensão do plano do controle da proteção plana do controle (CPPr) para obter mais informações sobre da configuração e do uso da característica de CPPr.

Limitadores da taxa do hardware

Específico da plataforma do apoio do Supervisor Engine 32 e do Supervisor Engine 720 do Cisco Catalyst 6500 Series, limitadores com base em hardware da taxa (HWRLs) para cenários de comunicação 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. HWRLs pode proteger o dispositivo IOS Cisco de uma variedade de ataques que exigem pacotes se processados pelo CPU.

Há diversos HWRLs habilitados por padrão. Refira a configurações padrão com base em hardware do limitador da taxa PFC3 para mais informação.

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

Fixando o BGP

O Border Gateway Protocol (BGP) é a fundação do roteamento da Internet. Como tal, toda a organização com requisitos de conectividade mais do que modestos encontra-se frequentemente utilizando o BGP. O BGP é visado frequentemente por atacantes devido a sua ubiquidade e “ajuste e esqueça” a natureza das configurações de 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.

Isto fornece uma vista geral dos recursos de segurança os mais importantes BGP. Onde apropriado, as recomendações de configuração são feitas.

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

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

Conhecido como o corte do mecanismo de segurança de ambos os TTL-estabelecimentos de bases generalizados (GTSM) e da segurança BGP TTL (BTSH), uma proteção de segurança dos TTL-estabelecimentos de bases entregam o valor TTL dos pacotes IP para assegurar-se que os pacotes BGP que são recebidos sejam de um par diretamente conectado. Esta característica exige frequentemente a coordenação dos roteadores peering; contudo, uma vez permitida, pode derrotar completamente muitos ataques com base em TCP contra o BGP.

GTSM para o BGP é permitido usando a opção da TTL-segurança para o comando configuration vizinho do BGP Router. 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>

!

Enquanto os pacotes BGP são recebidos, o valor TTL está verificado e deve ser superior ou igual a 255 menos o contagem de saltos especificado.

Refira ao suporte do BGP para a verificação de segurança TTL para mais informação.

Autenticação do bgp peer com MD5

A autenticação de peer que usa o MD5 cria um resumo MD5 de cada pacote enviado como parte de uma sessão de BGP. Especificamente, as parcelas do IP e dos cabeçalhos de TCP, o payload de TCP, e uma chave secreta são usados a fim 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 auto-falante de BGP de recepção usa o mesmos algoritmo e chave secreta para regenerar o message digest. Se os resumos recebidos e computados não são idênticos, o pacote está rejeitado.

A autenticação de peer com MD5 é configurada usando a opção de senha ao comando configuration vizinho do BGP Router. O uso deste comando é ilustrado como segue:


!

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

!

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

Configurando prefixos máximos

Os prefixos BGP são armazenados por um roteador na memória. Mais prefixos um roteador deve guardar resultados no BGP que consome mais memória. Em algumas configurações, um subconjunto de todos os prefixos do Internet pode ser armazenado, como nas configurações que entregam somente uma rota padrão ou rotas para as redes cliente de um fornecedor.

A fim de impedir a exaustão da memória, é importante configurar o número máximo de prefixos aceitos em uma base por peer. Recomenda-se que um limite esteja configurado para cada BGP peer.

Ao configurar esta característica usando o comando neighbor maximum-prefix BGP Router configuration, um argumento é exigido: o número máximo de prefixos que são aceitos antes que um peer seja desligado. Opcionalmente, um número de 1 a 100 pode igualmente ser incorporado. Este número representa a porcentagem do valor máximo dos prefixos em que ponto um mensagem de registro é enviado.


!

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

!

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

Prefixos de filtração BGP com listas de prefixo

As listas de prefixo permitem um administrador de rede aceitar ou rejeitar os prefixos específicos enviados ou recebidos através do BGP. As listas de prefixo devem ser usadas sempre que seja possível para assegurar-se de que o tráfego de rede esteja enviado sobre os trajetos pretendidos. As listas de prefixo devem ser aplicadas a cada peer do eBGP no de entrada e em direções externas.

As listas de prefixo configuradas limitam os prefixos que são enviados ou recebidos àqueles permitidos especificamente pela política de roteamento de uma rede. Se este não é praticável devido ao grande número de prefixos recebidos, uma lista de prefixos deve ser configurada para obstruir especificamente prefixos ruins conhecidos. Estes prefixos ruins conhecidos incluem o espaço de endereços IP e as redes não localizadas que são reservadas para interno ou propósitos testando pelo RFC 3330. As listas de prefixo de partida devem ser configuradas para permitir especificamente somente 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

!

Refira a conexão a um provedor de serviços que usa o BGP externo para a cobertura completa da filtração do prefixo BGP.

Prefixos de filtração BGP com listas de acessos do trajeto do sistema autônomo

As listas de acessos do trajeto do sistema autônomo BGP permitem que o usuário filtre os prefixos recebidos e anunciados baseados no atributo do Como-PATH de um prefixo. Isto pode ser usado conjuntamente com listas de prefixo para estabelecer um grupo 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 que são originados de todos os sistemas autônomos restantes 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

!

Fixando os Interior Gateway Protocols

A capacidade de uma rede envia corretamente o tráfego e recupera-o das alterações de topologia ou as falhas são dependentes de um visualização precisa da topologia. Executar um protocolo Interior Gateway Protocols (IGP) pode frequentemente fornecer esta vista. Por padrão, os IGP são dinâmicos e descobrem os roteadores adicionais que se comunicam com o IGP particular no uso. Os IGP igualmente descobrem as rotas que podem ser usadas durante uma falha do link de rede.

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

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

A falha para fixar a troca de informação de roteamento permite que um atacante introduza a informação de roteamento falsa na rede. Usando a autenticação de senha com protocolos de roteamento entre roteadores, você pode ajudar à 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.

Adicionando capacidades da mistura MD5 ao processo de autenticação, as atualizações de roteamento já não contêm senhas de texto claro, e os índices inteiros da atualização de roteamento são mais resistentes à alteração. Contudo, a autenticação md5 é ainda suscetível à força brutal e aos ataques do dicionário se as senhas fracas são escolhidas. 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 pode igualmente ser usado a fim validar e fixar protocolos de roteamento, mas estes exemplos não detalham seu uso.

O EIGRP e o RIPv2 utilizam portas-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 EIGRP Router usando o 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>

!

Consulte para configurar a autenticação da rota de EIGRP para mais informação.

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>

!

Refira a possibilidade da autenticação do RIP para mais informação.

Este é um exemplo de configuração para a autenticação do OSPF Router usando o MD5. O OSPF não utiliza portas-chaves.


!

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

!

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

!

Refira configurar o OSPF para mais informação.

Comandos passive-interface

Os escapes da informação, ou a introdução de informação falsa em um IGP, podem ser abrandados com o uso do comando passive-interface que ajuda em controlar a propaganda da informação de roteamento. Você é recomendado não anunciar nenhuma informação às redes que estão fora de seu controle administrativo.

Este exemplo demonstra o uso desta característica:


!

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

!

Refira a recursos de interface passiva da opção para obter mais informações sobre da característica da interface passiva.

Filtragem de rota

A fim de reduzir a possibilidade de introduzir a informação de roteamento falsa na rede, você deve utilizar o filtragem de rota. Ao contrário do comando configuração router interface passiva , distribuir ocorre em relações uma vez que o filtragem de rota é permitido, mas a informação que é anunciada ou processada é limitada.

Para o EIGRP e o RIP, usando o comando distribute-list com os limites da palavra-chave da saída que informação está anunciada, quando o uso na palavra-chave limitar que atualizações estão processadas. O comando distribute-list está disponível para o OSPF, mas não impede que um roteador propague rotas filtradas. Em lugar de, o comando area filter-list pode ser usado.

Este exemplo EIGRP filtra propagandas de partida com o comando distribute-list e 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> 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>

!

Refira configurar características independentes do protocolo de IP Routing para obter mais informações sobre de controlar a propaganda e do processamento das atualizações de roteamento.

Este exemplo OSPF utiliza uma lista de prefixo com o comando area filter-list OSPF-específico:


!

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

!

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

!

Refira o tipo 3 LSA OSPF ABR que filtra para obter mais informações sobre do tipo 3 filtração do roteador de borda da área do OSPF (ABR) do Link-State Advertisements.

Consumo do recurso do processo de roteamento

Os prefixos do protocolo de roteamento são armazenados por um roteador na memória, e o consumo do recurso aumenta com prefixos adicionais que um roteador deve sustentar. A fim de impedir o esgotamento de recurso, é importante configurar o protocolo de roteamento para limitar o consumo do recurso. Isto é possível com o OSPF utilizando os recursos de proteção da sobrecarga da base de dados do estado do link.

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> 

!

Refira a limitação do número da Auto-Geração LSA para um processo de OSPF para obter mais informações sobre da proteção da sobrecarga do banco de dados de estado de link OSPF.

Fixando primeiros protocolos da redundância de salto

Os primeiros protocolos da redundância de salto (FHRPs) fornecem a elasticidade e a redundância para os dispositivos que estão atuando 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, estes protocolos comunicam-se usando comunicações não-autenticadas. Este tipo de comunicação pode permitir que um atacante levante como um dispositivo FHRP-falante para supor o papel do gateway padrão na rede. Esta aquisição maioritária permitiria que um atacante executasse um ataque que envolva pessoas e interceptasse todo o tráfego de usuário que retira a rede.

A fim impedir este tipo de ataque, todo o FHRPs que é apoiado pelo Cisco IOS Software inclui uma capacidade da autenticação usando o MD5 ou as seqüências de caracteres 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

!

Refira configurar GLBP, configurar o HSRP, e configurar o VRRP para obter mais informações sobre da configuração da autenticação com FHRPs.

Plano dos dados

Embora o plano dos dados seja responsável para mover dados da fonte para o destino, dentro do contexto da segurança, o plano dos dados seja menos importante dos três planos. É por esta razão que ao fixar um dispositivo de rede é importante proteger a gestão e a controlar os planos na preferência sobre os dados do plano.

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 estas características e opções tais que você pode mais facilmente segurar sua rede.

Endurecimento do plano dos dados gerais

A grande maioria de fluxos de tráfego plano dos dados através da rede como 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. As características tais como opções IP, especificamente a opção de roteamento de origem, formam um desafio da segurança em redes de hoje.

O uso do trânsito ACL é igualmente relevante ao endurecimento do plano dos dados. Veja o tráfego de trânsito de filtração com seção do trânsito ACL deste original para mais informação.

Queda seletiva das opções IP

Há dois interesses de segurança apresentados por opções IP. Trafique que contem opções IP deve ser comutado por processamento pelos dispositivos IOS Cisco, que podem conduzir à carga de CPU elevado. As opções IP igualmente incluem a funcionalidade para alterar o trajeto que o tráfego toma através da rede, permitindo potencial que subverta controles de segurança.

Devido a estes interesses, as opções do global configuration command ip {drop | ignore} foi adicionado aos Cisco IOS Software Release 12.3(4)T, 12.0(22)S, e 12.2(25)S. No primeiro formulário deste comando, as opções IP deixam cair, todos os pacotes IP que contêm as opções IP que são recebidas pelo dispositivo IOS Cisco são deixadas cair. 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.

O segundo formulário deste comando, opções IP ignorar, configura o dispositivo IOS Cisco para ignorar as opções IP que são contidas em uns pacotes recebidos. Quando isto abrandar as ameaças relativas às opções IP para o dispositivo local, é possível que os dispositivos de downstream poderiam ser afetados pela presença de opções IP. É por esta razão que o formulário queda deste comando é altamente recomendado. Isto é demonstrado no exemplo de configuração:


!

ip options drop

!

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

Uma vez que a queda seletiva das opções IP foi permitida, o comando exec do tráfego IP da mostra pode ser usado a fim de determinar o número de pacotes que são deixado cair devido à presença de opções IP. Esta informação esta presente no contador de queda forçado.

Refira a queda seletiva das opções IP ACL para obter mais informações sobre desta característica.

Desabilite o roteamento do origem de IP

O roteamento do origem de entrega de IP a rota de origem e as opções de rota de registro fracas em tandem ou a rota de origem restrita junto com a opção de rota de registro permitir a fonte do IP datagrama de especificar o caminho de rede tomadas de um pacote. Esta funcionalidade pode ser usada nas tentativas de distribuir o tráfego em torno dos controles de segurança na rede.

Se as opções IP não foram completamente desabilitadas através da característica seletiva da gota das opções IP, ele são importantes que o roteamento do origem de IP é deficiente. O roteamento do origem de IP, que é permitido à revelia em todos os Cisco IOS Software Release, é deficiente através do comando global configuration do no ip source-route. Este exemplo de configuração ilustra o uso deste comando:


!

no ip source-route

!

Refira a referência do comando cisco IOS para obter mais informações sobre do comando ip source-route.

Desabilite o redirecionamentos de ICMP

Os redirecionamentos de ICMP são usados a fim informar um dispositivo de rede de um trajeto melhor a 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 atacante fazer com que o dispositivo Cisco IOS envie muitas mensagens do redirecionamento de ICMP, tendo por resultado uma carga de CPU elevado. Por este motivo, recomenda-se que a transmissão dos redirecionamentos de ICMP seja deficiente. Os redirecionamentos de ICMP são deficientes usando o no ip redirects do comando interface configuration, segundo as indicações do exemplo de configuração:


!

interface FastEthernet 0
 no ip redirects

!

Refira o comando cisco IOS para obter mais informações sobre o IP redirect o comando interface configuration.

Desabilite ou limite broadcasts direto de IP

Os broadcasts direto de IP tornam possível enviar um pacote da transmissão IP a uma sub-rede do IP remoto. Uma vez que alcança a rede remota, o dispositivo IP da transmissão envia o pacote como uma transmissão da camada 2 a todas as estações na sub-rede. Esta funcionalidade da transmissão direcionada de entregue como um auxílio da amplificação e da reflexão em diversos ataques, incluindo o ataque de smurf.

As versões atuais do Cisco IOS Software têm esta funcionalidade desabilitada por padrão; contudo, pode ser permitida através do comando interface configuration da transmissão direta de IP. As versões do Cisco IOS Software antes de 12.0 têm esta funcionalidade permitida por padrão.

Se uma rede absolutamente requer a funcionalidade da transmissão direcionada, seu uso deve ser controlado. Isto é possível usando um Access Control List como uma opção ao comando ip directed-broadcast. Este exemplo de configuração limita transmissões direcionadas à aqueles pacotes de UDP que 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

!

Refira o comando de IP Addressing Services para obter mais informações sobre do comando ip directed-broadcast.

Tráfego de trânsito de filtração com trânsito ACL

É possível controlar que tráfego transita pela rede usando o trânsito ACL (tACLs). Isto é em contraste com a infra-estrutura ACL que procura ao filtrar tráfego que é destinado à rede própria. A filtração fornecida por tACLs é benéfica quando é desejável ao filtrar tráfego a um grupo particular de dispositivos ou de tráfego que esteja transitando pela rede.

Este tipo de filtração é executado tradicionalmente por firewall. Contudo, há os exemplos onde pode ser benéfico executar isto que filtra em um dispositivo IOS Cisco na rede, por exemplo, onde filtrar deve ser executada mas nenhum firewall esta presente.

O trânsito ACL é igualmente um lugar apropriado em que para executar proteções estáticas anti-falsificação. Veja a anti seção das proteções da falsificação deste documento para mais informação.

Consulte Listas de Controle de Acesso de Trânsito: Filtração em sua borda para obter mais informações sobre dos tACLs.

Filtração do pacote ICMP

O protocolo Protocolo de controle de mensagens de Internet (ICMP) foi projetado como um protocolo de controle para o IP. Como tal, as mensagens que transporta podem ter ramificação de grande envergadura no TCP e nos protocolos IP em geral. O ICMP é usado pelas ferramentas de Troubleshooting da rede executa o ping e traceroute, assim como pelo Path MTU Discovery; contudo, a conectividade externa ICMP é raramente necessária para a operação apropriada de uma 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 ACL permite o ICMP das redes confiáveis ao obstruir todos os pacotes ICMP de outras fontes:


!

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

!

Fragmentos de filtração IP

Como detalhado previamente no acesso de limitação à rede com seção da infra-estrutura ACL deste documento, a filtração de pacotes IP fragmentados pode levantar um desafio aos dispositivos de segurança.

Devido à natureza não instuitiva do fragmento que segura, os fragmentos IP frequentemente são inadvertidamente permitidos por ACL. A fragmentação é frequentemente usada nas tentativas de iludir a detecção pelo Intrusion Detection Systems. É por estas razões que os fragmentos IP são frequentemente usados nos ataques e devem explicitamente ser filtrados na parte superior de todos os tACLs configurados. O ACL abaixo inclui a filtração detalhada de fragmentos IP. A funcionalidade ilustrada neste exemplo deve ser usada conjuntamente 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

!

Refira a lista de controle de acesso e fragmentos IP para obter mais informações sobre a manipulação ACL de pacotes IP fragmentados.

Apoio ACL para opções IP de filtração

Começando no Cisco IOS Software Release 12.3(4)T, o Cisco IOS Software apoia o uso dos ACL filtrar os pacotes IP baseados nas opções IP que são contidas no pacote. A presença de opções IP dentro de um pacote pode indicar uma tentativa de subverter controles de segurança na rede ou de alterar de outra maneira as características do trânsito de um pacote. É por estas razões que os pacotes com opções IP devem ser filtradas na borda da rede.

Este exemplo deve ser usado com o índice dos exemplos anteriores para incluir a filtração completa dos 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

!

Refira ao apoio ACL para opções IP de filtração para mais informação.

Proteções anti-falsificação

Muitos ataques utilizam a falsificação do endereço IP de origem para serem eficazes ou para esconder o origem verdadeira de um ataque e para impedir o retorno de monitoramento exato. 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.

A proteção de origem de IP é eficaz na falsificação de minimização para as redes que estão sob o controle administrativo direto pela porta de switch de execução, pelo MAC address, e pela verificação do endereço de origem. O unicast RPF fornece a verificação da rede da fonte e pode reduzir ataques falsificado das redes que não são abaixo controle administrativo direto. A segurança de porta pode ser usada a fim de validar endereços MAC na camada de acesso. A inspeção do Dynamic Resolution Protocol (ARP) Inspection (DAI) abranda os vetores do ataque que utilizam o envenenamento ARP em segmentos locais.

Unicast RPF

O unicast RPF permite um dispositivo de verificar que o endereço de origem de um pacote enviado pode ser alcançado através da relação que recebeu o pacote. Você não deve confiar no unicast RPF como a única proteção contra a 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 confia em você para permitir o Cisco Express Forwarding em cada dispositivo, e é configurado em uma base da interface per.

O unicast RPF pode ser configurado em um de dois modos: fraco ou restrito. 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 IP verifique o comando interface configuration, a palavra-chave configura o modo fraco quando a palavra-chave RX configurar o modo restrito.

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


!

ip cef

!

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

!

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

Refira o modo fraco do Unicast Reverse Path Forwarding para obter mais informações sobre esta característica.

Proteção de origem de IP

A proteção de origem de IP é os significados efetivo da prevenção da falsificação que podem ser usados se você tem o controle sobre interfaces de camada 2. Informação dos usos da proteção de origem de IP da espião DHCP para configurar dinâmicamente um Access Control List da porta (PACL) na interface de camada 2, negando algum tráfego dos endereços IP que não são associados na tabela de ligação do origem de IP.

A proteção de origem de IP pode ser aplicada às interfaces de camada 2 que pertencem aos DHCP com VLANs com espião habilitado. 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 permitida com o IP verifica o comando configuration da interface de segurança da porta de origem. Isto exige a opção de informação da espião DHCP do global configuration command ip; adicionalmente, o servidor DHCP deve apoiar a opção de DHCP 82.

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

Segurança da porta

A segurança de porta é usada a fim de abrandar a falsificação do MAC address 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. Uma vez que a segurança de porta determinou uma violação MAC, pode utilizar um de quatro modos da violação. Estes modos protegem, restringem, parada programada, e parada programada VLAN. Nos exemplos quando uma porta fornece somente o acesso para uma estação de trabalho única que utiliza protocolos padrão, um número máximo onde um pode ser suficiente. Os protocolos que leverage endereços MAC virtuais tais como o HSRP não funcionam quando o número máximo é ajustado a 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>

!

Refira configurar a segurança de porta para obter mais informações sobre de configurar a segurança de porta.

Inspeção ARP dinâmica

A inspeção ARP dinâmica (DAI) pode ser utilizada para abrandar ataques do 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 atacante usa o envenenamento ARP a fim de executar um ataque que envolva pessoas.

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, DAI utiliza os dados que são gerados pela característica da espião DHCP. Os pacotes ARP que são recebidos em relações confiadas não são validados e os pacotes inválidos em interfaces não confiável 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, o ARP ACL é exigido para habilitar 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>

!

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

ACL anti-falsificação

Os ACL manualmente configurados podem fornecer a proteção anti-falsificação estática contra os ataques que utilizam o espaço de endereços não utilizado e não confiável conhecido. 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. Os ACL anti-falsificação exigem a monitoramento regular enquanto podem freqüentemente mudar. A falsificação pode ser minimizada no tráfego que origina da rede local aplicando os ACL de partida que limitam o tráfego aos endereços do local válido.

Este exemplo demonstra como os ACL podem ser usados a fim de 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ê configura estes tipos de ACL, procure uma referência atualizada que seja conclusiva.


!

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

!

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

!

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

A lista oficial de endereços do Internet não alocada é mantida pela equipe Cymru. A informação adicional sobre endereços não utilizados de filtração está disponível na página da referência de Bogon .leavingcisco.com

Limitando o impacto CPU do tráfego plano dos dados

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. O plano dos dados, que consiste no tráfego que transita pelo dispositivo de rede, deve ser fixado para assegurar a operação da gestão e para controlar planos. Se o tráfego de trânsito pode fazer com que um dispositivo processe o tráfego do interruptor, o plano do controle de um dispositivo pode ser afetado que possa conduzir a um rompimento operacional.

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

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

  • Logging ACL - O tráfego do logging ACL consiste em todos os pacotes que forem gerado devido a uma combinação (permitir ou negar) de um ACE em que a palavra-chave do registro é usada.

  • Unicast RPF - O unicast RPF usado conjuntamente com um ACL pode conduzir à comutação do processo de determinados pacotes.

  • Opções IP - Todos os pacotes IP com as opções incluídas devem ser processados pelo CPU.

  • Fragmentação - Todo o pacote IP que exigir a fragmentação deve ser passada ao CPU para processamento.

  • Expiração do tempo ao vivo (TTL) - Os pacotes que têm um valor TTL inferior ou igual a 1 para exigir o tempo do protocolo Protocolo de control de mensajes de Internet (ICMP) excederam (tipo 11 ICMP, código 0) as mensagens a ser enviadas, que conduz ao processamento de CPU.

  • ICMP não alcançável - Os pacotes que conduzem aos mensagens que não chega a seu destino do ICMP devido à distribuição, o MTU, ou a filtração são processados pelo CPU.

  • Tráfego que exige uma requisição ARP - Os destinos para que uma entrada de ARP não existe exigem o processamento pelo CPU.

  • Tráfego não-IP - Todo o tráfego não-IP é processado pelo CPU.

Veja a seção de endurecimento plana dos dados gerais deste documento para obter mais informações sobre do endurecimento plano dos dados.

Filtração no valor TTL

Você pode usar o apoio ACL para filtrar na característica do valor TTL, introduzido no Cisco IOS Software Release 12.4(2)T, em uma lista de acesso IP estendido para filtrar os pacotes baseados no valor TTL. Esta característica pode ser usada a fim proteger um dispositivo que recebe o tráfego de trânsito onde o valor TTL é um zero ou esse. Os pacotes de filtragem baseados em valores TTL podem igualmente ser usados a fim assegurar que o valor TTL não é mais baixo do que o diâmetro da rede, assim a proteção do plano do controle de dispositivos de infra-estrutura a jusante dos ataques da expiração TTL.

Note que algumas aplicações e ferramentas tais como o traceroute usam pacotes da expiração TTL para o teste e os propósitos de 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 

!

Refira a identificação e a mitigação do ataque da expiração TTL para obter mais informações sobre dos pacotes de filtragem baseados no valor TTL.

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

Começando com o Cisco IOS Software Release 12.4(4)T, o pacote flexível que combina (FPM) permite que um administrador combine em bit arbitrários de um pacote. Esta política FPM deixa cair pacotes com um valor TTL menos de seis.


!

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

!

Refira a harmonização flexível do pacote, situada no pacote flexível do Cisco IOS que combina o homepage, para obter mais informações sobre a característica.

Filtração na presença de opções IP

No Cisco IOS Software Release 12.3(4)T e Mais Recente, você pode usar o apoio ACL para a característica de filtração das opções IP em uma lista de acesso IP nomeada estendido para filtrar pacotes IP com as opções IP atuais. Os pacotes IP de filtração que são baseados na presença de opções IP podem igualmente ser usados a fim impedir que o plano do controle dos dispositivos de infra-estrutura tenha que processar estes pacotes a nível CPU.

Note que o apoio ACL para opções IP que de filtração a característica pode ser usada somente com nomeado, ACL estendido. Deve-se igualmente notar que o RSVP, a engenharia de tráfego do Multiprotocol Label Switching, as versões IGMP 2 e 3, e outros protocolos que usam pacotes das opções IP não podem poder funcionar corretamente se os pacotes para estes protocolos são deixados cair. Se estes protocolos estão no uso na rede, a seguir o apoio ACL para opções IP de filtração pode ser usado; contudo, a característica seletiva da queda das opções IP ACL poderia deixar cair este tráfego e estes protocolos não podem funcionar corretamente. Se não há nenhum protocolo no uso que exige opções IP, a queda seletiva das opções IP ACL é o método preferido para deixar cair estes pacotes.

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


!

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

!

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

!

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

  • 0 extremidades da lista de opções (eool)

  • 7 Rota do registro (registro-rota)

  • 68 Selo de tempo (timestamp)

  • 131 - Rota de origem fraca (lsr)

  • 137 - Rota de origem restrita (ssr)


!

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

!

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

!

Refira o apoio ACL para opções IP de filtração para obter mais informações sobre desta característica. Veja a seção de endurecimento plana dos dados gerais deste original para obter mais informações sobre da gota seletiva das opções IP ACL.

Consulte Listas de Controle de Acesso de Trânsito: Filtração em sua borda para obter mais informações sobre do tráfego de filtração do trânsito e da borda.

Uma outra característica no Cisco IOS Software que pode ser usado a fim filtrar pacotes com opções IP é CoPP. Começando com o Cisco IOS Software Release 12.3(4)T, CoPP permite que um administrador filtre o fluxo de tráfego de pacotes do plano do controle. Um dispositivo que apoie CoPP e apoio ACL para opções IP de filtração, introduzidos no Cisco IOS Software Release 12.3(4)T, pode usar uma política da lista de acessos para filtrar os pacotes que contêm opções IP.

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


!

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

!

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

!

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

!

control-plane
 service-policy input COPP-POLICY

!

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

  • 0 extremidades da lista de opções (eool)

  • 7 Rota do registro (registro-rota)

  • 68 Selo de tempo (timestamp)

  • 131 Rota de origem fraca (lsr)

  • 137 Rota de origem restrita (ssr)


!

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

!

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

!

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

!

control-plane
 service-policy input COPP-POLICY

!

Nas políticas precedentes de CoPP, as entradas do Access Control List (ACE) pacotes dessa combinação com o resultado da ação da licença nestes pacotes que estão sendo rejeitados pela função da queda do mapa de política, quando os pacotes que combinam a ação da negação (não mostrada) não forem afetados pela função da queda do mapa de política.

Refira ao apoio ACL para opções IP de filtração para mais informação.

Refira ao plano de distribuição do controle que policia e controle o policiamento plano para obter mais informações sobre da característica de CoPP.

Controle a proteção plana

Começando com o Cisco IOS Software Release 12.4(4)T, controle a proteção plana (CPPr) pode ser usado a fim de restringir o tráfego plano ou de controlar de polícia pelo CPU de um dispositivo IOS Cisco. Quando similar a CoPP, CPPr tem a capacidade para restringir ou policiar o tráfego usando a granularidade mais fina do que CoPP. CPPr divide o plano agregado do controle em três categorias separadas do plano do controle conhecidas como subinterfaces: As subinterfaces do host, do trânsito, e da CEF-Exceção existem.

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 precedente de CPPr, as entradas do Access Control List que combinam pacotes com a ação da licença conduzem a estes pacotes que estão sendo rejeitados pela função da queda do mapa de política, quando os pacotes que combinam a ação da negação (não mostrada) não forem afetados pela função da queda do mapa de política.

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

Trafique a identificação e o retorno de monitoramento

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

Netflow

O NetFlow identifica a atividade de rede anômala e relacionado à segurança por fluxos de rede de seguimento. Os dados de Netflow podem ser vistos e analisado através do comando line interface(cli), ou os dados podem ser exportados para um coletor de Netflow do anúncio publicitário ou do freeware para a agregação e a análise. Os coletores de Netflow, com da tensão a longo prazo, podem fornecer a análise do comportamento de rede e do uso. O NetFlow funciona executando a análise em atributos específicos dentro dos pacotes IP e criar fluxo. A versão 5 é a versão de uso mais comum do NetFlow, contudo, a versão 9 é mais elástica. Os fluxos do NetFlow podem ser criados usando dados de tráfego provados em ambientes do alto-volume.

O Cisco Express Forwarding (CEF), ou o CEF distribuído, são uma condição prévia a permitir o NetFlow. O NetFlow pode ser configurado em roteadores e em interruptores.

Este exemplo ilustra a configuração básica desta característica. Em versões anteriores do Cisco IOS Software, o comando habilitar o NetFlow em uma relação é o fluxo do cache de rota IP em vez do fluxo IP {entrada | saída}.


!

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

!

interface <interface> 
 ip flow <ingess|egress> 

!

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

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

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

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

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

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

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

Classificação ACL

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

Um administrador pode expedir uma resposta do incidente usando a classificação ACL com a lista de acesso da mostra e os comandos exec claros dos contadores da lista de acesso IP.

Este exemplo ilustra a configuração de uma classificação ACL 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 

!

A fim de identificar o tráfego que usa uma classificação ACL, use o comando EXEC show access-list acl-name. Os contadores ACL podem ser cancelados usando o comando exec clear ip access-list counters ad-name .

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) 

Refira a compreendendo a Lista de Controle de Acesso Registrando para obter mais informações sobre como permitir potencialidades de registro dentro dos ACL.

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

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

Estas seções fornecem uma vista geral das características, dos benefícios, e das encenações do uso potencial dos VACL e dos PACL.

Controle de acesso com mapas VLAN

Os VACL, ou o mapas VLAN aplicam a todos os pacotes que incorporam o VLAN, fornecem a capacidade para reforçar o controle de acesso no tráfego do intra-VLAN. Este não é ACL de utilização possíveis em interfaces roteadas. Por exemplo, um mapa VLAN pode ser usado a fim de impedir os anfitriões que são contidos dentro do mesmo VLAN da comunicação um com o outro, desse modo minimizando oportunidades para que atacantes ou worms explorem um host no mesmo segmento de rede. A fim negar pacotes de usar um mapa VLAN, você pode criar um Access Control List (ACL) essa combinação de tráfego e, no mapa VLAN, se ajusta à ação para deixar cair. 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 do acesso de vlan apoiam o IPv4 e as listas de acessos MAC; contudo, não suportam o registo ou o IPv6 ACL.

Este exemplo utiliza uma lista de acessos nomeada prolongada que ilustre a configuração desta característica:


!

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 VLAN para negar portas TCP 139 e 445 assim como o protocolo do VINES-IP:


!

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

!

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

!

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

!

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

!

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

!

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

!

vlan filter VACL vlan 100 

!

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

Controle de acesso com PACL

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

Este exemplo utiliza uma lista de acesso nomeada prolongada a fim ilustrar a configuração desta característica:


!

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

!

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

!

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

Controle de acesso com MAC

As lista de controle de acesso MAC ou as lista prolongadas podem ser aplicadas na rede IP com o uso deste comando no modo de configuração da interface:

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

Nota: É classificar 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.

Este comando de interface tem que ser aplicado na interface de entrada e instrui o Forwarding Engine para não inspecionar o cabeçalho IP. O resultado é que você pode usar uma lista de acessos MAC no ambiente IP.

Usando VLAN privados

Os VLAN privados (PVLAN) são uns recursos de segurança da camada 2 que limitem a conectividade entre estações de trabalho ou server dentro de um VLAN. Sem PVLAN todos os dispositivos em uma camada 2 VLAN podem comunicar-se livremente. As situações da comunicação de rede existem onde a segurança pode ser ajudada limitando uma comunicação entre dispositivos em um único VLAN. Por exemplo, os PVLAN são frequentemente usados a fim de proibir uma comunicação entre um servidor em uma sub-rede publicamente acessível. Se um servidor único fica comprometido a falta da conectividade a outros servidores devido à aplicação dos PVLAN pode ajudar a limitar o acordo ao um servidor.

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

Vlan isolado

A configuração de um VLAN secundário como um vlan isolada impede completamente uma comunicação entre dispositivos no VLAN secundário. Pode somente haver um vlan isolado pela VLAN principal, e somente as portas misturadas podem comunicar-se com as portas em um vlan isolado. Os vlan isolados devem ser usados em redes não confiáveis como as redes que apoiam convidados.

Este exemplo de configuração configura o VLAN 11 como um VLAN isolado e associa-o ao VLAN principal, VLAN 20. O exemplo abaixo igualmente configura os FastEthernet 1/1 da relação como uma porta isolada no VLAN 11:


!

vlan 11
 private-vlan isolated

!

vlan 20
 private-vlan primary
 private-vlan association 11

!

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

!

VLAN de comunidade

Um VLAN secundário que seja configurado enquanto um VLAN de comunidade permite uma comunicação entre membros do VLAN assim como com todas as portas misturadas no 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. Os VLAN de comunidade devem ser usados a fim agrupar os servidores que precisam ter conectividade um com o outro, mas onde a conectividade a todos os outros dispositivos no VLAN não é exigida. Este cenário é comum em uma redes publicamente acessível ou em qualquer lugar aquela server fornece o índice aos clientes não confiáveis.

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


!

vlan 12
 private-vlan community

!

vlan 20
 private-vlan primary
 private-vlan association 12

!

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

!

Portas misturadas

As portas de switch que são colocadas no VLAN principal são conhecidas como portas misturadas. As portas misturadas podem comunicar-se com todas portas restantes no preliminar e nos VLAN secundários. 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

!

Ao executar PVLAN, é importante assegurar-se de que a configuração da camada 3 no lugar apoie as limitações que são impor por PVLAN e não as permita a configuração de PVLAN ser subvertidas. A camada 3 que filtra usando um Roteador ACL ou firewall pode impedir a subversão da configuração de PVLAN.

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

Conclusão

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

Reconhecimentos

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

Anexo: Dispositivo IOS Cisco que endurece a lista de verificação

Esta lista de verificação é uma coleção de todas as etapas de endurecimento que são 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. Os administradores são recomendados avaliar cada opção para seu risco potencial antes de executar a opção.

Plano de gerenciamento

  • Senhas

    • Permita o hashing MD5 (opção secreta) para senhas habilitadas e de usuários locais.

    • Configurar o fechamento da nova tentativa da senha

    • Desabilite a recuperação de senha (considere o risco)

  • Desabilite serviços não utilizados

  • Configurar manutenções de atividade TCP para sessões de gerenciamento

  • Ajuste a memória e as notificações de threshold de CPU

  • Configurar

    • Notificações da memória e de threshold de CPU

    • Memória da reserva para o acesso de console

    • Detector de escape de memória

    • Detecção do excesso de buffer

    • Coleção aumentada do crashinfo

  • Use iACLs para restringir o acesso de gerenciamento

  • Filtre (considere o risco)

    • Pacotes ICMP

    • Fragmentos IP

    • Opções IP

    • Valor TTL nos pacotes

  • Controle a proteção plana

    • Configurar a filtração da porta

    • Configurar pontos iniciais da fila

  • Acesso de gerenciamento

    • Use a proteção do plano de gerenciamento para restringir interfaces de gerenciamento

    • Ajuste o intervalo do executivo

    • Use um protocolo de transporte cifrado (tal como o SSH) para o acesso CLI

    • Controle o transporte para as linhas vty e o tty (opção da classe do acesso)

    • Advirta usando bandeiras

  • AAA

    • Use o AAA para a autenticação e a reserva

    • Use AAA (TACACS+) para o comando authorization

    • Use o AAA explicando

    • Use servidores AAA redundantes

  • SNMP:

    • Configurar as comunidades SNMPv2 e aplique ACL

    • Configurar o SNMPv3

  • Registro

    • Configure o registro centralizado

    • Ajuste níveis de registro para todos os componentes relevantes

    • Ajuste a fonte-interface de registo

    • Configurar a granularidade do data/hora de registro

  • Gerenciamento de configuração

    • Substitua e rollback

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

    • Configuração de resiliência do software

    • Notificações da alteração de configuração

Controle o plano

  • Desabilitar (considere o risco)

    • Redirecionamentos de ICMP

    • ICMP não alcançável

    • Proxy ARP

  • Configurar a autenticação de NTP se o NTP está sendo usado

  • Configurar o policiamento do plano do controle/proteção (filtração da porta, os pontos iniciais da fila)

  • Fixe protocolos de roteamento

    • BGP (TTL, MD5, prefixos máximos, listas de prefixo, trajeto ACL do sistema)

    • IGP (MD5, interface passiva, filtragem de rota, consumo do recurso)

  • Configurar limitadores da taxa do hardware

  • Fixe os primeiros protocolos da redundância de salto (GLBP, HSRP, o VRRP)

Plano dos dados

  • Configurar a queda seletiva das opções IP

  • Desabilitar (considere o risco)

    • Roteamento do origem de IP

    • Broadcasts direto de IP

    • Redirecionamentos de ICMP

  • Broadcasts direto de IP do limite

  • Configurar tACLs (considere o risco)

    • Filtre o ICMP

    • Filtre fragmentos IP

    • Filtre opções IP

    • Filtre valores TTL

  • Configure proteções anti-falsificação exigidas

    • ACL

    • Proteção de origem de IP

    • Inspeção ARP dinâmica

    • Unicast RPF

    • Segurança da porta

  • Controle a proteção plana (a CEF-exceção do controle plano)

  • Configurar o NetFlow e a classificação ACL para a identificação do tráfego

  • Configure exigiu o controle de acesso ACL (mapas VLAN, PACL, o MAC)

  • Configurar VLAN privados

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Informações Relacionadas


Document ID: 13608