IP : Serviços de endereçamento IP

Melhorando a Segurança em Roteadores Cisco

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


Interativo: Este documento oferece uma análise personalizada do seu dispositivo Cisco.


Índice

Introdução
Pré-requisitos
     Requisitos
     Componentes Usados
     Convenções
Informações complementares
Gerenciamento de Senha
     enable secret
     service password-encryption (e limitações)
Acesso Interativo de Controle
     Portas do Console
     Acesso Interativo Geral
     Banners de Advertência
Serviços de Gerenciamento Configurados Normalmente
     SNMP
     HTTP
Gerenciamento e Acesso Interativo através da Internet (e outras Redes Não-Confiáveis)
     Farejadores de Pacotes
     Outros Riscos de Acesso à Internet
Registro
     Informações sobre a Gravação de Registros
     Registrar Violações da Lista de Acesso
IP Routing Seguro
     Anti-Falsificação
     Controle de Broadcasts Direcionados
     Integridade de Caminho
Gerenciamento de Inundação
     Inundações de Trânsito
     Autoproteção do Roteador
Serviços Possivelmente Desnecessários
     Serviços Pequenos de TCP e UDP
     Finger
     NTP
     CDP
Mantenha-se Atualizado
Lista de Comandos
Discussões relacionadas da comunidade de suporte da Cisco
Informações Relacionadas

Introdução

Este documento é uma discussão informal sobre algumas definições de configuração da Cisco que administradores de rede devem pensar em alterar em seus roteadores, especialmente em seus roteadores de borda, para melhorar a segurança. Este documento trata de itens básicos de configuração de texto padrão que são aplicáveis de forma praticamente universal em redes IP, bem como de alguns itens inesperados dos quais você deve ter ciência.

Se você tiver a saída de um comando show running-configuration de seu dispositivo da Cisco, é possível usar para visualizar possíveis problemas e correções.Você deverá ser um cliente registrado, estar conectado e possuir o JavaScript habilitado para usar .

Pré-requisitos

Requisitos

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

Componentes Usados

Este documento não está restrito a versões específicas de software e de hardware.

Convenções

Consulte Convenções de Dicas Técnicas da Cisco para obter mais informações sobre as convenções de documentos.

Informações complementares

Esta não é uma lista completa, nem pode ser substituída pelo conhecimento do administrador da rede. Este documento é um lembrete de algumas coisas que, às vezes, são esquecidas. Somente comandos importantes para redes IP são mencionados. Muitos dos serviços habilitados em roteadores Cisco exigem uma configuração de segurança cuidadosa. No entanto, este documento baseia-se principalmente em serviços habilitados por padrão, ou que quase sempre são habilitados pelos usuários, e que talvez precisem ser desabilitados ou reconfigurados.

Isso é especialmente importante porque algumas das configurações padrão do Cisco IOS® Software estão presentes por razões históricas. As configurações faziam sentido quando foram escolhidas, mas podem ser diferentes se novos padrões forem escolhidos atualmente. Outros padrões fazem sentido para a maioria dos sistemas, mas podem criar exposições de segurança se forem usados em dispositivos que fazem parte de uma defesa de perímetro de rede. Outros ainda, são realmente exigidos por padrões, mas nem sempre são desejáveis do ponto de vista de segurança.

O Cisco IOS Software possui muitas características específicas de segurança, como listas de acesso de filtragem de pacotes, Conjunto de Recursos do Cisco IOS Firewall, Interceptação de TCP, AAA e criptografia. Muitas outras características, como registro de pacotes e Quality of Service (QoS), podem ser utilizadas para aumentar a segurança de rede contra vários ataques. Nenhum desses são discutidos, exceto superficialmente. Este não é um documento sobre configuração de firewall. Em sua maioria, trata-se de um documento sobre como proteger o próprio roteador e ignora a questão igualmente importante de proteção de outros dispositivos de rede.

Gerenciamento de Senha

Senhas e segredos similares, como strings de comunidade do Simple Network Management Protocol (SNMP), são a principal defesa contra acesso não autorizado ao roteador. A melhor maneira de tratar a maioria das senhas é mantê-las em um servidor de autenticação TACACS+ ou RADIUS. No entanto, quase todos os roteadores ainda possuem uma senha configurada localmente para acesso privilegiado e também podem ter outras informações de senha em seus arquivos de configuração.

enable secret

O comando enable secret é usado para definir a senha que garante acesso administrativo privilegiado ao sistema IOS. Uma senha secreta habilitada deve ser sempre configurada. Utilize o comando enable secret, e não o antigo comando enable password. O comando enable password utiliza um algoritmo de criptografia fraco. Consulte a seção service password-encryption deste documento para obter mais informações.

Se nenhuma senha secreta habilitada estiver definida e uma senha for configurada para a linha TTY do console, a senha do console poderá ser usada para obter o acesso privilegiado, mesmo a partir de uma sessão de VTY remota. Isso, quase certamente, não é o que você quer, mas é outra razão para estar certo de configurar uma habilitação de segredo.

service password-encryption (e limitações)

O comando service password-encryption orienta o software IOS a criptografar senhas, segredos CHAP, e dados similares que são salvos em seu arquivo de configuração. Isso é útil para evitar que observadores casuais leiam as senhas, como por exemplo quando espiam a tela do administrador.

No entanto, o algoritmo usado pelo comando service password-encryption é a cifra de Vigenere simples. Qualquer criptógrafo amador competente pode revertê-lo facilmente em algumas horas. O algoritmo não foi desenhado para proteger arquivos de configuração contra análises sérias, até mesmo por invasores levemente sofisticados, e não deverá ser usado para este propósito. Qualquer arquivo de configuração Cisco que contenha senhas criptografadas deve ser tratado com o mesmo cuidado usado para uma lista de texto puro dessas mesmas senhas.

Esse aviso de criptografia fraca não se aplica a senhas definidas com o comando enable secret, mas se aplica a senhas definidas com o comando enable password.

O comando enable secret usa o MD5 para hashing de senha. O algoritmo teve revisão pública considerável e não é reversível, até onde o pessoal da Cisco saiba. No entanto, ele está sujeito a ataques de dicionário. Um ataque de dicionário é quando um computador tenta todas as palavras de um dicionário ou de outra lista de senhas candidatas. Portanto, é aconselhável manter o arquivo de configuração longe de pessoas não confiáveis, especialmente se não tiver certeza de que as senhas foram bem escolhidas.

Acesso Interativo de Controle

Qualquer pessoa que possa efetuar logon em um roteador Cisco pode exibir as informações que provavelmente você não deseja disponibilizar ao público em geral. Um usuário que possa efetuar logon no roteador também pode usá-lo como relay para outros ataques de rede. Qualquer pessoa que possa obter acesso privilegiado ao roteador pode reconfigurá-lo. É necessário controlar logons interativos ao roteador para evitar acesso impróprio.

Embora a maioria dos acessos interativos esteja desabilitada por padrão, há exceções. A exceção mais evidente são as sessões interativas dos terminais assíncronos conectados diretamente, como o terminal do console, e das linhas de modem integradas.

Portas do Console

É importante lembrar que a porta do console de um dispositivo Cisco IOS tem privilégios especiais. Especificamente, se um sinal BREAK for enviado à porta do console durante os primeiros segundos após uma reinicialização, o procedimento de recuperação de senha pode ser facilmente utilizado para assumir o controle do sistema. Isso significa que invasores que interrompam a alimentação ou induzam um travamento do sistema, e que tenham acesso à porta do console através de um terminal conectado, um modem, um servidor de terminal, ou outro dispositivo de rede, podem assumir o controle do sistema, mesmo que não tenham acesso físico a ele ou a capacidade de conectar-se a ele normalmente.

Qualquer modem ou dispositivo de rede que forneça acesso à porta do console Cisco deve estar protegido com um padrão comparável ao da segurança usada para acesso privilegiado ao roteador. No mínimo, todo modem de console deverá ser de um tipo que possa exigir que o usuário dialup forneça uma senha de acesso, e a senha do modem deve ser gerenciada cuidadosamente.

Acesso Interativo Geral

Existem mais maneiras de obter conexões interativas para roteadores do que os usuários imaginam. O Cisco IOS Software, que depende da configuração e da versão do software, é compatível com as seguintes conexões:

  • via Telnet

  • rlogin

  • SSH

  • protocolos de rede que não sejam baseados em IP, como LAT, MOP, X.29 e V.120

  • possivelmente outros protocolos

  • via conexões assíncronas locais e discagens de modem

Mais protocolos para acesso interativo estão sempre sendo adicionados. O acesso Telnet interativo está disponível não apenas na porta TCP Telnet padrão (porta 23), mas também em uma gama de portas de numeração elevada.

Todos os mecanismos interativos de acesso utilizam a abstração TTY IOS (em outras palavras, todos eles envolvem sessões em linhas de um tipo ou de outro). Os terminais assíncronos locais e os modems dialup usam linhas padrão, conhecidas como TTYs. Conexões de rede remotas, independente do protocolo, utilizam TTYs virtuais (VTYs). A melhor forma de proteger um sistema é certificar-se de que os controles adequados sejam aplicados em todas as linhas, incluindo as linhas VTY e TTY.

Como é difícil ter certeza de que todos os modos de acesso possíveis tenham sido bloqueados, os administradores devem usar algum tipo de mecanismo de autenticação para garantir que logons em todas as linhas sejam controlados, mesmo em máquinas que supostamente deveriam ser inacessíveis a redes não confiáveis. Isso é especialmente importante para linhas VTY e para linhas conectadas aos modems ou outros dispositivos remotos.

Os comandos login e no password podem ser configurados para evitar completamente logons interativos. Esta é a configuração padrão para VTYs, mas não para TTYs. Há muitas formas de configurar senhas e outras formas de autenticação de usuário para linhas TTY e VTY. Consulte a documentação do Cisco IOS Software para obter mais informações.

Controle de TTYs

Terminais assíncronos locais são menos comuns do que antigamente, mas ainda existem em algumas instalações. A menos que os terminais estejam fisicamente protegidos, e normalmente mesmo se estiverem, o roteador deve ser configurado para exigir que os usuários, em terminais assíncronos locais, efetuem logon antes de utilizar o sistema. A maioria das portas TTY em roteadores modernos são conectadas a modems externos ou são implementadas por modems integrados. A segurança dessas portas é, evidentemente, ainda mais importante do que a segurança de portas terminais locais.

Por padrão, um usuário remoto pode estabelecer uma conexão a uma linha TTY através da rede. Isso é conhecido como Telnet reverso. Esse recurso permite que o usuário remoto interaja com o terminal ou o modem conectado à linha TTY. É possível aplicar a proteção por senha nessas conexões. É recomendável permitir que os usuários estabeleçam conexões com linhas de modem, para que possam efetuar chamadas de saída. No entanto, essa característica pode permitir que um usuário remoto se conecte a uma porta de terminal assíncrono local, ou até mesmo a uma porta de modem de discagem, e simule o prompt de logon do roteador para roubar senhas. Essa característica também pode executar ações para enganar usuários locais ou interferir em seu trabalho.

Execute o comando de configuração transport input none para desabilitar a característica de Telnet reverso em qualquer linha de modem ou assíncrona que não deva receber conexões de usuários de rede. Se possível, não use os mesmos modems para discagem interna e discagem externa e não permita conexões Telnet reversas nas linhas que você usa para discagem interna.

Controle de VTYs e Garantia de Disponibilidade de VTY

Todo VTY deve ser configurado para aceitar conexões somente com os protocolos realmente necessários. Isso é feito com o comando transport input. Por exemplo, um VTY que deva receber somente sessões Telnet é configurado com o comando transport input telnet, enquanto um VTY que permita sessões Telnet e SSH tem o comando transport input telnet ssh. Se seu software for compatível com um protocolo de acesso criptografado, como o SSH, ative somente esse protocolo e desative o Telnet de texto puro. Além disso, execute o comando ip access-class para restringir os endereços IP dos quais o VTY deve aceitar conexões.

Um dispositivo Cisco IOS possui um número limitado de linhas VTY, geralmente cinco. Quando todos os VTYs estiverem em uso, nenhuma conexão interativa remota poderá ser estabelecida. Isso cria a oportunidade de um ataque de recusa de serviço. Se um invasor pode abrir sessões remotas para todos os VTYs no sistema, o administrador legítimo poderá não conseguir efetuar logon. O invasor não precisa efetuar logon para fazer isso. As sessões podem simplesmente ser deixadas no prompt de logon.

Uma forma de reduzir essa exposição é configurar um comando ip access-class mais restritivo no último VTY do sistema do que nos outros VTYs. O último VTY, em geral VTY 4, pode ser restrito de forma a aceitar conexões apenas de uma única estação de trabalho administrativa específica, enquanto os outros VTYs podem aceitar conexões de qualquer endereço em uma rede corporativa.

Outra tática útil é executar o comando exec-timeout para configurar expirações VTY. Isso impede uma sessão ociosa de consumir um VTY indefinidamente. Embora sua eficácia contra ataques deliberados seja relativamente limitada, ele também oferece alguma proteção contra sessões deixadas ociosas acidentalmente. Da mesma forma, habilitar as keepalives de TCP em conexões recebidas com o comando service tcp-keepalives-in pode ajudar na proteção contra ataques maliciosos e sessões órfãs motivados por travamentos do sistema remoto.

É possível desabilitar todos os protocolos de acesso remoto que não sejam baseados em IP e usar a criptografia IPSec para todas as conexões interativas remotas com o roteador para fornecer uma proteção VTY completa. O IPSec é uma opção de custo extra e sua configuração foge do escopo deste documento.

Banners de Advertência

Em algumas jurisdições, as ações civis e criminais contra invasores que invadem sistemas são muito facilitadas se você utilizar um banner que informe a usuários não autorizados que o uso não é autorizado. Em outras jurisdições, pode ser proibido monitorar as atividades até mesmo de usuários não autorizados, a menos que você tenha realizado etapas para notificá-los de sua intenção. Uma forma de fornecer essa notificação é colocá-la em uma mensagem de banner, configurada com o comando banner login do Cisco IOS.

Requisitos de notificações legais são complexos e variam de acordo com a jurisdição e a situação. Mesmo em jurisdições, as opiniões legais variam e essa questão deve ser discutida com seu próprio advogado. Decida com seu advogado qual informação colocar em seu banner:

  • Uma observação informando que o sistema só poderá ser acessado ou utilizado por pessoal autorizado específico e, talvez, informações sobre quem pode autorizar o uso.

  • Uma observação informando que qualquer utilização não autorizada do sistema é ilegal e pode estar sujeita a penalidades civis e/ou criminais.

  • Uma observação informando que qualquer utilização do sistema pode ser registrada ou monitorada sem aviso prévio e que os arquivos de registro resultantes podem ser utilizados como evidência nos tribunais.

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

Por questões de segurança, e não do ponto de vista legal, o seu banner de logon não deve conter nenhuma informação específica sobre o roteador, como nome, modelo, qual software ele executa ou quem é o proprietário. Essas informações podem ser usadas por invasores.

Serviços de Gerenciamento Configurados Normalmente

Muitos usuários usam protocolos em vez de logon remoto interativo para gerenciar suas redes. Os protocolos mais comuns para essa finalidade são o SNMP e o HTTP.

Nenhum desses protocolos é habilitado por padrão e, como para qualquer outro serviço, a opção mais segura é não habilitá-los. Entretanto, se estiverem habilitados, eles deverão ser protegidos como descrito nesta seção.

SNMP

O SNMP é amplamente utilizado para monitoramento de roteador e freqüentemente utilizado para alterações de configuração do roteador. Infelizmente, a versão 1 do protocolo SNMP, que é a mais comumente usada, utiliza um esquema de autenticação muito fraco baseado em uma string de comunidade. Isso resulta em uma senha fixa transmitida através da rede sem criptografia. Se possível, utilize a versão 2 do SNMP, que é compatível com um esquema de autenticação de digest baseado em MD5 e permite acesso restrito a vários dados de gerenciamento.

Se precisar usar a versão 1 do SNMP, escolha strings de comunidade que não sejam óbvias. Não escolha, por exemplo, "pública" ou "privada". Se possível, evite utilizar as mesmas strings de comunidade para todos os dispositivos de rede. Utilize uma string ou strings diferentes para cada dispositivo, ou, pelo menos, para cada área da rede. Não faça uma string somente leitura igual a uma string de leitura/gravação. Se possível, deverá ser feita uma apuração periódica da versão 1 do SNMP com uma string de comunidade somente leitura. Strings leitura/gravação só devem ser utilizadas para operações de gravação reais.

A versão 1 do SNMP não é adequada para uso na Internet pública pelos seguintes motivos:

  • Ele utiliza as strings de autenticação de texto claro.

  • A maioria das implementações de SNMP envia essas strings repetidamente como parte da apuração periódica.

  • É um protocolo de transação, baseado em datagrama, que pode ser falsificado facilmente.

Antes de usá-lo dessa maneira, você deve considerar com cuidado as implicações.

Na maioria das redes, mensagens SNMP legítimas são emitidas apenas por determinadas estações de gerenciamento. Se isso ocorre em sua rede, provavelmente é necessário utilizar a opção número de lista de acesso no comando snmp-server community para restringir o acesso da versão 1 do SNMP apenas aos endereços IP das estações de gerenciamento. Não utilize o comando snmp-server community para qualquer finalidade em um ambiente da versão 2 do SNMP puro. Implicitamente, este comando habilita a versão 1 do SNMP.

Para a versão 2 do SNMP, configure a autenticação de digest com as palavras-chave authentication e md5 do comando de configuração snmp-server party. Se possível, utilize um valor secreto de MD5 diferente para cada roteador.

As estações de gerenciamento de SNMP normalmente possuem grandes bancos de dados de informações de autenticação, como strings de comunidade. Essas informações permitem o acesso a vários roteadores e outros dispositivos de rede. Essa concentração de informações torna a estação de gerenciamento de SNMP um alvo natural para ataques. Sendo assim, ela deve ser protegida de acordo.

HTTP

As versões mais recentes do Cisco IOS Software utilizam o protocolo HTTP da World Wide Web para serem compatíveis com o monitoramento e a configuração remotos. Geralmente, o acesso HTTP é equivalente ao acesso interativo ao roteador. O protocolo de autenticação utilizado para o HTTP é equivalente a enviar uma senha de texto claro através da rede. Infelizmente, não há provisões eficientes no HTTP para senhas baseadas em desafio ou de uma vez. Isso torna o HTTP uma escolha relativamente arriscada para utilização na Internet pública.

Se você escolher utilizar o HTTP para gerenciamento, execute o comando ip http access-class para restringir o acesso aos endereços IP apropriados. Além disso, execute o comando ip http authentication para configurar a autenticação. Assim como nos logons interativos, a melhor opção para autenticação HTTP é utilizar um servidor TACACS+ ou RADIUS. Evite utilizar a senha de habilitação como uma senha HTTP.

Gerenciamento e Acesso Interativo através da Internet (e outras Redes Não-Confiáveis)

Muitos usuários gerenciam seus roteadores remotamente e, às vezes, isto é feito via Internet. Qualquer acesso remoto não criptografado apresenta riscos, mas o acesso através de uma rede pública, como a Internet, é especialmente perigoso. Todos os esquemas de gerenciamento remoto, o que inclui acesso interativo, HTTP e SNMP, são vulneráveis.

Os ataques discutidos nesta seção são relativamente sofisticados, mas não são impossíveis para os invasores de hoje em dia. Freqüentemente, esses ataques podem ser impedidos se os provedores de rede pública envolvidos tomarem as medidas de segurança adequadas. Você precisa avaliar o seu nível de confiança nas medidas de segurança utilizadas pelos provedores que conduzem seu tráfego de gerenciamento. Mesmo que você confie em seus provedores, é recomendável tomar pelo menos algumas medidas para se proteger dos resultados de quaisquer erros que possam ocorrer.

Todos os cuidados aqui aplicam-se tanto a hosts quanto a roteadores. Este documento trata da proteção de sessões de logon do roteador, mas você deve utilizar mecanismos análogos para proteger seus hosts se eles forem administrados remotamente.

A administração remota da Internet é útil, mas requer atenção especial quanto à segurança.

Farejadores de Pacotes

Os invasores freqüentemente entram em computadores pertencentes a provedores de serviços de Internet (ISPs), ou em computadores de outras redes de grande porte, e instalam programas farejadores de pacotes. Esses programas monitoram o tráfego realizado através da rede e roubam dados, como senhas e strings de comunidade do SNMP. Embora isso tenha sido dificultado graças às melhorias de segurança realizadas por operadores de rede, ainda é relativamente comum. Além do risco de invasores externos, não é incomum que o pessoal de ISP de rogue instale farejadores. Qualquer senha enviada através de um canal não criptografado está em risco. Isso inclui as senhas de logon e habilitação de seus roteadores.

Se possível, evite efetuar logon em seu roteador utilizando um protocolo não criptografado em uma rede não confiável. Se o software do roteador for compatível, utilize um protocolo de logon criptografado, como SSH ou Telnet Kerberizado. Outra possibilidade é utilizar a criptografia IPSec para todo o tráfego de gerenciamento do roteador, incluindo Telnet, SNMP e HTTP. Todas essas características de criptografia estão sujeitas a determinadas restrições de exportação impostas pelo governo dos Estados Unidos e são itens que exigem solicitação especial e custos extras em roteadores Cisco.

Se você não tiver acesso a um protocolo de acesso remoto criptografado, outra possibilidade é utilizar um sistema de senha de uma vez, como S/KEY ou OPIE, junto com um servidor TACACS+ ou RADIUS. Isso controla os logons interativos e o acesso privilegiado ao seu roteador. A vantagem nesse caso é que uma senha roubada fica inutilizada, pois é invalidada pela sessão em que é roubada. Dados sem senha transmitidos na sessão permanecem disponíveis aos curiosos, mas muitos programas farejadores estão instalados para se concentrarem nas senhas.

Se você precisar enviar senhas através de sessões de Telnet de texto puro, altere suas senhas com freqüência e preste muita atenção no caminho percorrido pelas sessões.

Outros Riscos de Acesso à Internet

Além dos farejadores de pacotes, o gerenciamento remoto de Internet dos roteadores apresenta os seguintes riscos à segurança:

  • Para gerenciar um roteador por meio da Internet, você deve permitir que no mínimo alguns dos hosts da Internet tenham acesso ao roteador. É possível que esses hosts sejam comprometidos ou que seus endereços sejam falsificados. Ao permitir o acesso interativo a partir da Internet, sua segurança passa a depender não somente de suas próprias medidas anti-falsificação, mas também das medidas dos provedores de serviços envolvidos.

    Você pode certificar-se de que todos os hosts que têm permissão para efetuar logon em seu roteador estejam sob seu controle para reduzir os riscos. Além disso, utilize protocolos de logon criptografados com autenticação forte.

  • Às vezes é possível seqüestrar uma conexão TCP não criptografada (como uma sessão de Telnet), e tomar o controle de um usuário que estiver conectado. Embora esses ataques não sejam tão comuns quanto simples farejadores de pacotes e possam ser de complexa realização, eles são possíveis e podem ser usados por um invasor que tenha especificamente sua rede como alvo. A única solução real para o problema de seqüestro de sessão é utilizar um protocolo de gerenciamento criptografado com autenticação forte.

  • Ataques de recusa de serviço são relativamente comuns na Internet. Se sua rede estiver sujeita a um ataque de recusa de serviço, você pode não ser capaz de alcançar seu roteador para coletar informações ou tomar uma ação defensiva. Até mesmo um ataque à rede de outra pessoa pode prejudicar o acesso de gerenciamento à sua própria rede. Embora seja possível executar alguns passos para tornar sua rede mais resistente a ataques de recusa de serviço, a única defesa real contra esse risco é ter um canal de gerenciamento diferente e que esteja fora da banda, como uma discagem por modem, para uso em emergências.

Registro

Os roteadores Cisco podem registrar informações sobre diversos eventos, muitos dos quais têm significado de segurança. Os registros podem ser muito importantes para caracterizar e combater incidentes de segurança. Estes são os tipos principais de registro utilizados pelos roteadores Cisco:

  • Registro de AAA—Coleta informações sobre conexões de entrada do usuário, logons, logouts, acessos HTTP, alterações de nível de privilégio, comandos executados e eventos semelhantes. As entradas de registro de AAA são enviadas aos servidores de autenticação que utilizam os protocolos TACACS+ e/ou RADIUS e gravadas localmente por esses servidores, geralmente em arquivos de disco. Se você utiliza um servidor TACACS+ ou RADIUS, é possível habilitar o registro de AAA de várias formas. Execute os comandos de configuração de AAA, como aaa accounting, para habilitá-lo. Uma descrição detalhada da configuração de AAA está além do escopo deste documento.

  • Registro de armadilha de SNMP—Envia notificações de alterações significativas no status do sistema para as estações de gerenciamento do SNMP. Utilize armadilhas de SNMP somente se você tiver uma infra-estrutura de gerenciamento de SNMP pré-existente.

  • Registro de sistema—Registra uma grande variedade de eventos, dependendo da configuração do sistema. Os eventos de registro do sistema podem ser informados a vários destinos, incluindo os seguintes:

    • A porta do console do sistema (console de registro).

    • Servidores que utilizem o protocolo UNIX syslog (logging ip-address, logging trap).

    • Sessões remotas em VTYs e sessões locais em TTYs (monitor de registro, monitor do terminal).

    • Um buffer de registro local na RAM do roteador (registro em buffer).

    Do ponto de vista da segurança, os eventos mais importantes, geralmente gravados pelo registro do sistema, são as alterações de status de interface, alterações na configuração do sistema, correspondências de lista de acesso e eventos detectados pelo firewall opcional e características de detecção de intrusões.

    Cada evento de registro de sistema é rotulado com um nível de urgência. O intervalo de níveis das informações de depuração (de menor urgência), para as principais emergências de sistema. Cada destino de registro pode ser configurado com urgência limiar, e recebe eventos de registro somente no limite, ou acima dele.

Informações sobre a Gravação de Registros

Por padrão, as informações de registro do sistema são enviadas somente para a porta de console assíncrona. Pelo fato de muitas portas de console não serem monitoradas, ou serem conectadas a terminais sem memória histórica, e com exibições relativamente pequenas, essas informações podem não estar disponíveis quando necessário, especialmente quando um problema for depurado através da rede.

Quase todos os roteadores devem salvar informações de registro do sistema em um buffer de RAM local. O buffer de registro tem tamanho fixo e mantém apenas as informações mais recentes. O conteúdo do buffer é perdido sempre que o roteador é recarregado. Mesmo assim, um buffer de registro de tamanho moderado normalmente é muito útil. Em roteadores low-end, um tamanho de buffer razoável deve ser de 16384 ou 32768 bytes. Em roteadores high-end com muita memória (e muitos eventos registrados),até 262144 bytes é apropriado. É possível executar o comando show memory para certificar-se de que o roteador tenha espaço suficiente na memória para ser compatível com um buffer de registro. Execute o comando de configuração logging buffered buffer-size para criar o buffer.

A maioria das instalações maiores terá servidores syslog. É possível enviar informações de registro para um servidor com o server-ip-address do registro, e é possível controlar o limite de urgência para registro no servidor com o comando logging trap urgency . Mesmo que você tenha um servidor syslog, ainda terá que ativar o registro local.

Se o seu roteador tiver um relógio em tempo real ou estiver executando o NTP, execute o comando service timestamps log datetime msecs para criar um rótulo de tempo para entradas do registro.

Registrar Violações da Lista de Acesso

Caso use listas de acesso para filtrar o tráfego, talvez seja conveniente registrar os pacotes que violarem seus critérios de filtragem. Versões mais antigas do Cisco IOS Software utilizam a palavra-chave log para serem compatíveis com registros. Isso causa o registro dos endereços IP e dos números de porta associados aos pacotes que correspondam a uma entrada da lista de acesso. Versões mais recentes fornecem a palavra-chave log-input, que acrescenta informações sobre a interface a partir da qual o pacote foi recebido e o endereço MAC do host que o enviou.

Não é uma boa idéia configurar o registro para entradas de listas de acesso que correspondam a muitos pacotes. Isso faz com que os arquivos de registro fiquem muito grandes, o que pode causar redução no desempenho do sistema. Entretanto, as mensagens do log de lista de acesso têm taxa limitada e, portanto, o impacto não é catastrófico.

O registro da lista de acessos também pode ser usado para registrar o tráfego suspeito, a fim de caracterizar o tráfego associado aos ataques à rede.

IP Routing Seguro

Esta seção discute algumas medidas de segurança básicas relacionadas à forma como o roteador encaminha pacotes IP. Consulte Características essenciais do IOS para obter mais informações sobre essas questões.

Anti-Falsificação

Muitos ataques à rede consistem em um invasor que falsifica ou frauda os endereços de origem de datagramas IP. Alguns ataques dependem de falsificação para funcionar e outros ataques serão muito mais difíceis de rastrear, se o invasor conseguir usar o endereço de outra pessoa, em vez do seu próprio endereço. Portanto, é importante que os administradores de rede impeçam a falsificação sempre que possível.

A anti-falsificação deve ser realizada em todos os pontos da rede onde for possível. Normalmente é mais fácil e mais eficaz nas bordas entre grandes blocos de endereço ou entre domínios de administração de rede. É praticamente impossível realizar a anti-falsificação em todos os roteadores de uma rede, por causa da dificuldade de determinar quais endereços de origem podem aparecer legitimamente em uma determinada interface.

Se você for um ISP, poderá perceber que a anti-falsificação eficaz, junto com outras medidas efetivas de segurança, faz com que assinantes caros e problemáticos transfiram seus negócios para outros provedores. Os ISPs devem aplicar controles anti-falsificação nos pools de dialup e outros pontos de conexão do usuário final (consulte RFC 2267 leavingcisco.com).

Os administradores de firewalls corporativos ou de roteadores de perímetro às vezes instalam medidas anti-falsificação para evitar que hosts da Internet se apropriem de endereços de hosts internos, mas não tomam providências para evitar que os hosts internos se apropriem dos endereços dos hosts da Internet. Tente evitar a falsificação em ambas as direções. Há pelo menos três boas razões para se executar a anti-falsificação em ambas as direções em um firewall organizacional:

  1. Usuários internos ficam menos tentados a realizar ataques a redes e têm menos chances de sucesso se tentarem de fato.

  2. Hosts internos configurados incorretamente por acidente têm menor probabilidade de causar problemas para locais remotos. Portanto, têm menor probabilidade de causarem ligações de reclamação ou de denegrir a reputação da organização.

  3. Invasores externos freqüentemente entram em redes como pontos de partida para outros ataques. Esses invasores podem ficar menos interessados em uma rede que tenha proteção de falsificação de saída.

Anti-Falsificação com Listas de Acesso

Infelizmente, não é possível fornecer uma lista simples de comandos que forneçam a proteção contra falsificação adequada. A configuração da lista de acesso depende muito da rede individual. O principal objetivo é descartar pacotes que cheguem em interfaces que não sejam caminhos viáveis dos supostos endereços de origem desses pacotes. Por exemplo, em um roteador de duas interfaces que conecta uma rede corporativa à Internet, qualquer datagrama que chegar na interface da Internet, mas cujo campo de endereço de origem indicar que veio de uma máquina na rede corporativa, deverá ser descartado.

Da mesma forma, todos os datagramas que chegarem à interface conectada à rede corporativa, mas cujo campo de endereço de origem indicar que a origem é uma máquina fora da rede corporativa, deverão ser descartados. Se os recursos de CPU permitirem, aplique a anti-falsificação em todas as interfaces onde seja viável determinar o tráfego que deve chegar de forma lícita.

ISPs que transportam tráfego de trânsito podem ter oportunidades limitadas de configurar listas de acesso anti-falsificação, mas eles podem, em geral, filtrar pelo menos o tráfego externo que alegar ser originado a partir do próprio espaço de endereço do ISP.

Geralmente, os filtros anti-falsificação devem ser construídos com listas de acesso de entrada. Isso significa que os pacotes devem ser filtrados nas interfaces pelas quais chegam no roteador e não nas interfaces pelas quais deixam o roteador. Isso é definido aplicando-se o comando de configuração de interface ip access-group list in. É possível utilizar listas de acesso de saída em algumas configurações de duas portas para anti-falsificação, mas listas de entrada costumam ser de mais fácil compreensão mesmo nestes casos. Além disso, uma lista de entrada protege o próprio roteador contra ataques de falsificação, enquanto uma lista de saída protege somente dispositivos atrás do roteador.

Quando existem listas de acesso anti-falsificação, elas sempre devem recusar os datagramas com endereços de origem broadcast ou multicast e os datagramas com endereço loopback reservado como endereço de origem. Normalmente é apropriado para uma lista de acesso anti-falsificação filtrar todos os redirecionamentos de ICMP, independentemente do endereço de origem ou de destino. Esses são os comandos adequados:

access-list number deny icmp any any redirect
access-list number deny ip 127.0.0.0 0.255.255.255 any
access-list number deny ip 224.0.0.0 31.255.255.255 any
access-list number deny ip host 0.0.0.0 any

O quarto comando filtra pacotes de saída de muitos clientes BOOTP/DHCP. Portanto, ele não é adequado em todos os ambientes.

Anti-Falsificação com Verificações de RPF

Em quase todas as versões do Cisco IOS Software que são compatíveis com o Cisco Express Forwarding (CEF) é possível fazer com que o roteador verifique o endereço de origem de qualquer pacote com relação à interface pela qual o pacote entrou no roteador. Se a interface de entrada não for um caminho possível para o endereço de origem de acordo com a tabela de roteamento, o pacote será descartado.

Isso funciona somente quando o roteamento é simétrico. Se a rede for desenhada de forma que o tráfego do host A para o host B possa seguir normalmente um caminho diferente do caminho seguido do host B para o host A, sempre ocorrerá uma falha na verificação e a comunicação entre os dois hosts será impossível. Esse tipo de roteamento assimétrico é comum no centro da Internet. Antes de ativar essa característica, certifique-se de que a sua rede não utiliza um roteamento assimétrico.

Esta característica é conhecida como verificação de encaminhamento de caminho reverso (RPF) e é habilitada com o comando ip verify unicast rpf. Ele está disponível no Cisco IOS Software Releases 11.1CC, 11.1CT, 11.2GS e em todas as versões 12.0 e posteriores, mas requer que o CEF esteja habilitado para que seja efetivo.

Controle de Broadcasts Direcionados

Broadcasts direcionados de IP são utilizados no ataque de recusa de serviço de smurf, extremamente comum e popular, e também podem ser utilizados em ataques relacionados.

Um broadcast direcionado de IP é um datagrama enviado para o endereço de broadcast de uma sub-rede à qual a máquina de envio não está conectada diretamente. O broadcast direcionado é roteado através da rede como um pacote unicast até chegar na sub-rede de destino, onde é convertido em um broadcast de camada de link. Devido à natureza da arquitetura de endereçamento IP, apenas o último roteador da cadeia, o que está diretamente conectado à sub-rede de destino, pode identificar conclusivamente um broadcast direcionado. Às vezes, broadcasts direcionados são utilizados para fins legítimos, mas tal utilização não é comum fora do mercado financeiro.

Em um ataque de smurf, o invasor envia solicitações de eco de ICMP a partir de um endereço de origem falsificado para um endereço de broadcast direcionado. Isso faz com que todos os hosts na sub-rede de destino enviem respostas para a origem falsificada. Enviando um fluxo contínuo dessas solicitações, o invasor consegue criar um fluxo muito maior de respostas. Isso pode inundar completamente o host, cujo endereço é falsificado.

Se uma interface Cisco for configurada com o comando no ip directed-broadcast, os broadcasts direcionados que seriam transformados em broadcasts de camada de link na interface serão descartados. Isso significa que o comando no ip directed-broadcast deve ser configurado em todas as interfaces de todos os roteadores conectados à sub-rede de destino. Não é suficiente configurar apenas roteadores de firewall. O comando no ip directed-broadcast é o padrão no Cisco IOS Software Release 12.0 e posteriores. Em versões anteriores, o comando deve ser aplicado a toda interface LAN que não seja conhecida para encaminhar broadcasts direcionados legítimos.

Para obter uma estratégia que bloqueia ataques de smurf em alguns roteadores de firewall, que depende do desenho de rede, e informações gerais sobre o ataque de smurf, consulte ataques de recusa de serviço leavingcisco.com.

Integridade de Caminho

Muitos ataques dependem da habilidade de influenciar os caminhos que os datagramas utilizam através da rede. Se conseguirem controlar o roteamento, os invasores podem falsificar o endereço da máquina de outro usuário e fazer com que o tráfego de retorno seja enviado para eles, ou podem interceptar e ler dados destinados a outra pessoa. O roteamento também pode ser interrompido simplesmente para fins de recusa de serviço.

Roteamento de Origem de IP

O protocolo IP é compatível com opções de roteamento de origem que permitem que o emissor de um datagrama IP controle a rota que o datagrama irá tomar em direção ao seu destino final e, em geral, a rota que qualquer resposta irá tomar. Essa opções raramente são utilizadas para fins lícitos em redes reais. Algumas implementações de IP mais antigas não fazem o processamento de pacotes roteados por origem corretamente e é possível enviar datagramas com opções de roteamento de origem para causar o travamento de máquinas que estejam executando essas implementações.

Um roteador Cisco com o comando no ip source-route definido jamais encaminhará um pacote IP que transporte uma opção de roteamento de origem. Você deve utilizar esse comando, a menos que sua rede precise de roteamento de origem.

Redirecionamentos ICMP

Uma mensagem de redirecionamento de ICMP instrui um nó final a utilizar um roteador específico como seu caminho para um determinado destino. Em uma rede IP que funcione corretamente, um roteador envia redirecionamentos somente para hosts em suas próprias sub-redes locais. Um nó final nunca envia um redirecionamento e um redirecionamento nunca percorre mais do que um salto na rede. No entanto, um invasor pode violar essas regras. Alguns ataques baseiam-se nisso. Filtre redirecionamentos de ICMP de entrada nas interfaces de entrada de qualquer roteador que esteja localizado em uma borda entre domínios administrativos. Além disso, é razoável que qualquer lista de acesso aplicada ao lado de saída da interface de um roteador Cisco filtre todos os redirecionamentos de ICMP. Isso não causa impactos operacionais em uma rede configurada corretamente.

Esse filtro evita apenas ataques de redirecionamento iniciados por invasores remotos. Ainda assim é possível que os invasores provoquem problemas significativos utilizando redirecionamentos, se seus hosts estiverem diretamente conectados ao mesmo segmento de um host que esteja sendo invadido.

Filtro de Protocolo de Roteamento e Autenticação

Se você utiliza um protocolo de roteamento dinâmico que é compatível com autenticação, habilite-a. Isso impede alguns ataques maliciosos na infra-estrutura de roteamento e também pode ajudar a impedir danos causados por dispositivos invasores configurados incorretamente na rede.

Pelas mesmas razões, provedores de serviços e outros operadores de redes de grande porte geralmente são muito orientados a utilizar filtragem de rota (com o comando distribute-list in) para evitar que seus roteadores aceitem informações de roteamento claramente incorretas. Apesar de o uso excessivo de filtros na rota ser capaz de liquidar as vantagens do roteamento dinâmico, o uso moderado geralmente ajuda na prevenção de resultados não desejados. Por exemplo, se você utiliza um protocolo de roteamento dinâmico para se comunicar com uma rede de cliente de stub, você não deve aceitar nenhuma rota desse cliente, além das rotas para o espaço de endereço que você realmente tiver atribuído a ele.

Instruções detalhadas sobre como configurar autenticação de roteamento e filtragem de rota estão além do escopo deste documento. A documentação está disponível no site da Cisco e em outros lugares. Devido à complexidade envolvida, é recomendável que iniciantes busquem orientação de pessoas experientes antes de configurar essas característica em redes importantes.

Gerenciamento de Inundação

Muitos ataques de recusa de serviço dependem das inundações de pacotes inúteis. Essas inundações congestionam os links de rede, reduzem o desempenho dos hosts e também podem sobrecarregar os roteadores. Uma configuração cuidadosa do roteador pode reduzir o impacto dessas inundações.

Uma parte importante no gerenciamento de inundações é estar ciente de onde ficam os gargalos de desempenho. Se a inundação sobrecarrega uma linha T1, então, filtrar a inundação no roteador na extremidade de origem da linha é eficiente, enquanto a filtragem na extremidade de destino surte pouco ou nenhum efeito. Se o próprio roteador for o componente da rede mais sobrecarregado, então, proteções de filtragem que demandem muito do roteador poderão piorar o problema. Pense nisso na hora de avaliar a implementação das sugestões desta seção.

Inundações de Trânsito

É possível utilizar as característica de QoS do Cisco para proteger os hosts e links contra alguns tipos de inundações. Infelizmente, um tratamento geral deste tipo de gerenciamento de inundação está além do escopo deste documento e a proteção depende muito do ataque. A única recomendação simples e geralmente aplicável é utilizar o WFQ (weighted fair queueing) sempre que os recursos de CPU forem compatíveis. WFQ é o padrão para linhas seriais de baixa velocidade em versões recentes do Cisco IOS Software. Outras característica possivelmente interessantes são a taxa de acesso comprometida (CAR), a modelagem de tráfego generalizado (GTS) e o enfileiramento personalizado. Às vezes, é possível configurar essas características sob ataque ativo.

Se você realmente estiver planejando utilizar características de QoS para controlar inundações, é importante entender como essas característica funcionam e como ataques de inundação comuns funcionam. Por exemplo, o WFQ é muito mais eficaz contra inundações de ping do que contra inundações de SYN. Isso acontece porque a inundação de ping normal aparece no WFQ como um único fluxo de tráfego, enquanto que cada pacote de uma inundação de SYN geralmente aparece como um fluxo separado. Um fluxo de respostas smurf localiza-se em algum lugar entre os dois. Uma grande quantidade de informações sobre as características de QoS da Cisco está disponível no site da Cisco e informações sobre ataques comuns estão disponíveis em muitos sites mantidos por terceiros.

A Cisco fornece duas características diferentes de roteador que pretendem reduzir especificamente o impacto de ataques de inundação de SYN nos hosts. A característica Interceptação de TCP está disponível em certas versões de software de muitos roteadores com modelo número 4000 ou superior. O Conjunto de Características do Cisco IOS Firewall, que está sendo disponibilizado em um número crescente de roteadores Cisco, inclui uma proteção diferente contra inundação de SYN. A proteção contra a inundação de SYN pode ser complexa e os resultados podem variar. Isso depende da taxa de inundação, da velocidade e do tamanho da memória do roteador e dos hosts em uso. Se você configurar alguma dessas características, leia a documentação no site da Cisco. Além disso, se possível, teste sua configuração em uma inundação real.

Autoproteção do Roteador

Antes que um roteador possa proteger outras partes da rede a partir dos efeitos de fluxos, o próprio roteador deve ser protegido de sobrecarga.

Modos de Switching e Cisco Express Forwarding

O modo de switching CEF, disponível no Cisco IOS Software Releases 11.1CC, 11.1CT, 11.2GS e 12.0, substitui o cache de roteamento Cisco tradicional por uma estrutura de dados que espelha toda a tabela de roteamento do sistema. Como não é necessário criar entradas de cache quando o tráfego começa a chegar para novos destinos, o CEF se comporta de forma mais previsível do que outros modos quando é apresentado a grandes volumes de tráfego endereçados a muitos destinos.

Embora a maioria dos ataques de recusa de serviço de inundação envie todo seu tráfego para um ou alguns destinos, e não tarife o algoritmo de manutenção de cache tradicional, muitos ataques de inundação de SYN comuns utilizam endereços de origem aleatórios. O host sob ataque responde a uma fração dos pacotes de inundação de SYN, criando tráfego para um grande número de destinos. Portanto, os roteadores configurados para CEF têm melhor desempenho nas inundações de SYN (dirigidas a hosts, e não a roteadores propriamente ditos) do que os roteadores que utilizam o cache tradicional. O CEF é recomendado quando disponível.

Configuração do programador

Quando um roteador Cisco executa o switching rápido de um grande número de pacotes, é possível que o roteador demore tanto para responder a interrupções das interfaces de rede que nenhum outro trabalho seja executado. Algumas inundações de pacote muito rápidas podem gerar essa condição. Execute o comando scheduler interval, que instrui o roteador a parar de lidar com interrupções e a realizar outras atividades em intervalos regulares, para reduzir o efeito. Uma configuração típica pode incluir o comando scheduler interval 500, que indica que as tarefas de nível de processo devem ser manipuladas freqüentemente, no mínimo a cada 500 milissegundos. Esse comando raramente tem efeitos negativos e deve ser parte da configuração padrão do roteador, a menos que haja um motivo específico para deixá-lo de lado.

Muitas plataformas mais recentes da Cisco utilizam o comando scheduler allocate em vez do comando scheduler interval. O comando scheduler allocate utiliza dois parâmetros: um período em microssegundos para que o sistema seja executado com interrupções habilitadas e um período em microssegundos para que o sistema seja executado com interrupções disfarçadas. Se o seu sistema não reconhecer o comando scheduler interval 500, execute o comando scheduler allocate 3000 1000. Esses valores foram escolhidos para representar os pontos médios dos intervalos. O intervalo para o primeiro valor é de 400 a 60000, e o intervalo para o segundo valor é de 100 a 4000. Esses parâmetros podem ser ajustados.

Serviços Possivelmente Desnecessários

Como regra geral, qualquer serviço desnecessário deve ser desativado em qualquer roteador que seja acessível a partir de uma rede potencialmente hostil. Os serviços listados nesta seção às vezes são úteis, mas devem ser desativados se não forem ativamente usados.

Serviços Pequenos de TCP e UDP

Por padrão, os dispositivos Cisco do Cisco IOS versões 11.3 e anteriores oferecem esses serviços pequenos:

  • eco

  • chargen

  • descarte

Esses serviços, especialmente suas versões UDP, são pouco utilizados para fins lícitos, mas podem ser usados para iniciar recusas de serviço e outros ataques que, de outra forma, são evitados por filtragem de pacote.

Por exemplo, é possível que um invasor envie um pacote DNS, que falsifica tanto o endereço de origem como um servidor DNS, que de outro modo seria inacessível, quanto a porta de origem como a porta de serviço de DNS (porta 53). Se um pacote como esse for enviado para a porta de eco UDP do Cisco, o Cisco enviará um pacote DNS para o servidor em questão. Nenhuma verificação de lista de acesso de saída é aplicada a este pacote, pois ele é gerado localmente pelo próprio roteador.

Embora a maior parte dos abusos dos pequenos serviços possa ser evitada ou minimizada pelas listas de acesso anti-falsificação, os serviços devem estar quase sempre desabilitados em qualquer roteador que faça parte de um firewall ou que pertença a uma parte da rede crítica para a segurança. Como os serviços são usados raramente, a melhor política é geralmente desabilitá-los em todos os roteadores de qualquer descrição.

Os serviços pequenos são desabilitados por padrão no Cisco IOS Software Release 12.0 e posteriores. Em softwares anteriores, é possível executar os comandos no service tcp-small-servers e no service udp-small-servers para desabilitá-los.

Finger

Os roteadores Cisco fornecem a implementação do serviço finger, que é utilizado para descobrir quais usuários estão conectados em um dispositivo da rede. Embora estas informações normalmente não sejam importantes, às vezes elas são úteis para um invasor. O serviço finger pode ser desativado com o comando no service finger.

NTP

O Protocolo de Tempo de Rede (NTP) não é especialmente perigoso, mas qualquer serviço desnecessário pode representar uma via de penetração. Se o NTP for realmente utilizado, é importante configurar explicitamente uma origem de tempo confiável e utilizar autenticação adequada. Isso é necessário porque o corrompimento da base de tempo é uma boa forma de subverter alguns protocolos de segurança. Se o NTP não for utilizado em uma interface de roteador específica, ele pode ser desabilitado com o comando de interface ntp disable.

CDP

O Cisco Discovery Protocol (CDP) é utilizado para algumas funções de gerenciamento de redes, mas é perigoso por permitir que qualquer sistema em um segmento conectado diretamente saiba que o roteador é um dispositivo Cisco e determine o número do modelo e a versão do Cisco IOS Software em execução. Essas informações podem ser usadas para desenhar ataques contra o roteador. As informações de CDP estão acessíveis apenas para sistemas conectados diretamente. O protocolo CDP pode ser desabilitado com o comando de configuração global no cdp running. O CDP pode ser desabilitado em uma interface específica com o comando no cdp enable.

Mantenha-se Atualizado

Como acontece com todo software, o Cisco IOS Software tem bugs. Alguns desses bugs possuem implicações na segurança. Além disso, novos ataques estão sempre sendo criados e um comportamento considerado correto durante a criação de um software pode ter efeitos nocivos quando explorado deliberadamente.

Quando uma nova vulnerabilidade de segurança significativa é descoberta em um produto Cisco, a Cisco normalmente executa uma recomendação de segurança sobre ela. Consulte Resposta de Incidente de Segurança de Produto Cisco para obter informações sobre o processo através do qual esses alertas são executados. Consulte Recomendações de Segurança e Notificações sobre Produtos Cisco para obter informações sobre os alertas.

Quase todos os comportamentos inesperados de qualquer software podem gerar algum tipo de exposição de segurança, e somente bugs com implicações especialmente diretas na segurança do sistema são mencionados nessas recomendações. Sua segurança melhorará se você mantiver o software atualizado mesmo na ausência de recomendações de segurança.

Alguns problemas de segurança não são causados por bugs de software e é importante que os administradores de rede fiquem atentos a diferentes tipos de tendências de ataques. Muitos sites, listas de endereços da Internet e grupos de notícias da Usenet estão preocupados com isso.

Lista de Comandos

Esta seção deve funcionar como um lembrete das sugestões de configuração em outras seções deste documento. Os nomes dos comandos de configuração do Cisco IOS são usados nesta tabela como auxílios mnemônicos. Leia sempre a documentação de qualquer comando antes de usá-lo.

Use

Para

enable secret

Configurar uma senha para acesso privilegiado ao roteador.

service password-encryption

Fornecer um mínimo de proteção para senhas configuradas.

no service tcp-small-servers

no service udp-small-servers

Evitar o abuso dos serviços pequenos para recusa de serviço ou outros tipos de ataque.

no service finger

Evitar a divulgação de informações de usuário a possíveis invasores.

no cdp running

no cdp enable

Evitar a divulgação de informações sobre o roteador para dispositivos conectados diretamente.

ntp disable

Impedir ataques contra o serviço do NTP.

no ip directed-broadcast

Impedir o invasor de usar o roteador como um amplificador de "smurf".

transport input

Controlar quais protocolos podem ser usados por usuários remotos para se conectar interativamente aos VTYs do roteador ou para acessar suas portas de TTY.

ip access-class

Controlar os endereços IP que podem ser conectados a TTYs ou VTYs. Reservar um VTY para o acesso a partir de uma estação de trabalho administrativa.

exec-timeout

Impedir que uma sessão ociosa obstrua um VTY indefinidamente.

service tcp-keepalives-in

Detectar e excluir sessões interativas inoperantes, impedindo que elas vinculem VTYs.

logging buffered buffer-size

Salvar informações de registro em um buffer de RAM local do roteador. Com softwares mais recentes, o tamanho do buffer pode ser seguido como limite de urgência.

ip access-group list in

Descartar pacotes IP falsificados. Descartar os redirecionamentos de ICMS recebidos.

ip verify unicast rpf

Descartar pacotes IP falsificados em ambientes de roteamento simétricos com CEF somente.

no ip source-route

Evitar que as opções de roteamento de origem de IP sejam usadas para falsificar o tráfego.

access-list number action criteria log

access-list number action criteria log-input

Ativar o logon de pacotes que são compatíveis com entradas de lista de acesso específicas. Utilize log-input se ele estiver disponível na versão de seu software.

scheduler-interval

scheduler allocate

Impedir inundações rápidas, desativando o processamento importante.

ip route 0.0.0.0 0.0.0.0 null 0 244

Descartar rapidamente os pacotes com endereços de destinos inválidos.

distribute-list list in

Filtrar as informações de roteamento para evitar aceitar rotas inválidas.

snmp-server community something-inobvious ro list

snmp-server community something-inobvious rw list

Habilitar a versão 1 do SNMP, configurar a autenticação e restringir o acesso a certos endereços IP. Utilize a versão 1 do SNMP apenas se a versão 2 não estiver disponível e aguarde sniffers. Habilite o SNMP apenas quando ele for necessário em sua rede e não configure o acesso leitura-gravação, a menos que seja preciso.

snmp-server party... authentication md5 secret ...

Configurar a autenticação da versão 2 do SNMP com base em MD5 Habilite o SNMP somente se for necessário em sua rede.

ip http authentication method

Autenticar as solicitações de conexão de HTTP (se tiver habilitado o HTTP no roteador).

ip http access-class list

Ter maior controle sobre o acesso HTTP, restringindo-o a endereços de host específicos (se tiver habilitado o HTTP no roteador).

banner login

Estabelecer um banner de advertência a ser exibido a usuários que tentarem efetuar logon no roteador.

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