Apostila-Curso-CCNA-Security-m.pdf

tel 41 304 3045.7 5.7810 810 - info info dlt dltec. ec.com com.br .br - www. www.dlt dltec. ec.com com.b .brr

DlteC do Brasil®

www.dltec.com.br [email protected] | 41 3045.7810

DLTEC DO BRASIL

APOSTILA/E-BOOK DO CURSO PREPARATÓRIO PARA O CCNA SECURITY – IINS / 640-554

Apostila/E-Book do Curso Preparatório para o IINS – 640-554 DlteC do Brasil® Todos os direitos reservados©

A p o s t i l a / E - Bo o k d o C u r s o I I N S 6 4 0 - 5 5 4      

   

 

 



   

    

   



Página 1

 

 

  

tel 41 304 3045.78 5.7810 10 - info info dlt dltec.c ec.com om.br .br - www.d www.dlte ltec.c c.com om.br .br

Sobre o E-book/Apostila O conteúdo desse documento é uma adaptação da matéria online de leitura do leitura do curso. O presente material traz conteúdo teórico do curso online, porém temos que deixar claro que não é um curso e sim uma adaptação do nosso material online para e-book/apostila. e-book/apostila. Portanto recursos como exercícios, simulados, tutoria (tira dúvidas com professores) e vídeo aulas não fazem parte desse e-book, pois são exclusivos para alunos devidamente matriculados em nosso site oficial.

Para maiores informações sobre nossos treinamento visite o site:

>>> http://www.dltec.com.br <<<


   

 

 



   

    

   



Página 2

 

 

  


Sobre o E-book/Apostila O conteúdo desse documento é uma adaptação da matéria online de leitura do leitura do curso. O presente material traz conteúdo teórico do curso online, porém temos que deixar claro que não é um curso e sim uma adaptação do nosso material online para e-book/apostila. e-book/apostila. Portanto recursos como exercícios, simulados, tutoria (tira dúvidas com professores) e vídeo aulas não fazem parte desse e-book, pois são exclusivos para alunos devidamente matriculados em nosso site oficial.

Para maiores informações sobre nossos treinamento visite o site:

>>> http://www.dltec.com.br <<<


   

 

 



   

    

   



Página 2

 

 

  


Direitos Autorais Aviso Importante! Esse material é de propriedade da DlteC do Brasil Ltda e Ltda e é protegido pela lei de direitos autorais 9610/98. 9610/98 . É expressamente proibida cópia física ou em meio digital, reprodução parcial, reprografia, fotocópia ou qualquer forma de extração de informações deste sem prévia autorização da DlteC do Brasil conforme Brasil conforme legislação vigente. Seu uso pessoal e intransferível é somente para o cliente que adquiriu o referido e-book/apostila. A cópia e distribuição são expressamente proibidas e seu descumprimento implica em processo cível de danos morais e materiais previstos na legislação contra quem copia e para quem distribui, sejam cópias físicas e/ou digitais. Copyright © 2016.


   

 

 



   

    

   



Página 3

 

 

  


Indice Capítulo 1 - Introdução ................................................................................................................ 5 Capítulo 2 - Ameaças a Segurança de Redes ................................................................................ 6 Capítulo 3 - Segurança em Roteadores Cisco .............................................................................. 42 Capítulo 4 - Conceitos e Configurações do AAA .......................................................................... 80 Capítulo 5 - ACL em Roteadores Cisco ...................................................................................... 103 Capítulo 6 -Implementando Firewall em Roteadores Cisco e ASA ............................................. 139 Capítulo 7 - Segurança na Camada 2 ....................................................................................... 202 Capítulo 8 - IPS - Intrusion Prevention System .......................................................................... 235 Capítulo 9 - Sistemas Criptográficos e PKI ................................................................................ 274 Capítulo 10 - Virtual Private Network - VPN ............................................................................. 323 Capítulo 11 - Operação e Gerenciamento de Redes Seguras ..................................................... 374


   

 

 



   

    

   



Página 4

 

 

  


Capítulo 1 – Introdução ao CCNA Security e Metodologia de Estudo Sumário do Capítulo 1 Visão geral do Curso CCNA Security da DlteC_____________________ _______________________________ __________ 6


   

 

 



   

    

   



Página 5

 

 

  

1

Visão geral do Curso CCNA Security da DlteC

O curso de segurança de redes “CCNA “CCNA Security” Security” da DlteC do Brasil visa qualificar os profissionais de segurança para enfrentar os desafios relacionados à segurança de maneira eficiente, protegendo as empresas e fornecendo serviços de alta qualidade. Além disso, é preparatório para a prova de certificação Cisco 640-554, contendo todo o conteúdo previsto para exame Implementing Cisco IOS Network Security (IINSv2), IINSv2), o qual dá para o candidato, com o CCENT ou CCNA R&S válido, o título de CCNA Security. Security. Durante o curso estudaremos tanto a teoria relacionada à segurança de redes como a prática em equipamentos Cisco. O foco do treinamento é entender as principais ameaças de segurança de redes, reforçar a segurança em roteadores e switches Cisco, configurar ACL’s e Firewall Baseado em Zona (ZPF), configurar IPS e IDS, configurar o ASA Firewall, ativar VPNs site-tosite no Cisco IOS e AnyConnect com ASA, assim como gerenciar uma rede focando na segurança. Portanto, o conteúdo cobre as as principais áreas de segurança segurança que um profissional de de redes com nível Associate é exigido conhecer no mercado de trabalho. Para os alunos que pretendem fazer a prova de certificação Implementing Cisco IOS Network Security (IINS) ela tem as seguintes características: 

 







Duração máxima de 90 minutos com 30 minutos de tempo extra para não nativos na língua Inglesa. Total de 60 a 70 questões. Tipos de questão: Multiple-Choice (uma ou mútiplas escolhas), Drag-and-Drop, Simulador, Simlet e Testlet. Disponível em inglês, russo, japonês e chinês. Valor da prova $ 250.00 (dólares Americanos) Nota para passar no exame é variável com pontuação máxima igual a 1000


   

 

 



   

    

   



Página 6

 

 

  


Capítulo 2 – Ameaças a Segurança de Redes

Nesse capítulo vamos começar a estudar os conceitos de segurança, terminologia, riscos, ameaças e demais itens essenciais para que possamos compreender o porque dos recursos e medidas que serão configurados nos equipamentos a partir do próximo capítulo.

Objetivos do Capítulo Ao final desse capítulo você terá estudado e deverá compreender: Os Três Princípios Básicos de Segurança Classificação dos Dados Controles de Segurança Classificação de Ataques e Hackers Conceito de Defense in Depth O que são Vírus, Worms e Cavalos de Tróia Conceito de Buffer Overflow Principais técnicas de Spoofing Principais Ataques à Confidencialidade, Integridade e Disponibilidade das Informações Listar as melhores Práticas para manter uma rede segura 

    



Aproveite o capítulo e bons estudos!

 




   

 

 



   

    

   



Página 6

 

 

  

tel 41 430 430457 457810 810 ou 41 406 4063-78 3-7810 10 - info info dlt dltec. ec.com com.br .br - www. www.dlt dltec. ec.com com.br .br

16 Melhores Práticas ou Best-Practices para Manter uma Rede Segura Segura ________ 40

Sumário do Capítulo

17

Resumo do Capítulo ____________ ____________ 41

1 Posicionamento dos Roteadores na Rede e Topologias de Acesso à Internet ________ ________ 8

1.1

Breve Histórico ___________________ 8

2

Os Três Princípios Básicos de Segurança 9

3

Classificação dos Dados____________ ____________ 10

4

Definições e Conceitos de Segurança _ 12

4.1 Outras Classificações de Riscos de Segurança ___________________________ 12 5

Controles de Segurança ____________ ____________ 13

5.1 6

Resposta a um Incidente de Segurança 14

Classificação de Ataques e Hackers __ 15

6.1 7

Tipos de Atacantes (Hackers) _______ 16

Tipos de Ataque às Redes __________ 18

7.1 set

Anatomia de um Ataque – Hacker Hacker Mind19

8

Defense in Depth _________________ _________________ 21

9

Network Foundation Foundation Protection (NFP) 22

10 Entendendo os Vírus, Worms e Cavalos de Tróia ______________________ ____________________________ ______ 23

10.1

Anti Vírus_____________________ 25

10.2

Outros Tipos de Malwares _______ 26

11

Entendendo o Buffer Buffer Overflow ____ 28

12

Entendendo o Spoofing __________ 30

12.1

Tipos de Spoofing ______________ 31

12.2

IP Spoofing ___________________ 31

12.3

Ataque Man-in-the-middle – MITM MITM 33

13 Entendendo Ataques à Confidencialidade das Informações______ 34 14 Entendendo Ataques à Integridade das Informações _____________________ ________________________ ___ 36 15 Entendendo Ataques à Disponibilidade das Informações _____________________ _____________________ 37

15.1

Ameaças Combinadas___________ 40


   

 

 



   

    

   



Página 7

 

 

  

tel 41 3045.7810 - info dltec.com.br - www.dltec.com.br

1

Posicionamento dos Roteadores na Rede e Topologias de Acesso à Internet

Para qualquer administrador de rede na atualidade o grande desafio é “como fornecer servi ços de redes de maneira segura, protegendo informações privadas, pessoais e comerciais estratégicas”. Manter uma rede segura significa garantir a segurança dos usuários da rede e proteger os interesses comerciais. Para manter uma rede segura é necessário vigilância por parte dos profissionais de segurança, os quais devem estar sempre cientes das novas ameaças e ataques a redes, e as vulnerabilidades dos dispositivos e aplicações. Esta informação é usada para se adaptar, desenvolver e implementar técnicas de mitigação. No entanto, a segurança da rede é, em última análise, responsabilidade de todos que a utilizam. Por esta razão, é trabalho do profissional de segurança de rede garantir que todos os usuários recebam treinamento de conscientização de segurança, assim como manter a rede segura e protegida, proporcionando um ambiente mais estável e funcional para todos. Vamos utilizar muito a palavra mitigar durante o curso e na área de segurança. Veja a seguir o sentido da palavra no dicionário da língua portuguesa. Mitigar: vtd 1 Amansar, tornar brando: Mitigar a indignação, a ira, o furor. vtd 2 Adoçar, aliviar, suavizar: Mitigar a dor. Com boas palavras procurei mitigar-lhe o desgosto. vtd 3 Acalmar, atenuar, diminuir: Mitigar a saudade. "...paramos à beira daquele olho-d'água, que nos mitigara a sede" (Gastão Cruls). vpr 4 Acalmar-se, tornar-se mais brando. "...nossa dor se mitigou para cuidarmos em brincar outra vez" (Joaquim Manuel de Macedo). Antôn: exasperar, aumentar. Nos próximos capítulos você aprenderá sobre os três principais objetivos de segurança: confidencialidade, integridade e disponibilidade. 1.1 Breve Histórico Para termos uma visão da linha do tempo podemos colocar alguns acontecimentos como os principais incidentes de segurança divulgados pela mídia: 1978 - Primeiro Spam na ARPAnet 1988 – Vírus Morris infectou diversos computadores na Internet 1999 – Vírus Melissa propagado por e-mail 2000 – Mafiaboy, Love Bug Worm, L0phtCrack 2001 – Ataque Code Red invadiu mais de 350,000 hosts no mundo todo 2004 - Botnet ataca sistemas militares dos Estados Unidos 2007 - Storm botnet – ataque a instituição de cartão de crédito 2008 – Fraude na Société Générale Stock 2011 - Vírus Stuxnet atacou usinas nucleares no Irã. Ataques aos sites do governo Brasileiro realizados pelo grupo de hackers denominado LulzSecBrazil. Atualmente estamos passando pela fase das redes sociais, onde Presidentes e CEO’s das empresas utilizam Facebook, ferramentas de mensagem instantânea e outras ferramentas para comunicação, networking e negócios. Faz parte da missão do profissional de redes implementar uma infra-estrutura física e lógica segura, que comporte as necessidades da empresa e limitem ao máximo os riscos de segurança.


   

 

 



   

    

   



Página 8

 

 

  

tel 41 430457810 ou 41 4063-7810 - info dltec.com.br - www.dltec.com.br

Existem atualmente diversas organizações que regulamentam e trocam informações de segurança entre profissionais da área, onde as três principais são:   

2

SysAdmin, Audit, Network, Security (SANS) Institute Computer Emergency Response Team (CERT) International Information Systems Security Certification Consortium

Os Três Princípios Básicos de Segurança

Os três principais objetivos da segurança de rede são:   

Confidencialidade Integridade Disponibilidade

Entende-se por Confidencialidade a proteção da informação compartilhada contra acessos não autorizados. Podemos garantir a confidencialidade pelo controle de acesso (senhas) e controle das operações individuais de cada usuário (log). Abaixo seguem mais alguns exemplos: 





Uso de mecanismos de segurança de rede (por exemplo, firewalls e listas de controle de acesso) para impedir o acesso não autorizado aos recursos da rede. Exigir credenciais adequadas (por exemplo, nomes de usuário e senhas) para acesso a recursos específicos da rede. Criptografar o tráfego para que um atacante não consiga decifrar todo o tráfego que ele capturar a partir da rede.

A Integridade é a garantia da veracidade da informação, que não pode ser corrompida, seja por alterações acidentais ou não autorizadas. Segue abaixo exemplos de violações de integridade:   

Modificar a aparência de um site corporativo Interceptar e alterar uma transação de comércio eletrônico Modificar os registros financeiros que são armazenados eletronicamente

A Disponibilidade é a prevenção de interrupções na operação de todo o sistema, seja ele hardware e/ou software. Por exemplo, uma quebra do sistema não deve impedir o acesso aos dados. Abaixo seguem mais alguns exemplos de como um invasor pode comprometer a disponibilidade de uma rede: 



Ele poderia enviar indevidamente dados formatados para um dispositivo de rede, resultando em um erro de exceção que o dispositivo não saberia tratar, interrompendo o serviço. Ele pode inundar um sistema de rede com uma quantidade excessiva de tráfego ou requisições. Esta sobrecarga iria consumir recursos de processamento do sistema e impedir que o sistema responda às muitas solicitações legítimas, fazendo com que o serviço seja negado aos usuários que realmente necessitam desse serviço. Este tipo de ataque é chamado de negação de serviço (DoS – Denial of service).


   

 

 



   

    

   



Página 9

 

 

  


Conheça a si próprio, conheça seu inimigo. Mil batalhas, mil vitórias. Sun Tzu

3

Classificação dos Dados

O processo de Classificação da Informação consiste em identificar quais são os níveis de proteção que as informações demandam e estabelecer classes e formas de identificá-las, além de determinar os controles de proteção necessários a cada uma delas. A fim de criar uma política de segurança adequada, você precisa primeiro classificar seus dados, o que pode até ser exigido por lei. Os benefícios da classificação de dados incluem o seguinte:   





Mostra o compromisso por parte da empresa para proteger a rede e seus recursos. Identifica os dados que são mais sensíveis da empresa. Facilita a criação de medidas de segurança que devem ser utilizadas para proteger os dados. Fornece uma melhor relação custo-benefício, possibilitando que a empresa foque em dados que tem a maior importância e, portanto, precisam de mais proteção. Normalmente as informações são classificadas mediante sua necessidade de sigilo, porém uma organização também pode elaborar procedimentos para classificá-la perante suas necessidades de integridade e disponibilidade. Cada nível de classificação é criado visando um tipo de informação e costuma-se utilizar um número reduzido de classificações (de 3 a 5).

Podemos ter basicamente um tipo de classificação utilizada por órgãos governamentais ou em empresas privadas, conforme exemplo abaixo: Governo Brasileiro Ultra-Secreto Secreto Confidencial Reservado

Empresas Privadas Interna Pública Restrita Privada


   

 

 



   

    

   



Página 10

 

 

  


Os governos e instituições militares utilizam normalmente a classificação abaixo:  







Dados não classificados - que tem poucos ou nenhum requisito de privacidade Sensível mas não classificados (SBU) - os dados que poderiam causar constrangimento, mas não constituem uma ameaça à segurança se revelado Dados confidenciais - tem uma probabilidade razoável de causar danos se forem divulgados para uma pessoa não autorizada Dados secretos - tem uma razoável probabilidade de causar sérios danos se divulgados para pessoas não autorizadas Dados ultra-secretos - tem uma probabilidade razoável de causar dano excepcionalmente grave se divulgados para pessoas não autorizadas

O governo dos EUA classifica informações confidenciais em três níveis:   

Confidencial Secreto Top-Secret (ultra secreto)

Além de classificar os dados é necessário determinar quais são as características do dado, por exemplo: 







Valor: é o critério mais importante e indica como os dados são importantes para a organização. Associação Pessoal: dados associados com uma pessoa, como um arquivo de empregado em Recursos Humanos (RH). Idade: o período de tempo que o valor dos dados diminui à medida que os eventos ocorrem, tais como mudanças nas tecnologias sendo usadas. Vida Útil: por quanto tempo a informação é útil?

Depois de decidir sobre um esquema de classificação, será necessário fazer algumas tarefas para finalizar o modelo de classificação de dados. Geralmente você precisa identificar quem detém os dados, como classificá-lo e a melhor forma de protegê-lo. Aqui segue uma lista para ajudar a determinar como proceder: 1. 2. 3. 4. 5. 6.

Identificar o custodiante dos dados (owner ou dono). Determinar como os dados são classificados e rotulados. Identificar o proprietário dos dados e classificar adequadamente. Identificar eventuais exceções. Identificar os controles específicos para ser usado com cada classificação, se necessário. Definir as regras para a desclassificação de dados e eliminação dos mesmos, se necessário. 7. Criar um programa de conscientização de segurança que aborda a classificação da informação.


   

 

 



   

    

   



Página 11

 

 

  


4 Definições e Conceitos de Segurança Em geral, analisando e simplificando o tópico segurança de rede, podemos elencar três fatores que fazem parte do assunto.   

Vulnerabilidade (Vulnerability) Ameaças (Threat) Ataques (Attack)

Podemos dizer que Vulnerabilidade são os protocolos e “furos” de segurança em sistemas e equipamentos que serão explorados pelos atacantes, por exemplo, vulnerabilidades do sistema operacional (windows, linux, etc). Isso inclui roteadores, switches, desktops, servidores e até mesmo dispositivos de segurança. Além disso, as vulnerabilidades podem ser geradas pela própria tecnologia (furos de segurança nos sistemas e aplicativos), por falhas na configuração dos sistemas ou por problemas na política de segurança da corporação. As Ameaças são os perigos em potencial contra a segurança da informação, por exemplo, indivíduos que tem interesse em realizar ataques e sempre estão procurando novas proezas e vulnerabilidades para o acesso não autorizado a redes e sistemas, ou então desejam informações privilegiadas para realizar delitos. Essas ameaças podem ser tanto internas como externas à rede, as quais serão mais bem estudadas posteriormente. O Ataque é a realização do que foi analisado como vulnerabilidade e colocado em prática por um atacante. Normalmente, os dispositivos de rede sob ataque são as extremidades, como servidores e desktops. Outros termos que podemos encontrar em estudos sobre o assunto segurança são: Assets: são os ativos, ou seja, quaisquer elementos que tenham valor para a empresa ou organização, por isso mesmo eles precisam ser classificados, pois nem todo asset tem o mesmo valor para diferentes organizações. Na prática é o que queremos proteger. Countermeasure: uma ação ou contramedida para mitigar um risco potencial, são as medidas técnicas, administrativas e controles físicos implementados para mitigar riscos. Information security risk: o risco à segurança da informação é a medida do impacto de vulnerabilidades e ameaças aos assets que a corporação deseja pr oteger. 





4.1 Outras Classificações de Riscos de Segurança Além disso, podemos classificar os riscos de segurança entre físico, lógico (das redes, por exemplo) e humano (engenharia social). Conforme mencionado anteriormente, quando se fala de segurança vem à mente um Firewall, ou seja, um dispositivo de redes, mas e o restante? E se o atacante conseguir acesso ao seu Datacenter ou ao CPD da empresa? Com certeza ele está atrás do Firewall e terá uma gama de ações possíveis para realizar de dentro da rede, normalmente muito mais vulnerável quando atacada internamente. Portanto, temos que abrir os horizontes e pensar que é importante sim a segurança de redes com Firewall, IDS e IPS, porém não podemos nos esquecer da Infraestrutura física e das pessoas, pois o fator humano conta muito para uma rede segura.


   

 

 



   

    

   



Página 12

 

 

  


As ameaças à infra-estrutura física podem ser resumidas em: 

 



Ameaças ao hardware – danos físicos à infra-estrutura e equipamentos que fazem parte da rede. Ameaças ao ambiente – temperatura, umidade, sujeira, e outros motivos ambientais. Ameaças elétricas – sobretensão, picos de energia, descargas atmosféricas (raios), sistemas de proteção elétrica mal dimensionada, etc. Ameaças à manutenção – problemas de nomenclatura, ocasionando desligamento de equipamentos errados, janelas de manutenção mal dimensionadas, falta de manutenção preventiva, etc.

Sobre o fator humano temos que falar da Engenharia Social, que são meios de levar membros de uma corporação ou até mesmo uma pessoa física a fornecerem informações importantes, como o local de arquivos ou senhas, facilitando o processo de invasão. Ela pode incluir sensibilizações ao ego de um funcionário ou pode ser uma pessoa disfarçada, ou com documento falsificado, que leva uma pessoa a fornecer informações confidenciais. Atualmente se fala bastante do risco das redes sociais, pois podem ser fonte de pesquisa para a Engenharia Social, permitindo que o atacante mal intencionado colete informações das pessoas da corporação para iniciar uma abordagem mais elaborada. O risco da engenharia social se estende para a vida pessoal, não somente para o corporativo, assim como os ataques buscando informações para crimes virtuais, como roubo de senha para acesso indevido à conta bancária via Internet, clonagem de cartões de crédito e compras indevidas com os dados pessoais e de cartão de crédito de outras pessoas. 5 Controles de Segurança Os controles de segurança são as medidas aplicadas para controlar e reduzir riscos para seus dados. Os controles de segurança são geralmente agrupados em três categorias: administrativas, técnicas e físico. Controles administrativos são tipicamente associados com as políticas e procedimentos de segurança. Seguem alguns exemplos abaixo:        

Políticas e procedimentos de segurança Conscientização dos usuários Auditorias Alterar os procedimentos de controle Checar antecedentes dos funcionários Práticas de contratação bem estabelecidas Job rotation (rotação de cargos) Separação de funções entre os funcionários bem estabelecidas

Os controles administrativos constituem a camada de gerenciamento da estrutura de controle, formando a base para montar uma estrutura de segurança. Já os controles técnicos são geralmente baseados em ferramentas de hardware e software. Abaixo seguem alguns exemplos:       

Firewalls Sistemas de detecção e prevenção de intrusão (IPS e IDS) Listas de controle de Acesso (ACL) Rede virtual privada (VPN) Sistemas de gerenciamento de identidade, como TACACS+ e RADIUS Sistemas de controle de admissão (CAC) Tokens e smartcards


   

 

 



   

    

   



Página 13

 

 

  


Tal como acontece com os controles administrativos, todos os controles técnicos do mundo são inúteis se eles são a única linha de defesa da empresa, pois as três categorias são interdependentes. Os controles físicos são normalmente de natureza mecânica. Os exemplos seguintes são de controles físicos:        

Fechaduras e travas Fontes de alimentação redundantes Geradores a Diesel Equipe de seguranças Sensores de movimento Sistemas de Alarme Cofres Sistemas de supressão de fogo

Os controles são classificados também como preventivos, impeditivos ou visam à detecção de um ataque, em inglês preventative, deterrent ou detective respectivamente. Deve ser lembrado que, embora haja a necessidade de controles físicos, a segurança humana deve vir acima de tudo, implantando portas e fechaduras que garantam a saída no caso de uma emergência, mas previnam a entrada de pessoas não autorizadas. Mesmo com todos os controles implementados a empresa pode ainda sofrer ataques e deve ter uma metodologia para responder a esse problema ou incidente, no próximo capítulo veremos melhor esse assunto. 5.1 Resposta a um Incidente de Segurança Responder a um incidente de segurança é fundamental e parte da rotina operacional da área de segurança nas empresas. E o modo como você responde a um incidente é ainda mais importante. Manter uma linha estabelecida e seguir um conjunto específico de procedimentos levará ao sucesso nessa tarefa. Há tipicamente seis fases para resposta a incidentes listadas nas boas práticas, as quais você pode memorizar usando a palavra PICERL mnemônico, como ilustrado aqui:      

P – Preparação I – Identificação C – Contenção E – Erradicação R – Restauração L - Lições aprendidas

Além disso, a resposta a um incidente de segurança tem seus aspectos legais, pois a quebra de sigilo e roubo de informações constituem crimes previstos em lei, porém as penas e interpretações podem variar de país para país. Uma dica importante é que se aconselha a não reinicializar os sistemas até que a investigação seja finalizada, pois pistas podem ser apagadas em alguns casos de ataque, por exemplo, se você não mantém o envio das mensagens de log (registros) dos roteadores em um servidor externo de syslog, ao reinicializá-lo essas mensagens serão apagadas, pois o buffer do roteador utiliza a memória RAM para armazenamento por padrão.


   

 

 



   

    

   



Página 14

 

 

  


6 Classificação de Ataques e Hackers Os ataques às redes, em linhas gerais, podem ser realizados das seguintes maneiras: 







Estruturado: por um indivíduo ou grupo estruturado e preparado técnica e tecnologicamente para realizar o ataque. É um ataque profissional e com um objetivo claro. Não Estruturado: normalmente iniciantes que utilizam ferramentas disponibilizadas para hackers, com a finalidade de testar os conhecimentos do atacante ou até mesmo com fins ilícitos. Externos: realizado por pessoas de fora da organização, normalmente via Internet, e pode ser realizado de maneira estruturada ou não estruturada. A gravidade do ataque depende da motivação e grau de experiência do atacante. Internos: realizado por pessoas que têm acesso à rede, ou seja, por um funcionário ou terceiro autorizado da corporação. São ataques normalmente mais difíceis de detectar e as redes precisam ter uma estrutura razoável para minimizar esse tipo de ataque.

Especificamente, de acordo com o Computer Security Institute (CSI), em San Francisco Califórnia, cerca de 60% a 80% dos incidentes de segurança são originados de dentro da rede, ou seja, por atacantes internos da empresa. Portanto, embora o isolamento de rede seja possível hoje em ambientes de rede, ele não assegura 100% às informações, pois mesmo que isolemos uma rede do mundo externo um atacante interno pode representar uma ameaça à segurança. O maior exemplo do que foi citado anteriormente são os filmes, onde muitas vezes são copiados e distribuídos mesmo antes de seu lançamento oficial nos cinemas. Os potenciais adversários dos analistas e recursos de segurança de uma empresa podem ser: Nações ou estados Terroristas Criminosos Hackers Competidores de mercado Empregados descontentes com a empresa Agências governamentais       


   

 

 



   

    

   



Página 15

 

 

  


À medida que os tipos de ameaças, ataques e meios de explorar vulnerabilidades em redes evoluíram, vários termos foram criados para descrever os “atacantes”, os quais nem sempre são “do mal”. Hacker geralmente é o termo geral historicamente utilizado para descrever um especialista em programação de computador. Mais recentemente, esse termo passou a ser utilizado de modo negativo para descrever um indivíduo que tenta obter acesso não autorizado a recursos de rede com má intenção, porém existe uma gama de tipos de hackers na atualidade. A seguir vamos estudar alguns termos e classificações para os tipos de atacantes. 6.1 Tipos de Atacantes (Hackers) Veja abaixo os tipos de Hackers e Atacantes com uma nomenclatura tradicional utilizada na área de segurança: White hat – um “atacante do bem”, normalmente procura falhas nos sistemas e protocolos para informar e corrigir o risco de segurança. Traduzindo para o português chama-se hacker “chapéu branco”. 

















Gray hat – Tem as habilidades e intenções de um hacker de chapéu branco na maioria dos casos, mas por vezes utiliza seu conhecimento para propósitos menos nobres. Um hacker de chapéu cinza pode ser descrito como um hacker de chapéu branco que às vezes veste um chapéu preto para cumprir sua própria agenda. Hackers de chapéu cinza tipicamente se enquadram em outro tipo de ética, que diz ser aceitável penetrar em sistemas desde que o hacker não cometa roubo, vandalismo ou infrinja a confidencialidade. Alguns argumentam, no entanto, que o ato de penetrar em um sistema por si só já é antiético (ética hacker). Black hat – esse é o “atacante do mal”, procura invadir sistemas e redes para fins pessoais (satisfação do seu ego) ou financeiros. Cracker é um exemplo de black hat. Traduzindo para o português chama-se hacker “chapéu preto”. Cracker – termo mais preciso para descrever alguém que tenta obter acesso não autorizado a recursos de rede com má intenção. Phreaker – o precursor do black hat, porém utilizando normalmente telefones públicos para realizar chamadas gratuitas. Spammer – esse conhecemos bem, pois recebemos uma pilha de e-mails indesejados diariamente dos spammers, os quais enviam os famosos “spams”, as propagandas, vírus e outros “lixos” eletrônicos por e-mail. Phisher – utiliza email ou outros meios para levar outras pessoas a fornecer informações confidenciais, como números de cartão de crédito ou senhas. Um phisher se mascara como uma parte confiável que teria uma necessidade legítima pelas informações confidenciais. Script Kiddies – subcategoria de crackers que não têm um alvo certo, vão tentando invadir tudo que vêm pela frente. Utilizam ferramentas encontradas na Internet, nem programar sabem, mas possuem um conhecimento digital bem acima dos usuários comuns. Hacktivistas – são hackers não mais preocupados em quebrar sistemas pela diversão, mas focados em questões políticas e sociais. São pessoas que dominam bits e bytes, assim como Mahatma Gandhi dominava as palavras, porém com um cunho político.


   

 

 



   

    

   



Página 16

 

 

  

tel 41 3045.7810 - info dltec.com.br - www.dltec.com.br 





Computer Security Hacker – um hacker de que tem conhecimento sobre as técnicas e aspectos da informática e sistemas de segurança de rede. Por exemplo, este pessoa pode tentar atacar um sistema protegido por um IPS fragmentando o tráfego malicioso de uma maneira que não são detectados pelo IPS. Hacker Acadêmico (Academic hacker) – é tipicamente um trabalhador ou um estudante em uma instituição de ensino superior que utiliza os recursos de computação da instituição para escrever programas “inteligentes”. Normalmente esses hackers usam seus nomes reais (ao contrário dos pseudônimos frequentemente utilizado dos Computer security hacker), e tendem a se concentrar em sistemas operacionais baseados em software livre (por exemplo, Linux). Hacker por Hobby – tendem a focar em computação doméstica. Eles podem modificar hardware ou software existentes para uso dos mesmos sem licença legal. Por exemplo, gerar um código que "destrava" o iPhone da Apple pode ser obra de um hacker por hobby.

Olhando essa quantidade de tipos de hackers é importante tentarmos responder algumas questões: “O que os motiva?” , “Como eles podem chegar a ter sucesso em seus ataques?”. Existem diversos tipos de formas de se fazer ataques, mas vamos agora descrevê-los de uma maneira mais abrangente e classificá-los conforme a lista abaixo. 









Passivo (passive): Um ataque passivo é difícil de detectar, porque o atacante não está ativamente enviando o tráfego (malicioso ou não). Um exemplo de ataque passivo é um atacante capturando pacotes da rede e tentando decifrá-los (se o tráfego estava criptografado originalmente), normalmente utilizando um sniffer. Ativo (active): Um ataque ativo é mais fácil de detectar, pois o atacante está ativamente enviando tráfego que pode ser detectado. Um invasor poderia lançar um ataque ativo na tentativa de acesso a informações confidenciais ou para modificar dados em um sistema. Esse é um ataque mais tradicional. Close-in ou Proximidade: Um ataque close-in, como o nome sugere, ocorre quando o atacante está em estreita proximidade física com o sistema de destino. Por exemplo, um invasor pode facilmente evitar a proteção de senha de console em alguns roteadores, switches e servidores se ele ganha acesso físico nesses dispositivos. Insider ou Interno: um ataque interno ocorre quando usuários legítimos da rede utilizam suas credenciais e conhecimento da rede para realizar o ataque. Distribuição (distribution): são ataques onde "back doors" são introduzidos intencionalmente ao hardware ou sistemas de software no momento da fabricação para facilitar ataques posteriores. Após esses sistemas terem sido vendidos a vários clientes o invasor pode usar seu conhecimento do back door (brecha de segurança traduzida literalmente por “porta dos fundos”), por exemplo, tendo acesso a dados protegidos, manipulando dados ou tornando o sistema indisponível para os usuários finais.

Por isso, lembre que segurança vai muito além de implementar um Firewall, o dispositivo mais conhecido pelo público em geral quando se fala do assunto, pois ela vai desde a parte física (aspectos de acessibilidade, energia...), disponibilidade da informação (backups, links reservas...), regras de uso ou política de segurança até os equipamentos e aplicativos de segurança de informação e redes que tradicionalmente conhecemos.


   

 

 



   

    

   



Página 17

 

 

  


7 Tipos de Ataque às Redes Podemos dividir esses ataques em três classes: reconhecimento, acesso e negação de serviços . Ataques de Reconhecimento servem para a detecção não autorizada e o mapeamento de sistemas, serviços ou vulnerabilidade. Ele também é conhecido como footprint ou coleta de informações e, é a fase inicial de uma invasão, onde o invasor está reconhecendo a rede e suas vulnerabilidades. O invasor tenta com esses ataques descobrir uma forma mais fácil de invadir a rede, sejam equipamentos ou sistemas. Exemplos de ataques de reconhecimento: 







Consultas de informações de Internet: utilizando ferramentas como whois e nslookup para descobrir endereços de IP de entrada para a rede. Varreduras de ping: com os endereços IP’s os atacantes podem enviar pings para determinar outros IP’s de outras máquinas como opções de acesso para invasão. Verificações de porta (port scan): o port scan tem o objetivo de verificar quais portas TCP e UDP estão abertas na rede, ou seja, que o firewall permite acesso para identificação das vulnerabilidades a serem exploradas (exploits). Sniffers de pacote: permitem que o atacante analise a comunicação em busca de troca de pacotes TCP e UDP não seguras para capturar usuários, senhas e outras informações úteis ao ataque, utilizando um analisador de protocolos. Uma rede privativa ou um método de criptografia pode ajudar a evitar

Após o reconhecimento o Ataque de Acesso é a tentativa de entrada ou acesso utilizando normalmente um script ou uma ferramenta que explore uma fraqueza conhecida do sistema, aplicativo ou dispositivo que está sendo atacado para descobrir um usuário e senha válidos, por exemplo. Exemplo de ataque de acesso: 









Ataque de senhas: utilização de scripts e programas para descobrir usuários e senhas para acesso a um sistema ou dispositivo. Normalmente são tentativas repetidas de login em um recurso compartilhado, como um servidor ou roteador, para identificar uma conta de usuário, senha ou ambos, também conhecido como ataque de força bruta. Um exemplo é a ferramenta L0phtCrack. Exploração de confiança (Trust Exploitation): o objetivo desse ataque é invadir um host confiável, utilizando-o para preparar ataques em outros hosts de uma rede. Redirecionamento de Porta (Port Redirection): Um ataque de redirecionamento de porta é outro tipo de ataque baseado na exploração de confiança. O atacante usa um host comprometido para o acesso através de um firewall que seriam normalmente bloqueados para um micro não confiável. Man-in-the-Middle ou Ataque de Interceptação: O ataque “man in the middle” (literalmente “ataque do homem no meio” ou “ataques do interceptor”), às vezes chamado MITM, é um cenário de ataque no qual um invasor “ouve” uma comunicação (utilizando um sniffer) entre dois interlocutores e falsifica as trocas a fim de fazer se passar por uma das partes. Spoofing de IP (Falsificação): A principal característica do Spoofing é convencer alguém de que ele é algo que ele não é, conseguindo assim, autenticação para acessar alguma parte restrita à qual ele não tem permissão, através da falsificação do seu endereço de origem.

A Negação de Serviços ou ataques DoS são os mais temidos, é uma tentativa em tornar os recursos de um sistema indisponíveis para seus utilizadores ou clientes. Alvos típicos são servidores web, e o ataque tenta tornar as páginas hospedadas indisponíveis na WWW. Não se trata de uma invasão do sistema, mas sim da sua invalidação por sobrecarga. Exemplos de ataques de DoS:


   

 

 



   

    

   



Página 18

 

 

  








DoS Distrubuído (DDoS): Em um ataque distribuído de negação de serviço (também conhecido como DDoS, um acrônimo em inglês para Distributed Denial of Service), um computador mestre (denominado "Master") pode ter sob seu comando até milhares de computadores ("Zombies" - zumbis), sendo que as tarefas de ataque de negação de serviço serão distribuídas a um "exército" de máquinas escravizadas. TCP SYN Flood: o atacante envia uma sequência de requisições SYN para um sistemaalvo visando uma sobrecarga direta na camada de transporte e indireta na camada de aplicação do modelo OSI. Ataque de Smurf : o invasor envia uma rápida sequência de solicitações de Ping (um teste para verificar se um servidor da Internet está acessível) para um endereço de broadcast. Usando spoofing (fazer passar por outro computador da rede para conseguir acesso a um sistema), o invasor faz com que o servidor de broadcast encaminhe as respostas não para o seu endereço, mas para o da vítima. Assim, o computador alvo é inundado pelo Ping.

Portanto, com um passo a passo bem estruturado e planejado, assim como lançando mão do uso de uma ou um conjunto de ferramentas conforme as citadas acima um hacker traça seu plano e pode executar ataques tanto a redes domésticas ou corporativas. Vamos aprender durante o curso como tratar e proteger a rede contra diversas ameaças. 7.1 Anatomia de um Ataque – Hacker Mind-set Vamos analisar um pouco sobre como um hacker pode planejar e executar um ataque, chamado “mind-set” do hacker, que em português poderíamos traduzir para “forma de pensar”. Veja um exemplo abaixo baseado nas principais publicações sobre o assunto: 







Passo 1 – Aprender mais sobre o sistema com ataques de reconhecimento (reconnaissance). Nesta etapa, também conhecido como "footprinting" (pegadas), o hacker descobre tudo o que puder sobre o sistema. Por exemplo, ele pode aprender os nomes de domínio da empresa-alvo e a faixa de endereços IP utilizada. Ele pode realizar uma varredura de portas (port-scan) para ver quais portas estão abertas. Passo 2 - Identificar as aplicações no sistema, assim como o sistema operacional dos servidores, também chamado de processo de enumeração. Os hackers podem utilizar várias ferramentas para tentar se conectar a um sistema e dependendo do prompt que eles recebem (por exemplo, um prompt de login do FTP ou uma página da Web padrão) é possível ter uma idéia do sistema operacional utilizado. Além disso, o port-scan, já mencionado, pode ajudar a identificar as aplicações/sistemas que estão rodando nos servidores. Passo 3 – Obter acesso ao sistema (realizar a invasão). A engenharia social é uma das maneiras mais populares para obter usuários/senhas de login a um sistema. Por exemplo, os registros públicos de DNS fornecem informações de contato da empresa, normalmente do administrado do domínio. Um hacker pode ser capaz de usar essas informações para convencer o administrador para revelar informações sobre o sistema, por exemplo, fingindo ser um prestador de serviços ou um funcionário público autorizado a receber essas informações genéricas sobre o sistema operacional e aplicações utilizadas. Esta abordagem é chamada de pretexto ou “pretexting”, ou seja, fingir que é outra pessoa para obter informações e tirar vantagem delas. Outra forma de invasão é utilizar as falhas do sistema ou exploits, problemas de configuração e outros tipos de brechas para penetrar no sistema. Passo 4 - Fazer o login com as credenciais do usuário obtidas e escalar privilégios de acesso (entrar como usuário normal de rede e tentar subir o nível para root). Por exemplo, um hacker poderia introduzir um cavalo de Tróia (um pedaço de software que parece ser uma aplicação legítima, mas tem uma função de ataque invisível na máquina de destino) para subir seus privilégios na máquina ou sistema.


   

 

 



   

    

   



Página 19

 

 

  






Passo 5 - Reunir nomes de usuário e senhas adicionais. Com os privilégios apropriados, os hackers podem executar utilitários para criar relatórios de nomes de usuário e/ou senhas, o que é muito comum na Internet em sites pagos, onde sofrem invasão e tem usuários e senhas divulgados em listas de sites de crackers. Passo 6 - Configurar uma "porta dos fundos” ou “backdoor”. Acessando um sistema através de um nome de usuário/senha pode não ser como um hacker quer repetidamente ter acesso ao sistema. As senhas podem expirar e logins podem ser registrados para auditorias futuras, deixando “rastros”. Portanto, os hackers preferem instalar uma backdoor, que é um método de ganhar acesso a um sistema burlando medidas de segurança normais. Passo 7 - Utilizar o sistema. Depois que o hacker ganha o controle do sistema ele pode reunir informações protegidas a partir desse acesso. Alternativamente, ele pode manipular os dados do sistema ou utilizar esse dispositivo/sistema invadido para lançar ataques contra outros sistemas, com os quais ele pode ter uma relação de confiança estabelecida.

Veja a figura a seguir um modelo do passo a passo da anatomia de um ataque.


   

 

 



   

    

   



Página 20

 

 

  


Conforme mencionado, o exemplo acima é hipotético e genérico. Agora vamos analisar os tipos de ataques que podem ser realizados para invadir mais especificamente uma rede. 8 Defense in Depth “Defense in Depth” ou “Defesa em Profundidade” é uma filosofia de design que realiza uma abordagem de segurança em camadas. De acordo com este princípio, não se deve depender de apenas um mecanismo de segurança não importando quão forte ele pareça ser. Ao invés disso, recomenda-se que sejam utilizados múltiplos mecanismos de segurança e que estes estejam configurados no nível mais alto possível de segurança e redundância. A estratégia principal é fazer com que o ataque seja significativamente arriscado e caro ao atacante

Um exemplo prático ocorre quando se utiliza dois roteadores, um externo conectado diretamente a Internet e um interno conectado diretamente a rede privada e entre eles um bastion host. Neste caso, esta estratégia poderia ser empregada utilizando redundância em ambos roteadores, aplicando-se ao roteador interno também as regras de filtragem adotadas no roteador externo. Desta forma, caso um pacote que deveria ser barrado no primeiro roteador chegasse ao segundo, isso indicaria que o primeiro roteador foi atacado com sucesso e, consequentemente, um alarme poderia ser acionado a fim de que medidas sejam tomadas para solucionar o problema. Esta estratégia permite que o sistema tolere mais falhas na segurança. Veja na tabela como pode ser realizada a proteção com duas camadas de segurança para as classes de ataques de hackers discutidas anteriormente.


   

 

 



   

    

   



Página 21

 

 

  


A estratégia de defesa em profundidade recomenda vários princípios, vamos resumir os pontos chave abaixo: Defender em vários lugares Defender os limites (fronteiras) Defender o ambiente de computação Construir defesas em camadas Utilizar componentes robustos Utilizar gerenciamento de chaves seguro e robusto Implantar IDS e/ou IPS na rede       

9 Network Foundation Protection (NFP) Outra maneira de proteger a rede é utilizando o conceito do NFP, ou seja, dividindo a rede em planos (planes) ou camadas:   

Control plane: protocolos de roteamento e controle. Data plane: encaminhamento dos quadros e pacotes. Management plane: utilizado em sessões de gerenciamento.

A Cisco possui uma caixa de ferramentas para NFP (Toolkit) que visa a proteção em cada um dos planos da rede conforme abaixo: 





Control Plane: Control Plane Policing (CoPP), Control Plane Protection (CPPr), Routing protocol authentication (autenricação para o RIP, EIGRP e OSPF) e AutoSecure. Management Plane: Authentication, Authorization, and Accounting (AAA), Network Time protocol (NTP), Syslog, Simple Network Management Protocol (SNMP), Secure Shell (SSH), Transport Layer Security (TLS) e CLI views. Data Plane: Access control lists (ACLs), Layer 2 controls (controles de camada-2), Zone-Based Firewall e IOS Intrusion Prevention System (IPS)

Muitas dessas proteções serão estudadas durante os próximos capítulos.


   

 

 



   

    

   



Página 22

 

 

  


10 Entendendo os Vírus, Worms e Cavalos de Tróia Keylogging, Virus, Trojan, Malware e Spyware são várias palavras para denominar uma série de “vilões” dos usuários, aqueles programas mal-intencionados cujo uso vai desde roubo de senhas e informações até o mais puro caos e destruição. Mesmo assim, muitos não sabem a diferença entre uma coisa e outra, chamando tudo de “vírus”, o que pode trazer algumas confusões na hora de se defender. Os MALWARES são programas especificamente desenvolvidos para executar ações danosas em um computador. Exemplos: worm, bots, virus, trojans... Um vírus é uma sequência de código inserida em outro código executável, o qual tem as seguintes características: 



Replicação: os vírus se replicam para diversos arquivos da máquina a fim de garantir a sua sobrevivência dentro daquele sistema. É ativado por uma ação externa: por exemplo, um arquivo anexo de e-mail que está localizado na caixa de entrada do programa gerenciador de e-mails. Se este arquivo não for executado não há como a máquina ser infectada por esse vírus.

A infecção ocorre no momento que se executa o programa com código malicioso. A partir daí esse se espalha, ou seja, ele se multiplica danificando diversos arquivos e sistemas da máquina onde ele se encontra.

Pode-se citar também outro tipo de programa malicioso que é intitulado como trojan. Sua principal função é inserir um trecho de código em um programa aparentemente inofensivo, mas na verdade a intenção é colocar um hospedeiro na máquina invadida, deixando assim o invasor com o controle total da máquina. Os trojans são um tipo de ferramenta que se popularizaram na Internet a partir de 1997, quando foi lançado o famoso Back Orifice (uma brincadeira com o nome Back Office da Microsoft). Um cavalo de tróia, ou trojan, é um programa que, quando instalado no sistema de alguém, geralmente abre uma porta TCP ou UDP para receber conexões externas, fornecendo normalmente o shell (prompt de comandos) daquele sistema para um possível invasor. Isso não é regra geral, já que alguns backdoors podem fazer também conexão reversa e outros


   

 

 



   

    

   



Página 23

 

 

  


tipos de técnicas. Um cavalo de tróia nada mais é do que um backdoor disfarçado de um programa comum, como um jogo. O termo “cavalo de tróia” faz analogia ao cavalo de madeira que os gregos deram aos troianos, no famoso episódio da guerra de Tróia.

Um worm, assim como um vírus, cria cópias de si mesmo de um computador para outro, mas faz isso automaticamente. Primeiro, ele controla recursos no computador que permitem o transporte de arquivos ou informações. Depois que o worm contamina o sistema, ele se desloca sozinho. O grande perigo dos worms é a sua capacidade de se replicar em grande volume.

Por exemplo, um worm pode enviar cópias de si mesmo a todas as pessoas que constam no seu catálogo de endereços de email, e os computadores dessas pessoas passam a fazer o mesmo, causando um efeito dominó de alto tráfego de rede que pode tornar mais lentas as redes corporativas e a Internet como um todo. Quando novos worms são lançados, eles se alastram


   

 

 



   

    

   



Página 24

 

 

  


muito rapidamente. Eles obstruem redes e provavelmente fazem com que você (e todos os outros) tenha de esperar um tempo maior para abrir páginas na Internet. Na prática, todos os vírus e vários worms não podem se espalhar sem que você abra um arquivo ou execute um programa infectado. Muitos dos vírus mais perigosos foram espalhados principalmente via anexos de email, os arquivos que são enviados com as mensagens de email. Geralmente você tem como saber que um email contém um anexo, pois este é exibido como um ícone de clipe de papel que representa o anexo e contém o seu nome. Fotos, cartas escritas no Microsoft Word e até mesmo planilhas eletrônicas do Excel são apenas alguns dos tipos de arquivo que você pode receber através de email a cada dia. Um vírus é ativado quando você abre um arquivo anexo infectado. 10.1 Anti Vírus O anti-vírus é a ferramenta mais recomendada contra vírus, worms e trojans nos hosts, além disso os IPSs (sistema de prevenção de intrusos) e os IDSs (sistema de detecção de intrusos), em conjunto com os firewalls podem ser de grande ajuda para evitar que esses programas e códigos maliciosos entrem na rede, infectando os micros e servidores.

Nada pode garantir que um computador está 100% protegido. Entretanto, para continuar a melhorar a segurança do computador recomenda-se manter os programas atualizados e atualizar sempre a assinatura do software antivírus. Outras ferramentas que podem ser implementadas são os HIPSs ou Host IPS e anti-spyware ou programa anti-espionagem que protegem contra diversos tipos de infecções e cavalos de tróia. Também não devemos abrir arquivos suspeitos, e-mails que não sejam de origem confiável, nem utilizar o computador em redes suspeitas sem estar com seu micro atualizado e com o anti-vírus atualizado. Tratando do problema com uma abordagem mais corporativa, ou seja, em como tratar um infecção de vários computadores em uma empresa, o administrador deve se preocupar com a política de segurança nos hosts, sejam micros ou servidores, garantindo que não saia uma máquina para um usuário final sem um anti-vírus instalado. Existem várias opções de anti-vírus corporativas que facilitam a administração, como por exemplo, os mostrados ao lado. Outra medida é que os anti-vírus e sistemas devem estar sempre atualizados. O NAC (Network Admission Control) da Cisco pode ajudar nessa tarefa, ele tem a função de avaliar se a política de segurança nos hosts está sendo cumprida e colocar micros fora da política em uma espécie A p o s t i l a / E - Bo o k d o C u r s o I I N S 6 4 0 - 5 5 4      

   

 

 



   

    

   



Página 25

 

 

  


de quarentena até que a situação seja resolvida, como por exemplo, o anti-vírus seja atualizado. Já uma infecção por um worm exigirá mais do administrador de rede por sua característica de propagação utilizando a rede. A resposta a uma infecção do worm pode ser dividida em quatro fases: contenção, inoculação, quarentena e tratamento. Veja na figura ao lado como mitigar ataques de worms. A contenção visa limitar a infestação que pode se espalhar na rede, o que pode ser realizado através de ACLs ou até mesmo desligando certos segmentos de redes infestados, isolando-os. A inoculação é onde o problema é resolvido, aplicando patches de segurança ou removedores de worms especificamente lançados para determinadas infestações. A quarentena e o tratamento serve para isolar os micros infectados e inoculá-los resolvendo o problema. Muitas vezes pode chegar ao ponto de ser necessária a reinstalação do sistema operacional para resolver o problema.

10.2 Outros Tipos de Malwares Existem além dos três vilões citados acima outros riscos, tais como: 

Adware: Tradicionalmente, o Adware é uma forma legítima de distribuição de software. Alguns desenvolvedores, principalmente aqueles independentes de grandes corporações, na hora de lucrar com suas criações, optam por um modelo de negócios alternativo: em vez de cobrar pelo programa em questão, cria-se um modelo de publicidade em programas. Ou seja, o desenvolvedor ganha uma comissão de anunciantes, que pagam para terem seus banners ou links nos programas utilizados pelos usuários. A prática é legal, porém existe o lado oposto, com Adwares que corrompem arquivos de usuários ou instalam Spyware. Um caso famoso era o software BonziBUDDY, um macaco roxo animado que era disponibilizado como um “companheiro” ao usuário, além de prometer aprimorar a experiência de navegação. Intrusões em excesso, mudança de configurações, exibição de pop-ups sem permissão, entre outras acusações, incluindo de instalação de Trojan e uso de Backdoor, levaram o macaco a ser um dos programas mais odiados da internet.


   

 

 



   

    

   



Página 26

 

 

  










Spyware: É o “software espião”. Geralmente, é um arquivo que é executado de maneira oculta, coletando dados de uso do computador e da internet do computador infectado. Alguns chegam a roubar dados, agir como keyloggers, alterar configurações e arquivos e até instalar programas. Botnet: No caso, não é uma ameaça direta, mas sim uma consequência de outros males. Uma Botnet, ou Rede de Robôs (Bots), acontece quando um hacker infecta uma série de computadores (por meio de Trojan ou Worm, geralmente), fazendo-os integrar uma rede, sem que seus donos saibam. Com esses computadores como seus “soldados”, o Hacker pode disponibilizar seus serviços por dinheiro, e utilizá-los para mandar mensagens de Spam em massa, assim como derrubar conexões e servidores por ataques de Denial of Service. Keyloggers: Software que realiza o Keylogging ou Keystroke Logging, é um programa oculto que registra tudo que é digitado em um computador. Geralmente instalado por meio de um Trojan, facilita a obtenção de informações e senhas. É por isso que vários sistemas de sites, como o exemplo de bancos, pedem o uso de teclados virtuais, que não necessitam que o usuário tecle suas senhas. Rootkit: Software de uso ativo, ele permite privilégios de acesso continuados a um computador, ao mesmo tempo que disfarça sua presença. Um Hacker geralmente instala um rootkit depois de passar das barreiras mais simples de um sistema, possibilitando acesso administrativo e, eventualmente, acesso total aos dados do sistema invadido.


   

 

 



   

    

   



Página 27

 

 

  


11 Entendendo o Buffer Overflow Os Buffers são áreas de memória criadas pelos programas para armazenar dados que estão sendo processados. Cada buffer tem um certo tamanho, dependendo do tipo e quantidade de dados que ele irá armazenar. O chamado “estouro de buffer”, falha muito comum hoje, ocorre quando o programa recebe mais dados do que está preparado para armazenar no buffer. Se o programa não foi adequadamente escrito, este excesso de dados pode acabar sendo armazenado em áreas de memória próximas, corrompendo dados ou travando o programa, ou mesmo ser executado, que é a possibilidade mais perigosa. Se um programa qualquer tivesse uma vulnerabilidade no sistema de login por exemplo, você poderia criar um programa que fornecesse caracteres de texto até completar o buffer e depois enviasse um executável, que acabaria rodando graças à vulnerabilidade. Tanto o stack overflow (overflow da pilha) quanto o heap overflow (overflow da memória heap) podem ser encontrados em diversos programas existentes no mercado. O conceito é simples e vamos pegar o stack overflow como exemplo. Suponhamos que eu esteja fazendo um programa em linguagem C (poderia ser qualquer uma) e nele crio um buffer, um espaço na memória destinado a receber entrada de dados. Veja o exemplo a seguir: #include #include int main(int argc, char **argv){ char buffer[10]; strcpy(buffer,

“testandostackoverflow”));

return 0; }

Nesse pequeno programa, definimos o tamanho do buffer como 10 caracteres e copiamos para ele (através da função strcpy) um texto (string) contendo 21 caracteres. Como a função strcpy, ao contrário de strncpy, não faz a checagem do tamanho do espaço disponível, esse programa causará um estouro de buffer, fazendo com que você possa incluir um código personalizado para ser executado pelo programa. Veremos as implicações disso depois. Portanto, a ideia é estourar o buffer e sobrescrever parte da pilha, mudando o valor das variáveis locais, valores dos parâmetros e/ou o endereço de retorno. Altera-se o endereço de retorno da função para que ele aponte para a área do código que se deseja executar, onde encontra-se armazenado o código malicioso. Pode-se assim executar código arbitrário com os privilégios do usuário que executa o programa vulnerável. Veja figura a seguir.


   

 

 



   

    

   



Página 28

 

 

  


Um caso famoso foi descoberto no passado (ano 2000) no Outlook Express. Graças à uma vulnerabilidade, era possível fazer com que um e-mail executasse arquivos apenas por ser aberto! Bastava anexar um arquivo com um certo número de caracteres no nome, que ele seria executado ao ser aberta a mensagem. Naturalmente, a Microsoft se apressou em lançar um patch e alertar os usuários para o problema. Para corrigir este tipo de vulnerabilidade de over flow basta tratar as entradas e não permitir entradas maiores do que o tamanho do buffer.


   

 

 



   

    

   



Página 29

 

 

  


12 Entendendo o Spoofing Spoofing é a arte de criar informações de rede falsas e utilizá-las para diversos propósitos: Evitar ser capturado nos logs do sistema fazendo o que não devia Realizar scanneamentos estando totalmente oculto (varreduras) Ganhar acesso a máquinas que são protegidas por configurações de firewall   

O IP Spoofing é uma das técnicas mais usadas para personificar quem você não é, ou seja, assumir uma identidade falsa, no caso do IP um endereço de rede falso conforme figura a seguir.

Os atacantes podem lançar uma variedade de ataques iniciando com um ataque de spoofing IP. Um ataque de spoofing de IP faz com que o endereço IP de um atacante pareça ser um endereço IP confiável. Por exemplo, se um invasor convence um host que ele é um cliente confiável, ele pode ganhar acesso privilegiado a um host ou capturar o tráfego de uma sessão, o qual pode incluir credenciais como nomes de usuários e senhas. Outro exemplo é utilizar a falsificação para fazer um ataque de negação de serviço (DoS) e negação de serviço distribuída (DDoS), onde o atacante pode usar falsificação de IP para ajudar a esconder sua identidade. Para simplificar, é como você chegar a algum local que te peçam um documento e você mostrar uma identidade falsa. Essa identidade não tem foto, somente um nome. A pessoa que está fazendo a segurança checa o nome, vê que está na sua lista e deixa entrar. Apesar de ser tecnicamente um pouco complexo, o conceito de spoofing é bem simples.


   

 

 



   

    

   



Página 30

 

 

  


12.1 Tipos de Spoofing Temos vários outros tipos: ARP Spoofing, spoofing de endereços MAC, DNS Spoofing e, claro, IP Spoofing. Existem dois tipos de IP spoofing: cego e não-cego. 



IP Spoofing Não-cego (Nonblind spoofing): geralmente, quando o IP spoofing é realizado, o pacote a ser enviado deve ser modificado, colocando outro endereço que não seja o do atacante. Esse pacote irá até o seu destino e será processado por ele de alguma maneira, seja enviando uma resposta ou simplesmente recusando-o. Agora como o atacante vai receber essa resposta, já que o endereço que está na informação enviada não é o verdadeiro da sua máquina original? A resposta é simples: se ele está em uma rede local, pode sniffar (farejar a rede) e analisar o tráfego dos pacotes IP e suas características internas. Isso seria o spoofing não-cego, pois o atacante pode ver a resposta do alvo, mesmo que ela seja endereçada a um endereço falso e inexistente que o atacante forjou. IP Spoofing Cego (Blind spoofing): nesse caso o atacante está fora da sub-rede do atacado, de uma rede local e, consequentemente, não pode capturar o tráfego de resposta. Esse spoofing só é útil em casos em que o atacante não precisa receber um pacote de retorno. Exemplos: enviar e-mails, realizar Denial of Service etc. Também podem ser utilizados para tentar acesso aos antigos serviços R baseados em autenticação por IP (rlogin, rsh etc.). Sabendo o endereço IP certo e enviando os comandos necessários, o atacante poderia realizar alguma configuração de firewall ou execução de backdoor e, assim, obter acesso posterior à máquina ou mesmo conexão reversa utilizando o Netcat, por exemplo.

12.2 IP Spoofing Para entender melhor como um ataque de falsificação de IP (spoofing) pode ser realizado vamos relembrar como uma sessão TCP é iniciada, pois na camada 3 é mais fácil do atacante falsificar o pacote IP. Veja a animação a seguir.

Analisando a figura lembre como o TCP é inicializado através do handshake de três vias:


   

 

 



   

    

   



Página 31

 

 

  






O host (A) inicia uma conexão enviando um pacote SYN para o host (B) indicando que o seu ISN = X: A —> B SYN, seq de A = X. No exemplo o número de sequência enviado é 100. “B” recebe o pacote, grava que a seq de A = X, responde com um ACK de X + 1, e indica que seu ISN = Y (Initial Sequence Number ou número inicial de sequência). O ACK de X + 1 significa que o host B já recebeu todos os bytes até ao byte X e que o próximo byte esperado é o X + 1: B —> A ACK, seq de A = X, SYN seq de B = Y, ACK = X + 1. No exemplo da figura 1, o micro B recebeu o SYN de A 100 e responde com um ACK igual a 101, enviando o valor de 200 como sequência para o micro A. “A” recebe o pacote de B, fica sabendo que a sequência de B = Y, e responde com um ACK de Y + 1, que finaliza o processo de estabelecimento da conexão: A —> B ACK, seq de B = Y, ACK = Y + 1. No exemplo da figura 2 A responde com o valor de 201.

Portanto, para entrar no meio de uma conexão, realizando um sequestro ou hijacking da sessão, será necessário que o atacante saiba, descubra ou “chute” os números de sequência para poder entrar nessa sessão TCP. Como vimos anteriormente, em um ataque não cego (nonblind spoofing) o atacante pode descobrir os números de sequência através de um snnifer, por exemplo, pois ele está na mesma sub-rede. No caso de um ataque cego (blind spoofing) já não é possível, sendo bem mais difícil prever os números de sequência. Uma das formas de prever os números de sequência do TCP em um ataque cego é através do “IP source routing” do ICMP. Veja a figura a seguir.

Com o "IP source routing" é possível previamente estabelecer o caminho que um pacote irá seguir (path) para chegar ao seu destino, fazendo também com que o destino desse pacote envie suas respostas (replies) utilizando o MESMO caminho. Dessa forma, um cracker sabendo do caminho desses pacotes pode interceptá-los fazendo com que o destino acredite ser ele o source (origem) correto desses pacotes. Nesse tipo de ataque o hacker pode escolher dois tipos de rotas de origem que são permitidas pelo source routing: 



Strict source routing: Mostra o caminho completo, da origem até o destino, a ser seguido. O datagrama é obrigado a seguir exatamente a rota especificada. Loose source routing: Apresenta uma lista de roteadores que não devem ser esquecidos. Esta opção exige que o datagrama passe por uma lista de roteadores especificados.


   

 

 



   

    

   



Página 32

 

 

  


Em roteadores com Cisco IOS você pode evitar esse problema com o comando “no ip source route” em modo de configuração global. Em equipamentos de segurança como o Cisco PIX 500 e Cisco ASA 5500 (Adaptive Security Appliances) esses tipos de pacote são descartados (drop – dropados) por padrão. 12.3 Ataque Man-in-the-middle – MITM Outra forma de spoofing de IP é através de um ataque de man-in-the-middle. Este ataque normalmente é realizado através da escuta do tráfego entre os dois pontos finais através de uma técnica de sniffing. Com a análise desse comunicação o atacante pode “fingir” ser uma extremidade da conexão e pode realizar seu ataque. Um exemplo desse tipo de ataque é realizado através do envio de uma série de pacotes de ARP gratuito (gratuitous ARP ou GARP). Esses pacotes de GARP tem o objetivo de fazer com que a máquina de destino acredite que o endereço MAC da camada atacante é o MAC do roteador do próximo salto ou gateway default. Dessa maneira o invasor pode capturar o tráfego e encaminhá-lo ao gateway sem o usuário final notar qualquer coisa suspeita. O ataque descrito anteriormente, onde o atacante coloca um HUB ou faz um SPAN de porta em um switch para espiar (sniffer) os pacotes de rede também é um tipo de ataque man-in-themiddle. Veja a figura a seguir.

Para proteger a rede contra ataques de falsificação de IP várias técnicas podem ser implementadas e serão estudadas em detalhe, porém abaixo seguem algumas recomendações gerais: 





Utilizar ACL’s nas

interfaces dos roteadores. Recomenda-se filtrar tentativas de acesso direta à rede LAN e também a saída de tráfego sainte com IP’s diferentes da rede interna. Criptografar o tráfego entre as duas pontas, evitando que o tráfego capturado possa ser lido. Um exemplo é a utilização de VPNs IPSec para trafegar dados sensíveis pela Internet. Criptografar a autenticação, evitando que um atacante descubra usuários e senhas quando transmitidos pela rede ou pela Internet. Isso evita o sequestro de uma sessão.


   

 

 



   

    

   



Página 33

 

 

  


13 Entendendo Ataques à Confidencialidade das Informações A definição de confidencialidade é: “A propriedade que limita o acesso a informação tão somente às entidades legítimas, ou seja, àquelas autorizadas pelo proprietário da informação”. Portanto ataques desse tipo visam descobrir itens confidenciais tanto de pessoas como de empresas, tais como registros pessoais (números de documento) ou de funcionários (ficha funcional), nomes de usuário e senhas, números de cartão de crédito, endereços e-mails, etc. Na maioria dos casos esses tipos de ataque visam somente coletar informações e não alterar dados em um banco de dados, por exemplo. Portanto, mesmo com auditorias de segurança são muito difíceis de detectar. Um exemplo desse tipo de ataque é quando um atacante invade uma rede para descobrir números de cartão de crédito e dados dos seus usuários para realizar compras pela Internet, conforme figura a seguir. O atacante se aproveita da relação de confiança entre o servidor de Web e o servidor de banco de dados para ganhar acesso e roubar informações confidenciais. Lembramos que o exemplo é hipotético.

Abaixo seguem algumas estratégias utilizadas pelos atacantes para realizar ataques à confidencialidade: 





Captura de pacotes ou packet sniffing: já mencionado anteriormente, permite que o atacante capture pacotes na rede, analise os protocolos e descubra informações como nomes de usuário e senhas, muitas vezes passados em modo texto através da Internet ou Intranets. Varreduras de ping e port scan: com a varredura de ping ou ping sweep o atacante pode descobrir IPs que estão disponíveis e aplicar um port scan (varredura de portas) para aí descobrir os serviços que estão disponíveis nesses hosts. Também pode ajudar ao atacante descobrir qual o sistema operacional do host atacado. Dumpster Diving ou Trashing: atividade na qual o lixo é verificado em busca de informações sobre a organização ou a vítima e, normalmente, não é um ataque por meio informatizado, embora seu resultado possa ser aplicado nesse meio. É uma técnica legal e mostra a necessidade de uma política de segurança para a papelada que circula na organização.


   

 

 



   

    

   



Página 34

 

 

  












Interceptação via interferência eletromagnética (EMI): como a maioria dos dados são transmitidos via pares metálicos os atacantes podem capturar essas “emanações” eletromagnéticas para realizar uma cópia desses dados enviados. Wiretapping ou escuta telefônica: técnica muito difundida em filmes de espionagem onde o atacante faz uma escuta telefônica em paralelo com os pares de fios do atacado e grava suas conversas em busca de informações. O sniffing é um tipo de escuta também, pois colocando um hub no meio da rede o atacante recebe uma cópia de todos os pacotes trocados por aquele usuário. Engenharia social: Tem como objetivo enganar pessoas pelo uso de identidades falsas, por exemplo, a fim de obter senhas ou outras informações importantes. Um exemplo seria um invasor se passar por um membro da equipe da TI e pedir para um usuário digitar seu usuário e senha em um computador comprometido, com um keylogger por exemplo, e capturar as informações digitadas. Envio de informações sobre canais abertos (overt channels): o atacante pode enviar ou receber informações retiradas da rede do atacado através do HTTP, por exemplo, utilizando o tunelamento de um programa de mensagens instantâneas tunelado nesse canal HTTP. Outra técnica utilizada é a esteganografia, a qual são técnicas para ocultar a existência de uma mensagem dentro de outra. Por exemplo, poderia enviar em uma imagem as informações escondidas em alguns pixels que somente o receptor saberia encontrar e decifrar. Envio de informações sobre canais secretos (covert channels): Um invasor pode enviar ou receber informações confidenciais em uma rede usando um canal secreto, que pode comunicar as informações como uma série de códigos e/ou eventos. Por exemplo, dados binários poderiam ser representados por enviar uma série de pings para um destino. Um ping único dentro de um determinado período de tempo representaria um bit 0 e dois pings dentro desse mesmo período de tempo representaria um binário 1. Phishing, pharming e roubo de identidade (identity theft): Phishing é uma tentativa de adquirir criminalmente informações confidenciais, como nomes de usuários, senhas e informações de cartão de crédito, fazendo-se parecer uma entidade ou pessoa confiável. Pharming é um ataque que visa redirecionar o tráfego de um site para outro site, muitas vezes podendo ser realizado pela invasão de servidores DNS e incluindo entradas falsas.


   

 

 



   

    

   



Página 35

 

 

  


14 Entendendo Ataques à Integridade das Informações Em segurança da informação, integridade significa ter a disponibilidade de informações confiáveis, corretas e dispostas em formato compatível com o de utilização, ou seja , informações íntegras. Os ataques a esse atributo visam alterar os dados, comprometendo sua integridade. Veja um exemplo de ataque à integridade na figura a seguir. Nesse exemplo o atacante realizou um ataque de man-in-the-middle não somente interceptando a transação, mas também alterando os dados e fazendo com que o depósito do cliente de R$500,00 se tornasse R$5.000,00 e depositado em outra conta bancária. Esse tipo de ataque é hipotético e muito difícil de ser realizado devido a todos os dispositivos de segurança implantados pelos bancos na atualidade.

Abaixo seguem algumas estratégias utilizadas pelos atacantes para realizar ataques à integridade: 





Ataque Salami: Esta é uma coleção de pequenos ataques que resultam em um ataque maior quando combinado. Por exemplo, se um invasor tinha uma coleção de números de cartões de crédito roubados ele poderia retirar pequenas quantias de dinheiro de cada cartão de crédito (possivelmente despercebidos pelos titulares de cartão de crédito). Embora cada retirada é pequena, eles somam um valor significativo para o atacante. Data diddling: O processo de data diddling são alterações de dados antes que ele seja armazenado em um sistema de computação. Os códigos maliciosos em um aplicativo de entrada ou vírus podem executar o diddling. Por exemplo, um vírus, cavalo de tróia ou um worm pode ser escrito para interceptar a entrada do teclado, como um keylogger, e exibirá os caracteres digitados corretamente na tela para que o usuário não perceba nenhum problema. No entanto, um aplicativo de banco de dados guardaria esses dados digitados para posteriormente serem analisados, ou antão esse programa poderia enviar os dados através da rede. Exploração de relação de confiança (trust relationship exploitation): esse método foi utilizado como exemplo na figura 1 e permite que o atacante consiga chegar ao seu objetivo atacando um elemento menos seguro. Por exemplo, atacando um host da rede menos protegido que tenha relação de confiança com o firewall, podendo enviar informações para fora da rede através do firewall devido a esse micro atacado ser permitido.


   

 

 



   

    

   



Página 36

 

 

  














Ataques por senha (password attacks): como o próprio nome diz é um ataque que tem como objetivo descobrir usuários e senhas da rede ou de determinado sistema. Descobrindo um usuário/senha válidos ele ganhará os privilégios desse usuário e pode procurar escalar ou ganhar privilégios adicionais à rede ou sistema. Abaixo seguem alguns exemplos de ataques por senha. Cavalo de tróia (trojan horse): Apesar de serem classificados como vírus pelas companhias de antivírus (na realidade, essas empresas sabem a diferença, mas, na hora de avisar o usuário leigo, dizem que é um vírus mesmo) um trojan é bem diferente de um vírus comum. O cavalo de tróia age de acordo com quem o instalou no sistema, essa pessoa passa a controlar aquele computador como se estivesse sentada em frente a ele. Com um trojan o atacante pode descobrir usuários e senhas. Captura de pacotes: já tratado anteriormente, utilizado para sniffar o atacado e descobrir usuários e senhas enviadas em modo texto. Keylogger: São programas especializados em capturar o que se digita no teclado e salvar no disco ou enviar essa informação para um endereço específico. Um excelente recurso para espionar o que outras pessoas fazem no computador, considerado como um vírus por alguns e como uma importante ferramenta comercial por outros. Força bruta (brute force): Parecida com o ataque de dicionários, mas esse método não utiliza palavras prontas em uma lista e, sim, gera todas as combinações possíveis de caracteres para tentar como senha. É, de longe, o método mais eficiente para senhas criptografadas locais e remotamente, não dá muito resultado. Ataque de dicionário: O ataque de dicionários consiste em criar uma lista de palavras (wordlist) ou senhas muito utilizadas e valer-se dessas informações. Se a pessoa utilizar uma senha simples ou fraca, esse processo costuma ser bem eficiente. Hijacking ou sequestro de sessão: como citado em exemplo anteriormente nesse capítulo, o sequestro de sessão é quando um hacker consegue, por exemplo, entrar no meio de uma sessão TCP. Se um atacante sequestra uma sessão de um dispositivo autorizado, ele pode ser capaz de manipular dados em um servidor protegido, por exemplo.

15 Entendendo Ataques à Disponibilidade das Informações Um sistema de alta disponibilidade é um sistema de informação resistente a falhas de software, hardware e energia, cujo objetivo é manter os serviços disponibilizados o máximo de tempo possível. Ataques a disponibilidade de um sistema é a tentativa de limitar a acessibilidade e usabilidade do sistema para os usuários. Por exemplo, se um invasor pode consumir os recursos do processador ou a memória de um determinado servidor, fazendo com que o sistema fique indisponível para usuários da empresa, sejam funcionários ou clientes. A estratégia dos atacantes para afetar a disponibilidade dos sistemas pode ir desde consumir recursos de software e hardware de um servidor até fazer ataques físicos, como desligar a energia de um escritório. Na sequência veremos algumas estratégias utilizadas pelos atacantes. Denial Of Service (DoS): a recusa de serviços tem como rede, consumindo os seus recursos. Isso pode ser feito de simples: um invasor poderia enviar um pacote spoofado para tivesse vindo de outro servidor da mesma rede, fazendo os consumindo toda a banda disponível.

objetivo derrubar um sistema da diversas maneiras. Um exemplo o servidor de uma rede, como se dois trocar informações entre si,


   

 

 



   

    

   



Página 37

 

 

  


Distributed denial of service (DDoS): A recusa de serviço distribuída é um poderoso recurso, pois soma todo o poder das conexões nos sistemas em que está instalada. Se eu infectar cem computadores, cada um deles possuindo uma conexão de até 256 Kb, já é o suficiente para derrubar grandes servidores. Existem alguns programas para realizar isso, o mais conhecido deles é o Tribal Flood Network, ou TFN. Esse software possui diversas versões, como o TFN2k. Também existem alguns poucos programas para Windows que realizam essa tarefa. Um dos mais conhecidos deles foi o WinTrinoo. Os computadores infectados para realizar o DDoS normalmente são chamados de zumbis. Botnet: São redes formadas por computadores infectados com Bots. Estas redes podem ser compostas por centenas ou milhares de computadores. Um invasor que tenha controle sobre uma Botnet pode utilizá-la para aumentar a potência de seus ataques, por exemplo, para enviar centenas de milhares de e-mails de Phishing ou Spam, desferir ataques de negação de serviço, etc. De modo similar ao Worm, o Bot é um programa capaz de se propagar automaticamente, explorando vulnerabilidades existentes ou falhas na configuração de softwares instalados em um computador, o qual se torna um computador zumbi (zombie). TCP SYN flood: Técnica que envia pacotes Syn para um sistema, mas não realiza a transação completa em três vias. O resultado é que o alvo vai recebendo inúmeros pacotes, fica aguardando o resto das respostas e, eventualmente, consome todos os seus recursos.

Ataques via ICMP: o ICMP é utilizado pelos administradores de rede com funções de trobleshooting, porém pode ser utilizado para realizar ataques, como o ping da morte ou “ping of death”, ataques de fragmentação e de smurf. O ataque de smurf é uma técnica que utiliza os endereços de broadcast das redes para gerar tráfego excessivo e redirecionar todos esses dados em um único alvo, consumindo automaticamente a sua banda.


   

 

 



   

    

   



Página 38

 

 

  


Distúrbios elétricos: em nível físico, o atacante pode interferir no fornecimento de energia elétrica, interrompendo do serviço ou apenas interferindo no seu bom funcionamento para causar a negação do serviço para os usuários. Por exemplo, um atacante pode invadir fisicamente um Datacenter e causar os seguintes problemas:      

Pico de energia ou Power spike Sobretensão ou Electrical surge Desligamento curto ou Power fault Desligamento prolongado ou Blackout Subtensão ou Power sag Subtensão prolongada ou Brownout

Outros ataques no sistema físico: podendo causar problemas nos recursos de informática danificando outros equipamentos, como o sistema de ar condicionado, afetando temperatura e umidade, e sistema de gás, podendo causar danos graves, pois os gases são inflamáveis. Algumas medidas básicas para o ambiente físico devem ser consideradas nos projetos: 

 





Limitar acesso aos equipamentos de rede com trancas, isolando os equipamentos de rede; Utilizar controle de acesso via uso de credenciais, como crachás e biometria; Implantar sistema de monitoração por vídeo (video surveilance) nos pontos de acesso à infra-estrutura; Ter controle de temperatura e umidade do ar para garantir que as especificações do fabricante sejam seguidas, incluindo sistema de alarme em caso de fuga dos parâmetros estabelecidos; Utilizar sistema de detecção e supressão de incêndio para evitar danos aos equipamentos.


   

 

 



   

    

   



Página 39

 

 

  


15.1 Ameaças Combinadas Os ataques combinados ou ameaças combinadas (Blended threats) são como pacotes de programas que combinam a funcionalidade de diferentes tipos de malware, incluindo Trojans, worms e backdoors. Uma ameaça combinada geralmente uma série de infecções onde,por exemplo, um visitante de um website é desviado para uma URL falsa, a qual via engenharia social desvia a atenção do visitante para que ele faça o download de um arquivo contaminado com um vírus ou trojan. Com essa metodologia criminosos virtuais conseguem espalhar essas ameaças pela Internet. Normalmente esse tipo de ameaça pode ser composta por: 





Mais de um meio de distribuição, por exemplo, enviando um vírus/worm híbrido por email que se replica sozinho para invadir um servidor Web, assim a infecção vai se espalhar para todos os visitantes do site; Exploração de vulnerabilidades, as quais podem já existir no sistema ou até mesmo serem provocadas pelo malware citado no item anterior; Intenção de causar problemas reais e mais sérios ao invés de só atrapalhar a vida do computador de um usuário, por exemplo, lançando um ataque de denial of service (DOS) contra o alvo ou então um cavalo de Tróia que será ativo em uma determinada data; Automatização do ataque para que ele precise do mínimo de ação por parte da vítima, como por exemplo abrir um anexo.

Esses tipos de ameaças podem ser evitadas pelos administradores de redes através da atualização constante dos sistemas operacionais e programas (aplicação de patch), através de firewalls confiáveis e bem configurados, softwares para detectar malwares nos servidores, varredura externa de ameaças realizadas por terceiros e educação dos usuários sobre o comportamento online ao acessar websites suspeitos e recebimento de e-mail. 16 Melhores Práticas ou Best-Practices para Manter uma Rede Segura Agora você tem uma compreensão fundamental das ameaças direcionadas aos ambientes de rede e informática, vamos analisar as recomendações da Cisco para ajudar a proteger sua rede:   

 





 



Aplicar patches de sistemas operacionais e aplicativos continuamente. Desativar serviços desnecessários e portas não utilizadas em roteadores e switches. Exigir senhas fortes e forçar a expiração da senha, fazendo com que os usuários troquem suas senhas periodicamente. Proteger o acesso físico aos computadores e demais equipamentos de rede. Impor práticas seguras de programação, tais como limitar os caracteres válidos que podem ser inseridos na caixa de diálogo de um aplicativo. Realizar regularmente backup de dados e verificar a integridade dos mesmos, pois fazer o backup somente não garante que ele esteja realmente íntegro e funcional. Treinar os usuários sobre boas práticas de segurança e educá-los sobre táticas de engenharia social. Usar criptografia forte para dados importantes (sensíveis). Defender-se contra ataques técnicos de implantação de sistemas de segurança de hardware e software (por exemplo, firewalls, sensores IPS e software antivírus). Criar uma política de segurança documentada para uso de toda a empresa.


   

 

 



   

    

   



Página 40

 

 

  


17 Resumo do Capítulo Bem pessoal, chegamos ao final do capítulo. É muito importante que nesse ponto do curso você tenha domínio dos seguintes itens:         



Os Três Princípios Básicos de Segurança Classificação dos Dados Controles de Segurança Classificação de Ataques e Hackers Conceito de Defense in Depth O que são Vírus, Worms e Cavalos de Tróia Conceito de Buffer Overflow Principais técnicas de Spoofing Principais Ataques à Confidencialidade, Integridade Informações Listar as melhores Práticas para manter uma rede segura

e

Disponibilidade


   

 

 



   

    

   



das

Página 41

 

 

  


Capítulo 3 - Segurança em Roteadores Cisco Nesse capítulo vamos começar a reforçar a segurança do perímetro configurando os roteadores, pois evitar acessos indevidos aos pontos de contato com o mundo exterior e que faz conexão entre as diversas redes da empresa é o primeiro passo para proteger sua rede corporativa.

Objetivos do Capítulo Ao final desse capítulo você terá estudado e deverá compreender: Como proteger o acesso administrativo em roteadores Cisco (senhas criptografadas, exec timeout, limitando erros de login e melhorias na segurança para o login no IOS da Cisco). Configurar múltiplos níveis de privilégio em roteadores Cisco. Configurar o “role based CLI” para proteger acesso administrativo em roteadores Cisco. Proteger a imagem do Cisco IOS e o arquivo de configuração. Utilizar CLI e CCP para configurar o SSH em roteadores Cisco para permitir o acesso remoto seguro. Configurar o Syslog via CLI e CCP. Como utilizar o recurso de Auditoria de Segurança do CCP para proteger roteadores. Como utilizar o One-Step Lockdown do CCP para proteger um roteador Cisco. 





Muitos conceitos foram estudados no CCNA R&S ou CCENT, porém agora daremos foco em aspectos específicos relacionados à segurança.













   

 

 



   

    

   



Página 42

 

 

  


4 Configurando os Níveis de Acesso Administrativos _____________________ 62

Sumário do Capítulo 1 Posicionamento dos Roteadores na Rede e Topologias de Acesso à Internet _______ 44

1.1 Itens de Segurança em um Edge-Router – Roteador de Borda ___________________ 45 1.2 O Acesso Seguro a um Dispositivo de Infraestrutura ________________________ 46 1.3 2

Formas de Acesso em Roteadores Cisco 47

Protegendo o Acesso Administrativo _ 48

2.1 Enable Secret (senha secreta para o modo Executivo Privilegiado) ____________ 49 2.2

Linha de Console_________________ 50

2.3 Linha Auxiliar ou Aux ( Acesso remoto via modem discado) ___________________ 51 2.4 Comandos Extras para Reforçar a Segurança ao Acesso Administrativo ______ 51 2.5 Configurando um Usuário e Senha Local para Acesso Administrativo _____________ 53 3 Aumentando a Segurança para o Login Virtual _____________________________ 54

3.1

Exemplos Práticos _______________ 55

3.2

Configuração de Banners __________ 56

3.3

Configurando o Acesso Remoto Via SSH 57

4.1 CLI Views – Níveis de Acesso por Usuário Local _________________________ 63 5 Segurança dos Arquivos de IOS e Configuração _______________________ 65 6 Reforçando a Segurança no Gerenciamento e Report ______________ 65 7 Configurando o Sysylog em Roteadores Cisco ______________________________ 66

7.1

Configurando o Syslog ____________ 68

8 Configurando o SNMP de Maneira Segura ____________________________ 69

8.1

Versões do SNMP ________________ 69

8.2

Configurando o SNMP via CCP _____ 70

9 Configurando o NTP – Network Time Protocol ___________________________ 70

9.1

NTP via CCP ____________________ 71

9.2

Ajuste Manual – Clock Set e via CCP _ 71

10 Realizando a Auditoria de Segurança via CCP ____________________________ 71

10.1

Security Audit Wizard - CCP ______ 72

10.2

Cisco Autosecure - CLI __________ 72

10.3

Aplicando o Autosecure _________ 73

10.4

One-step Lock-down - CCP _______ 77

3.4 Acessando um Roteador Cisco com Acesso Remoto Via SSH_________________ 58

11 E para o IPv6? Continua a mesma coisa? _____________________________ 78

3.5 Acessando o Cisco Configuration Professional e Configurando o SSH via WebGUI 59

12

3.5.1

Resumo do Capítulo ____________ 79

Navegando no CCP e Ativando o SSH 60


   

 

 



   

    

   



Página 43

 

 

  


1 Posicionamento dos Roteadores na Rede e Topologias de Acesso à Internet Levando-se em conta que estamos trabalhando com uma empresa que possui sua rede Interna, ou Intranet, e um ou mais pontos de acesso à Internet ou Extranets, os roteadores podem ser classificados como:  

Roteadores Internos: com endereçamento IP da Intranet. Roteadores de borda ou Edge-routers: posicionados na saída para Internet ou Extranets.

A diferença básica entre os dois posicionamentos é que o roteador de borda estará sujeito a mais ataques, muito mais variados e sofisticados, necessitando cuidados especiais e uma topologia que garanta que ele não será um ponto único de falha para a rede. Lógico que dependendo do tamanho da empresa podemos utilizar diferentes abordagens e topologias que se adéquam à sua realidade tecnológica e principalmente financeira. Vamos aqui ilustrar três abordagens: Single-router: apenas um roteador será o ponto de ligação entre a Internet e a Intranet. Essa topologia é a mais simples e que exige menos custo, porém também é a mais vulnerável, pois passando pelo roteador o atacante terá a rede “em suas mãos”. Essa topologia é recomendada para pequenos escritórios remotos ou home offices. Os roteadores da Cisco suportam essa topologia contemplando tanto as características de segurança como as de roteamento em um equipamento único.

Defense-in-depth: De acordo com este princípio, não se deve depender de apenas um mecanismo de segurança não importando quão forte ele pareça ser. Ao invés disso, recomenda-se que sejam utilizados múltiplos mecanismos de segurança e que estes estejam configurados no nível mais alto possível de segurança e redundância. A estratégia principal é fazer com que o ataque seja significativamente arriscado e caro ao atacante que se espera encontrar.

DMZ (Zona Desmilitarizada): Também conhecida como Rede de Perímetro, a DMZ é uma pequena rede situada entre uma rede confiável e outra não confiável, geralmente entre a rede local e a Internet. Veja a figura 3. Note que na figura três o firewall fornece uma porta de acesso aos servidores que podem ser acessados diretamente pela Internet. Já os micros da Intranet, ou rede Interna, estão protegidos contra ataques externos. A p o s t i l a / E - Bo o k d o C u r s o I I N S 6 4 0 - 5 5 4      

   

 

 



   

    

   



Página 44

 

 

  


1.1 Itens de Segurança em um Edge-Router – Roteador de Borda Também quando falamos em segurança de um edge-router ou roteador de borda temos que lembrar em garantir os seguintes itens de segurança: • Segurança Física: instalar o equipamento em local seguro e com limitação de acesso à pessoas não autorizadas, bem como garantir fontes de energia reserva para evitar ataques de negação de serviço (DoS) através do desligamento da chave geral da energia do prédio, seja intencional ou por motivos fortuitos.


   

 

 



   

    

   



Página 45

 

 

  


• Sistema Operacional (IOS): de preferência configurar o equipamento com o máximo de memória possível, para que haja suporte à diversas facilidades de segurança e garantir que o roteador suporte alguns tipos de ataque de DoS, bem como utilizar sempre a versão mais estável de IOS, que garanta estabilidade ao sistema e correção de problemas. É importante lembrar que a última versão nem sempre é a mais estável. Por último garantir que exista uma cópia segura do sistema operacional e configuração para os casos mais graves.

• Limitar acesso, desativar portas e serviços desnecessários: assegurando o controle administrativo, certifique-se que somente o pessoal autorizado tenha acesso e que seu nível de acesso é controlado, assim como desabilitando portas e interfaces não utilizadas. E por último é recomendado também desativar serviços desnecessários, pois alguns desses serviços podem ser utilizados por um atacante para coletar informações ou para fins de exploração. 1.2 O Acesso Seguro a um Dispositivo de Infraestrutura Quando falamos de acesso administrativo várias tarefas importantes estão envolvidas em garantir o acesso seguro a um dispositivo de infra-estrutura. Abaixo vamos estudar as principais. 1. Restringir o acesso ao dispositivo - Limitar as portas de acesso, restringir os métodos de conexão local ou remoto permitido e restringir os métodos de acesso permitidos. 2. Registrar (log) e contabilizar todos os acessos (registro) - Para fins de auditoria qualquer acesso de qualquer usuário a um dispositivo deve ser registrado, incluindo “o que” e “quando” aconteceu. Podemos utilizar o AAA e Syslog para esse quesito. 3. Autenticar o acesso - Garantir que o acesso é permitido apenas aos usuários, grupos ou serviços autenticados, assim como limitar o número de tentativas de login e o tempo entre logins, evitando ataques de força bruta. Podemos utilizar o AAA para esse quesito. 4. Autorizar ações - Restringir as ações e tipos de visualização por qualquer usuário, grupo ou serviço em particular. Podemos utilizar o AAA para esse quesito. 5. Aviso Legal – Deve-se mostrar um aviso legal, desenvolvido em conjunto com a área Jurídica da companhia a cada tipo de tentativa de acesso ou sessão. Podemos utilizar os Banners para esse quesito. 6. Assegurar a confidencialidade dos dados - Proteger dados sensíveis armazenados localmente tanto para visualização como para cópia. Considere também a vulnerabilidade dos dados trafegando através de um meio compartilhado que pode sofrer ataques de sniffing, sequestro de sessão e “man-in-the-middle” (MITM). Por exemplo, em uma sessão de telnet os dados trocados entre o micro de gerência e o roteador estão em texto claro, enquanto via SSH


   

 

 



   

    

   



Página 46

 

 

  


eles estão criptografados. Se for necessário acesso Web ao dispositivo preferir o HTTPS (seguro) ao HTTP. 1.3 Formas de Acesso em Roteadores Cisco Além do que estudamos até o momento, vale lembrar que existem apenas duas formas de acesso administrativo: local ou remota. Um roteador ou switch Cisco pode ser acessado localmente através da porta de console e as maneiras de deixar esse acesso mais seguro é através da segurança física ao equipamento e implementar senhas de acesso administrativo. O acesso remoto a um roteador e switches tem apenas uma diferença, a porta auxiliar, a qual não está presente nos switches. Ela permite acesso remoto discado através de um modem. O acesso remoto via a rede IP pode ser realizado de diversas maneiras: Telnet, Secure Shell (SSH), HTTP, HTTPS ou via Simple Network Management Protocol (SNMP). Veja o resumo das formas de acesso na figura a seguir.

As boas práticas de segurança recomendam que se o acesso remoto para fins administrativos é necessário, ele deve ser realizado por computadores e/ou redes específicas (dedicadas) para fins de gerenciamento, limitando esse acesso a esse grupo de computadores. Abaixo seguem mais algumas recomendações importantes sobre o acesso remoto: • Criptografar todo o tráfego entre o computador de gerenciamento e o roteador, por exemplo, utilizando SSH e HTTPS ao invés de Telnet e HTTP. • Criar uma rede de gerenciamento dedicado. Definindo micros ou servidores específicos de gerenciamento que podem acessar interfaces específicas do roteador, bloqueando acessos desnecessários.


   

 

 



   

    

   



Página 47

 

 

  


• Configurar filtro de pacotes (ACL) para permitir que apenas os micros de gerenciamento identificados e protocolos permitidos acessem o roteador. Por exemplo, permitir apenas acesso via SSH a partir do endereço IP do micro de gerência para iniciar uma conexão remota com os roteadores da rede. Lembrem que essas medidas de segurança melhoram a proteção da rede mas não garantem que ela se torne intransponível. Por exemplo, senhas seguras devem utilizadas para que todo o esquema de proteção funcione. No decorrer do curso veremos como implementar via CLI e CCP (Cisco Configuration Professional) a teoria estudada até o momento. 2 Protegendo o Acesso Administrativo Para proteger os equipamentos como roteadores e switches o primeiro passo deve ser a escolha de senhas fortes, seguindo diretrizes ou regras para criar senhas que não sejam facilmente descobertas por métodos de “tentativa e erro” ou ferramentas para quebra de senha. Abaixo seguem algumas regras para criação de uma senha segura: • Use uma senha com comprimento de 10 ou mais caracteres, portanto quanto maior melhor será. • Utilize senhas complexas, as quais devem incluir uma mistura de letras maiúsculas e minúsculas, números, caracteres especiais e espaços. • Evite senhas baseadas em repetição, palavras do dicionário, sequências de números, nomes de parentes ou animal de estimação, informação biográfica, tais como datas de nascimento, números de documentos, nomes dos antepassados ou informações que sejam rastreáveis e de fácil identificação. Por exemplo: senha1234, admin/admin, joao160599, etc. • Erre deliberadamente a ortografia da palavra utilizada como senha. Por exemplo, cisco = C1sc0 ou password = P@ssw0rd. • Altere as senhas com frequência. Se uma senha for comprometida sem que o administrador de rede ou o usuário saibam, a janela de oportunidade para que o atacante use a senha estará limitada. • Não escreva senhas em locais óbvios como sobre a mesa, em sua agenda ou monitor, o ideal é não escrever em local algum e sim memorizá-la. Dica: Em roteadores Cisco e muitos outros sistemas, os espaços no início da senha são ignorados, mas espaços após o primeiro caractere não são ignorados. Portanto, um método para criar uma senha forte é usar a barra de espaço e criar uma frase composta de muitas palavras. Isso é chamado de uma frase secreta. A frase é muitas vezes mais fácil de lembrar do que uma simples senha. Também é mais longo e difícil de adivinhar.


   

 

 



   

    

   



Página 48

 

 

  


2.1 Enable Secret (senha secreta para o modo Executivo Privilegiado) A senha “enable secret” é um comando que deve ser executado em modo configuração global e tem o objetivo de restringir o acesso ao modo EXEC privilegiado. Na senha enable secret é utiliza um algoritmo de hash (criptografia) Message Digest 5 (MD5). Se a senha de enable for perdida ou esquecida, ela deve ser trocada utilizando o processo de recuperação de senha. Veja a seguir um exemplo de aplicação. Router>enable Router#config term Router(config)#enable secret d1t3c@! Router(config)#end Router#disable Router>enable Password:

Após configurada a senha de enable será necessarário digitar a senha para ter acesso ao modo provilegiado. Veja no comando show running-config que a senha de enable secret vem critptografada. Router#show running-config Building configuration... Current configuration : 499 bytes ! version 12.4 no service timestamps log datetime msec no service timestamps debug datetime msec no service password-encryption ! hostname Router ! enable secret 5 $1$mERr$hx5rVt7rPNoS4wqbXKX7m0 !

O 5 que aparece na configuração significa que a criptografia é MD-5 e os caracteres $1$mERr$hx5rVt7rPNoS4wqbXKX7m0 é a senha criptografada. Existe ainda o enable password, porém esse comando não deve ser utilizado por não ser criptografado. O enable password, apesar de não ser criptografado, foi mantido nas versões mais novas de IOS como uma forma de compatibilidade com versões mais antigas em caso de necessidade de um downgrade de versão, ou seja, necessidade de uma versão antiga de IOS que não suporte o comando “enable secret”.


   

 

 



   

    

   



Página 49

 

 

  


2.2 Linha de Console Por padrão, a porta de console não exige uma senha para acesso administrativo, porém não é recomendado deixá-la sem uma proteção de acesso por senha. Siga os passos a seguir para criar uma senha de console local. Router# Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)#line console 0 Router(config-line)#password D1t3c@! Router(config-line)#login Router(config-line)#end Router# %SYS-5-CONFIG_I: Configured from console by console Router# Router#show running-config | begin line con line con 0 password D1t3c@! login line vty 0 4 login ! ! ! end

O sub-comando “password” define a senha como D1t#c@! e o "login" faz com que a senha seja solicitada ao conectar um laptop via cabo de console. Note no show running-config que a senha definida é mostrada em texto claro, pois com exceção da senha secreta (enable secret) isso ocorrerá com todas as outras senhas. Para resolver esse problema entre com o comando “service password-encryption”, o qual criptografará todas as senhas em modo texto com um hash proprietário da Cisco de nível 7.


   

 

 



   

    

   



Página 50

 

 

  


2.3 Linha Auxiliar ou Aux ( Acesso remoto via modem discado) As portas auxiliares não requerem uma senha para acesso administrativo remoto, porém alguns administradores utilizam essa porta para configurar e monitorar remotamente o roteador usando uma conexão de modem dial-up (discado). Para acessar a linha auxiliar utilize o comando “line aux 0”, utilizando os comandos “password”e “login” para definir e solicitar a senha de acesso. Veja ao lado. Lembre que por padrão, com exceção da senha “enable secret”, todas as senhas do roteador Cisco são armazenadas em texto simples na configuração do roteador. Essas senhas podem ser visualizados com o comando “show running-config”. Sniffers também podem ser utilizados para ver essas senhas se a conexão onde o servidor TFTP que guarda as configurações for insegura ou através da comunicação com o roteador via Telnet. Caso um intruso obtenha acesso ao servidor de TFTP onde os arquivos de configuração do roteador são guardados como backup e as senhas estiverem em modo texto, ele será capaz de visualizar as senhas e ter seu ataque facilitado. O mesmo vale para os laptops dos técnicos de campo e micros de gerenciamento. 2.4 Comandos Extras para Reforçar a Segurança ao Acesso Administrativo Para o IOS 12.3(1) ou acima um comando em modo de configuração global foi adicionado para definir o tamanho mínimo de caracteres para as senhas a serem configuradas. Segue a sintaxe do comando seguir. R1(config)#security passwords min-length ? <0-16> Minimum length of all user/enable passwords R1(config)#security passwords min-length 10 R1(config)# R1(config)#enable secret cisco % Password too short - must be at least 10 characters. Password configuration failed R1(config)#end R1#

Perceba que após a configuração para um mínimo de 10 caracteres (security passwords minlength 10) foi tentado configurar a senha de enable com menos que o permitido (enable secret cisco) e uma mensagem de erro foi mostrada (% Password too short - must be at least 10 characters. Password configuration failed) indicando que a senha é muito curta e menor que 10 caracteres. Você pode configurar para que a senha tenha no máximo 16 caracteres, o mínimo recomendado na maioria das documentações são 8 caracteres. Além disso, lembre que é recomendado desativar sessões que não estejam em uso, isso vale para todas as linhas de configuração. Por padrão elas vêm com 10 minutos de tolerância à inatividade, após isso ela finaliza a sessão. Para alterar esse timer utilize o comando “ exectimeout” dentro do modo de configuração da linha específica, no exemplo a seguir para 5 minutos e 30 segundos.


   

 

 



   

    

   



Página 51

 

 

  


R1(config)#line console 0 R1(config-line)#exec-timeout ? <0-35791> Timeout in minutes R1(config-line)#exec-timeout 5 ? <0-2147483> Timeout in seconds R1(config-line)#exec-timeout 5 30 R1(config-line)#end R1#

Note que o primeiro parâmetro está definido em minutos, onde na config acima ficou em 5 minutos, e o segundo parâmetro em segundos, o qual foi configurado para 30 seg, ou seja, “exec-timeout 5 30”. Outro comando importante é o “service password-encryption”, pois todas as senhas mostradas até o momento vêm em modo texto claro na configuração, podendo ser visualizadas no arquivo de configuração caso esse comando não seja executado no roteador ou switch. Apesar da função ser semelhante, porém posterior, no enable secret o hash de criptografia aplicado pelo “service password-encryption” é mais fraco que o da senha de enable, podendo ser quebrada facilmente por um programa de “craker” de senha. Consulte o site http://www.ifm.net.nz/cookbooks/passwordcracker.html e veja um exemplo de descriptografia de senhas em roteadores e switches Cisco. Ele funciona apenas para senhas de nível 7, como a que o comando “service password-encryption” utiliza. O "enable secret" utiliza o nível 5 que é mais forte. Digite apenas a senha, não o comando inteiro. Veja a figura a seguir.


   

 

 



   

    

   



Página 52

 

 

  


2.5 Configurando um Usuário e Senha Local para Acesso Administrativo Outra maneira de configurar o acesso administrativo local e remoto é utilizando um usuário e uma senha com o comando “username”. Existem duas opções de configurar o usuário e a senha, conforme abaixo: 1. username usuario password senha 2. username usuario secret senha A diferença entre os dois é que o primeiro vem sem criptografia, necessitando do comando “service password-encryption” para ser criptografado. Já a opção 2 é como o enable secret, o qual vem criptografado com MD-5. Para ativar nas lines utilize o comando “ login local”, não sendo mais necessário configurar o comando “password”. Veja um exemplo de configuração a seguir. R1#conf t Enter configuration commands, one per line. End with CNTL/Z. R1(config)#username Admin secret ciscoooooo R1(config)#username User password ciscoooooo R1(config)#line cons 0 R1(config-line)#login local R1(config-line)#line vty 0 4 R1(config-line)#login local R1(config-line)#end R1# R1#sho run Building configuration... Current configuration : 1114 bytes ! version 12.4 ! ... saida omitida ! username Admin secret 5 $1$dbJB$2eahYM/Nx08dcDOjbEiHr1 username User password 0 ciscoooooo ! ! ... saida omitida ! line con 0 login local line aux 0 login local line vty 0 4 login local ! ! End Após a configuração veja um teste de acesso telnet como fica o prompt inicial. R1# *Apr 21 16:41:27.303: %SYS-5-CONFIG_I: Configured from console by console R1# R1#telnet 192.168.1.110 Trying 192.168.1.110 ... Open


   

 

 



   

    

   



Página 53

 

 

  


User Access Verification Username: Admin Password: R1>

Algumas versões de IOS tem o serviço de AAA ativado por padrão, nesse caso o comando login local não irá funcionar, para utilizar a configuração acima digite “ no aaa new-model”. O AAA será estudado no próximo capítulo. 3 Aumentando a Segurança para o Login Virtual Apenas configurando senhas de acesso não garante que outros tipos de ataques não sejam efetuados na tentativa de descobrir o usuário e senha do roteador, como por exemplo, um ataque de força bruta com um dicionário de usuários e senhas. Se você analisar essa situação o ataque acaba sendo similar a um DoS, pois serão feitas repetidas tentativas até o atacante descobrir o usuário e senha de acesso ao roteador. Um roteador pode ser configurado para reagir às repetidas tentativas de login, ao recusar os pedidos de login adicionais (bloqueio de login). Esta opção pode ser configurada por u m período de tempo, que é chamado de período de silêncio. Além disso, as tentativas de conexão legítimas podem ainda ser autorizadas durante um período de silêncio, configurando uma lista de controle de acesso (ACL) com os endereços que são conhecidos e liberados, por exemplo dos computadores de gerenciamento. Para habilitar a segurança avançada no processo de login você deverá configurar os seguintes parâmetros: 1. Atrasos entre sucessivas tentativas de login: Router# configure terminal ! ! item 1 – você determina o atraso (delay) em segundos sendo o padrão 1 seg ! Router(config)# login delay segundos

2. Entrar em shutdown se um ataque de DoS está sob suspeita: !item 2 – o primeiro comando determina o bloqueio e o segundo quem não deve passar por essa regra ! Router(config)# login block-for segundos attempts tentativas within segundos Router(config)# login quiet-mode access-class {acl-name | acl-number}

3. Geração de mensagens de log do sistema para registrar as tentativas login: ! item 3 – faz o log das tentativas de login que falham e tem sucesso ! Router(config)# login on-failure log [every login] Router(config)# login on-success log [every login]


   

 

 



   

    

   



Página 54

 

 

  


3.1 Exemplos Práticos 1) Configure o roteador para que ele bloqueie o login por 3 minutos se forem realizadas 6 tentativas de acesso em um prazo de 30 segundos. Router(config)# login block-for 180

attempts 6 within 30

Agora se houver uma quebra na regra de segurança o roteador bloqueará acesso por 180 segundos ou 3 minutos. Para que não haja problemas de acesso aos micros de gerenciamento que realmente são permitidos acesso você deve escolher os IP’s permitidos com uma ACL e utilizar o comando “login quiet mode” para definir os micros que poderão fazer o login mesmo com o roteador ainda em bloqueio. Isso será visto no exemplo 2. Existem dois momentos distintos nessa monitoração, o watch time ou tempo de vigília e o quiet mode ou modo de silêncio. O primeiro é quando está tudo normal e o roteador está monitorando os acessos, caso ele contabilize uma quebra na regra o roteador entra no quiet mode, ou seja, em bloqueio do acesso remoto. 2) Nesse exemplo a rede de gerenciamento é a 192.168.1.0/24 e deve ser toda liberada mesmo que a regra do item 1 tenha sido quebrada. Router(config)#access-list 1 permit 192.168.1.0 0.0.0.255 Router(config)# login quiet-mode access-class 1

Note que a amarração entre os IP’s selecionados e o comando é o número ou nome da ACL, nesse exemplo foi configurada uma ACL padrão numerada utilizando o número 1 como referência. Agora os micros de 192.168.1.1 a 192.168.1.254 terão acesso ao VTY mesmo com o timer de bloqueio ativo no roteador. Lembre que se esse comando não for configurado todo acesso remoto será bloqueado até o timer de 180 segundos finalizarem. 3) Agora vamos configurar o Login Delay, ou atraso para o login, o que auxilia a mitigar os ataques de dicionário ou Dictionary Attacks. Router(config)# login delay 3

O valor padrão é 1 segundo, agora vamos alterar para 3 segundos. 4) Agora vamos ativar a monitoração com o comando “logging”. Podemos logar as tentativas que obtiveram sucesso com o parâmetro “on-success” e as tentativas que falharam com o parâmetro “on-failure”. Se utilizarmos somente esses dois parâmetros se houver uma falha ela será logada, podemos alterar esse valor com o subcomando “every” que pode levar os números de 1 a 65.535 falhas consecutivas. Agora veja a seguir o comando para gravar os logins com ou sem sucesso que ocorram 5 vezes. Router(config)# login on-failure log every 5 Router(config)# login on-success log every 5

Uma configuração alternativa para gravar somente as falhas é o comando “security authentication failure rate qtde_falhas log”, por exemplo, se você quiser que a cada 10 falhas gere um log utilize o comando abaixo: R1(config)#security authentication failure rate 10 log


   

 

 



   

    

   



Página 55

 

 

  


Para verificar as tentativas de login e falhas utilize os comandos abaixo consecutivamente: 1. Show login 2. Show login failure Veja um exemplo da saída dos comandos a seguir. R1#show login No login delay has been applied. No Quiet-Mode access list has been configured. Router NOT enabled to watch for login Attacks R1#show login failure *** No logged failed login attempts with the device.*** R1#

3.2 Configuração de Banners Além dos comandos mostrados você deve ainda configurar uma mensagem legal para as tentativas de acesso ao roteador com o comando “banner”. Veja o comando abaixo onde o “d” é o caractere delimitador da mensagem. banner {exec | incoming | login | motd | slip-ppp} d message d Existem diversas opções para esse comando e a mais utilizada é a “banner motd”, o qual configura um banner do dia para os acessos locais e remotos. Veja a seguir a lista de subcomandos possíveis e a configuração do banner motd. R1(config)#banner ? LINE c banner-text c, where 'c' is a delimiting character exec Set EXEC process creation banner incoming Set incoming terminal line banner login Set login banner motd Set Message of the Day banner prompt-timeout Set Message for login authentication timeout slip-ppp Set Message for SLIP/PPP R1(config)#banner motd @ Enter TEXT message. End with the character '@'. ################################# Acesso Restrito a Area de TI Invasores sujeitos a penas Previstas em lei ################################# @ R1(config)# Veja abaixo como o banner aparecerá quando um usuário tentar acessor o router via console ou VTY: Press RETURN to get started. #################################


   

 

 



   

    

   



Página 56

 

 

  


Acesso Restrito a Area de TI Invasores sujeitos a penas Previstas em lei ################################# User Access Verification Username:

Para todos os banners a sintaxe é a mesma “banner” mais o tipo, por exemplo, “exec” e após um caractere delimitador, digite o texto, finalize com o caractere delimitador e está finalizada a config. No exemplo acima o @ foi utilizado como delimitador, porém poderia ser qualquer caractere. 3.3 Configurando o Acesso Remoto Via SSH O SSH representa aplicação e protocolo ao mesmo tempo, além de trabalhar de forma similar às ferramentas "r" Berkeley, como por exemplo o rsh e rexec. Atualmente existem duas versões do SSH: SSHv1 e SSHv2 as quais são suportadas pelos roteadores Cisco. O SSH, conforme será mostrado neste capítulo do curso oferece um serviço de criptografia para as sessões entre os usuários/administradores e roteadores. Resumindo, o SSH funcionará de forma similar ao Telnet, sendo a única diferença a criptografia da conexão. Como sabemos o Telnet não é recomendado em situações onde a segurança das senhas pode ser comprometida (em redes onde existem conexões não seguras), devido ao fato que o telnet envia as senhas em formato "clear text" através da rede, o que pode ser facilmente capturado por terceiros, através de ferramentas "sniffer" (CA Sniffer, Ethereal, etc). O SSH dos equipamentos Cisco é integrado com as formas de autenticação RADIUS ou TACACS+, e suporta Data Encryption Standard (DES), Triple DES (3DES), além da autenticação de senhas configuradas localmente no roteador. O SSH utiliza o protocolo TCP na porta 22 e o Telnet a porta 23, também do TCP. Abaixo seguem os comandos necessários para ativar o SSH. Siga os passos a seguir para aprender como configurar o SSH em roteadores Cisco. Passo 1. Configure o hostname e um usuário e senha para login. hostname DlteC Recomendável: os comandos abaixo criam um usuário e senha local para acesso. username dltec secret D1t3C@!

Passo 2. Configure o domínio da empresa. ip domain-name dltec.com.br


   

 

 



   

    

   



Página 57

 

 

  


Passo 3. Crie a chave para acesso seguro via SSH a ser utilizada. A opção “modulus” permite criar uma chave de 360 bits a 2048 bits, no exemplo abaixo foi criada uma chave de 1024 bits. crypto key generate rsa general-keys modulus 1024

Passo 4. Configure o timeout (tempo de espera do roteador pelo cliente) e o número de tentativas válidas para o acesso SSH. ip ssh time-out 60 ip ssh authentication-retries 2

Passo 5. Habilite o SSH nas lines VTY. line vty 0 4 transport input ssh login local

Passo 6. Opcionalmente configure a versão do SSH. !Configurando SSH v1: Router(config)#ip ssh version 1 !Configurando SSH v2: Router(config)#ip ssh version 2 !Configurando SSH v1 e v2: Router(config)#no ip ssh version

Você também pode zerar as chaves criadas anteriormente para o SSH caso seja necessário com o comando “crypto key zeroize rsa”. 3.4 Acessando um Roteador Cisco com Acesso Remoto Via SSH Para acessar um roteador ou switch via SSH você deverá utilizar um programa SSH Client, como por exemplo, o Putty. Para verificar as configurações e status utilize o comando “show ssh” e para iniciar uma conexão SSH a partir do roteador existe o comando “ssh” em modo privilegiado, conforme exemplo a seguir. DlteC-FW-GW#ssh ? -c Select encryption algorithm -l Log in using this user name -m Select HMAC algorithm -o Specify options -p Connect to this port -v Specify SSH Protocol Version -vrf Specify vrf name WORD IP address or hostname of a remote system DlteC-FW-GW#ssh 192.168.1.5 Password:


   

 

 



   

    

   



Página 58

 

 

  


3.5 Acessando o Cisco Configuration Professional e Configurando o SSH via Web-GUI O CCP é um software que vem instalado de fábrica em diversos roteadores, porém ele pode ser também instalado no seu computador, normalmente disponível em um CD-ROM ou disponível para download do site Cisco.com para roteadores novos. Para que o roteador seja acessível via CCP, tanto a versão expressa instalada na memória flash como pela versão desktop, algumas configurações prévias devem ser realizadas, segue abaixo a “receita de bolo”. Configurar uma senha de nível de privilégio 15 (root): username nome privilege 15 secret senha Ativar o HTTP

ip ip ip ip

http http http http

server:

server authentication local secure-server (for enabling HTTPS access to CCP) timeout-policy idle 600 life 86400 request 1000

Configurar a VTY para acesso via Telnet

e Secure Shell (SSH):

line vty 0 15 privilege level 15 login local transport input telnet ssh

Para acessar diretamente o roteador com CCP Express instalado apenas entre em seu browser e digite o IP do roteador, por exemplo, http://10.10.10.1. Para rodar o CCP instalado em seu laptop ou desktop de preferência inicie o programa em modo de administrador no Windows.

Se um atalho não estiver criado em seu desktop vá em “Start > Programs (All Programs) > Cisco Systems > Cisco CCP > Cisco CCP”. Clique no link abaixo para ver mais informações sobre o CCP. Esse é um vídeo da Cisco e está em inglês. http://www.static-cisco.com/assets/cdc_content_elements/embedded-video/video-datasheets/ccp-overview.swf


   

 

 



   

    

   



Página 59

 

 

  


3.5.1 Navegando no CCP e Ativando o SSH

As opções Home, Configure e Monitor são os botões que utilizaremos no dia a dia com o CCP. Eles aparecem na barra de botões superiores da tela do programa. Quando clicamos em Configure ou Monitor algumas opções são mostradas na barra lateral esquerda, as quais podem ser configuradas via “wizard”, ou seja, configuração facilitada e guiada estilo NNF do Windows (Next, Next, Finish).

Foram inseridas novas facilidades no Cisco Configuration Professional para quem administra ambientes de maior porte como Communities, Templates e User Profile s.  



Communities: grupos de dispositivos que tem algo em comum. Templates: permite aplicar as mesmas configurações básicas de acesso em outros equipamentos. User profiles: visualizações de GUI (views) que fornecem controle de acesso por função (role-based access control) para diversos administradores de rede.

Para se conectar a um roteador via CCP você pode adicionar uma Community ou simplesmente clicar em “Manager Devices” e inserir as informações do roteador a ser configurado. A seguir clique em Discover, após esse passo se o roteador estiver acessível ele pode ser configurado clicando no botão configure. Nesse passo uma mensagem de certificado digital pode ser mostrada quando configuramos pela primeira vez o dispositivo, essa mensagem é relacionada ao acesso SSH ou HTTPS. Para ativar o SSH basta clicar no botão Configure, escolher a opção “Router > Router Access > SSH”. Note que no exemplo da tela a seguir o SSH já está configurado, por isso o botão fica apagado. Você pode nesse mesmo menu configurar a VTY e contas de acesso (User Accounts/View).


   

 

 



   

    

   



Página 60

 

 

  


Veja o detalhe da tela VTY a seguir. Clicando em Edit você pode alterar as configurações da line VTY. As configurações básicas são bastante auto explicativas, porém teremos durante o curso vídeos específicos explicando as configurações e com exemplos práticos de uso do CCP.


   

 

 



   

    

   



Página 61

 

 

  


4 Configurando os Níveis de Acesso Administrativos Com o que configuramos até o momento você já deve ter notado que estamos trabalhando somente com dois níveis de acesso, o acesso de usuário, chamado de acesso de nível 1 (privilege access level 1), e um nível de acesso privilegiado que nos possibilita executar qualquer comando disponível no roteador, também conhecido como acesso nível 15. Os roteadores e switches Cisco possuem 16 níveis de privilégio, conforme abaixo: • Nível 0: predefinido para privilégios de acesso em nível de usuário. Raramente utilizado, mas inclui cinco comandos: enable, disable, exit, help e logout. • Nível 1: O nível padrão para o login com o roteador prompt Router>. Um usuário não pode fazer quaisquer alterações ou ler o arquivo de configuração. • Níveis 2 -14: Podem ser personalizados para os privilégios de usuário conforme necessidade. Comandos de níveis mais baixos podem ser movidos para outro nível mais elevado, ou comandos de níveis mais altos podem ser movido para baixo para um nível inferior. • Nível 15: reservado para o modo privilegiado (comando enable). Os usuários podem alterar as configurações e arquivos de configuração. É o root (Linux/Unix) ou administrador (Windows) do Cisco IOS. Embora com esses acessos consigamos trabalhar, em algumas empresas isso não se aplica, pois podemos ter funcionários de vários níveis que precisam de diferentes tipos de acesso para executar comandos específicos e outros não. Por exemplo, uma equipe de monitoração que precisa apenas dar comandos show e não executar alterações nos equipamentos, como resolvemos esse problema com apenas dois níveis de acesso? Para alterar o que cada nível de permissão pode ou não executar utilize o comando abaixo: Router(config)# privilege mode {level nível comando | reset} comando

Além disso, para implementar níveis de privilégios você deverá definir usuário/senha por nível de acesso. Vamos analisar um exemplo prático onde teremos os níveis 1, 5, 10 e 15. Os níveis 1 e 15 não terão nenhuma alteração, pois já tem sua definição de comandos. Já para o nível 5 permitiremos apenas o ping, enquanto para o nível 10 será permitido adicionalmente reload e comandos show. Veja a configuração a seguir. Router(config)#username Usuario privilege 1 secret dltec Router(config)#username Admin privilege 10 secret dltec10 Router(config)#username Root privilege 15 secret dltec15 Router(config)#privilege exec level 5 ping Router(config)#enable secret level 5 dltec5 Router(config)#username Suporte privilege 5 secret dltec5 Router(config)#privilege exec level 10 reload Router(config)#privilege exec level 10 show Router(config)#enable secret level 10 dltec10


   

 

 



   

    

   



Página 62

 

 

  


4.1 CLI Views – Níveis de Acesso por Usuário Local A administração de rede das organizações pode ter diversos administradores, e cada um deles pode ter diferentes tipos de acesso ou diferentes modos de visualização (views). Para criá-los, podemos usar os níveis de privilégio (visto no item anterior) ou o enable view.É de costume usar os níveis de privilégio, mas por este meio não temos o controle tão detalhado como no enable view. O view da CLI é uma feature do Cisco IOS, que permite ao administrador especificar exatamente quais comandos e interfaces um grupo de administradores terão acesso. O IOS permite 15 views diferentes em cada dispositivo. Root-View: Equivale ao privilégio exec nível 15. Quando o usuário se loga com este nível, a permissão para criação e manipulação das views é adicionada. Pré-requisitos para a criação das views: 1. Senha de "enable" (usada para logar na root view); 2. AAA habilitado no router/switch; 3. Logar-se na "root view", com a senha de enable; Acompanhe a seguir um exemplo de configuração de uma view chamada visitante. ! habilitando o AAA aaa new-model ! configurando senha do enable enable secret dltec end ! logando na root view. Aqui será pedida a senha de enable enable view configure terminal ! criando a view nomeada "visitante" parser view visitante ! antes de tudo, na view é necessária a configuração da senha secret cisco ! no modo de configuração global, a view dará acesso aos seguintes comandos: ! end commands configure include all end ! interface fastethernet0 commands configure include interface commands configure include all interface fastethernet0 ! no modo de configuração e acesso à interfaces, a view dará acesso aos seguintes comandos: ! fastethernet (acesso somente à esta interface) commands interface include all fastethernet ! e o número da interface (para ser reconhecido pela CLI) commands interface include all 0 ! no modo exec, qualquer comando iniciado com: ! telnet commands exec include all telnet ! comando logout commands exec include all logout ! debug icmp, apenas nesta view. Parâmetro especificado pelo comando "includeexclusive" commands exec include-exclusive debug ip icmp ! entrada ao modo de configuração global commands exec include configure terminal ! undebug commands exec include all undebug


   

 

 



   

    

   



Página 63

 

 

  


! e show ip interface brief commands exec include show ip interface brief end copy run start

Para testarmos a view visitante, devemos logar nela, usando o comando “enable view visitante”. Será pedida a senha, e o login será efetuado com sucesso. A partir daí, estarão presentes somente os comandos acima especificados. Feita a configuração, o output do show running-config será como o mostrado a seguir. Router#show run | begin parser parser view visitante secret 5 $1$yI7R$kSW4QghsnDJnFVWgVrbGY/ commands configure include all end commands configure include interface commands exec include all telnet commands exec include configure terminal commands exec include configure commands exec include-exclusive undebug ip icmp commands exec include undebug ip commands exec include all undebug commands exec include show ip interface brief commands exec include show ip interface commands exec include show ip commands exec include show commands exec include all logout commands exec include-exclusive debug ip icmp commands exec include debug ip commands exec include debug commands configure include all interface FastEthernet0 ! ! end Router#

Observe que alguns comandos não colocados em nossa configuração aparecem, pois estes são inclusos automaticamente, como por exemplo, "show ip interface brief ". No capítulo a seguir você vai estudar como fazer a autorização de comandos via AAA, porém aí precisaremos de um servidor externo para validar se o comando pode ou não ser executado.


   

 

 



   

    

   



Página 64

 

 

  


5 Segurança dos Arquivos de IOS e Configuração O Cisco IOS permite que um administrador faça uma cópia de segurança do sistema operacional ou IOS e do arquivo de configuração, podendo ser armazenado em um local escondido no roteador. Este recurso é chamado Cisco IOS Resilient Configuration. O sistema de arquivos é chamado bootset. Além disso, o comando “no service password-recovery” pode ser utilizado para bloquear o processo de recuperação de senha em um roteador. Para recuperar um dispositivo ao qual foi aplicado o comando acima você deve iniciar a sequência de break dentro de cinco segundos depois do início da descompactação da imagem de IOS durante o boot, porém será solicitado para confirmar o control+break digitado. Após a ação for confirmada, a configuração de inicialização é completamente apagada e o processo de recuperação de senha será ativado novamente. Caso você não confirmar a ação de interrupção, o processo de recuperação de senha será bloqueado. Siga os passos abaixo para criar uma cópia de segurança da configuração e imagem de IOS: 1. Comando “secure boot–image”- deve ser utilizado em modo de configuração global e protege a imagem do Cisco IOS ocultando seu nome para que ela não seja listada nos diretórios quando comandos para visualização de arquivos forem dados, como por exemplo, “show version” ou “show flash” ou “dir flash”. 2. Comando “secure boot-config” - também executado a partir do modo de configuração global, grava o conteúdo da running-config em um local seguro e escondido, chamado “persistent storage”, o qual não pode ser a memória flash, DRAM ou NVRAM do roteador. 3. Verifique a configuração usando o comando show secure bootset. 6 Reforçando a Segurança no Gerenciamento e Report A capacidade de ter um canal seguro de comunicações para fins de gerenciamento e reporte é essencial para o funcionamento da rede. Os administradores precisam e esperam ter uma comunicação segura entre o roteador e o sistema de gerência, sem o risco de expor nomes de usuários e senhas em texto claro. Além disso, os protocolos utilizados para gerenciamento podem servir se mal configurados, de mais uma fonte de informações para usuários mal intencionados ou invasores externos. Por esse motivo vamos aprender nesse capítulo a configurar o Syslog, o SNMP e o Network Time Protocol support (NTP). O gerenciamento de redes pode ter duas abordagens básicas, podendo ser: • Out-of-band (OOB) - Os fluxos de informação de gerenciamento passam por uma rede dedicada em que não há tráfego de produção, ou seja, o fluxo de gerenciamento está isolado. • In-band - Os fluxos de informação passam junto com os dados da rede de produção da empresa, na Internet, ou ambos, usando os mesmos canais de dados. Na figura a seguir você pode notar que foram criadas duas redes, uma para dados (In-band) e outra para gerenciamento (Out-of-band) isolado dos dados dos usuários ou do ambiente de produção da empresa.


   

 

 



   

    

   



Página 65

 

 

  


O gerenciamento fora da banda (OOB) é com certeza muito mais seguro, porém exige uma rede isolada, o que para empresa de um porte menor torna-se inviável financeiramente. A melhor solução para empresas menores é o gerenciamento dentro da banda (in-band) e utilizar protocolos seguros como SSH ao invés do Telnet e informações sensíveis deve ser transmitidas utilizando canais seguros, como por exemplo, um túnel IPSEC. 7 Configurando o Sysylog em Roteadores Cisco Mensagens de Syslog são geralmente mensagens de log de uma variedade de dispositivos de rede e hosts. Estes hosts e dispositivos de rede são definidos como clientes Syslog porque eles são os únicos a enviar informações para um servidor Syslog. Um cliente Syslog usa a porta UDP 514 para se comunicar com o servidor Syslog.


   

 

 



   

    

   



Página 66

 

 

  


Estas mensagens de log permitem aos administradores analisar acontecimentos do passado para obter informações que serão utilizadas na identificação de problemas, responder aos eventos de segurança e solução de problemas gerais. Isso é importante em um ambiente de rede porque os roteadores Cisco possuem uma quantidade limitada de espaço de buffer para armazenar mensagens de log. Espaço de buffer é outro termo para a quantidade de RAM que está alocado para as mensagens de log. Conforme a quantidade de mensagens que você está recebendo o buffer pode encher e sobrescrever os dados mais antigos. Por isso, é melhor ter um ou mais servidores Syslog externos configurados para receber as mensagens de log. O envio de mensagens de log para um servidor externo não é apenas boa prática, muitas vezes é necessário para fins de cumprimento de normas legais ou empresariais (compliance). No atual ambiente de segurança torna-se uma obrigação! As mensagens de log podem ser enviadas para a console, linha virtual VTY, Syslog, Buffer ou para um agente SNMP. Por padrão as mensagens ficam no buffer e são enviadas para a linha de console, lembre das mensagens que aparecem de vez em quando ao configurar um roteador. Na linha VTY para as mensagens serem exibidas você deve executar o comando “terminal monitor”, pois por padrão ele vem desabilitada (terminal no monitor). A seguir estão listados os níveis de severidade dos registros de acordo com a Cisco e uma descrição deles. Dependendo de quais tipos de informações você está interessado em reportar, você tem a opção de escolher exatamente o nível que você precisa. • 0 ou emergencies—System is unusable (sistema comprometido) • 1 ou alerts—Immediate action needed (ação imediata requerida) • 2 ou critical—Critical conditions (condição crítica) • 3 ou errors—Error conditions (condição de erro) • 4 ou warnings—Warning conditions (alertas) • 5 ou notifications—Normal but significant conditions (aviso normal, porém importante) • 6 ou informational—Informational messages (mensagens informacionais) • 7 ou debugging—Debugging messages (mensagens de debug) Deve-se notar que na escolha de um nível de severidade as mensagens dos níveis anteriores serão mostradas, por exemplo, escolhendo o nível 4 também inclui as mensagens dos níveis 3, 2, 1 e 0. Nos momentos em que você está tentando solucionar um problema, você pode querer usar uma depuração mais avançado para obter as mensagens de log mais detalhadas. A informação gerada pelo syslog tem três partes distintas: • Timestamp: quando ocorreu o aviso. • Mensagem de log e sua severidade. • Descrição da mensagem.


   

 

 



   

    

   



Página 67

 

 

  


7.1 Configurando o Syslog A maior dificuldade para o uso do syslog é correlacionar os eventos reportados com as situações de problemas ou segurança que estão ocorrendo, pois tratar as informações de todos os equipamentos que estão enviando mensagens é uma tarefa difícil, diríamos quase impossível de ser realizada por um operador. Uma opção disponibilizada pela Cisco é o equipamento Cisco Security Monitoring, Analysis, and Response System (MARS), o qual tem a função de analisar logs de diversos dispositivos, Cisco e não Cisco, fazendo uma análise de correlação de eventos baseada em um banco de dados de regras, o qual enviará um aviso em caso de risco de ataques ou outras situações consideradas como um ataque. A configuração do Syslog é bastante simples, basta definir o IP do servidor de Syslog. As demais configs mostradas são para fazer um ajuste fino, melhorando o desempenho e segurança do serviço. Vamos mostrar na prática a configuração do syslog em um roteador Cisco. Exemplo prático: o objetivo é ativar o syslog no roteador com nome 7200_R1 que deverá utilizar a Gigabit Ethernet 0/0 como interface de origem para envio dos logs e o servidor de Syslog está no IP 10.0.0.1. Além disso, vamos enviar mensagens em nível informacional. Etapa 1: ativando o syslog e configurando o IP do servidor. 7200_R1#config term 7200_R1(config)#logging on 7200_R1(config)#logging host 10.0.0.1

Etapa 2: configurando a interface de origem para envio dos logs. 7200_R1(config)#logging source-interface giga 0/0

Etapa 3: configurando o nível do log. 7200_R1(config)#logging trap informational

Para executar a mesma configuração via CCP siga o caminho “ Configure > Router > Logging” e insira as informações necessárias conforme projeto. Além disso, o CCP possui um monitor de logs para você verificar as informações enviadas para o Syslog em “Monitor > Router > Logging”.


   

 

 



   

    

   



Página 68

 

 

  


8 Configurando o SNMP de Maneira Segura O Simple Network Management Protocol (SNMP) é o protocolo mais utilizado para gerenciar dispositivos de rede, computadores e servidores atualmente. Foi introduzido através da versão 1 em uma série de RFCs no ano de 1988. Desde então passou por duas grandes revisões e sua versão mais atual é a 3. O SNMP versão 1 (SNMPv1) e SNMP versão 2 (SNMPv2) baseiam-se em estações de gerenciamento (sistemas de gerenciamento de rede [NMSs]), os agentes (nós gerenciados), e as Bases de Informação de Gerenciamento (MIBs). Em qualquer configuração, pelo menos um nó do gerenciador possui um software de gerenciamento SNMP. Os dispositivos de rede que precisam ser gerenciados, como switches, roteadores, servidores e estações de trabalho, são equipados com um módulo de software agente SMNP. O agente é responsável por fornecer acesso à MIB que reflete os recursos e as atividades em seu nó. As MIBs possuem informações sobre a operação do dispositivo e estão disponíveis para usuários remotos autenticados. O gerente SNMP pode obter informações (Get) do agente, assim como alterar ou inserir informações do agente (Set). Pode também alterar as variáveis de configuração no agente. Os Traps SNMP permitem que um agente notifique à estação de gerenciamento sobre eventos significativos, como problemas e alarmes, através do envio de uma mensagem SNMP não solicitadas, chamadas traps. As ações de Get e Set são as vulnerabilidades do SNMP, permitindo ataques e coleta de informações sobre a rede.

8.1 Versões do SNMP Ao contrário do SNMP v1 e v2c, SNMP v3 fornece um meio de comunicação seguro entre o gerente e o agente. A ideia de um modelo de segurança é um dos conceitos que não existia nas versões anteriores do SNMP. O modelo de segurança do SNMP v3 inclui autenticação em nível de usuário e grupo. Veja abaixo as três opções de configuração do SNMPv3. • noAuthNoPriv ou noAuth: sem autenticação ou criptografia, este é o nível disponível no SNMP V1 e V2c. Utiliza apenas Community string como segurança. • authNoPriv ou Auth: com autenticação e sem privacidade, fornece autenticação na forma de hash como HMAC MD5 ou HMAC SHA mas sem criptografia para privacidade. • authPriv ou Priv: com autenticação e privacidade, além de fornecer a autenticação observado anteriormente, fornece criptografia como DES, 3DES ou AES.


   

 

 



   

    

   



Página 69

 

 

  


8.2 Configurando o SNMP via CCP Para configurar o SNMP utilizando o CCP abra o programa e vá em “ Configure > Router > SNMP” depois clique no botão Edit. Existem dois tipos de strings de gerenciamento a Read-only (somente leitura) e a Read-Write (leitura e escrita). Esses strings de comunidade devem ser as mesmas configuradas nos servidores SNMP ou gerentes quando utilizamos a versão 1 ou 2c. Depois de inserir as communities strings você deve configurar o IP do gerente SNMP ou Servidor, às vezes chamado de NMS (network management server) que receberão as traps ou mensagens SNMP. Além disso, na mesma tela você pode definir a localização do equipamento (device location) e o contato do administrador de redes (adnministrator contact). A configuração via CLI já foi abordada no material do CCNA R&S e CCENT, por isso não entra nesse tópico. 9 Configurando o NTP – Network Time Protocol Primeiramente, um servidor NTP (Network Time Protocol) é utilizado como fonte de relógio, ou seja, os outros equipamentos da rede, através do protocolo NTP, sincronizam seus relógios com o do servidor NTP. O NTP utiliza a porta UDP 123 e está documentado no RFC 1305. O processo de configuração do seu roteador ou switch Cisco para utilização de um servidor NTP é muito simples. Para ativar esta cofiguração em roteadores ou switches Cisco, entre com os comandos abaixo: Router# conf t Router(config)# ntp server 192.168.15.10

Você pode configurar múltiplos servidores para agregar redundância neste serviço, no exemplo mostrado ao lado, estamos usando um servidor na rede interna e outro na internet (187.49.33.15 - 1.fedora.pool.ntp.org). Outra configuração importante é o ajuste do time zone do equipamento. O UTC já é o padrão. Router# conf t Router(config)# ntp server 192.168.15.10 Router(config)# ntp server 187.49.33.15 Router(config)# clock timezone utc -3

Você também pode configurar a autenticação e criptografia com MD-5 para o NTP conforme mostrado a seguir. O número da chave deve ser o mesmo nos comandos da linha 2 e 3. Router(config)# ntp authenticate Router(config)# ntp authentication-key 1 md5 dltec@! Router(config)# ntp trusted-key 1


   

 

 



   

    

   



Página 70

 

 

  


9.1 NTP via CCP Para fazer a configuração do NTP via CCP entre em Configure > Router > Time > NTP and SNTP e clique em Add para adicionar um servidor NTP. Nessa tela você pode adicionar o IP do servidor NTP e marcar o principal com o checkbox “Prefer”, depois escolher a interface de origem e configurar a autenticação e criptografia, quando aplicável. 9.2 Ajuste Manual – Clock Set e via CCP Outra maneira de acertar a data e hora do roteador é manualmente com o comando “clock set”, veja um exemplo de configuração a seguir. Router# clock set 22:55:05 June 19 2006

Para verificar as configurações de clock utilize o comando abaixo. Router# show clock detail 22:56:07.136 PDT Mon Jun 19 2006 Time source is user configuration

É importante essa informação de tempo para o correto registro dos logs que estudamos anteriormente, pois senão o roteador irá gerar as mensagens com datas erradas. Essa deve ser uma das primeiras etapas de configuração dos roteadores e switches Cisco. Via CCP você tem o ajuste da hora com o laptop ou desktop de gerenciamento em Configure > Router > Time > Date and Time, clicando depois em “Change Settings” e escolhendo a opção “Synchronyze with my local PC clock”. 10 Realizando a Auditoria de Segurança via CCP É importante para um administrador de redes saber se existem pontos de falhas ou riscos de segurança em sua rede, pois nos roteadores e switches Cisco temos diversos serviços e portas habilitadas ou desabilitadas por padrão, o qual é uma comodidade para o operador. Um exemplo de serviço padrão que pode representar um risco à segurança é o CDP, pelo qual um invasor pode descobrir diversas informações dos equipamentos, tais como hostname, IP’s, modelo de hardware e software. Em alguns casos ele é fundamental, porém como dito anteriormente o administrador de redes deve estar ciente que ele está rodando na rede e o risco que isso representa. Temos basicamente três ferramentas para auxiliar o administrador de redes: 1. Security Audit Wizard - um recurso de auditoria de segurança do Cisco CCP, o qual fornece uma lista de vulnerabilidades e em seguida dá a opção do administrador escolher quais os possíveis riscos devem ser alterados na configuração do roteador. Você encontra em Configure > Security > Security Audit > Security Audit. 2. Cisco AutoSecure - um recurso de auditoria de segurança disponível através do Cisco IOS CLI. O comando autosecure inicia uma auditoria de segurança e permite mudanças de configuração. Com base no modo selecionado as alterações de configuração podem ser automáticas ou exigir intervenção do administrador de rede.


   

 

 



   

    

   



Página 71

 

 

  


3. One-Step Lockdown - um recurso de auditoria de segurança do Cisco CCP, o qual bloqueia uma lista de vulnerabilidades e faz automaticamente todas as alterações recomendadas relacionadas à segurança diretamente na configuração do roteador. Você encontra em Configure > Security > Security Audit > One Step Lockdown. 10.1 Security Audit Wizard - CCP O Security Audit Wizard compara a configuração do roteador com as configurações recomendadas e executa as seguintes verificações: • Desliga servidores desnecessários. • Desativa serviços desnecessários. • Aplica o firewall para as interfaces externas. • Desativa ou melhora a segurança do SNMP. • Desliga interfaces não utilizadas. • Verifica se as senhas são seguras. • Reforça o uso de ACLs. Quando uma Security Audit Wizard é iniciada, o assistente deve saber quais interfaces do roteador se conectam à rede interna e quais se conectam com a Internet. Em seguida ele inicia os testes da configuração do roteador para determinar possíveis problemas de segurança que possam existir. Uma janela mostra todas as opções de configuração testadas e se a configuração atual do roteador passou nos testes. Quando a auditoria for concluída, a Security Audit identifica possíveis vulnerabilidades na configuração e fornece uma tela para correção (fix) desses problemas. Ela também dá ao administrador a opção para corrigir problemas automaticamente. No final a lista de comandos utilizados na correção dos problemas será mostrada. Antes de qualquer mudança de configuração é exibida uma página de resumo com a lista de todas as alterações de configuração que o Security Audit realizou. O administrador deve clicar em Concluir/Finish para enviar as configurações ao roteador. 10.2 Cisco Autosecure - CLI Já o Cisco Autosecure é um comando que deve ser executado na CLI do roteador. Ele tem quase a mesma funcionalidade que o One-Step Lockdown do CCP, porém mais tarde veremos a diferença entre eles. Essa facilidade foi lançada na versão 12.3 do IOS da Cisco, veja o comando sendo executado a seguir. DlteC-FW-GW#auto firewall forwarding full login management no-interact ntp ssh tcp-intercept

secure ? AutoSecure Firewall Secure Forwarding Plane Interactive full session of AutoSecure AutoSecure Login Secure Management Plane Non-interactive session of AutoSecure AutoSecure NTP AutoSecure SSH AutoSecure TCP Intercept

DlteC-FW-GW#


   

 

 



   

    

   



Página 72

 

 

  


O padrão de execução se você não colocar nenhum comando adicional, ou seja, digitar somente auto secure, é o interativo, onde prompts serão mostrados para que o administrador de redes escolha o que deve ou não ser bloqueado. Você pode escolher um modo não interativo com o operando “no-interact”, deixando que a rotina bloqueie todos os serviços considerados riscos de segurança. Existem vários serviços de gerenciamento e funções que são analisadas e bloqueadas pelo Auto Secure: • BOOTP, CDP, FTP, TFTP, PAD, UDP, TCP small servers, MOP, ICMP (redirecionamentos, máscara de respostas), IP source routing, Finger, criptografia de senha, keepalives, ARP gratuito, proxy ARP e broadcast dirigido. • Notificação legal através de um banner. • Senhas e login. • Secure NTP. • Acesso SSH. • Serviços de interceptação via TCP . Além disso, há três serviços de encaminhamento que são alterados: • Habilita o CEF • Permite a filtragem de tráfego com ACLs • Implementa Cisco IOS firewall para inspeção de protocolos comuns O AutoSecure é frequentemente utilizado na prática para fornecer uma baseline (linha mestra) de política de segurança em um novo roteador, podendo ser alterado para entrar em conformidade com a política de segurança da organização. 10.3 Aplicando o Autosecure Agora vamos analisar passo a passo a aplicação do comando Auto Secure em um roteador. Você vai notar que grifamos algumas partes do texto onde os prompts foram lançados para escolha do administrador. Tudo se inicia com uma mensagem geral sobre o auto secure e como utilizá-lo. Após isso você terá que informar se o roteador tem ou não conexão com a Internet e dizer que Interface ela está conectada. Note que houveram 3 tentativas até a interface ser aceita, recomendamos escrever o nome igual ao resumo de interfaces mostrado. Na sequência você terá que configurar o banner com seu aviso legal de acesso restrito ao roteador, após isso alterar a senha de enable utilizando uma senha segura. Também na sequência alguns prompts serão mostrados para configurar o bloqueio em caso de falhas nas tentativas de acesso e ataques de DoS e dicionário estudados anteriormente. Em seguida virá a configuração do SSH, lembre-se que seu IOS deve suportar essa facilidade, e por último a configuração a ser alterada será exibida e uma pergunta se você quer aplicá-la no seu roteador será mostrada, finalizando o processo. Verifique que vários serviços serão desabilitados, tais como CDP, NTP e SNMP, por isso você terá que analisar o que realmente precisa estar ou não habilitado em sua rede para não bloquear serviços que deveriam estar ativos.


   

 

 



   

    

   



Página 73

 

 

  


R1#auto secure --- AutoSecure Configuration --*** AutoSecure configuration enhances the security of the router, but it will not make it absolutely resistant to all security attacks *** AutoSecure will modify the configuration of your device. All configuration changes will be shown. For a detailed explanation of how the configuration changes enhance security and any possible side effects, please refer to Cisco.com for Autosecure documentation. At any prompt you may enter '?' for help. Use ctrl-c to abort this session at any prompt. Gathering information about the router for AutoSecure Is this router connected to internet? [no]: yes Enter the number of interfaces facing the internet [1]: 1 Interface IP-Address OK? Method Status Protocol FastEthernet0/0 10.0.0.1 YES NVRAM up up FastEthernet0/1 unassigned YES NVRAM administratively down down Serial1/0 unassigned YES NVRAM administratively down Serial1/1 unassigned YES NVRAM administratively down Serial1/2 unassigned YES NVRAM administratively down Serial1/3 unassigned YES NVRAM administratively down Enter the interface name that is facing the internet: fast 0/0 Invalid interface name Enter the interface name that is facing the internet: FastEthernet 0/0 Invalid interface name Enter the interface name that is facing the internet: FastEthernet0/0

down down down down

Securing Management plane services... Disabling service finger Disabling service pad Disabling udp & tcp small servers Enabling service password encryption Enabling service tcp-keepalives-in Enabling service tcp-keepalives-out Disabling the cdp protocol Disabling Disabling Disabling Disabling Disabling

the bootp server the http server the finger service source routing gratuitous arp

Here is a sample Security Banner to be shown at every access to device. Modify it to suit your enterprise requirements. Authorized Access only This system is the property of So-&-So-Enterprise. UNAUTHORIZED ACCESS TO THIS DEVICE IS PROHIBITED. You must have explicit permission to access this


   

 

 



   

    

   



Página 74

 

 

  


device. All activities performed on this device are logged. Any violations of access policy will result in disciplinary action. Enter the security banner {Put the banner between k and k, where k is any character}: @ ####################################### AMBIENTE RESTRITO E ACESSO NAO AUTORIZADO, PUNICOES CONFORME LEIS VIGENTES ####################################### @ Enter the new enable password: Confirm the enable password: Configuring AAA local authentication Configuring Console, Aux and VTY lines for local authentication, exec-timeout, and transport Securing device against Login Attacks Configure the following parameters Blocking Period when Login Attack detected: 120 Maximum Login failures with the device: 10 Maximum time period for crossing the failed login attempts: 40 Configure SSH server? [yes]: yes Enter the domain-name: dltec.com.br Configuring interface specific AutoSecure services Disabling the following ip services on all interfaces: no no no no no

ip ip ip ip ip

redirects proxy-arp unreachables directed-broadcast mask-reply

Securing Forwarding plane services... Enabling CEF (This might impact the memory requirements for your platform) Enabling unicast rpf on all interfaces connected to internet This is the configuration generated: no service finger no service pad no service udp-small-servers no service tcp-small-servers service password-encryption service tcp-keepalives-in service tcp-keepalives-out no cdp run


   

 

 



   

    

   



Página 75

 

 

  


no ip bootp server no ip http server no ip finger no ip source-route no ip gratuitous-arps banner motd ^C #######################################^C security passwords min-length 6 security authentication failure rate 10 log enable password 7 05080F1C22431F5B4A5142 aaa new-model aaa authentication login local_auth local line con 0 login authentication local_auth exec-timeout 5 0 transport output telnet line aux 0 login authentication local_auth exec-timeout 10 0 transport output telnet line vty 0 15 login authentication local_auth transport input telnet login block-for 120 attempts 10 within 40 ip domain-name dltec.com.br crypto key generate rsa general-keys modulus 1024 ip ssh time-out 60 ip ssh authentication-retries 2 line vty 0 15 transport input ssh telnet service timestamps debug datetime msec localtime show-timezone service timestamps log datetime msec localtime show-timezone logging facility local2 logging trap debugging service sequence-numbers logging console critical logging buffered interface FastEthernet0/0 no ip redirects no ip proxy-arp no ip unreachables no ip directed-broadcast no ip mask-reply interface FastEthernet0/1 no ip redirects no ip proxy-arp no ip unreachables no ip directed-broadcast no ip mask-reply interface Serial1/0 no ip redirects no ip proxy-arp no ip unreachables no ip directed-broadcast no ip mask-reply interface Serial1/1 no ip redirects no ip proxy-arp no ip unreachables no ip directed-broadcast


   

 

 



   

    

   



Página 76

 

 

  


no ip mask-reply interface Serial1/2 no ip redirects no ip proxy-arp no ip unreachables no ip directed-broadcast no ip mask-reply interface Serial1/3 no ip redirects no ip proxy-arp no ip unreachables no ip directed-broadcast no ip mask-reply ip cef access-list 100 permit udp any any eq bootpc interface FastEthernet0/0 ip verify unicast source reachable-via rx allow-default 100 ! end

Apply this configuration to running-config? [yes]: yes Applying the config generated to running-config The name for the keys will be: R1.dltec.com.br % The key modulus size is 1024 bits % Generating 1024 bit RSA keys, keys will be non-exportable...[OK] R1#

10.4 One-step Lock-down - CCP A terceira maneira disponibilizada para manter seu equipamento seguro através de um wizard é utilizando a ferramenta de Lock-down. O lock-down desabilitará os seguintes serviços: • Finger service • PAD service • TCP small servers service • UDP small servers service • IP BOOTP server service • IP identification service • Cisco Discovery Protocol • IP source route • IP GARPs

• SNMP • IP redirects • IP proxy ARP • IP directed broadcast • MOP service • IP unreachables • IP mask reply • IP unreachables em interfaces null

Além disso, ele habilitará: • Password encryption – criptografia das senhas em modo texto • TCP keepalives para sessões Telnet (entrantes e saintes) • Números de sequência e timestamps nos debugs • IP Cisco Express Forwarding Enable NetFlow switching • Unicast Reverse Path Forwarding (RPF) em Interfaces de saída • Firewall em todas Interfaces de saída • SSH • AAA A p o s t i l a / E - Bo o k d o C u r s o I I N S 6 4 0 - 5 5 4      

   

 

 



   

    

   



Página 77

 

 

  


E por último irá alterar os seguintes parâmetros: • Tamanho mínimo da senha para seis caracteres • Menos de três tentativas para considerar falha de autenticação • Temporização do TCP synwait • Banner de notificação • Parâmetros de registro • Senha secreta • Scheduler • Scheduler allocate • Usuários • Configurações Telnet • Acess class no servidor HTTP • Acess class em linhas vty Note que o One-step Lockdown do CCP não implementa todas as facilidades do comando auto secure e também algumas facilidades no CCP foram implementadas de maneira diferente, portanto analise qual a melhor opção de acordo com a política de segurança da sua corporação. 11 E para o IPv6? Continua a mesma coisa? Uma das vantagens do IPv6 em relação ao IPv4 em termos de segurança é que o IPsec é mandatório para implementações em todos os dispositivos, o que protege a comunicação fim a fim entre hosts e dispositivos de rede, porém ele deve ser ativado para que funcione corretamente. Apesar disso, sabemos que os riscos de segurança não são resolvidos apenas criptografando e criando túneis VPN entre hosts ou unidades de uma empresa, pois muitas das vulnerabilidades do ambiente de rede IPv6 são as mesmas ou senão semelhantes a que encontramos no IPv4. Existem vulnerabilidades e riscos exclusivos do IPv6 que são novos, por exemplo: Treinamento da equipe de suporte e operação. O IPv6 não prevê o uso de endereçamento privativo e NAT na Internet, por isso os nós de rede estarão mais expostos. Cabeçalhos novos no protocolo IPv6 chamados de “Extension Headers” vulneráveis a ataques diversos. O ICMP versão 6 utiliza bastante multicast, pois no IPv6 não temos mais broadcast. Riscos relacionados ao tunelamento e mecanismos de convivência e transição IPv4/IPv6. Riscos relacionados ao dual-stack (configurar IPv4 e IPv6 na mesma rede). Riscos relacionados ao endereçamento dinâmico no IPv6 (SLAAC e DHCPv6), etc.  



   

Recomendações práticas para reforçar a segurança em redes IPv6: Aplicar filtros de entrada (ACL – suportada por roteadores e alguns switches). Reforçar a segurança em protocolos utilizados na transição IPv4/IPv6, preferencialmente utilizar dual stack. Controlar o uso de túneis como método de transição. Considerar melhorias atuais e futuras na segurança da rede IPv6.  

 

Em termos de proteger o acesso a um roteador com IPv6 configurado podemos utilizar o SSH e HTTPS como acesso remoto, pois ambos os protocolos são suportados pelo IPv6 em diversos roteadores e switches, porém em switches há uma limitação maior dos recursos para IPv6 em versões mais antigas de equipamento e Cisco IOS. Já as configurações gerais, como senhas, parser view, SSH, banners, etc. continuam as mesmas!


   

 

 



   

    

   



Página 78

 

 

  


12 Resumo do Capítulo Bem pessoal, chegamos ao final do capítulo. É muito importante que nesse ponto do curso você tenha domínio dos seguintes itens: Como proteger o acesso administrativo em roteadores Cisco (senhas criptografadas, exec timeout, limitando erros de login e melhorias na segurança para o login no IOS da Cisco). Configurar múltiplos níveis de privilégio em roteadores Cisco. Configurar o “role based CLI” para proteger acesso administrativo em roteadores Cisco. Proteger a imagem do Cisco IOS e o arquivo de configuração. Utilizar CLI e CCP para configurar o SSH em roteadores Cisco para permitir o acesso remoto seguro Configurar o Syslog via CLI e CCP. Como utilizar o recurso de Auditoria de Segurança do CCP para proteger roteadores. Como utilizar o One-Step Lockdown do CCP para proteger um roteador Cisco. 

   

  


   

 

 



   

    

   



Página 79

 

 

  


Capítulo 4 - Conceitos e Configurações do AAA Nesse capítulo estudaremos os conceitos e configuração do AAA em roteadores Cisco.

Objetivos do Capítulo Ao final desse capítulo você terá estudado e deverá compreender: Explicar as funções e importância do AAA (Autenticação, Autorização e Auditora). Descrever as características do TACACS + e protocolos RADIUS. Configuração da autenticação. Configuração da autorização. Configuração da auditoria ou contabilidade (accounting).

Também estudaremos os conceitos de como utilizar banco de dados locais e externos com ACS e a ferramenta gratuita para testes TAC PLUS durante os laboratórios.





  



   

 

 



   

    

   



Página 80

 

 

  


Sumário do Capítulo 1

Introdução ______________________ 82

2

Introdução ao AAA e sua Importância 82

3 Configurando o AAA com Base de Dados Local ______________________________ 84

3.1

Verificando as Configurações_______ 86

3.2

Configuração via CCP _____________ 88

4 AAA Baseado em Servidor – Autenticação________________________ 89

4.1

Visão Geral do TACAS+ e RADIUS ___ 90

4.2 CLI

Configurando o TACACS+ e RADIUS via 92

4.3 CCP

Configurando o TACACS+ e RADIUS via 94

4.4 Verificando as Configurações com Autenticação via Servidor _______________ 94 5 Configurando a Autorização (Authorization) e Auditoria (Accounting) Baseada em Servidor _________________ 95

5.1 Configurando a Autorização (Authorization) Baseada em Servidor _____ 96 5.2

Configurando Autorização via CCP __ 97

5.3 Configurando a Auditoria (Accounting) Baseada em Servidor___________________ 97 6

Cisco Secure ACS _________________ 99

6.1

Dicas de Configuração do ACS _____ 101

7

Cisco ISE _______________________ 102

8

Resumo do Capítulo ______________ 102


   

 

 



   

    

   



Página 81

 

 

  


1

Introdução

Em segurança da informação, o termo protocolos AAA é uma referência aos protocolos relacionados com os procedimentos de autenticação, autorização e auditoria. A autenticação verifica a identidade digital do usuário de um sistema, a autorização garante que um usuário autenticado somente tenha acesso aos recursos autorizados e, por fim, a auditoria refere-se a coleta de informações sobre o uso dos recursos de um sistema pelos seus usuários. Em roteadores Cisco que rodam IOS podemos configurar o AAA para acesso a um banco de dados de usuário local e senha. Usando um banco de dados local para nomes de usuário e senha você consegue dar um nível a mais de proteção se comparado com termos apenas uma senha local. Além disso, podemos configurar o AAA nos roteadores para acessar um Cisco Secure Access Control Server (ACS), por exemplo. O Cisco ACS é uma plataforma escalável, onde todos os dispositivos de infraestrutura de rede passam a acessar um servidor central de AAA, podendo ser configurado de forma redundante para evitar interrupção no serviço. Normalmente essa solução é implementada apenas por grandes organizações.

2

Introdução ao AAA e sua Importância

O AAA oferece uma forma para a autenticação de usuários em servidores ou dispositivos de conectividade (router, switch, etc), além de controlar o nível de acesso destes usuários para os recursos desejados.


   

 

 



   

    

   



Página 82

 

 

  


Este componente permite, também, o registro de cada comando inserido em um terminal, onde tudo o que for executado pelo usuário será armazenado em arquivos para consultas ou auditorias futuras por parte dos administradores da rede. Para que isto seja possível, o AAA participa em três etapas durante todo este processo: 1. Autenticação de usuários: Com o AAA, é possível centralizar o gerenciamento de todas as contas de usuários e respectivas senhas, facilitando bastante o trabalho do administrador da rede. O administrador da rede poderá especificar diversos mecanismos para a autenticação de usuários, entre eles RADIUS, TACACS+ ou Kerberos e, para que isto ocorra, a ordem de execução destes componentes deverá ser informada e devidamente associada para uma interface ou mais interfaces do equipamento de rede. Por exemplo, um usuário que necessita configurar uma rota em um roteador Cisco poderá informar o seu username e password para o acesso ao equipamento. 2. Autorização para a execução de comandos: Após a autenticação do usuário, o AAA precisa informar ao roteador sobre os comandos que o referido usuário poderá executar no terminal. É possível limitar a quantidade de comandos disponíveis para a execução das seguintes formas: por usuário, perfil ou grupo de usuários. 3. Auditar os acessos ao equipamento: O AAA enviará dados sobre cada comando executado pelo usuário durante uma sessão com o roteador. Com este recurso, poderemos identificar e controlar todas as atividades de configuração e monitoramento efetuadas no roteador. Por exemplo, o administrador de rede pode analisar o que o usuário dltecuser fez durante sua sessão e quando ele executou os comandos. O AAA oferece diversos benefícios, dentre eles citaremos os principais: • Padronização das formas de autenticação. Todos os seus usuários poderão ser autenticados através de um método único e centralizado, diminuindo a complexidade e facilitando o gerenciamento da rede. • Gerenciamento aprimorado. O AAA reduz os eforços para a configuração dos métodos de autenticação e controle de acessos aos equipamentos de rede. Toda a configuração poderá ser executada de forma centralizada. • Backup. É possível disponibilizar mecanismos redundantes para garantir a continuidade do serviço AAA. O serviço de autenticação pode ser utilizado para fornecer controle de acesso administrativo remoto, por exemplo, acesso aos roteadores e switches via Telnet ou SSH, ou para acesso remoto à uma rede, quando por exemplo, um usuário em home-office deseja conectar-se via VPN à rede local da empresa. Nos equipamentos Cisco a autenticação pode ser configurada em uma base de dados local ou com uma base de dados remota baseada em servidor, por exemplo, com o ACS utilizando RADIUS ou TACACS+. É importante lembrar que no caso da utilização da base local para usuários e senhas o próprio roteador faz a autenticação, o que não ocorre com a versão do AAA via servidor, onde o roteador deve consultar a base do servidor e ele fará o processo de verificação e autenticação das credenciais desse usuário. Conforme figura acima.


   

 

 



   

    

   



Página 83

 

 

  


Após a autenticação dos usuários eles são autorizados para determinados recursos específicos da rede conforme a política da empresa. A autorização é basicamente o que um usuário pode ou não fazer na rede. Ou seja, logo após o usuário ser autenticado é limitado os direitos e privilégios específicos a certos comandos no roteador por usuário, perfil ou grupo de usuários. Esse processo é semelhante aos níveis de privilégio via CLI que configuramos no capítulo passado. A autorização é tipicamente implementada usando uma solução baseada em servidor AAA. Autorização usa um conjunto de atributos que descreve o acesso do usuário à rede. Esses atributos são comparados com as informações contidas no banco de dados AAA e uma espécie de política de restrições é aplicada no roteador onde o usuário está conectado. A autorização é automática e não exige que os usuários executem etapas adicionais após a autenticação, pois ela é executada imediatamente após o usuário se autenticar. Por último, o procedimento de accounting ou auditoria é uma referência à coleta da informação relacionada à utilização de recursos de rede pelos usuários. Esta informação pode ser utilizada para gerenciamento, planejamento, cobrança e etc. A auditoria em tempo real ocorre quando as informações relativas aos usuários são trafegadas no momento do consumo dos recursos. Na auditoria em batch as informações são gravadas e enviadas posteriormente. As informações que são tipicamente relacionadas com este processo são a identidade do usuário, a natureza do serviço entregue, o momento em que o serviço se inicia e o momento do seu término. Em equipamentos Cisco podemos contabilizar ou registrar vários níveis de informação, tais como de rede (por exemplo: interface UP/DOWN), de conexões, modos executivos ou EXEC, do sistema (por exemplo: reloads), sobre comandos executados e o uso dos recursos dos equipamentos. Na sequência vamos estudar como configurar cada uma das etapas do AAA em equipamentos Cisco. 3

Configurando o AAA com Base de Dados Local

A Autenticação AAA local também é conhecida como autossuficiente ou self-contained e é recomendada para redes de menor porte, ou seja, com um número limitado de usuários. Nesse método utilizaremos nomes de usuários locais e as senhas armazenadas no próprio roteador para realizar a autenticação. O método de autenticação local é semelhante ao uso do comando login local, com a diferença que o AAA fornece uma maneira de configurar métodos de backup de autenticação. A configuração é simples e vamos explicar os comandos na prática. 1. Inicie ativando o AAA com o comando “aaa new-model” em modo de configuração global; 2. Escolha o método de autenticação local. A “lista de Métodos”, ou “Method List “, para a autenticação é representada durante esta tarefa de configuração do AAA. Se o método “default” for mencionado ele será vinculado para todas as interfaces do roteador. Caso você queira vincular um método para uma interface apenas, utilize um nome diferente de “ default”, o que chamamos de “named method list”. O seguinte comando permite a criação do method list e listas de autenticação: Router(config)#aaa method2... method 4]

authentication

login

{default

|

list-name}


   

 

 



   

    

   



[method1

Página 84

 

 

  


Segue a lista de palavras chave para escolha dos métodos.        





Enable: Usa a senha de enable para autenticação. krb5: Usa o Kerberos 5 para autenticação. Line: Usa a senha da line para autenticação. Local: Usa o nome do banco de dados local para autenticação. None: Não usa autenticação. Group radius: Utiliza a lista do RADIUS para fornecer serviços de autenticação. Group tacacs+: Utiliza a lista do TACACS + para fornecer serviços de autenticação. krb5-telnet: Usa o protocolo Kerberos 5 Telnet de autenticação quando se usa o Telnet para se conectar ao roteador. Group | group-name: Utiliza um subconjunto do RADIUS ou TACACS + como servidores de autenticação, tal como definido pelo nome do grupo de grupo de servidores. Local-case: Usa autenticação local pelo username, porém case-sensitive.

3. Agora vamos configurar o roteador para utilizar AAA e vamos configurar 2 usuários e senha, sendo que o segundo método de autenticação caso o usuário não lembre a senha será a senha de enable. Vamos então fazer uma configuração especial para a line VTY ou acesso telnet onde será apenas com o usuário e senha local. Vamos utilizar a opção que distingue entre maiúsculo e minúsculo. R1#config term Enter configuration commands, one per line. End with CNTL/Z. R1(config)#username Userdltec secret DltecUser@! R1(config)#username Admin secret DltecUser@! R1(config)#enable secret Dltec R1(config)#aaa new-model R1(config)#aaa authentication login default local-case enable R1(config)#! caso o adm esqueca o usuario e a senha R1(config)#! ele pode entrar com a senha de enable R1(config)#aaa authentication login Telnet local-case R1(config)#line vty 0 15 R1(config-line)#login authentication Telnet R1(config-line)#exit R1(config)#aaa local authentication attempts max-fail 5 R1(config)#end R1# *Apr 28 23:36:49.247: %SYS-5-CONFIG_I: Configured from console by console R1#

Caso você esqueça o usuário e senha basta entrar com o usuário Dltec e senha Dltec, pois o segundo método é via a senha de enable, faça o teste. O comando default define os métodos em todas as linhas e interfaces a não ser que um segundo método específico tenha sido definido, como no exemplo acima para a line VTY. Para a VTY foi utilizada um médoto de autenticação com o nome de Telnet, o qual determina que seja utilizado o usuário e senha configurados localmente com o comando username com distinção entre maiúsculo e minúsculo. Não há método backup configurado, preste atenção que o único método é o “local-case”. Ainda temos um comando opcional para definir o máximo de tentativas que um usuário é permitido fazer antes de ser bloqueado: “aaa local authentication attempts numero_maximo_ de_tentativas”. No exemplo acima esse número foi definido como 5, ou seja, se o usuário errar 5 vezes a senha de um dos usernames definidos ele será bloqueado.


   

 

 



   

    

   



Página 85

 

 

  


3.1 Verificando as Configurações Para verificar os usuários bloqueados utilize o comando “show aaa local user lockout” e para liberar o usuário bloqueado utilize o comando “clear aaa local user lockout {username username | all}”. O operando all libera todos os usuários bloqueados. Para verificar o AAA local você pode utilizar o comando “show aaa sessions” e “show aaa user {usuário_específico | all}”. R1#show aaa sessions Total sessions since last reload: 2 Session Id: 2 Unique Id: 4 User Name: Admin IP Address: 0.0.0.0 Idle Time: 0 CT Call Handle: 0 R1# R1#show aaa user all -------------------------------------------------Unique id 4 is currently in use. Accounting: log=0x18001 Events recorded : CALL START INTERIM START INTERIM STOP update method(s) : NONE update interval = 0 Outstanding Stop Records : 0 Dynamic attribute list: 65406390 0 00000001 connect-progress(35) 4 Term Serv Auth 654063A4 0 00000001 pre-session-time(253) 4 72(48) 654063B8 0 00000001 elapsed_time(322) 4 0(0) 654063CC 0 00000001 pre-bytes-in(249) 4 0(0) 654063E0 0 00000001 pre-bytes-out(250) 4 0(0) 654063F4 0 00000001 pre-paks-in(251) 4 0(0) 65406408 0 00000001 pre-paks-out(252) 4 0(0) No data for type EXEC No data for type CONN NET: Username=(n/a) Session Id=00000002 Unique Id=00000004 Start Sent=0 Stop Only=N stop_has_been_sent=N Method List=0 Attribute list: 65406390 0 00000001 session-id(320) 4 2(2) No data for type CMD No data for type SYSTEM No data for type RM CALL No data for type RM VPDN No data for type AUTH PROXY No data for type CALL No data for type VPDN-TUNNEL No data for type VPDN-TUNNEL-LINK No data for type 11 No data for type IPSEC-TUNNEL No data for type RESOURCE


   

 

 



   

    

   



Página 86

 

 

  


Debg: No data available Radi: No data available Interface: TTY Num = 0 Stop Received = 0 Byte/Packet Counts till Call Start: Start Bytes In = 0 Start Bytes Start Paks In = 0 Start Paks Byte/Packet Counts till Service Up: Pre Bytes In = 0 Pre Bytes Out Pre Paks In = 0 Pre Paks Out Cumulative Byte/Packet Counts : Bytes In = 0 Bytes Out = 0 Paks In = 0 Paks Out = 0 StartTime = 20:38:29 utc Apr 28 2011 Component = EXEC Authen: service=LOGIN type=ASCII method=LOCAL Kerb: No data available Meth: No data available Preauth: No Preauth data. General: Unique Id = 00000004 Session Id = 00000002 Attribute List: 65406390 0 00000009 interface(157) 4 tty0 654063A4 0 00000001 port-type(161) 4 Async 654063B8 0 00000009 clid(27) 5 async PerU: No data available Service Profile: No Service Profile data.

Out = 0 Out = 0 = 0 = 0

R1#

Você pode ainda utilizar o comando “debug aaa authentication” para verificar os problemas com o AAA em um nível de depuração mais elevado. Procure mais especificamente pelas mensagens GETUSER e GETPASS. A mensagem Method também pode auxiliar a encontrar a lista que você está querendo verificar no debug. Veja a sequência a seguir que foi gerada com a configuração utilizada no exemplo do AAA local via CLI. User Access Verification Username: A *Apr 29 00:02:52.999: AAA/BIND(00000008): Bind i/f *Apr 29 00:02:53.007: AAA/AUTHEN/LOGIN (00000008): Pick method list 'default' Username: Admin Password: % Authentication failed Username: *Apr 29 00:03:01.971: AAA/AUTHEN/LOGIN (00000008): Pick method list 'default' Username: Admin Password: % Authentication failed Username: D *Apr 29 00:03:17.143: AAA/AUTHEN/LOGIN (00000008): Pick method list 'default'


   

 

 



   

    

   



Página 87

 

 

  


Username: Dltec Password: *Apr 29 00:03:20.223: AAA/AUTHEN/ENABLE(00000008): Processing request action LOGIN *Apr 29 00:03:20.227: AAA/AUTHEN/ENABLE(00000008): Done status GET_PASSWORD *Apr 29 00:03:22.407: AAA/AUTHEN/ENABLE(00000008): Processing request action LOGIN *Apr 29 00:03:22.451: AAA/AUTHEN/ENABLE(00000008): Done status PASS R1>

Perceba que o método utilizado foi através do “enable secret”. 3.2 Configuração via CCP A configuração da autenticação local utilizando AAA é bastante simples, comece criando os usuários em “Configure > Router > Router Access > User Accounts/View” clicando no botão Add. Depois em “Configure > Router > AAA > AAA Summary” verifique se o AAA está realmente ativado (Enabled - comando aaa new-model do CLI está inserido). Se o AAA estiver desativado você pode ativá-lo no botão Enable AAA. Estando ativado entre em “Configure > Router > AAA >Authentication Policies > Login” para configurar o uso da base de dados local de usuários no login remoto ao roteador ou switch. O método default já vem criado nos roteadores, clique nele, depois em Edit e defina como Local para que o roteador utilize os usuários e senhas locais no login remoto. Você pode até definir mais métodos, por exemplo, caso o usuário local falhe se logar com a senha de enable. Veja a tela abaixo.


   

 

 



   

    

   



Página 88

 

 

  


4 AAA Baseado em Servidor – Autenticação A configuração do AAA local, conforme já estudado, é útil para redes pequenas, porém em larga escala ela não tem a performance necessária que um administrador de rede necessita, pois a administração torna-se muito trabalhosa pelo esforço manual de criação e administração de usuários. O AAA baseado em servidor (server based AAA) foi criado para administrar esse tipo de cenário, onde temos uma rede de maior porte e com um grande número de usuários. Um exemplo de servidor AAA é o Cisco Secure ACS (Access Control Server ou Servidor de Controle de Acesso) ou então você pode utilizar o serviço TACACS+ ou RADIUS em um servidor Linux.

O Cisco Secure ACS permite criar um banco de dados de usuário centralizado para acesso administrativo, possibilitando que todos os dispositivos na rede possam acessá-lo. Ele também pode trabalhar com muitos bancos de dados externos, incluindo Active Directory e Lightweight Directory Access Protocol (LDAP). Estas bases de dados armazenam informações de conta e senhas do usuário, permitindo a administração central de contas de usuário. Veja a figura ao lado. A família Cisco Secure ACS de produtos suporta os protocolos Terminal Access Control Access Control Server Plus (TACACS +) e Remote Dial-in User Services (RADIUS), que são os dois protocolos mais utilizados pelos equipamentos de segurança da Cisco, roteadores e switches para implementar o AAA . Embora ambos os protocolos possam ser utilizados para comunicação entre clientes e servidores AAA, o TACACS + é considerado mais seguro, isto porque todas as trocas de mensagens do protocolo TACACS + são criptografadas. Já o RADIUS só criptografa a senha do usuário, não criptografando nomes de usuários, informações de auditoria ou quaisquer outras informações enviadas nas trocas de mensagens do RADIUS.


   

 

 



   

    

   



Página 89

 

 

  


4.1 Visão Geral do TACAS+ e RADIUS O protocolo RADIUS (Remote Authentication Dial-In User Service) hoje faz parte dos padrões da IETF e pode funcionar juntamente com outros serviços. Ele foi desenvolvido pela Livingston, é um protocolo aberto IETF AAA padrão para aplicações como acesso à rede ou com mobilidade IP. Atualmente é definido pelas RFCs 2865, 2866, 2867 e 2868. O processo de autenticação do RADIUS utiliza um servidor que tem contato com o cliente, um servidor RADIUS e um banco de dados onde os dados dos usuários são armazenados. A autenticação é feita por meio de uma mensagem que o cliente RADIUS envia para o servidor RADIUS contendo login e senha. Quando o servidor recebe a mensagem, ele valida o cliente e verifica o login, senha e outros parâmetros que vêm com a mensagem. Em caso de uma autenticação válida, o servidor envia ao cliente uma mensagem permitindo o acesso bem como as ações permitidas pelo nível de acesso. O RADIUS tem uma porta para autenticação (UDP 1645 ou UDP 1812) e outra para contabilidade (UDP 1646 ou UDP 1813). Na figura a seguir você pode verificar as etapas de autenticação para acesso remoto em um roteador utilizando o RADIUS.

O protocolo TACACS+ é proprietário da cisco sendo suportado pela grande maioria dos roteadores da cisco. É uma melhoramento do protocolo aberto TACACS. O TACACS+ também é um protocolo que veio após o RADIUS e portanto apresenta algumas vantagens em relação a este. O TACACS+ usa conexões TCP (mais segura) enquanto que o RADIUS faz transporte via UDP(menos seguro). Do ponto de vista da segurança a diferença entre os protocolos de transporte utilizados é fundamental. O RADIUS precisa trabalhar com um número maior de variáveis para suprir a falta de serviços do UDP. Como TACACS+ usa TCP, que é orientado a conexão, esses detalhes não são preocupação do protocolo TACACS+. Usando TCP é mais fácil descobrir quando um servidor está off-line e quando ele está simplesmente lento. O TACACS+ criptografa todo o corpo do pacote e faz a separação entre autenticação e autorização e contabilização. Com essa separação é possível criar soluções de autorização separadas. O TACACS+ utiliza o protocolo TCP na porta 49 para transmitir suas informações de maneira segura. Além disso, o TACACS+ tem suporte multiprotocolo. Na figura a seguir você pode verificar o mesmo processo para acesso remoto em um roteador utilizando agora o TACACS+ como protocolo de autenticação.


   

 

 



   

    

   



Página 90

 

 

  


Portanto, ambos TACACS + e RADIUS são protocolos de autenticação, porém cada um suporta diferentes recursos e funcionalidades. Escolher entre o TACACS + ou RADIUS depende das necessidades da organização. Por exemplo, um grande provedor de acesso pode selecionar RADIUS porque suporta um billing detalhado (contabilidade) necessárias para o faturamento dos usuários. Já uma organização com vários grupos de usuários pode preferir utilizar o TACACS +, porque possibilita a implementação de políticas de autorização que pode ser aplicada por usuário ou por grupo. É importante compreender as muitas diferenças entre o TACACS + e RADIUS. As características do TACACS + incluem:    

É incompatível com os seus antecessores TACACS e XTACACS Separa autenticação e autorização Criptografa toda a comunicação Utiliza a porta TCP 49

As características do Radius incluem:     

RADIUS usa servidores proxy para dar escalabilidade Combina a autenticação RADIUS e autorização como um único processo Criptografa apenas a senha Utiliza UDP Suporta tecnologias de acesso remoto (802.1X e SIP)

Veja na tabela a seguir um resumo da comparação entre o TACACS+ e o RADIUS.


   

 

 



   

    

   



Página 91

 

 

  


Vale a pena citar que o protocolo DIAMETER é o sucessor do RADIUS, sendo compatível com ele. O protocolo DIAMETER apresenta algumas evoluções em relação ao RADIUS. Ele é bidirecional entre os pares, diferentemente do RADIUS que é unidirecional. Apresenta maior eficiência em suas traduções porque trabalha com 32 bits VSAs, já o RADIUS trabalha com 8 bits. Suporta maior quantidade de pedidos AAA e terá suporte a send/receive e acknowledgment. E utiliza criptografia para se prevenir de ataques. 4.2 Configurando o TACACS+ e RADIUS via CLI Para configurar a autenticação baseada em servidores com TACACS+ ou RADIUS o processo é semelhante, basta seguir os 4 passos básicos abaixo: 1. Habilitar o AAA (aaa new-model) 2. Especificar o endereço IP do servidor ACS ou do servidor de autenticação externo 3. Configurar a chave secreta 4. Configurar a autenticação para usar um servidor RADIUS ou TACACS + (aqui podemos configurar a redundância para autenticação) Vamos mostrar um exemplo de configuração conforme figura a seguir onde existem dois servidores: 1. Servidor TACACS+ (ACS) com IP 172.16.41.151 2. Servidor RADIUS (ACS) com IP 172.16.41.186


   

 

 



   

    

   



Página 92

 

 

  


A primeira opção para login será o TACACS+, a segunda o RADIUS e a terceira o usuário local case-sensitive. Veja a configuração abaixo. R1#config term R1(config)#aaa new-model R1(config)#tacacs-server host 172.16.41.151 single-connection R1(config)#tacacs-server key CHAVE-TACACS R1(config)#radius-server host 172.16.41.186 R1(config)#radius-server key CHAVE-RADIUS R1(config)#aaa authentication login default group tacacs+ group radius local-case

Portanto para o TACACS+ o comando “tacacs-server host” define o IP do servidor ACS que está suportando o serviço do TACACS. O subcomando single-connection colocado no final evita que a sessão seja fechada e aberta toda vez que haja um novo acesso, ficando uma conexão aberta sempre para melhorar a performance da conexão. Já o comando “tacacsserver key” define a senha para acesso ao servidor. O mesmo princípio serve para o RADIUS, porém para o RADIUS não existe o subcomando “single-connection”, pois ele trabalha com UDP que não é orientado a conexão. O comando para definir o método de autenticação foi o mesmo utilizado para o AAA local, sendo que o início do comando é o “aaa authentication login default”, logo após definidos os métodos: 1. Primeiro via TACACS+ com o group tacacs+ 2. Segundo via RADIUS com o group radius 3. Terceiro via usuário/senha locais com o local-case


   

 

 



   

    

   



Página 93

 

 

  


4.3 Configurando o TACACS+ e RADIUS via CCP A filosofia para configuração via CCP é a mesma, porém agora vamos utilizar um modo gráfico para executá-la. Vamos aos passos. Primeiro entre em “Configure > Router > AAA > AAA Servers and Groups >Servers” e adicione os servidores em Add. Não esqueça para o TACACS+ de selecionar o checkbox “Single Connection to Server”, explicado anteriormente. No botão Global Settings você pode definir as chaves (senhas) para o RADIUS e TACACS+, assim como o IP da interface que será utilizado nas requisições (source interface). Em seguida entre em “Configure > Router > AAA > Authentication Policies > Login” para definir uma lista de métodos, a qual pode ser a default aplicada em todas as linhas e interfaces ou uma definida pelo usuário. Depois aplique essa política para o acesso remoto via SSH/Telnet em “ Configure > Router > Router Access > VTY”. Clique no botão Edit e faça a configuração. 4.4 Verificando as Configurações com Autenticação via Servidor Os comandos show são os mesmos mostrados para o AAA via autenticação local. O que muda é a utilização do debug. Para realizar o troubleshooting utilize os seguintes comandos debug: • debug aaa authentication • debug tacacs authentication • debug radius authentication Semelhante ao comando debug aaa authentication, a depuração tacacs e radius também indicam as mensagens de status de PASS ou FAIL. R1#debug tacacs ? accounting authentication authorization events packet

TACACS+ TACACS+ TACACS+ TACACS+ TACACS+

protocol protocol protocol protocol packets

accounting authentication authorization events

R1#debug tacacs authentication TACACS+ authentication debugging is on R1#debug radius ? accounting RADIUS accounting packets only authentication RADIUS authentication packets only brief Only I/O transactions are recorded elog RADIUS event logging failover Packets sent upon fail-over retransmit Retransmission of packets verbose Include non essential RADIUS debugs R1#debug radius authentication Radius protocol debugging is on Radius protocol brief debugging is off Radius protocol verbose debugging is off Radius packet hex dump debugging is off


   

 

 



   

    

   



Página 94

 

 

  


Radius Radius Radius Radius Radius Radius R1#

5

packet protocol (authentication) debugging is on packet protocol (accounting) debugging is off elog debugging debugging is off packet retransmission debugging is off server fail-over debugging is off elog debugging debugging is off

Configurando a Autorização (Authorization) e Auditoria (Accounting) Baseada em Servidor

Após a autenticação do usuário, o AAA precisa informar ao roteador sobre os comandos que o referido usuário poderá executar no terminal. É possível limitar a quantidade de comandos disponíveis para a execução das seguintes formas: por usuário, perfil ou grupo de usuários. O protocolo TACACS + permite a separação entre a autenticação e autorização. Um roteador pode ser configurado para restringir o usuário de executar determinados comandos após a autenticação. A autorização pode ser configurada para o modo de caracteres (autorização exec) e em modo pacote (autorização de rede). Já o RADIUS não separa a autenticação do processo de autorização, eles acabam fazendo parte do mesmo pacote de facilidade de configuração. Outro aspecto importante da autorização é a capacidade de controlar o acesso a serviços específicos. Controlando o acesso aos comandos de configuração simplifica a infraestrutura de segurança em redes corporativas de grande porte. Além disso, com o Cisco Secure ACS a configuração pode ser simplificada com uma lista de autorização por usuários centralizada. Por exemplo, um usuário autorizado pode ser autorizado a acessar o comando show version, mas não o comando configure terminal para entrar em modo de configuração global. Com a autorização ativa no AAA o roteador consultará o ACS antes executar os comandos em nome do usuário de acordo com o que foi configurado em sua lista de permissões. Quando o usuário digita o comando show version, o ACS envia uma resposta ACCEPT. Se o usuário emite um comando configure terminal, o ACS envia uma resposta REJECT, não autorizando o comando. TACACS + por padrão estabelece uma nova sessão TCP para cada solicitação de autorização, que pode gerar atraso quando o usuário digitar os comandos. O Cisco Secure ACS suporta sessões TCP persistentes para melhorar o desempenho desse serviço.


   

 

 



   

    

   



Página 95

 

 

  


5.1 Configurando a Autorização (Authorization) Baseada em Servidor Para configurar a autorização no roteador Cisco você deve utilizar o comando “aaa authorization {network | exec | commands level} {default | list-name} method1...[method4]”. Vamos agora analisar cada parte do comando. Primeiro vamos começar com as opções de serviços que podemos autorizar: R1(config)#aaa authorization ? auth-proxy For Authentication Proxy Services cache For AAA cache configuration commands For exec (shell) commands. config-commands For configuration mode commands. configuration For downloading configurations from AAA server console For enabling console authorization exec For starting an exec (shell). ipmobile For Mobile IP services. network For network services. (PPP, SLIP, ARAP) reverse-access For reverse access connections template Enable template authorization

As três opções mais utilizadas são: Commands: autoriza em nível de comandos EXEC Exec: para iniciar o modo privilegiado EXEC Network: para serviços de rede (PPP, SLIP, ARAP) Após definido o que você deseja autorizar você pode criar uma lista de métodos, similar ao capítulo anterior, ou então utilizar a padrão ou default, conforme saída do comando abaixo. R1(config)#aaa authorization exec ? WORD Named authorization list. default The default authorization list.

Vamos fazer uma lista de método default, onde as lines e interfaces serão configuradas por padrão nessa lista de autorização, conforme abaixo. R1(config)#aaa authorization exec default ? group Use server-group. if-authenticated Succeed if user has authenticated. local Use local database. none No authorization (always succeeds).

Dentro de uma lista (default ou criada pelo usuário) você pode ter ela definida por um grupo, ifauthenticated, local ou none. Para configurar com um servidor externo ACS ou qualquer outro tipo, seja TACACS+ ou RADIUS, entre com a opção group e escolha uma lista, radius ou tacacs+. R1(config)#aaa authorization exec default group ? WORD Server-group name radius Use list of all Radius hosts. tacacs+ Use list of all Tacacs+ hosts.

Agora a configuração está finalizada para o tacacs+. Veja abaixo. R1(config)#aaa authorization exec default group tacacs+ R1(config)#


   

 

 



   

    

   



Página 96

 

 

  


Assim como na autenticação, na autorização também podemos ter redundância com até 4 métodos. Veja a seguir mais um exemplo utilizando o conceito de autenticação e autorização baseados em servidor. Analise a configuração mostrada. Router(config)# aaa new-model Router(config)# aaa authentication login VIEW_AUTHEN group tacacs+ Router(config)# aaa authorization commands 15 VIEW_AUTHOR group tacacs+ Router(config)# line con 0 Router(config-line)# login authentication VIEW_AUTHEN Router(config-line)# authorization commands 15 VIEW_AUTHOR Router(config)# line vty 0 4 Router(config-line)# login authentication VIEW_AUTHEN Router(config-line)# authorization commands 15 VIEW_AUTHOR

No exemplo acima criamos um método para autenticação e um para autorização definidos pelo usuário. Esses métodos direcionam o usuário para um servidor TACACS+, onde tanto a autenticação como a autorização deverão ser autenticadas e autorizadas por esse servidor. 5.2 Configurando Autorização via CCP Para configurar a autorização via CCP vá em “ Configure > Router > AAA > Authorization Policies > EXEC Command Mode” e clique em Add. Crie uma lista default ou entre com um nome para fazer uma lista definida pelo usuário. Após clique em Add na tela que abriu e escolha o método de autorização similar ao conceito que utilizamos via CLI. 5.3 Configurando a Auditoria (Accounting) Baseada em Servidor Para a configuração da Auditoria ou Accounting no AAA com um servidor externo ou um Cisco Secure ACS você deve utilizar o comando “aaa accounting { network | exec | connection} {default | list-name} {start-stop | stop-only | none} [broadcast] method1...[method4]”. O objetivo da auditoria no AAA é que o roteador ou switch envie dados sobre cada comando executado pelo usuário durante uma sessão. Com este recurso, é possível identificar e controlar todas as atividades de configuração e monitoramento efetuadas no roteador por usuário cadastrado, tendo um nível de controle eficaz em caso de problemas de segurança ou auditorias futuras. Seguindo os mesmos preceitos para “Method Lists”, as seguintes “Method Lists” estão disponíveis para a auditoria: 

 





Network: Informa detalhes sobre todas as sessões PPP, SLIP ou ARAP, inclusive fornecendo contadores sobre pacotes e bytes. EXEC: Fornece informações sobre todas as sessões de usuários no access server. Commands: Fornece informações sobre todos os comandos digitados no EXEC mode, incluindo os comandos inseridos no global configuration mode. Connection: Fornece informações sobre todas as conexões inbound e outbound feitas para o access server, incluindo telnet, local-area transport (LAT), TN3270, packet assembler/disassembler (PAD), e rlogin. System: Provê informações sobre os eventos do sistema.


   

 

 



   

    

   



Página 97

 

 

  

tel 41 304 3045.78 5.7810 10 - info info dlt dltec.c ec.com om.br .br - www.d www.dlte ltec.c c.com om.br .br 

Resource: Resource: Provê registros “start” e “stop” para todas as chamadas por onde a autenticação do usuário foi bem sucedida. Além disto, informa os registros “stop” para as chamadas cujas autenticações não foram bem sucedidas.

Os métodos que estão disponíveis para a auditoria (accounting) são TACACS+ e RADIUS. Veja ao lado um exemplo de configuração da auditoria colocando o TACACS+ como método principal e o RADIUS como reserva. Vamos coletar informações sobre sessões estabelecidas via rede (network) e sobre as sessões de usuários (EXEC). O parâmetro “start-stop “start-stop”” é o trigger ou gatilho que dispara o registro ou gravação na base sobre a ação do usuário. Aqui todo início e fim gerará um registro na base da auditoria. Veja exemplo a seguir. R1(config)#aaa accounting network default start-stop group tacacs+ group radius R1(config)#aaa accounting exec default start-stop group tacacs+ group radius

Os seguintes comandos poderão ser utilizados para monitorarmos o accouting: show accounting, debug aaa accounting.


   

 

 



   

    

   



Página 98

 

 

  


6 Cisco Secure ACS O Cisco Secure ACS (Access Control System) System) foi desenvolvido para atender às novas demandas de gestão de controle de acesso e confidencialidade, apoiando e implementando as políticas de segurança de acesso. Ele faz parte da nova linha TrustSec da Cisco. Veja a seguir a tela de abertura do ACS e também a tela inicial mostrada após o login.


   

 

 



   

    

   



Página 99

 

 

  


Os benefícios do uso do Cisco Secure Access Control System são: • Fácil implantação e integração com outros componentes da Cisco TrustSec para controle de completo de acesso e solução de confidencialidade • Suporte tanto ao RADIUS para controle de acesso à rede e TACACS + para de controle de acesso aos dispositivos de rede • Permite o uso de várias bases de dados simultaneamente para máxima flexibilidade na aplicação da política de acesso • Aumento do poder e flexibilidade para implementação das políticas de controle de acesso que podem incluir requisitos de autenticação para diferentes equipamentos e usuários • Monitoramento integrado e geração de relatórios para auxílio na solução de problemas de rede tudo via interface gráfica baseada em web Cisco Secure ACS utiliza uma base de dados central, centralizando o controle de todos os privilégios do usuário e distribui essa política a todos os pontos de acesso em toda a rede. Cisco Secure ACS fornece relatórios detalhados, além de ter capacidade de monitoramento do comportamento do usuário, conexões de acesso e mudanças na configuração do dispositivo. Esta característica é extremamente importante para as organizações que estão tentando cumprir regulamentações governamentais. O Cisco Secure ACS suporta uma ampla variedade de conexões de acesso, incluindo LAN cabeadas e sem fio (WLAN), conexão discada (Dial-up), banda larga, conteúdo, armazenamento (storage), VoIP, firewalls e redes virtuais privadas (VPNs). Cisco Secure ACS fornece uma variedade de funcionalidades avançadas: • Serviço de monitoramento automático. • Sincronização Sincronização de banco de dados e ferramentas de importação para implementações de projetos de grande escala. • Suporte a autenticação LDAP. • Relatórios de usuário e de acesso administrativo. • Restrições no acesso à rede com base em critérios como horários e dias da semana. • Perfis baseado em dispositivos ou grupo de usuários. O Cisco ACS pode ser instalado em um servidor ou utilizado em um Appliance (hardware com o software instalado). Quando o IINS foi atualiza a versão disponível era a 5.2, porém no momento da atualização do material do curso da DlteC essa versão já entrou em fim de vendas (EOS – End Of Sales) e as versões disponíveis são 5.3 e 5.4, porém as telas e funcionalidades são similares. Cisco Secure ACS também é um importante componente da arquitetura Cisco Identity Based Networking Services (IBNS). Cisco IBNS baseia-se no port-security com o IEEE 802.1X e Extensible Authentication Protocol (EAP), melhorando a segurança do perímetro da rede para cada ponto de conexão dentro da LAN. Nova política de controle, tais como cotas por usuário, atribuições de VLAN e listas de controle de acesso (ACLs) podem ser implantados dentro desta nova arquitetura. Isto é devido à capacidade estendida de switches Cisco e pontos de acesso para consulta da Cisco Secure ACS sobre o protocolo RADIUS. O Cisco Secure ACS é também um importante componente do Cisco Network Admission Control (NAC). NAC). Cisco NAC é uma iniciativa da indústria patrocinada pela Cisco e usa a infraestrutura de rede para reforçar a política de segurança. Com o Cisco NAC, os clientes podem optar por permitir o acesso à rede apenas aos dispositivos terminais compatíveis e confiáveis e restringir o acesso de dispositivos incompatíveis. O NAC é parte da iniciativa da Cisco SelfDefending Network e é a base para permitir o NAC na Camada 2 e Camada 3 da rede.


   

 

 



   

    

   



Página 100

 

 

  


6.1 Dicas de Configuração do ACS Para se comunicar com o Cisco Secure S ecure ACS (autenticação externa) podemos utilizar o TACACS+ ou RADIUS, sendo que o TACACS+ é o mais seguro, porém o RADIUS é padrão aberto. Portanto, em ambientes de vários fabricantes (multi-vendor) o RADIUS é mais aconselhável. Facilidades e características do TACACS+ no Cisco ACS: Separa autenticação e autorização Suporta diversos recursos (features) avançados Tem comunicação criptografada (segura) Utiliza porta TCP 49    

O RADIUS tem as seguintes segui ntes características práticas: Suporta ambientes de grande porte (escalável) Utiliza porta UDP 1645 ou 1812 para autenticação Utiliza porta UDP 1646 ou 1813 para accounting   

Para configurar a autorização em roteadores e switches Cisco através do ACS 4.x você terá que seguir as seguintes etapas: 



Na tela “ACS “ACS User Group setup”, setup”, utilize as opções disponíveis no “Shell “ Shell Command Authorization Set” Set” e configure quais comandos e seus parâmetros (ou argumentos) você deseja permitir ou negar. Quando adicionar um roteador como cliente AAA do servidor ACS escolha o TACACS+ para realizar a autorização, conforme estudado durante o capítulo.

A novidade a partir do ACS 5.2 é a possibilidade de conceder permissões não somente através da verificação da identidade do solicitante, sendo possível criar políticas baseadas em regras com uma abordagem mais flexível, que pode combinar uma variedade de condições de acesso encontradas nas redes atuais. Isso inclui localização, tipo de acesso, data, hora e assim por diante, por exemplo, podemos definir que determinados usuários acessem os roteadores somente após o horário comercial. Essa facilidade se chama “ Rule-Based Policies”. Policies”.


   

 

 



   

    

   



Página 101

 

 

  


A configuração do rule-based policy no ACS utiliza os seguintes passos: 1. Adicionar um roteador como cliente AAA. 2. Configure o “identity “identity groups” groups” e “identity “identity store”. store”. 3. Configure os serviços de acesso que devem processar p rocessar a requisição. 4. Crie uma “identity “identity policy”. policy”. 5. Crie uma “authorization “authorization policy”. policy”. A instalação em laboratório do Cisco ACS 5.2 pode ser feita em ambiente virtual, com VMWare Workstation ou no Virtual Box, sendo que vamos utilizar em nossas demonstrações a primeira opção. Você precisa ter a imagem (ISO) do ACS e também baixar uma licença de demonstração demon stração no site da Cisco, porém é necessário CCO (usuário registrado no site da Cisco) Ci sco) para fazer o download. O processo de instalação em VM é relativamente r elativamente simples, porém um pouco demorado, você deve seguir os passos indicados em nosso blog no link: http://www.dltec.com.br/blog/?p=3716 7 Cisco ISE O Cisco Identity Services Engine ( Engine (ISE ISE)) é um controlador de acesso e identidade que integra as funcionalidades do ACS e do NAC. O ISE pode validar que um computador atende aos requisitos da política pol ítica de segurança de uma empresa relacionada a arquivos de definição de vírus, service servi ce pack e assim por diante antes de permitir que o dispositivo na rede (função do NAC). Esta solução utiliza muitas características do AAA, mas não é um substituto completo do ACS. Os clientes que utilizam os recursos do ISE provavelmente p rovavelmente precisarão do ACS para a autenticação e autorização de componentes de rede e também utilizar uti lizar o ISE para a verificação verifi cação de políticas de conformidade dos computadores (clientes de rede). 8 Resumo do Capítulo Bem pessoal, chegamos ao final do capítulo. É muito importante que nesse n esse ponto do curso você tenha domínio dos seguintes itens: Explicar as funções e importância do AAA (Autenticação, Autorização e Auditora). Descrever as características do TACACS + e protocolos RADIUS. Configuração da autenticação. Configuração da autorização. Configuração da auditoria ou contabilidade (accounting).     


   

 

 



   

    

   



Página 102

 

 

  


Capítulo 5 – ACL em Roteadores Cisco Nesse capítulo estudaremos como reduzir as ameaças à roteadores Cisco e redes utilizando ACLs (Access Control List).

Objetivos do Capítulo Ao final desse capítulo você terá estudado e deverá compreender: Explicar a funcionalidade das ACL’s padrão, estendida e nomeada utilizadas pelos roteadores para filtrar pacotes. Configurar e verificar ACL’s IP para reduzir ameaças em redes via CLI (filtro de tráfego destinado ao Telnet, SNMP e ataques DDoS). Prevenindo a falsificação de endereço IP (IP Spoofing) utilizando ACL’s via CLI. Analisar e identificar pontos chaves a serem considerados na construção de ACLs. Implementar ACLs Reflexivas e timebased. Entender e implementar ACLs para IPv6. 

As ACLs são a base para o entendimento do funcionamento de um firewall, além disso serão utilizadas em diversas configurações de outros recursos durante o curso.













   

 

 



   

    

   



Página 103

 

 

  


2.10.3


2.11 Resumo sobre ACL’s Padrão e Estendidas __________________________ 123

Introdução _____________________ _____________________ 105

2 Listas de Controle de Acesso (ACL) Revisão ______________________ ___________________________ _____ 106

Exemplo 3 – 3 – ACL ACL Nomeada Estendida 123

2.12

Atividade Prática _____________ 124

2.1

Entendendo e Criando as Regras ___ 108

3 Configurando ACL Padrão e Estendida via CCP ______________ _________________________ _____________ __ 125

2.2

ACL IP Padrão __________________ 111

4

2.3

Máscara Curinga ________________ 111

2.3.1 Máscara curinga para selecionar redes classful 112 2.3.2 Máscara curinga para apenas um IP (máscara de host) ____________________ _______________________ ___ 112 2.3.3 Máscara curinga para permitir quaisquer redes (todas as redes) ___________ ___________ 113 2.3.4 Selecionando Sub-redes__________ __________ 113 2.3.5 Selecionando Faixas de Endereços IP 114 2.3.6 Máscaras Curinga Esdrúxulas _____ 116

ACL Reflexiva - Reflexive ACLs _____ 125

4.1 Configurando Listas de Acesso Reflexivas __________________________ 127 5 ACL Dinâmica - Dynamic ACLs ou Lockand-key __________________________ 129

5.1 6

ACL Temporizada – Time-based ACL 131

6.1 7

Exemplo Prático ________________ 130

Exemplo Prático ________________ 132

Mitigando Ataques com ACLs _____ 132

2.4

ACL IP Estendida ________________ 116

2.5

Exemplo de ACL Estendida ________ ________ 117

7.1

Exemplo Prático ________________ 133

2.6

Verificando as ACLs Criadas _______ 118

7.2

Mitigando Ataques ao SNMP _____ 134

2.7

Listas de Acesso Nomeadas _______ 119

2.8

Aplicando ACL nas Interfaces ______ 120

8 Mitigando Riscos de Segurança com ACLs IPV6 _____________________________ 135

2.9 Limitando Acesso ao SSH e Telnet nos Roteadores _________________________ 121 2.10

Exemplos Práticos de ACLs AC Ls ______ 121

2.10.1 2.10.2

Exemplo 1 – 1 – ACL ACL Padrão _________ _________ 121 Exemplo 2 – 2 – ACL ACL Estendida _______ 122

9

8.1

O que uma ACL IPv6 pode filtrar? __ 136

8.2

Configurando uma ACL IPV6 ______ 136

8.3

Exemplo de ACL IPv6 IPv6 ____________ 137

Resumo do Capítulo _____________ _____________ 138


   

 

 



   

    

   



Página 104

 

 

  


1 Introdução As listas de controle de acesso (ACLs) são amplamente utilizadas em redes de computadores e em segurança de rede para mitigar os ataques e controlar o tráfego da rede. Os administradores usam ACLs para definir e controlar o tráfego em classes de dispositivos de rede com base em vários parâmetros. Esses parâmetros são específicos para a camada do modelo OSI (2, 3, 4 e 7). As ACLs podem ser numeradas (access-list) ou nomeadas (ip access-list), veja saída abaixo. DlteC-FW-GW(config)#access-list ? <1-99> IP standard access a ccess list <100-199> IP extended access a ccess list <1000-1099> IPX SAP access acces s list <1100-1199> Extended 48-bit 48- bit MAC address addre ss access list <1200-1299> IPX summary address a ddress access list <1300-1999> IP standard access a ccess list (expanded (e xpanded range) range ) <200-299> Protocol type-code type -code access list <2000-2699> IP extended access a ccess list (expanded (e xpanded range) range ) <2700-2799> MPLS access list l ist <300-399> DECnet access list <600-699> Appletalk access acc ess list <700-799> 48-bit MAC address a ddress access list <800-899> IPX standard access list <900-999> IPX extended access list dynamic-extended dynamic-exten ded Extend the dynamic ACL absolute timer rate-limit Simple rate-limit specific access list DlteC-FW-GW(config)# DlteC-FW-GW(config)#ip access-list ? extended Extended Access List log-update Control access list log updates logging Control access list logging resequence Resequence Access List standard Standard Access List DlteC-FW-GW(config)#

Praticamente qualquer tipo de tráfego pode ser filtrado usando uma ACL. Por exemplo, no passado, o campo “tipo” do cabeçalho do quadro Ethernet foi utilizado para definir certos tipos de tráfego. Um “tipo” 0x8035 indicava in dicava a presença de um quadro do Reverse Address Resolution Protocol (RARP) e ACLs numeradas, com um intervalo de 200-299, eram utilizados para controlar o tráfego pelo tipo do quadro Ethernet. Veja a saída do comando ao lado com os tipos de ACL que podem ser criadas. Outro exemplo comum do passado era a criação de ACLs com base em endereços MAC. Uma ACL numerada 700-799 filtra o tráfego com base em endereços MAC, possibilitando o controle através desse parâmetro. Após definir como filtrar (IP, MAC, Tipo de quadro ethernet, etc), uma ACL pode bloquear (deny) ou permitir (permit) o tráfego selecionado. Por exemplo, uma ACL numerada 700-799 poderia ser utilizada para bloquear um cliente com um endereço MAC específico de se conectar na rede via um AP (Access-point) pré-determinado. Hoje os tipos mais comuns dos parâmetros utilizados nas ACLs são os endereços IPv4/IPv6 e números de porta TCP e UDP. Por exemplo, uma ACL pode permitir que todos os usuários com um determinado endereço IP de rede baixem arquivos da internet utilizando FTP seguro, assim como essa mesma ACL pode ser usado para negar (bloquear) todos os endereços IP acessarem ao FTP tradicional, garantindo que somente a versão segura seja utilizada.


   

 

 



   

    

   



Página 105

 

 

  


Além das ACL’s numeradas podemos criar os mesmos tipos de ACL nomeadas, o que facilita a criação e estende o número de ACLs que podem ser criadas, pois como você pode notar as ACLs numeradas são limitadas por um range específico de valores. Nesse capítulo faremos um estudo sobre a aplicação das ACLs para mitigar problemas de segurança, lembrando que o conceito já deve ter sido estudado no CCNA R&S ou CCENT, prérequisito para que um aluno obtenha a certificação CCNA Security. 2 Listas de Controle de Acesso (ACL) - Revisão Uma Lista de Controle de Acesso ou “Access Control List” (ACL) é um conjunto de instruções que diz ao roteador para aceitar (permit ou permitir) ou rejeitar (deny ou negar) determinados pacotes vindos de redes IP especificadas. Esse filtro pode atuar até na camada-4, onde é possível especificar portas TCP ou UDP que você deseja filtrar, selecionando assim quais aplicações podem ser acessadas na rede interna e quais podem acessar a rede externa. Uma ACL pode ser utilizada como um “Firewall” básico, fornecendo recursos de filtragem básica, podendo ser aplicada como uma barreira de proteção com a finalidade de controlar o tráfego de dados entre sua rede interna e a Internet. Essas listas devem ser criadas em modo de configuração global, como uma sequência de regras ou statements (declarações) e aplicadas em uma interface LAN, WAN ou em dentro da line VTY, para limitar acesso ao Telnet e SSH, conforme estudado no capítulo anterior. Existem duas maneiras de criar uma ACL: 1. ACL Numerada: as quais podem ser padrão ou estendida ou 2. ACL Nomeada: também podem ser padrão (standard) ou estendidas (extended). Uma ACL IP padrão pode filtrar o tráfego apenas baseado em pacotes IP através do endereço ou rede de origem, tanto na forma nomeada quanto na numerada. Para a ACL IP estendida o administrador de redes tem uma gama maior de opções de filtragem, como pacotes IP através do endereço de origem e destino, protocolos TCP e UDP, protocolo ICMP, outros protocolos como RIP, OSPF, EIGRP, GRE, pelo estado das conexões das portas TCP, etc. Nas figuras a seguir você pode verificar como um pacote é processado quando o roteador tem uma lista de acesso aplicada. As listas são aplicadas nas interfaces em duas possíveis direções:


   

 

 



   

    

   



Página 106

 

 

  


1. In: tráfego entrante

2. Out: tráfego de saída do roteador


   

 

 



   

    

   



Página 107

 

 

  


Note que para a ACL colocada na direção de entrada da Interface ou Inbound (In), a ACL é processada antes do pacote ser roteado, ou seja, somente se ele for permitido pela ACL que o roteador fará o processo de roteamento. Já para a direção de saída ou outbound (Out), o pacote já passou pelo processo de roteamento e após isso será processado pela ACL. Além disso, você pode notar em ambos os diagramas que sempre no final, se você não criar uma regra com permissão o pacote será descartado, pois existe uma negação implícita no final de toda lista de acesso, ou seja, um “deny any” negando todos os pacotes. Portan to para as regras funcionarem deve existir no mínimo uma permissão ou então nenhum pacote será encaminhado. Resumindo: • ACL é um conjunto de regras de teste que se satisfeitos deixarão o pacote ser encaminhado ou filtrarão o pacote; • Pode ser uma lista padrão, analisando apenas a rede IP de origem do pacote e decidindo se aquele pacote vai ou não ser encaminhado; • Caso haja necessidade de maior granularidade, ou seja, filtrar utilizando outros parâmetros como: rede de destino, tipo de protocolo, porta TCP ou UDP, estado da conexão, uma lista de acesso estendida deve ser utilizada; • As listas podem ser numeradas (1 a 99 – ACL IP Padrão / 100 a 199 – ACL IP estendida) ou nomeadas, as quais não tem limitação de listas por utilizarem nomes; • As ACLs podem ser aplicadas nas Interfaces de LAN e WAN ou na linha de Telnet (VTY) dos roteadores e switches em duas direções: Entrada (In) e Saída (Out); • Devem ser criadas em modo de config global e aplicadas nas Interfaces ou Lines; • Os pacotes serão processados um a um, regra a regra, caso uma ele atenda a regra ele será permitido ou negado, caso não atenda passará para o próximo teste até o final das regras. • As regras mais específicas devem ser posicionadas no início da ACL, assim você garante que não haverá atrasos em processamento pelos testes em regras anteriores até chegar à mais específica. • Pacotes gerados pelo roteador não podem ser filtrados por ele mesmo. • Se uma ACL é aplicada a uma interface e não foi criada em modo global o tráfego irá passar normalmente, pois para se ter uma negação (deny) implícito pelo a regra deve ter sido criada. Agora vamos estudar como criar as regras, pois existe uma lógica de funcionamento que depende do entendimento da comunicação em rede e dos protocolos que desejamos filtrar ou proteger. 2.1 Entendendo e Criando as Regras Para entender e criar uma lista de acesso você deve entender como um pacote é formado e enviado na rede, uma sugestão caso haja dúvidas é revisar a matéria que você deve ter estudado no CCNA Routing e Switching. Basicamente em uma rede IP quando um micro deseja conversar com outro fora da sua rede, esse pacote atravessa a rede e o endereço ou rede IP de origem será a do micro que originou a comunicação. Já a rede IP de destino será a rede onde o IP do computador remoto está. Na figura o micro da rede A deseja acessar uma página de Web do servidor que está na rede B. Portanto o a rede de origem é a rede do micro A e a de destino a rede do Servidor B.


   

 

 



   

    

   



Página 108

 

 

  


Agora vamos analisar o cominho de volta, quando o servidor B responde a requisição do micro A, agora ele será a origem da comunicação e o micro A será o destino. Para ACL padrão somente esse dado importa, quem é a rede IP de origem. Utilizando a figura ao lado, você poderia criar uma regra para bloquear pacotes IP para o servidor que venham de uma determinada rede de origem, porém não pode especificar para que serviço ele esteja sendo bloqueado, porque a ACL padrão não tem essa granularidade. Ou a rede inteira ou parte dela passa ou é bloqueada.

Para a ACL estendida a regra do jogo muda bastante, pois ela pode ir além do endereço de origem, portanto você pode ir mais fundo na sua filtragem. A ACL estendida chega até a camada 4 do modelo OSI, ou seja, a camada de transporte, podendo filtrar portas TCP e UDP, consequentemente filtrando as aplicações que passam por aquela interface. Agora veja a figura ao lado para termos um entendimento melhor do que a ACL estendida é capaz.


   

 

 



   

    

   



Página 109

 

 

  


Você agora pode filtrar pelas redes IP de origem e destino, mais os protocolos de camada 3 e 4 suportados pelos roteadores, como ICMP, IGMP, TCP, UDP e outros. No exemplo mostrado anteriormente, o micro A formaria um pacote com o IP do Servidor B e a porta TCP com destino 80, pois é a porta padrão do protocolo Web HTTP. A porta de origem do micro depende do sistema operacional que ele está usando, mas normalmente é uma porta acima de 1024. Quando o servidor responder ele colocará sua porta de origem 80 e a porta de destino com o número da porta que ele recebeu originalmente do computador A. Vale também lembrar que o TCP é orientado a conexão e faz um processo de handshake triplo para inicializar a conexão. Nesse processo ele inicia enviando o SYN setado em 1 e o Ack (reconhecimento) em “0”. Nas ACLs existe um operando ou opção que identifica conexões estabelecidas, ao contrário do que aconteceu anteriormente com o ACK igual a 1, chamado estabilished. Para o protocolo UDP não existe esta opção, pois ele não tem conexão, ele sempre está pronto para receber e enviar, conforme as aplicações necessitarem. Portanto, se um exercício pedir para você filtrar a comunicação do Telnet com a rede LAN do servidor você teria que determinar:     

Rede de origem e sua máscara Rede de destino e sua máscara (a rede da sua LAN) Pelo protocolo: qual a porta utilizada e se ela é TCP ou UDP Nesse caso a porta de destino é a 23 do protocolo TCP Como são clientes se conectando as portas de origem são varáveis

Lembrando que quando um pacote é formado ele possui os endereços:  

IP de origem e destino, conforme analisamos anteriormente. Portas TCP ou UDP de origem e destino, as quais sobre a direção têm as mesmas características.


   

 

 



   

    

   



Página 110

 

 

  


Porém lembrem que as portas TCP e UDP representam os diversos serviços de redes que os aplicativos das camadas superiores ou aplicações podem utilizar. Aqui temos uma arquitetura cliente/servidor, onde o servidor normalmente tem uma porta bem conhecida e o cliente utiliza uma porta aleatória que inicia acima de um valor padrão. Na continuação do curso veremos como criar as regras utilizando cada tipo de lista de acesso. 2.2 ACL IP Padrão O início da configuração de uma ACL padrão e estendida são o mesmo, ou seja, você entra em modo de configuração global, digita o comando “access-list”, escolhe o número da ACL e inclui o parâmetro “permit” (permitir) ou “deny” (negar), conforme mostrado abaixo. Router(config)#access-list 1 ? deny Specify packets to reject permit Specify packets to forward O “deny” especifica pacotes a serem rejeitados e o “permit” os que serão encaminhados. Na configuração de uma ACL IP padrão, depois de definido se você vai permitir ou negar um pacote você deverá entrar com o IP ou rede de origem e a máscara curinga. Veja a seguir um exemplo onde o tráfego originado da rede 10.0.0.0/8 é permitido. Router#conf Enter configuration commands, one per line. Router(config)#access-list 1 permit 10.0.0.0 0.255.255.255

End

t CNTL/Z.

with

2.3 Máscara Curinga Note que a máscara curinga é formada, assim com a máscara de rede, por quatro octetos de oito bits, sendo que bit 0 na máscara curinga significa que deve haver correspondência e o bit 1 significa que você pode ignorar a correspondência entre o pacote a ser testado e a rede configurada na ACL. Veja o exemplo do item enterior: Router#conf Enter configuration commands, one per line. Router(config)#access-list 1 permit 10.0.0.0 0.255.255.255

End

t CNTL/Z.

with

Um octeto com oito bits zeros (.0) significa que o octeto correspondente no endereço deve ser exatamente igual ao informado na ACL. Já um octeto com oito bits 1 (.255) significa que quaisquer valores são aceitos para aquela entrada.


   

 

 



   

    

   



Página 111

 

 

  


Portanto a dupla - rede e máscara curinga - definem o range de IPs que serão testados na ACL. Seguem alguns macetes para calcular a máscara curinga. 2.3.1 Máscara curinga para selecionar redes classful

A máscara curinga na prática muitas vezes é o contrário da máscara de sub-redes, ou seja, onde é zero na máscara de sub-rede é um na máscara curinga e vice-versa. Essa regra se aplica perfeitamente para redes classe cheia. • Classe A – “10.0.0.0 0.255.255.255” Em uma rede classe A o primeiro octeto é utilizado para a rede e os demais para o host, sendo assim somente o primeiro octeto tem que ser testado para garantir que a rede selecionada seja classe A, os demais octetos podem ser ignorados. Esse mesmo princípio pode ser utilizado para as classes B e C. • Classe B – “130.0.0.0 0.0.255.255” • Classe C – “200.200.100.0 0.0.0.255” 2.3.2 Máscara curinga para apenas um IP (máscara de host)

Nesse caso utilizamos a máscara com todos os bits zero, “End -IP 0.0.0.0” ou o mnemônico “host End-IP”. Lembre que um octeto inteiro “0” significa que você deve testar todos os bits. Exemplo para permitir o micro 10.1.2.21: • Router(config)#access-list 1 permit 10.1.2.21 0.0.0.0 • Router(config)#access-list 1 permit host 10.1.2.21 Usando o mesmo princípio que utilizamos para redes classe cheia, a máscara de sub-rede para um host é a /32 (255.255.255.255), portanto o inverso dela é uma /0 (0.0.0.0)


   

 

 



   

    

   



Página 112

 

 

  


2.3.3 Máscara curinga para permitir quaisquer redes (todas as redes)

Nesse caso utilizamos a máscara com todos os bits em um “0.0.0.0 255.255.255.255” ou o mnemônico “any”. Exemplo: • Router(config)#access-list 1 permit any • Router(config)#access-list 1 permit 0.0.0.0 255.255.255.255 Usando o mesmo princípio que utilizamos para redes classe cheia e de host, a rede que representa todos os IPs (Internet) é 0.0.0.0 0.0.0.0 ou 0.0.0.0/0, portanto sua máscara curinga é 0.0.0.0 255.255.255.255! Lembre-se que esse é um “macete” prático, porque na realidade os bits da máscara curinga e de sub-rede tem significado diferentes! 2.3.4 Selecionando Sub-redes

Nesse caso basta diminuir a máscara /32 (255.255.255.255) da máscara de sub -rede que você está trabalhando. Por exemplo, selecione somente a subnet zero da rede 10.0.0.0/28 para ser permitido na ACL padrão 1: _ 255.255.255.255 255.255.255.240 ________________ 0. 0 . 0 . 15 Portanto a rede e a máscara curinga são: “10.0.0.0 0.0.0.15” Router(config)#Access-list 1 permit 10.0.0.0 0.0.0.15 Note que os três primeiros octetos devem ser iguais e o último octeto é 15 em decimal, ou seja, 00001111 em binário. Se você fizer a variação de 15 em binário você terá: 00000000 - 0 00000001 - 1 00000010 - 2 ... 00001110 - 14 00001111 – 15 Portanto você terá dos IPs 10.0.0.0, 0+1, 0+2,..., 0+14 até 0+15. Agora permitir a terceira sub-rede válida considerando a rede 10.0.0.0 com uma máscara /27 (255.255.255.224): _ 255.255.255.255 255.255.255.224 ________________ 0. 0 . 0 . 31


   

 

 



   

    

   



Página 113

 

 

  


A máscara curinga continua a mesma, porém a rede agora será: “10.0.0.96 0.0.0.31”, pois o range inicia em 10.0.0.96 (terceira sub-rede válida). Router(config)#Access-list 1 permit 10.0.0.96 0.0.0.31 Note que os três primeiros octetos devem ser iguais e o último octeto é 31 em decimal, ou seja, 00011111 em binário. Se você fizer a variação de 31 em binário você terá: 00000000 - 0 00000001 - 1 00000010 - 2 00000011 - 3 00000100 - 4 ... 00011110 - 30 00011111 – 31 Portanto você terá dos IPs 10.0.0.96, 96+1, 96+2,..., 96+30 até 96+31. Ou seja, dos IPs 10.0.0.96 até 10.0.0.127. A próxima sub-rede começa em 10.0.0.128/27. 2.3.5 Selecionando Faixas de Endereços IP

Para selecionar um range (faixa) de IPs ou redes, não importando a sub-rede que ele esteja, você deverá lembrar que a seleção pode ser feita apenas por blocos de IP. Os blocos podem ter tamanho de 2, 4, 8, 16, 32, 64, 128 ou 256 endereços ou redes selecionando 1, 2, 3, 4, 5, 6, 7 ou 8 bits da máscara curinga respectivamente. Para blocos com 4 IPs você poderá ter os IPs ou redes de 0 a 3, 4 a 7, 8 a 11 e assim por diante. Outro exemplo, para blocos com 32 IPs você terá ranges de IP ou rede variando de 0 a 31, 32 a 63, 64 a 95 e assim por diante. Portanto não tem como selecionar exatamente os IPs de 10.0.0.20 a 10.0.0.50, por exemplo, pois estão fora dos blocos. Exemplo: calcule a máscara curinga para permitir que as redes de 200.200.1.0 a 200.200.7.0 sejam negadas em uma ACL. Resolução: as redes de 1 a 7 estão no bloco 8 IPs (de 0 a 7), escolhendo blocos de 4 bits a ACL será a: Router(config)#Access-list 51 deny 200.200.0.0 0.0.7.255

Lembre-se que sempre que o exercício pedir para iniciar um range a partir de 1 você deverá iniciar a partir de 0. Uma maneira de calcular é fazendo o seguinte, por exemplo, o exercício pede para você calcular uma máscara curinga que selecione as redes 172.16.32.0 a 172.16.63.0 com a máscara de subrede /24. Os octetos 172 e 16 nunca irão variar, portanto você colocará 0.0. para esses dois octetos. O octeto 0 pode variar de 0 a 255, pois são os Ips possíveis dessa rede com máscara /24. Agora basta calcular o range de 32 a 63, conforme esquema abaixo: 172.16.32.0 172.16.63.0 ____________ 0. 0 . ? .255 Onde o range está indeterminado siga os seguintes passos:


   

 

 



   

    

   



Página 114

 

 

  


converta o 32 em binário converta o 63 em binário compare os números em binário, onde for igual fica 0 e diferente fica 1: 32 -> 00100000 63 -> 00111111 31 -> 00011111 É o mesmo que diminuir 32 de 63, agora você deverá escolher o método que melhor se adapte a sua forma de estudo e guardar o conteúdo. A máscara curinga é 0.0.31.255. Como rede utilize o IP de número menor (32). Portanto a ACL ficará: Router(config)#Access-list 10 permit 172.16.32.0 0.0.31.255

Utilizando os exemplos acima, podemos escrever uma ACL que bloqueie o tráfego das redes 200.200.0.0 a 200.200.7.0 e permita a passagem dos pacotes das redes 172.16.32.0 a 172.16.63.0: Router(config)#Access-list 10 deny 200.200.0.0 0.0.7.255 Router(config)#Access-list 10 permit 172.16.32.0 0.0.31.255

Ou aproveitando o deny implícito que o IOS coloca no final da lista poderíamos apenas permitir o tráfego referente à rede 172.16 que automaticamente todas as demais redes estariam bloqueadas: Router(config)#Access-list 10 permit 172.16.32.0 0.0.31.255 Router(config)#Access-list 10 deny any (implícito)

Outro exemplo interessante é quando há solicitação de bloqueio de apenas algumas redes, pois você deverá lembrar-se de permitir alguma rede no final ou sua ACL bloqueará todo o tráfego que passar pela interface em que ela for aplicada. Por exemplo: Router(config)#Access-list 10 deny 200.200.0.0 0.0.7.255

A ACL acima bloqueia as redes de 200.200.0.0 até 200.200.7.0, porém bloqueará todo o tráfego restante devido ao deny implícito colocado pelo IOS. Para solucionar o problema insira o comando: Router(config)#Access-list 10 permit any

Assim as demais redes serão permitidas. Lembre-se que sempre que sua ACL iniciar com um “deny” você deve ter no mínimo um “permit”.


   

 

 



   

    

   



Página 115

 

 

  


2.3.6 Máscaras Curinga Esdrúxulas

Os casos que estudamos de máscaras curingas são os tradicionais, porém na prática podemos utilizar em ocasiões especiais máscaras que não parecem corretas, porém tem um certo significado, por isso são esdrúxulas ou diferentes, no popular “sinistras”... Por exemplo, podemos fazer uma máscara que só deixe passar endereços pares, basta configurar o último bit da máscara curinga em zero que nenhum número ímpar será selecionado. Veja exemplo abaixo: Router(config)#Access-list 10 permit 10.0.0.0 0.0.0.254

Nesse caso os IPs que será selecionados devem ter os primeiros três octetos iguais a 10.0.0 e no último octeto temos 0 na rede e na máscara curinga 254, convertendo em binário 11111110. Então esse octeto deixa passar tudo que tenha o último bit igual a zero, que é a característica de um número par em binário! Esse exemplo foi dado porque não devemos ignorar máscaras diferentes do padrão que estamos acostumados, pois se o examinador quiser fazer uma questão de ACL mais complexa está aí onde ele consegue diferenciar “o joio do trigo”! 2.4 ACL IP Estendida As Listas de Acesso estendidas são utilizadas quando você deseja permitir, por exemplo, tráfego http (web) e negar o FTP (File Transfer Protocol) ou telnet de redes que não sejam da empresa, ou seja, vão além do endereço IP de origem e testam também condições dentro da camada-4. As ACLs estendidas verificam os endereços IP de origem e destino dos pacotes, protocolos específicos, números de portas (TCP e UDP) e outros parâmetros. As ACLs estendidas usam um número de intervalo de 100 a 199. Veja a seguir a sintaxe para configurar a ACL estendida. Access-list <100-199> Permit/deny Protocolo Rede/IP-origem Máscara-curinga Opções-origem Rede/IP-destino Máscara-curinga Opções-destino Demais-opções

Os protocolos podem ser definidos pelo número de 0 a 255 (referente ao protocolo IP) ou através dos mnemônicos: ahp, eigrp, esp, gre, icmp, igmp, igrp, ip, ipinip, nos, ospf, pcp, pimm, tcp e udp. Os mais utilizados são “ ip” o qual representa todos os protocolos, icmp, tcp e udp. A rede de origem é analisada no campo “IP de origem” do cabeçalho do pacote IP, já o destino é analisada no campo “IP de destino” do cabeçalho do pacote IP. Importante: Quando você estiver analisando um pacote que entra em sua rede, o IP de origem será um IP pertencente à rede remota e o de destino pertencente a sua própria rede. Agora, no caso de um pacote que está sendo enviado da rede interna para um roteador externo (exemplo: acesso a Internet) o IP de origem será da sua própria rede e o de destino será da rede externa. Essa análise deve ser bem entendida para resolver os problemas relativos a ACL. As opções para origem e destino são: eq, gt, lt, neq e range. O mais utilizado é o “eq”, que significa equal ou igual, serve para selecionar uma porta TCP ou UDP por exemplo.


   

 

 



   

    

   



Página 116

 

 

  


As demais opções podem ser: ack, dscp, established, fin, log, log-input, precedence, psh, rst, syn, time-range, tos e urg. As mais utilizadas são: “log” - envia uma informação quando a instrução for casada, ou seja, houve correspondência para aquela instrução da ACL, para um servidor de “syslog”. “estabilished” - testa se a conexão TCP já está aberta (bit ack do protocolo TCP diferente de zero). O cálculo da máscara curinga é o mesmo realizado para ACL padrão. 



2.5 Exemplo de ACL Estendida Para melhor ilustrar o uso de uma ACL estendida vamos a um exemplo. Você deve criar uma ACL que permita a entrada de quaisquer redes externas no caso de acesso a Web (http), FTP. Para o telnet permitir acesso apenas aos Ips da rede 10.0.0.0/24. Para os demais serviços negar acesso. A resolução você pode verificar a seguir e logo após temos uma explicação mais detalhada de como chegamos nesse resultado. Router(config)#access-list Router(config)#access-list Router(config)#access-list Router(config)#access-list

100 100 100 100

permit permit permit permit

tcp tcp tcp tcp

any any eq 80 any any eq ftp any any eq ftp-data 10.0.0.0 0.0.0.255 any eq 23

O primeiro statement ou instrução indica que você permitiu acesso ao protocolo TCP (“access list 100 permit tcp”), para quaisquer redes de origem e destino (“any any”) para porta 80 (“eq 80”), a qual é a porta referente ao serviço http. Na segunda e terceira instrução foi permitido acesso ao FTP, o qual possui dois canais TCP, um para dados e outro para controle. Note que ao invés do número da porta foram utilizados mnemônicos, porém somente algumas portas o possuem. Abaixo segue a lista dos mnemônicos, sendo que os mais importantes estão em negrito: DlteC-FW-GW(config)#access-list 100 permit tcp any any eq ? <0-65535> Port number bgp Border Gateway Protocol (179) chargen Character generator (19) cmd Remote commands (rcmd, 514) daytime Daytime (13) discard Discard (9) domain Domain Name Service (53) drip Dynamic Routing Information Protocol (3949) echo Echo (7) exec Exec (rsh, 512) finger Finger (79) ftp File Transfer Protocol (21) ftp-data FTP data connections (20) gopher Gopher (70) hostname NIC hostname server (101) ident Ident Protocol (113) irc Internet Relay Chat (194) klogin Kerberos login (543) kshell Kerberos shell (544) login Login (rlogin, 513) lpd Printer service (515) nntp Network News Transport Protocol (119) pim-auto-rp PIM Auto-RP (496) pop2 Post Office Protocol v2 (109)


   

 

 



   

    

   



Página 117

 

 

  


pop3 smtp sunrpc tacacs talk telnet time uucp whois www

Post Office Protocol v3 (110) Simple Mail Transport Protocol (25) Sun Remote Procedure Call (111) TAC Access Control System (49) Talk (517) Telnet (23) Time (37) Unix-to-Unix Copy Program (540) Nicname (43) World Wide Web (HTTP, 80)

Na última linha de instruções foi inserido o comando para permitir acesso ao protocolo TCP (“access-list 100 permit tcp”), para a rede de origem 10.0.0.0/24 (“10.0.0.0 0.0.0.255”), para quaisquer redes de destino (any) quando o tráfego for direcionado ao telnet (eq 23 ou eq telnet). O comando para bloquear o restante do tráfego não precisa ser inserido, pois o IOS colocará para você a linha “access-list 100 deny ip any any” no final da sua configuração, porém ela não aparecerá no comando “show running-config” por ser um comando implícito. O parâmetro “ip” inserido no campo do protocolo seleciona todos os protocolos possíveis. 2.6 Verificando as ACLs Criadas Para verificar as ACLs padrão e estendida você pode utilizar os comandos: 

 

“show run” – mostra as ACLs configuradas e onde elas foram aplicadas (em que interfaces) “show access-lists” – Mostra todas as ACLs “show ip access-lists” – Mostra apenas as ACLs IP

Nos comandos “show Access-list” e “show ip Access-list” você pode ainda colocar o número da ACL para verificar somente ela. Para verificar onde uma ACL foi aplicada (em que interface) e se ela é de entrada ou saída entre com o comando “show ip interface”, somente esse comando mostra o posicionamento de uma ACL. Router#sho ip access-lists Standard IP access list 1 permit 10.1.2.21 permit 10.0.0.0, wildcard bits 0.255.255.255 permit any Extended IP access list 100 permit ip 10.0.0.0 0.0.0.255 11.0.0.0 0.0.0.255 permit tcp any any eq www permit tcp any any eq ftp permit tcp any any eq ftp-data permit tcp 10.0.0.0 0.0.0.255 any eq telnet Router#show access-lists Standard IP access list 1 permit 10.1.2.21 permit 10.0.0.0, wildcard bits 0.255.255.255 permit any Extended IP access list 100 permit ip 10.0.0.0 0.0.0.255 11.0.0.0 0.0.0.255 permit tcp any any eq www permit tcp any any eq ftp


   

 

 



   

    

   



Página 118

 

 

  


permit tcp any any eq ftp-data permit tcp 10.0.0.0 0.0.0.255 any eq telnet

2.7 Listas de Acesso Nomeadas As listas de acesso estudadas acima foram a padrão e a estendida numeradas. Você pode configurar uma ACL padrão e estendida com uma ACL nomeada também. A vantagem de uma ACL nomeada é que você pode utilizar um nome sugestivo para guardar a ACL e lembrar para que fim essa ACL foi criada. Além disso ela estende o range de ACLs que podem ser criadas. Veja o exemplo a seguir para a criação da ACL padrão com o nome de “bloqueiarede”. Note que a configuração feita foi para bloquear o acesso à rede 172.16.20.0/24 e permitir quaisquer outras redes. Lab_A#config t Enter configuration commands, one per line. End with CNTL/Z. Lab_A(config)#ip access-list ? extended Extended Acc (ACL estendida) logging Control access list logging Standard Standard Access List (ACL padrão) Lab_A(config)#ip access-list standard ? <1-99> Standard IP access-list number WORD Access-list name Lab_A(config)#ip access-list standard bloqueiarede Lab_A(config-std-nacl)#? Standard Access List configuration commands: default Set a command to its defaults deny Specify packets to reject exit Exit from access-list configuration mode no Negate a command or set its defaults permit Specify packets to forward Lab_A(config-std-nacl)#deny 172.16.20.0 0.0.0.255 Lab_A(config-std-nacl)#permit any Lab_A(config-std-nacl)#exit Lab_A(config)#^Z


   

 

 



   

    

   



Página 119

 

 

  


2.8 Aplicando ACL nas Interfaces Após criar a ACL em modo de configuração global, você deve aplicá-la em uma interface. É importante lembrar que a ACL pode ser de entrada (inbound – in) ou de saída (outbound – out). A figura a seguir ilustra o sentido de aplicação de uma ACL em relação ao tráfego IP.

No sentido de entrada (in) os pacotes são processados pela lista de acesso antes de serem encaminhados pela interface de saída. Já no sentido de saída (out) os pacotes são primeiro encaminhados para a saída para depois serem processados pela lista de acesso. Note que para bloquear um pacote IP que vem pela interface s0/0 em direção a LAN de R1 (f0/0), você pode utilizar uma ACL de entrada na s0/0 ou uma de saída na f0/0. Agora para bloquear um pacote que sai da LAN de R1 em direção a outras redes pode ser filtrado por uma ACL de entrada na interface f0/0 ou de saída na s0/1. O comando para aplicar a ACL em uma interface é o “ip access-group” em modo de configuração de interface, veja o exemplo a seguir, onde a lista 101 é aplicada no sentido de saída da interface serial 0 do roteador. Router#conf t Enter configuration commands, one per line. Router(config)#int s0 Router(config-if)#ip access-group 101 out Router(config-if)#^Z Router#

End with CNTL/Z.


   

 

 



   

    

   



Página 120

 

 

  


2.9 Limitando Acesso ao SSH e Telnet nos Roteadores Você também pode limitar o acesso ao telnet via VTY utilizando o comando “access-class”, dentro da line vty, conforme mostrado a seguir. Router(config)#access-list 10 permit 10.0.0.0 0.0.0.255 Router(config)#line vty 0 15 Router(config-line)#access-class 10 in Router(config-line)#^Z Router#

No exemplo a lista de acesso 10 que é aplicada na line vty do roteador (comando “access class”) limita a entrada via telnet apenas para os micros 10.0.0.1 até 10.0.0.254. Os demais IPs não terão acesso ao telnet do roteador via VTY devido ao deny implícito. A configuração mostrada é a mesma para roteadores ou switches Cisco. O mesmo comando pode limitar acesso via Telnet ou SSH quando micros remotos tentarem se conectar aos roteadores e/ou switches. Portanto, uma ACL deve ser aplicada em todas as portas vty na direção que previna um usuário não permitido acessar essa porta desprotegida, através do comando “access-class”. 2.10 Exemplos Práticos de ACLs 2.10.1 Exemplo 1 – ACL Padrão

A empresa ABC Inc tem a política interna de liberar o acesso remoto aos equipamentos de rede somente para os micros de gerenciamento inseridos na rede 192.168.1.0/28. Sua tarefa é criar uma ACL que limite acesso remoto apenas aos micros pertencentes a essa rede. Para resolver a solicitação acima temos primeiro que criar a lista padrão escolhendo a rede 192.168.1.0/28 (255.255.255.240). Qual a máscara curinga? Lembre-se de subtrair o broadcast da máscara em questão. Será “255.255.255.255 - 255.255.255.240 = 0.0.0.15” Criando a lista: Router#conf t Router(config)#access-list 10 permit 192.168.1.0 0.0.0.15

Como existe um deny (negação) implícito no final de uma ACL somente o comando acima é o suficiente para criar a lista, pois ele deixará passar apenas os IP’s da rede 192.168.1.0/24 e os demais serão bloqueados. Agora vamos aplicar a regra na entrada line vty: Router(config)#line vty 0 15 Router(config-line)#access-class 1 in Router(config-line)#end Router#copy run start

Com essa config os equipamentos estarão protegidos de acesso não autorizado pelos micros fora da rede de gerenciamento.


   

 

 



   

    

   



Página 121

 

 

  


2.10.2 Exemplo 2 – ACL Estendida

Agora você deve configurar em um roteador, que tem a sub-rede 192.168.1.0/26 em sua LAN (Fast 0/0) que está entroncada com um Switch de acesso e possui várias sub-redes na mesma interface, para que a rede 192.168.1.128/26 seja bloqueada quando tentar acessar os serviços de FTP e TFTP em quaisquer micros e servidores dentro dessa sub-rede específica. Todas as demais sub-redes devem ser permitidas para todos os serviços. O primeiro passo é verificar as portas e protocolos dos serviços a serem bloqueados: FTP: portas 20 e 21 do TCP TFTP: porta 69 do UDP Note que os pacotes serão originados na sub-rede 192.168.1.128 e chegarão na rede de destino 192.168.1.0, ou seja, os micros da sub-rede 192.168.1.128 estão em um roteador remoto. Após isso vamos selecionar a sub-rede de origem a ser bloqueada (ponta remota): 192.168.1.128 /26 ou 255.255.255.192 -> Máscara curinga = 255.255.255.255 – 255.255.255.192 = 0.0.0.63. A sub-rede do roteador de destino (rede do roteador): 192.168.1.0 /26 ou 255.255.255.192 -> Máscara curinga = 255.255.255.255 – 255.255.255.192 = 0.0.0.63. Agora vamos criar a lista considerando: 1. Bloquear acesso ao FTP da sub-rede 192.168.1.128 à sub-rede 192.168.1.0: Access-list 100 deny tcp 192.168.1.128 0.0.0.63 192.168.1.0 0.0.0.63 eq 20 Access-list 100 deny tcp 192.168.1.128 0.0.0.63 192.168.1.0 0.0.0.63 eq 21

2. Bloquar acesso ao TFTP considerando as mesmas redes do item 1: Access-list 100 deny udp 192.168.1.128 0.0.0.63 192.168.1.0 0.0.0.63 eq 69

3. Permitir as demais redes: Access-list 100 permit ip any any

Ou podemos utilizar os comandos abaixo substituindo o número das portas pelos seus mnemônicos. Access-list Access-list Access-list Access-list

100 100 100 100

deny tcp 192.168.1.128 0.0.0.63 192.168.1.0 0.0.0.63 eq ftp deny tcp 192.168.1.128 0.0.0.63 192.168.1.0 0.0.0.63 eq ftp-data deny udp 192.168.1.128 0.0.0.63 192.168.1.0 0.0.0.63 eq tftp permit ip any any

Criada a lista 100 agora teremos que ativar na interface LAN do roteador: Interface fast 0/0 Ip access-group 100 out

A lista foi aplicada na saída da interface LAN, ou seja, quando os pacotes de FTP e TFTP vindos da rede 192.168.1.128/26 tentarem sair pela interface serão bloqueados. As demais subredes serão permitidas. Você pode verificar a ACL com o comando “show ip interfaces” e “show ip access-list 100”.


   

 

 



   

    

   



Página 122

 

 

  


2.10.3 Exemplo 3 – ACL Nomeada Estendida

Agora vamos repetir o exercício anterior utilizando ACL nomeada estendida. Uma ACL estendida é criada com o comando “ip access-list [extended | standard] nome”. As regras serão criadas dentro do modo de configuração de ACL. Lab_A(config)#ip access-list extended Exemplo3 Lab_A(config-ext-nacl)#deny tcp 192.168.1.128 0.0.0.63 192.168.1.0 0.0.0.63 eq ftp Lab_A(config-ext-nacl)#deny tcp 192.168.1.128 0.0.0.63 192.168.1.0 0.0.0.63 eq ftp-data Lab_A(config-ext-nacl)#deny udp 192.168.1.128 0.0.0.63 192.168.1.0 0.0.0.63 eq tftp Lab_A(config-ext-nacl)#permit ip any any Lab_A(config-ext-nacl)#exit Lab_A(config)#Interface fast 0/0 Lab_A(config-subif)#Ip access-group Exemplo3 out Lab_A(config-subif)#end Lab_A#copy run start

2.11 Resumo sobre ACL’s Padrão e Estendidas Vamos lembrar das regras básicas sobre a criação e funcionamento de uma ACL. 



 







ACLs são criadas em modo de configuração global e, em seguida, aplicadas em uma interface. Uma ACL pode filtrar o tráfego que passa através do roteador, em trânsito ou que vai para o roteador, dependendo de como ela é aplicada (em que interface e que direção – in/out). Apenas uma ACL por interface - por protocolo roteado, por direção - é permitida. O termo standard/padrão ou extended/estendida indica que informação pode ser utilizada para filtrar pacotes. ACLs são processadas de cima para baixo. Uma vez que um pacote passar em um teste da ACL, o processamento para e o pacote é permitido ou negado, portanto, as declarações ou statements mais específicas devem ir ao topo da lista, ou seja, o que tem maior probabilidade de ocorrer (dar match) deve ir primeiro. Todas as ACLs tem uma negação implícita "deny any" no final, portanto, cada lista deve ter pelo menos uma declaração de autorização (permit) para permitir o tráfego passar. Caso seja criada uma ACL somente com comandos de negação ou deny todo o tráfego na interface que ela for aplicada será bloqueado. Uma ACL padrão deve ser aplicada mais próximo ao destino do tráfego a ser bloqueado, pois ela somente verifica pacotes de origem. Já uma ACL estendida deve ser aplicada mais próxima à origem do tráfego a ser bloqueado, pois assim você evita tráfego desnecessário passando pela rede. Veja a figura a seguir.


   

 

 



   

    

   



Página 123

 

 

  










Quando novas entradas ou statements são adicionadas a uma ACL já criada, eles são sempre adicionados no final da lista, ou seja, se você adicionar um statement ele será o último comando a ser analisado. Por isso, recomenda-se quando necessário alterar uma ACL apagar a antiga e criar uma nova. Se você estiver usando Cisco IOS Versão 12.3 ou posterior, números de sequência podem ser utilizados para garantir que uma nova instrução seja adicionada no local correto. A ACL é processada de cima para baixo com base nos números de sequência das declarações (do mais baixo ao mais alto). Alguns pacotes gerados pelo roteador, como atualizações de tabela de roteamento, não estão sujeitos à filtragem por ACL no roteador de origem. Se a política de segurança requer filtrar esses tipos de pacotes, ACLs de entrada em roteadores vizinhos ou outros mecanismos de filtragem devem ser utilizados.

2.12 Atividade Prática Vimos no decorrer do capítulo alguns conceitos importantes de segurança e também sobre as ACL's em roteadores Cisco. Agora você deve praticar o que aprendeu. Faça o laboratório de desafio ACL que se encontra na página de programação do curso no capítulo 05. Importante: para a realização da atividade prática abra o arquivo correspondente "Lab_Desafio_de_ACL.pkt". Boa prática.


   

 

 



   

    

   



Página 124

 

 

  


3 Configurando ACL Padrão e Estendida via CCP Usando o Cisco CCP, o administrador pode criar regras de acesso para negar certos tipos de tráfego, permitindo ao mesmo tempo acesso a outros tipos. Cisco CCP fornece regras padrões para criar listas de controle de acesso, sendo que essas regras definem como um roteador trata um determinado tipo de tráfego. Um administrador também pode ver as regras que foram criadas de outras formas, sem o uso Cisco CCP, chamadas de regras externas (Externally defined rules), bem como as regras que o Cisco CCP não suporta, que são chamadas de regras sem suporte (Unsupported rules). Você pode ver um resumo das ACLs criadas em “Configure > Router > ACL > ACL Summary”. Para acessar a configuração das regras vá em “ Configure > Router > ACL > ACL Editor”. Clicando em Add você pode definir o nome da regra. Além disso, você pode colocar uma descrição, que via CLI é feito com o comando “remark”. Para criar os statements ou testes você deve cliclar em Add na tela de criação da ACL, selecionar se o tráfego deve ser permitido (permit) ou negado (deny), escolher o tipo de tráfego (se um host ou uma rede por exemplo) e definir o IP. Também é possível colocar um description e selecionar se o statement deve ser logado ou não. Caso você marque o checkbox “log matches...” cada pacote que for compatível com a regra gera um log para o seu servidor de Syslog, por exemplo. Vale a pena lembrar que se você escolher uma rede ao invés de um host no menu dropdown “Source Host/Network”, a opção de rede(network) e máscara curinga (wildcard mask) será fornecida pelo CCP para a configuração. Assim como na configuração via CLI, após criar a lista (ACL) e suas regras ou statements, você deve vincular a lista a uma interface de entrada (inbound) ou de saída (outbound). Para fazer essa operação clique em “Associate” e vincule a regra na interface/direção desejada, conforme figura ao lado. Para visualizar a configuração aplicada no roteador vá ao menu View e clique em Running Config para analisar os comandos aplicados. Esse menu está logo abaixo em Utilities. 4

ACL Reflexiva - Reflexive ACLs

Agora começamos realmente a novidade! Essa é uma feature do Cisco IOS introduzida na versão 11.3 ou superior que tem a capacidade de filtrar o tráfego baseada nas informações da sessão TCP/UDP e não somente portas TCP/UDP e endereço IP. Esse tipo de ACL aprende as informações da sessão dinamicamente e permitem o tráfego de retorno somente com base no tráfego de saída, ou seja, as informações da sessão TCP criada pelo usuário ao acessar um conetúdo externo são utilizadas para criar uma ACL dinâmica que permite somente a entrada da resposta à solicitação original.


   

 

 



   

    

   



Página 125

 

 

  


As ACLs reflexivas criam filtros temporários no início da sessão entre dois hosts, os quais são removidos quando essa sessão é finalizada. Pré-Requisitos de seu funcionamento:  

As ACLs devem ser IP; Deve ser do tipo estendida e nomeada.

Para entender melhor o uso das ACLs reflexivas vamos analisar o seguinte cenário, conforme figura mostrada a seguir. Nesse cenário temos o roteador R1 representando a rede interna da empresa, o roteador R2 é o que está entre a rede Interna e a Internet e o R3 representa um host que está na Internet.

Analisando a situação real em uma empresa, os micros da rede Interna apenas fazem conexão com o mundo externo via Internet. Se você verificar na figura quando um micro quer acessar a web via HTTP ele abre uma conexão TCP com um servidor da Internet e esse servidor responderá a essa requisição. Quando um micro abre a conexão TCP os bits ACK ou RST estão ainda em zero, representando a abertura de uma sessão TCP e as portas utilizadas nesse caso sempre serão as mesmas, 80 no servidor HTTP e acima de 1024 no computador. No processo inverso, quando um host externo tenta acessar a rede interna ele enviará uma solicitação de uma abertura de conexão TCP, no exemplo da figura a solicitação é para o serviço de FTP para um computador qualquer da rede Interna, o que deve ser considerado um ataque e bloqueado pelo roteador R2. Normalmente no passado isso seria feito com o comando estabilished presente nas ACLs estendidas, conforme comando mostrado a seguir.


   

 

 



   

    

   



Página 126

 

 

  


R2(config)#Access-list 100 permit tcp any any estabilished R2(config)#Access-list 100 deny any any R2(config)#Int s0 R2(config-if)#ip access-group 100 in R2(config-if)#end R2#

Na lista ao lado permitimos apenas o tráfego TCP que estiver estabelecido entrar na rede e chegar até o R1. Porém, agora vamos analisar os prós e contras dessa solução: 







O que vai acontecer com o tráfego UDP nesse caso? O UDP não é orientado a conexão e você terá que escolher o que passar do UDP e bloquear os demais serviços. E se um atacante enviar um segmento TCP falso com um IP falso e a conexão estabelecida? E se essa conexão for enviada diversas vezes para fazer uma negação de serviços com IP’s falsos e conexões estabelecidas? Como monitorar além da porta estabelecida e verificar se a sessão é realmente verdadeira? Ou seja, iniciada por um micro interno?

Para isso as ACLs reflexivas foram criadas. Com ela você criará uma lista na direção de entrada (inbound) que servirá de referência para os pacotes que deverão sair (outbound) da interface em direção à rede Interna. 4.1 Configurando Listas de Acesso Reflexivas Para configurar uma ACL reflexiva siga os passos abaixo: 1. Pense sobre a interface que você vai aplicar a ACL. Utilizar a Reflexive ACL é configurar essa lista na mesma interface aplicada em direções opostas. 2. Configure uma lista de acesso estendida nomeada que filtra o tráfego de saída da rede interna. Ela deve conter pelo menos um comando “reflect” que inicia a lista de acesso temporária. 3. Aplique esta lista de acesso na interface escolhida na direção correta. 4. Configure uma lista de acesso estendida nomeada que filtrará o tráfego de resposta. Ela deve conter pelo menos um comando “evaluate” que determina a análise do tráfego de retorno. 5. Aplique esta lista de acesso na interface escolhida na direção correta, geralmente a mesma interface como anteriormente, mas aplicadas na direção oposta. 6. Cuidado com a direção, pois analisando a topologia da figura, se você escolher a interface S0 do roteador 2 para aplicar a lista reflexiva, o passo 3 deve ser colocado na direção de saída (outbound) e o passo 5 na direção de entrada (inbound). Caso você escolha a S1 do mesmo roteador deve inverter os comandos, pois o tráfego que vai para a internet iniciado pela rede interna estará na direção de entrada (in) e o retorno na direção de saída (out). Vamos a um exemplo prático para aprender os comandos onde vamos analisar todo o tráfego TCP e UDP com a ACL reflexiva no roteador R2, utilizando a figura da topologia mostrada anteriormente como referência.


   

 

 



   

    

   



Página 127

 

 

  


1. Crie uma lista estendida nomeada que "analise" os pacotes de saída da rede interna pela serial 0 do roteador R2: ip access-list extended analise-dos-pacotes-de-saida permit tcp any any reflect tcp-reflexive-temporary-list permit udp any any reflect udp-reflexive-temporary-list

2. Agora crie uma lista de acesso nomeada estendida que avalie os pacotes de retorno através da diração de inbound que vem da internet para a intranet: ip access-list extended captura-pacotes-de-entrada evaluate tcp-reflexive-temporary-list evaluate udp-reflexive-temporary-list

3. Agora vamos aplicar a ACL na interface conforme diretivas: interface serial 0 ip access-group analise-dos-pacotes-de-saida out ip access-group captura-pacotes-de-entrada in

Além disso, você pode criar as demais regras da sua ACL em conjunto com os comandos das ACL’s reflexivas. Recomenda-se que o tráfego a ser analisado seja somente aquele que foi permitido sair da sua rede interna e não como o exemplo acima, pois você pode sobrecarregar o seu roteador. Você ainda pode mudar o timeout da lista temporária criada para cada sessão com o comando “ip reflexive-list timeout segundos”, por exemplo, para alterar o valor padrão para 200 segundos o comando ficaria “ip reflexive-list timeout 200”.


   

 

 



   

    

   



Página 128

 

 

  


Para verificar a ACL utilize os mesmos comandos mostrados anteriormente, como o “show access-list”. Você ainda deve lembrar que algumas aplicações trocam os números de porta dentro de uma mesma sessão. Essas aplicações inicialmente utilizam uma porta bem conhecida e após estabelecida a sessão mudam as portas, portanto esse tipo de aplicação não vai funcionar com ACL's reflexivas. O FTP ativo é um exemplo de serviço que não funciona com as ACLs reflexivas, o administrador que utilizá-las em sua rede vai precisar de um FTP passivo ao invés do ativo. 5 ACL Dinâmica - Dynamic ACLs ou Lock-and-key Access-lists dinâmicas são ferramentas interessantes, que podem, por exemplo, nos permitir identificar o usuário antes de dar acesso a um determinado recurso (Lock-and-key). Com o Lock-and-key configurado, o usuário pode ter acesso a um host ou rede que era bloqueada inicialmente. Para isso o usuário deve primeiro se autenticar no roteador, via senha Telnet com usuário e senha, utilizando o AAA local ou com TACACS+/RADIUS. Após autenticado a ACL dinâmica é inserida na interface, permitindo o tráfego. Após o tempo limite configurado a ACL é removida, voltando ao cenário inicial (tráfego negado), conforme figura a seguir.

Para configurar uma ACL dinâmica siga os passos abaixo: 1. Crie uma ACL estendida, seja numerada ou nomeda, ambas são suportadas pela ACL dinâmica. A primeira entradas na ACL deve permitir Telnet ou SSH através de um endereço IP do roteador que os usuários externos podem usar para a autenticação. 2. Defina a autenticação. 3. Habilite a autenticação dinâmica O comando para criar a entrada dinâmina na ACL estendida é o mostrado abaixo:


   

 

 



   

    

   



Página 129

 

 

  


Router(config)# access-list {100-199} dynamic dynamic_ACL_name [timeout minutes] {pe rmit | deny} protocol source-addr [source-wildcard] [operator operand] destination-addr [destination-wildcard] [operator operand] [established] Pelo menos uma entrada com a opção dinâmica deve ser criada na mesma ACL estendida do passo 1 para que o processo seja inicializado. O comando “autocommand access-enable” aplicado na VTY é que determina o modo da autenticação, pois será utilizado o que for configurado para a linha VTY. Veja um exemplo do comando abaixo. Router(config)# line vty 0 4 Router(config-line)# autocommand access-enable host [timeout em minutos] O comando timeout limita o tempo de duração da ACL dinâmica criada. 5.1 Exemplo Prático Vamos a um exemplo prático de configuração. Neste cenário o roteador R1 não permite nenhum tipo de tráfego, além do Telnet para sua Loopback. Apenas após o usuário do Micro1 se autenticar ele poderá ter acesso ao Servidor1. Veja a topologia e acompanhe a solução.

1) Crie um usuário (ou quantos desejar), para autenticação local. username dltecuser secret dltecadmin

2) Crie uma Loopback que será usada para autenticação (também é possível usar uma interface física). interface Loopback0. ip address 172.16.1.1 255.255.255.255

3) A primeira linha na ACL 100 permite apenas o Telnet para autenticação (loopback). access-list 100 permit tcp 1.1.1.0 0.0.0.255 host 172.16.1.1 eq telnet

4) A segunda entrada da ACL 100 será a dinâmica, que permitirá acesso total após autenticação. Neste exemplo ela ficará ativa 30 minutos após a autenticação, com ou sem tráfego. access-list 100 dynamic testlist timeout 30 permit ip any any

5) Aplique a access-list 100 na interface por onde o usuário se conectará. interface FastEthernet0/1 ip address 1.1.1.1 255.255.255.0 ip access-group 100 in


   

 

 



   

    

   



Página 130

 

 

  


6) A autenticação utilizada será a local e após se autenticar será encerrado o Telnet, e se não tiver atividade a sessão é finalizada, após 5 minutos (subcomando timeout). line vty 0 4 password cisco login local autocommand access-enable host timeout 5

6

ACL Temporizada – Time-based ACL

Criar ACLs baseadas em períodos (time-based) é uma ferramenta importante para um administrador de redes, pois as empresas atualmente enfrentam o problema do uso das redes sociais e Internet pelos funcionários durante o horário de trabalho. Com uma ACL time-based o administrador pode liberar acesso a Internet apenas a partir de um determinado período do dia, limitando as horas de acesso a Internet, por exemplo. Usamos como exemplo o acesso a Internet, mas poderíamos limitar por horário o acesso a quaisquer serviços. Para configurar uma ACL temporizada devemos seguir 3 etapas: 1. Definir um nome a ser atribuido a um determinado período Router(config)#time-range nome_do_timerange

2. Definir um intervalo em que as ACLs serão aplicadas. Router(config-time-range)# periodic dia_da_semana hh:mm to [dia_da_semana] hh:mm

Valem nomes de dias da semana em inglês e a hora no formato hh:mm. O parâmetro dia_da_semana pode ser: 

  

Um dia específico da semana: Monday, Tuesday, Wednesday, Thursday, Friday, Saturday ou Sunday Daily (todo dia) Weekdays (segunda a sexta) Weekend (sábado e domingo)

Outra forma, seria definir um tempo absoluto definindo apenas a data de inicio e data de fim: Router(config-time-range)# absolute [data_de_inicio] [data_de_fim]

3. Criar uma ACL e aplicar as regras configuradas. Note que o sucesso das time based ACLs depende mais do nosso conhecimento de regras de ACLs já discutidas anteriormente. Router(config)# access-list {100-199} {permit | deny} protocol source-addr [source-mask] [operator operand] destination-addr [destination-mask] [operator operand] [established] [log | log-input] [established] [time-range name_of_time_range]

Depois de criada a ACL aplique em uma interface na direção correta.


   

 

 



   

    

   



Página 131

 

 

  


6.1 Exemplo Prático Vamos a um exemplo prático onde o administrador de rede quer limitar o horário de acesso a Internet pelos funcionários apenas durante a 1 hora de almoço, entre 12:30h e 13:30h, e no intervalo entre dois turnos, o qual vai das 17h às 20h.

R1(config)# time-range Internet-livre R1(config-time-range)# periodic weekdays 12:30 to 13:30 R1(config-time-range)# periodic weekdays 17:00 to 20:00 R1(config-time-range)# exit R1(config)# access-list 110 permit ip 192.168.1.0 0.0.0.255 Internet-livre R1(config)# access-list 110 deny ip any any R1(config)# interface FastEthernet 0/1 R1(config-if)# ip access-group 110 in R1(config-if)# exit

any

time-range

7 Mitigando Ataques com ACLs As ACLS podem ser utilizadas para mitigar alguns tipos de ataques comuns à rede, assim como filtrar alguns tipos de tráfegos não desejados, tais como:     

Spoofing ou falsificação de endereços IP (inbound e outbound) Ataques de DoS através do TCP SYN Ataques de DoS smurf Mensagens ICMP (inbound e outbound), ex. ping Traceroute

Outras regras úteis quando falamos de roteadores que estão conectados à Internet é bloquear os seguintes tipos de tráfego:    



Endereços de loopback (127.0.0.0/8) Endereços privados (RFC 1918 - Address Allocation for Private Internets) Endereços IP de multicast (224.0.0.0/4) Endereços de envio diferentes dos quais estão configurados na rede Interna, assim como o retorno apenas de endereços IPs cujo destino realmente pertença à rede interna. Os serviços mais usuais devem ser liberados no firewall, tais como FTP, HTTP, Telnet e SSH (lembre que o SSH é sempre preferível ao invés do telnet). Os demais serviços devem ser bloqueados.

Por último devemos analisar e limitar o acesso externo ao protocolo ICMP, pois muitos atacantes utilizam esse protocolo para varrer a rede e descobrir subnets e pontos falhos para iniciar ataques.


   

 

 



   

    

   



Página 132

 

 

  


Vamos dividir as recomendações sobre o ICMP em duas categorias que são recomendadas a permissão: 1. Regras para pacotes entrantes ou inbound a. Echo reply – permitir ping somente a hosts autorizados. b. Source quench – requisição para o emissor diminuir a velocidade de envio das mensagens. c. Unreachable –mensagens de unreachable. 2. Regras para pacotes saintes ou outbound a. Echo – permitir que os usuários internos pinguem endereços externos. b. Parameter problem – informa sobre problemas no cabeçalho do pacote. c. Packet too big – utilizado para descobrir o maximum transmission unit (MTU) configurado. d. Source quench – diminui o tráfego quando necessário. 7.1 Exemplo Prático Vamos a um exemplo prático de configuração para ilustrar os exemplos de mitigação com uso de ACL. Para o exemplo vamos utilizar a figura da topologia.

Primeiro vamos às regras para os pacotes vindos da Internet em direção à Intranet, no exemplo acima que partem do roteador R3 tentando acessar a Intranet. Esses pacotes serão filtrados em uma ACL aplicada na direção de entrada ou inbound da serial 0 do roteador R2. Hostname R2 Access-list 110 deny 0.0.0.0 0.255.255.255 any Access-list 110 deny 10.0.0.0 0.255.255.255 any Access-list 110 deny 172.16.0.0 0.15.255.255 any Access-list 110 deny 192.168.0.0 0.0.255.255 any Access-list 110 deny 224.0.0.0 0.255.255.255 any Access-list 110 deny host 255.255.255.255 any Access-list 110 deny ip 192.168.1.0 0.0.0.255 any ! ! As regras acima previnem contra o spoofing de IP de for a para dentro. ! Note que tem uma regra para a rede 192.168.1.0 que é a rede interna ! e deixamos ela mesmo já tendo uma regra acima que abrange essa regra ! para explicitar a necessidade de bloquear o acesso externo ! com a tentativa de usar o IP interno como origem ! Access-list 110 permit icmp any any echo-reply Access-list 110 permit icmp any any source-quench Access-list 110 permit icmp any any unreachable Access-list 110 deny icmp any any Access-list 110 permit ip any any !


   

 

 



   

    

   



Página 133

 

 

  


Int serial 0 Ip access-group 110 in

Note que tratamos apenas dos itens mencionados nesse capítulo, as regras devem ir além e bloquear todos os serviços considerados não necessários, deixando passar apenas os permitidos. Agora vamos adicionar regras para pacotes que são gerados no roteador R1, na rede Interna, e desejam acessar a Internet. A rede dos micros do roteador R1 é a 192.168.1.0/24 Access-list 120 permit icmp 192.168.1.0 0.0.0.255 any echo Access-list 120 permit icmp 192.168.1.0 0.0.0.255 any parameter-problem Access-list 120 permit icmp 192.168.1.0 0.0.0.255 any packet-too-big Access-list 120 permit icmp 192.168.1.0 0.0.0.255 any source-quench Access-list 120 deny icmp any any Access-list 120 permit ip 192.168.1.0 0.0.0.255 any ! ! A regra acima previne contra o spoofing de IP de dentro para fora. ! As demais são relacionadas ao ICMP. ! Note que nesse exemplo o tráfego UDP foi completamente bloqueado. ! Int serial 1 Ip access-group 120 in

7.2 Mitigando Ataques ao SNMP Você pode ainda, de uma maneira simples, mitigar ataques ao roteador via o protocolo SNMP definindo uma lista de acesso com os IP’s permitidos para gerenciamento, o qual é aconselhável ter bem definido em uma rede as estações de gerenciamento. Veja os comandos a seguir. R1(config)# access-list 80 permit host 10.0.0.3 R1(config)# snmp-server community snmp-host1 ro 80

No exemplo foi criada uma lista de acesso padrão numerada 80 com o IP do host de gerenciamento 10.0.0.3. Essa lista foi ligada ao comando “snmp-server community snmp-host1 ro”, já analisado em capítulos anteriores, simplesmente inserindo o número da ACL no final (80), o que faz uma restrição para apenas esse IP acessar as informações via SNMP do roteador R1.


   

 

 



   

    

   



Página 134

 

 

  


8 Mitigando Riscos de Segurança com ACLs IPV6 Apesar do IPv6 ter diferenças no cabeçalho e formato do endereço as listas de acesso são parecidas com as ACLs nomeadas que criamos e estudamos até o momento para o IPv4. Assim como os objetivos de filtragem e controle de tráfego que entra e sai na rede são os mesmos, porém o IPv6 tem algumas características próprias e novas em relação ao IPv4. A ACL IPv6 também pode ser utilizada em outras configurações como selecionador de redes de origem e/ou destino que farão parte daquele serviço específico. Devemos ter em mente que o IPv6 não terá redes públicas e privativas como no IPv4 com o NAT. O NAT naturalmente já implementa um certo grau de proteção aos roteadores porque as redes internas das empresas utilizam endereços não roteáveis na Internet. No IPv6 teremos os hosts que precisam acessar a Internet com endereços “quentes” a princípio, por isso os firewalls e listas de acesso precisarão lidar com essa nova realidade. As versões atuais dos roteadores com Cisco IOS já tem implementado por padrão algumas regras, por exemplo, de não deixar entrar pacotes IPv6 com cabeçalho de extensão de roteamento (routing header - RH0). Se por acaso o roteador não tiver esse recurso implementado será necessário criar uma ACL para filtrar esse tipo de tráfego. Outro risco de segurança do IPv6 é o tunelamento que será utilizado como técnica de convivência e migração entre IPv4 e IPv6, por exemplo, o Windows utiliza túneis Teredo que já vem configurados por padrão nos computadores. Através desses túneis usuários poderiam acessar sites ou recursos não permitidos em IPv4 através do IPv6 sem que o administrador de rede perceba se não houver monitoração e filtragem desse tipo de tráfego. O ICMPv6 também é diferente do ICMP para IPv4, tanto que existe até uma recomendação para tratar o assunto na RFC 4890 - ICMPv6 Filtering Recommendations (recomendações para filtragem do IPv6). Várias funções de protocolos auxiliares do IPv4 foram incorporados pelo ICMPv6, por exemplo, o ARP foi colocado no protocolo NDP que é parte do ICMPv6. A autoconfiguração é outro assunto a ser tratado e podemos proteger a rede contra esse tipo de ataque colocando listas de acesso nas portas dos switches de acesso bloqueando mensagens de RA (router advertisement) onde não estão roteadores realmente autorizados a enviar esse tipo de mensagem, porém existem mecanismos mais avançados para tratar esse tipo de problema. Os conceitos básicos do IPv6 são alvo de estudo atualmente do CCNA R&S, mais especificamente em nosso curso CCNA CCENT, pois o IPv6 está em quase toda sua totalidade no material do ICND-1. Também temos nosso curso de IPv6 próprio, onde tratamos de vários assuntos e também conceitos mais avançados de segurança, inclusive até com uma ferramenta para testar vulnerabilidades em redes IPv6, vale a pena conferir se você tem interesse em realmente aprender o IPv6.


   

 

 



   

    

   



Página 135

 

 

  


8.1 O que uma ACL IPv6 pode filtrar? Lembre-se que um endereço IPv6 tem 128 bits e é escrito em hexadecimal, não mais em decimal pontuado, portanto as redes de origem e destino nas ACLs serão diferentes. Já os protocolos de camadas superiores, tais como TCP e UDP continuam os mesmos, por exemplo, para bloquear acesso ao HTTP no IPv6 é só selecionar na ACL o protocolo TCP porta 80. As ACLs IPv6 podem basicamente filtrar os seguintes itens:   







Endereços e/ou redes de origem e destino. Portas TCP e/ou UDP de origem e destino. Filtrar pacotes com cabeçalhos de extensão com base na informação do “next header” (próximo cabeçalho) ou então que contenha simplesmente a opção “Next header”. O deny implícito também está presente no final da ACL, porém com a exceção de pacotes de neighbor solicitation (NS) e neighbor advertisement (NA), pois eles são implicitamente habilitados. Se você quiser bloquear tudo no final de uma ACL IPv6 você precisará incluir regras explícitas com deny para o NS e NA. Se uma ACL que não foi criada ou apagada em modo de configuração global for aplicada a uma interface nada ocorre, assim como estudamos para o IPv4. ACLs do tipo reflexivas e time-based access lists são suportadas pelo IPv6. O comportamento é o mesmo que estudamos para o IPv6.

Note que a maior diferença é com o deny implícito que deixa passar pacotes de NS, utilizados para descobrir o MAC remoto em LANs (substituto do ARP request), e de RA que solicitam o prefixo do roteador local para o processo de autoconfiguração (SLAAC – Stateless Address Auto Configuration). 8.2 Configurando uma ACL IPV6 Para configurar a ACL IPv6 utilizamos o mesmo princípio de criar as regras em modo de configuração global e depois aplicar a lista em uma interface, subinterface ou na VTY. Veja abaixo um exemplo de navegação nas opções de criação cri ação das listas. R1(config)#ipv6 access-list ? WORD User selected selecte d string identifying iden tifying this access list log-update Control access list log updates R1(config)#ipv6 access-list IINS-DlteC R1(config-ipv6-acl)#? IPv6 Access List configuration commands: default Set a command to its defaults deny Specify packets to reject evaluate Evaluate an access list exit Exit from access-list configuration mode no Negate a command or set its defaults permit Specify packets pack ets to forward forwar d remark Access list entry comment sequence Sequence number for this entry R1(config-ipv6-acl)#deny ? <0-255> An IPv6 protocol proto col number X:X:X:X::X/<0-128> X:X:X:X::X/<0 -128> IPv6 source prefix x:x::y/ ahp Authentication Authenticatio n Header Protocol any Any source prefix esp Encapsulation Security Payload host A single source host icmp Internet Control Message Protocol


   

 

 



   

    

   



Página 136

 

 

  


ipv6 pcp sctp tcp udp

Any IPv6 Payload Compression Compr ession Protocol Protoc ol Streams Control Transmission Protocol Transmission Control Protocol User Datagram Protocol

R1(config-ipv6-acl)#deny 2000::/64 ? X:X:X:X::X/<0-128> X:X:X:X::X/<0 -128> IPv6 destination prefix x:x::y/ any Any destination prefix host A single destination host R1(config-ipv6-acl)#deny 2000::/64 any R1(config-ipv6-acl)#permit any any

No exemplo acima foi criada a lista de acesso com o nome IINS-DlteC, IINS-DlteC, a qual não permite pacotes com a rede de origem 2000::/64, porém todos os demais pacotes IPv6 são permitidos. Para aplicar a lista na interface utilizamos o comando “ipv6 “ ipv6 traffic-filter” traffic-filter” com o nome da lista e o sentido do tráfego a ser filtrado (in ou out  igual ao que estudamos para IPv4). Veja a aplicação da lista acima na interface fast 0/0 do roteador. R1(config-)#int f0/0 R1(config-if)#ipv6 traffic-filter IINS-DlteC out R1(config-if)#

Para aplicar a ACL IPv6 à VTY precisamos criar a lista em modo de configuração global e vinculá-la à line com com o comando “ipv6 “ipv6 access-class”. access-class”. 8.3 Exemplo de ACL IPv6 Vamos aproveitar o exemplo de ACL estendida do IPv4 e realizar as configurações com IPv6. Agora você deve configurar o roteador R1, que tem a sub-rede 2000::/64 em sua LAN (Fast 1/0) que está entroncada com um Switch de acesso e possui várias sub-redes na mesma interface, para que a rede 2002::/64 seja bloqueada quando tentar acessar os serviços de FTP e TFTP em quaisquer micros e servidores dentro dessa sub-rede específica. Todas as demais sub-redes devem ser permitidas para todos os serviços. O primeiro passo é verificar as portas e protocolos dos serviços a serem bloqueados:  

FTP: portas FTP: portas 20 e 21 do TCP TFTP: porta TFTP: porta 69 do UDP

Note que os pacotes serão originados na sub-rede 2002::/64 e chegarão na rede de destino 2000::/64, ou seja, os micros da sub-rede 2002::/64 estão em um roteador remoto.


   

 

 



   

    

   



Página 137

 

 

  


R2(config)#Ipv6 access-list bloq-2002 R2(config-ipv6-acl)# deny tcp 2002::/64 2000::/64 eq ftp R2(config-ipv6-acl)# deny tcp 2002::/64 2000::/64 eq ftp-data R2(config-ipv6-acl)# deny udp 2002::/64 2000::/64 eq tftp R2(config-ipv6-acl)# permit ip any any R2(config-ipv6-acl)#exit R2(config)#Interface fast 1/0 R2(config-if)# ipv6 traffic-filter bloq-2002 out R2(config-if)#end R2#

9 Resumo do Capítulo Bem pessoal, chegamos ao final do capítulo. É muito importante que nesse n esse ponto do curso você tenha domínio dos seguintes itens: Explicar a funcionalidade das ACL’s padrão, estendida e nomeada utilizadas pelos roteadores para filtrar pacotes. Configurar e verificar ACL’ s IP para reduzir ameaças em redes via CLI (filtro de tráfego destinado ao Telnet, SNMP e ataques DDoS). Prevenindo a falsificação de endereço IP (IP Spoofing) utilizando ACL’s via vi a CLI. Analisar e identificar pontos chaves a serem considerados na construção de ACLs. Implementar ACLs Reflexivas e time-based. Entender e implementar ACLs para IPv6. 



   


   

 

 



   

    

   



Página 138

 

 

  


Capítulo 6 - Implementando Implementando Firewall em Roteadores Cisco e ASA

Nesse capítulo veremos como implementar o recurso de firewall Cisco IOS utilizando o CCP e também via CLI.

Objetivos do Capítulo Ao final desse capítulo você terá estudado e deverá compreender: Descrever os pontos fortes e fracos das diferentes tecnologias de firewall. Explicar a operação dos firewalls stateful e a função da tabela de estado. Implementar firewall baseada em zona (Zone Based Firewall) utilizando o CCP. Princípios de funcionamento do ASA Firewall. Ativar o ASA Firewall. Configurar o ASA Firewall via ASDM.

O objetivo maior do exame IINS 640-554 é o Zone Policy Based Firewall configurado via CCP, porém estudaremos o CBAC e conceitos de configuração via CLI, pois na vida prática eles podem ajudar muito os administradores de rede e de segurança.









 

Vamos também iniciar o estudo do firewall ASA e o ASDM para configuração gráfica via Web. Aproveite o capítulo e bons estudos!

Apostila do Curso IINS 640-554      

   

 

 



   

    

   



Página 139

 

 

  


Sumário do Capítulo

5.1 Zone-Based Firewall – Design Design e Funcionamento ______________________ 169

1

5.2 Zone-Based Firewall – Dicas Dicas de Implantação ________________________ 171

Introdução _____________________ _____________________ 141

5.3 CLI

1.1 Primeira Geração de Firewalls - Filtros de Pacotes __________________________ 142

5.3.1 5.3.2

Passo 1: Crie as Zonas. ___________ ___________ 173 Passo 2: Defina as classes de tráfego. t ráfego. 174 5.3.3 Passo 3: Defina as políticas de segurança do firewall. _________________ _________________________ ___________ ___ 175 5.3.4 Passo 4: Aplicar as políticas de firewall entre as Zonas. ___________________ _________________________ ______ 176 5.3.5 Passo 5: Associar as interfaces a uma zona. 176

1.2 Segunda Geração de Firewalls - Filtros de Estado de Sessão __________________ 143 1.3 Terceira Geração (Gateway de Aplicação - OSI) 144 1.4 2

Quarta Geração e Sucessores _____ 145

Tipos de Firewall e Principais Aplicações 146

2.1

Firewall por Filtragem de Pacotes __ 148

2.2

Firewall Stateful ________________ 149

2.3

Soluções Cisco para Firewall ______ 150

5.4 Exemplo de Configuração de ZBF via CLI e Comandos Show ___________________ 177

3 Considerações de Design de Redes com Firewall ______________________ ___________________________ _____ 153

5.5 CCP

Zone-Based Firewall – Configuração Configuração Via 179

5.6

Verificando as configurações via CCP 186

5.7

Implementando NAT com ZBF _____ 187

6 Configurando Firewall Básico no Cisco ASA ______________________ ______________________________ ________ 188

3.1

Dual Homed Host Architecture Architecture ____ 154

3.2

Screened Host Architecture _______ 155

3.3

Screened Subnet Architecture _____ 156

6.1

Equipamentos da Família ASA 55xx 188

3.4

Outras Variações Variações _______________ 157

6.2

Facilidades e Recursos do ASA ASA ____ 189

6.3 Princípios de Funcionamento do ASA Firewall ____________________________ 190

4 Configurando Context Based Access Control (Statefull Firewall) ____________ ____________ 158

6.4

4.1 Princípio de Funcionamento do Firewall CBAC 159

5

Zone-Based Firewall – Configuração Configuração Via 173

4.2

Configuração do CBAC ___________ 161

4.3

Exemplo Prático ________________ 165

4.4

Verificando as Configurações______ 166

Acessando o ASA e Emulação via GNS3 192

6.5 Configurando e Testando o ASA via ASDM 196 6.6 7

Configurando o ASA via CLI _______ 198

Resumo do Capítulo _____________ _____________ 201

Zone-Based Firewall – Conceitos____ 167


   

 

 



   

    

   



Página 140

 

 

  


1 Introdução Firewall (em português: muro corta-fogo) é o nome dado ao dispositivo de uma rede de computadores que tem por objetivo aplicar apli car uma política de segurança a um determinado ponto de controle da rede. Sua função consiste em regular o tráfego de dados entre redes distintas e impedir a transmissão e/ou recepção de acessos nocivos ou não autorizados de uma rede para outra. Este conceito inclui os equipamentos de filtros de pacotes e de proxy de aplicações, comumente associados a redes TCP/IP.

Os sistemas firewall nasceram no final dos anos 80, motivado pela necessidade de criar restrição de acesso entre as redes existentes. Nesta época a expansão das redes acadêmicas e militares, que culminou com a formação da ARPANET , e posteriormente p osteriormente a Internet, e a popularização dos primeiros computadores tornou-se um prato cheio para a pequena comunidade hacker. Casos de invasões de redes, de acessos indevidos a sistemas e de fraudes em sistemas de telefonia começaram a surgir, e foram retratados no filme Jogos de Guerra ("War Games"), de 1983. Em 1988, administradores de rede identificaram o que se tornou a primeira grande infestação de vírus de computador e que ficou conhecido como Internet Worm. Em menos de 24 horas, o worm escrito por Robert T. Morris Jr disseminou-se por todos os sistemas da então existente Internet (formado exclusivamente por redes de ensino e governamentais), provocando um verdadeiro "apagão" na rede. Após sua criação os firewalls vem evoluindo ano a ano e vamos ver um pouco dessa de ssa evolução na sequência.


   

 

 



   

    

   



Página 141

 

 

  


1.1 Primeira Geração de Firewalls - Filtros de Pacotes  





A tecnologia foi disseminada em 1988 através de pesquisa pe squisa sustentada pela DEC; Bill Cheswick e Steve Bellovin da AT&T desenvolvem o primeiro modelo para prova de conceito; O modelo tratava-se de um filtro de pacotes responsável pela avaliação de pacotes do conjunto de protocolos TCP/IP; Apesar do principal protocolo de transporte TCP orientar-se a um estado de conexões, o filtro de pacotes não tinha este objetivo inicialmente i nicialmente (uma possível vulnerabilidade);

Até hoje, este tipo de tecnologia é adotada em equipamentos de rede para permitir configurações de acesso simples (as chamadas "listas de acesso" ou "access lists" ou ACL) . O ipchains é exemplo recente de um firewall que utiliza a tecnologia desta geração. Hoje o "ipchains" foi substituído pelo iptables que é nativo do Linux e com maiores recursos. As regras típicas na primeira geração de firewalls firewall s abrangiam:  

Restringir tráfego baseado no endereço IP de origem ou destino; Restringir tráfego através da porta (TCP ou UDP) do serviço.

O filme Guerreiros da Internet ilustra bem o funcionamento de um firewall baseado em filtro de pacotes, assista ao filme no link http://www.youtube.com/watch?v=O_xG0ay5Vqs


   

 

 



   

    

   



Página 142

 

 

  


1.2 Segunda Geração de Firewalls - Filtros de Estado de Sessão 





A tecnologia foi disseminada a partir de estudo desenvolvido no começo dos anos 90 pelo Bell Labs; Pelo fato do principal protocolo de transporte TCP orientar-se por uma tabela de estado nas conexões, os filtros de pacotes não eram suficientemente efetivos se não observassem estas características; Foram chamados também de firewall de circuito.

As regras típicas na segunda geração abrangiam:   



Todas as regras da 1.ª geração; Restringir o tráfego para início de conexões (NEW); Restringir o tráfego de pacotes que não tenham sido iniciados a partir da rede protegida (ESTABLISHED); Restringir o tráfego de pacotes que não tenham número de sequência corretos.

O Firewall de circuito nasceu com a segunda geração e tem o diferencial de armazenar o estado das conexões e filtrar com base nesse estado. Existem três estados para uma conexão:   

NEW: Novas conexões; ESTABLISHED: Conexões já estabelecidas; RELATED: Conexões relacionadas a outras existentes.


   

 

 



   

    

   



Página 143

 

 

  


1.3 Terceira Geração (Gateway de Aplicação - OSI) 

 





Baseado nos trabalhos de Gene Spafford (co-autor do livro Practical Unix and Internet Security), Marcos Ranum (fundador da empresa TIS), e Bill Cheswick; Também são conhecidos como "Firewall de Aplicação" ou "Firewall Proxy"; Foi nesta geração que se lançou o primeiro produto comercial em 13 de Junho de 1991— o SEAL da DEC; Diversos produtos comerciais surgiram e se popularizaram na década de 90, como os firewalls Raptor, Gauntlet (que tinha sua versão gratuita batizada de TIS) e Sidewinder, entre outros; Não confundir com o conceito atual de ''Firewall'' de Aplicação: firewalls de camada de aplicação eram conhecidos desta forma por implementarem o conceito de Proxy e de controle de acesso em um único dispositivo (o Proxy Firewall), ou seja, um sistema capaz de receber uma conexão, decodificar protocolos na camada de aplicação e interceptar a comunicação entre cliente/servidor para aplicar regras de acesso.

As regras típicas na terceira geração abrangem:    

Todas as regras das gerações anteriores; Restringir acesso FTP a usuários anônimos; Restringir acesso HTTP para portais de entretenimento; Restringir acesso a protocolos desconhecidos na porta 443 (HTTPS).


   

 

 



   

    

   



Página 144

 

 

  


1.4 Quarta Geração e Sucessores 



O firewall consolida-se como uma solução comercial para redes de comunicação TCP/IP com o surgimento do Stateful Firewall ou Firewall de Estado de Sessão. Diversas empresas como StoneSoft, Fortinet, SonicWALL, Juniper, Checkpoint, BRconnection e Cisco desenvolvem soluções que ampliam características anteriores: o Stateful Inspection para inspecionar pacotes e tráfego de dados baseado nas características de cada aplicação, nas informações associadas a todas as camadas do modelo OSI (e não apenas na camada de rede ou de aplicação) e no estado das conexões e sessões ativas; o Prevenção de Intrusão para fins de identificar o abuso do protocolo TCP/IP mesmo em conexões aparentemente legítimas; o Deep Packet Inspection associando as funcionalidades do Stateful Inspection com as técnicas dos dispositivos IPS.

A partir do início dos anos 2000, a tecnologia de Firewall foi aperfeiçoada para ser aplicada também em estações de trabalho e computadores domésticos (o chamado "Firewall Pessoal"), além do surgimento de soluções de firewall dedicado a servidores e aplicações específicas (como servidores Web e banco de dados).


   

 

 



   

    

   



Página 145

 

 

  


2 Tipos de Firewall e Principais Aplicações Os Firewalls podem ter variadas conotações para diferentes pessoas e organizações, mas todos os firewalls compartilham algumas propriedades comuns:  



Devem ser resistente a ataques. Todos os fluxos de tráfego da Internet ou redes consideradas inseguras passam através do firewall (ponto único de acesso). Reforça a política de controle de acesso à rede.

Vantagens do uso de firewalls:  

  

Prevenir a exposição de hosts e aplicações sensíveis para usuários/redes não confiáveis. O fluxo dos protocolos pode ser “higienizado”, impedindo a exploração das falhas mais conhecidas dos protocolos, normalmente exploradas no início dos ataques. Impedir o fluxo de dados não seguros de serem enviados a servidores e clientes. Facilitar a aplicação da política de segurança de maneira escalável e robusta. Convergir o controle de acesso à rede em alguns pontos reduzindo a complexidade do gerenciamento de segurança.

Desvantagens do uso do firewall: 

 



Se mal configurado, um firewall pode ter consequências graves (ponto único de falha – SPOF – Single Point Of Failure). Os firewalls não conseguem tratar certos tipos de tráfego de forma segura. Os usuários podem proativamente procurar maneiras de burlar as regras do firewall para receber material bloqueado e, propositalmente ou não, acabam por criar uma potencial falha de segurança. O desempenho da rede pode ser degradado, pois todo o tráfego passando por um único ponto pode trazer lentidão se mal projetado.


   

 

 



   

    

   



Página 146

 

 

  


Tráfego não autorizado pode ser encapsulado ou oculto dentro de um protocolo válido e passar através do firewall.

Existem diversas classificações e nomenclaturas para os diferentes tipos de firewalls. Acompanhem na figura abaixo os tipos de firewall em relação ao modelo de referência OSI sobre sua capacidade de filtragem por camada seguido de uma explicação breve de cada tipo.















Firewall de filtragem de pacotes (packet filtering) - Normalmente é um roteador com a capacidade de filtrar conteúdo do pacote IP ou protocolo TCP/UDP (camadas 3 e 4), utilizando para filtragem parâmetros como endereços IP de origem e destino, portas TCP e UDP de origem e destino. Stateful Firewall - Monitora o estado de conexões (se a conexão está iniciando, realizando a transferência de dados ou estabelecida ou o estado de finalização). Atua nas camadas 3, 4 e 5 do modelo OSI. Firewall de Aplicação (firewall proxy ou gateway de aplicação) - Um firewall que filtra as informações nas camadas 3, 4, 5 e 7 do modelo OSI. A maior parte do controle e filtragem é realizada em nível de software. São muitas vezes chamados de Proxy Firewall. Firewall de Tradução de endereços (NAT – Network Address Translation) – Permite o uso de endereços privativos na Internet traduzindo os Ips da rede interna por um endereço válido de Internet. Ele também acaba ocultando os endereços internos por utilizar uma faixa de Ips privativos e não válidos na Internet. Personal Firewall (baseado em Host - servidor e/ou pessoal) - Um PC ou servidor com o software de firewall em execução, por exemplo, o firewall que vem residente no Windows. Firewall Transparente - Um firewall que filtra o tráfego IP entre um par de interfaces em modo Bridge. Firewall Híbrido - Um firewall que é uma combinação de vários tipos de firewalls.

Vamos estudar os principais tipos de firewall a seguir.


   

 

 



   

    

   



Página 147

 

 

  


2.1 Firewall por Filtragem de Pacotes Os firewalls por filtragem de pacotes não representam uma solução completa de firewall, porém é uma parte importante da maioria das soluções disponíveis no mercado. Com a filtragem de pacotes você pode limitar o tráfego através de informações da camada-3, limitando acesso a determinadas redes IP de origem ou destino, assim como ir além e configurar filtros baseados na camada 4, ou seja, portas TCP ou UDP de origem e destino, limitando aplicações específicas. Um exemplo é uma empresa que utiliza e-mail, normalmente ela terá que liberar o uso da porta 25 do protocolo TCP para o envio dos e-mails através do protocolo SMTP (Simple Mail Transport Protocol). As regras de um firewall baseado em filtragem de pacotes normalmente são as que estudamos nas lista de controle de acesso padrão e estendidas (ACL IP), podendo filtrar por:      

Endereço de origem (Source IP address) Endereçe de destino (Destination IP address) Protocolo Porta TCP/UDP de origem (Source port number) Porta TCP/UDP de destino (Destination port number) Estado da conexão (Synchronize/start – SYN)

As vantagens desse tipo de firewall são a facilidade de implementação, não gerar sobrecarga no processamento do firewall ou impacto sobre o fluxo da rede, é uma etapa inicial importante de filtragem na rede e pode ser implementado facilmente em qualquer equipamento, firewall ou roteador. As desvantagens da filtragem de pacote tem origem em sua simplicidade, pois hackers podem enviar pacotes que passam pelas regras da ACL para realizar ataques de falsificação de IP (IP spoofing). Além disso, seguem algumas outras desvantagens da filtragem de pacotes:   



Regras muito complexas podem ser difíceis de administrar e manter. Não trabalham bem com pacotes segmentados. Não conseguem filtrar serviços que tem negociação dinâmica, por exemplo, que utilizam portas variáveis ou mudam de porta durante a negociação. Não mantém o estado da conexão, podendo sofrer ataques onde o contexto da conexão deve ser analisado.

No quadro a seguir temos um exemplo de regra de firewall com filtragem de pacotes.


   

 

 



   

    

   



Página 148

 

 

  


Vamos analisar, por exemplo, a regra 3 onde quaisquer pacotes vindo da rede 192.168.10.0 com a máscara 255.255.255.0 (IPs de 192.168.10.1 a 192.168.10.254) podem acessar quaisquer IP’s de destino desde que seja através da porta 80 do protocolo TCP. Nada mais é que uma ACL padrão ou estendida que estudamos no capítulo anterior! 2.2 Firewall Stateful A evolução da filtragem de pacotes foram os firewalls Stateful, os quais além de filtrar por todos os parâmetros utilizados pelo antecessor, também conseguem verificar o estado da conexão, mantendo uma tabela de estado. Sabemos que as maiores partes das conexões são do protocolo TCP, o qual estabelece e gerencia uma sessão entre os dois hosts para garantir a confiabilidade das trocas de mensagem. Porém, diversos serviços (o FTP ativo, por exemplo) iniciam uma conexão sobr e uma porta estática, mas abrem dinamicamente (ou seja, de maneira aleatória) uma porta para estabelecer uma sessão entre o servidor e a máquina cliente. Assim, com uma filtragem simples de pacotes fica impossível prever as portas que devemos permitir ou proibir. Para resolver esse tipo de questão, o sistema de filtragem dinâmica de pacotes baseia-se na inspeção das camadas 3, 4 e 5 do modelo OSI, permitindo que o firewall acompanhe as transações entre o cliente e o servidor. O termo “stateful inspection ” ou “stateful packet filtering” pode ser traduzido para “filtragem de pacotes com estado”. Veja a figura a seguir.

O firewall de tipo “stateful inspection” é assim capaz de realizar o acompanhamento das trocas, ou seja, de monitorar o estado dos pacotes para aplicar as regras de filtragem. Quando um serviço é acessado fora, o firewall stateful mantém certos detalhes da conexão, salvando o estado da conexão na tabela de estado. Cada vez que uma conexão TCP ou UDP é estabelecida para conexões de entrada ou de saída, o firewall registra as informações em uma tabela de


   

 

 



   

    

   



Página 149

 

 

  


sessão com estado de fluxo. Quando o sistema fora responde a um pedido, o servidor firewall compara os pacotes recebidos com o estado guardado para permitir ou negar acesso à rede. A tabela de estado normalmente contém os endereços de origem e destino, números de porta TCP, informações de sequenciamento e sinalizadores adicionais (flags) para cada conexão TCP ou UDP que está associado a essa sessão em particular. Esta informação cria um objeto de conexão que é utilizado pelo firewall para comparar todos os pacotes de entrada e saída contra os fluxos de sessão na tabela de fluxo de sessão stateful. O firewall permite o fluxo de dados somente se existir uma conexão adequada para validar a passagem dos dados. Alguns firewalls stateful mais avançados incluem a capacidade de analisar comandos do FTP e atualizar a tabela de estado para permitir que o FTP trabalhe de forma transparente através do firewall. Os stateful firewalls avançados também podem analisar números de sequência do TCP e respostas do DNS para garantir que o firewall permita somente pacotes entrantes que sejam relativos às conexões que realmente se originaram de dentro da rede, evitando o spoofing de IP. Esses recursos reduzem a ameaça de ataques de flooding de TCP/RST e DNS cachê poinsoning (ataques ao DNS). Há uma desvantagem potencial da utilização de filtragem de estado. Embora a inspeção stateful proporcione rapidez e transparência, os pacotes dentro da rede devem fazer o seu caminho para a rede externa. Isso pode expor os endereços IP internos para hackers em potencial. A maioria dos firewalls stateful podem atuar como gateways de Network Address Translation (NAT) e servidores proxy para maior segurança. Além disso, eles não protegem contra a exploração das falhas nos aplicativos, ligadas às vulnerabilidades das aplicações, estas vulnerabilidades representam a parte mais importante dos riscos em termos de segurança. Outras desvantagens são as de não suportar autenticação e que nem todos os protocolos como UDP e ICMP, podem ser inspecionados utilizando esse tipo de firewall ou possuem uma inspeção limitada. 2.3 Soluções Cisco para Firewall Falando especificamente das soluções Cisco para Firewall, o administrador possui várias opções de implementação que vão desde diretamente no roteador, via um Cisco IOS Firewall, até dispositivos específicos com a linha de produtos PIX e ASA. A linha de firewall implementadas diretamente nos roteadores através do IOS Firewall são dedicadas a empresas de pequeno e médio porte, inclusive escritórios remotos. Abaixo seguem algumas das facilidades do IOS Firewall da Cisco:        

Suporte a zone-based policy framework Filtragem de Instant messenger e aplicativos peer-to-peer Firewall para protocolos VoIP Suporte a Virtual routing and forwarding (VRF) Integração com redes Wireless Firewall Stateful Filtragem por URL Inspeção para tráfego web e email

O Cisco IOS Firewall é capaz de implementar um firewall stateful, permitindo integrar os serviços de roteamento e firewall em um único dispositivo, o que acaba trazendo uma economia para a empresa. O firewall integrado ao IOS permite ao administrador configurar : 

Proxy de autenticação (authentication proxy): é um método pelo qual você pode restringir o acesso a determinados recursos, exigindo que os usuários se autentiquem antes de utilizar a Internet, por exemplo. Este recurso é normalmente ligado ao envio de


   

 

 



   

    

   



Página 150

 

 

  






solicitações de autenticação para os servidores em outras partes da rede, como os serviços de AAA, incluindo servidores RADIUS e TACACS. Firewall Transparente: este é um novo recurso que foi introduzido no IOS 12.3 (7) T em plataformas limitada e agora está na liberado para IOS’s a partir da versão 12.4 (1). Ele pode ser usado quando você quer ter um firewall entre segmentos de rede, onde a introdução de um firewall de camada 3 não é possível por qualquer motivo, pois ele utiliza uma bridge de camada 2 e atua filtrando os pacotes que passam entre os segmentos que são interligados. Firewall Statful (Stateful Packet Inspection): utilizando a Context Based Access Control (CBAC) foi a primeira aplicação de inspeção de pacotes stateful (SPI) com base no software IOS da Cisco. Antes da introdução do CBAC, a filtragem de pacotes estática (ACLs) era o padrão e não havia acompanhamento do estado das conexões. O CBAC introduziu uma maneira de fazer mais do que apenas permitir ou negar, com base no endereço IP ou porta TCP/UDP. Essa funcionalidade foi introduzida no IOS versão 11.2p.

Além disso, o IOS Firewall permite a mitigação de ataques de DDoS. A linha de produtos Cisco PIX (Private Internet eXchange) foi um firewall popular e também serve como Network Address Translation (NAT) no mesmo equipamento. Foi um dos primeiros produtos neste segmento de mercado.

Em 2005, a Cisco lançou a nova linha de firewalls, os Adaptive Security Appliance (ASA – ver figura 2), que herdou muito das características PIX, e em 2008 anunciou o fim das vendas do PIX (end-of-sales).


   

 

 



   

    

   



Página 151

 

 

  


Também existe a opção em forma de blade com o Firewall Services Module (FWSM), para os switches da série Cisco Catalyst 6500 e roteadores série 7600.

A linha de produtos Cisco ASA (Adaptive Security Appliances) são fáceis de implementar e integram capacidades de firewall, com segurança do Cisco Unified Communications (voz e vídeo), VPN SSL (Secure Sockets Layer) e IPsec, IPS e serviços de segurança de conteúdo. Concebido como um componente chave da Cisco Self-Defending Network,o ASA prevê defesa A p o s t i l a / E - Bo o k d o C u r s o I I N S 6 4 0 - 5 5 4      

   

 

 



   

    

   



Página 152

 

 

  


contra ameaças e serviços de comunicação seguros que previnem os ataques antes que eles afetem os negócios. O ASA foi projetado para proteger as redes de todos os tamanhos de organizações. Ao escolher dentre as várias opções para uma solução de firewall, é importante realizar uma análise de custo versus risco. Independente da solução de firewall escolhida, a arquitetura de segurança do projeto de segurança é fundamental para seu funcionamento eficaz, assunto que vamos tratar no próximo tópico. 3

Considerações de Design de Redes com Firewall

Um profissional de segurança de rede é responsável pela criação e manutenção de uma política de segurança, incluindo uma política de segurança de firewall. Abaixo segue uma lista parcial e genérica que pode servir como ponto de partida para a política de segurança de firewall: 



  





Firewalls são posicionados nas fronteiras de segurança ou bordas entre a rede interna e o mundo exterior. Firewalls são os dispositivos de segurança primária, mas não é prudente confiar exclusivamente em um firewall como dispositivo de segurança único, deve-se combinar outros dispositivos de segurança como IDS e IPS. Negar todo o tráfego e permitir apenas os serviços que são necessários. Garantir que o acesso físico ao firewall é controlado e restrito. Monitorar regularmente logs do firewall. O Cisco Security Monitoring, Analysis and Response System (MARS) é especialmente desenhado para o acompanhamento dos logs de firewall. Aplicar controle de gestão de mudanças (Change Management – ITIL) para as mudanças de configuração do firewall. Firewalls protegem principalmente contra ataques tecnicamente sofisticados provenientes do exterior, enquanto ataques internos tendem a ser de outra natureza.

Antes de apresentar algumas arquiteturas de firewalls, é importante que se esteja familiarizado com alguns termos. Estas são algumas definições básicas: 



Bastion Host: um computador que deve ser altamente seguro por estar mais exposto a Internet sendo, portanto, mais vulnerável a ataques. Perimeter Network (rede de perímetro): uma rede colocada entre a rede interna (protegida) e a rede externa com objetivo de adicionar mais uma camada de segurança. Esta rede é também chamada de DZM (De-Militarized Zone).


   

 

 



   

    

   



Página 153

 

 

  


3.1 Dual Homed Host Architecture A primeira arquitetura que vamos analisar no design de redes com firewall é a Dual-homed host architecture. Esta arquitetura é formada por um computador dual-homed, ou seja, possui pelo menos duas interfaces de rede. Um host dual-homed como firewall tem a função de roteamento desativada, ou seja, os pacotes da rede interna protegida não são encaminhados diretamente à uma rede externa ou vice-versa, mas podem se comunicar com o host dualhomed, que separa as redes e para que haja comunicação entre a rede interna e externa é necessário a intermediação de um proxy.


   

 

 



   

    

   



Página 154

 

 

  


Um host dual-homed pode fornecer serviços apenas através de proxies, uma vez que ele não realiza qualquer tipo de roteamento, ou fazendo os usuários se conectarem diretamente ao host o que também não é muito aconcelhável do ponto de vista da segurança, ou mesmo inconveniente para os usuários. O uso de host dual-homed pode fornecer um nível alto de controle, entretanto a desvantagem clara desta arquitetura é que ele passa a ser o único ponto de falha, logo a segurança deste host deve ser absolutamente impecável. O uso apropriado dessa arquitetura é indicado para algumas das situações abaixo:    

O tráfego para a Internet é pequeno. O tráfego para a Internet não é crítico para os negócios. Nenhum serviço está sendo oferecido a usuários baseados na Internet. A rede que está sendo protegida não contém dados extremamente valiosos.

3.2 Screened Host Architecture A segunda arquitetura é chamada de Screened host architecture. Na arquitetura screened host ou host com triagem, as conexões podem ser abertas da rede interna para Internet, bem como as conexões externas podem ser abertas para a rede interna de forma controlada exclusivamente para os bastion hosts (como exemplo podemos permitir conexões para o servidor web). A filtragem de pacotes acontece no firewall, também chamado de roteador de triagem, que permite apenas certos tipos de conexões, como consultas ao DNS de Internet. O bastion host deve manter um alto nível de segurança, nele esta justamente o ponto de falha desta arquitetura, caso o bastion host seja invadido, o atacante já estará dentro da rede. Outro problema é o ponto único de acesso que aumenta a probabilidade de parada total da rede.


   

 

 



   

    

   



Página 155

 

 

  


O uso apropriado desta arquitetura é quando: 



Poucas conexões estão vindo da Internet. Não é uma arquitetura apropriada se o host de triagem é um servidor web público. A rede que está sendo protegida tem um nível relativamente alto de segurança de host.

3.3 Screened Subnet Architecture A terceira arquitetura é uma variação da anterior chamada Screened Subnet Architecture. A screened subnet architecture, também conhecida como arquitetura de sub -rede com triagem, adiciona uma nova rede de perímetro, como mostra na figura ao lado, que isola ainda mais a rede interna da Internet, mais especificamente os bastion hosts, que são máquinas vulneráveis na rede, ainda que haja os melhores esforços para protegê-los.

Nesta arquitetura é possível notar a presença de um ou mais filtro de pacotes, um para a rede interna e o outro para a rede externa, além dos bastion hosts. É muito comum encontrar roteadores de triagem com várias placas de rede. Nesse caso o bastion host fica confinado em uma área conhecida como Zona Desmilitarizada (DMZ) aumentando o nível de segurança, uma vez que, para ter acesso à rede interna o atacante terá que passar por dois processos de filtragem. Vejamos outro possível uso desta arquitetura, conforme a ilustração a seguir.


   

 

 



   

    

   



Página 156

 

 

  


É preciso ficar bem atento na definição dos firewalls, pois qualquer falha pode resultar em uma falsa sensação de segurança. O firewall externo deve permitir que usuários externos tenham acesso apenas aos serviços disponibilizado na DMZ, e o firewall interno deve permitir requisições e respostas apenas aos usuários da rede interna. 3.4 Outras Variações Existem outras variações possíveis sobre essas arquiteturas, e uma flexibilidade no modo como você pode configurar e combinar componentes de firewall para melhor atender as necessidades e orçamento da política de segurança a ser adotada, veja um exemplo com dois roteadores para garantir uma arquitetura redundante.

Nessa topologia, mesmo que o roteador R1 fique indisponível, os micros externos conseguem acessar os servidores da DMZ via o roteador R1.


   

 

 



   

    

   



Página 157

 

 

  


4 Configurando Context Based Access Control (Statefull Firewall) O CBAC (Controle de Acesso Baseado no Contexto) é utilizado para criar um firewall stateful nos roteadores com Cisco IOS Firewall e possui quatro funções principais: filtragem de tráfego, inspeção de tráfego, detecção de intrusão e geração de auditorias e alertas. Além disso, o CBAC provê as seguintes facilidades:        

Monitora o estabelecimento de sessões TCP (SYN/ACK). Mantém informações sobre sessões UDP. Rastreia os numeros de sequencia do TCP. Inspecionam pedidos do DNS (queries e replies). Inspeciona mensagens comuns do protocolo ICMP. Suporta aplicações que necessitam de conexões múltiplas. Inspeciona embedded addresses. Inspeciona informações da camada de aplicação.

O CBAC funciona criando permissões temporárias (aberturas) nas interfaces do firewall com ACLs dinâmicas, adicionando uma entrada ACL temporária para uma sessão específica. Estas aberturas são criadas quando o tráfego especificado sai da rede interna protegida pelo firewall em direção à Internet. As aberturas temporárias permitem que o tráfego de retorno, que normalmente seria bloqueado, entre na rede interna através do firewall, portando, sem esta entrada ACL temporária o tráfego será negado pela ACL preexistente. A tabela de estado atua de forma dinâmica e se adapta às mudanças no fluxo de informações. Veja a figura a seguir.


   

 

 



   

    

   



Página 158

 

 

  


4.1 Princípio de Funcionamento do Firewall CBAC Vamos analisar o funcionamento do Context - Based Access Control ou CBAC da Cisco com um exemplo prático. Vamos supor que um usuário está tentando acessar a página da Internet http://www.dltec.com.br/ através do roteador de perímetro que tem configurado nele uma CBAC, conforme figura a seguir.

Portanto o micro que está tentando acessar a Internet está no lado inside ou interno e a Internet no lado outside ou externo da rede. Uma lista de acesso é colocada na interface interna do roteador para inspecionar o tráfego desejado no sentido inbound (entrante ou in), ao passo que a lista temporária será colocada automaticamente pelo roteador na interface externa do roteador no sentido inbound (entrante ou in). Abaixo segue o passo a passo da troca de informações entre o cliente e o servidor e as ações que o roteador configurado com a CBAC vai tomar. 1. O pacote é enviado pelo micro em direção à Internet 2. É verificado se o pacote tem permissão de saída na ACL aplicada na interface interna no sentido In. 3. O pacote é inspecionado e uma entrada sobre o estado da conexão é criada na tabela de estado do roteador. 4. Essas informações sobre o estado da conexão são utilizadas para criar uma lista temporária que permite o retorno apenas do tráfego permitido e aplicada na direção inbound da interface externa do roteador. 5. O pacote é enviado para a Internet. 6. O servidor HTTP recebe os pacotes do usuário e responde, enviando pacotes de resposta em direção ao roteador. 7. Os pacotes são recebidos na interface em sentido inbound e verificados utilizando a access list de entrada (inbound) temporária. 8. Como o pacote é realmente uma resposta do servidor ao pedido do micro interno para acesso à internet ele é permitido entrar na rede. 9. Várias inspeções são realizadas durante a troca de informações. 10. Quando o fluxo é terminado a ACL temporária é retirada. Com base no que vimos acima, devemos complementar com o que o CBAC consegue tratar de informações para os protocolos TCP e UDP nas figuras abaixo. Primeiro vamos ver a requisição DNS que é feita em UDP.


   

 

 



   

    

   



Página 159

 

 

  


Agora o acesso telnet através da porta 23 do protocolo TCP.

Note que para o TCP ele é capaz de verificar o estabelecimento da sessão, que se dá com o handsake triplo e a troca dos números de confirmação via SYN e ACK, após isso monitora os números de sequencia até a finalização da sessão e posterior desativação da ACL temporária. Além disso, ele mantém as informações dos endereços IP de origem e destino, assim como portas TCP de origem e destino, o que caracteriza a sessão por completo. A p o s t i l a / E - Bo o k d o C u r s o I I N S 6 4 0 - 5 5 4      

   

 

 



   

    

   



Página 160

 

 

  


Para o protocolo UDP não existem números de confirmação ou retransmissão, pois ele não é orientado a conexão. Nesse caso os endereços IP de origem e destino mais as portas UDP de origem e destino são utilizados para caracterizar o tráfego, além disso, o timeout configurado é utilizado para determinar quando a sessão UDP foi finalizada. Com o CBAC é possível evitar ataques de DoS monitorando sessões TCP que não foram finalizadas ou Half-Open Connections. Todas vez que uma conexão é aberta no TCP sabemos que é realizado o processo do handshake triplo, através dos flags de SYN e ACK. Porém, quando um hacker está gerando um ataque de DoS através de SYN flooding ou inundação de solicitações de abertura de conexão TCP, essa abertura de sessão é falsa e normalmente não é finalizada. Logo, se em um período de tempo curto vários SYNs são enviados e não há conclusão da conexão TCP você está sendo atacado. Via CBAC você pode monitorar:   

Número total de sessões TCP half-opened Número de sessões half-opened abertas em um intervalo de tempo Número de sessões half-opened abertas por host

4.2 Configuração do CBAC Para configurar o CBAC siga os passos abaixo: 1. Determine as interfaces: internas e externas; 2. Configure as ACLs nas interfaces; 3. Defina as regras de inspeção com o comando em modo de config global “Router(config)#ip inspect name inspection_name protocol [alert {on | off}] [audit-trail {on | off}] [timeout seconds]”; 4. Aplique as regras de inspeção na interface com o comando “Router(config-if)#ip inspect inspection_name {in | out}”. O comando do passo 3 permite você definir o protocolo a ser inspecionado, assim como os alertas e parâmetros de auditoria. Acompanhe a seguir a lista de protocolos suportados, porém ela pode variar conforme versão do IOS. A lista de protocolos suportados é bastante grande, indo até aplicações peer-to-peer como Kazaa. DlteC-FW-GW(config)#ip inspect name test ? 802-11-iapp IEEE 802.11 WLANs WG IAPP ace-svr ACE Server/Propagation appfw Application Firewall appleqtc Apple QuickTime bgp Border Gateway Protocol biff Bliff mail notification bittorrent bittorrent bootpc Bootstrap Protocol Client bootps Bootstrap Protocol Server cddbp CD Database Protocol cifs CIFS cisco-fna Cisco FNATIVE cisco-net-mgmt cisco-net-mgmt cisco-svcs cisco license/perf/GDP/X.25/ident svcs cisco-sys Cisco SYSMAINT cisco-tdp Cisco TDP cisco-tna Cisco TNATIVE


   

 

 



   

    

   



Página 161

 

 

  


citrix citriximaclient clp creativepartnr creativeserver cuseeme daytime dbase dbcontrol_agent ddns-v3 dhcp-failover directconnect discard dns dnsix echo edonkey entrust-svc-hdlr entrust-svcs esmtp exec fasttrack fcip-port finger fragment ftp ftps gdoi giop gnutella gopher gtpv0 gtpv1 h323 h323-annexe h323-nxg hp-alarm-mgr hp-collector hp-managed-node hsrp http https ica icabrowser icmp ident igmpv3lite imap imap3 imaps ipass ipsec-msft ipx irc irc-serv ircs ircu isakmp iscsi iscsi-target

Citrix IMA/ADMIN/RTMP Citrix IMA Client Cisco Line Protocol Creative Partnr Creative Server CUSeeMe Protocol Daytime (RFC 867) dBASE Unix Oracle dbControl Agent po Dynamic DNS Version 3 DHCP Failover Direct Connect Version 2.0 Discard port Domain Name Server DNSIX Securit Attribute Token Map Echo port eDonkey Entrust KM/Admin Service Handler Entrust sps/aaas/aams Extended SMTP Remote Process Execution FastTrack Traffic - KaZaA, Morpheus, Gro FCIP Finger IP fragment inspection File Transfer Protocol FTP over TLS/SSL GDOI Oracle GIOP/SSL Gnutella Version2 Traffic - BearShare, S Gopher GPRS Tunneling Protocol Version 0 GPRS Tunneling Protocol Version 1 H.323 Protocol (e.g, MS NetMeeting, Intel Video Phone) H.323 Protocol AnnexE (e.g, MS NetMeetin H.323 Protocol AnnexG HP Performance data alarm manager HP Performance data collector HP Performance data managed node Hot Standby Router Protocol HTTP Protocol Secure Hypertext Transfer Protocol ica (Citrix) icabrowser (Citrix) ICMP Protocol Authentication Service IGMP over UDP for SSM IMAP Protocol Interactive Mail Access Protocol 3 IMAP over TLS/SSL IPASS Microsoft IPsec NAT-T IPX Internet Relay Chat Protocol IRC-SERV IRC over TLS/SSL IRCU ISAKMP iSCSI iSCSI port


   

 

 



   

    

   



Página 162

 

 

  


kazaa2 kerberos kermit l2tp ldap ldap-admin ldaps login lotusmtap lotusnote microsoft-ds ms-cluster-net ms-dotnetster ms-sna ms-sql ms-sql-m msexch-routing msrpc mysql n2h2server ncp net8-cman netbios-dgm netbios-ns netbios-ssn netshow netstat nfs nntp ntp oem-agent oracle oracle-em-vp oraclenames orasrv parameter pcanywheredata pcanywherestat pop3 pop3s pptp pwdgen qmtp r-winsock radius rcmd rdb-dbs-disp realaudio realsecure router rpc rsvd rsvp-encap rsvp_tunnel rtc-pm-port rtelnet rtsp send shell sip

Kazaa Version 2 Kerberos kermit L2TP/L2F Lightweight Directory Access Protocol LDAP admin server port LDAP over TLS/SSL Remote login Lotus Mail Tracking Agent Protocol Lotus Note Microsoft-DS MS Cluster Net Microsoft .NETster Port Microsoft SNA Server/Base Microsoft SQL Microsoft SQL Monitor Microsoft Exchange Routing Microsoft Remote Procedure Call MySQL N2H2 Filter Service Port NCP (Novell) Oracle Net8 Cman/Admin NETBIOS Datagram Service NETBIOS Name Service NETBIOS Session Service Microsoft NetShow Protocol Variant of systat Network File System Network News Transport Protocol Network Time Protocol OEM Agent (Oracle) Oracle Oracle EM/VP Oracle Names Oracle SQL*Net v1/v2 Specify inspection parameters pcANYWHEREdata pcANYWHEREstat POP3 Protocol POP3 over TLS/SSL PPTP Password Generator Protocol Quick Mail Transfer Protocol remote-winsock RADIUS & Accounting R commands (r-exec, r-login, r-sh) Oracle RDB Real Audio Protocol ISS Real Secure Console Service Port Local Routing Process Remote Prodedure Call Protocol RSVD RSVP ENCAPSULATION-1/2 RSVP Tunnel Oracle RTC-PM port Remote Telnet Service Real Time Streaming Protocol SEND Remote command SIP Protocol


   

 

 



   

    

   



Página 163

 

 

  


sip-tls skinny sms smtp snmp snmptrap socks sqlnet sqlserv sqlsrv ssh sshell ssp streamworks stun syslog syslog-conn tacacs tacacs-ds tarantella tcp telnet telnets tftp time timed tr-rsrb ttc udp uucp vdolive vqp webster who winmx wins x11 xdmcp

SIP-TLS Skinny Client Control Protocol SMS RCINFO/XFER/CHAT Simple Mail Transfer Protocol Simple Network Management Protocol SNMP Trap Socks SQL Net Protocol SQL Services SQL Service SSH Remote Login Protocol SSLshell State Sync Protocol StreamWorks Protocol cisco STUN SysLog Service Reliable Syslog Service Login Host Protocol (TACACS) TACACS-Database Service Tarantella Transmission Control Protocol Telnet Telnet over TLS/SSL TFTP Protocol Time Time server cisco RSRB Oracle TTC/SSL User Datagram Protocol UUCPD/UUCP-RLOGIN VDOLive Protocol VQP Network Disctionary Who's service WinMx file-sharing application Microsoft WINS X Window System XDM Control Protocol

Agora segue um exemplo de configuração onde os alertas ao syslog foram habilitados, os parâmetros de auditoria também e foi definido um timeout de 300 segundos caso não haja atividade na sessão. 1841_CCNA_SEC(config)#ip inspect name FWRULE smtp alert on audit-trail on timeout 300


   

 

 



   

    

   



Página 164

 

 

  


4.3 Exemplo Prático Vamos utilizar a figura a seguir como exemplo da configuração. Nesse exemplo a rede interna que será protegida é a 10.10.10.0/24 e a rede externa está conectada à interface serial s0.1 com a rede 10.10.11.0.

Primeiro vamos criar a lista de acesso que permite apenas os IP’s da rede interna acessarem via TCP, UDP e ICMP a rede externa: access-list access-list access-list access-list

101 101 101 101

permit tcp 10.10.10.0 0.0.0.255 any permit udp 10.10.10.0 0.0.0.255 any permit icmp 10.10.10.0 0.0.0.255 any deny ip any any

Agora vamos criar a lista de acesso que permite apenas acesso ao servidor SMTP posicionado internamente e limitar acesso aos demais serviços que são considerados desnecessários: access-list access-list access-list access-list prohibited access-list access-list access-list access-list access-list access-list

102 permit eigrp any any 102 permit icmp any 10.10.10.0 0.0.0.255 echo-reply 102 permit icmp any 10.10.10.0 0.0.0.255 unreachable 102 permit icmp any 10.10.10.0 0.0.0.255 administratively102 102 102 102 102 102

permit icmp any 10.10.10.0 0.0.0.255 packet-too-big permit icmp any 10.10.10.0 0.0.0.255 echo permit icmp any 10.10.10.0 0.0.0.255 time-exceeded permit tcp any host 10.10.10.1 eq smtp permit tcp any host 10.10.10.1 eq ftp deny ip any any

Veja que o EIGPR foi adicionado na lista de permissão devido aos roteadores fazerem roteamento via esse protocolo - isso é apenas um exemplo. Veja que foram permitidos acessos básicos que são recomendados e ao SMTP e FTP, que são serviços providos pelo servidor 10.10.10.1. Agora vamos configurar as regras de inspeção, nesse caso vamos analisar o protocolo TCP e UDP, sendo também analisados mais especificamente o FTP e o SMTP que fazem parte dos serviços disponibilizados pelos servidores. ip ip ip ip

inspect inspect inspect inspect

name name name name

meusite meusite meusite meusite

ftp smtp tcp udp


   

 

 



   

    

   



Página 165

 

 

  


Agora vamos aplicar as regras de inspeção e ACLs nas interfaces do roteador, considerando que elas já estavam configuradas e funcionando tanto na camada 2 como na 3. interface Ethernet0 ip access-group 101 in ip inspect meusite in ! interface Serial0.1 point-to-point ip access-group 102 in

4.4 Verificando as Configurações Para fazer as verificações e manutenção em roteadores configurados com CBAC utilize os comandos mostrados a seguir. • show ip access-lists

sessão TCP)

(o comando mostra as entradas dinâmicas criadas em cada

router1#show ip access-list 102 permit eigrp any any (385 matches) permit icmp any 10.10.10.0 0.0.0.255 echo-reply permit icmp any 10.10.10.0 0.0.0.255 unreachable permit icmp any 10.10.10.0 0.0.0.255 administratively-prohibited permit icmp any 10.10.10.0 0.0.0.255 packet-too-big permit icmp any 10.10.10.0 0.0.0.255 echo permit icmp any 10.10.10.0 0.0.0.255 time-exceeded permit tcp any host 10.10.10.1 eq smtp (142 matches) • show ip inspect name router1#show ip inspect name mysite Inspection name inspect_outbound cuseeme alert is on audit-trail is on timeout 3600 ftp alert is on audit-trail is on timeout 3600 http alert is on audit-trail is on timeout 3600 rcmd alert is on audit-trail is on timeout 3600 realaudio alert is on audit-trail is on timeout 3600 smtp max-data 20000000 alert is on audit-trail is on timeout 3600 tftp alert is on audit-trail is on timeout 30 udp alert is on audit-trail is on timeout 15 tcp alert is on audit-trail is on timeout 3600 • show ip inspect config router1#show ip inspect config Session audit trail is disabled one-minute (sampling period) thresholds are [400:500]connections max-incomplete sessions thresholds are [400:500] max-incomplete tcp connections per host is 50. Block-time 0 minute. tcp synwait-time is 30 sec -- tcp finwait-time is 5 sec tcp idle-time is 3600 sec -- udp idle-time is 30 sec dns-timeout is 5 sec Inspection Rule Configuration Inspection name mysite ftp timeout 3600 smtp timeout 3600 tcp timeout 3600


   

 

 



   

    

   



Página 166

 

 

  


• show ip inspect interfaces • show ip inspect all

Para desabilitar todos os alertas que podem ser gerados pelas configurações do CBAC realizadas utilize o comando “Router(config)#ip inspect alert-off”. Além disso, a auditoria vem desabilitada por default, para habilitar utilize o comando “Router(config)#ip inspect audit -trail”. Por último, para remover uma CBAC utilize o comando “Router(config)#no ip inspect”. Existe também o comando debug “Router#debug ip inspect protocol parameter”, onde você pode monitorar em tempo real a inspeção de determinado protocolo. 5 Zone-Based Firewall – Conceitos Desde a versão 12.0 de IOS a Cisco dá suporte a tecnologia de Stateful Inspection Firewall, mais recentemente a partir da versão 12.4(6)T a Cisco introduziu ao código do IOS a técnica de firewall baseado em zonas ou Zone-Based Policy Firewall (ZFW ou ZBF ou ZPF), apesar de ainda manter o desenvolvimento para a versão clássica boa parte dos esforços foram direcionados para a tecnologia de firewall baseado em zonas.

Firewalls baseados em zona mudam a forma como o IOS Stateful Inspection é realizado, “por interface” no caso dos firewall clássicos, realizando o mesmo processo, porém baseado em zonas. Por padrão um tráfego inter-zonas não é permitido, ou seja, redes que estão situadas em zonas distintas por default não trocam tráfego entre si até que exista uma regra para isso. As regras são criadas usando Cisco Common Classification Policy Language (C3PL ou CPL), que emprega um processo hierárquico de controle para definir protocolos de rede ou grupos de hosts onde a inspeção de tráfego será aplicada.


   

 

 



   

    

   



Página 167

 

 

  


Cada interface poder ser membro apenas de uma zona, mas as zonas podem abrir múltiplas interfaces. Quando uma interface torna-se membro de uma zona todo tráfego entrante pela mesma é bloqueado até que seja criada uma política que permita esse tráfego. Políticas são estabelecidas criando-se uma classe e definindo o tráfego que a mesma afetará. Uma interface configurada no firewall baseado em zona (ZPF ou ZBF ou ZFW) suporta funcionalidades de firewall stateful incluindo a inspeção de pacotes, inspeção de aplicação, filtragem de URL e mitigação de ataques de DoS. Alguns dos benefícios da ZBF incluem o seguinte:  





Não depende de ACLs. A política de segurança do roteador é bloquear a menos que o tráfego seja explicitamente permitido. As políticas são mais fáceis de entender e, consequentemente, solucionar problemas com o C3PL. Uma política consegue filtrar todo o tráfego, ao contrário das ACLs tradicionais que precisam de múltiplos statements ou condições para filtrar os diversos tipos de tráfegos.


   

 

 



   

    

   



Página 168

 

 

  


5.1 Zone-Based Firewall – Design e Funcionamento Ao decidir entre aplicar CBAC ou ZBF, uma observação importante é que ambos os modelos de configuração podem ser ativadas simultaneamente em um roteador, porém os modelos não podem ser combinados em uma única interface. Por exemplo, uma interface não pode ser configurada como um membro da zona de segurança e configurado para inspeção stateful IP via CBAC simultaneamente. Pensando agora em como projetar uma rede com firewall baseado em zonas o administrador de rede terá que levar em consideração os seguintes passos: 1. Definir as Zonas: nesse passo o administrador de redes deve pensar em separar sua infraestrutura em zonas levando em consideração a parte lógica da implementação, não a parte física e equipamentos. Por exemplo, ele pode ter uma topologia com DMZ onde ele tem a rede pública (Internet), uma zona para a rede interna e outra zona para os servidores DMZ.

2. Definir a Política entre as Zonas: agora você deve definir os requisitos de tráfego entre as zonas. Para cada par de zonas (Zone-pair), por exemplo, o tráfego da rede interna para os servidores da DMZ, você deve definir que tráfego é permitido ou bloqueado através de uma política. Em outras palavras, um par de zonas especifica o sentido do tráfego interessante, onde a direção é definida especificando uma zona origem (source) e uma zona de destino (destination). Observe que não é permitido configurar uma mesma zona como origem e destino. Assim como no passo 1 aqui estamos definindo a estrutura lógica. Veja a figura a seguir onde temos 4 zonas e as setas em pontilhado indicam como o tráfego entre as zonas está definido, por exemplo, entre a Internet e a DMZ apenas os protocolos SMTP, HTTP e DNS são permitidos, além disso o tráfego que vem da Internet não pode entrar para nenhuma outra zona definida.


   

 

 



   

    

   



Página 169

 

 

  


3. Definir a Estrutura Física: nesse passo o administrador deve levar em consideração a segurança e a disponibilidade da rede para definir o melhor design físico baseado no que foi definido nos passos anteriores sobre a estrutura das zonas e requisitos de tráfego. Veja a seguir exemplos de topologias físicas.


   

 

 



   

    

   



Página 170

 

 

  


4. Identificar Subconjuntos dentro das Zonas e Consolidar as Exigências de Tráfego: Para cada firewall no projeto o administrador deve identificar subconjuntos de zonas conectados às suas interfaces e procurar consolidar ou agrupar as exigências de tráfego para essas zonas. Por exemplo, várias zonas podem estar indiretamente ligadas a uma interface única de um firewall, resultando em uma política inter-zona específica do dispositivo. Aqui a ideia é fazer uma otimização dos recursos dos equipamentos para facilitar mais tarde o troubleshooting, porém deve-se levar em conta os gargalos que podem surgir desses agrupamentos. 5.2 Zone-Based Firewall – Dicas de Implantação Ao implementar ZBF, primeiro você deve criar as zonas para depois associar as interfaces com as zonas criadas. Existe uma zona no roteador chamada de zona própria ou self-zone, a qual representa o próprio roteador. Abaixo seguem as regras gerais que definem o fluxo de informações entre as diversas zonas configuradas nos firewalls e roteadores. 1. Uma zona deve ser configurada antes das interfaces poderem ser atribuídas à zona. 2. Uma interface pode ser atribuída a apenas uma zona de segurança. 3. Todo o tráfego (in e out) em uma determinada interface é implicitamente bloqueado quando a interface é atribuída a uma determinada zona, exceto quando o tráfego vai para outras interfaces na mesma zona ou para qualquer interface de um roteador. 4. O tráfego é permitido por padrão entre as interfaces que são membros da mesma zona. 5. A fim de permitir o tráfego (in e out) da interface de uma zona para outra, uma política que permita (pass) ou inspecione (inspect) o tráfego deve ser configurada entre essa zona e qualquer outra zona (zone pairs ou pares de zona). 6. A zona própria (self-zone) é a única exceção para o padrão da política de negar todas (deny all). Todo o tráfego de qualquer interface do roteador é permitido até que o tráfego seja expressamente negado. 7. O tráfego não pode fluir entre uma interface membro de uma zona e qualquer interface que não seja um membro dessa zona. As ações de pass, inspect e drop podem ser aplicada entre duas zonas para definir a política entre elas.


   

 

 



   

    

   



Página 171

 

 

  


8. Interfaces que não tenham sido atribuídas a uma zona podem usar a inspeção stateful clássica via CBAC. 9. Se for necessário que uma interface no firewall não faça parte das políticas das zonas, ainda assim será necessário colocá-la em uma zona e configurar uma política de “pass all” (passa tudo) entre essa zona e qualquer outra zona em que o fluxo do tráfego seja necessário. 10. Da regra anterior podemos concluir que se o tráfego deve fluir entre todas as interfaces de um roteador, todas as interfaces devem ser parte do modelo de zoneamento do ZBF (cada interface deve ser um membro de uma zona ou outra). 11. A única exceção à regra de negar todo tráfego vista anteriormente é quando estamos falando do tráfego do roteador (entrada ou saída), o que será permitido por padrão. Uma política explícita pode ser configurada para restringir esse tráfego. Portanto o tráfego é permitido entre as interfaces na mesma zona, entre as interfaces que pertencem a nenhuma zona e o tráfego entrante ou de saída na zona self (roteador). Quando o tráfego de uma interface que pertence a uma zona vai para uma interface que está fora do esquema de zoneamento ele é bloqueado por padrão e não existe maneira de alterar esse comportamento, veja o item 9 das regras de tráfego. Acima falamos algumas vezes na Política da Zona ou Zone Policy, essa política define o que vamos permitir ou negar no tráfego entre as zonas (zone pair ou par de zonas). Por exemplo, nós só queremos permitir HTTP e bloquear o SMTP e ICMP. Para isso existem três ações possíveis quando configurar ZBF via CCP: "pass", "drop" e "inspect". As ações "pass" e "drop" são ações autoexplicativas, ou seja, o “pass” é semelhante ao “permit”de uma ACL e o “drop” ao “deny”. A ação de “inspect” ou inspecionar diz ao router para usar um mapa de classe (class-map) pré-definido para filtrar o tráfego, equivalente ao comando “ip inspect” que utilizamos no CBAC. Via CLI existem outras opções de configuração para a política além das três citadas acima, porém a prova dá um enfoque maior ao CCP. Outro ponto importante sobre as regras mencionadas acima é que o ZBF aplica política unidirecional entre duas zonas. Veja a figura a seguir, nela podemos notar que as políticas ou policy são aplicadas por direção, e quando não definida o tráfego inteiro entre duas zonas é bloqueado, por exemplo, note que existe uma política que define regras para o acesso da Internet em direção à DMZ, porém da DMZ para a Internet não existe tal política, o que acaba por bloquear todo o tráfego que sai da DMZ em direção à Internet. Não ficou bem mais fácil configurar dessa maneira a restrição da DMZ à Internet? Volte ao capítulo anterior e veja como o CBAC foi configurado para essa restrição e compare.


   

 

 



   

    

   



Página 172

 

 

  


Portanto, as políticas definem restrições através de endereços IP, protocolos e aplicações que podem ser permitidos, negados ou inspecionados. As políticas são aplicadas unidirecionalmente entre duas zonas: elas só afetam o tráfego em uma direção. No entanto, você pode facilmente estabelecer políticas em ambos os sentidos entre as zonas. As políticas podem ser aplicadas com base na seguinte classificação de tráfego:   



Equipamentos: ACLs, endereços IP e/ou sub-redes Protocolos: TCP, UDP, ICMP e assim por diante Serviços e/ou aplicações: números de porta TCP e/ou UDP e tipos de mensagens ICMP Informações da Camada de Aplicação: Com informações da camada HTTP, por exemplo, você pode restringir que métodos (comandos) são executados, quais arquivos e diretórios podem ser acessados, o tráfego não HTTP nas portas HTTP, e muitas outras opções. Você pode aplicar políticas para diversas aplicações.

5.3 Zone-Based Firewall – Configuração Via CLI A configuração de uma ZBF segue basicamente os cinco passos que veremos a seguir com seus devidos comandos. Vamos utilizar a topologia da figura abaixo como referência para os comandos e levar em conta que toda a configuração prévia está realizada no roteador/firewall.

5.3.1 Passo 1: Crie as Zonas. Router(config)#zone security nome-da-zona Router(config-sec-zone)#description descricao-da-zona

Levando em conta nossa topologia da figura, para criar duas zonas chamadas Internet e Intranet utilize os comandos abaixo: Router(config)#zone security Internet Router(config-sec-zone)#description Conexao com a Internet Router(config)#zone security Intranet Router(config-sec-zone)#description Rede interna


   

 

 



   

    

   



Página 173

 

 

  


5.3.2 Passo 2: Defina as classes de tráfego.

O comando “class-map type inspect” cria as classes de tráfego, veja a sintaxe e opções gerais abaixo do comando: Router(config)#class-map type inspect [match-any | match-all] nome-da-map-class

Aqui você cria uma class-map com um nome (nome-da-map-class) e pode utilizar os parâmetros match-any, o qual é o padrão e caso quaisquer dos itens definidos nos parâmetros de match sejam validados a class-map é aceita. Já se você utilizar o match-all, o tráfego deverá satisfazer todas as condições definidas nos comandos de match. Router(config-cmap)#match access-group {número-da-ACL | name nome-da-ACL}

Utilizado para fazer a validação da class-map através de uma ACL nomeada ou numerada. Router(config-cmap)#match protocol nome-do-protocolo

Utilizado para fazer a validação da class-map através de um protocolo específico, a lista de protocolos é a mesma mostrada para a CBAC. Router(config-cmap)#match class-map nome-da-class_map

Utilizado para fazer uma filtragem mais precisa utilizando outra class-map como referência. Vamos a um exemplo simples da configuração do mapa de classes. Router(config)#class-map type inspect match-any meumapa Router(config-cmap)#match protocol http Router(config-cmap)#match protocol tcp

No exemplo acima o nome do mapa é “meumapa” e o protocolo HTTP será inspecionado por inteiro, ou seja, a aplicação como um todo, e o protocolo TCP será inspecionado de maneira stateful nas camadas 3 e 4 do modelo OSI, sendo adicionadas suas conexões a tabela de estado, como no CBAC. A verificação é feita do primeiro statement para o último, assim como nas ACLs, do primeiro para o último até que haja a combinação ou match. Outro exemplo seria se você tivesse a rede Interna configurada como 10.0.10.0/24, ou seja, dos IP’s 10.0.10.1 até 10.0.10.254, e deseja que apenas essa rede passe pelo firewall você poderia configurar da seguinte maneira: Router(config)#access-list 100 permit ip 10.0.10.0 0.0.0.255 any Router(config)#class-map type inspect match-any meumapa Router(config-cmap)#match access-group 100

Primeiro foi criada uma ACL estendida com o número 100, selecionando a rede inteira e depois vinculada ao mapa de classes com o comando “match access-group 100”, onde o 100 é o número da ACL criada. Poderia ser feito também com uma ACL estendida. Cuidado no uso do comando match-all ao criar a class-map, pois, por exemplo, se você colocar uma condição para verificar o protocolo HTTP e UDP no mesmo mapa de classe ele nunca será satisfeito, pois o HTTP é TCP, e quando se utiliza o match-all significa que todas as condições devem ser satisfeitas.


   

 

 



   

    

   



Página 174

 

 

  


5.3.3 Passo 3: Defina as políticas de segurança do firewall.

Para associar uma política de segurança (policy) a uma class-map é necessário criar uma policy-map com o comando “policy-map type inspect”. É possível criar políticas nas camadas 3, 4 ou 7 com esse comando. Seguem as opções para configurar uma policy-map: Router(config)#policy-map type inspect [L7_type] nome-da-policy_map

Este comando cria a política e leva a um novo modo de configuração para definir o que será realizado. Router(config-pmap)#class type inspect [L7_type] nome-da-class_map

O comando acima especifica o nome da class-map que a política será aplicada. Router(config-pmap-c)#service-policy inspect [L7_type] nome-da-policy_map

O comando acima faz referência a um mapa de classes de DPI de camada 7 (deep packet inspection). Isto é usado para qualificar uma política de camada 3/4 em um class-map. Router(config-pmap-c)#inspect [nome-do-parameter_map]

O comando acima ativa a inspeção stateful do tráfego, porém normalmente já foi ativada no mapa de classes. Router(config-pmap-c)#police rate bits-por-segundo burst numero-de-bytes

O comando police rate permite limitar a taxa do tráfego que está sendo verificado, similar ao comando do frame-relay CIR (commited interface rate) e Bc (commited burst), onde você define uma taxa média em bits por segundo e um valor de burst permitido que pode ser excedido em bytes. Os comandos abaixo são as possibilidades de ação (política) encima do tráfego de interesse definido na class-map. Router(config-pmap-c)#drop [log] - bloqueia o tráfego e o log é opcional para gerar uma mensagem quando o tráfego é bloqueado Router(config-pmap-c)#pass - permite o tráfego Router(config-pmap-c)#reset - reseta a conexão TCP Router(config-pmap-c)#log - cria uma mensagem no log quando a condição é satisfeita Router(config-pmap-c)#urlfilter nome-do-parameter_map

Aplica políticas de filtragem de um servidor de conteúdo Websense ou N2H2. Router(config-pmap-c)#exit Router(config-pmap)#class class-default Router(config-pmap-c)#

Há um mapa de classes definido pelo sistema chamado de "class-default". Este mapa inclui todos os pacotes que não correspondem a nenhum dos mapas de outras classes e deve ser configurado como última opção na policy-map. Se você não configurar políticas ou ações para este mapa de classes do sistema a ação padrão é bloquear o tráfego (drop). Vamos a um exemplo prático de aplicação abaixo, onde criamos uma política chamada testepolicy, a qual fará a inspeção do tráfego determinado em uma classe de mapas chamada meumapa.


   

 

 



   

    

   



Página 175

 

 

  


Router(config)#policy-map type inspect testepolicy Router(config-pmap)#class type inspect meumapa Router(config-pmap-c)#inspect

5.3.4 Passo 4: Aplicar as políticas de firewall entre as Zonas.

Para criar um par de zonas (zone pair) utilize o comando: Router(config)#zone-pair security nome-da-zone_pair source {nome-da-zona | self} destination { nome-da-zona | self} Router(config-sec-zone-pair)#description descrição

Opcionalmente você pode adicionar uma descrição ao zone-pair. Após definir o zone pair aplique a política de segurança definida com a policy-map: Router(config-sec-zone-pair)#service-policy type inspect nome-da-policy_map

Esta política que foi adicionada ao zone-pair afeta apenas uma direção. Veja um exemplo prático abaixo onde o zone pair está sendo configurado o tráfego na direção da rede Interna para a Internet: Router(config)#zone-pair security intranet-internet source intranet destination internet Router(config-sec-zone-pair)#service-policy type inspect testepolicy Router(config-sec-zone-pair)#exit

5.3.5 Passo 5: Associar as interfaces a uma zona.

Para associar as interfaces a uma zona utilize o comando em modo de config de interface: Router(config-if)#zone-member security nome-da-zona

Segue exemplo de configuração levando em conta a figura. Router(config)#interface serial 0/0 Router(config-if)#zone-member security Internet Router(config-if)#exit Router(config)#interface Fast 0/0 Router(config-if)#zone-member security Intranet Router(config-if)#exit


   

 

 



   

    

   



Página 176

 

 

  


5.4 Exemplo de Configuração de ZBF via CLI e Comandos Show Neste exemplo, o tráfego TCP e UDP do usuário de saída deve ser permitido, com o tráfego de retorno permitido. Para os usuários da Internet o tráfego web para o servidor 10.1.1.1 será tratado de maneira stateful para o tráfego que vem da Internet em direção à Intranet. Veja a figura abaixo e acompanhe as configurações.

Primeiro vamos selecionar o tráfego interessante com as class-maps e criar as políticas, iniciando com o tráfego da Intranet. Router(config)#class-map type inspect match-any Intranet Router(config-cmap)#match tcp Router(config-cmap)#match udp Router(config-cmap)#exit Router(config)#policy-map type inspect policy_intranet Router(config-pmap)#class type inspect Intranet Router(config-pmap-c)#inspect Router(config-pmap-c)#exit Router(config-pmap)#exit

Agora vamos fazer o mesmo para o acesso que vem da Internet para a Intranet, conforme enunciado do exercício. Router(config)#access-list 100 permit tcp any host 10.1.1.1 eq 80 Router(config)#class-map type inspect match-all Internet Router(config-cmap)#match http Router(config-cmap)#match access-group 100 Router(config-cmap)#exit Router(config)#policy-map type inspect policy-internet Router(config-pmap)#class type inspect Internet Router(config-pmap-c)#inspect Router(config-pmap-c)#exit Router(config-pmap)#exit

Vamos criar as zonas da Internet e Intranet. Router(config)#zone Intranet Router(config-sec-zone)#description Rede Interna Router(config-sec-zone)#exit Router(config)#zone Internet


   

 

 



   

    

   



Página 177

 

 

  


Router(config-sec-zone)#description Internet Router(config-sec-zone)#exit

Criar as regras de firewall entre as zonas que definimos, onde a inside-to-outside define o acesso dos micros internos à Internet. A outside-to-inside define o acesso dos micros da Internet para a Intranet. Router(config)#zone-pair security inside-to-outside source Intranet destination Internet Router(config-sec-zone-pair)#service-policy type inspect policy-intranet Router(config-sec-zone-pair)#exit Router(config)#zone-pair security outside-to-inside source Internet destination Intranet Router(config-sec-zone-pair)#service-policy type inspect policy-internet Router(config-sec-zone-pair)#exit

Por último vamos adicionar as interfaces nas zonas corretas, conforme topologia. Router(config)#interface Serial 0/0 Router(config-if)#zone-member security Internet Router(config-if)#exit Router(config)#interface Fast 0/0 Router(config-if)#zone-member security Intranet Router(config-if)#end Router#

Para verificar as configurações utilize os seguintes comandos show:    



show class-map type inspect - mostra as class maps. show policy-map type inspect - mostra as policy maps. show zone security - mostra as zonas e interfaces associadas a elas. show zone-pair security - Mostra as zonas de origem e destino, assim como a política aplicada a elas. show policy-map type inspect zone-pair sessions - Mostra a tabela de estado (state table) do roteador.


   

 

 



   

    

   



Página 178

 

 

  


5.5 Zone-Based Firewall – Configuração Via CCP Configurar um ZBF via Cisco Configuration Professional você precisa ir até a opção “Configure > Security > Firewall > Firewall”. Nesse ponto você encontrará duas opções “Basic Firewall”, o qual trata de um firewall com duas interfaces em diferentes zonas, e o “Advanced Firewall”, o qual permite a inserção de uma terceira zona, tal como uma DMZ.

Além disso, nessa mesma tela podemos utilizar o método antigo do IOS-based firewall via CBAC clicando na opção “Switch to Classic Firewall”. Escolhendo a opção “Basic Firewall” e clicando em Launch of the Selected Task você cai em uma tela de explicação básica, clica em Next e vai ter a tela que pede para você escolher as redes “trusted network” (Rede Corporativa ou Interna) e “untrusted network” (Internet ou externa) através da interface que elas estão conectadas. Você pode escolher mais de uma rede Interna e apenas uma rede externa.


   

 

 



   

    

   



Página 179

 

 

  


Se você deixar de selecionar uma das interfaces aparecerá um aviso informando que essa interface não selecionada não fará parte de nenhuma zona e não terá seu tráfego encaminhado entre as zonas que serão criadas. Além disso, existe um checkbox para ser marcado caso você deseje acessar o CCP via interfaces externas, ou seja, de fora para dentro.

Marque corretamente as interfaces, se for gerenciar o roteador via Internet pelo CCP marque o checkbox e siga enfrente, mensagens aparecerão basta clicar em YES e prosseguir.


   

 

 



   

    

   



Página 180

 

 

  


Quando utilizamos o ZBF Wizard podemos escolher três níveis de segurança: High Security: Com esta definição o firewall identifica e bloqueia mensagens instantâneas e tráfego peer-to-peer. Ele faz inspeção aplicação para web e tráfego de email, bloqueando tráfego incompatível. Ele faz também inspeção genérica de aplicações TCP e UDP. Medium Security: Similar ao High Security sem fazer a inspeção do tráfego web e email. Low Security: O roteador não faz inspeção em nível de aplicação, porém faz inspeção genérica do TCP e UDP. 





Você pode nesse ponto ainda clicar em “Preview Commands” e verificar o que será aplicado nas configurações do seu roteador ou então clicar em Next e depois em Finish. O wizard pode ainda mostrar algumas mensagens sobre as configurações e o tráfego que será bloqueado no roteador antes de finalizar a aplicação dos comandos nele. Veja um exemplo aplicando uma política de Low Security: ip access-list extended CCP_AH remark CCP_ACL Category=1 permit ahp any any exit access-list 101 remark CCP_ACL Category=128 access-list 101 permit ip any any access-list 100 remark CCP_ACL Category=128 access-list 100 permit ip host 255.255.255.255 any access-list 100 permit ip 127.0.0.0 0.255.255.255 any access-list 100 permit ip 192.168.10.0 0.0.0.255 any ip access-list extended CCP_IP remark CCP_ACL Category=1 permit ip any any exit ip access-list extended CCP_ESP remark CCP_ACL Category=1 permit esp any any


   

 

 



   

    

   



Página 181

 

 

  


exit ip access-list extended CCP_HTTPS remark CCP_ACL Category=1 permit tcp any any eq 443 exit ip access-list extended CCP_SHELL remark CCP_ACL Category=1 permit tcp any any eq cmd exit ip access-list extended CCP_SSH remark CCP_ACL Category=1 permit tcp any any eq 22 exit class-map type inspect match-any CCP_HTTPS match access-group name CCP_HTTPS exit class-map type inspect match-any CCP_SHELL match access-group name CCP_SHELL exit class-map type inspect match-any CCP_SSH match access-group name CCP_SSH exit class-map type inspect match-any CCP-cls-access match class-map CCP_HTTPS match class-map CCP_SSH match class-map CCP_SHELL exit class-map type inspect match-any ccp-h225ras-inspect match protocol h225ras exit class-map type inspect match-all CCP-access match class-map CCP-cls-access match access-group 101 exit class-map type inspect match-any ccp-cls-icmp-access match protocol icmp match protocol tcp match protocol udp exit class-map type inspect match-any ccp-h323annexe-inspect match protocol h323-annexe exit class-map type inspect match-all ccp-protocol-http match protocol http exit class-map type inspect match-any CCP_IP match access-group name CCP_IP exit class-map type inspect match-any CCP_ESP match access-group name CCP_ESP exit class-map type inspect match-any CCP_AH match access-group name CCP_AH exit class-map type inspect match-any CCP_EASY_VPN_SERVER_TRAFFIC match protocol isakmp match protocol ipsec-msft match class-map CCP_AH match class-map CCP_ESP exit


   

 

 



   

    

   



Página 182

 

 

  


class-map type inspect match-all ccp-invalid-src match access-group 100 exit class-map type inspect match-any ccp-cls-insp-traffic match protocol cuseeme match protocol dns match protocol ftp match protocol https match protocol icmp match protocol imap match protocol pop3 match protocol netshow match protocol shell match protocol realmedia match protocol rtsp match protocol smtp extended match protocol sql-net match protocol streamworks match protocol tftp match protocol vdolive match protocol tcp match protocol udp exit class-map type inspect match-all ccp-icmp-access match class-map ccp-cls-icmp-access exit class-map type inspect match-all ccp-insp-traffic match class-map ccp-cls-insp-traffic exit class-map type inspect match-any ccp-h323-inspect match protocol h323 exit class-map type inspect match-any ccp-sip-inspect match protocol sip exit class-map type inspect match-any ccp-h323nxg-inspect match protocol h323-nxg exit class-map type inspect match-any ccp-skinny-inspect match protocol skinny exit class-map type inspect match-all CCP_EASY_VPN_SERVER_PT match class-map CCP_EASY_VPN_SERVER_TRAFFIC exit policy-map type inspect ccp-permit-icmpreply class type inspect ccp-icmp-access no drop inspect exit class type inspect ccp-sip-inspect no drop inspect exit class type inspect ccp-h323-inspect no drop inspect exit class type inspect ccp-h323annexe-inspect no drop inspect


   

 

 



   

    

   



Página 183

 

 

  


exit class type inspect ccp-h225ras-inspect no drop inspect exit class type inspect ccp-h323nxg-inspect no drop inspect exit class type inspect ccp-skinny-inspect no drop inspect exit class class-default no drop pass exit exit policy-map type inspect CCP-permit-ip class type inspect CCP_IP no drop pass exit class class-default drop log exit exit policy-map type inspect ccp-inspect class type inspect ccp-invalid-src drop log exit class type inspect ccp-protocol-http no drop inspect exit class type inspect ccp-insp-traffic no drop inspect exit class type inspect ccp-sip-inspect no drop inspect exit class type inspect ccp-h323-inspect no drop inspect exit class type inspect ccp-h323annexe-inspect no drop inspect exit class type inspect ccp-h225ras-inspect no drop inspect exit class type inspect ccp-h323nxg-inspect no drop inspect exit class type inspect ccp-skinny-inspect


   

 

 



   

    

   



Página 184

 

 

  


no drop inspect exit exit policy-map type inspect ccp-permit class type inspect CCP_EASY_VPN_SERVER_PT no drop pass exit class type inspect CCP-access no drop inspect exit class type inspect ccp-sip-inspect no drop inspect exit class type inspect ccp-h323-inspect no drop inspect exit class type inspect ccp-h323annexe-inspect no drop inspect exit class type inspect ccp-h225ras-inspect no drop inspect exit class type inspect ccp-h323nxg-inspect no drop inspect exit class type inspect ccp-skinny-inspect no drop inspect exit class class-default exit zone security in-zone zone security ezvpn-zone zone security out-zone zone-pair security CCP-zp-in-ezvpn1 source in-zone destination ezvpn-zone service-policy type inspect CCP-permit-ip exit zone-pair security ccp-zp-out-self source out-zone destination self service-policy type inspect ccp-permit exit zone-pair security CCP-zp-out-ezpn1 source out-zone destination ezvpn-zone service-policy type inspect CCP-permit-ip exit zone-pair security ccp-zp-self-out source self destination out-zone service-policy type inspect ccp-permit-icmpreply exit zone-pair security CCP-zp-ezvpn-in1 source ezvpn-zone destination in-zone service-policy type inspect CCP-permit-ip exit zone-pair security ccp-zp-in-out source in-zone destination out-zone service-policy type inspect ccp-inspect exit


   

 

 



   

    

   



Página 185

 

 

  


zone-pair security CCP-zp-ezvpn-out1 source ezvpn-zone destination out-zone service-policy type inspect CCP-permit-ip exit interface FastEthernet0/0 description $FW_OUTSIDE$ zone-member security out-zone exit interface Loopback1 description $FW_INSIDE$ zone-member security in-zone exit interface Virtual-Template1 type tunnel zone-member security ezvpn-zone exit interface FastEthernet0/1.10 description $FW_INSIDE$ zone-member security in-zone exit interface FastEthernet0/1.30 description $FW_INSIDE$ zone-member security in-zone exit

Note que o CCP cria páginas de comandos através desse wizard e conforme o nível de segurança escolhido eles podem variar. Você deve guardar qual sua escolha e os comandos aplicados para facilitar futuros troubleshootings e possíveis alterações nas regras. 5.6 Verificando as configurações via CCP É possível também verificar ou alterar as configurações utilizando o CCP na aba Edit Firewall Policy no mesmo local onde ele foi configurado em “Configure > Security > Firewall > Firewall”.

Para verificar a atividade do firewall em tempo real podemos utilizar o Monitor do CCP em “Monitor > Security > Firewall Status”.


   

 

 



   

    

   



Página 186

 

 

  


5.7 Implementando NAT com ZBF Podemos também adicionar o Network Address Translation (NAT) no mesmo roteador que tem uma ZBF configurada. A maneira mais simples de fazer o NAT é utilizando a interface externa do firewall como “outside interface” e ativar o overload nesse endereço (Port Address Translation - PAT). Para configurar o NAT via CCP vá em “Configure > Router > NAT” e inicie o Basic NAT Wizard. Caso o NAT já esteja configurado você pode verificar na aba ao lado com o nome de Edit NAT Configuration. A configuração é mais simples que a via CLI estudada no CCNA R&S e/ou CCENT, pois basta escolher as interfaces inside e outside através de uma tabela e clicando em um checkbox. Lembre abaixo dos comandos de configuração do NAT com overload via CLI. Nesse exemplo a interface outside é a Giga0/0 (Internet) e a interface inside é a Giga0/1 (Rede Corporativa). A rede interna utiliza a rede 10.0.0.0/24. R1(config)#access-list 1 permit 10.0.0.0 0.0.0.255 R1(config)#ip nat inside source list 2 interface GigabitEthernet0/0 overload R1(config)#interface GigabitEthernet0/0 R1(config-if)#ip nat outside R1(config-if)#exit R1(config)#interface GigabitEthernet0/1 R1(config-if)#ip nat inside R1(config-if)#exit

Com o comando “show ip nat translations” você verifica se o roteador está realmente traduzindo os endereços. Mas se já estudamos isso no pré-requisito porque voltar ao assunto? Simplesmente para mostrar que o mesmo roteador que é um firewall pode assumir outros papéis e também a configuraçaõ via CCP, pois os conceitos são os mesmos.


   

 

 



   

    

   



Página 187

 

 

  


6 Configurando Firewall Básico no Cisco ASA Até o momento utilizamos um roteador com Cisco IOS como firewall, agora vamos estudar como configurar um Cisco ASA como firewall, pois ele é um dispositivo voltado somente para segurança com mais recursos e capacidade de tratativa de requisições que um roteador.

6.1 Equipamentos da Família ASA 55xx Vamos analisar um pouco da família de equipamentos e suas principais características, lembrando que os equipamentos tem um tempo de vida e após o momento que o material foi escrito podem ter entrado em final de ciclo de vendas ou End of Sales (EOS). Especificações principais

Cisco ASA 5500 Series Cisco ASA 5505

  

Cisco ASA 5510

  

Recursos de segurança

Firewall até 150 Mbps 25 sessões de usuário VPN Suporta no máximo de 3 (truncamento desativado) / 20 (truncamento ativado) interfaces virtuais (VLANs) Firewall até 300 Mbps 250 sessões de usuários VPN 50/100 VLANs

Firewall Serviços VPN

 

Firewall Segurança de conteúdo Prevenção contra invasão (IPS) Serviços VPN Firewall Segurança de conteúdo Prevenção contra invasão Serviços VPN

 





Cisco ASA 5520, 5540, 5550

  

Firewalls com mais de 300 Mbps Mais de 750 sessões de usuários VPN 150 VLANs

 






   

 

 



   

    

   



Página 188

 

 

  


O ASA 5585 é uma opção de alta performance, com firewall de alta capacidade, suporte a diversos add-ons, tais como módulos especiais adicionais. Eles ocupam mais espaço em rack que os modelos de 5510 até 5550. O Firewall Services Module (FWSM) e o ASA Services Module são firewalls em blade compatíveis com switches de alta capacidade tais como o Catalyst 6500. Esses módulos suportam diversas facilidades e recursos similares aos que o ASA família 55xx suporta. 6.2 Facilidades e Recursos do ASA O ASA suporta maioria senão todos os recursos discutidos anteriormente para os firewalls configurados via Cisco IOS em roteadores, além disso ele suporta muitos recursos de roteamento e outros voltados ao usuário final que você vai perceber em diversas redes que ele poderia substituir o roteador e assumir por completo a rede. Vamos abaixo resumir os principais recursos do ASA: Packet filtering: filtragem de pacotes simples como em ACLs com a diferença de não utilizar máscaras curinga, se ele precisa representar uma máscara em suas declarações utiliza a máscara de sub-rede. Stateful filtering: por padrão o ASA já faz o tratamento das regras utilizando o estado da conexão, ou seja, a cada conexão aberta com o mundo exterior é como se o ASA criasse uma ACL virtual esperando pelo pacote de retorno sem a necessidade de configurações extras em suas ACLs. Application inspection/awareness: com a facilidade de “application layer inspection” ou inspecionar a aplicação o ASA pode aprender portas dinâmicas e permitir conexões que foram acordadas dinamicamente, evitando problemas como os citados anteriormente sobre o FTP que pode mudar dinamicamente suas portas. Network Address Translation (NAT): o ASA suporta o NAT e PAT de maneira básica, como estudamos anteriormente para os roteadores, assim como possui recursos avançados aplicados em ambientes com VPNs ou que faixas de endereços que precisam cruzar o NAT sem serem traduzidos com a inserção de exceções. DHCP: Em ambientes de menor porte o ASA pode ser utilizado como servidor DHCP, o que agregado ao NAT elimina a necessidade de outros dispositivos para que a rede tenha um bom funcionamento. Routing: o ASA suporta RIP, EIGRP, OSPF e rotas estáticas. Layer 3 or Layer 2 implementation: o ASA pode ser configurado como um firewall de camada-3, assim como os roteadores, e também como um firewall em bridge, fazendo uma ponte entre dois segmentos de rede e aplicando regras de filtragem e inspeção de maneira transparente. VPN support: o ASA suporta VPNs para acesso remoro de usuários e site-to-site (conectar Unidades Remotas via Internet). Pode também suportar Secure Sockets Layer (SSL) sem ouso de clientes ou através do AnyConnect. O uso do SSL está crescendo como acesso remoto para usuários não para conexões site-to-site.. Object groups: o ASA permite a tratativa de faixas de IP ou endereços em grupos, o que facilita a configuração e possibilita reduzir o número de comandos em uma declaração.


   

 

 



   

    

   



Página 189

 

 

  


Botnet traffic filtering: muitas vezes é difícil para um usuário final saber que seu computador faz parte de um Botnet e está sendo utilizado em um ataque combinado (às vezes mais de 100 mil computadores) a um determinado alvo. O ASA permite verificações específicas utilizando um sistema externo da Cisco que fornece informações sobre o tráfego (Botnet Traffic Filter Database) e consegue proteger a rede contra esse tipo de ameaça. High availability: pode ser combinado com um segundo firewall para formar uma rede de altíssima disponibilidade. AAA support: tem suporte a authentication, authorization, and accounting (AAA) podendo ser integrado a um Access Control Server (ACS), por exemplo. 6.3 Princípios de Funcionamento do ASA Firewall No ZBF do Cisco IOS o princípio de funcionamento foi definir zonas e criar políticas de encaminhamento entre elas. O firewall ASA tem um princípio de funcionamento um pouco diferente para seu recurso de firewall. No ASA vamos utilizar níveis de segurança ou “security levels” entre 0 e 100 para definir quanto essa interface é confiável. Quanto maior o número mais confiável é a rede que essa interface está conectada. Se você utilizar o valor 100 significa que você está conectando sua rede Interna nessa interface, pois ela é a mais confiável na rede. Já a interface conectada à Internet normalmente utilizamos o valor zero (security-level 0). Em termos de configuração, para que uma interface fique ativa no ASA precisamos configurar os seguintes parâmetros: Definir um security level para a interface Dar um nome à interface Ativar a interface com o comando “no shutdown”   

Mesmo que você configure o IP, máscara e dê um no shut a interface do ASA não irá encaminhar pacotes até que os três itens estejam configurados. Além das interfaces internas (inside) e externas (outside) podemos ter interfaces onde servidores Internos podem estar posicionados com possibilidade de acesso externo, ou seja, uma zona desmilitarizada ou DMZ. Normalmente o nível de segurança de uma DMZ é configurado entre 1 e 99, porém em nossos exemplos vamos utilizar 50 para a interface que será utilizada como DMZ. Falamos aqui em interface, mas pode ser também uma VLAN. Veja a figura a seguir com um esquema representando o funcionamento do ASA firewall com uma rede Interna, uma saída para a Internet e DMZ.


   

 

 



   

    

   



Página 190

 

 

  


Os valores dos níveis de segurança definem quem pode falar com quem, por exemplo, a rede interna (interface com nome redeinterna) pode enviar pacotes inicialmente para a Internet e para a DMZ, pois ela tem security-level 100, a Internet 0 e a DMZ 50. Já a DMZ consegue enviar pacotes inicialmente somente para a Internet, já do servidor em direção à rede interna não é possível, pois ela é uma rede menos confiável (security-level 50) que a rede interna (security-level 100). Com a configuração padrão a DMZ também não poderia ser acessada via Internet, pois ela tem nível de segurança maior (50 > 0), por isso na figura indica que precisará configurações adicionais para que o fluxo da Internet em direção à DMZ seja liberado. Por padrão o tráfego de retorno passará pela análise da tabela stateful do firewall, ou seja, somente sessões abertas por hosts da rede mais confiável podem retornar de uma rede menos confiável em direção à rede mais confiável.


   

 

 



   

    

   



Página 191

 

 

  


6.4 Acessando o ASA e Emulação via GNS3 As ferramentas para gerenciamento do Cisco ASA são: Command-line interface (CLI): similar ao IOS. ASA Security Device Manager (ASDM): interface gráfica já incluída no ASA. Cisco Security Manager (CSM): software de maior porte que gerenciar diversos dispositivos de rede como roteadores, switches e dispositivos de segurança como o ASA.   

Em um ASA novo (zerado) sem endereço IP configurado você precisará conectar via console portof the ASA. O cabo é o mesmo que utilizamos nos roteadores e switches, portanto você vai precisar de uma porta serial ou um adaptador USB para serial do lado do seu laptop. Via CLI temos o ROM Monitor, EXEC mode (de usuário e privilegiado), modo de configuração global, modo de configuração de interface e assim vai, similar aos roteadores e switches. A navegação é por contexto, assim como já estamos acostumados com o CLI, temos os comandos enable, exit, Ctrl+Z, etc. Uma diferença importante notar é que você pode usar a letra Q (quit) para interromper a rolagem através das páginas de saída de uma página de cada vez. O ASDM é uma ferramenta gráfica via Web que vem disponível nos equipamentos da família ASA Firewall. Você pode se conectar até cinco diferentes firewalls com o ASDM e vamos utilizálo em nossas práticas. Portanto, o recomendado é ao ligar o ASA conectar-se via console, utilizar o wizard de configuração via CLI para configurar um endereço IP na interface do ASA e depois conectar-se via ASDM. É possível também fazer as configurações pela CLI normalmente como fizemos nos roteadores. Você pode utilizar o GNS3 para simular o ASA em seu computador ou laptop. O recomendado é utilizar o Cisco ASA 5520 with IOS 8.4.2 and ASDM 6.47. O funcionamento no GNS3 é relativamente simples, basta seguir os passos a seguir.


   

 

 



   

    

   



Página 192

 

 

  


Inicie pegando os códigos fonte no link: https://www.box.com/s/9a4f93e904799e189d64 ou http://www.mediafire.com/download/l010dd0c1nayf0d/ASA842.zip Depois de fazer o download descompacte o arquivo em um local conhecido do seu computador, pois utilizaremos na configuração a seguir. Agora vamos aos passos finais da configuração do ASA no GNS3: 1. Entre em Editar > Preferências > Qemu e em General Settings configure a pasta que você descompactou os arquivos baixados. Aplique a configuração. 2. Na aba ASA dê um nome no campo Identifier Name, exemplo, ASA-8.4.2. 3. Configure a RAM para 1024 Mb. 4. No campo «Qemu Options» copie os seguites parâmetros: -vnc none -vga none -m 1024 icount auto -hdachs 980,16,32 5. No campo «Initrd» aponte para o caminho do arquivo “asa842-initrd.gz” 6. No campo «Kernel» aponte para o arquivo “asa842-vmlinuz” 7. No campo «Kernel cmd line» copie os parâmetros abaixo: -append ide_generic.probe_mask=0x01 ide_core.chs=0.0:980,16,32 auto nousb console=ttyS0,9600 bigphysarea=65536 8. Salve as configurações e aplique. Agora no painel de dispositivos insira um ASA e inicie o dispositivo. Após inicializado você dev e entrar com a chave de ativação do firewall com os comandos abaixo. conf t activation-key 0x4a3ec071 0x0d86fbf6 0x7cb1bc48 0x8b48b8b0 0xf317c0b5 ! ou activation-key 0xb23bcf4a 0x1c713b4f 0x7d53bcbc 0xc4f8d09c 0x0e24c6b6 wr exit

Para acessar o ASA via ASDM é o mesmo princípio do roteador, temos que inserir uma núvem e conectar o ASA a uma interface loopback. Configure a topologia, sua interface loopback com um IP que deve estar na mesma sub-rede do ASA seguindo os passos abaixo: 1. Insira um switch e conecte o ASA a ele antes de ligá-lo. 2. Conecte a núvem ao switch e não diretamente ao ASA.


   

 

 



   

    

   



Página 193

 

 

  


Para configurar a interface conectada ao switch no ASA utilize o scritp abaixo (considerei o ASA com IP 10.0.0.1 e meu computador 10.0.0.10/24): config t int gi 0 ip address 10.0.0.1 255.255.255.0 nameif gerenciamento no shut end wr

Teste a conectividade com seu computador pingando o IP configurado na loopback que conecta a núvem ao ASA: ciscoasa#ping 10.0.0.10 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.0.10, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms ciscoasa#

Se você não tem o ASDM na memória flash precisa copiá-lo com o comando “copy tftp: flash:” (mesmo princípio do roteador), porém primeiro ative seu servidor TFTP no computador e garanta que seu firewall permita o acesso ou desative-o. ciscoasa#copy tftp flash: Address or name of remote host [10.0.0.10]? Source filename [ASDM-647.bin]? Destination filename [ASDM-647.bin]? Accessing tftp://10.0.0.10/ASDM-647.bin...!!!!!!!!!!!!!!!!!! ###Saída Omitidas ###!!!!!!!! 17902288 bytes copied in 98.220 secs (182676 bytes/sec) ciscoasa#show flash: --#-- --length-- -----date/time------ path 3 4096 Nov 09 2013 00:24:06 log 8 4096 Nov 09 2013 00:24:08 coredumpinfo 9 59 Nov 09 2013 00:24:08 coredumpinfo/coredump.cfg 13 196 Nov 09 2013 00:24:08 upgrade_startup_errors_201311090024.log 14 196 Nov 09 2013 00:27:58 upgrade_startup_errors_201311090028.log 15 196 Nov 09 2013 00:34:28 upgrade_startup_errors_201311090034.log 22 17902288 Nov 09 2013 01:04:14 ASDM-647.bin 266846208 bytes total (248877056 bytes free) ciscoasa#

Uma vez copiado o arquivo ASDM-647.bin na flash execute os seguintes comandos para permitir que o ASA seja acessado via ASDM: ciscoasa#conf t ciscoasa(config)#ASDM image flash:ASDM-647.bin ciscoasa(config)#http server enable ciscoasa(config)#http 10.0.0.10 255.255.255.255 gerenciamento ciscoasa(config)#username dltec password dltec123 privilege 15 ciscoasa(config)#end ciscoasa#wr Building configuration... Cryptochecksum: ca21aef9 c95a02fe cae19878 bbd7931c


   

 

 



   

    

   



Página 194

 

 

  


2270 bytes copied in 0.640 secs [OK] ciscoasa#

Para acessar o ASDM entre em seu browser e digite https://10.10.10.1. Clique na opção Install ASDM Launcher para fazer o download e instalar o aplicativo ASDM a partir do ASA. Após instalar o aplicativo você poderá acessar o ASA via interface gráfica.

Depois será mostrada uma tela para entrar com o IP, usuárion e senha de acesso ao ASA.


   

 

 



   

    

   



Página 195

 

 

  


No próximo tópico vamos aprender a configuração básica do firewall ASA. O ASA emulado no GNS3 pode algumas vezes para de responder e parecer que travou, por isso é importante sempre salvar as configurações e ter paciência, pois ele volta a responder após um tempo relativamente curto. Em ASAs reais, não simulados, quando ele está zerado um guia de configuração parecido com o modo setup dos roteadores será apresentado. Ele é simples e útil para configuração inicial e proporcionar o acesso via Web. 6.5 Configurando e Testando o ASA via ASDM Existe um menu muito útil chamado Wizards com várias ferramentas guidas de configuração fácil. Você pode utilizá-lo para configurar diversos recursos, inclusive zerar o equipamento (voltar às configurações de fábrica).


   

 

 



   

    

   



Página 196

 

 

  


Vamos abaixo indicar os caminhos para configuração manual dos principais itens: Interfaces: Configuration > Device Setup > Interfaces Servidor DHCP: Configuration > Device Management > DHCP > DHCP Server Roteamento básico: Configuration > Device setup > Routing NAT e PAT: Configuration > Firewall > NAT Rules Regras de firewall: Configuration > Firewall > Access Rules     

Para testes temos a opção Monitoring e também o Packet Tracer no menu Tools, não é o programa Packet Tracer que simula redes é uma ferramenta do ASDM. Essa ferramenta do ASDM permite que você verifique se determinado tráfego vai ser permitido ou bloqueado pelo firewall.

Esse teste pode ser feito pela CLI utilizando o comando abaixo: ASA#packet-tracer input inside tcp 10.0.0.101 1065 1.2.3.4 80

Nesse teste estamos verificando se o pacote gerado pela origem 10.0.0.101 com porta 1065 será encaminhado para o destino 1.2.3.4 porta de destino 80, ou seja, se o computador 10.0.0.101 acessa o servidor de Web 1.2.3.4. Veja o resultado do teste feito pelo ASDM. A configuração via ASDM será mostrada durante a vídeo aula do capítulo.


   

 

 



   

    

   



Página 197

 

 

  


6.6 Configurando o ASA via CLI Vamos mostrar os comandos e as explicações diretamente abaixo. Nesse exemplo vamos configurar as interfaces utilizando VLANs para dividir a rede corporativa, Internet e DMZ, onde servidores estarão expostos na Internet. ASA-FW(config)#configure terminal ASA-FW(config)# ! Vamos começar com a Switched Virtual Interface (SVI – camada-3) ASA-FW(config)#interface Vlan1 ! Ativando a interface ASA-FW(config-if)#no shutdown ! Adicionando a descrição opcional ASA-FW(config-if)#description Conectada à DMZ ! Dando um nome à interface ASA-FW(config-if)#nameif dmz ! Definindo o nível de segurança (security level) ASA-FW(config-if)#security-level 50 ! Configurando o endereço IP ASA-FW(config-if)#ip address 192.168.1.1 255.255.255.0 ASA-FW(config-if)#exit ! Agora vamos configurar as demais interfaces VLAN ASA-FW(config)#interface Vlan2 ASA-FW(config-if)#no shutdown ASA-FW(config-if)#nameif redeinterna ASA-FW(config-if)#security-level 100 ASA-FW(config-if)#ip address 10.0.0.1 255.255.255.0 ASA-FW(config-if)#exit ASA-FW(config)# ASA-FW(config)#interface Vlan4 ASA-FW(config-if)#no shutdown ASA-FW(config-if)#no forward interface Vlan2 ASA-FW(config-if)#nameif Internet ASA-FW(config-if)#security-level 0 ASA-FW(config-if)#ip address 200.200.200.2 255.255.255.240 ASA-FW(config-if)#exit ASA-FW(config)# ! Vamos agora vincular as interfaces às VLANs criadas ASA-FW(config)#interface Ethernet0/1 ASA-FW(config-if)#switchport access vlan 4 ASA-FW(config-if)#exit ASA-FW(config)# ASA-FW(config)#interface Ethernet0/2 ASA-FW(config-if)#switchport access vlan 2 ASA-FW(config-if)#exit ASA-FW(config)# ASA-FW(config)#interface Ethernet0/3 ASA-FW(config-if)#switchport access vlan 2 ASA-FW(config-if)#exit ASA-FW(config)# ASA-FW(config)#interface Ethernet0/4 ASA-FW(config-if)#switchport access vlan 2 ASA-FW(config-if)#exit ASA-FW(config)# ASA-FW(config)#interface Ethernet0/5 ASA-FW(config-if)#switchport access vlan 2 ASA-FW(config-if)#exit ASA-FW(config)# ASA-FW(config)#interface Ethernet0/6


   

 

 



   

    

   



Página 198

 

 

  


ASA-FW(config-if)#switchport access vlan 2 ASA-FW(config-if)#exit ASA-FW(config)# ASA-FW(config)#interface Ethernet0/7 ASA-FW(config-if)#switchport access vlan 2 ASA-FW(config-if)#exit ! Vamos verificar as configurações ASA-FW(config)#show run interface interface Ethernet0/0 ! interface Ethernet0/1 switchport access vlan 4 ! interface Ethernet0/2 switchport access vlan 2 ! interface Ethernet0/3 switchport access vlan 2 ! interface Ethernet0/4 switchport access vlan 2 ! interface Ethernet0/5 switchport access vlan 2 ! interface Ethernet0/6 switchport access vlan 2 ! interface Ethernet0/7 switchport access vlan 2 ! interface Vlan1 description Conectada à DMZ nameif dmz security-level 50 ip address 192.168.1.1 255.255.255.0 ! interface Vlan2 nameif redeinterna security-level 100 ip address 10.0.0.1 255.255.255.0 ! interface Vlan4 no forward interface Vlan2 nameif Internet security-level 0 ip address 200.200.200.2 255.255.255.240 ASA-FW(config)#

Se o ASA não suportar o comando “interface vlan”, ou seja, não suportar as SVIs você pode criar VLANs de forma similar ao que fizemos nos roteadores, porém a VLAN Untagged fica na interface física e as subinterfaces levan as demais VLANs, ou seja, a de ger enciamento dica na interface física. Veja exemplo abaixo. interface GigabitEthernet0 nameif principal security-level 100 ip address 10.0.0.1 255.255.255.0 !


   

 

 



   

    

   



Página 199

 

 

  


interface GigabitEthernet0.2 vlan 2 nameif redeinterna1 security-level 100 ip address 10.0.1.1 255.255.255.0 ! interface GigabitEthernet0.3 vlan 3 nameif redeinterna2 security-level 100 ip address 10.0.2.1 255.255.255.0

Agora vamos configurar o servidor DHCP para a rede corporativa (interface redeinterna). ASA-FW(config)#dhcpd ASA-FW(config)#dhcpd ASA-FW(config)#dhcpd ASA-FW(config)#dhcpd

address 10.0.0.100-10.0.0.200 redeinterna enable redeinterna dns 8.8.8.8 interface redeinterna domain dltec-iins.com interface redeinterna

Vamos configurar a rota para a Internet, sendo que o IP do gateway do provedor é 200.200.200.1. Note que após o comando route referenciamos a interface conectada à internet pelo nome que demos a ela na configuração. ASA-FW(config)#route Internet 0.0.0.0 0.0.0.0 200.200.200.1

Para configurar o NAT/PAT utilizamos os comandos abaixo. Primeiro vamos criar um objeto que se referencie à rede corporativa 10.0.0.0/24. ASA-FW(config)#object network rede_interna ASA-FW(config-network-object)#subnet 10.0.0.0 255.255.255.0 ASA-FW(config-network-object)#description rede_interna ASA-FW(config-network-object)#exit

Para criar a regra do NAT utilizamos o comando abaixo: ASA-FW(config)#nat (redeinterna,Internet) 1 source dynamic rede_interna interface

Entre parenteses temos a rede inside (interface com nome redeinterna) e outside (interface com nome Internet), conforme configuramos anteriormente. Para criar regras adicionais ao firewall via CLI vamos a um exemplo prático abaixo, você vai notar que a configuração é um pouco diferente do roteador, porém com uma lógica mais simples. ASA-FW(config)#access-list acesso-in deny tcp any any eq telnet ASA-FW(config)#access-list acesso-in deny tcp any any eq www ASA-FW(config)#access-list acesso-in permit ip any any ASA-FW(config)#access-group acesso-in in interface redeinterna

Note que as regras são similares a uma ACL IP nomeada estendida, porém não é aplicada à Interface e sim vinculada diretamente em modo de configuração global através do nome da interface. A regra criada proibe acesso Telnet e HTTP da rede corporativa em direção à Internet, pois o in e out aqui tem o mesmo significado que nos roteadores, portanto o in em uma interface LAN pega o tráfego que está saindo da LAN em direção a outra interface.


   

 

 



   

    

   



Página 200

 

 

  


7 Resumo do Capítulo Bem pessoal, chegamos ao final do capítulo. É muito importante que nesse ponto do curso você tenha domínio dos seguintes itens: Explicar a funcionalidade das ACL’s padrão, estendida e nomeada utilizadas pelos roteadores para filtrar pacotes. Configurar e verificar ACL’s IP para reduzir ameaças em redes via CLI (filtro de tráfego destinado ao Telnet, SNMP e ataques DDoS). Prevenindo a falsificação de endereço IP (IP Spoofing) utilizando ACL’s via CLI. Analisar e identificar pontos chaves a serem considerados na construção de ACLs. 



 


   

 

 



   

    

   



Página 201

 

 

  


Capítulo 7 - Segurança na Camada 2 Nesse capítulo estudaremos como mitigar ataques à camada-2 (Layer-2).

Objetivos do Capítulo Ao final desse capítulo você terá estudado e deverá compreender: Ameaças e ataques possíveis na camada de enlace. Opções de mitigação na camada de enlace. Descrever como prevenir ataques de camada 2. Configurar recursos de segurança em switches Cisco Catalyst.

A camada de enlace é a porta de entrada para a rede e uma vez comprometida todas as demais camadas também estarão, portanto é de suma importância que o administrador de rede conheça e saiba mitigar os possíveis ataques à camada 2.











   

 

 



   

    

   



Página 202

 

 

  


2.5.4 Storm)


Introdução _____________________ 204

3 Recursos e Configurações de Segurança na Camada 2 ______________________ 217

3.1

1.1 Visão Geral dos Recursos de Segurança em Camada-2________________________ 205 2

3.2 Configurando os Comandos Portfast e BPDU Guard ________________________ 222

2.1 MAC Spoofing (falsificação de endereço MAC) 209 MAC Address Table Overflow _____ 209

2.3

Ataques ao Serviço de DHCP ______ 211

2.4 Ataques ao Protocolo ARP - ARP Spoofing ____________________________ 212

VLAN Hopping _________________ 213 Double Tagging _________________ 214 Ataques ao Spanning Tree ________ 215

3.3

Configurando o Root Guard ______ 224

3.4

Segurança nos Trunks ___________ 225

3.5

Configurando o DHCP Snooping ___ 225

3.6

Configurando o Storm Control ____ 227

3.7

Protocolo 802.1x e Cisco IBNS _____ 228

3.8 Espelhamento de Portas - SPAN e RSPAN _____________________________ 230

2.5 Ataques a VLAN e ao Protocolo Spanning-Tree (STP) __________________ 212 2.5.1 2.5.2 2.5.3

Configurando o Port Security _____ 217

3.1.1 Exemplo Prático de Configuração e Verificação do Port Security _______________ 221

Tipos de Ataques à Camada de Enlace 205

2.2

Tempestade de broadcast (Broadcast 216

3.8.1

4

RSPAN ou SPAN Remoto _________ 232

Resumo do Capítulo _____________ 234


   

 

 



   

    

   



Página 203

 

 

  


1 Introdução Normalmente a tendência do administrador de segurança de redes é focar seus recursos em equipamentos como roteadores e firewalls, limitando o trabalho de proteção dos recursos de TI na Camada 3 e superiores, deixando muitas vezes equipamentos da Camada 2 nos padrões de fábrica ou com configurações mínimas necessárias para seu funcionamento.

Essa tendência de extremo cuidado com firewalls e roteadores deve-se ao fato de que são esses os equipamentos que separam a intranet corporativa das outras redes externas (Internet e Extranets). Como a tendência é imaginar que a absoluta maioria das ameaças se origina na Internet, a rede Interna ou Intranet e seus principais equipamentos (Switches) são normalmente esquecidos no planejamento da segurança de TI, porém descuidar da possibilidade da intranet tornar-se um alvo de ataques é um grande erro que precisa ser corrigido no momento de estabelecer o Plano de Segurança da TI, pois uma rede é tão segura como seu elo mais fraco. Pelos motivos citados acima e as estatísticas, que apontam um crescimento em ataques originados pela rede interna das empresas, que os equipamentos de camada-2, como switches, devem ser protegidos seguindo as melhores práticas de segurança e dos fabricantes. É importante lembrar também que a segurança dos equipamentos terminais, como computadores e servidores, inclui também garantir que a infra-estrutura de rede esteja preparada para prevenir ataques à camada-2, tais como MAC spoofing e ataques de manipulação de STP. As configurações de segurança camada-2 incluem o port-security, BPDU guard, proteção do root-bridge, o controle da tempestade de broadcast, SPAN e SPAN remotos (RSPAN) para a monitoração das VLANs, tópicos que serão abordados durante esse capítulo. Além disso, estudaremos considerações de segurança em redes sem fio, VoIP, tecnologias SANs e segurança nos endpoints (micros e servidores).


   

 

 



   

    

   



Página 204

 

 

  


1.1 Visão Geral dos Recursos de Segurança em Camada-2 Se focarmos nos recursos de segurança na camada-2 desenvolvidos pela Cisco podemos citar com destaque as seguintes ferramentas: 







 







Port security: limita o número de endereços MAC que pode ser aprendido por porta de um switch. BPDU guard: protege as portas do switch detectando BPDUs recebidos em locais não permitidos bloqueando a porta. Root guard: controle que porta ou não pode ser eleita como “root port” protegendo a topologia do STP. Dynamic ARP inspection: previne o spoofing em camada-2 analisando as características dos hosts conectados às portas dos switches. IP source guard: protege a rede contra o spoofing de camada-3. 802.1x: autentica usuários e permite que somente quadros devidamente autenticados sejam enviados na rede. DHCP snooping: previne que “rogue DHCP servers” (servidores DHCP piratas) injetem informações falsas em clientes de rede. Storm control: limita a quantidade de tráfego broadcast ou multicast enviados pelos switches na rede. Access control lists: já estudamos as ACLs e elas podem ajudar a reforçar as políticas de segurança melhorando também a segurança na camada-2.

Em termos do exame IINS (CCNA Security) o maior foco da prova na segurança da camada de enlace será encima do port security, BPDU guard, root guard, DHCP snooping e ACLs. 2 Tipos de Ataques à Camada de Enlace A camada de enlace é a porta de entrada para a rede e uma vez comprometida todas as demais camadas também estarão, portanto é de suma importância que o administrador de rede conheça e saiba mitigar os possíveis ataques à camada 2. Em um computador a camada 2 está dentro do driver de uma placa de rede e tem uma instrução básica de ler o endereço de destino que vem do quadro recebido, comparar com seu próprio endereço MAC, quando forem iguais ela repassa para a camada superior, ou seja, para a camada de Internet (protocolo IP), caso seja para um endereço diferente a camada 2 ignora o pacote. Uma exceção à regra é para os endereços de broadcast direcionados ou sobrecarregados que são sempre passados para a camada 3 (MAC = ffff.ffff.ffff). Além disso, existe ainda o endereço de multicast que tem um MAC específico (de 01:00:5e:00:00:00 até 01:00:5e:7f:ff:ff) e se configurado será também tratado pela placa de rede.


   

 

 



   

    

   



Página 205

 

 

  


Nos HUBs temos que lembrar que a camada 2 é transparente, ou seja, um HUB é um dispositivo da camada física e não trata informações das camadas superiores. Para resumir o HUB é como um “curto circuito”, o que um micro transmite todos recebem, por esse motivo maior risco ao utilizar esse tipo de equipamento é o “ sniffing” da rede, o qual consiste em colocar a placa de rede em modo promíscuo, lendo todo e qualquer quadro recebido, para analisar a comunicação dos equipamentos situados naquele segmento de rede. Os programas utilizados para “sniffar” a rede são Wireshark, EtherDetect, IPTraf, dentre outros. Com esses programas os atacantes conseguem capturar usuários e senhas, por exemplo, ou as mensagens trocadas com aplicativos como e-mails e Instant Messengers. Na figura a seguir temos um exemplo da tela do Wireshark.


   

 

 



   

    

   



Página 206

 

 

  


O uso dos switches e bridges melhora substancialmente o risco do sniffing, pois eles são equipamentos de camada 2 e trabalham aprendendo os endereços MACs dos hosts que estão em suas portas, criando uma tabela chamada SAT/CAM ou Content Addressable Memory e encaminhando os quadros diretamente para as portas onde esses micros estão conectados, criando um caminho virtual ponto a ponto entre os dois hosts, veja a figura a seguir.


   

 

 



   

    

   



Página 207

 

 

  


Porém, enquanto o MAC não é aprendido o switch fará uma inundação ou flooding do quadro, enviando uma cópia do quadro para todas as portas, menos a que o enviou. Outra situação anômala que um switch pode apresentar é quando sua tabela de endereços MAC está cheia e há um estouro da memória, nesse caso o switch faz o processo de flooding constantemente tornando o switch funcionalmente igual a um HUB, possibilitando o sniffing dos pacotes que trafegam por ele. Com base no conteúdo estudado até o momento, podemos classificar os principais riscos comuns à camada 2 como: • MAC Spoofing (falsificação de endereço MAC). • MAC Address Table Overflow (estouro da tabela MAC). • Ataques de DHCP (considerado em algumas bibliografias como ataques à camada 7). • Ataques de ARP (considerado em algumas bibliografias como ataques à camada 3). • Ataques ao protocolo STP. • Ataques a VLANs (LANs Virtuais). • Tempestade de broadcast (Broadcast Storm). Vamos a seguir estudar os principais tipos de ameaças à camada de enlace.


   

 

 



   

    

   



Página 208

 

 

  


2.1 MAC Spoofing (falsificação de endereço MAC) É um tipo de ataque utilizado para substituir uma entrada na tabela CAM que possui um endereço MAC conhecido que aponta para uma determinada porta, fazendo com que ele aponte para outra porta - normalmente a que o atacante está conectado. Quando o switch recebe o mesmo endereço MAC em uma porta diferente ele apaga a entrada antiga e assume a nova entrada como verdadeira. Na figura abaixo temos um exemplo onde um dos hosts está se fazendo passar pelo servidor.

Através desse ataque é possível causar a interrupção de serviços e pode, também, ser usado como um ataque man-in-the-middle. Esse tipo de ataque só pode ser bloqueado em switches gerenciáveis que possuem ferramentas de segurança para tal, como por exemplo, o port security dos Switches Cisco. 2.2 MAC Address Table Overflow O endereço MAC é a principal forma de identificação de equipamentos em uma rede, e são utilizados em redes Ethernet, Wireless (802.11a/b/g), Bluetooth, FDDI, Fiber Channel e Token Ring. Os endereços MAC possuem 48 bits, sendo que os primeiros 24 bits são utilizados para identificar o fabricante da placa de rede e são definidos pelo IEEE, já os últimos 24 bits são atribuídos pelo fabricante da placa. Para que os endereços MAC funcionem adequadamente eles devem ser únicos dentro de uma rede, caso haja mais de um haverá conflito. Por definição o endereço FF-FF-FF-FF-FF-FF é usado como endereço de broadcast, ou seja, servirá para comunicação simultânea com todas as máquinas que estão na mesma rede. Um switch constrói e mantém dinamicamente uma tabela CAM (Content-Addressable Memory) ou tabela de endereços MAC (MAC Adrress Table), mantendo todas as informações MAC necessárias para cada porta. A memória CAM é o equivalente no switch à tabela de roteamento dos roteadores. É a partir das informações armazenadas na tabela CAM que o switch escolhe para qual porta um determinado quadro deve ser encaminhado.


   

 

 



   

    

   



Página 209

 

 

  


Um dos principais problemas de segurança envolvendo o endereçamento da camada de enlace é o overflow da tabela CAM dos switches. A tabela CAM de um switch é responsável por armazenar e relacionar endereços MAC, portas e parâmetros de VLANS, podendo assim encaminhar de forma correta os quadros que passam por ele. Fisicamente a tabela CAM é armazenada em uma memória normal e como tal possui tamanho limitado, percebendo isso no ano de 1999 Ian Vitek criou Vitek criou uma ferramenta chamada Macof , que cria inundações de endereços MAC de origem inválidos (cerca de 155000 por minuto). Essa ferramenta é capaz de encher rapidamente a tabela CAM do switch que está diretamente conectado ao host responsável pela execução da ferramenta, e os switches que estiverem conectados ao equipamento atacado também são afetados.

O resultado desse ataque é um comportamento adotado pelo switch quando ele não consegue encontrar um endereço em sua tabela, ele envia os quadros recebidos para todas as suas portas, passando a se comportar como um Hub, conforme figura a seguir.


   

 

 



   

    

   



Página 210

 

 

  


Com esse comportamento é possível realizar a espionagem dos pacotes e até possibilitar um ataque de man-in-the-middle monitorando o tráfego da rede. Este tipo de ataque, também conhecido como ataque do homem do meio, é um cenário no qual o atacante intercepta a comunicação entre dois hosts e falsifica as mensagens a fim de fazer-se passar por uma das partes. Para resolver esse problema é preciso utilizar switches gerenciáveis que possuam ferramentas de segurança para controlar os dados que trafegam por cada porta, além disso, deve-se realizar um monitoramento refinado dos dados que trafegam pela rede a fim de detectar o uso não autorizado de ferramentas de monitoramento. Esse ataque também pode ser mitigado com o uso do port security que security que será estudado posteriormente. Esse comportamento de encaminhar os quadros cujo endereço não é conhecido, chamado de flooding ou inundação, ou quando a tabela CAM está cheia para todas as portas (menos para a própria porta que encaminhou o quadro) é chamado de modo fail-open ou falha aberta. aberta. No modo fechado ou fechado ou fail-closed o fail-closed o comportamento seria o contrário, ou seja, o equipamento não encaminharia esse tipo de quadro que ele não saberia encaminhar, porém no caso dos switches isso não é possível de se configurar. 2.3 Ataques ao Serviço de DHCP O primeiro tipo de ataque ao serviço de DHCP consiste em esgotar todos os endereços IP disponíveis no servidor DHCP (DHCP (DHCP Starvation), Starvation), para tal o atacante envia diversas requisições DHCP com endereços MACs falsos. Isso leva à negação de serviço (DoS) na rede para os clientes habituais, abrindo uma brecha para os atacantes configurarem um servidor DHCP falso, e através dele enviar informações falsas para os clientes, como por exemplo, dando-lhes o seu próprio endereço IP, se passando por default gateway. A partir do momento que os clientes aceitarem as novas configurações DHCP todo o tráfego da rede passará pela máquina do atacante, tornando assim muito fácil o monitoramento das informações.


   

 

 



   

    

   



Página 211

 

 

  


O segundo tipo de ataque é quando servidores DHCP falsos são inseridos na rede e como os clientes aceitam o primeiro DHCP OFFER que recebem, os clientes seriam configurados com informações falsas visando captura de pacotes ou ataques de MITM. É o que chamamos de Rogue DHCP Server ou inserir um DHCP “pirata” na rede fornecendo endereços IP e informações falsas para os clientes de rede. Esse problema pode ocorrer de forma proposital e maliciosa por um atacante ou então mesmo sem intenção de atacar a rede por usuários testando funcionalidades de dispositivos móveis ou que desejam compartilhar um ponto de rede físico através de um AP sem fio, por exemplo. Sendo proposital ou não o envio de anúncios de DHCP não legítimos na rede deve ser fortemente combatido, pois podem gerar graves problemas para os usuários finais. Para mitigar esses tipos de ataque temos o DHCP Snooping, que classifica cada porta como trusted ou untrusted (confiável ou não confiável), possibilitando proteger o serviço de DHCP legítimo da rede. 2.4 Ataques ao Protocolo ARP - ARP Spoofing O acrônimo ARP significa Address Resolution Protocol, e é um dos protocolos mais utilizados para mapear endereços IP para endereço MAC, além de ser essencial para a comunicação TCP/IP. Dentro de um mesmo segmento de rede computadores trocam mensagens ARP uns com os outros para encontrar o endereço MAC baseados no endereço IP que possuem. Por ser um protocolo muito simples ele não possui muitos recursos de segurança, o que acaba abrindo uma brecha para possíveis ataques. O ataque mais conhecido para se aproveitar da simplicidade do protocolo ARP é o ARP Spoofing, e consiste no envio de endereços IP ou MAC falsos causando ataques como a negação de serviços e o man-in-the-middle. man-i n-the-middle. Uma das formas de se evitar estes ataques é adicionando os pares IP/MAC manualmente na tabela ARP dos computadores na rede, o que ajudaria a eliminar alguns cenários de ataque ARP Spoofing, mas está longe de ser uma solução viável, uma vez que, em redes de grande porte seria quase que impossível manter um controle adequado. Outra solução que ajudaria a amenizar esse problema seria utilizar ferramentas de monitoramento e auditoria, dessa forma seria possível averiguar com mais rapidez comportamentos anormais no tráfego da rede. r ede. Os recursos como o DAI ( DAI (Dynamic Dynamic ARP Inspection) Inspection) e o IP Source Guard podem Guard podem ser utilizados para mitigar o ARP Spoofing, assim como o MAC e IP Spoofing. 2.5 Ataques a VLAN e ao Protocolo Spanning-Tree (STP) As VLANs (IEEE 802.1Q) são redes logicamente independentes ligadas fisicamente em uma rede maior, permitindo criar múltiplos domínios de broadcast dentro da rede, além de separar diferentes tipos de tráfegos. A tecnologia de LANs virtuais permite grande flexibilidade no gerenciamento da rede, uma vez que dá ao administrador a possibilidade de criar diversas LANs Virtuais ou VLANs dento do mesmo switch. É possível também através de trunks transportar dados e informações de VLANs entre os diversos switches. Trunks são interligações entre switches que permitem identificar a que VLAN pertence determinado dado através de tags, compartilhando a informação das diversas VLANs em um único link. Através da criação de VLANs é possível se atingir um excelente nível de segurança na camada de enlace, pois permite a separação dos diferentes tipos de tráfego existente na rede.


   

 

 



   

    

   



Página 212

 

 

  


Mas ainda assim é preciso tomar cuidado, pois a má configuração desses switches pode permitir a ocorrência de um ataque conhecido como VLAN hopping. Esse tipo de ataque permite ao invasor tentar enviar dados para hosts que estão em outras VLANs através da alteração da tag que diz a qual VLAN pertence o dado. Como a implementação do 802.1Q está disponível para os mais diversos sistemas operacionais ele possui um modo padrão de funcionamento do trunk, o que permite ao atacante criar um link em modo trunk entre ele e o switch, e dessa forma ter acesso a todos os hosts em todas as VLANs configuradas. Nos switches da Cisco existe um protocolo para estabelecimento dinâmico de trunks chamado DTP (Dynamic trunk protocol), o qual possibilita o ataque citado acima. Com o uso desse protocolo DTP um atacante pode colocar um switch na rede e se autoconfigurar com um trunk para capturar informações de VLANs que estejam passando por aquele segmento de rede. O recomendado para os switches é não utilizar o protocolo DTP e deixar somente os links que realmente são reservados para o entroncamento entre os switches como trunk, os demais como portas de acesso, fechando ao máximo a possibilidade de autoconfiguração. 2.5.1 VLAN Hopping

Um ataque de VLAN hopping pode ser lançado em uma de duas maneiras. 1. Introduzindo um switch na rede (rogue switch) e configurando a porta dele em modo de trunking. A partir daqui, o atacante pode enviar o tráfego para uma determinada VLAN e atacar um segmento de rede ou host específico daquela sub-rede.

2. Enviando de mensagens falsas de DTP através de um computador com uma placa de rede que suporte o protocolo 802.1Q e fazendo o mesmo ataque exposto anteriormente,

Para evitar esse tipo de problema é recomendado desativar o DTP, configurar as portas não trunk como acesso e desabilitar as portas não utilizadas, colocando-as em shutdown e/ou em uma VLAN sem uso (de contenção).


   

 

 



   

    

   



Página 213

 

 

  


2.5.2 Double Tagging

Um tronco ou trunk 802.1Q marca com uma etiqueta ou tag cada quadro indicando a que VLAN ele pertence, processo chamado de “tagging” ou etiquetamento. O double tagging é um ataque onde o invasor anexa dois rótulos ou tags de VLAN no pacote, daí o nome double tag ou etiquetamento duplo. O primeiro rótulo contém um tag tag válido para VLAN em que ela participa, o qual ao ao chegar no primeiro switch ele é apagado e o quadro com a segunda tag é enviado para o destino. O segundo tag, o qual é falso, agora está visível para o segundo switch que o pacote encontra. O cabeçalho do quadro indica que ele é destinado para uma entidade em uma VLAN diferente da original (tag 1) e pertencente a VLAN indica no tag falso. Portanto, o quadro é enviado para a entidade da rede a qual originalmente o atacante não tinha acesso.

Para evitar esse tipo de ataque é recomendado alterar a VLAN nativa, que nos equipamentos Cisco vem como VLAN 1, para outro valor e não utilizar essa VLAN para envio de dados, ou seja, que essa VLAN não seja utilizada. Com essa recomendação e a dada anteriormente de desabilitar o DTP (protocolo de tronco dinâmico da Cisco) nas portas trunk você garante que um switch invasor (roge switch) não vai conseguir fazer o VLAN Hop nem o double tagging, sendo essas as principais recomendações para mitigar esse tipo de ataque.


   

 

 



   

    

   



Página 214

 

 

  


2.5.3 Ataques ao Spanning Tree

Outro tipo de ataque bastante conhecido é a criação de loops na rede, rede , que acontece quando duas portas pertencentes à mesma VLAN possuem ligações entre si, ou quando há dois ou mais caminhos entre dois switches.

Usuários com más intenções e que possuem acesso a infraestrutura de TI podem criar fisicamente loops na rede, ligando cabos cruzados em portas que pertencem ao mesmo switch e a mesma VLAN. Este tipo de ataque faz com que os pacotes de broadcast trafeguem por um longo período de tempo em sua rede, inundando cada porta que pertence à VLAN atacada em cada switch, prejudicando bastante o desempenho, ou até mesmo derrubando a rede. Para resolver esse problema foi desenvolvido o STP ou Spanning Tree Protocol (IEEE 802.1D), que trabalha para desativar links que possam formar loops, verificando a possibilidade de implantação de ligações redundantes na rede. Mas com essa solução veio também outro tipo de problema, onde o atacante envia broadcasts de configuração STP ou mudanças de topologia através dos BPDUs (Bridge Protocol Data Unit), forçando recálculos STP e esperando que o atacante se torne o root bridge (spoofing ou falsificação de root bridge). O STP demora cerca de 30 a 45 segundos para reeleger um novo root bridge caso o antigo falhe, resultando assim em ataques de negação de serviço. Como root bridge, o atacante pode monitorar todos os quadros ethernet que pertencem p ertencem a outras VLANs. Nesse caso, para evitar os ataques basta monitorar o tráfego da rede e verificar de tempos em tempos as configurações dos switches. Nos switches Cisco outra maneira de mitigar a manipulação do STP inclui a configuração do PortFast, root guard e o BPDU guard, os quais serão estudados posteriormente.


   

 

 



   

    

   



Página 215

 

 

  


2.5.4 Tempestade Tempestade de broadcast (Broadcast Storm)

Pacotes de broadcast e multicast são comuns em todas as redes e utilizados por diversos protocolos, tais como ARP, DHCP, DNS e outros, porém um nível excessivo desse tipo de tráfego pode causar degradação na rede podendo diminuir o tráfego para os usuários ou até parar completamente a transmissão impossibilitando o uso dos recursos de rede. Esse excesso de broadcasts pode ser causado por problemas de configuração, placas de rede defeituosas ou por um ataque de negação de serviço ou DoS que esteja sendo realizado por um atacante. No caso de um ataque, pacotes de multicas e/ou broadcast são enviados excessivamente em uma mesma VLAN, o que causará um uso excessivo da CPU do switch levando a 100% do processamento, podendo prejudicar a performance substancialmente e até mesmo, no limiar, causar a interrupção dos serviços de rede.

Nos switches da Cisco existe a facilidade do “storm control” ou controle de tempestade de broadcast, o qual monitora os quadros de broadcast e quando o nível atingir um limiar prédeterminado o switch bloqueará o tráfego para evitar a sobrecarga em sua CPU. Essa monitoração é efetuada em um determinado período de tempo, se entre esse período o tráfego excede o limiar ele é bloqueado, conforme mostrado a seguir.


   

 

 



   

    

   



Página 216

 

 

  


3 Recursos e Configurações de Segurança na Camada 2 As configurações de segurança para quaisquer camadas dependem da política organizacional, porém existem algumas recomendações e boas práticas que vamos abordar nesse n esse capítulo. A primeira recomendação é sempre que possível fazer o gerenciamento da rede fora da banda (out of band), segregando o tráfego interno do gerenciamento. Além disso, é importante desativar serviços que não são necessários e portas que não estão sendo utilizadas (shutdown). Implementar o port security, root guard, BPDU guard e demais facilidades de segurança disponíveis nos switches. Outra recomendação é desabilitar o protocolo CDP, porém se sua rede estiver utilizando telefonia IP da Cisco o protocolo será utilizado pelos telefones IP, portanto deve-se avaliar essa questão com cuidado. Alterar a VLAN de gerenciamento geren ciamento e nativa do switch, pois por padrão os switches Cisco utilizam a VLAN 1, o que é conhecido e divulgado em sua documentação, portanto os atacantes já sabem por onde começar se você não alterar esse parâmetro. Segue um resumo das recomendações básicas abaixo: • Fazer o gerenciamento seguro dos dispositivos (SSH, gerenciamento out-of-band, out -of-band, ACLs nas linhas de VTY, senhas seguras, etc). • Utilizar o port security em portas p ortas de acesso. • Habilitar a mitigação de ataques ao STP (BPDU guard e root guard). • Utilizar o CDP somente se necessário. • Configurar o PortFast nas portas de acesso (spanning -tree portfast). • Configurar o root guard nas não root ports do STP. • Configurar BPDU guard em todas as portas p ortas de acesso. acesso. • Alterar o VLAN ID da VLAN nativa (por padrão vem como 1). • Não utilizar a VLAN 1 para nada. • Desabilitar portas não utilizadas (shutdown) e colocá-las colocá-las em uma VLAN de segregação. • Desabilite o DTP nas portas trunk, configurando manualmente as porta s de entroncamento entre switches. • Configurar todas as portas que não serão utilizadas como trunk para acesso (switchport mode access). 3.1 Configurando o Port Security O Port Security é Security é um assunto já estudado e configurado tanto no CCNA R&S como no CCENT e tem a função de proteger a rede contra ataques de MAC Flooding ou MAC Table Overflow e MAC Spoofing (falsificação), possibilitando possibilitando restringir a entrada de um número grande de endereços MAC em uma interface, limitando e identificando endereços MAC de estações que podem ter acesso as portas. Basicamente essa facilidade exige que o administrador defina como o switch aprende os MACs, defina um limite de aprendizagem de MACs por porta e defina em caso de uma violação, ou seja, se o número máximo de portas aprendidas for excedido ou um MAC diferente está tentando acessar a porta, o que o switch deverá fazer (desliga a porta? informa i nforma a gerência?).


   

 

 



   

    

   



Página 217

 

 

  


Veja abaixo formas que o switch pode aprender os endereços MAC: 1. Endereços MAC estáticos (Static): Esses são configurados manualmente usando o comando: “switchport port-security mac-address aabb.ccdd.eeff ” dentro do modo de configuração de interface. O endereço é guardado na tabela e adicionado ao “running config” do dispositivo. 2. Endereços MAC dinâmicos (Dynamic): Esses, como o nome diz, são aprendidos dinamicamente. O endereço é guardado na tabela MAC, porém não é adicionado ao “running config” e é removido caso o switch reinicie. É a forma padrão de aprendizado pelo port security. 3. Endereços MAC Sticky: Esses podem ser aprendidos dinamicamente ou adicionados manualmente. O endereço é guardado na tabela e adicionado ao “running config”. Como os endereços forem salvos no “running config” não precisam ser aprendidos novamente quando o switch reiniciar. Uma porta segura pode ter de 1 a 132 endereços associados a ela. Porém o numero total de endereços seguros em um switch é normalmente de 1024, dependendo do modelo do switch esse valor pode variar. Portanto, no port security o administrador definirá um número máximo de endereços MAC seguros que cada porta irá permitir e quando esse máximo é atingido, ou seja, uma estação que não tem seu endereço MAC na tabela do dispositivo tentar um acesso na interface, uma violação de segurança ocorre. O Switch pode reagir de três maneiras a essa violação de segurança: 1. Modo Protect: Todos os pacotes vindos de estações com o endereço desconhecido serão descartados até que você libere um número suficiente de endereços MAC seguros ou aumente o número de endereços seguros permitidos. Neste modo você não será notificado das violações de segurança. 2. Modo Restrict: Exatamente igual ao modo Protect. Porém, nesse modo, você é notificado das violações de segurança. É enviada uma trap SNMP, uma mensagem ao syslog e o contador de violações é incrementado. 3. Modo Shutdown: Nesse modo uma violação de segurança muda o estado da porta para “error-disabled” o que desativa a porta (até os leds). Também envia um trap SNMP, uma mensagem ao syslog e incrementa o contador de violações. Essa é a configuração padrão nas portas dos switches Cisco. Veja abaixo uma ilustração do que estudamos até o momento. Acompanhe ao lado as etapas de configuração do port-security em switches Cisco.


   

 

 



   

    

   



Página 218

 

 

  


1. Colocar a interface como acesso: Switch(config)#Interface fast 0/1 Switch(config-if)#Switchport mode acess

2. Ativar o port security na Interface: Switch(config-if)#switchport port-security

Abaixo seguem as opções do comando port security que veremos nos próximos passos. Switch(config-if)#switchport port-security ? aging Port-security aging commands mac-address Secure mac address maximum Max secure addresses violation Security violation mode

3. Definir o máximo de MACs que podem ser aprendidos na Interface (o padrão é 1 e o máximo 132), nesse exemplo vamos definir no máximo 2 MACs para a porta em questão: Switch(config-if)#switchport port-security maximum 2

4. Definir como os MACs serão aprendidos (estático, dinâmico ou sticky): Switch(config-if)#switchport port-security mac-address ? H.H.H 48 bit mac address sticky Configure dynamic secure addresses as sticky


   

 

 



   

    

   



Página 219

 

 

  


Portanto você pode definir o MAC com o format H.H.H, ou seja, 3 conjuntos de 4 caracteres em Hexadecimal, ou utilizar o parâmetro sticky. O padrão é o dynamic, quando um dos dois acima não são utilizados. Vamos no exemplo abaixo definir que um dos MACs será definido estaticamente e o outro dinamicamente com o comando stiky: Switch(config-if)#switchport port-security mac-address ccca.1234.ffe2 Switch(config-if)#switchport port-security mac-address sticky

5. Definir a ação que o switch tomará caso uma violação de segurança seja detectada (protect, restrict ou shutdown): Switch(config-if)#switchport port-security violation ? protect Security violation protect mode restrict Security violation restrict mode shutdown Security violation shutdown mode

Vamos nesse exemplo definir que se houver uma violação a porta deve ser desligada. Switch(config-if)#switchport port-security violation shutdown

6. Definir o tempo que o MAC aprendido será considerado válido em caso de inatividade da porta ou “aging time”: Switch(config-if)#switchport port-security aging ? static Enable aging for configured secure addresses time Port-security aging time type Port-security aging type

O parâmetro static define um aging time para endereço aprendido estaticamente. Já com o parâmetro time você define um tempo específico entre 0 e 1440, sendo que o 0 desabilita o aging time para essa porta, você vai notar que em algumas versões de IOS o valor vai de 1 a 1440. Por último com o parâmetro type você tem duas opções de uso: • Absolute - Os endereços seguros na porta são apagados após o tempo especificado aging time. Esse é o método padrão que vem configurado na interface. • Inactive - Os endereços seguros na porta são excluídos apenas se ela estiver inativa durante o período especificado. É importante lembrar que não podemos utilizar o port security se a porta estiver configurada como: Trunk, Dynamic, Dynamic-access, EtherChannel, 802.1X ou como destino de um Switch Port Analyzer (SPAN). Para a configuração do port security a porta deve ser de acesso.


   

 

 



   

    

   



Página 220

 

 

  


3.1.1 Exemplo Prático de Configuração e Verificação do Port Security

Vamos agora fazer a configuração de um exemplo prático encontrado em redes com telefonia IP da Cisco, onde o telefone IP tem duas portas, uma para conectar-se à rede e outra onde o micro do usuário é conectado nele, portanto vamos definir o máximo de MACs permitidos na porta para 2, com aprendizado dinâmico e em caso de violação vamos desabilitar a porta colocando-a em shutdown. A mesma configuração deve ser aplicada das portas 5 a 24 do switch 2960 que tem 24 portas, pois as primeiras quatro portas são reservadas para entroncamento. Nesse e xemplo consideramos que as configurações de VLAN de Voz e Dados já foram realizadas anteriormente. Switch#conf t Enter configuration commands, one per line. End with CNTL/Z. Switch(config)#interface range fastEthernet 0/5 - 24 Switch(config-if-range)#switchport mode access Switch(config-if-range)#switchport port-security Switch(config-if-range)#switchport port-security maximum 2 Switch(config-if-range)#switchport port-security violation shutdown Switch(config-if-range)#end Switch#show running-config interface f0/5 Building configuration... Current configuration : 164 bytes ! interface FastEthernet0/5 switchport access vlan 10 switchport mode access switchport voice vlan 20 switchport port-security switchport port-security maximum 2 spanning-tree portfast end Switch#

Para verificar o port security você pode utilizar o comando mostrados a seguir. Switch#show port-security ? address Show secure address interface Show secure interface | Output modifiers Switch#show port-security Secure Port MaxSecureAddr CurrentAddr SecurityViolation Security Action (Count) (Count) (Count) --------------------------------------------------------------------------Fa0/5 2 0 0 Shutdown Fa0/6 2 0 0 Shutdown Fa0/7 2 0 0 Shutdown Fa0/8 2 0 0 Shutdown Fa0/9 2 0 0 Shutdown Fa0/10 2 1 0 Shutdown Fa0/11 2 0 0 Shutdown Fa0/12 2 0 0 Shutdown Fa0/13 2 0 0 Shutdown Fa0/14 2 0 0 Shutdown


   

 

 



   

    

   



Página 221

 

 

  


Fa0/15 2 0 0 Shutdown Fa0/16 2 0 0 Shutdown Fa0/17 2 0 0 Shutdown Fa0/18 2 0 0 Shutdown Fa0/19 2 0 0 Shutdown Fa0/20 2 0 0 Shutdown Fa0/21 2 0 0 Shutdown Fa0/22 2 0 0 Shutdown Fa0/23 2 0 0 Shutdown Fa0/24 2 0 0 Shutdown --------------------------------------------------------------------------Total Addresses in System (excluding one mac per port) : 0 Max Addresses limit in System (excluding one mac per port) : 1024 Switch#show port-security interface f0/5 Port Security : Enabled Port Status : Secure-down Violation Mode : Shutdown Aging Time : 0 mins Aging Type : Absolute SecureStatic Address Aging : Disabled Maximum MAC Addresses : 2 Total MAC Addresses : 0 Configured MAC Addresses : 0 Sticky MAC Addresses : 0 Last Source Address : 0000.0000.0000 Security Violation Count : 0 Switch#

Em amarelo grifamos onde podemos ver quantos MACs seguros foram aprendidos na porta do switch. Já em azul temos o campo que mostra se houve violação, ou seja, o número máximo de MACs seguros foi excedido. 3.2 Configurando os Comandos Portfast e BPDU Guard Os comandos que estudaremos agora têm a função de mitigar problemas relativos ao protocolo spanning-tree ou STP. O comando portfast tem a funcionalidade de dizer para o switch que aquela porta não precisará passar pelos processos de listening e learning do spanning-tree, indo diretamente para o estado forwarding. O comando tem duas opções “spanning-tree portfast” ou “spanning-tree portfast trunk”, os quais tem a mesma funcionalidade de fazer a porta ir rapidamente para forwarding state (encaminhar tráfego), porém a diferença é que o primeiro é utilizado em portas de acesso (Access) e o segundo em portas configuradas como trunk. Assim o como spanning-tree portfast o comando spanning-tree portfast trunk não teve ser usado em portas que são utilizadas para uplink (conexão entre dois switches), pois pode causar um loop. Veja um exemplo de configuração. Router(config-if)# spanning-tree portfast Router(config-if)# spanning-tree portfast trunk %Warning:portfast should only be enabled on ports connected to a single host. Connecting hubs, concentrators, switches, bridges, etc... to this interface when portfast is enabled, can cause temporary bridging loops. Use with CAUTION


   

 

 



   

    

   



Página 222

 

 

  


O comando spanning-tree portfast trunk pode ser utilizado em uma porta po rta trunk conectada a um servidor que utilize 802.1q, por exemplo. Quando a porta desse servidor cair ela não terá que esperar por todo o processo do spanning-tree para voltar a responder, melhorando o desempenho para os clientes. Você pode ainda utilizar o comando “spanning-tree “ spanning-tree portfast default” default” para habilitar o portfast em todas as portas não trunk de um switch ao mesmo tempo. Já o BPDU Guard Guard é uma feature usada para prevenir loops quando outro switch é indevidamente anexado a uma porta configurada com o comando PortFast. Quando a facilidade de BPDU Guard é ativada na interface, a interface é colocada em errordisabled state (shutdwon) state (shutdwon) se um quadro de BPDU do protocolo STP é recebido na interface. Esse comando pode ser habilitado na interface ou globalmente, afetando todas as interfaces Portfast. Abaixo segue como configurar o BPDU Guard na interface: Switch(config-if)# interface fast 0/10 Switch(config-if)# spanning-tree bpduguard enable

Assim como no caso do portfast, o BPDU Guard pode ser configurado globalmente em todas as portas não trunk, veja comando a seguir. Switch(config)# spanning-tree portfast bpduguard default

Para verificar a configuração do BPDU Guard utilize o comando “ show spanning-tree summary totals”, totals ”, conforme mostrado a seguir. Switch#show spanning-tree summary totals Switch is in pvst mode Root bridge for: VLAN0001, VLAN0010 EtherChannel misconfig guard is enabled Extended system ID is enabled Portfast Default is disabled PortFast BPDU Guard Default is disabled Portfast BPDU Filter Default is disabled Loopguard Default is disabled UplinkFast is disabled BackboneFast is disabled Pathcost method used is short Name Blocking Listening Lis tening Learning Learni ng Forwarding STP Active ---------------------- -------- --------- -------- ---------- ---------2 vlans 0 0 0 3 3

Agora vamos aplicar o BPDU Guard por default e verificar a mudança de status no comando show. Switch(config)#spanning-tree portfast bpduguard default Switch(config)#do show spanning-tree summary totals Switch is in pvst mode Root bridge for: VLAN0001, VLAN0010 EtherChannel misconfig guard is enabled Extended system ID is enabled Portfast Default is disabled PortFast BPDU Guard Default is enabled Portfast BPDU Filter Default is disabled


   

 

 



   

    

   



Página 223

 

 

  


Loopguard Default UplinkFast BackboneFast Pathcost method used

is is is is

disabled disabled disabled short

Name Blocking Listening Lis tening Learning Learni ng Forwarding STP Active ---------------------- -------- --------- -------- ---------- ---------2 vlans 0 0 0 3 3 Switch(config)#

3.3 Configurando o Root Guard O Root Guard é utilizado para proteger o brigde raiz ou root bridge do spanning-tree, ele ajuda a combater o problema quando o novo switch adicionado à rede tenta se tornar o switch raiz. O recurso Root Guard permite que outro switch seja conectado à interface e participe do STP enviando e recebendo BPDUs, porém quando a interface do switch, que possui o Root Guard ativado, recebe um BPDU superior ao switch raiz original (um BPDU que tenha um bridge ID menor/melhor), o switch com o Root Guard reage ignorando o BPDU superior e desativando a interface. A interface suspeita não envia ou recebe quadro enquanto os BPDUs superiores continuarem chegando. Se os BPDUs superiores pararem de chegar, o switch pode começar a utilizar a interface novamente. Switch>enable Switch# conf tEnter configuration commands, one per line. End with CNTL/Z. Switch(config)# int f0/10 Switch(config-if)# spanning-tree guard root Switch(config-if)# end Switch#

Para verificar o status do root guard utilize o comando “ show spanning-tree inconsistentports”, inconsistentports”, conforme saída a seguir. Switch#show spanning-tree inconsistentports Name Interface ---------------------------------- --------- --------------------------------- ----- VLAN001 FastEthernet3/1 FastEthernet 3/1 Port VLAN001 FastEthernet3/2 FastEthernet 3/2 Port VLAN002 FastEthernet3/1 FastEthernet 3/1 Port VLAN002 FastEthernet3/2 FastEthernet 3/2 Port VLAN003 FastEthernet3/1 FastEthernet 3/1 Port VLAN003 FastEthernet3/2 FastEthernet 3/2 Port VLAN004 FastEthernet3/1 FastEthernet 3/1 Port VLAN004 FastEthernet3/2 FastEthernet 3/2 Port VLAN005 FastEthernet3/1 FastEthernet 3/1 Port VLAN005 FastEthernet3/2 FastEthernet 3/2 Port Number of inconsistent inc onsistent ports por ts (segments)

Inconsistency Inconsistenc y ------------------------------- -----Type Inconsistent In consistent Type Inconsistent In consistent Type Inconsistent In consistent Type Inconsistent In consistent Type Inconsistent In consistent Type Inconsistent In consistent Type Inconsistent In consistent Type Inconsistent In consistent Type Inconsistent In consistent Type Inconsistent In consistent

in the system: system : 10


   

 

 



   

    

   



Página 224

 

 

  


3.4 Segurança nos Trunks Os trunks 802.1Q nos switches da Cisco vem por padrão com o protocolo DTP habilitado, a recomendação é que ele seja desabilitado e o trunk configurado manualmente. No exemplo a seguir vamos configurar a porta fast 0/24 como trunk, desabilitar o DTP (comando “switchport “switchport nonegotiate”) nonegotiate”) e alterar a VLAN nativa para a 99. Após vamos verificar a configuração da interface com um show running apenas dela. Switch#conf Switch#conf t Enter configuration configuration commands, one per line. End with CNTL/Z. Switch(config)#vlan 99 Switch(config-vlan)#name Gerenciamento Switch(config-vlan)#int vlan 1 Switch(config-if)#no ip add Switch(config-if)#shut Switch(config-if)#int vlan 99 Switch(config-if)#ip add 10.0.0.10 255.255.255.0 Switch(config-if)#no shut Switch(config-if)# Switch(config-if)#int f0/24 Switch(config-if)#switchport mode trunk Switch(config-if)#switchport nonegotiate Switch(config-if)#switchport trunk native vlan 99 Switch(config-if)#do sho run int f0/24 Building configuration... Current configuration : 114 bytes ! interface FastEthernet0/24 switchport trunk native vlan 99 switchport mode trunk switchport nonegotiate end Switch(config-if)#

Note que a VLAN 1 que é a padrão de gerenciamento não pode ser apagada, portanto apenas tiramos o endereço IP da interface VLAN 1 (SVI – Switched Virtual Interface) e desativamos (shut). Além disso, criamos a VLAN 99 e inserimos o IP de gerenciamento nela. Esse mesmo procedimento deve ser executado em todos os switches da rede, assim como a inserção do comando switchport trunk native vlan 99 em 99 em todos os trunks da rede. 3.5 Configurando o DHCP Snooping Para evitar ataques via serviço de DHCP os switches utilizam uma filosofia de configuração relativamente simples, pois sabemos que porta o servidor DHCP está conectado ou que o switch recebe as respostas do servidor DHCP legítimo, l egítimo, portanto vamos definir portas que são confiáveis (trusted) e outras não confiáveis (untrusted) para receber essas respostas do serviço de DHCP. Portanto, os servidores DHCP ficam nas portas trusted e trusted e o restante das portas devem ser configuradas como untrusted. Quando switch interceptar requisições DHCP nas portas untrusted antes de encaminhá-las, caso ele receba um DHCP Reply de uma porta não confiável, esse pacote será descartado.


   

 

 



   

    

   



Página 225

 

 

  


O DHCP snooping mantém uma base de dados dad os com endereço IP, endereço MAC, lease l ease time e outros parâmetros que podem ser utilizados uti lizados em outros recursos como o DAI ( DAI (Dynamic Dynamic ARP Inspection) Inspection) e o IP Source Guard. Guard. Para habilitar o DHCP Snooping siga os passos abaixo. 1. Digite o seguinte comando no modo de configuração global: Switch(config)#ip dhcp snooping

2. Identifique as VLANs que serão protegidas: Switch(config)#ip dhcp snooping vlan 100

3. Todas as portas do switch ficam no modo untrusted por untrusted por padrão quando habilitamos o DHCP snooping, por isso precisamos configurar as portas onde estão e stão os servidores DHCP da rede como trusted. trusted. Veja no exemplo abaixo onde o servidor DHCP está conectado à porta fast 0/1. Switch(config)#interface FastEthernet 0/1 Switch(config-if)#ip dhcp snooping trust

3. Podemos também configurar um limite de requisições DHCP que passam passam em uma interface, o rate pode ser um valor de 1 a 2048 pacotes por segundo: Switch(config)#interface FastEthernet 0/1 Switch(config-if)#ip dhcp snooping limit rate 10

Quando uma requisição DHCP é interceptada em uma porta untrusted, o switch adiciona seu próprio MAC e um identificador da porta de origem no campo option-82, em seguida encaminha para o servidor DHCP. Quando retorna o pacote reply o switch compara o campo option-82 para confirmar que a requisição foi originada de uma porta válida. Você pode fazer se a opção utilizada pelo servidor é realmente válida opcionalmente com o comando abaixo. Switch(config)#ip dhcp snooping information option

Para verificar as configurações podemos utilizar os comandos “show “ show ip dhcp snooping” snooping” e “show “show ip dhcp snooping binding”. binding”.


   

 

 



   

    

   



Página 226

 

 

  


3.6 Configurando o Storm Control A configuração do storm control é control é bastante simples, precisando definir o nível ní vel de uso pelo broadcast ou multicast que será considerando como limiar de corte e a ação que a interface deve tomar, as quais podem ser shutdown (desligar (d esligar a interface) ou trap (informar a gerência). Vamos ao passo a passo a seguir. 1) Entre em modo de config global. 2) Entre nas interfaces de 5 a 10 simultaneamente e defina o limiar do storm control para 70% tanto para broadcast como para multicast e unicast (comando storm-control broadcast level). Switch(config)#int range fast 0/5 - 10 Switch(config-if-range)#storm-control ? action Action to take for storm-control storm-control broadcast Broadcast address ad dress storm control c ontrol multicast Multicast address ad dress storm control c ontrol unicast Unicast address storm control Switch(config-if-range)#storm-control broadcast ? level Set storm suppression level on this interface Switch(config-if-range)#storm-control broadcast level ? pps Enter suppression suppres sion level in packets per second <0 - 100> Enter Integer Intege r part of level lev el as percentage percent age of bandwidth bandwid th Switch(config-if-range)#storm-control broadcast level 70 Switch(config-if-range)#storm-control multicast level 70 Switch(config-if-range)#storm-control unicast level 70

Note que no comando acima você poderia definir pela porcentagem de uso da Interface ou pelo PPS ou pacotes por segundo. Quando utilizado o PPS você deve definir um parâmetro de máximo e quanto o tráfego deve cair para ser encaminhado novamente, por exemplo, “storm“storm control broadcast level pps 2k 1k”, se o nível de broadcast chegar a 2000 pps ele será bloqueado até que caia a 1000 pps. Se você não definir nada ele deve cair a 2000 pps para voltar a ser encaminhado. 3) Defina a ação que o switch irá tomar caso o limiar definido no item anterior seja excedido. Switch(config-if-range)#storm-control action shutdown Switch(config-if-range)#end Switch#

4) Verifique o estado do storm control com o comando “show stormstorm -control”. Switch#show storm-control Interface Filter State --------- ------------Fa0/1 inactive Fa0/2 inactive Fa0/3 inactive Fa0/4 inactive Fa0/5 Forwarding Fa0/6 Forwarding Fa0/7 Forwarding Fa0/8 Forwarding Fa0/9 Forwarding

Trap State ------------inactive inactive inactive inactive inactive inactive inactive inactive inactive

Upper ------100.00% 100.00% 100.00% 100.00% 70.00% 70.00% 70.00% 70.00% 70.00%

Lower ------100.00% 100.00% 100.00% 100.00% 70.00% 70.00% 70.00% 70.00% 70.00%

Current ------N/A N/A N/A N/A 0.00% 0.00% 0.00% 0.00% 0.00%

Traps Sent ---------0 0 0 0 0 0 0 0 0


   

 

 



   

    

   



Página 227

 

 

  


Fa0/10 Forwarding Fa0/11 inactive Fa0/12 inactive ... Saída omitida...

inactive inactive inactive

70.00% 100.00% 100.00%

70.00% 100.00% 100.00%

0.00% N/A N/A

0 0 0

A ativação do storm control é feita por interface, porém com o comando range você pode ativar em várias interfaces simultaneamente. No exemplo vamos configurar as interfaces de 5 a 10 com limiar de corte para o switch em 70% da utilização da interface para quadros quadr os de Broadcast, Multicast ou Unicast e caso o limiar seja excedido a interface i nterface será desligada. Vamos a mais um exemplo de configuração com opções diferentes. Neste exemplo, foram configurados três níveis distintos de supressão de tempestade, usando três diferentes di ferentes tipos de medições. No primeiro foi definido o nível de controle unicast tempestade a 80,5%. No segundo, o nível de controle de tempestade multicast foi definido para 3000 bits por segundo, com um nível de supressão de queda de 1.000 bits por segundo. Switch1(config)# interface gigabitethernet 0/4 Switch1(config-if)# storm-control unicast level 80.5 Switch1(config-if)# storm-control multicast level bps 3k 1k Switch1(config-if)# storm-control broadcast level pps 100k Switch1(config-if)# storm-control action shutdown

Isso significa que o tráfego deve cair abaixo de 1.000 bits por segundo para ser encaminhado novamente. Se você não definir um nível de supressão de queda, o nível de supressão de queda é definido como 3000 bits por segundo. E por último o nível de broadcast foi criado usando 100.000 pacotes por segundo. 3.7 Protocolo 802.1x e Cisco IBNS Este protocolo foi proposto tendo como foco as redes com fio e os riscos associados à possibilidade de uma estação não autorizada ser conectada a um switch e a partir deste momento ter acesso aos recursos de rede red e da mesma forma que uma estação autorizada. Na verdade, não há uma definição formal presente no padrão pad rão 802.3 com relação a uma estação autorizada e não autorizada, dado que neste protocolo não há processos definidos de autenticação e associação. Isto também se aplica para o 802.11 no modo Open System, ou seja, quando o protocolo WEP não está habilitado. habili tado. Define-se estação não autorizada qualquer estação para a qual não há uma política implícita ou explícita que autorize sua conexão. Por exemplo, para o caso de empresas que não autorizam a conexão de notebooks de terceiros em suas redes, considera-se o notebook uma estação não autorizada. O 802.1X (802.1X, 2001) encontra vasta aplicação nas redes sem fio, pois a associação de estações não autorizadas fica potencializada. Na figura a seguir estão representadas as 3 entidades do 802.1x: 





O suplicante: suplicante: que representa a entidade que deseja se autenticar na rede e ter o acesso autorizado para uso dos recursos oferecidos através do sistema autenticador; O sistema autenticador: autenticador : que verifica o status do suplicante e quando adequado encaminha a requisição de autenticação para o servidor de autenticação verificar a validade das credenciais; O sistema de autenticação: autenticação : que é uma base de dados com as credenciais dos usuários e que contém os logs de utilização dos recursos da rede para fins de cobrança (billing), por exemplo.


   

 

 



   

    

   



Página 228

 

 

  


Um exemplo de uso pode ser visto em redes locais, onde um desktop está conectado a um switch e existe um servidor RADIUS presente na rede. O desktop representa o suplicante, o switch o sistema autenticador e o RADIUS o sistema de autenticação. Em um primeiro momento o switch somente habilita a porta conectada ao desktop para operações de autenticação do protocolo 802.1X e que se destinem ao sistema de autenticação. Com a autenticação efetivada o acesso aos demais recursos de rede é autorizado. Em redes 802.11 o processo é semelhante, mas consideram-se as portas p ortas como associações lógicas. No 802.11 o suplicante corresponde às estações sem fio, o autenticador aos pontos de acesso e servidor de autenticação a um servidor AAA (Authentication, Authorization and Accounting) como RADIUS ou TACACS+. O 802.1X é um padrão para controle de acesso e autenticação e pode utilizar diversos protocolos como o EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) e o EAP-MD5 (Extensible Authentication Protocol - Message Digest 5), sendo o primeiro mais utilizado atualmente. O EAP-TLS é baseado no encapsulamento do EAP em conexões ponto a ponto do protocolo TLS. O TLS é baseado em protocolos de chaves públicas, onde ambas as entidades possuem certificados digitais assinados por uma terceira entidade em que confiam. Portanto, com todos os ataques mencionados até agora, se atacante ganhou o acesso à rede e o switch aceita quadros do atacante a rede está comprometida. Sua primeira linha de defesa deve restringir o acesso às interfaces do switch autenticando o computador ou usuário. Genericamente, este é referido como Identity-Based Networking Services (IBNS ou liberação de serviços de rede baseados em identidade). Com IBNS, um computador deve primeiro ser autenticado antes do acesso ser ser permitido através da interface do switch. switch. A Cisco suporta muitas soluções IBNS através de seus diversos produtos, porém o exame CCNA Security só aborda o 802.1x, e muito brevemente. Outras opções são discutidas no currículo da Cisco CCSP.


   

 

 



   

    

   



Página 229

 

 

  


O padrão 802.1x usa o Extensible Authentication Protocol (EAP), definido pelo IETF RFC 2284, para implementar a autenticação e distribuição de chaves dinâmicas (este último só é necessário para a autenticação de dispositivos sem fio que precisam de uma chave WEP para a criptografia). O EAP é uma extensão do PPP e carrega as informações de autenticação do usuário. O EAP em conjunto com 802.1x foi originalmente projetado para redes sem fio, no entanto, uma extensão da EAP chamada “EAP over LAN (EAPoL)”, permite que ele funcione em redes baseadas em LAN, com switches Ethernet, sendo utilizado para trocar as mensagens entre o suplicante e o autenticador. Veja a seguir.

3.8 Espelhamento de Portas - SPAN e RSPAN O SPAN – Switched Port Analyzer Analyzer - também conhecido como Port Mirroring ou Port Monitoring é a capacidade de espelhar o tráfego de uma porta (ou portas, ou VLAN) para outra. Apesar de não fazer parte dos objetivos da prova nova do CCNA Security 640-554 mantivemos o conteúdo porque para um analista de segurança ou administrador de redes no dia a dia é muito importante saber como monitorar o tráfego em um switch ou porta do switch. Não confunda o SPAM SPAM de e-mails com o port SPAN SPAN ou espelhamento de portas, pois são conceitos totalmente diferentes! Cuidado ao utilizar o SPAN e o RSPAN, pois se o tráfego a ser monitorado for muito alto você pode causar o aumento do uso do processamento e/ou memória do ou dos switches participantes dessa monitoração, podendo até gerar indisponibilidade na rede. Entre outras aplicações, esta funcionalidade é muito utilizada em conjunto com equipamentos de análise de rede, que deve receber o tráfego espelhado. Veja a figura a seguir, onde vamos monitorar o tráfego das portas onde os computadores A e B estão conectados utilizando um sniffer.


   

 

 



   

    

   



Página 230

 

 

  


Vamos analisar os comandos na prática com duas situações, no primeiro exemplo vamos monitorar uma porta e na segunda todo o tráfego de uma VLAN. O tráfego gerado na porta fast 0/24 será espelhado na porta 0/1, onde pode ser conectado um analisador de protocolos ou um IDS, por exemplo, para verificar questões de segurança ou troubleshooting. S1(config)#monitor session 1 source interface fast 0/24 S1(config)#monitor session 1 destination interface fast 0/1 encapsulation replicate

No segundo exemplo vamos monitorar todo o tráfego da VLAN 10 através da porta 0/24. A opção both indica que será monitorado transmissão (tx) e recepção (rx), você poderia especificar uma direção específica para monitorar. S1(config)# monitor session 2 source vlan 10 both S1(config)# monitor session 2 destination interface FastEthernet 0/24

Note que em ambos os casos o comando source define a origem, o que será monitorado, e o destination define a porta que será utilizada para realizar a monitoração ou espelhamento. Com o comando “show monitor session numero” você pode verificar o status da monitoração. Um exemplo prático de uso do SPAN é na colocação de um IDS (Intrusion Detection System) na rede para mitigar riscos de segurança vindos de uma rede externa, onde o tráfego a ser analisado deve ser espelhado para a porta onde o IDS será conectado. Veja a figura a seguir.


   

 

 



   

    

   



Página 231

 

 

  


3.8.1 RSPAN ou SPAN Remoto

O RSPAN ou SPAN Remoto tem todas as características do SPAN, porém permite a monitoração de portas de origem e destino distribuídas através de vários switches, permitindo a monitoração de qualquer porta de destino localizada na VLAN de RSPAN. Na prática permite ao administrador monitorar o tráfego em um switch usando uma porta de destino localizada em outro switch. Veja os exemplos das figuras a seguir.


   

 

 



   

    

   



Página 232

 

 

  


Na figura acima temos o mesmo exemplo visto no SPAN anteriormente, porém com o IDS localizado em um ponto único da rede e analisando o tráfego remoto que pode vir de outros switches dentro da VLAN definida para RSPAN. Para configurar o RSPAN todos os switches que participarão deverão ter a mesma VLAN de monitoração configurada e devem suportar o RSPAN. Acompanhe o exemplo de configuração a seguir de acordo com a topologia.

Switch1(config)# vlan 250 Switch1(config-vlan)# remote-span Switch1(config-vlan)# exit

O mesmo deve ser realizado no ou nos switches remotos e essa VLAN terá que atravessar a rede. Depois de criada e definida a VLAN de monitoração, defina o tráfego a ser monitorado no switch remoto. Switch1(config)# monitor session 1 source interface fastethernet0/1 both Switch1(config)# monitor session 1 destination remote vlan 250

Agora no switch de monitoração defina a porta que será utilizada o IDS, Sniffer ou qualquer outro aparelho de monitoração, mas lembre de criar a VLAN de monitoração antes de definir a monitoração remota. Switch2(config)# vlan 250 Switch2(config-vlan)# remote-span Switch2(config-vlan)# exit Switch2(config)#monitor session 1 source remote vlan 250 Switch2(config)#monitor session 1 destination interface fastethernet0/7


   

 

 



   

    

   



Página 233

 

 

  


Lembre-se de que a VLAN que foi utilizada para o espelhamento remote deve passar do switch de origem até o de destino, verifique se a VLAN não está sendo bloqueada manualmente ou via VTP Prunning com o comando “show interfaces trunk”. Para verificar a monitoração utilize o comando “show monitor”, o mesmo utilizado para o SPAN. 4

Resumo do Capítulo

Bem pessoal, chegamos ao final do capítulo. É muito importante que nesse ponto do curso você tenha domínio dos seguintes itens: Ameaças e ataques possíveis na camada de enlace. Opções de mitigação na camada de enlace. Descrever como prevenir ataques de camada 2. Configurar recursos de segurança em switches Cisco Catalyst.    


   

 

 



   

    

   



Página 234

 

 

  


Capítulo 8 - IPS - Intrusion Prevention System Nesse capítulo iremos tratar dos sistemas de prevenção a intrusão ou intrusos, assim como a implementação de um IPS utilizando CLI e CCP em roteadores Cisco.

Objetivos do Capítulo Ao final desse capítulo você terá estudado e deverá compreender: Definição de detecção e prevenção de intrusão de rede versus de um host. Explicar as tecnologias de IDS e IPS Respostas aos ataques e opções de monitoramento. Implementação de IPS via CLI e CCP. Principais opções de dispositivos IPS e IDS Cisco. 











   

 

 



   

    

   



Página 235

 

 

  



Introdução _____________________ 237

3.4

Reputation-Based IPS/IDS ________ 251

3.5

Abordagem de Honeypot ________ 251

4

Implementando Cisco IOS IPS via CLI 252

4.1

2 Características Gerais dos Sistemas IDS e IPS 238

Passo 01: Download dos arquivos do IPS 254

4.2 Passo 02: Criando diretório de configuração na flash para o IOS IPS _____ 255

2.1

IPS – Intrusion Prevention System __ 239

2.2

Assinaturas de Ataques - Signatures 240

2.3

Verdadeiro/Falso Positivo/Negativo 241

4.3 Passo 03: Configure a chave criptográfica (crypto key) para o IOS IPS __ 255

2.4

Ações do IPS Frente a uma Ameaça _ 242

4.4

Passo 04: Habilitando o IPS via CLI _ 256

4.5 Passo 05: Carregando o pacote de assinaturas do IOS IPS no roteador ______ 258

2.5 Controlando e Configurando Ações dos Sensores____________________________ 243 2.6

Monitoração e Alertas do IDS/IPS __ 244

5

2.7

IPv6 e IPS______________________ 245

2.8

É possível Enganar um IPS/IDS? ____ 245

6 Modificando as Assinaturas Via CLI e CCP - Tunning _________________________ 267

2.9

Comparação entre IPS e IDS _______ 246

2.10

Opções da Cisco para IPS e IDS___ 247

3 Tipos de Abordagens para Identificação de Invasões ________________________ 249

3.1 Abordagem por Assinaturas (Signature based approach) _____________________ 249 3.2 Abordagem por Políticas (Policy based approach)___________________________ 250 3.3 Anomaly - Based Approach ou Abordagem por Detecção de Anomalias __ 250

Implementando Cisco IOS IPS via CCP 261

6.1 Modificando as Assinaturas Via CCP Tunning ____________________________ 268 7 Best Practices no Ajuste Fino de IPSs para Iniciantes _____________________ 270 8 Gerenciando e Monitorando Alertas de Segurança do IPS ___________________ 271 9 10

Conclusão: “O que o IOS IPS pode fazer?” 273

Resumo do Capítulo ___________ 273


   

 

 



   

    

   



Página 236

 

 

  


1 Introdução Note que até o momento tratamos de ameaças que são detectadas e tratadas nas camadas 2, 3 e 4 da camada OSI. Mas e se um tráfego que afeta a camada de aplicação passar pelas defesas de um firewall, por exemplo, o que acontecerá? Uma vez invadido um host interno ou sistema o firewall ou demais defesas estudadas anteriormente não farão nenhuma diferença. O IPS e IDS vieram para tratar desse problema: “E se a ameaça estiver escondida em um fluxo, tráfego ou pacote mas nas camadas superiores?” Em linhas gerais a função do IPS (Intrusion Prevention System) é ser um dispositivo de segurança de rede que monitora o tráfego e/ou atividades dos sistemas em busca de comportamentos maliciosos ou não desejáveis em tempo real, com a finalidade de bloquear ou prevenir essas atividades. Um IPS baseado em rede, por exemplo, vai operar em linha para monitorar todo o tráfego em busca de códigos maliciosos ou ataques. Quando um ataque é detectado, é possível bloquear os pacotes danosos enquanto o tráfego normal continua seu caminho. Outra ferramenta utilizada para evitar ataques ou invasões é o Sistema de Detecção de Intrusos ou simplesmente IDS (Intrusion Detection System), o qual pode ser um software ou dispositivo que utiliza meios técnicos de descobrir quando uma rede está sofrendo acessos não autorizados que podem indicar a ação de um cracker ou até mesmo funcionários mal intencionados. Assim como o IPS, o IDS pode ser baseado em rede ou diretamente no host. Veja a figura a seguir.

No começo o IPS era apenas um IDS que possibilitava alguma interação com o firewall para controlar o acesso. Em pouco tempo foi necessário desenvolver algo mais robusto, uma vez que, apenas comandar o firewall ainda deixava que ao menos aquele pacote malicioso trafegasse na rede, a solução era implementar formas inteligentes de bloqueio dentro do IPS. Visto como uma extensão do firewall, o IPS possibilita decisões de acesso baseadas no conteúdo da aplicação, e não apenas no endereço IP ou em portas como os firewalls A p o s t i l a / E - Bo o k d o C u r s o I I N S 6 4 0 - 5 5 4      

   

 

 



   

    

   



Página 237

 

 

  


tradicionais trabalham. Entretanto, nada impede que para otimizar a performance muitos IPS utilizem regras baseadas em portas e endereço IP. O IPS também pode servir secundariamente como um serviço instalado no próprio host, prevenindo atividades potencialmente maliciosas. Existem vantagens e desvantagens entre o IPS baseado em host e o IPS baseado em rede. Em alguns casos, as tecnologias podem ser complementares. Porém, não se pode esquecer que muita da tecnologia de IPS de rede evoluiu e hoje pode tranquilamente exercer também as funções de host. A qualidade de um sistema de prevenção de intrusos está em ser um excelente detector de tráfego malicioso com uma média de falso positivo e falso negativo baixo. Nos próximos slides vamos estudar com mais detalhes o IPS e sua implementação em roteadores Cisco utilizando CLI e CCP, principal fico da prova. 2 Características Gerais dos Sistemas IDS e IPS Vamos iniciar estudando o IDS. Ele é uma ferramenta utilizada para monitorar o tráfego da rede, detectar e alertar sobre ataques e tentativas de acessos indevidos. Na grande maioria das vezes não bloqueia uma ação, mas verifica se esta ação é ou não uma ameaça para um segmento de rede, informando a um sistema de gerenciamento de falhas. A vantagem de se utilizar um IDS é que ele não interfere no fluxo de tráfego da rede, pois ele trabalha em paralelo à rede, apenas monitorando o fluxo de dados, analisando e reportando possíveis ataques ou riscos à segurança. Um IDS é geralmente instalado em um modo que chamamos de “Promiscous-mode” ou simplesmente “Modo Promíscuo”, veja a figura a seguir.

Podemos verificar na figura que o equipamento identificado como “Sensor” está conectado a uma porta do Switch de camada 2 e todo o trafego que está passando por este switch está sendo analisado, consequentemente caso seja identificado algum tráfego malicioso, que vá de encontro a base de dados de assinaturas do software IDS um alerta imediato será enviado ao sistema de gerenciamento (System Management). Este alerta pode ser, por exemplo, via email ao administrador de segurança. A p o s t i l a / E - Bo o k d o C u r s o I I N S 6 4 0 - 5 5 4      

   

 

 



   

    

   



Página 238

 

 

  


Sua maior desvantagem é não conseguir agir sozinho sobre o problema, dependendo de outros elementos de segurança para poder eliminar o possível ataque. Resumindo, em sua operação ele deve receber uma cópia de todos os pacotes enviados na rede, comparar com sua base de assinaturas de ataques (signature database) e caso seja detectado algum ataque ele informa a uma console de gerenciamento ou envia um log para o syslog, por exemplo. Seu uso é mais de monitorar os possíveis riscos de invasão e verificar se o sistema de firewall e IPS estão realmente sendo efetivo e não deixando passar ameaças. 2.1 IPS – Intrusion Prevention System O IPS surgiu como um complemento do IDS, pois ele tem a capacidade de identificar uma invasão, analisar a relevância do evento/risco e bloquear determinados eventos, fortalecendo assim a tradicional técnica de detecção de intrusos. Resumindo, o IDS apenas monitora e o IDS monitora e pode também agir sobre a ameaça. O IPS é uma ferramenta com inteligência na maneira de trabalhar, pois reúne componentes que fazem com que ele se torne um repositório de logs e técnicas avançadas de alertas e respostas, voltadas exclusivamente para tornar o ambiente computacional cada vez mais seguro sem perder o grau de disponibilidade que uma rede deve ter. O IPS usa a capacidade de detecção do IDS junto com a capacidade de bloqueio de um firewall, notificando e bloqueando de forma eficaz qualquer tipo de ação suspeita ou indevida e é uma das ferramentas de segurança de maior abrangência, uma vez que seu poder é de alertar e bloquear, agindo em diversos pontos de uma arquitetura de rede. Um IPS é instalado em modo In-Line como mostrado no desenho ao lado, ou seja, em série com o fluxo de dados, dessa forma o equipamento consegue enxergar todo o tráfego em ambos os sentidos (In and out).


   

 

 



   

    

   



Página 239

 

 

  


O IPS monitora as camadas 3 e 4 do tráfego, além disso analisa também o conteúdo do payload das camadas superiores, podendo agir contra ataques mais sofisticados que podem incluir dados prejudiciais (maliciosos) nas camadas de 2 a 7 do modelo OSI. As plataformas de IPS da Cisco podem utilizar uma mistura de tecnologias de análise e detecção de intrusos incluindo as baseadas em assinatura, baseado no perfil e por detecção de protocolo. Esta análise mais profunda permite ao IPS identificar, parar e bloquear os ataques que normalmente passam por um firewall tradicional. Quando um pacote chega através de uma interface em um IPS, esse pacote não é enviado para a interface de saída até que o pacote seja analisado. Aqui está a maior desvantagem do IPS, que se mal configurado ou mal dimensionado pode representar um gargalo na rede, pois todo o tráfego passará por ele. 2.2 Assinaturas de Ataques - Signatures As tecnologias IDS e IPS utilizam assinaturas para detectar desvios de padrões de tráfego na rede. Uma assinatura é um conjunto de regras que um IDS ou IPS utiliza para detectar uma atividade intrusiva. As assinaturas podem ser utilizadas para detectar falhas graves de segurança, ataques comuns à rede e coleta de informações, podendo detectar padrões de assinatura atômica ou atomic patterns (pacote único) ou padrões de assinatura composta ou composite patterns (multipacket). Utilizar uma destas tecnologias não significa que um administrador não deve usar a outra, na verdade, as tecnologias de IDS e IPS são complementares. Por exemplo, o IDS pode ser implementado para validar a operação IPS, sendo configurado para uma inspeção de pacotes mais profunda quando estiver offline. Isso permite focar o IPS em analisar menos padrões de tráfego, ou seja, somente o que seja mais importante ou crítico para a política de segurança da empresa. Veja na figura a seguir um exemplo de aplicação prática, onde um IPS faz a filtragem do tráfego na entrada da rede, antes do firewall e dois IDS’s validam a operação dele dentro da rede Interna e na DMZ.


   

 

 



   

    

   



Página 240

 

 

  


Para facilitar o processo de análise os sensores da Cisco utilizam uma microengine ou signature microengine (SME), que em português poderia ser traduzido como um micromotor ou micro-sistema, que é uma espécie de pré-processador que controla grupos de assinaturas específicas. Um sensor tem vários SME’s e cada uma é responsável por um grupo de assinaturas, as quais são agrupadas por protocolo ou outras características semelhantes, facilitando o processo de comparação que seria muito mais complexo se fossem realizado um a um. No Cisco IOS você tem 5 micro-engines:  



 

Atomic – examina pacotes simples como o ICMP e UDP. Service – examina diversos serviços de rede na camada de aplicação, não importando o sistema operacional. String – examina “regular expression-based patterns” para detectar intrusões ou invasões. Multi-string – suporta “flexible pattern matching” e “Trend Labs signatures”. Other – engine interno que trata outros tipos de assinaturas gerais.

As SMEs string e multi-string muitas vezes são tratadas em apenas um grupo que suportam a verificação flexível de padrões, podendo identificar pacotes únicos ou um grupo de pacotes, por exemplo, uma sessão TCP. Uma das propriedades das assinaturas é a severidade (severity – chamado de “attack severity rating” - ASR). O valor varia de 0 a 100 e indica quanto o ataque é letal para a rede com base nas configurações do administrador de segurança. Esse parâmetro faz parte dos três fatores de cálculo do risco de um ataque que estudaremos posteriormente. Na prática, ao invés do sensor mostrar um número ele mostrará a severidade como informational, low, medium ou high, onde high é a severidade mais alta e low a mais baixa. A severidade informational é uma assinatura informacional, não representa um risco real ao sistema. As assinaturas já possuem um padrão configurado que pode ser alterado via configuração. No próximo tópico vamos estudar como um IPS pode agir frente a uma ameaça detectada através de uma assinatura. 2.3 Verdadeiro/Falso Positivo/Negativo Portanto, os IPSs e IDSs farão a análise do tráfego da rede e comparando com as assinaturas e regras criadas e serão gerados avisos (alarmes e registros) sobre tráfegos e pacotes suspeitos. É claro que os administradores de redes e de segurança esperam que esses avisos gerados pelos IPSs e IDSs sejam confiáveis. Porém, quando trabalhamos com sistemas IPS/IDS você pode se deparar com os seguintes termos: 







Falso positivo (false positive) ocorre quando a ferramenta classifica uma ação como uma possível intrusão, quando na verdade trata-se de uma ação legítima. Falso negativo (false negative) ocorre quando uma intrusão real acontece, mas a ferramenta permite que ela passe como se fosse uma ação legítima. Verdadeiro positivo (true positive) e verdadeiro negativo (true negative) são as situações opostas às descritas acima e o esperado que um IDS detecte o que realmente está acontecendo. Subversão ocorre quando o intruso modifica a operação da ferramenta de IDS para forçar a ocorrência de falso negativo.


   

 

 



   

    

   



Página 241

 

 

  


Opa! Espera um pouco, quer dizer que algo que meu IPS ou IDS reportou não é 100% verdade? Um alarme de uma possível invasão pode ser falso? Ou então algo que deixei passar como tráfego confiável pode ser um ataque/invasão? A resposta é sim! Essa é uma parte da “emoção” da tarefa de um administrador de segurança! O falso positivo acontece quando o sensor gera um alerta sobre um tráfego que na realidade não é um ataque ou algo malicioso ou importante em termos de segurança. Esse tipo de problema é simples de ser identificado e tratado porque os alertas gerados são sobre tráfegos comuns. Normalmente você precisará ajustar seu sensor para que o tráfego não gere mais alerta e seja permitido. Já os falsos negativos são os mais perigosos para os administradores de segurança, pois se trata de um tráfego perigoso, um ataque ou tentativa de invasão e por algum motivo o IPS/IDS não gera nenhum alarme e o trata como um fluxo confiável ou normal. Nesse caso é recomendado ter outros sistemas auxiliares de alerta de terceiros ou externos que avisem sobre o problema, por exemplo, mensagens de syslog de um equipamento de rede. Os verdadeiros positivos e verdadeiros negativos são o que esperamos que aconteça em maioria das vezes, pois um verdadeiro positivo significa que o sensor alertou sobre uma ameaça real e caso o sensor seja um IPS ele pode até já bloquear esse ataque. O verdadeiro negativo significa que um tráfego normal, sem nenhum risco ao ambiente foi detectado e permitido pelo sensor, ou seja, nenhum alerta é gerado nesse caso e no caso de IPS o tráfego é permitido para dentro da rede. 2.4 Ações do IPS Frente a uma Ameaça O IPS pode ser configurado para que uma ação possa ser tomada em resposta às ameaças que ele detecta. Já um IDS apenas fará o alerta através de um alarme ou mensagem ao sistema de gerenciamento de segurança. A seguir estão as ações de resposta que o IPS pode tomar quando os pacotes em uma sessão coincidem com uma assinatura: 













Bloquear o atacante (Deny attacker inline): ação disponível se o sensor está configurado como IPS fazendo o bloqueio dos pacotes IP através do endereço de origem do atacante por um período de tempo configurável, portanto o bloqueio pode ser dinamicamente removido. Bloquear a conexão (Deny connection inline): ação também disponível se o sensor está operando como IPS, sendo que os pacotes que dispararam a ação são bloqueados, assim como os futuros pacotes desse mesmo tipo de conexão TCP. Com essa ação o atacante pode abrir uma nova conexão TCP com portas diferentes e ser permitido entrar na rede pelo IPS. Bloquear o pacote (Deny packet inline): também o sensor deve estar como IPS, pois todas as opções de bloqueio (deny) somente são aplicadas em modo IPS. Bloqueia o tipo de pacote que gerou o alerta em questão. Logar os pacotes do atacante: inicia a gravação dos pacotes e alertas com base no endereço de origem do atacante por um curto período de tempo, normalmente 30 segundos após o alerta inicial. Os registros (log files) são armazenados em um formato que pode ser lido por maioria dos analisadores de protocolos do mercado. Logar os pacotes da vítima: similar ao anterior, porém o registro é feito pelo endereço de destino, ou seja, o IP da vítima do ataque. Logar o par de pacotes (vítma+atacante): nesse tipo de ação os pacotes logados são da vítima e do atacante, iniciando pelo endereço de origem (atacante) e relacionando o IP de destino (vítima). Gerar alerta: um alerta é gerado pelo mecanismo utilizado pelo IDS/IPS para identificar eventos, por exemplo, indicando um match em uma assinatura reconhecida A p o s t i l a / E - Bo o k d o C u r s o I I N S 6 4 0 - 5 5 4

     

   

 

 



   

    

   



Página 242

 

 

  












em um fluxo suspeito. Esse é o comportamento padrão de maioria das assinaturas na prática. Gerar alerta detalhado (verbose alert): similar à ação anterior, porém com o extra de conter o pacote que gerou o alerta, por isso ele é mais detalhado. Bloquear a conexão: alguns sensores podem pedir ajuda a outros dispositivos para bloquear o tráfego relativo a um ataque em determinados pontos da rede. O dispositivo se conecta ao equipamento remoto e aplica uma ACL em um roteador com Cisco IOS, em um switch pode aplicar uma VLAN access control lists (VACL) ou aplicar um bloqueio em um Adaptive Security Appliance (ASA) Firewall. Essa ação faz com que o sensor solicite um dispositivo de bloqueio remoto fazer a filtragem com base no endereço IP de origem do atacante, o endereço IP de destino da vítima e portas envolvidas no pacote que gerou o alerta. Essa opção dá a oportunidade para o atacante enviar o tráfego em portas ou endereços diferentes de destino e ainda permitir conectividade para novas sessões. Bloquear o host: essa ação faz com que o sensor envie solicitações de bloqueio (ver parágrafo anterior) com base no endereço IP de origem do atacante, independentemente das portas em uso ou endereços IP de destino para os pacotes futuros. Gerar SNMP trap: faz com que o sensor gere um trap do Simple Network Management Protocol (SNMP) para o servidor de gerenciamento configurado. Resetar a conexão TCP: com essa ação o sensor envie um sinal de reset da sessão TCP ao atacante. Essa ação afeta apenas tráfegos TCP.

Portanto, além das assinaturas para detectar tráfego malicioso o administrador de segurança precisará configurar ações caso tais fluxos sejam detectados pelos sensores. As ações serão tomadas frente a um verdadeiro positivo ou um falso positivo, portanto não é só implantar um IPS e esquecer, pois temos na operação do dia a dia de segurança a análise dos alertas gerados para verificar se tráfegos legítimos não estão sendo bloqueados e alterar essas ações. Além disso, o mais importante de verificar se falsos negativos não está ameaçando o sistema, hosts, serviços e servidores e fazer os devidos ajustes às regras e assinaturas. 2.5 Controlando e Configurando Ações dos Sensores A administração das diversas mensagens e logs gerados por um sensor anos atrás se tornou um atividade entediante e extenuante para os administradores de segurança, pois o gerenciamento individual das ações que cada assinatura deve tomar tornou-se uma sobrecarga devido ao crescente no número de assinaturas gerada dia a dia. Uma solução que permite o IPS/IDS deve agir frente a uma ameaça é considerar o risco e sua severidade frente a uma ameaça, aí dependendo dessa avaliação o sensor pode tomar uma ação contra a ameaça (countermeasure) dinamicamente. Esse recurso pode ser implementado com um recurso chamado “risk rating” (em português, avaliação/categorização de risco), onde é implementada uma fórmula que seu resultado pode ir de zero a 100. Com base em uma fórmula o IPS pode mudar dinamicamente a ação de uma assinatura. Por exemplo, se uma assinatura esta configurada apenas para gerar um alerta, mas o Risk Rating é alto, o IPS altera a ação da assinatura para que além do alerta o atacante seja bloqueado.


   

 

 



   

    

   



Página 243

 

 

  


Na formula são utilizadas as seguintes variáveis: 









Target Value Rating (TVR): É um valor que você associa a um host ou a uma rede, de acordo com a importância deste host ou desta rede no seu cenário. Os valores disponíveis para o TVR são: Zero (50), Low (75), Médium (100), High (150) e Mission Critical (200). Quanto maior o número mais importante é o host ou a rede. Attack Severity Rating (ASR): É configurado por assinatura e indica o quão perigoso é o evento. As opções que temos são Information (25), Low (50), Médium (75) e High (100). Os números nos parênteses são a representação numérica da severidade e podem ser alterados pelo administrador de segurança. Signature Fidelity Rating (SFR): Também é configurado por assinatura e pode ir de de 0 a 100. O SFR define o quanto uma assinatura é assertiva (confiável - gera pouco falso-positivo). Attack Relevancy (AR ou Attack Relevancy Rating - ARR): É um valor definido pelo IPS com base na informação de Sistema Operacional e não configurável. Ele mostra a importância do ataque no ambiente. Por exemplo, um ataque para Windows em um ambiente Linux não tem muita importância, mas o mesmo ataque em um ambiente Windows terá muita importância. Possíveis valores: Relevant (10), Unknown (0) e Not Relevant (-10). Global correlation: Se o sensor está participando de correlação global e recebe informações sobre endereços de origem específicos que estão sendo usados para implementar ataques em larga escala, ataques vindo dos endereços IP nessa lista terão o valor de classificação de risco maior.

Os três primeiros parâmetros são os mais importantes para o valor final do risk rating. 2.6 Monitoração e Alertas do IDS/IPS Um sensor IPS pode reagir em tempo real quando uma assinatura de ataque é detectada, ou seja, quando o tráfego de entrada possui uma característica que é encontrada na base de assinaturas do dispositivo. Isso permite que o sensor possa agir antes que a segurança da rede tenha sido comprometida. O sensor pode agir e em seguida registrar o evento enviando uma mensagem para um servidor de syslog, por exemplo, ou pode enviar alerta através do “Security Device Event Exchange” ou SDEE. O uso do SDEE é mais aconselhável porque ele é o mais novo e mais seguro recurso para envio de alertas, utilizando HTTPS para trocar os alertas entre o IPS e o servidor de monitoramento. Ao usar o IOS IPS em um roteador, o SDEE é usado para relatar eventos para o CCP, por exemplo. No entanto, o CCP é limitado pelo fato de que ele não pode fazer acompanhamento em tempo real ou correlacionar os eventos de vários sensores presentes na rede, ele tem apenas a capacidade de mostrar os diversos alarmes. Para ter esses recursos avançados é necessário implantar uma ferramenta como o “Cisco Security Monitoring, Analysis and Response System” (CS - MARS) ou o “Cisco Works”. Como alternativa às ferramentas acima, que são caras e para redes de médio a grande porte, o “Cisco IPS Event Viewer software” (IEV) pode ser utilizado. O download exige um login e CCO e para obter atualizações de assinatura você deve ter um contrato de manutenção válido para cada um dos sensores que você está usando.


   

 

 



   

    

   



Página 244

 

 

  


2.7 IPv6 e IPS O que vai acontecer com meu IPS se a empresa utilizar IPv6 na rede? 1. O IPS/IDS devem entender ou suportar o protocolo IPv6. 2. Mais regras e assinaturas deverão ser criadas e ativadas para mitigar ataques ao protocolo IPv6. Portanto, normalmente um upgrade ou update de software e instalação de novas assinaturas resolverão também assuntos pertinentes ao IPv6. 2.8 É possível Enganar um IPS/IDS? Claro que o atacante sempre tem o objetivo de realizar um ataque de maneira que ele não possa ser rastreado e fique invisível aos sistemas de segurança utilizando vários métodos de evasão. Não seria diferente para um sistema que utiliza IPS/IDS e foram desenvolvidas várias técnicas e maneiras para se evadir desses sistemas de segurança. A Cisco constantemente estuda essas técnicas e implementa recursos para minimizar tais tentativas. Abaixo segue uma lista de algumas técnicas de evasão e como a Cisco trata o problema em seus sensores. 











Fragmentação dos pacotes IP (Traffic fragmentation): o atacante divide o tráfego ou pacotes IP em fragmentos na esperança que o IPS/IDS e firewall não detectem o ataque, pois cada pedaço do código malicioso está em um fragmento. Os sensores para resolver esse problema fazem a remontagem dos pacotes (reassembly) para aí sim analisar seu conteúdo. Esse é um tipo de ataque comum no IPv6. Substituição e inserção de tráfego (Traffic substitution and insertion): o atacante substitui caracteres nos dados utilizando formatos diferentes com o mesmo significado, por exemplo, utilizando palavras em Unicode que o usuário final conseguiria interpretar, mas o IPS/IDS podem não reconhecer. Esse tipo de técnica de evasão é combatido com a normalização dos dados e técnicas de “de-obfuscation”, inclusive os sensores da Cisco conseguem analisar strings em Unicode, letras maiúsculas, substituição de espaços por TAB e outros recursos similares utilizados para confundir os sensores. Ataques aos protocolos (Protocol level misinterpretation): um atacante pode tentar fazer com que um sensor interprete de forma errada o significado de um protocolo de rede na comunicação fim a fim, talvez não pegando um ataque em andamento. Os recursos implementados para evitar esse tipo de ataque são análise do TTL (IP Time-To-Live analysis) e verificação do checksum do TCP. Ataques temporizados (Timing attacks): enviando mensagens com uma taxa baixa a assinatura pode não perceber o ataque e deixar de disparar um alerta, por exemplo, uma assinatura que verifica um ataque de flood e é disparada com uma taxa de 1500 pacotes por segundo, se o atacante enviar 1000 pacotes por segundo o ataque não será detectado pela assinatura. Nesses casos podemos configurar diferentes intervalos para o mesmo ataque e também utilizar correlação de eventos com outros dispositivos de segurança. Criptografia e Tunelamento (Encryption and tunneling): se um atacante conseguir fechar um túnel criptografado com sua vítima dificilmente ele será detectado pelo sensor. Se for fechado um túnel GRE sem criptografia os sensores da Cisco são capazes de analisar o payload. Um túnel coloca a informação final dentro de outro cabeçalho do IP, por isso torna-se difícil de analisar, ainda mais quando esse payload está criptografado. Esse é um dos maiores riscos com as técnicas de migração e convivência do IPv6, pois existem diversos tipos de túneis que podem ser criados mesmo quando a rede IPv4 utiliza NAT. Exaustão de recursos (Resource exhaustion): se o atacante enviar milhares de ataques simultâneos ele pode sobrecarregar tanto o sensor como o administrador de A p o s t i l a / E - Bo o k d o C u r s o I I N S 6 4 0 - 5 5 4

     

   

 

 



   

    

   



Página 245

 

 

  


redes, distraindo a atenção de ambos enquanto tenta realizar um ataque mais específico. Nos sensores da Cisco há possibilidade de fazer a sumarização de ataques em poucos alertas, por exemplo, se 1000 dispositivos estão sofrendo o mesmo ataque o sensor sumariza esses ataques em poucos avisos, o que é muito melhor que visualizálos um a um. Então, na sua opinião “é possível enganar um sensor seja ele de que fabricante for”? Será que conseguimos com os recursos de firewall, medidas de proteção na camada-2, IPS e IDS manter a rede 100% segura contra quaisquer tipos de ataques e atacantes? Pense sobre o assunto, essa é uma conclusão que cada um deve chegar sozinho! Quer discutir o assunto? Utilize o fórum do capítulo. 2.9 Comparação entre IPS e IDS Veja na tabela um resumo da comparação entre um IDS e um IPS.

As principais vantagens de um IPS de rede (Network IPS - NIPS) são que ele não interfere diretamente na rede, apesar de que se mal planejado pode causar problemas de desempenho, como atraso e jitter, também seu sistema operacional é independente e específico para o dispositivo e consegue verificar problemas e incidentes desde a camada 2 a 7 do modelo OSI. Suas principais desvantagens são não conseguir analisar tráfego criptografado e não conseguir determinar se o ataque detectado foi ou não bem sucedido, pois o ataque pode ter sido bloqueado após algum tempo e já ter causado danos ao host de destino.


   

 

 



   

    

   



Página 246

 

 

  


2.10 Opções da Cisco para IPS e IDS Cisco oferece uma série de sensores IDS/IPS, mais especificamente a série Cisco 4200. É importante saber que todos os sensores possuem pelo menos duas interfaces: 



Interface de comando e controle: Uma interface de controle deve ser configurada com um endereço IP e é utilizada para se comunicar com outros dispositivos de rede (por exemplo, um dispositivo de monitoração) para fins de gerenciamento. Interface de monitoração: Todos os sensores têm pelo menos uma interface de monitoramento, a qual é utilizada para monitorar/analisar o tráfego da rede.

Além da série 4200 temos as seguintes opções para implantação do IDS e IPS: 



Software rodando em roteadores com Cisco IOS que suportam esses recursos. Tanto a linha ISR-G1 como a linha ISR-G2 suportam esse recurso.

Módulo em roteadores com Cisco IOS IPS Advanced Integration Module (IPS AIM) ou um Network Module Enhanced (IPS NME).


   

 

 



   

    

   



Página 247

 

 

  






Módulo no ASA firewall chamado “Inspection and Prevention Security Services Module” (ASA AIP-SSM).

Em blade para switches multicamada 6500, chamado “Intrusion Detection System Services Module” (IDSM-2).

A escolha do equipamento a ser utilizado na sua rede depende de vários parâmetros, mas principalmente:    

Volume de tráfego da rede Topologia da rede Orçamento para área de segurança Equipe técnica capacitada para trabalhar com a Tecnologia IPS

Implementações de pequeno porte, tais como escritórios remotos podem ter apenas o Cisco IOS IPS habilitado no roteador ISR. Com o aumento dos padrões de tráfego pode ser instalado um módulo IPS NME ou AIM IPS, liberando o roteador das funções de IPS e deixando para os módulos tratarem, liberando processamento e memória dos roteadores para outras atividades. Instalações de maior porte poderiam ser implantados usando um firewall ASA 5500 existente com módulo AIP ASA.


   

 

 



   

    

   



Página 248

 

 

  


Já em empresas de grande porte e prestadores de serviço necessitam de dispositivos que funcionam exclusivamente como IPS da família 4200 ou um Catalyst 6500 com um módulo de rede IDSM-2. 3 Tipos de Abordagens para Identificação de Invasões Os sensores IDS e IPS podem ser usados para rastrear e identificar o tráfego suspeito através de diferentes abordagens ou maneiras. Cada uma das abordagens tem vantagens e desvantagens, mas utilizando a combinação de abordagens é possível obter resultados finais muito bons. As abordagens que os sensores podem utilizar são:     

Signature based IPS/IDS (com base nas Assinaturas de Ataque). Policy based IPS/IDS (com base em política). Anomaly based IPS/IDS (com base em anomalia). Reputation-based IPS/IDS (com base na reputação). Honey-pot (tradução literal “pote de mel”).

Vamos estudar essas abordagens a seguir. 3.1 Abordagem por Assinaturas (Signature based approach) Essa abordagem também pode ser chamada de abordagem baseada em padrões (pattern based approach) e está fundamentada em uma simples comparação de um padrão de tráfego préestabelecido na base de assinaturas com o tráfego entrante. Normalmente o sistema irá procurar uma assinatura apenas se um pacote está associado a um serviço específico (geralmente utilizando a porta de destino). Para aplicações como cavalos de Tróia e similares, fica quase impossível de se identificar o ataque através de uma porta de destino, porque as portas mudam dinamicamente nos aplicativos. Veja a figura a seguir.

Após a implantação de um IPS você terá problemas com o número de mensagens geradas, pois a otimização de um sensor pode demorar a ser feita. Com isso você pode receber vários alertas imediatamente após uma nova instalação. Estes alertas são chamados de falsos positivos e eles ocorrem quando uma assinatura age sobre um tráfego que não pertence a um ataque, ou seja, é um tráfego normal da rede e não uma ameaça. Depois que o sistema é ajustado para as especificações da rede haverá menos alertas falsos do que com uma abordagem baseada em política (será discutido a seguir). A p o s t i l a / E - Bo o k d o C u r s o I I N S 6 4 0 - 5 5 4      

   

 

 



   

    

   



Página 249

 

 

  


3.2 Abordagem por Políticas (Policy based approach) Essa abordagem utiliza um algoritmo para tomada de decisão, onde o administrador pode definir uma atividade suspeita baseada no histórico da rede, por exemplo. Com base na política configurada, qualquer padrão de tráfego detectado que fique fora dela o IPS pode informar ao sistema de monitoramento através um alarme ou até mesmo bloquear esse tráfego suspeito. Vamos a um exemplo prático de detecção baseada em políticas para detectar uma varredura de porta ou port scan, onde o algoritmo irá gerar um alarme quando um número limite de portas (pré-determinado pelo administrador) for acessado em um período d e tempo em uma máquina específica, veja a figura a seguir. Algoritmos de assinatura baseada em política podem analisar apenas tipos específicos de pacotes (por exemplo, os pacotes SYN onde o bit SYN está configurado durante o processo de handshake no início da sessão).

Uma abordagem ou detecção baseada em Política requer que o administrador execute alguns ajustes para que as medidas de segurança estejam em conformidade com sua política global de segurança para a rede da empresa. Essa abordagem pode ser usada para procurar um evento estatístico simples ou relações complexas. 3.3 Anomaly - Based Approach ou Abordagem por Detecção de Anomalias O IDS ou IPS que usa essa técnica estabelece uma base com padrões de uso normal, e tudo o que desviar bastante desse padrão será marcado como uma possível intrusão. O que é considerado anomalia pode variar, mas normalmente, qualquer incidente que ocorra com frequência de mais ou menos dois desvios padrões da norma estatística gera uma preocupação. Esses detectores constroem um padrão de comportamento para os usuários, hosts e conexões de rede. Essa abordagem também pode ser chamada de behavior-based detection ou detecção baseada em comportamento. Temos dois tipos de IPS e IDS que podem utilizar a detecção por anomalias de rede: 

Estatístico: aprende o perfil da rede monitorada a partir da própria rede por um período de tempo. Após esse período, o sistema pode detectar atividades fora do padrão habitual, fazendo com que o sistema dispare um alarme para a monitoração.


   

 

 



   

    

   



Página 250

 

 

  


Não estatística: tem uma definição prévia do que pode ser considerado “bom comportamento” conhecido (normalmente definido pelo fabricante). Um alarme é disparado quando um evento fora do perfil ocorre.

Vantagens da detecção por anomalias: 



Como detecta comportamentos, e não usuários, pode detectar um ataque sem conhecimento prévio do mesmo; Gera informações que podem ser usadas para definir assinaturas.

Desvantagens da detecção por anomalias: 



É comum produzir grande numero de alarmes falsos, devido a comportamentos imprevisíveis dos usuários e de sistemas; Devem ser realizadas muitas sessões para coletar dados para o sistema, com o intuito de caracterizar os padrões normais de comportamento.

3.4 Reputation-Based IPS/IDS Esse tipo de abordagem é bastante recente e leva em conta uma coleção de entradas de sensores espalhados pelo globo e estão participando de uma rede de correlação global, ou seja, o que os sensores aprenderam de maneira coletiva pode ser utilizado pelo seu sensor de maneira local. Reputation-based IPS/IDS podem utilizar blocos de endereços IP, URLs, domínios de DNS e outros tipos de descritores para identificar a origem de um ataque. Serviços de correlação de eventos globais são mantidos e gerenciados pela Cisco como serviços em nuvem. 3.5 Abordagem de Honeypot Honeypot (em português, Pote de Mel) é uma ferramenta que tem a função de propositalmente simular falhas de segurança em um sistema ou equipamento com o objetivo de colher informações sobre o invasor. Ele é uma espécie de armadilha para invasores e não oferece nenhum tipo de proteção, pelo contrário, deve ser um dispositivo, servidor ou VM que será “sacrificado” e totalmente comprometido. Além disso, o honeypot pode também servir como uma distração para os atacantes, escondendo os dispositivos que realmente devem estar seguros na rede. Veja a figura a seguir.


   

 

 



   

    

   



Página 251

 

 

  


Abaixo seguem os tipos de HoneyPot mais comumente utilizados: 



Honeypots de pesquisa: tem a função de acumular o máximo de informações dos invasores e suas ferramentas, normalmente não possuem ligação com a rede interna da empresa. Honeypots de produção: elemento de distração ou dispersão para proteger os servidores e dispositivos dos atacantes.

4 Implementando Cisco IOS IPS via CLI O Cisco IOS IPS permite aos administradores gerenciar a prevenção de intrusões nos roteadores que utilizam o Cisco IOS versão 12.3(8)T4 ou superiores. Cisco IOS IPS monitora e impede intrusões, comparando o tráfego com as assinaturas de ataques conhecidas para bloquear o tráfego quando for detectada uma ameaça. Os IOSs versão 12.4(10) ou anteriores utilizam o IPS versão 4.x, as versões posteriores utilizam o IPS versão 5.x, o qual tem alguns comandos diferentes em relação à versão anterior. Para instalar um IOS IPS no roteador você deve certificar que ele possui as especificações de memória RAM necessárias e escolher o IOS correto para seu modelo. Veja a seguir as tabela para a série 800/1800/2800/3800 e 800/1900/2900/3900. Para fazer o download o seu CCO deve ter um cotrato de serviços atrelado que permita tal operação.


   

 

 



   

    

   



Página 252

 

 

  


Família de Produtos

Plataformas Suportadas

IOS Suportado (Feature Sets)

800

871, 876, 877, 878

Advanced IP Services

1800

1801,1802,1803,1811,18 12,1841, 1861

Advanced Security, Advanced Enterprise e Advanced IP Services

2800

2801, 2811,2821,2851


3800

3825,3845


SR520

Advanced Security e Advanced IP Services

7200

7204VXR, 7206VXR


7301

7301


SR520

Família de Produtos

Plataformas Suportadas

Licença Suportada

800

881, 886, 887, 888, 891, 892

Advanced IP Services

1900

1921, 1941

Security

2900

2901, 2911,2921,2951

Security

3900

3925,3945

Security

Agora, levando em conta que o IOS está instalado e rodando em seu roteador, para implementar o IPS em um roteador com o Cisco IOS IPS via CLI devemos seguir os passos abaixo: 1. 2. 3. 4. 5.

Fazer o download dos arquivos relacionados ao IOS IPS (pacote de assinaturas). Criar um diretório de configuração na flash para o IOS IPS. Configurar uma chave criptográfica (crypto key) para o IOS IPS. Habilitar o IPS via CLI. Carregar o pacote de assinaturas do IOS IPS no roteador.

Vamos estudar os passos para ativação do IOS IPS via CLIa seguir.


   

 

 



   

    

   



Página 253

 

 

  


4.1 Passo 01: Download dos arquivos do IPS Antes de iniciar a configuração do IPS devemos baixar os arquivos com as assinaturas de ataques ou pacote de assinaturas, além disso, será necessário baixar a chave de criptografia pública também do site da Cisco.com, para isso o seu CCO deve possuir permissão para tais ações. Os arquivos terão a seguinte nomenclatura:  

IOS-Sxxx-CLI.pkg – baixar a última versão de pacote de assinatura disponível. realm-cisco.pub.key.txt – esta é a chave criptográfica pública utilizada pelo IOS IPS.

As assinaturas podem ser baixadas via o Software Download Center: http://www.cisco.com/cisco/software/navigator.html?a=a&i=rpm Clicando em “Security”, seguido de "Integrated Router/Switch Security", depois clicando no link "Integrated Threat Control", por último clicando no link "Cisco IOS Intrusion Prevention System Feature Software".  


   

 

 



   

    

   



Página 254

 

 

  


4.2 Passo 02: Criando diretório de configuração na flash para o IOS IPS Agora vamos criar o diretório para guardar as assinaturas e arquivos de configuração do IPS na memória flash do roteador utilizando o comando “mkdir nome-do-diretorio” em modo privilegiado (EXEC). Outro comando útil é o “rename nome-atual novo-nome”, que pode ser utilizado pelo administrador para mudar o nome do diretório sem apagar seu conteúdo. Para verificar o conteúdo da flash e o diretório criado utilize o comando “dir flash:”. No exemplo a seguir vamos criar um diretório chamado IPS e depois visulizar se ele foi criado corretamente na flash. Router#mkdir flash:IPS Create directory filename [IPS]? Created dir flash:IPS Router#dir flash: Directory of flash:/ 4 3 2 1

drw-rw-rw-rw-

0 33591768 28282 227537

date> date> date> date>

IPS c1841-advipservicesk9-mz.124-15.T1.bin sigdef-category.xml sigdef-default.xml

64016384 bytes total (30168797 bytes free) Router#

4.3 Passo 03: Configure a chave criptográfica (crypto key) para o IOS IPS Copie o conteúdo do arquivo realm-cisco.pub.key.txt que pode ser baixado do site da Cisco ou da "Área do Aluno", abra o arquivo no notepad, entre em modo de configuração global no roteador, selecione o texto completo, copie e cole no prompt do roteador. Acompanhe a seguir: R1#config term R1(config)#crypto key pubkey-chain rsa R1(config-pubkey-chain)# named-key realm-cisco.pub signature Translating "realm-cisco.pub" R1(config-pubkey-key)# key-string Enter a public key as a hexidecimal number .... R1(config-pubkey)#$2A864886 F70D0101 R1(config-pubkey)#$D6CC7A24 5097A975 R1(config-pubkey)#$912BE27F 37FDD9C8 R1(config-pubkey)#$085FADC1 359C189E R1(config-pubkey)#$0298AF03 DED7A5B8 R1(config-pubkey)#$994AE74C FA9E481D R1(config-pubkey)#$5E4189FF CC189CB9 R1(config-pubkey)#$A3B3FB1F 9FB7B3CB R1(config-pubkey)#$80CA4F4D 87BFCA3B R1(config-pubkey)# F3020301 0001 R1(config-pubkey)# quit R1(config-pubkey-key)# exit R1(config-pubkey-chain)# exit R1(config)#end R1#

01050003 206BE3A2 11FC7AF7 F30AF10A 9479039D F65875D6 69C46F9C 5539E1D1 BFF668E9

82010F00 06FBA13F DCDD81D9 C0EFB624 20F30663 85EAF974 A84DFBA5 9693CCBB 689782A5

3082010A 6F12CB5B 43CDABC3 7E0764BF 9AC64B93 6D9CC8E3 7A0AF99E 551F78D2 CF31CB6E

02820101 4E441F16 6007D128 3E53053E C0112A35 F0B08B85 AD768C36 892356AE B4B094D3


   

 

 



   

    

   



Página 255

 

 

  


Essa chave criptográfica verificará a integridade do arquivo principal de assinaturas, o qual o conteúdo foi assinado com a chave pública da Cisco. Ela garante a autenticidade e validade do arquivo. Caso ocorra um erro, como o ilustrado abaixo, remova a chave e crie novamente, caso a chave tenha sido configurada errada. %IPS-3-INVALID_DIGITAL_SIGNATURE: Invalid Digital Signature found (key not found) Veja abaixo os comandos para apagar a chave: router#configure terminal router(config)#no crypto key pubkey-chain rsa router(config-pubkey-chain)#no named-key realm-cisco.pub signature router(config-pubkey-chain)#exit router(config)#exit

Verifique também se os arquivos baixados estão corretos e se não houve problema no download através do MD5 do arquivo. 4.4 Passo 04: Habilitando o IPS via CLI Para habilitar o IPS básico em seu roteador, você deve seguir 5 passos. Passo 1: Crie o nome de uma regra que será utilizada em uma Interface para habilitar o IPS. Comando: ip ips name < opcional ACL>. Veja o exemplo a seguir utilizando como nome ios-ips. router#configure terminal router(config)# ip ips name ios-ips

Você pode ainda através de uma ACL padrão ou estendida filtrar o tráfego que será escaneado ou analisado pela regra criada. O tráfego permitido pela ACL será analisado pelo IPS e o negado (deny) não será avaliado. Veja exemplo abaixo: router(config)#ip ips name ips list ? <1-199> Numbered access list WORD Named access list

Passo 2: Configure o arquivo do IPS, criado no passo 2, veja na prática abaixo como configurar. Comando: ip ips config location flash: router(config)#ip ips config location flash:IPS

Passo 3: Habilite a notificação de eventos via SDEE (veja exemplo a seguir). Comando: ip ips notify sdee router(config)# ip http server router(config)#ip ips notify sdee

Também podemos enviar as mensagens do IOS IPS utilizando um servidor de syslog, podendo ser configurado ao mesmo tempo em que o SDEE, ou seja, o roteador pode utilizar os dois métodos. As notificações de Syslog são habilitadas por padrão, para habilitar em caso de terem sido desligadas utilize o comando abaixo: router(config)#ip ips notify log


   

 

 



   

    

   



Página 256

 

 

  


Para utilizar o SDEE o HTTP server deve estar habilitado, conforme comando acima (ip http server). O SDEE é desabilitado por padrão e para utilizá-lo você terá que habilitar. Passo 4: Configure o IOS IPS para utilizar categorias de assinaturas pré-definidas. No IOS IPS com Cisco 5.x as assinaturas são agrupadas em categorias, as quais são hierárquicas e parecidas com a maneira que os dispositivos IPS da Cisco operam. Isto ajuda a classificar as assinaturas para facilitar o agrupamento e ajuste fino (tuning). As três categorias mais utilizadas são all, basic e advanced. As assinaturas que IOS IPS utilizará para verificar o tráfego podem ser retired (aposentadas na tradução literal ou retiradas) ou unretired (utilizadas), sendo que ao dar o comando de retire em uma assinatura o IOS IPS não compilará essa assinatura na memória para varredura. Ao passo que o comando unretire para uma categoria de assinatura faz com que o IOS IPS compile a assinatura na memória e utilize-a para verificar o tráfego. Quando IOS IPS é configurado pela primeira vez, todas as assinaturas na categoria “all” devem receber o comando de retired, pois normalmente o roteador não possui memória e capacidade o suficiente para tratar todas as assinaturas que o IPS tem na categoria all, podendo trazer uma queda drástica na performance do equipamento. Ao invés de utilizar a categoria de assinatura all você deve utilizar a basic, por exemplo. Veja a configuração a seguir. router(config)#ip ips signature-category router(config-ips-category)# category all router(config-ips-category-action)# retired true router(config-ips-category-action)# exit router(config-ips-category)# category ios_ips basic router(config-ips-category-action)# retired false router(config-ips-category-action)# exit router(config-ips-category)# exit Do you want to accept these changes? [confirm]y router(config)#

Com o comando “ip ips signature-category” você entra no modo de configuração/edição das categorias e pode entrar em cada categoria pré-configurada (comando category categoria) e utilizar o comando retired seguido por true, que faz com que a categoria seja retirada da análise, ou false, que faz com que a categoria seja compilada na memória para análise do tráfego pelo IPS. Para configurar o IPS para utilizar a categoria básica, diferente da categoria all, tivemos que digitar o nome que criamos no passo 4.1, veja no pedaço de configuração retirado abaixo. router(config-ips-category)# category ios_ips basic router(config-ips-category-action)# retired false router(config-ips-category-action)# exit

Note também que ao sair desse modo de operação foi solicitado um “yes” para confirmar as alterações. Passo 5: Habilitar a regra do IPS na interface desejada e direção correta. Comandos: interface ip ips A p o s t i l a / E - Bo o k d o C u r s o I I N S 6 4 0 - 5 5 4      

   

 

 



   

    

   



Página 257

 

 

  


router(config)#interface Fast 0/0 router(config-if)#ip ips ios-ips in router(config-if)#exit router(config)#exit router#

A direção “in” refere-se ao tráfego entrante na interface e a “out” o tráfego de saída da interface. Para habilitar o IPS para inspecionar tanto in como out na mesma interface digite o nome da regra separadamente para as duas direções, conforme exemplo abaixo: router(config)#interface Fast 0/1 router(config-if)#ip ips ios-ips in router(config-if)#ip ips ios-ips out router(config-if)#exit router(config)#exit router#

4.5 Passo 05: Carregando o pacote de assinaturas do IOS IPS no roteador Para carregar o pacote de assinaturas o mais utilizado são os serviços de FTP e TFTP, porém outros métodos podem ser utilizados como diretamente da flash ou via HTTP. Para carregar via FTP utilize o comando abaixo: copy ftp:/// idconf O usuário e senha são referentes ao servidor FTP, veja um exemplo abaixo. router#copy ftp://dltec:[email protected]/IOS-S310-CLI.pkg idconf Loading IOS-S310-CLI.pkg !!!!!!!!!!!!!!!!!!!!!!!!!!!!!! [OK - 7608873/4096 bytes]

No exemplo mostrado ao lado primeiro vamos copiar o arquivo de assinaturas com o nome “IOS-S556-CLI.pkg” para a flash no subdiretório com o nome IOS (previamente criado), em seguida vamos compilar o arquivo a partir da flash, seguem os comandos: R1#copy tftp:IOS-S556-CLI.pkg flash:/IPS Address or name of remote host [10.0.10.15]? Source filename [IOS-S556-CLI.pkg]? Destination filename [/IPS/IOS-S556-CLI.pkg]? Accessing tftp://10.0.10.15/IOS-S556-CLI.pkg... Loading IOS-S556-CLI.pkg from 10.0.10.15 (via FastEthernet0/0): !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! [OK - 12757876 bytes] 12757876 bytes copied in 357.632 secs (35673 bytes/sec) R1# R1#copy disk0:/IPS/IOS-S556-CLI.pkg idconf R1#

Imediatamente após o pacote ser carregado no roteador a compilação é iniciada e os logs do roteador serão mostrados se você estiver logado com uma senha de nível 6 ou acima, conforme exemplo abaixo. *Feb 14 16:44:47 *Feb 14 16:44:47 13 engines *Feb 14 16:44:47 packets for this

PST: %IPS-6-ENGINE_BUILDS_STARTED: 16:44:47 PST Feb 14 2008 PST: %IPS-6-ENGINE_BUILDING: multi-string - 8 signatures - 1 of PST: %IPS-6-ENGINE_READY: multi-string - build time 4 ms engine will be scanned


   

 

 



   

    

   



Página 258

 

 

  


*Feb 14 16:44:47 PST: %IPS-6-ENGINE_BUILDING: service-http - 622 signatures - 2 of 13 engines *Feb 14 16:44:53 PST: %IPS-6-ENGINE_READY: service-http - build time 6024 ms packets for this engine will be scanned | Saída omitida…

| *Feb 14 16:45:18 PST: %IPS-6-ENGINE_BUILDING: service-smb-advanced - 35 signatures - 12 of 13 engines *Feb 14 16:45:18 PST: %IPS-6-ENGINE_READY: service-smb-advanced - build time 16 ms - packets for this engine will be scanned *Feb 14 16:45:18 PST: %IPS-6-ENGINE_BUILDING: service-msrpc - 25 signatures - 13 of 13 engines *Feb 14 16:45:18 PST: %IPS-6-ENGINE_READY: service-msrpc - build time 32 ms packets for this engine will be scanned *Feb 14 16:45:18 PST: %IPS-6-ALL_ENGINE_BUILDS_COMPLETE: elapsed time 31628 ms

A compilação pode demorar dependendo da versão do arquivo “pkg”, pois pode haver várias assinaturas. Além disso, alguns erros podem aparecer se você tiver dado um unretire nas categorias basic ou advanced, pois algumas assinaturas não são compatíveis com o IOS IPS. O roteador fará a análise dos pacotes com as assinaturas que foram compiladas com sucesso. Para verificar o arquivo carregado e se a compilação teve sucesso utilize o comando “ show ip ips signature count”, veja exemplo abaixo. R1#show ip ips signature count Cisco SDF release version S556.0 Trend SDF release version V0.0 Signature Micro-Engine: multi-string: Total Signatures 199 multi-string enabled signatures: 137 multi-string retired signatures: 59 multi-string compiled signatures: 65 multi-string inactive signatures - invalid params: 2 multi-string Inactive - compile failure: 73 multi-string obsoleted signatures: 1 Signature Micro-Engine: service-http: Total Signatures 887 service-http enabled signatures: 161 service-http retired signatures: 664 service-http compiled signatures: 139 service-http inactive signatures - invalid params: 12 service-http Inactive - compile failure: 72 service-http obsoleted signatures: 3 Signature Micro-Engine: string-tcp: Total Signatures 2372 string-tcp enabled signatures: 640 string-tcp retired signatures: 1612 string-tcp compiled signatures: 275 string-tcp inactive signatures - invalid params: 107 string-tcp Inactive - compile failure: 378 string-tcp obsoleted signatures: 32 Signature Micro-Engine: string-udp: Total Signatures 79 string-udp enabled signatures: 0 string-udp retired signatures: 73 string-udp compiled signatures: 6 string-udp obsoleted signatures: 2


   

 

 



   

    

   



Página 259

 

 

  


Signature Micro-Engine: state: Total Signatures 38 state enabled signatures: 13 state retired signatures: 19 state compiled signatures: 16 state inactive signatures - invalid params: 2 state Inactive - compile failure: 1 Signature Micro-Engine: atomic-ip: Total Signatures 413 atomic-ip enabled signatures: 105 atomic-ip retired signatures: 222 atomic-ip compiled signatures: 99 atomic-ip Inactive - compile failure: 92 atomic-ip obsoleted signatures: 1 Signature Micro-Engine: string-icmp: Total Signatures 3 string-icmp enabled signatures: 0 string-icmp retired signatures: 3 Signature Micro-Engine: service-ftp: Total Signatures 3 service-ftp enabled signatures: 1 service-ftp retired signatures: 2 service-ftp compiled signatures: 1 Signature Micro-Engine: service-rpc: Total Signatures 76 service-rpc enabled signatures: 44 service-rpc retired signatures: 28 service-rpc compiled signatures: 30 service-rpc inactive signatures - invalid params: 18 Signature Micro-Engine: service-dns: Total Signatures 39 service-dns enabled signatures: 27 service-dns retired signatures: 8 service-dns compiled signatures: 31 service-dns obsoleted signatures: 1 Signature Micro-Engine: normalizer: Total Signatures 9 normalizer enabled signatures: 8 normalizer compiled signatures: 8 Signature Micro-Engine: service-smb-advanced: Total Signatures 62 service-smb-advanced enabled signatures: 47 service-smb-advanced retired signatures: 12 service-smb-advanced compiled signatures: 50 service-smb-advanced obsoleted signatures: 1 Signature Micro-Engine: service-msrpc: Total Signatures 35 service-msrpc enabled signatures: 15 service-msrpc retired signatures: 20 service-msrpc compiled signatures: 15 service-msrpc obsoleted signatures: 1 Total Signatures: 4215 Total Enabled Signatures: 1198 Total Retired Signatures: 2722 Total Compiled Signatures: 735 Total Signatures with invalid parameters: 141 Total Signatures with compile failures: 616 Total Obsoleted Signatures: 42


   

 

 



   

    

   



Página 260

 

 

  


R1#

Esse arquivo também já pode estar gravado na memória flash do roteador caso ele tenha sido adquirido com o software de IOS IPS, normalmente o arquivo SDF vem nomeado com a quantidade de memória do roteador, por exemplo, um router de 128M de RAM o arquivo será nomeado 128MB.sdf na versão 4.x e no formato ‘IOS-S360-CLI-pkg’ para a 5.x. Com essas configurações o IPS estará habilitado no roteador com o IOS IPS instalado. Em seguida veremos a mesma configuração através do CCP. 5

Implementando Cisco IOS IPS via CCP

Para configurar o IOS IPS via CCP vamos utilizar uma metodologia muito parecida com o que fizemos no capítulo anterior, porém com a facilidade de um Wizard (ferramenta de ajuda) para executar as configurações. Para iniciar a configuração abra o CCP, faça o login no roteador, depois de carregada a tela inicial clique “Configure > Security > Intrusion Prevention” ou “Configure > Security > Advanced Security> Intrusion Prevention”, dependendo da versão do CCP, e por último clique no botão “Launch IPS Rule Wizzard”, conforme figura a seguir.

Para que o computador rodando CCP possa configurar o IOS IPS, um mínimo de “Java heap size” deve ser configurado para 256MB de memória, porém somente se ao clicar no botão do Wizard aparecer um erro. Se o erro aparecer quando você clicar no botão Iniciar IPS Rule Wizard, você deve alterar esse parâmetro do Java clicando na opção Java e abrir o Control Panel (painel de contorle) do Java. Selecione a guia Java, clique no botão "Ver" em “Applet Java Runtime Settings” e no campo “Java Parameter Runtime” digite exatamente -Xmx256m e clique em OK.


   

 

 



   

    

   



Página 261

 

 

  


Caso apareça uma janela sobre a ativação do SDEE após o clique no botão de “Launch IPS Rule...” clique em OK depois aparecerá outra janela informando que o CCP vai abrir uma sessão para coletar eventos via SDEE, também clique OK, conforme figuras a seguir respectivamente.

Na próxima aba você terá uma tela de introdução que dará uma instrução geral de como prosseguir nas configurações.

Clique no botão Next (tecnologia NNF – next, next, finish mais uma vez) para escolher as interfaces a serem analisadas pelo IPS. As direções in e out estão com o nome completo inbound e outbound, conforme figura a seguir.


   

 

 



   

    

   



Página 262

 

 

  


No próximo passo, dependendo da versão de CCP utilizada você deverá indicar o local onde o arquivo SDF deve ser carregado ou o pacote de assinaturas que deverá ser encontrado. Como estamos utilizando a versão mais nova e baseando as assinaturas no formato da versão 5.x a tela que você receberá será conforme figura a seguir.

Primeiro você deverá inserir a localização do arquivo de assinatura (signature file) no formato sigv5-CCP-SXXX.zip, note que o formato que o CCP utiliza é diferente do que utilizamos para a configuração via CLI e estamos buscando as assinaturas no próprio computador. É possível


   

 

 



   

    

   



Página 263

 

 

  


utilizar a opção de Download, mas você precisa ter um CCO válido e com permissão para baixar direto do site da Cisco. Na mesma tela no campo abaixo “Configure Public Key” insira os valores da chave pública da Cisco, a mesma utilizada no capítulo anterior, porém insira somente a chave, pois os comandos para criar no roteador o próprio CCP irá inserir. Os detalhes de como baixar os arquivos são os mesmos vistos anteriormente. O nome da chave é realm-cisco.pub. Sobre a chave, copie tudo entre as palavras "key-string" e "quit", conforme abaixo: 30820122 300D0609 2A864886 F70D0101 01050003 82010F00 3082010A 02820101 00C19E93 A8AF124A D6CC7A24 5097A975 206BE3A2 06FBA13F 6F12CB5B 4E441F16 17E630D5 C02AC252 912BE27F 37FDD9C8 11FC7AF7 DCDD81D9 43CDABC3 6007D128 B199ABCB D34ED0F9 085FADC1 359C189E F30AF10A C0EFB624 7E0764BF 3E53053E 5B2146A9 D7A5EDE3 0298AF03 DED7A5B8 9479039D 20F30663 9AC64B93 C0112A35 FE3F0C87 89BCB7BB 994AE74C FA9E481D F65875D6 85EAF974 6D9CC8E3 F0B08B85 50437722 FFBE85B9 5E4189FF CC189CB9 69C46F9C A84DFBA5 7A0AF99E AD768C36 006CF498 079F88F8 A3B3FB1F 9FB7B3CB 5539E1D1 9693CCBB 551F78D2 892356AE 2F56D826 8918EF3C 80CA4F4D 87BFCA3B BFF668E9 689782A5 CF31CB6E B4B094D3 F3020301 0001 Depois de inseridas as informações clique em Next para configurar a localização do arquivo de configuração e a categoria de assinaturas a serem utilizadas (Config Location) e após defina a categoria (Choose Category), conforme figura a seguir.

No passo 1, clicando no botão “Config Location” você irá criar a pasta onde os arquivos de configuração (XML) e as assinaturas serão guardadas no roteador. Escolha o nome do arquivo criado na flash e clique em OK. Se você não criou o arquivo utilize a CLI ou SSH/Telnet para criar conforme estudamos para a ativação do IPS via CLI (comando mkdir).


   

 

 



   

    

   



Página 264

 

 

  


No passo 2 você deve escolher a categoria de assinaturas, onde a básica (basic) é recomendada para roteadores com até 128M de RAM e o avançado (advanced) para roteadores com mais de 128M de memória RAM. Após escolhida a categoria clique em “Netx” para visualizar o resumo das configurações e clique em “Finish” para finalizar o Wizard.

Nessa etapa o CCP te dá algumas opções desde cancelar, apenas gravar em um arquivo ou aplicar no roteador (deliver).


   

 

 



   

    

   



Página 265

 

 

  


Clicando em deliver teremos as seguintes mensagens: um resumo dos comandos, depois de clicar OK o CCP informará que as assinaturas estão sendo aplicadas no roteador e pode levar vários minutos para finalizar, pois é um processo igual ao que fizemos via CLI quando compilamos as assinaturas e levou alguns minutos para finalizar.


   

 

 



   

    

   



Página 266

 

 

  


6 Modificando as Assinaturas Via CLI e CCP - Tunning Você pode encontrar alguns casos onde uma assinatura é obsoleta e pode dar problemas na compilação devido ao espaço em memória ou parâmetros inválidos. Nesses casos você pode dar um comando de “retire” individualmente por assinatura. Lembre que fizemos isso para uma categoria inteira na config do IPS via CLI. Seguem os comandos ao lado: R1(config)#ip ips signature-definition R1(config-sigdef)#signature 3124 0 R1(config-sigdef-sig)#status R1(config-sigdef-sig-status)#retired true R1(config-sigdef-sig-status)#

Você ainda pode alterar as ações que o IPS deverá tomar caso o tráfego entrante seja compatível com uma assinatura de ataque tanto pela categoria como por assinatura. Acompanhe nos comandos a seguir. Alterando para uma assinatura específica: R1(config)#ip ips signature-definition R1(config-sigdef)#signature 3124 0 R1(config-sigdef-sig)#engine R1(config-sigdef-sig-engine)#event-action produce-alert R1(config-sigdef-sig-engine)#event-action deny-packet-inline R1(config-sigdef-sig-engine)#event-action reset-tcp-connection R1(config-sigdef-sig-engine)#

Alterando para uma categoria (basic): router(config)#ip ips signature-category router(config-ips-category)# category ios-ips basic router(config-ips-category-action)# event-action produce-alert router(config-ips-category-action)# event-action deny-packet-inline router(config-ips-category-action)# event-action reset-tcp-connection router(config-ips-category)# exit Do you want to accept these changes? [confirm]y router(config)#

Existem outros parâmetros que podem ser configurados como ação, o exemplo acima ilustra a utilização de apenas 3 tipos.


   

 

 



   

    

   



Página 267

 

 

  


6.1 Modificando as Assinaturas Via CCP - Tunning Via CCP indo em “Configure > Security > Intrusion Prevention”, clicando na aba “Edit IPS” depois clicando em “Signatures” você pode verificar ou editar as assinaturas ou categorias de assinaturas de maneira gráfica e mais simplificada. Basta selecionar a assinatura e clicar no botão Edit. Note que existem diversas categorias de assinaturas e cada uma também com diversas assinaturas, por isso nessa mesma tela existe opções de filtragem dessas assinaturas para que você possa localizar as mais interessantes com maior facilidade.

Temos quatro botões de modificação para utilizar nas assinaturas: Enable: se a assinatura não estiver como retired ele é ativada. As assinaturas marcadas como Enable e Unretire estão sendo utilizadas nas verificações pelo IDS/IPS. Disable: marcada como Retired ou não essa assinatura não está sendo utilizada para as verificações do IPS. Retire: desativa completamente uma assinatura e economiza memória RAM do roteador. Essa assinatura não consome memória nem se for ativada com a opção enable. Unretire: faz com que uma assinatura seja compilada e se ativada fará parte da varredura por ameaças pelo IPS. Essa assinatura vai consumir memória do roteador estando ou não ativada, porém se não estiver ativada (enabled) não será utilizada na varredura por ameaças. 







Se você notar ainda na tela das assinaturas algumas delas estão com um sinalizador verde (estão compiladas e ativas) e outras vermelho (inativas). Podemos dar um Uretire e Enable nas que estão em vermelho, nesse ponto uma marca laranja/amarela/âmbar vai aparecer do lado indicando que é preciso aplicar a alteração no roteador, clicando em Apply Changes essa marca vai desaparecer e a assinatura ficará verde. Outra alteração que podemos fazer está relacionada à ação que a assinatura deve gerar ao detectar um tráfego malicioso. Maioria das assinaturas tem como ação apenas gerar alerta, mas podemos modificar essa ação clicando com o botão direito encima da assinatura e depois na opção Actions. Via IOS IPS temos as seguintes ações possíveis:  

Deny attacker inline. Deny connection inline. A p o s t i l a / E - Bo o k d o C u r s o I I N S 6 4 0 - 5 5 4

     

   

 

 



   

    

   



Página 268

 

 

  

tel 41 3045.7810 - info dltec.com.br - www.dltec.com.br   

Deny packet inline. Produce alert. Reset TCP connection (somente para ataques ao protocolo ou serviços que utilizem TCP).

Veja exemplo na figura a seguir.

Com o botão de Edit você pode alterar as propriedades da assinatura de maneira detalhada e alterar de maneira profunda a assinatura, porém deve-se tomar cuidado ao fazer esse tipo de operação para não causar problemas operacionais futuros. Por exemplo, se você deseja modificar a propriedade da assinatura que define o “Alert Severity” (severidade di alerta) de high para informational nessa tela é possível, veja figura abaixo.


   

 

 



   

    

   



Página 269

 

 

  


Note que o CCP informa o que foi ajustado pelo usuário colocando um losango vermelho na frente do parâmetro, fazendo uma identificação simples e clara para o operador do que foi alterado manualmente. 7

Best Practices no Ajuste Fino de IPSs para Iniciantes 1. Comece com a categoria de assinaturas básicas para verificar quanta memória e CPU o roteador vai utilizar com a ativação do IPS antes de passar para a categoria de assinaturas avançadas. Lembre-se que quanto mais assinaturas mais memória e CPU o roteador utilizará. 2. É interessante agendar tanto instalação como atualizações de assinaturas de IPS para horários alternativos, evitando risco de paradas na rede em horário de produção. 3. Retire as assinaturas que são irrelevantes para a sua rede para economizar recursos no roteador. 4. Monitore a memória livre para garantir que você não causar danos ao seu roteador ou causando sobrecarga com serviços adicionais. 5. Existem opções disponíveis que podem dizer ao roteador para não encaminhar todo o tráfego através de uma interface IPS protegida se algum tipo de problema fizer com que a assinatura não seja compilada, ou seja, para que ele atue como fail-closed. A outra opção (fail-open) faz com que se um problema com as assinaturas do IPS ocorra, mesmo assim o roteador deverá encaminhar o tráfego. Essa é uma decisão da política de segurança da empresa. Lembre-se que apesar de mais seguro, se o roteador estiver configurado como fail-closed ele pode parar a comunicação de rede devido a uma falha do IPS. 6. Cuidado antes de dar um unretire e permitir a categoria todas as assinaturas ( allsignatures), pois isso pode causar sérios problemas de desempenho no roteador.

Sobre o item 5 existe no CCP uma página para configurar o roteador como fail-open ou failclosed em “Configure > Security > Intrusion Prevention” clicando em “Global Settings” e depois indo na aba Global Engine, conforme figura abaixo.


   

 

 



   

    

   



Página 270

 

 

  


8 Gerenciando e Monitorando Alertas de Segurança do IPS Para manter o IPS e verificar status e configurações utilize os seguintes comandos show:  









show ip ips all – mostra todas as configurações do IPS; show ip ips configuration – mostra as configurações adicionais que não são mostradas no comando show running-config; show ip ips interfaces – mostra os dados relacionados às interfaces configuradas para análise via IPS; show ip ips signatures – verifica as configurações e parâmetros relacionados às assinaturas; show ip ips statistics – mostra o número de pacotes auditados, alarmes gerados e outras estatísticas; show ip sdee alerts: mostra os eventos do SDEE via CLI.

Além dos comandos via CLI você pode monitorar o IPS utilizando o CCP através das seguintes telas: 



Monitor > Security > IPS Status clicando na aba IPS Signature Statistics: mostra informações sobre o número total de assinaturas, quantas estão enabled, retired e compiled.

Monitor > Security > IPS Status clicando na aba IPS Alert Statistics: mostra mensagens individuais sobre os alertas, incluindo o risk rating.


   

 

 



   

    

   



Página 271

 

 

  




Monitor > Router > Logging clicando na aba SDEE Message Log: inclui um time stamp para os alertas (quando ocorretu), tipo (se é uma entrada de estado ou realmente um alerta), event ID, signature ID, risk rating e outras informações sobre os alarmes de segurança.

Lembre que o CCP comunica-se com os roteadores utilizando o SDEE somente através do protocolo HTTP ou HTTPS.


   

 

 



   

    

   



Página 272

 

 

  


9 Conclusão: “O que o IOS IPS pode fazer?” Vamos resumir as capacidades de um roteador com o recurso de sensor IPS/IDS ativado, pois temos que lembrar que ele não fará tudo que os appliances 4200 são capazes de fazer. Primeiro sobre as tecnologias de detecção que o IOS-based IPS suporta são: Profile based Signature based Protocol analysis based   

Ele não suporta o anomaly-based detection. Quais são os benefícios de utilizar um roteador como IPS/IDS? Pode ser configurado com updates dinâmico de assinaturas. Integra facilmente com a rede existente, por exemplo, você pode ativar o recurso em um roteador situado em uma Unidade Remota sem a necessidade de comprar um novo hardware. Compatível com outros recursos de segurança como Zone-Based Firewalls (ZBF) , virtual private network (VPN), access control lists (ACL), AAA e outros recursos, claro que depende da capacidade de memória e CPU de cada roteador. Facilidades de gerenciamento remoto via Cisco Configuration Professional (CCP) , IPS Manager Express (IME) e Cisco Security Manager (CSM), além da CLI. Suporta assinaturas de ataque da mesma base de dados que os IPS appliances utilizam, ou seja, uma assinatura do 4200 pode ser utilizado em um roteador com Cisco IOS IPS.  







Além disso, o Cisco IOS IPS suporta também sumarização de alarmes, risck rating, as técnicas antievasão citadas anteriormente, configuração de limiares para geração de alertas (Threshold), uso de expressão regular para fazer a verificação de textos (strings) em pacotes no reconhecimento de padrões de ataques e a configuração de diferentes respostas aos ataques, conforme estudamos na implementação via CLI e CCP. 10 Resumo do Capítulo Bem pessoal, chegamos ao final do capítulo. É muito importante que nesse ponto do curso você tenha domínio dos seguintes itens: Definição de detecção e prevenção de intrusão de rede versus de um host. Explicar as tecnologias de IDS e IPS Respostas aos ataques e opções de monitoramento. Implementação de IPS via CLI e CCP. Principais opções de dispositivos IPS e IDS Cisco.     


   

 

 



   

    

   



Página 273

 

 

  


Capítulo 9 - Sistemas Criptográficos e PKI

O objetivo desse capítulo é o estudo dos sistemas criptográficos, base para realizar a comunicação segura em um meio não confiável.

Objetivos do Capítulo Ao final desse capítulo você terá estudado e deverá compreender: Explicar os diferentes métodos de criptografia. Explicar os princípios do PKI. Explicar o que é um CA e como configurar um ASA como CA Server. 

Além disso, estudaremos conceitos sobre public key infrastructure (PKI) e certificate authority (CA), inclusive como ativar o recurso no ASA.

 



   

 

 



   

    

   



Página 274

 

 

  


6.1


Histórico dos Inventores do DH____ 301

6.2 Algoritmo Diffie-Hellman – Troca de Chaves _____________________________ 302

Introdução _____________________ 276

7 Assinatura Digital – Digital Signature 303

2 Criptografia – Histórico, Terminologia e Conceitos__________________________ 278

8 Criptografia Simétrica Versus Assimétrica _______________________ 305

3

4

Integridade de Dados - Funções de Hash 281

3.1

Integridade com MD5____________ 283

3.2

Integridade com SHA ____________ 285

Autenticidade com HMAC _________ 286

5 Introdução à Confidencialidade Criptografia _______________________ 287

5.1

Chaves Simétricas _______________ 288

5.2

Chaves Assimétricas _____________ 290

5.3

Que algoritmo de criptografia escolher? 292

5.4

Data Encryption Standard (DES) ___ 293

5.5

Triple Data Encryption Standard – 3DES 294

5.6

Advanced Encryption Standard - AES 296

5.7 Software-optimized Encryption Algorithm (SEAL) _____________________ 299 5.8

Série de Algoritmos RC ___________ 299

5.9 Algoritmo RSA - Rivest, Shamir e Adleman____________________________ 300

8.1

IPSec _________________________ 306

8.2

SSL e TLS ______________________ 306

8.3

PGP __________________________ 306

8.4

S/MIME ______________________ 306

8.5

SET __________________________ 306

8.6

X.509_________________________ 306

9 Gerenciamento das Chaves Criptográficas _____________________ 307 10

Public Key Infrastructure – PKI ___ 309

10.1

Campos do Certificado Digital ___ 311

10.2 Introdução às Autoridades Certificadoras - CA ___________________ 312 10.3

Padrões de PKI _______________ 313

10.4 Autoridades Certificadoras Topologias __________________________ 316 10.5

Uso do PKI na Prática __________ 318

10.6 Exemplo de Configuração de PKI – CA Server 319 11

Resumo do Capítulo ___________ 322

6 Algoritmo Diffie-Hellman – Troca de Chaves ____________________________ 300


   

 

 



   

    

   



Página 275

 

 

  


1 Introdução Até agora estudamos como proteger os dispositivos de rede, como roteadores, switches, computadores e servidores através da implementação de ACL’s, firewall, técnicas de reforço na segurança dos dispositivos Cisco, IPS/IDS, uso do AAA e outras ferramentas. Uma vez que sua infraestrutura está segura, ou seja, da sua empresa para dentro, precisamos pensar nos funcionários, usuários, parceiros de negócio e demais pessoas que estão fora da empresa e precisam acesso à rede interna, pois normalmente esse tipo de acesso é realizado através da Internet e sem garantia de privacidade. Esse é o objetivo desse e do próximo capítulo do curso, estudar a teoria atrás das VPNs e sua implementação nos equipamentos Cisco. Veja a figura a seguir.

Perceba que para fornecer acesso aos usuários de escritórios externos ou em home-office é necessário passar os dados pela Internet e o tráfego entre esses usuários e a rede Interna deve ser seguro. Por esse motivo devem ser tomadas medidas para garantir que o tráfego não possa ser alterado, falsificado ou decifrado/decodificado se for interceptado quando passar pela Internet, o qual é um meio inseguro para envio de informações corporativas. A criptografia e formação de túneis seguros tem esse papel de proteger os dados através de quatro objetivos principais: 

Confidencialidade da mensagem: só o destinatário autorizado deve ser capaz de extrair o conteúdo da mensagem da sua forma cifrada. Além disso, a obtenção de informação sobre o conteúdo da mensagem (como uma distribuição estatística de certos caracteres) não deve ser possível, uma vez que, se o for, torna mais fácil a análise criptográfica.


   

 

 



   

    

   



Página 276

 

 

  






Integridade da mensagem: o destinatário deverá ser capaz de determinar se a mensagem foi alterada durante a transmissão. Autenticação do remetente: o destinatário deverá ser capaz de identificar o remetente e verificar que foi mesmo ele quem enviou a mensagem. Não-repúdio ou anti-reply do emissor: não deverá ser possível ao emissor negar a autoria da mensagem.

Nem todos os sistemas ou algoritmos criptográficos são utilizados para atingir todos os objetivos listados acima. Normalmente, existem algoritmos específicos para cada uma destas funções. Mesmo em sistemas criptográficos bem concebidos, bem implementados e usados adequadamente, alguns dos objetivos acima não são práticos (ou mesmo desejáveis) em algumas circunstâncias. Por exemplo, o remetente de uma mensagem pode querer permanecer anônimo, ou o sistema pode destinar-se a um ambiente com recursos computacionais limitados. Portanto, ao longo desse capítulo estudaremos um pouco da história da criptografia, técnicas, conceitos e tecnologias, estudo que servirá como base para sua aplicação prática no capítulo seguinte onde realizaremos a implementação dos conceitos através de uma VPN.


   

 

 



   

    

   



Página 277

 

 

  


2 Criptografia – Histórico, Terminologia e Conceitos A palavra criptografia vem do grego kryptos (em português, escondido) + grafo (grafia, escrita): arte ou ciência de escrever em cifra ou código. Em outras palavras, é um conjunto de técnicas que permitem tornar incompreensível uma mensagem originalmente escrita com clareza, permitindo que apenas o destinatário a decifre e compreenda. Uma ciência muito antiga, a criptografia já estava presente no sistema de escrita hieroglífica dos egípcios há quase quatro mil anos. Desde então vem sendo muito utilizada, principalmente para fins militares, diplomáticos e inclusive amorosos. Quase sempre o ato de decifrar uma mensagem requer uma chave, uma informação secreta disponível ao destinatário. Terceiros podem através de uma "escuta" ter acesso a mensagem cifrada e determinar o texto original ou mesmo a chave, quebrando o sistema. Uma das primeiras técnicas documentadas foi utilizada na Grécia antiga, a qual possuía um sistema de cifra chamado SCYTALE. O scytale era um bastão confiado aos generais lacedemônios para sua correspondência militar. Enrolava-se em torno desse bastão uma estreita tira de papiro e escrevia-se nela, assim enrolada em linha reta, ao longo do bastão. Uma vez desenrolada, a escrita não tinha sentido e só podia tê-lo enrolada em um bastão perfeitamente igual.

Outro método de criptografia antigo muito conhecido foi a Cifra de César, também conhecida como cifra de troca, código de César ou troca de César. Trata-se de uma das mais simples e conhecidas técnicas de criptografia. É um tipo de cifra de substituição na qual cada letra do texto é substituída por outra, que se apresenta no alfabeto abaixo dela um número fixo de vezes. Por exemplo, com uma troca de três posições, A seria substituído por D, B se tornaria E, e assim por diante. O nome do método é em homenagem a Júlio César, que o usou para se comunicar com os seus generais. Veja a figura a seguir.


   

 

 



   

    

   



Página 278

 

 

  


Utilizando o exemplo da figura veja como ficaria o alfabeto com o código de César: Normal: ABCDEFGHIJKLMNOPQRSTUVWXYZ Cifrado: DEFGHIJKLMNOPQRSTUVWXYZABC Vamos ver um exemplo de mensagem cifrada: Normal: a ligeira raposa marrom saltou sobre o cachorro cansado Cifrado: D OLJHLUD UDSRVD PDUURP VDOWRX VREUH R FDFKRUUR FDQVDGR Como você pode notar, cada um desses métodos de criptografia utiliza seu próprio algoritmo, chamado cifragem, para critografar e decriptografar as mensagens. Cada processo de cifragem define os passos bem definidos para realizar a tarefa de cifrar e decifrar as mensagens. Outro campo de estudo relacionado a criptografia é a criptoanálise (analisys = decomposição). A criptoanálise é a arte de se tentar descobrir o texto cifrado e/ou a lógica utilizada em sua encriptação (chave). As pessoas que participam desse esforço são denominadas criptoanalistas. Como não há um meio matemático de se provar que esse algoritmo é ou não é seguro, então ele é seguro até que se consiga decodifica-lo. Essa segurança dura até que alguém consiga descobrir um método de decodificação. A grande dificuldade que um criptoanalista encontra ao tentar quebrar um algoritmo está no número de chaves que esse utiliza. Quanto maior o número de chaves, maior a dificuldade de se conseguir obter sucesso na criptoanálise de um determinado sistema. Uma variedade de técnicas pode ser utilizada por um criptoanalista para tentar quebrar uma determinada cifra. Abaixo seguem alguns métodos utilizados. 









Ataque por texto ilegível: Um ataque por texto ilegível ocorre quando algum criptoanalista consegue obter o texto legível simplesmente estudando o texto criptografado. Esse tipo de ataque consegue quebrar algoritmos baseados no método da monosubstituição ( 1 = 1+x, 2 = 2+x), e atualmente só serve para resolver problemas de desafios em revistas de palavra cruzadas. Usa-se nesse tipo de ataque a frequência com que as letras ocorrem. Por exemplo, a letra "a" ocorre com mais frequência na lingua portuguesa, então se no texto criptografado ocorrer mais a letra "b", pode-se deduzir que a letra "b" corresponde a letra "a". Ataque por combinação: Esse tipo de ataque ocorre quando um criptoanalista consegue obter alguma parte do texto legível e alguma do texto ilegível. Com essas combinações ele pode chegar a alguma conclusão do método criptográfico. Esse tipo de "ataque" é muito utilizado para resolver desafios de revistas de palavras cruzadas também. Ataque por encriptação: Um criptoanalista, tendo acesso a chave de codificação, encripta um texto qualquer, e utiliza o método da combinação para tentar descobrir algum texto encriptado. Ou então, pode-se utilizar uma espécie de comparação. Na comparação, encripta-se vários textos aleatoriamente, comparando os textos encriptados. Vários "cracks" de senha utilizam essa técnica. Eles pegam um dicionário e encriptam cada palavra dele, até encontrar algum que contenha o mesmo texto criptografado da senha desejada. Meet-in-the-middle: É um ataque a sistemas criptográficos que permite reduzir a robustez de sistemas que utilizam um algoritmo duas vezes, como por exemplo, o Double DES. Análise de frequência: É um método empregado para decifrar mensagens criptografadas por meio da análise, no texto criptografado, de padrões que se repetem constantemente, que podem indicar a ocorrência de letras ou de palavras de uso A p o s t i l a / E - Bo o k d o C u r s o I I N S 6 4 0 - 5 5 4

     

   

 

 



   

    

   



Página 279

 

 

  


corriqueiro, tais como preposições ("de", "da"), pronomes, ("não", "sim"), etc. Veja a figura a seguir.

Da fusão da criptografia com a criptoanálise, forma-se a criptologia. A criptologia é a disciplina científica que reúne e estuda os conhecimentos (matemáticos, computacionais, psicológicos, filológicos, etc.) e técnicas necessárias à criptoanálise (solução de criptogramas) e à criptografia (escrita codificada). A história da criptologia teve um marco importante com o descoberta da criptografia assimétrica que permitiu uma mudança de enfoque da criptografia que antes buscava garantir a confidencialidade das informações e, a partir de então, pode se preocupar também com a integridade, autenticidade e a irretratabilidade das mensagens. Outro termo bastante falado quando tratamos desse assunto é a esteganografia (do grego "escrita escondida"), a qual é o estudo e uso das técnicas para ocultar a existência de uma mensagem dentro de outra. Em outras palavras, esteganografia é o ramo particular da criptologia que consiste em fazer com que uma forma escrita seja camuflada em outra a fim de mascarar o seu verdadeiro sentido. É importante frisar a diferença entre criptografia e esteganografia. Enquanto a primeira oculta o significado da mensagem, a segunda oculta a existência da mensagem. Um exemplo básico de técnica moderna de esteganografia é a alteração do bit menos significativo de cada pixel de uma imagem colorida de forma a que ele corresponda a um bit da mensagem. Essa técnica, apesar de não ser ideal, pouco afeta o resultado final de visualização da imagem.


   

 

 



   

    

   



Página 280

 

 

  


3 Integridade de Dados - Funções de Hash Quando falamos sobre integridade de dados temos que falar sobre o hash. Uma função hash é uma equação matemática que utiliza texto (tal como uma mensagem de email) para criar um código chamado message digest (resumo de mensagem ou digesto da mensagem). Alguns exemplos conhecidos de funções hash são o MD4 (MD significa message digest), MD5 e SHA. São chamadas de funções unidirecionais, pois você pode criar um hash a partir de uma entrada, mas é praticamente impossível recriar a mensagem a partir desse valor. As funções de hash (funções one-way hash – sentido único ou unidirecional) descrevem uma ampla classe de algoritmos criptográficos com um objetivo comum: produzir uma " impressão digital" dos dados de entrada com comprimento fixo. Diferentemente das funções de criptografia algoritmos de hash retornam sempre um valor de saída de comprimento fixo, independente do tamanho da entrada. O comprimento da saída dependente apenas da função ou algoritmo específico que foi utilizado. Veja a figura a seguir.

O tamanho do MD (message digest) depende do algoritmo escolhido (MD1, MD2, ..., MD5 ou SHA1), que é medido em bits, por exemplo, o SHA1 é o mais recente dentre estes anteriores e gera um hash de 160 bits. A principal aplicação para as funções de hash é a de verificar a integridade dos dados, por exemplo, uma função de hash pode ser utilizada para determinar se um documento eletrônico (arquivo de processador de texto, email, etc) foi alterado. A segurança ou "força" de uma função hash tem origem no "one-way" ou “sentido único” da natureza do algoritmo, ou seja, é fácil de calcular um valor de hash para uma dada entrada, mas é extremamente difícil obter uma entrada que irá produzir um especificado valor de hash. Um exemplo clássico utilizado para ilustrar o que a função de hash produz é comparar com um moedor de café ou de carne, você consegue moer facilmente o café, porém é muito difícil a partir das pequenas partes moídas remontarem os grãos que foram moídos. Esse é o princípio do hash unidirecional ou one-way.


   

 

 



   

    

   



Página 281

 

 

  


Uma função hash utilizada para autenticação digital deve ter certas propriedades que a tornem segura para uso criptográfico, principalmente deve ser impraticável encontrar: 



O Texto que dá um hash a um dado valor. Ou seja, mesmo que você conheça o MDmessage digest, não conseguirá decifrar a mensagem. Duas mensagens distintas que dão um hash ao mesmo valor.

A capacidade de descobrir uma mensagem que dê um hash a um dado valor possibilita a um agressor substituir uma mensagem falsa por uma mensagem real que foi assinada. Permite ainda que alguém rejeite de forma desleal uma mensagem, alegando que, na realidade, ele ou ela assinou uma mensagem diferente, dando um hash ao mesmo valor e violando assim a propriedade de não-repúdio das assinaturas digitais. A capacidade de descobrir duas mensagens distintas que apresentem um hash ao mesmo valor possibilita um tipo de ataque no qual alguém é induzido a assinar uma mensagem que dá um hash ao mesmo valor como sendo outra mensagem com um conteúdo totalmente diferente. É importante lembrar que o hash não fornece segurança na transmissão das informações, porém pode garantir a integridade dessa informação. Por exemplo, você pode ter um determinado arquivo para download em um site e como dono desse arquivo você faz um cálculo com uma função de hash e publica esse valor. Quando um usuário baixar o arquivo para seu micro, antes de utilizar a informação ele pode fazer o cálculo do valor de hash utilizando a mesma ferramenta ou função de hash e comparar com o valor publicado no site. Se os valores são iguais é sinal que o arquivo é íntegro, caso os valores sejam diferentes houve algum problema que corrompeu o arquivo e o usuário deve refazer o download. A função de hash criptográfico é aplicada em muitas outras situações diferentes: 





Para prova da autenticidade quando é usada com uma chave de autenticação secretas simétricas, como o IP Security (IPSec) ou autenticação do protocolo de roteamento. Para oferecer autenticação gerando “one-time” e “one-way” aos desafios nos protocolos de autenticação, como o PPP Challenge Handshake Authentication Protocol (CHAP). Para enviar uma mensagem à prova de verificação de integridade, tais como os utilizados nos contratos assinados digitalmente e infraestrutura de chaves públicas (PKI).


   

 

 



   

    

   



Página 282

 

 

  


3.1 Integridade com MD5 O MD5 (Message-Digest algorithm 5) é um algoritmo de hash de 128 bits unidirecional desenvolvido pela RSA Data Security, Inc., descrito na RFC 1321, e muito utilizado por softwares com protocolo ponto a ponto (P2P, ou Peer-to-Peer, em inglês) na verificação de integridade de arquivos e logins. Foi desenvolvido em 1991 por Ronald Rivest para suceder ao MD4 que tinha alguns problemas de segurança. Por ser um algoritmo unidirecional, um hash MD5 não pode ser transformado novamente no texto que lhe deu origem. O método de verificação é, então, feito pela comparação dos dois hashs (um da mensagem original confiável e outro da mensagem recebida). O MD5 também é usado para verificar a integridade de um arquivo através, por exemplo, do programa “MD5 Check Utility” (MD5.exe) disponível na biblioteca da "Área do aluno" na pasta Programas, que cria o hash de um arquivo. Isto pode se tornar muito útil para downloads de arquivos grandes, para programas P2P que constroem o arquivo através de pedaços e estão sujeitos a corrupção dos mesmos. Como autenticação de login é utilizada em vários sistemas operacionais unix e em muitos sites com autenticação. Esse processo é recomendado ao baixar um IOS de um roteador, a Cisco publica o hash MD-5 dos IOS’s para que o usuário que baixou o arquivo possa garantir que ele não foi corrompido durante o processo de download do site. Veja a figura a seguir.

Veja na figura a seguir a tela de comparação utilizando o software citado anteriormente. Você deve inserir o MD5 hash que foi publicado no site da Cisco e abaixo inserir o caminho do arquivo que está no seu computador a ser comparado. Após a comparação o MD5 checker vai dar uma mensagem se os códigos são os mesmos ou não.


   

 

 



   

    

   



Página 283

 

 

  


Com o comando no roteador ou switch em modo privilegiado “verify” você pode conferir também o hash MD-5 do arquivo baixado, e assim utiliza-lo para comparar com o que a Cisco publicou, se for diferente refaça o download porque seu IOS está corrompido. Veja o exemplo do comando abaixo: Router# verify /md5 disk1: Verify filename []? c7200-js-mz .................................. .................................. .................................. .................................. .................................. ...............................Done! verify /md5 (disk1:c7200-js-mz) = 0f369ed9e98756f179d4f29d6e7755d3

O valor “0f369ed9e98756f179d4f29d6e7755d3” é o hash MD-5 calculado pelo comando verify. O algoritmo principal do MD5 é baseado em uma função de compressão, que opera em blocos, ou seja, a entrada é um bloco de dados mais um feedback dos blocos anteriores. O MD5 utiliza como entrada blocos de 512 bits, os quais são divididos em 16 sub-blocos de 32 bits. Esses blocos são então rearranjados com operações simples em um loop principal que consiste em quatro rodadas. A saída do algoritmo é um conjunto de quatro blocos de 32 bits que são concatenados para formar um único valor de hash de 128 bits. O tamanho da mensagem também está codificado no digesto da mensagem (message digest). Veja a figura a seguir.


   

 

 



   

    

   



Página 284

 

 

  


Pelo fato do MD5 ter sido baseado no MD4, o qual já foi quebrado, e devido a falhas consideradas não críticas ele não é considerado o mais seguro dos Hashs. Para aumentar a segurança de alguns sistemas usa-se a tática de adicionar um texto fixo no texto original a ser criptografado, chamado de sal (salt em inglês). Deste modo se o sal for "wiki" e a senha for "1234", a pseudo-senha poderá ser "wiki1234" e assim mesmo que alguém tenha o MD5 de 1234 por ser uma senha comum ela não terá de wiki1234. Porém caso o "sal" seja simples como no exemplo e houver o MD5 de "wiki1234" é possível descobrir o sal e deste modo decriptografar as senhas mais comuns. 3.2 Integridade com SHA Já o SHA-1 (Secure Hash Algorithm - Algoritmo Hash Seguro) foi aprovado pelo governo dos EUA em 1995 para ser usado por todos os departamentos e agências federais na autenticação de documentos digitais. Partindo de uma mensagem menor do que 264 bits, o SHA-1 produz uma saída de 160 bits chamada de digesto da mensagem. Este digesto pode ser, por exemplo, a entrada para o DSA (Digital Signature Algorithm - Algoritmo de Assinatura Digital), o qual gera ou faz a verificação da assinatura da mensagem. Apesar de ligeiramente mais lento que o MD5 o SHA-1 tem um digesto da mensagem ou message digest maior, tornando-o mais seguro contra ataques de colisão por força bruta e inversão. Desde então quatro variantes foram lançadas com capacidades de saída aumentadas e um design ligeiramente diferente: SHA-224, SHA-256, SHA-384, e SHA-512 — algumas vezes chamadas de SHA-2. Essas versões são mais seguras, por terem hashs maiores, porém ainda não estão padronizadas. Comparando o SHA-1 e o MD5:   



O SHA-1 é completado em 80 passos e o MD5 em 64. O SHA-1 gera um hash de 160 bits e o MD5 com 128 bits. O MD5 é geralmente processado mais rapidamente em um mesmo equipamento em comparação com o SHA-1. O SHA-1 é mais seguro que o MD5.


   

 

 



   

    

   



Página 285

 

 

  


Veja abaixo a comparação entre os hashs para um mesmo arquivo de imagem:    



MD5: 4bd562ca4abaf7dfc1efdd791bc3aaf6 SHA1: 4b2d988edc00d3e1701ed33514bf8bb40c116ce1 SHA256: b7c7f8611b01bf36a6758c6c4f39a9f4c4ef6634757ddf0a9a709457beabe1c9 SHA384: 52de6e664bfc8d3e54ffc130422d3729dc4d4b00adbdc706f5d98e4276ee01acf1e5802cf05 735e32771e02d32fc83c5 SHA512: cdb9828545df7972df63e19e3a11fa218b9b6c1d926b42940a3650eae562446e4aa37cd02 79e967e46e58b67b066a157bebd52e7781b16c4386ed84cbdfa0edb

Lembre que quanto maior o hash maior a segurança dele. 4 Autenticidade com HMAC Em criptografia, um autenticador de mensagem (em inglês Message Authentication Code ou MAC) é um pequeno pedaço de informação usado para autenticar a mensagem. Um algoritmo MAC, algumas vezes chamado função de dispersão chaveada (criptografia), em inglês keyed hash function, recebe como entrada uma chave secreta e uma mensagem de tamanho arbitrário para ser autenticado, e dá como saída um MAC (algumas vezes chamada de tag ou etiqueta). O valor do MAC protege tanto a integridade dos dados da mensagem, assim como a sua autenticidade, permitindo aos verificadores (que também possuem a chave secreta) detectar quaisquer mudanças no conteúdo na mensagem. Algoritmos MAC podem ser construídos de outros primitivos criptográficos, como funções criptográficas de dispersão (hash functions), como no caso do HMAC ou de algoritmos de cifra de bloco (OMAC, CBC-MAC e PMAC). No entanto, muitos dos algoritmos mais rápidos MAC como UMAC e VMAC são construídos baseados em hash universal (universal hashing). Veja um exemplo na figura a seguir. Basicamente a mensagem de origem é processada por um hash MD5 ou SHA-1, por exemplo, passado pelo algoritmo MAC com uma chave e quando enviada é acrescentado o MAC. Quando o receptor recebe a mensagem ele recalcula o MAC com sua chave e compara o valor desse resultado com o que foi enviado pelo transmissor, se os valores dos MACs são iguais o dado está íntegro, porém se esses valores forem diferentes indica que houve alteração e o dado não é confiável.


   

 

 



   

    

   



Página 286

 

 

  


Um código de autenticação de mensagem baseado em hash ou keyed-hash message authentication code (HMAC ou KHMAC) pode ser usado, portanto, para determinar se uma mensagem enviada por um canal inseguro foi violada, desde que o remetente e destinatário compartilham uma chave secreta. O remetente calcula o valor de hash para os dados originais e envia os dados originais e o HMAC em uma única mensagem. O receptor recomputa o valor de hash na mensagem recebida e verifica se o valor de hash calculado corresponde ao valor de hash transmitido. HMAC pode ser usado com a função de hash criptográfico iterativa, por exemplo, MD5 ou SHA1, em combinação com uma chave compartilhada secreta. A segurança criptográfica do HMAC depende de das propriedades da função de hash subjacente. Qualquer modificação nos dados ou o valor de hash resulta em uma incompatibilidade, porque é necessário conhecimento da chave secreta para modificar a mensagem e reproduzir o valor de hash correto. Portanto, se os valores de hash calculados na origem coincidirem com o calculado no destino a mensagem são autenticados. Os equipamentos Cisco podem utilizar os seguintes tipos de tecnologia HMAC:  

Keyed MD5 (HMAC-MD5), basedo no algoritmo de hashing MD5 Keyed SHA-1 (HMAC-SHA-1), basedo no algoritmo de hashing SHA-1

As chaves secretas são conhecidas ou compartilhadas na origem e destino, protegendo contra ataques de man-in-the-middle. Redes privadas virtuais (VPNs) via IPsec dependem das funções do HMAC para autenticar a origem de cada pacote e fornecer verificação da integridade dos dados. 5

Introdução à Confidencialidade - Criptografia

Em criptografia, encriptação é o processo de transformar informação usando um algoritmo (chamado cifra) de modo a impossibilitar a sua leitura a todos exceto aqueles que possuam uma informação particular, geralmente referida como chave. O resultado deste processo é a informação encriptada (referida como texto cifrado em criptografia). Em alguns casos, o termo encriptação também se refere implicitamente ao processo inverso, desencriptação (por exemplo “software de encriptação” tipicamente também realiza desencriptação), tornando a informação encriptada novamente legível (isto é, torná-la desencriptada). Todos esses mecanismos são baseados em duas abordagens básicas, proteção do algoritmo e proteção das chaves. Tanto o algoritmo quanto as chaves devem ser seguras e fortemente protegidas. O processo de encriptação pode fornecer serviços de comunicação seguro em diversas camadas do modelo OSI, tais como: 

 



Encriptação de link proprietário na camada-2, fornecida por mecanismos de segurança próprios de determinado fabricante. Segurança na camada de rede, tal como o IPSec. Na camada de transporte e sessão como os protocolos Secure Sockets Layer (SSL) ou Transport Layer Security (TLS). Secure email (email seguro), secure database session (Oracle SQL*net – segurança para o banco de dados) e secure messaging (Lotus Notes – segurança na troca de mensagens) fornecem segurança na camada de aplicação.

Para a proteção das chaves existe dois tipos básicos de algoritmos para proteção das chaves: simétricos e assimétricos. Ambos diferem na maneira que as chaves são utilizadas.


   

 

 



   

    

   



Página 287

 

 

  


5.1 Chaves Simétricas Uma Chave Simétrica é o tipo mais simples de criptografia, já que tanto o emissor quanto o receptor da mensagem possuem a mesma chave, ou seja, a mesma chave é usada tanto na codificação quanto na decodificação, esta chave foi previamente compartilhada (pre-shared key). Para ser realizada, basta que o emissor, antes de enviar a mensagem criptografada, envie a chave privada que será utilizada para descriptografá-la. Veja a figura a seguir.

As chaves simétricas são bastante rápidas, pois dependem apenas de algoritmos com cálculos matemáticos relativamente simples de serem executados pelos dispositivos, por isso são utilizados preferencialmente nas VPNs. Possuem entre 80 e 256 bits e são conhecidas também como “algoritmo de chave compartilhada”. Apesar de sua simplicidade, existem alguns problemas na criptografia simétrica: 





Como cada par necessita de uma chave para se comunicar de forma segura, para uma rede de n usuários precisaríamos de algo da ordem de n^2 chaves, quantidade esta que dificulta a gerência das chaves; A chave deve ser trocada entre as partes e armazenada de forma segura, o que nem sempre é fácil de ser garantido; A criptografia simétrica não garante a identidade de quem enviou ou recebeu a mensagem (autenticidade e não-repudiação).


   

 

 



   

    

   



Página 288

 

 

  


Abaixo segue tabela com exemplos de algoritmos de criptografia simétrica. Algoritmo Simétrico DES

Bits

Descrição

56

Triple DES

112 ou 168

IDEA

128

Blowfish

32 a 448

Série RC

RC2 (40 e 64) RC4 (1 até 256) RC5 (0 até 2040) RC6 (128, 192 e 256)

AES

128, 192 e 256

Software Encryption Algorithm (SEAL)

160

O Data Encryption Standard (DES) é o algoritmo simétrico mais disseminado no mundo. Foi criado pela IBM em 1977 e, apesar de permitir cerca de 72 quadrilhões de combinações (256), seu tamanho de chave (56 bits) é considerado pequeno, tendo sido quebrado por "força bruta" em 1997 em um desafio lançado na Internet. O 3DES é uma simples variação do DES, utilizandoo em três ciframentos sucessivos, podendo empregar um versão com duas ou com três chaves diferentes. O International Data Encryption Algorithm foi criado em 1991 por James Massey e Xuejia Lai e possui patente da suíça ASCOM Systec. O algoritmo é estruturado seguindo as mesmas linhas gerais do DES. Mas na maioria dos microprocessadores, uma implementação porsoftware do IDEA é mais rápida do que uma implementação por software do DES. O IDEA foi utilizado principalmente no mercado financeiro e no PGP, o programa para criptografia de e-mail pessoal muito disseminado no mundo. Algoritmo desenvolvido por Bruce Schneier, que oferece a escolhe entre maior segurança ou desempenho através de chaves de tamanho variável. O autor aperfeiçoou-o no Twofish, concorrente ao AES. Projetado por Ron Rivest (o R da empresa RSA Data Security Inc.) e utilizado no protocolo S/MIME, voltado para criptografia de e-mail corporativo. Também possui chave de tamanho variável. Rivest também é o autor do RC4, RC5 e RC6, este último concorrente ao AES. AES (Advanced Encryption Standard) é rápido tanto em software como em hardware, é relativamente fácil de implementar e requer pouca memória. Como um novo padrão de criptografia, está sendo atualmente implantado em grande escala. Seal é um algoritmo alternativo ao DES, 3DES e AES. Ele usa uma chave de encriptação de 160 bits e tem um impacto menor para a CPU quando comparado com outros algoritmos baseados em software.


   

 

 



   

    

   



Página 289

 

 

  


5.2 Chaves Assimétricas Diferente do método de Chave Simétrica, as Chaves Assimétricas utilizam 2 chaves, uma pública e uma privada. O sistema funciona da forma que alguém cria uma chave e envia essa chave à quem quiser mandar informações à ela, essa é a chamada chave pública. Com ela é feita a codificação da mensagem. Para decodificação será necessário utilizar outra chave que deve ser criada, a chave privada – que é secreta. Veja a figura a seguir.

De uma forma simplificada, o sistema funciona assim: "B" e todos os que desejam comunicarse de modo seguro geram uma chave de ciframento e sua correspondente chave de deciframento. Ele mantém secreta a chave de deciframento, a qual é chamada de sua chave privada. Ele torna pública a chave de ciframento: esta é chamada de sua chave pública. A chave pública realmente condiz com seu nome. Qualquer pessoa pode obter uma cópia dela. "B" inclusive encoraja isto, enviando-a para seus amigos ou publicando-a em boletins. Assim, "E" (atacante da Internet) não tem nenhuma dificuldade em obtê-la. Quando "A" deseja enviar uma mensagem para "B", precisa primeiro encontrar a chave pública dele. Feito isto, ela cifra sua mensagem utilizando a chave pública de "B", despachando-a em seguida. Quando "B" recebe a mensagem, ele a decifra facilmente com sua chave privada. "E", que interceptou a mensagem em trânsito, não conhece a chave privada de "B", embora conheça sua chave pública. Mas este conhecimento não o ajuda a decifrar a mensagem. Mesmo "A", que foi quem cifrou a mensagem com a chave pública de "B", não pode decifrá-la agora. A grande vantagem deste sistema é permitir que qualquer um possa enviar uma mensagem secreta, apenas utilizando a chave pública de quem irá recebê-la. Como a chave pública está amplamente disponível, não há necessidade do envio de chaves como é feito no modelo simétrico. A confidencialidade da mensagem é garantida, enquanto a chave privada estiver segura. Caso contrário, quem possuir acesso à chave privada terá acesso às mensagens. Embora a matematicamente cada algoritmo assimétrico difere um do outro, todos eles partilham uma característica: “os cálculos necessários são complicados”. Seu design é baseado em problemas computacionais, tais como fatorar números muito grandes ou computação logaritmica discreta de números extremamente grandes. Como resultado, o cálculo leva mais tempo para os algoritmos assimétricos que para os simétricos, podendo ser até 1.000 vezes mais lento que algoritmos simétricos. Devido a esse fato os algoritmos assimétricos são


   

 

 



   

    

   



Página 290

 

 

  


normalmente utilizados para trocas de chaves e assinaturas digitais, não para realizar a criptografia de um fluxo de dados, o que deixaria uma VPN, por exemplo, muito lenta. Na tabela a seguir temos exemplos de sistemas de criptografia assimétricos Algoritmo RSA

Descrição O RSA é um algoritmo assimétrico que possui este nome devido a seus inventores: Ron Rivest, Adi Shamir e Len Adleman, que o criaram em 1977 no MIT. É, atualmente, o algoritmo de chave pública mais amplamente utilizado, além de ser uma das mais poderosas formas de criptografia de chave pública conhecidas até o momento. O RSA utiliza números primos. A premissa por trás do RSA é que é fácil multiplicar dois números primos para obter um terceiro número, mas muito difícil recuperar os dois primos a partir daquele terceiro número. Isto é conhecido como fatoração. Por exemplo, os fatores primos de 3.337 são 47 e 71. Gerar a chave pública envolve multiplicar dois primos grandes; qualquer um pode fazer isto. Derivar a chave privada a partir da chave pública envolve fatorar um grande número. Se o número for grande o suficiente e bem escolhido, então ninguém pode fazer isto em uma quantidade de tempo razoável. Assim, a segurança do RSA baseia-se na dificuldade de fatoração de números grandes. Deste modo, a fatoração representa um limite superior do tempo necessário para quebrar o algoritmo.

Uma chave RSA de 512 bits foi quebrada em 1999 pelo Instituto Nacional de Pesquisa da Holanda, com o apoio de cientistas de mais 6 países. Levou cerca de 7 meses e foram utilizadas 300 estações de trabalho para a quebra. Um fato preocupante: cerca de 95% dos sites de comércio eletrônico utilzam chaves RSA de 512 bits. As chaves podem ser de 512 a 2048 bits. ElGamal O ElGamal é outro algoritmo de chave pública utilizado para gerenciamento de chaves. Sua matemática difere da utilizada no RSA, mas também é um sistema comutativo. O algoritmo envolve a manipulação matemática de grandes quantidades numéricas. Sua segurança advém de algo denominado problema do logaritmo discreto. Assim, o ElGamal obtém sua segurança na dificuldade de se calcular logaritmos discretos em um corpo finito, o que lembra bastante o problema da fatoração. As chaves podem ser de 512 ou 1024 bits. Diffie-Hellman Também baseado no problema do logaritmo discreto e o criptosistema de chave pública mais antigo ainda em uso. O conceito de chave pública aliás foi introduzido pelos autores deste criptosistema em 1976. Contudo, ele não permite nem ciframento nem assinatura digital. O sistema foi projetado para permitir a dois indivíduos entrarem em um acordo ao compartilharem um segredo tal como uma chave, muito embora eles somente troquem mensagens em público. As chaves podem ser de 512, 1024 a 2048 bits. Digital DSS foi criado pelo NIST e especifica o algoritmo DSA para assinaturas Signature digitais. DSA é um algoritmo de chave pública com base no esquema de Standard assinatura ElGamal. Essa velocidade de criação da assinatura é semelhante (DSS) e Digital ao RSA, mas é de 10 a 40 vezes mais lenta para a verificação. Pode utilizar Signature chaves de 512 a 1024 bits. Algorithm (DSA)


   

 

 



   

    

   



Página 291

 

 

  


Curvas Elípticas

Em 1985, Neal Koblitz e V. S. Miller propuseram de forma independente a utilização de curvas elípticas para sistemas criptográficos de chave pública. Eles não chegaram a inventar um novo algoritmo criptográfico com curvas elípticas sobre corpos finitos, mas implementaram algoritmos de chave pública já existentes, como o algoritmo de Diffie e Hellman, usando curvas elípticas. Assim, os sistemas criptográficos de curvas elípticas consistem em modificações de outros sistemas (o ElGamal, por exemplo), que passam a trabalhar no domínio das curvas elípticas, em vez de trabalharem no domínio dos corpos finitos. Eles possuem o potencial de proverem sistemas criptográficos de chave pública mais seguros, com chaves de menor tamanho. Normalmente utilizam chaves de 160 bits. Muitos algoritmos de chave pública, como o Diffie - Hellman, o ElGamal e o Schnorr podem ser implementados em curvas elípticas sobre corpos finitos. Assim, fica resolvido um dos maiores problemas dos algoritmos de chave pública: o grande tamanho de suas chaves. Porém, os algoritmos de curvas elípticas atuais, embora possuam o potencial de serem rápidos, são em geral mais demorados do que o RSA.

5.3 Que algoritmo de criptografia escolher? Analisando o que estudamos até o momento vem uma pergunta: “ como escolher que algoritmo ou tipo de criptografia utilizar?”. Para responder a essa questão algumas perguntas devem ser realizadas para escolha da melhor tecnologia a ser utilizada como solução de criptografia e troca de chaves: 1. O algoritmo é reconhecido e confiável perante a comunidade de estudos relativos à criptografia? Basicamente você deve verificar se o algoritmo é realmente confiável e reconhecido pela comunidade de criptografia. O DES, 3DES, IDEA, RC4, AES, RSA e o Diffie-Hellman são considerados confiáveis. 2. O algoritmo protege eficazmente os dados contra ataques de força bruta? O 3DES é muito melhor que o DES, por exemplo, pois o DES já foi quebrado. 3. O algoritmo suporta diferentes tipos de tamanho de chaves e é escalável? Sua infraestrutura deve permitir adaptações e crescimento sem necessidade de uma nova fase de implementação, sem partir do zero. 4. O algoritmo não tem restrições de importação e exportação entre diferentes países ou sistemas? Certifique-se que o sistema criptográfico escolhido é interoperável globalmente e não tem restrições. Vamos a seguir estudar um pouco mais sobre os principais algoritmos de criptografia utilizados.


   

 

 



   

    

   



Página 292

 

 

  


5.4 Data Encryption Standard (DES) DES é tipo de algoritmo simétrico por bloco, ou seja, um algoritmo que toma uma string de tamanho fixo de um texto plano e a transforma, através de uma série de complicadas operações, em um texto cifrado de mesmo tamanho. No caso do DES, o tamanho do bloco é 64 bits. O DES também usa uma chave para personalizar a transformação, de modo que a descriptografia somente seria possível, teoricamente, por aqueles que conhecem a chave particular utilizada para criptografar. A chave tem 64 bits, porém somente 56 deles são realmente utilizados pelo algoritmo. Os oito bits restantes são utilizados para verificar a paridade e depois são descartados, portanto o tamanho efetivo da chave é de 56 bits, e assim é citado o tamanho de sua chave. Além disso, desses 56 bits, 40 são utilizados para a chave secreta e 16 são conhecidos, o que torna o DES um algoritmo de 40 bits efetivamente utilizados como chave de segurança. O DES foi estudado academicamente e motivou os sistemas modernos de entendimento da criptoanálise, sendo padronizado em 1976. O DES é atualmente considerado inseguro para muitas aplicações. Isto se deve principalmente a pequena chave de 56-bit. Em Janeiro de 1999 a distributed.net e a Electronic Frontier Foundation juntas violaram uma chave DES em 22 horas e 15 minutos. Também existem alguns resultados analíticos, obtidos teoricamente, que demonstram a fragilidade da cifra, no entanto são improváveis de se montar na prática. Acredita-se que o algoritmo seja seguro na forma de 3DES embora existam ataques teóricos. O DES pode operar com dois tipos de cifras: 



Block Cipher ou cifras de bloco – utilizando o Electronic Code Book (ECB) e Cipher Block Chaining (CBC), cada um com blocos de 64 bits encriptados utilizando chaves de 56 bits. As cifras de bloco operam em blocos de tamanho fixo, geralmente de 64 ou 128 bits. Para cifrar mensagens cujo comprimento ultrapasse o tamanho do bloco, existem vários modos de operação. A maioria apenas confere confidencialidade, porém algumas proporcionam confidencialidade e autenticação. Stream Cipher ou cifras de fluxo – utilizando o Output Feedback (OFB) e Cipher Feedback (CFB). As cifras de fluxo, que convertem o texto claro em texto cifrado bit a bit, ainda são objeto de pesquisa e têm uma aplicação prática muito discreta. O motivo é que as cifras de fluxo dependem de geradores randômicos de chaves que, apesar da aparente simplicidade, são difíceis de implementar através de software ou de hardware.

O modo de operação mais simples é o electronic codebook - ECB (livro de código eletrônico). A mensagem clara é fracionada em blocos de tamanho fixo e cada bloco é cifrado isoladamente. No final, a mensagem cifrada é obtida pela concatenação dos blocos cifrados. O EBC utiliza operações XOR. No modo de operação cipher-block chaining - CBC (corrente de blocos), é feita uma operação XOR entre cada novo bloco de texto claro com o bloco cifrado obtido na etapa imediatamente anterior. Desta forma, cada um dos blocos cifrados depende de todos os blocos de texto claro anteriores, tornando-o mais seguro que o método anterior. Veja a figura a seguir.


   

 

 



   

    

   



Página 293

 

 

  


O DES possui diversas fragilidades, dentre elas 4 chaves fracas e 12 chaves consideradas semifracas. Apesar disso ele é um método considerado rápido e que tem um consumo médio de CPU. 5.5 Triple Data Encryption Standard – 3DES O 3DES (Triplo DES), sigla para Triple Data Encryption Standard, é um padrão de criptografia simétrico baseado em outro algoritmo de criptografia, o DES, desenvolvido pela IBM em 1974 e adotado como padrão em 1977. O 3DES usa 3 chaves de 64 bits, podendo ter um tamanho de 112 e 168 bits. Os dados são encriptados com a primeira chave, decriptados com a segunda chave e finalmente encriptados novamente com uma terceira chave. Isto faz o 3DES ser mais lento que o DES original, porém em contrapartida oferece maior segurança. Em vez de 3 chaves podem ser utilizadas apenas 2, fazendo-se K1 = K3, nesse modo de operação a chave cai para os 112 bits e tem sua força reduzida. A variante mais simples do 3DES opera da seguinte forma: DES(k3;DES(k2;DES(k1;M))), onde M é o bloco de mensagem a ser criptografado e k1, k2 e k3 são chaves DES. Veja a figura a seguir.


   

 

 



   

    

   



Página 294

 

 

  


A implementação da Cisco para o IPsec utiliza o DES e 3DES em modo CBC. O 3DES utiliza um método chamado 3DES-Encrypt-Decrypt-Encrypt (3DES-EDE) para realizar a criptografia do texto claro. Veja a figura a seguir. Note que no processo do 3DES a criptografia é iniciada encriptando o texto com a chave 1 (Key 1), depois desencriptando com a chave 2 (key 2) e por último encriptando novamente com a chave 3 (key 3). No processo de desencriptação o processo é iniciado no caminho inverso, primeiro a chave 3, depois a chave 2 e por último utilizando a chave 1.

Apesar de muito seguro, o 3DES é mais pesado em termos de processamento e por esse motivo o AES foi desenvolvido, pois ele é tão seguro quanto o 3DES, porém mais leve.


   

 

 



   

    

   



Página 295

 

 

  


5.6 Advanced Encryption Standard - AES O Advanced Encryption Standard (AES, ou Padrão de Criptografia Avançada, em português), também conhecido por Rijndael, é uma cifra de bloco adotada como padrão de criptografia pelo governo dos Estados Unidos. Espera-se que seja utilizada em todo o mundo e analisada extensivamente, assim como foi seu predecessor, o Data Encryption Standard (DES). O AES foi anunciado pelo NIST (Instituto Nacional de Padrões e Tecnologia dos EUA) como U.S. FIPS PUB (FIPS 197) em 26 de Novembro de 2001, depois de 5 anos de um processo de padronização. Tornou-se um padrão efetivo em 26 de Maio de 2002. Em 2006, o AES já era um dos algoritmos mais populares usados para criptografia de chave simétrica. Em 1997 o governo americano, através do NIST (National Institute of Standards and Technology), lançou um processo de seleção que definiria um novo algoritmo de chave simétrica para proteger informações do governo federal. Este novo algoritmo criptográfico substituiu o DES (Data Encryption Standard), que havia sido quebrado pela máquina DES Cracker, construída pela ONG Electronic Frontier Foundation com apenas 250 mil dólares. Três anos e meio após o início do concurso, o NIST chega à escolha do vencedor: Rijndael. O nome é uma fusão de Vincent Rijmen e Joan Daemen, os dois belgas criadores do algoritmo. Segundo o NIST, ele combina as características de segurança, desempenho, facilidade de implementação e flexibilidade. O Rijndael apresenta alta resistência a ataques como "power attack" e "timing attack" e exige pouca memória, o que o torna adequado para operar em ambientes restritos como "smart cards", PDAs e telefones celulares. O AES não é exatamente o Rijndael (embora na prática possam ser permutados) já que o Rijndael suporta uma maior gama de tamanhos do bloco e da chave. O AES tem um tamanho de bloco fixo em 128 bits e uma chave com tamanho de 128, 192 ou 256 bits, enquanto o Rijndael pode ser especificado com chaves e tamanhos de bloco de qualquer múltiplo de 32 bits, com um mínimo de 128 bits e um máximo de 256 bits. O tempo estimado para quebrar uma chave AES com um computador de capacidade de processar 255 chaves por segundo, seria de mais de 140 trilhões de anos enquanto o 3DES, considerando o mesmo computador, levaria 4,6 bilhões de anos. Já o DES levaria quase 7 dias para ser quebrado com o mesmo poder de processamento dos casos anteriores. Além dessa característica importante de segurança, o AES é mais leve e mais rápido que o DES e o 3DES. Apesar dessas vantagens o AES é ainda considerado um algoritmo jovem, em comparação com o 3DES que já tem 35 anos de aplicação em campo. O AES opera sobre um arranjo bidimensional de bytes com 4x4 posições, denominado de estado (as versões do Rijndael com um tamanho de bloco maior têm colunas adicionais no estado). Para criptografar, cada turno do AES (exceto o último) consiste em quatro estágios:


   

 

 



   

    

   



Página 296

 

 

  


1. AddRoundKey - cada byte do estado é combinado com a subchave própria do turno (RoundKey); cada subchave é derivada da chave principal usando o algoritmo de escalonamento de chaves.

2. SubBytes - é uma etapa de substituição não linear onde cada byte é substituído por outro de acordo com uma tabela de referência.

3. ShiftRows - é uma etapa de transposição onde cada fileira do estado é deslocada de um determinado número de posições.


   

 

 



   

    

   



Página 297

 

 

  


4. MixColumns - é uma operação de mescla que opera nas colunas do estado e combina os quatro bytes de cada coluna usando uma transformação linear.

5. O turno final substitui o estágio de MixColumns por um novo estágio de AddRoundKey. O AES está disponível nos seguintes dispositivos Cisco VPN:    

IPSec - Cisco IOS versão 12.2(13)T e posteriores Cisco PIX Firewall versão 6.3 e posteriores Cisco ASA software versão 7.0 e posteriores Cisco VPN 3000 software versão 3.6 e posteriores


   

 

 



   

    

   



Página 298

 

 

  


5.7 Software-optimized Encryption Algorithm (SEAL) O software otimizado algoritmo de criptografia ou em inglês Software-optimized Encryption Algorithm (SEAL) é um algoritmo simétrico alternativo ao DES, 3DES e AES. Phillip Rogaway e Don Coppersmith desenvolveram o SEAL em 1993. É uma cifra de fluxo que utiliza uma chave de encriptação de 160 bits. Pelo fato de ser uma cifra de fluxo os dados são criptografados continuamente é, portanto, muito mais rápido do que as cifras de bloco. No entanto, tem uma longa fase de inicialização durante o qual um grande conjunto de tabelas é criada utilizando o SHA. O SEAL tem um impacto menor sobre a CPU em comparação com outros algoritmos baseados em software e foi adicionado no Cisco IOS verão 12.3(7)T, porém SEAL tem várias limitações, dentre elas:  



O roteador Cisco e seus pares remotos devem suportar IPSec. O roteador Cisco seus pares remotos devem executar uma imagem do IOS com o chaves longas k9 (subsistema k9). O roteador e seus pares remotos não devem ter criptografia IPSec baseada em hardware.

5.8 Série de Algoritmos RC Projetado por Ron Rivest (o R da empresa RSA Data Security Inc.) a família RC são algoritmos simétricos utilizados em diversas aplicações de rede. Também possui chave de tamanho variável. Existem diversas versões do protocolo: 







RC2 - Cifra de bloco de tamanho variável que foi concebida como um substituto do DES. Possui chave de 40 e 64 bits e foi lançada em 1987. RC4 - Cifra de fluxo mais utilizado no mundo. Este algoritmo é uma cifra de fluxo Vernam com chave de tamanho variável que geralmente é usado em produtos de criptografia de arquivo e de comunicações seguras, como o SSL. Não é considerado um one-time pad, porque sua chave não é aleatória. A cifra é executada em software, rápida e considerada segura. Embora possa ser implementado de forma insegura, como na Wired Equivalent Privacy (WEP). Possui chave de 1 até 256 bits e foi lançada em 1987. RC5 - Uma cifra de bloco rápida que tem um tamanho de bloco e chave variáveis. O RC5 pode ser usado como um substituto para o DES se o tamanho do bloco for definido com 64 bits. Pode utilizar chave de 0 até 2040 e foi lançada em 1994. RC6 - Desenvolvido em 1997, foi um dos finalistas na competição para definição do AES que o Rijndael ganhou. Trata-se de uma de cifra de bloco com 128, 192 e 256 bits que foi desenvolvido por Rivest, Sidney e Yin. Foi baseado no RC5 e seu principal objetivo foi o de cumprir as exigências da AES. Foi lançada em 1998.


   

 

 



   

    

   



Página 299

 

 

  


5.9 Algoritmo RSA - Rivest, Shamir e Adleman RSA é um algoritmo de criptografia de dados, que deve o seu nome a três professores do Instituto MIT (fundadores da atual empresa RSA Data Security, Inc.), Ronald Rivest, Adi Shamir e Leonard Adleman, que inventaram este algoritmo — até a data (2008), a mais bem sucedida implementação de sistemas de chaves assimétricas, que se fundamenta em teorias clássicas dos números. É considerado dos mais seguros, já que mandou por terra todas as tentativas de quebrá-lo. Foi também o primeiro algoritmo a possibilitar criptografia e assinatura digital, e uma das grandes inovações em criptografia de chave pública. O RSA é uma chave de infra-estrutura pública (PKI) capaz de realizar a criptografia e assinatura digital, sendo um algoritmo de cifras por bloco (Bock Cipher). O tamanho das chaves do RSA não é comparável aos comprimentos dos algoritmos simétricos, por exemplo, uma chave RSA de 1024 bits é considerada igual a uma chave de 80 bits simétrica, uma RSA de 2048 bits é comparada a uma chave de 112 bits e uma RSA de 3072 com uma chave simétrica de 128 bits. Utiliza normalmente chaves de 512 a 2048 bits. Abaixo seguem as principais vulnerabilidades do RSA: 





Ataque de Timing ou Temporização - Um invasor pode medir os tempos de decriptação para uma série de textos de cifras e se o hardware é conhecido a chave de decodificação pode ser deduzida rapidamente. A maioria das implementações RSA usam um esquema conhecido como cegueira ou blinding para parar o tempo de criptografia, o qual está correlacionado com o texto cifrado. Ataque adaptativo por texto cifrado escolhido ou Adaptive chosen cipher text attack – Utiliza vulnerabilidades na RSA/PKCS # 1 quando utilizado em protocolos SSL e é usado para recuperar chaves de sessão. Uma versão atualizada do PKCS # 1 que não é vulnerável a este ataque foi lançada recentemente. Branch Prediction Analysis attack ou ataque BPA - usado em processadores modernos que usam previsão de desvio (Branch Prediction) e multithreading simultânea (SMT - Simultaneous multithreading). Um ataque utiliza um processo de espionagem para estatisticamente descobrir a chave privada quando elas estão sendo processadas com estes modelos de processadores.

6 Algoritmo Diffie-Hellman – Troca de Chaves Diffie-Hellman (DH) é um método de criptografia desenvolvido por Whitfield Diffie e Martin Hellman e publicado em 1976. Antes de 1975 se alguém falasse que seria possível a troca de informações criptografadas entre duas partes sem que houvesse uma troca de chaves secretas entre ambas as partes, provavelmente muitos matemáticos diriam ser impossível. Portanto, o algoritmo Diffie-Hellman foi o primeiro algoritmo assimétrico de chave pública a ser inventado. Isto significa que seus autores também são os donos da ideia. O algoritmo pode ser usado para a distribuição de chaves, mas não para cifrar ou decifrar mensagens. Sua segurança reside na dificuldade de calcular logaritmos discretos num campo finito comparada com a facilidade de realizar exponenciações no mesmo campo. Explicação complicada, concorda? Vale lembrar que o Diffie-Hellman não é um método de encriptação de dados, mas um método de troca segura das chaves que encriptam os dados, que utiliza chaves de 512, 1024 ou 2048 bits. Em sistemas simétricos, os quais estudamos até o momento, ambos os lados conhecem uma chave que foi previamente compartilhada e a troca dessa chave é o grande desafio dessa classe de algoritmo de criptografia. Em um sistema assimétrico esse problema de troca de chaves é resolvido com duas chaves, uma privada, que somente o computador de origem conhece, e uma chave pública, que é aberta e será distribuída. Portanto, o Diffie-Hellman é um algoritmo


   

 

 



   

    

   



Página 300

 

 

  


matemático que permite que dois computadores gerem uma chave compartilhada idêntica em ambos os lados sem ter se comunicado antes. A nova chave compartilhada na verdade nunca é trocada entre a origem e o destino. Esse é o motivo da complexidade matemática desse método e o que garante a segurança desse sistema, pois sua complexidade já é um fator que melhora os aspectos de segurança do Diffie-Hellman. O Diffie-Hellman é normalmente utilizado em VPN IPsec, SSL/TLS e SSH ou quando os dados são trocados pela Internet, porém, como os sistemas de chave assimétrica são extremamente lentos para qualquer tipo de criptografia em massa, muitas vezes os algoritmos simétricos como DES, 3DES ou AES são utilizados para encriptar os dados que serão trocados entre origem e destino, sendo que o algoritmo Diffie-Hellman fica limitado a criar as chaves que serão usadas pelo algoritmo de criptografia. Whitfield Diffie nasceu em Nova Iorque, EUA, em 1944. Desde criança tinha fascínio pela matemática e foi por isto que acabou estudando no MIT - Massachusetts Institute of Technology, formando-se em 1965. Depois disto trabalhou com segurança de computadores até que, em 1970, estava pronto para uma carreira solo - transformou-se num dos poucos especialistas em segurança realmente independente, sem vínculos com o governo ou com grandes corporações. Seus cabelos longos e seu jeito de ser fazem de Diffie uma espécie de hippie da alta tecnologia e, sem dúvida alguma, pode ser considerado o primeiro cypherpunk da história. Um dos problemas que mais chamava a atenção de Diffie era o problema da distribuição de chaves. Acompanhando a evolução da organização de pesquisa ARPA (Advanced Research Projects Agency), fundada pelo Departamento de Defesa dos EUA, a qual, em 1969, criou o sistema de comunicação em rede chamado de ARPANet, Diffie sentia que uma revolução estava prestes a acontecer e que o projeto abria as portas para o desenvolvimento de uma supervia de comunicação. O tempo mostrou que seu prognóstico estava certo (em 1982 nascia a Internet) e que sua preocupação com o sigilo e a privacidade dos usuários de uma grande rede era mais do que justificado. Neste contexto, sabia que a criptografia se transformaria numa ferramenta essencial e que o problema da distribuição de chaves se tornaria especialmente agudo. 6.1 Histórico dos Inventores do DH Em 1974 Diffie foi convidado para dar uma palestra na IBM e o tema, como não poderia deixar de ser, foi sobre as várias estratégias de ataque à distribuição de chaves e propostas para algumas soluções. A reação dos ouvintes não foi das mais calorosas. Os monstros sagrados da IBM, assim como todo mundo, tinham a ideia preconcebida de que este era um problema insolúvel (e não seria um cabeludo que iria mudar as coisas). A única resposta positiva foi a de Alan Konheim, um dos especialistas em criptografia da IBM. Comentou que Martin Hellman, professor da Universidade de Stanford, Califórnia, também havia proferido uma palestra destacando o problema da distribuição de chaves. Foi o que bastou para Diffie atravessar os EUA à procura da pessoa que, aparentemente, era a única que compartilhava suas opiniões.

Whitfield Diffie

Martin Hellman

Martin Hellman nasceu no Bronx, Nova Iorque, EUA, em 1945. Judeu numa vizinhança católica, teve problemas de autoafirmação desde a infância. Ele conta que este foi um dos motivos pelos A p o s t i l a / E - Bo o k d o C u r s o I I N S 6 4 0 - 5 5 4      

   

 

 



   

    

   



Página 301

 

 

  


quais começou a se interessar pela criptografia - já que era diferente, queria ser diferente de vez. Até a inesperada visita de Diffie em 1974, o famoso livro de David Kahn, The Codebreakers, tinha sido o livro de cabeceira e a única fonte de informação de Hellman. Depois de uma meia hora de conversa, um estava impressionado com o conhecimento do outro e perceberam que não estavam mais sozinhos na busca de uma solução "impossível". Apesar das evidentes diferenças de personalidade, este foi o começo de uma grande amizade e companheirismo. Imediatamente começaram a arquitetar um plano para poderem trabalhar juntos. Como Diffie não tinha condições de contratar o novo amigo como pesquisador, Hellman resolveu registrar Diffie como estudante graduado de Stanford. E a peregrinação começou... 6.2 Algoritmo Diffie-Hellman – Troca de Chaves O processo do DH funciona por ambas as partes acordar em dois números não secretos e cada uma das partes gerando um número secreto. Cada uma das partes, em seguida, gera um número público de seu segredo (chave privada) e os dois números não secretos, passando seus números para a outra parte. Cada uma das partes, em seguida, gera um segredo compartilhado a partir do seu próprio número secreto e do número público gerado pela outra parte. Veja os passos da geração da chave abaixo: 1. Ambas as partes concordam em utilizar dois números não secretos chamados “generator” ou “p” e “base” ou “g”. No exemplo utilizaremos p=23 e g=5. 2. O micro 1 escolhe um número secreto inteiro chamado de “a”, onde no exemplo a=6, e envia para o micro 2 o resultado da seguinte expressão modular A=g^a mod p • A = 5^6 mod 23 = 8. 3. O micro 2 escolhe um número secreto inteiro chamado de “b”, onde no exemplo b=15, e envia para o micro 1 o resultado da seguinte expressão modular B = g^b mod p • B = 5^15 mod 23 = 19. 4. Parte 1 calcula s = B^a mod p • 19^6 mod 23 = 2. 5. Parte 2 calcula s = A^b mod p • 8^15 mod 23 = 2. Portanto a chave que será utilizada por ambos para criptografar a mensagem será o “2”. Normalmente o g é um número muito pequeno (2, 3, 4 ou 5) e p é um número primo bastante grande, os quais podem ser retirados de uma tabela de valores pré-definidos. Nessa conta o valor 2 é somente um exemplo, pois a chave normalmente é bem maior e um número mais complexo. Para quem ainda não viu uma função modular ou aritmética modular, simplificadamente, vamos dizer que o módulo (module ou mod) da fórmula é o resto de uma divisão, conforme exemplos abaixo: 43 mod 12 = 43 ÷ 12 = 3 com resto 7 --> 43 mod 12 = 7 59 mod 5 = 59 ÷ 5 = 11 com resto 4 --> 59 mod 5 = 4 Veja na figura a seguir a representação do processo utilizado pelo DH. Quem conseguir espiar a comunicação entre os micros A e B não conseguirá calcular o valor secerto somente com g, p, A e B, os quais são conhecidos e trocados pelo meio de transmissão. Será necessário pelo menos um valor secreto para calcular o segredo compartilhado, a não ser que os atacantes consigam calcular o algoritmo discreto da equação acima para recuperar a e b, eles não conseguirão decifrar o segredo compartilhado.


   

 

 



   

    

   



Página 302

 

 

  


7 Assinatura Digital – Digital Signature Outro benefício da criptografia com chave pública é a assinatura digital, que permite garantir a autenticidade de quem envia a mensagem, associada à integridade do seu conteúdo. Por exemplo, suponha que "A" (origem) queira comunicar o nascimento de sua filha para todos os seus amigos (destinatário = "B"), mas queira garantir aos mesmos que a mensagem foi enviada realmente por ela. E, embora não se importe com o sigilo da mensagem, deseja que a mesma chegue íntegra aos destinatários, sem alterações como, por exemplo, do sexo da criança. "A" então cifra a mensagem com sua chave privada e a envia, em um processo denominado de assinatura digital. Cada um que receber a mensagem deverá decifrá-la, ou seja, verificar a validade da assinatura digital, utilizando para isso a chave pública de "A". Como a chave pública de "A" apenas decifra, ou seja, verifica a validade de mensagens cifradas com sua chave privada, fica garantida assim a autenticidade, integridade e não-repudiação da mensagem. Se alguém modificar um bit do conteúdo da mensagem ou se outra pessoa assiná-la ao invés de "A", o sistema de verificação não irá reconhecer a assinatura digital de "A" como sendo válida. É importante lembrar que a assinatura digital, como descrita no exemplo anterior, não garante a confidencialidade da mensagem. Qualquer um poderá acessá-la e verificá-la, mesmo um intruso ("E"), apenas utilizando a chave pública de "A". Para obter confidencialidade com assinatura digital, basta combinar os dois métodos. "A" primeiro assina a mensagem, utilizando sua chave privada, e em seguida, ela criptografa a mensagem novamente, junto com sua assinatura, utilizando a chave pública de "B". Este, ao receber a mensagem, deve, primeiramente, decifrá-la com sua chave privada, o que garante sua privacidade, logo após "decifrá-la" novamente, ou seja, verificar sua assinatura utilizando a chave pública de "A", garantindo assim sua autenticidade. Veja a figura a seguir.


   

 

 



   

    

   



Página 303

 

 

  


Muitos produtos Cisco utilizam assinaturas digitais, segue um resumo abaixo: 





Gateways IPSec e os clientes usam assinaturas digitais para autenticar suas sessões Internet Key Exchange (IKE), nos casos onde o administrador escolhe os certificados digitais e IKE RSA como método de autenticação de assinatura digital. Endpoints Cisco SSL, tais como servidores HTTP Cisco IOS, o Cisco Adaptive Security Device Manager (ASDM) utilizam assinaturas digitais para provar a identidade do servidor SSL. Alguns dos protocolos de voz para a gestão de billing utilizam assinaturas digitais para autenticar as partes envolvidas.

Veja a seguir a descrição de alguns algoritmos utilizados para assinatura digital. 





RSA: Como já mencionado, o RSA também é comutativo e pode ser utilizado para a geração de assinatura digital. A matemática é a mesma: há uma chave pública e uma chave privada, e a segurança do sistema baseia-se na dificuldade da fatoração de números grandes. ElGamal: Como o RSA, o ElGamal também é comutativo, podendo ser utilizado tanto para assinatura digital quanto para gerenciamento de chaves; assim, ele obtém sua segurança da dificuldade do cálculo de logaritmos discretos em um corpo finito. DSA: O Digital Signature Algorithm, unicamente destinado a assinaturas digitais, foi proposto pelo NIST em agosto de 1991, para utilização no seu padrão DSS (Digital Signature Standard). Adotado como padrão final em dezembro de 1994, trata-se de uma variação dos algoritmos de assinatura ElGamal e Schnorr. Foi inventado pela NSA e patenteado pelo governo americano.


   

 

 



   

    

   



Página 304

 

 

  


8

Criptografia Simétrica Versus Assimétrica

Qual o modelo de criptografia que devemos utilizar? Simétrico ou assimétrico? A resposta é simples: devemos utilizar os dois, em um modelo denominado híbrido, como já citado anteriormente. O algoritmo simétrico, por ser muito mais rápido, é utilizado no ciframento da mensagem em si. Enquanto o assimétrico, embora lento, permite implementar a distribuição de chaves e a assinatura digital. Além disso, como já exposto no item anterior, deve-se utilizar também o mecanismo de Hashing para complemento da assinatura digital. Veja o resumo na tabela a seguir.

Em resumo, os algoritmos criptográficos podem ser combinados para a implementação dos três mecanismos criptográficos básicos: o ciframento, a assinatura e o Hashing. Estes mecanismos são componentes dos protocolos criptográficos, embutidos na arquitetura de segurança dos produtos destinados ao comércio eletrônico. Estes protocolos criptográficos fornecem os serviços associados à criptografia que viabilizam o comércio eletrônico: disponibilidade, sigilo, controle de acesso, autenticidade, integridade e não-repúdio. Abaixo seguem exemplos de protocolos que empregam sistemas criptográficos híbridos.


   

 

 



   

    

   



Página 305

 

 

  


8.1 IPSec Padrão de protocolos criptográficos desenvolvidos para o IPv6. Realiza também o tunelamento de IP sobre IP. É composto de três mecanismos criptográficos: Authentication Header (define a funçãoHashing para assinatura digital), Encapsulation Security Payload (define o algoritmo simétrico para ciframento) e ISAKMP (define o algoritmo assimétrico para gerência e troca de chaves de criptografia). Criptografia e tunelamento são independentes. Permite Virtual Private Network fim-a-fim. Futuro padrão para todas as formas de VPN. 8.2 SSL e TLS Oferecem suporte de segurança criptográfica para os protocolos NTTP, HTTP, SMTP e Telnet. Permitem utilizar diferentes algoritmos simétricos, message digest (hashing) e métodos de autenticação e gerência de chaves (assimétricos). 8.3 PGP Inventado por Phil Zimmermman em 1991, é um programa criptográfico famoso e bastante difundido na Internet, destinado a criptografia de e-mail pessoal. Algoritmos suportados: hashing: MD5, SHA-1, simétricos: CAST-128, IDEA e 3DES, assimétricos: RSA, DiffieHellman/DSS. 8.4 S/MIME O S/MIME (Secure Multipurpose Internet Mail Extensions) consiste em um esforço de um consórcio de empresas, liderado pela RSADSI e pela Microsoft, para adicionar segurança a mensagens eletrônicas no formato MIME. Apesar do S/MIME e PGP serem ambos padrões Internet, o S/MIME deverá se estabelecer no mercado corporativo, enquanto o PGP no mundo do mail pessoal. 8.5 SET O SET é um conjunto de padrões e protocolos, para realizar transações financeiras seguras, como as realizadas com cartão de crédito na Internet. Oferece um canal de comunicação seguro entre todos os envolvidos na transação. Garante autenticidade X.509v3 e privacidade entre as partes. 8.6 X.509 Recomendação ITU-T, a especificação X.509 define o relacionamento entre as autoridades de certificação. Faz parte das séries X.500 de recomendações para uma estrutura de diretório global, baseada em nomes distintos para localização. Utilizado pelo S/MIME, IPSec, SSL/TLS e SET. Baseado em criptografia com chave pública (RSA) e assinatura digital (com hashing).


   

 

 



   

    

   



Página 306

 

 

  


9 Gerenciamento das Chaves Criptográficas As chaves criptográficas possuem um papel importantíssimo na segurança dos dados, pois elas são os insumos (entradas) para que os algoritmos criptográficos possam garantir um ou mais requisitos básicos da segurança da informação: a autenticidade, a confidencialidade, a integridade e o não-repúdio. Muitas vezes os atacantes não visam quebrar os códigos criptográficos de um sistema de comunicação, mas também visam o repositório das chaves criptográficas, motivo pelo qual muitos cripto-sistemas falharam em sua missão fundamental da segurança, pois a preocupação foi apenas com o meio inseguro. Desde a sua criação até a sua destruição, as chaves criptográficas passaram por várias fases, cada uma delas contendo características próprias. As fases descrevem de uma forma geral e de alto nível a situação da chave. Em cada fase, as chaves criptográficas passam por ou mais estágios. A transição de estágios é comandada por eventos característicos que definem qual será o novo estágio da chave como, por exemplo, o comprometimento da chave, a expiração do criptoperíodo e etc. Existem várias características essenciais no gerenciamento de chaves criptográficas que devem ser considerados: 









Geração da Chave - No início as chaves eram escolhidas pelo emissor, como nos casos da cifra de César e Vigenere. Nos sistemas atuais de criptografia a geração de chaves é normalmente automatizada e não depende do usuário final. Verificação da Chave - Algumas chaves são melhores que as outras. Quase todos os algoritmos criptográficos têm algumas chaves fracas, as quais não devem ser usadas, e com a ajuda de procedimentos de verificação isso pode ser evitado caso ocorra, sendo gerada novamente uma chave mais forte que a inicial. Por exemplo, com a cifra de César usando uma chave 0 ou 25 a mensagem não será criptografada, por isso não deve ser utilizado. Armazenamento das Chaves – Nos sistemas atuais, normalmente a chave pode ser armazenada na memória do dispositivo, o que representa um possível problema quando a memória é trocada para o disco, porque um programa do tipo Cavalo de Tróia instalado no computador de um usuário poderia então ter acesso à chave privada do usuário. Exchange ou Envio das Chaves - procedimentos de gerenciamento de chaves devem fornecer um mecanismo seguro de troca das chaves, o qual possibilite uma transação segura no momento da troca em um meio inseguro como a Internet. Revogação e Destruição – A revogação notifica todas as partes interessadas que uma determinada chave foi comprometida e não deve mais ser utilizada, enquanto a destruição apaga chaves antigas para previnir contra ataques que visem recuperá -las.


   

 

 



   

    

   



Página 307

 

 

  


Chaves criptográficas são medidas em bits, por exemplo, 40 bits, 56 bits, 64 bits, 128 bits, chamado de tamanho da chave ou “key length”. Com o tamanho em bits você pode tirar o espaço das chaves ou “keyspace”, por exemplo, uma chave de 40 bits tem o espaço de 2^40 chaves ou 1.099.511.627.776 chaves possíveis para alocação. Uma chave de 56 bits tem um intervalo de 2^0 ate 2^56 chaves, ou seja, mais de 1 quatrilhão de chaves. Uma das tentativas para descoberta da chave é utilizando um ataque de força bruta, ou seja, tentar descobrir a chave gerando as diversas possibilidades que o espaço da chave tem. Lembre que a cada bit acrescentado ao tamanho da chave dobrará o tempo requerido para um ataque de força bruta, porque cada bit adicional dobra o número de chaves possíveis, criando um efeito avalanche. Lembrete: Em média, um ataque de força bruta consegue varrer cerca de 50 por cento do espaço das chaves (key space), que é o conjunto de todas as chaves possíveis, motivo pelo qual quanto maior a chave menor a chance de um ataque desse tipo ser bem sucedido. Cada tipo de criptografia tem suas fraquezas, por exemolo, no DES as chaves fracas são aqueles que produzem 16 subchaves idênticas:    

Alternando uns e zeros (0101010101010101) Alternando F e E (FEFEFEFEFEFEFEFE) E0E0E0E0F1F1F1F1 1F1F1F1F0E0E0E0E

Com técnicas de força bruta ou criptoanálise um atacante poderia descobrir as chaves mais fracas e já documentadas, por isso é importante após o processo de geração fazer a verificação das chaves para evitar esse tipo de situação de risco. O tamanho da chave é o fator decisivo no sucesso do sistema de chaves criptográficas, pois quanto maior a chave mais difícil de um atacante quebrar o código. Com a tecnologia vigente um atacante levaria milhões até bilhões de anos para decriptografar a mensagem ou descobrir a chave criptográfica, portanto os dados mais importantes devem ser guardados com as chaves maiores possíveis.


   

 

 



   

    

   



Página 308

 

 

  


Um exemplo seria um ataque ao DES tradicional, com um super-computador a chave poderia ser quebrada em minutos, porém com técnicas mais avançadas como 3DES de 168-bits ou RC4 de 128-bits o atacante levaria milhões de anos com o mesmo super-computador para quebrar essa chave. Quanto maior a chave mais segura ela será, porém terá seu processamento mais lento. Portanto deve-se fazer uma análise sobre a importância da informação e a performance do dispositivo. Vários tipos de chaves criptográficas podem ser geradas:    

As chaves simétricas, que podem ser trocadas entre dois roteadores via VPN. As chaves assimétricas, que são utilizadas em aplicações seguras HTTPS. As assinaturas digitais, que são utilizadas ao se conectar a um site seguro. Chaves de Hash, que são utilizadas na geração de chaves simétricas e assimétricas, assinaturas digitais e outros tipos de aplicações.

10 Public Key Infrastructure – PKI A infraestrutura para lidar com o gerenciamento de chaves públicas é definido pelo padrão Public Key Infrastructure (PKI), a qual define onde os certificados digitais serão armazenados e recuperados, de que forma estão armazenados, como um certificado é revogado, dentre outras informações. A PKI refere-se também a um processo que utiliza chaves públicas e Certificados Digitais para garantir a segurança do sistema e confirmar a identidade de seus usuários. Veja a figura a seguir.

A PKI baseia-se em um sistema de confiança, no qual duas partes (pessoas ou computadores) confiam mutuamente em uma CA (Autoridade Certificadora ou Certification Authority) para verificar e confirmar a identidade de ambas as partes. Por exemplo, a maioria das pessoas e empresas confia na validade de uma carteira de habilitação de motorista ou em um passaporte. Isto ocorre porque elas confiam na forma pela qual o governo emite estes documentos. Entretanto, uma carteira de estudante é normalmente aceita como prova de sua identificação apenas para a escola que a emite. O mesmo vale para os Certificados Digitais. Um certificado digital é um arquivo presente no computador que permite identificar uma pessoa ou um computador. Alguns aplicativos como um navegador da web ou um leitor de correio eletrônico, podem utilizar esse arquivo para comprovar a identidade do computador ou da pessoa com a qual se está conectado. Um exemplo típico é:


   

 

 



   

    

   



Página 309

 

 

  


Quando um usuário consulta seu banco através de seu Website, este se identifica através de um certificado digital que aparece como um cadeado na interface de seu navegador. Clicando no cadeado o usuário pode confirmar que o Banco é realmente quem diz ser. Esta operação de identificação das partes permite ainda que as informações que trafegam entre o site do banco e o computador do usuário sejam protegidas de forma que impossibilitem a interceptação de dados confidenciais do cliente. Como uma carteira de identidade, um Certificado Digital confirma a autenticidade dos sites. Veja as figuras a seguir.

Na figura abaixo segue um exemplo dos certificados digitais instalados em um computador e visualizados através do menu Internet Options do Internet Explorer.


   

 

 



   

    

   



Página 310

 

 

  


10.1 Campos do Certificado Digital Um Certificado Digital costuma conter os seguintes campos:    

 

A chave pública. O nome e endereço de e-mail. A validade da chave pública. O nome da empresa (a Autoridade Certificadora ou CA) que emitiu seu Certificado Digital. O número de série do Certificado Digital. A assinatura digital da CA.

Um certificado quando utilizado em um roteador deve conter no mínimo:  



Chave pública do roteador. Nome do dispositivo criptografado com a chave privada. Isso só pode ser decifrada utilizando a chave pública e comprova se o roteador é quem diz ser. Assinatura da CA. Este é o nome da CA criptografada com a chave privada da CA. Somente a chave pública pode decifrar a assinatura comprovando que o certificado foi assinado pela autoridade de certificação.

Um certificado pode ter uma classe de certificado para indicar a confiabilidade do certificado. Quanto maior a classe do certificado mais verificações precisam ser feitas para provar a autenticidade do solicitante. Uma classe 0, por exemplo, pode não exigir verificações, já a classe 1 pode exigir um e-mail a partir do domínio para provar a identidade, por exemplo. O protocolo SCEP (Simple Certificate Enrolment Protocol) é um método automatizado para emitir certificados para hosts/routers. O host irá solicitar um certificado da CA (autoridade certificadora – será estudada a seguir). Esse protocolo opera em dois modos:  

Manual - Administrador deve aprovar o pedido. Chave pré-compartilhada - Dispositivos passarão a chave para o CA para permitir que ele gerasse automaticamente o certificado.


   

 

 



   

    

   



Página 311

 

 

  


10.2 Introdução às Autoridades Certificadoras - CA Uma CA (Autoridade Certificadora) é a empresa que emite ou assina um Certificado Digital. A sua CA pode, por exemplo, ser a empresa para a qual você trabalha ou uma empresa que você paga para emitir Certificados Digitais. Além disso, uma CA executa muitas outras tarefas além de emitir os certificados de assinatura do usuário, tais como a autenticação de usuários ao se inscreverem com a PKI, geração de chaves e distribuição de certificados. Estas tarefas podem ser transferidas para uma Autoridade de Registro (AR ou Registration Authority - RA), permitindo que a CA concentre-se na assinatura. Veja a figura a seguir.

Com a PKI, ambas as partes de uma transação (seja ela um banco on-line e seus clientes ou um empregador e seus funcionários) concordam em confiar na CA que emite seus Certificados Digitais. Normalmente, o aplicativo de software que utiliza seu Certificado Digital tem algum mecanismo para confiar nas CAs. Por exemplo, um navegador contém uma lista das CAs em que confia. Quando é apresentado ao navegador um Certificado Digital (por exemplo, de um shopping on-line realizando comércio seguro), ele consulta a CA que emitiu o Certificado Digital. Se a CA estiver na lista de CAs confiáveis, o navegador aceita a identidade do site da Web e exibe a página da Web. Entretanto, se a CA não estiver na lista de CAs confiáveis, o navegador exibe uma mensagem de aviso que lhe pergunta se você deseja confiar na nova CA. Geralmente seu navegador lhe dá opções para confiar permanente ou temporariamente na CA ou não confiar em absoluto. Como usuário, você tem controle sobre em qual (ais) CA(s) deseja confiar, porém o gerenciamento da confiança é feito pelo aplicativo de software (neste exemplo, pelo navegador). Alguns modelos de PKI podem oferecer a possibilidade, ou mesmo exigir, o uso de dois pares de chaves por entidade. O par de chaves pública e privada da primeira chave é destinado apenas para operações de criptografia. A chave pública cifra e a chave privada decifra. O par de chaves pública e privada da segunda chave é destinado para operações de assinatura digital, onde a chave privada assina e a chave pública verifica a assinatura. Estas chaves são chamadas às vezes de chaves de uso especiais. Elas podem ser diferentes em comprimento e até mesmo na escolha do algoritmo de chave pública. Se o PKI requer dois pares de chaves por entidade, o usuário tem dois certificados. Um certificado de criptografia contém a chave pública do usuário, que criptografa os dados, e um certificado de assinatura digital contém a chave pública do mesmo usuário, que verifica a assinatura digital do usuário.


   

 

 



   

    

   



Página 312

 

 

  


A PKI é mais do que uma CA e seus usuários, pois além de implementar a tecnologia de apoio, a construção de uma PKI envolve uma grande quantidade de trabalho organizacional e legal. Existem cinco principais componentes de uma PKI:    



Usuários (pessoas, dispositivos e servidores). CAs para gerenciamento de chaves. Armazenamento e protocolos. Apoio à estrutura organizacional, conhecido como práticas e autenticação de usuários usando Local Registration Authorities (LRA ou RA). Apoio jurídico.

10.3 Padrões de PKI A padronização e interoperabilidade de diferentes fornecedores de PKI ainda é um problema até os dias de hoje. A interoperabilidade entre uma PKI e os seus serviços de apoio, como Lightweight Directory Access Protocol (LDAP) e diretórios X.500, é uma preocupação porque muitos fornecedores têm proposto e implementado soluções proprietárias, em vez de esperar que as normas sejam desenvolvidas. O estado de interoperabilidade é muito básico, mesmo após 10 anos de desenvolvimento de software voltado para PKI. Para resolver este problema de interoperabilidade, a IETF formou o grupo de trabalho “PublicKey Infrastructure X.509” (PKIX), que se dedica à promoção e normalização do PKI na Internet. Este grupo de trabalho tem publicado um conjunto de normas chamadas de X.509, detalhando os formatos comuns de dados e protocolos relacionados de PKI para uso em rede. O padrão X.509 hoje em sua versão 3, está se tornando o padrão mais utilizado pela maioria dos grandes fabricantes de software. Veja a figura a seguir.

O padrão X.509v3 pode ser utilizado para as seguintes aplicações de segurança:    

Secure web servers: SSL e TLS Navegadores de Internet: SSL e TLS Email: S/MIME VPN IPsec: IKE


   

 

 



   

    

   



Página 313

 

 

  


Outro importante padrão de PKI é a “Public-Key Cryptography Standards” (PKCS). PKCS refere-se a um grupo de Public Key Cryptography Standards elaborado e publicado pela RSA Laboratories, a qual fornece interoperabilidade básica de aplicativos que usam criptografia de chave pública. PKCS define os formatos de baixo nível para a troca segura de dados arbitrários, como um pedaço de dados criptografados ou um pedaço de dados assinado. Como refere o site da RSA Laboratories, "A Public-Key Cryptography Standards são especificações produzidas pelos Laboratórios RSA em cooperação com desenvolvedores de sistemas seguros de todo o mundo com o propósito de acelerar a implantação de criptografia de chave pública". Abaixo seguem os padrões de PKCS:  

 









 

PKCS #1: RSA Cryptography Standard – padrão de criptografia RSA PKCS #3: DH Key Agreement Standard – trata-se de um protocolo de criptografia que permite que duas partes que não têm conhecimento prévio da outra possam estabelecer conjuntamente uma chave secreta compartilhada sobre um canal de comunicação inseguro, como a Internet, utilizando o Algoritmo Diffie-Hellman. PKCS #5: Password-Based Cryptography Standard – criptografia baseada em senha PKCS #6: Extended-Certificate Syntax Standard - define as extensões para o padrão X.509 v1, obsoletos na atualidade pelo uso da versão 3. PKCS #7: Cryptographic Message Syntax Standard - utilizada para assinar e/ou criptografar mensagens em um PKI. Usado também para divulgação de certificado (por exemplo, como uma resposta a uma mensagem de PKCS # 10). Serviu de base para S/MIME e define a sintaxe das mensagens criptografadas e mensagens com assinatura digital. PKCS #8: Private-Key Information Syntax Standard - Usados para transportar pares de chaves privadas de certificados (criptografados ou não criptografados). PKCS #10: Certification Request Syntax Standard - formato das mensagens enviadas a uma CA para solicitar a certificação de uma chave pública. PKCS #12: Personal Information Exchange Syntax Standard - define um formato de arquivo comumente usado para armazenar chaves privadas com acompanhamento de certificados de chave pública, protegida com uma chave baseada em senha simétrica. PKCS #13: Elliptic Curve Cryptography Standard – ainda em desenvolvimento. PKCS #15: Cryptographic Token Information Format Standard - define um padrão que permite usuários de tokens criptográficos identificarem-se aos aplicativos, independente da implementação do aplicativo Cryptoki (PKCS # 11) ou outra API.


   

 

 



   

    

   



Página 314

 

 

  


A tecnologia de chave pública é cada vez mais utilizada e está se tornando a base para a segurança baseada em padrões como os protocolos IPSec e IKE. Com o uso de certificados de chave pública em protocolos de segurança vem a necessidade de um protocolo de gerenciamento de certificados PKI que os clientes e servidores de CA possam utilizar para apoiar as operações do ciclo de vida da PKI, tais como registro e revogação de certificados. O objetivo do Simple Certificate Enrollment Protocol (SCEP) é apoiar a emissão de certificados de segurança para dispositivos de rede de uma forma escalável, usando a tecnologia existente sempre que possível. Veja a figura a seguir.

No exemplo da figura um usuário inicia a solicitação do certificado enviando utilizando o PKCS#10 e envia dentro de um pacote envelopado com o PKCS#7 para um CA. Após a CA receber o pedido, ela pode aprovar automaticamente o pedido ou enviar o certificado para trás, ou obrigar o usuário a esperar até que o operador autentique manualmente a identidade da entidade solicitante, ou seja, do usuário.


   

 

 



   

    

   



Página 315

 

 

  


10.4 Autoridades Certificadoras - Topologias Existem várias topologias para um sistema de PKI que as CAs podem utilizar: 





Raiz Única ou Single Root - Difícil escalonamento e vulnerável, pois se a chave raiz é comprometida todos os certificados gerados se tornarão inválidos. Devido à sua simplicidade VPNs que são gerenciadas por uma única organização muitas vezes utilizam essa topologia.

Hierárquica - Uma CA raiz (root CA) ao invés de emitir os certificados, passa para uma CA subordinada emitir. A autoridade de certificação subordinada, ent ão emite os certificados para usuários finais. Isso melhora a escalabilidade e reduz o impacto se uma chave está comprometida.

Certificação Cruzada ou Cross-certifying - A CA irá cruzar as certificações com outra CA em uma instalação de PKI diferente, criando uma relação de confiança.


   

 

 



   

    

   



Página 316

 

 

  


Roteadores Cisco suportam os seguintes dispositivos/servidores:    

Entrust Baltimore Verisign Windows 2000

Conforme mencionado em capítulos anteriores, a CA pode executar muitas tarefas além de certificar assinatura do usuário, tais como a autenticação de usuários ao se inscreverem com o PKI, geração de chaves e distribuição de certificados. Estas tarefas podem ser transferidas para uma Autoridade de Registro Local. Uma Autoridade de Registro (AR ou RA - Registration Authority) é um dos elementos de uma PKI, ou talvez o mais importante. Esta é o intermediário entre Autoridade de Certificação, Diretoria X.500, Base de Dados de Autenticação e Cliente (aquele que pede o certificado), caso o último não peça o certificado diretamente à Autoridade de Certificação. A AR é quem valida a entidade do Cliente, através de auditorias, para ver se o Cliente não se faz passar por quem disse à Autoridade de Registro, e é quem se responsabiliza perante a Autoridade de Certificação pelo cumprimento da CPS (Certification Practice Statement, Declaração das Práticas de Certificação). Veja a figura a seguir.


   

 

 



   

    

   



Página 317

 

 

  


10.5 Uso do PKI na Prática Portanto, os certificados digitais podem ser usados para os clientes que desejam autenticar um servidor web e verificar se eles estão se conectando ao servidor correto usando HTTP seguro (HTTPS), Transport Layer Security (TLS) ou Secure Sockets Layer (SSL). Os certificados digitais são usados também quando você faz acesso ao Internet-Banking a partir do seu computador para o site do seu banco. Ou então na tecnologia SSL para VPNs de acesso remoto na autenticação dos pares da VPN. Podemos também utilizar os certificados digitais com a família do protocolo de IPSec na autenticação em VPNs, por exemplo. Além disso, certificados digitais podem também ser utilizados com o 802.1x, para autenticação nas extremidades das redes ou como parte do NAC. Um exemplo é a utilização em redes sem fio para controle de acesso e autenticação, utilizando certificados digitais permitir que os usuários tivessem acesso aos recursos de rede. Tanto o Adaptive Security Appliance (ASA) como roteadores com Cisco IOS podem utilizar certificados digitais. Por padrão o Firewall ASA já utiliza certificados digitais como “ self-signed digital certificate”, ou seja, o certificado está no próprio dispositivo e é utilizado para dar acesso administrativo ao ASDM, e para suporte aos clientes SSL VPN (vamos estudar no próximo capítulo). O problema desse tipo de certificado é que ele não aparecerá como confiável e não temos como colocar o ASA como um “trusted CA”, portanto toda vez que fizermos uma conexão HTTPS ao ASA o administrador vai receber uma mensagem que o certificado não é confiável e terá que confirmar uma exceção de segurança, dependendo do browser utilizado. Você pode utilizar o certificado a partir de um CA server na Internet ou na Intranet, para isso você precisa instalar um certificado raiz (root certificate) e o certificado de identidade (identity certificate) no ASA. Para isso você precisa de um CA Server na rede funcionando.


   

 

 



   

    

   



Página 318

 

 

  


10.6 Exemplo de Configuração de PKI – CA Server Apesar de não ser parte do curso, configurar um roteador como CA Server para servir como autorizador para outros roteadores e ASAs quando utilizam autenticação via certificados digitais RSA não é uma tarefa difícil e funciona bem no GNS3. A seguir vamos ensinar uma “receita de bolo” que você pode utilizar em seus laboratórios para criação do CA Server. Você vai notar na configuração que o certificado raiz vai ficar na própria memória flash do roteador, para isso você precisa formatar a flash do GNS3 (“format flash:”), pois ela não funciona sem essa etapa ela não deixa gravar arquivos. Pré-requisitos para a configuração do roteador como CA Server: Interfaces configuradas e roteamento OK  todos os equipamentos da topologia se comunicando e conseguem chegar ao CA Server. Network Time Protocol (NTP)  devido a data e hora de validade e expiração dos certificados. Trivial File Transfer Protocol (TFTP)  opcional se você for utilizar um ponto de armazenamento externo para as chaves, aqui vamos utilizar a própria flash do roteador para armazenamento. Domain Name System (DNS)  nome de domínio configurado. Servidor HTTP ativado (ip http server) para suportar os enrollments através do protocolo Simple Certificate Enrollment Protocol (SCEP). 





 

Vamos nesse exemplo supor que temos uma topologia isolada sem conexão à Internet, por isso o clock do roteador será configura localmente e ele servirá como NTP Server (master). Os demais roteadores da topologia devem se sincronizar via NTP com o CA Server, essa configuração é opcional e apenas um exemplo, você pode integrar o GNS3 com a Internet e pegar a referência de clock de um servidor real. Clock set hh:mm:ss dia mês ano ! mês em inglês Config term Int f0/0 Ip add 200.0.0.1 255.255.255.0 No shut ! Hostname CA-Server ntp master 1 ! O roteador será mestre com Stratum 1 clock timezone UTC -3 Ip http server ! Utiliza por padrão porta 80 Ip domain-name dltec.com.br ! crypto pki server ca-pki-test ! Esse nome deve ser o mesmo nos outros eqtos lifetime certificate 60 ! Validade do certificado do router cliente 60 dias lifetime ca-certificate 75 ! Validade do certificado raiz 75 dias issuer-name CN= DlteC, C=PK ! Nome do emissor que vai aparecer na assinatura digital dos clientes grant auto ! Certificados emitidos pelos routers serão aceitos automaticamente database url pem flash: ! os certificados serão armazenados localmente na flash no shutddown ! Nessa etapa você precisará definir uma chave de proteção para as chaves end copy run start ! Salve para garantir...

Você pode testar roteador seu CA Server utilizando um ASA e fazendo o enrollment através do ASDM. Para fazer emitir o certificado digital em um roteador basta seguir os passos abaixo: Hostname R2


   

 

 



   

    

   



Página 319

 

 

  


Int f0/0 Ip add 200.0.0.2 255.255.255.0 No shut ! ntp server 200.0.0.1 clock timezone UTC -3 Ip domain-name dltec.com.br crypto key generate rsa modulus 1024 crypto pki trustpoint ca-pki-test usage ike subject-name CN= R2, C=PK enrollment url http://200.0.0.1:80 ! endereço do próprio roteador na porta 80 exit crypto ca authenticate ca-pki-test ! responda Y para sim crypto ca enroll ca-pki-test ! entre com as senha e depois responda N, N e Y end copy run start

Verifique se os certificados foram criados. R2#sho crypto ca certificates Certificate Status: Available Certificate Serial Number: 0x2 Certificate Usage: General Purpose Issuer: cn=DlteC c=PK Subject: Name: R2.dltec.com.br hostname=R2.dltec.com.br cn=R2 c=PK Validity Date: start date: 22:30:40 UTC Nov 12 2013 end date: 22:30:40 UTC Jan 11 2014 Associated Trustpoints: ca-pki-test CA Certificate Status: Available Certificate Serial Number: 0x1 Certificate Usage: Signature Issuer: cn=DlteC c=PK Subject: cn=DlteC c=PK Validity Date: start date: 22:14:14 UTC Nov 12 2013 end date: 22:14:14 UTC Jan 26 2014 Associated Trustpoints: ca-pki-test R2#


   

 

 



   

    

   



Página 320

 

 

  


Para fazer a mesma coisa com o ASA e o ASDM podemos seguir os seguintes passos, veja as telas a seguir. Com esse passo a passo geramos ao mesmo tempo o Root e o Identity certificate. Para isso clique no botão Configuration depois procure do lado esquerdo inferior a opção “Device Management”. Em Device Management procure a opção Certificate Management e clique em Identity Certificates. Em Idendity Certificates você vai clicar em Add, depois dar um nome ao trustpoint, colocamos o mesmo so CA Server “ca-pki-test”, aí escolha a opção “Add a New Identity Certificate” e clique em New. Nessa nova tela dê um nome para o novo par de chaves, escolha o tamanho da chave e clique em Generate Now. Não deve dar erros.

A seguir ainda na tela anterior clique em Advanced e coloque o IP do CA Server para que ele emita o certificado via SCEP.

Se o seu certificado de identidade não ficar OK e apresentar um “Pending” resolva entrando na CLI e alterando o seguinte parâmetro: ciscoasa(config)# crypto ca trustpoint ca-pki-test ciscoasa(config-ca-trustpoint)# no fqdn ciscoasa(config-ca-trustpoint)# end ciscoasa# wr


   

 

 



   

    

   



Página 321

 

 

  


Com isso o certificado será mostrado corretamente e validado pelo CA Server, esse problema ocorre porque nesse ambiente não temos um servidor DNS para traduzir o nome do CA e dos clientes. Depois você pode visualizar a chaves clicando nas opções “CA Certificates” e “Identity Certificates” e poderá clicar neles para verificar os dados em “Show Details”.

11 Resumo do Capítulo Bem pessoal, chegamos ao final do capítulo. É muito importante que nesse ponto do curso você tenha domínio dos seguintes itens: Explicar os diferentes métodos de criptografia. Explicar os princípios do PKI. Explicar o que é um CA.   


   

 

 



   

    

   



Página 322

 

 

  


Capítulo 10 - Virtual Private Network – VPN Nesse capítulo veremos os conceitos sobre VPN e estudaremos sua implementação nas versões site-to-site e acesso remoto através do CCP e CLI.

Objetivos do Capítulo Ao final desse capítulo você terá estudado e deverá compreender: Descrever o que é uma VPN, seus tipos, aplicações e topologias. Descrever os blocos funcionais do IPSec e suas funções. Explicar a funcionalidade do protocolo IKE e suas fases de estabelecimento. Configurar e verificar uma VPN siteto-site com “pre-shered key authentication” e utilizando certificados digitais utilizando o CCP e CLI. Comandos Show e Debug para realizar troubleshooting em VPNs. Conceito e implementação de VPNs SSL através do ASA e ASDM. 



Além disso, também estudaremos como implementar VPNs SSL utilizando o ASA Firewall e seu gerenciador gráfico ASDMP.











   

 

 



   

    

   



Página 323

 

 

  


5.1 Passo 1 - Configuração Parâmetros da Fase 1 do IKE ________________________ 345


5.2 Passos 2, 3 e 4 - Configuração dos Parâmetros da Fase 2 do IKE, Tráfego Interessante e Crypto-Map ____________ 346

Introdução _____________________ 325

2 Conceitos Básicos sobre VPN e suas Topologias ________________________ 326

2.1

Vantagens do Uso de VPN ________ 327

2.2

Topologias e Tipos de VPNs _______ 327

5.3 6

Framework IPSec _______________ 331

3.2

Visão Geral dos Protocolos ESP e AH 333

3.2.1 3.2.2

3.3

ESP (Encapsulation Security Payload) 335 AH (Authentication Header) ______ 336

Modos de Operação do IKE _______ 338 Main Mode ____________________ 339 Agressive Mode ________________ 340 Resumo das fases de estabelecimento 341

Configuração da VPN via CCP _____ 355

6.4

Troubleshooting Básico em VPNs __ 358

7.1

Protocolos SSL e TLS ____________ 360

7.2

Estabelecimento de VPNs SSL _____ 361

7.3 ASA

Configurando SSL Clientless VPNs no 362

7.4 Configurando o Full SSL AnyConnect VPN no ASA _________________________ 366 7.5 Conectando-se ao ASA e Instalando o AnyConnected_______________________ 371

4 Planejando a Implantação de uma VPN IPSec _____________________________ 343 Configurando uma VPN IPSec via CLI 344

6.3

7 Conceitos e Implantação do VPN SSL no Cisco ASA _________________________ 359

3.4 Fases de Estabelecimento de uma VPN IPSec 342

5

Planejando a Implantação via CCP _ 352

6.2 Preparando os roteadores: certificado digital e NTP ________________________ 354

Protocolo IKE (Internet Key Exchange) 337

3.3.1 3.3.2 3.3.3 3.3.4 do IKE

Configurando uma VPN IPSec via CCP 350

6.1

3 VPN IPSec – Conceitos, Protocolos e Terminologia ______________________ 331

3.1

Testanto o Túnel _______________ 349

7.6 8

Split Tunneling _________________ 372

Resumo do Capítulo _____________ 373


   

 

 



   

    

   



Página 324

 

 

  


1 Introdução As redes virtuais privadas ou VPNs (Virtual Private Networks) já vêm sendo estudadas e implementadas há algum tempo, sendo que nos dias atuais as VPNs são frequentemente utilizadas para implementar acesso remoto a usuários e soluções site-to-site, conectando funcionários e escritórios remotos à rede corporativa através da Internet de maneira segura.

VPN significa coisas diferentes para pessoas diferentes, mas em geral é um método para conectar duas redes diferentes, normalmente utilizando a Internet, através de um processo de tunelamento e criptografia. Nesse capítulo iremos focar principalmente em túneis criptografados utilizando IPSec utilizando roteadores com Cisco IOS e VPNs SSL utilizando o ASA. Não podemos aprender sobre VPNs sem aprender sobre IPSec (IP Security), o qual é o padrão que utilizaremos neste capítulo. O IPSec é baseado em uma série RFCs (normas internacionais) que foram emitidas inicialmente durante os meados da década de 90. Estas especificações têm sido continuamente atualizadas e estão em uso no mundo inteiro. Veja a figura a seguir.


   

 

 



   

    

   



Página 325

 

 

  


Os conceitos de chaves criptográficas, criptografia, PKI e demais teorias necessárias para entender o que é uma VPN e como ela protege a comunicação já foram estudados no capítulo anterior, agora vamos colocar em prática os conceitos teóricos, juntar as peças e fazer as VPNs funcionarem! Aproveitem o capítulo e bons estudos! 2

Conceitos Básicos sobre VPN e suas Topologias

Simplificadamente, uma VPN conecta dois ou mais pontos em uma rede pública para formar uma conexão lógica, as quais que podem ser feitas na Camada 2 ou Camada 3 do modelo OSI. As tecnologias de VPN podem ser classificados em geral como VPNs de Camada 2 (enlace) ou Camada 3 (rede). Exemplos comuns de VPNs são IPSec, SSL e VPNs camada-3 do MPLS. VPNs de Camada 3 podem ser conexões remotas ponto a ponto (site-to-site), como o IPSec, ou podem estabelecer conectividade entre usuários remotos e a rede local de uma empresa através da Internet, chamado de acesso remoto. Além disso, podem ser montadas VPNs ponto multiponto para facilitar a adição e remoção de dispositivos que se conectam às VPNs. Como a VPN pode garantir a segurança dos dados que estão sendo enviados pelo meio público, como a Internet? A resposta estudamos no capítulo anterior: “ através de algoritmos de criptografia”. Em uma VPN os dados que devem ser protegidos são criptografados e enviados dentro de um pacote IP, garantindo que ao ser capturado por um sniffer, por exemplo, ele não possa ser decifrado.

Portanto, um túnel VPN visa proteger principalmente o Data Plane, ou seja, a transmissão dos dados dos usuários finais, porém pode ser utilizado para proteção do Control e Management Plane também, por exemplo, se os dispositivos trocam informação de roteamento através do túnel a criptografia acaba protegendo também esses dados que são de controle.


   

 

 



   

    

   



Página 326

 

 

  


2.1 Vantagens do Uso de VPN Bem planejada, uma VPN pode trazer muitos benefícios para a empresa. Por exemplo:          

Ampliar a área de conectividade. Aumentar a segurança. Reduzir custos operacionais (em relação a uma rede WAN dedicada, por exemplo). Reduzir tempo de locomoção e custo de transporte dos usuários remotos. Aumentar a produtividade. Simplificar a topologia da rede. Proporcionar melhores oportunidades de relacionamentos globais. Prover acesso seguro ao usuário remoto externo. Prover compatibilidade de rede de dados de banda larga. Prover retorno de investimento mais rápido do que a tradicional WAN.

Abaixo seguem as características que um bom projeto de rede VPN deve possuir:     

Segurança (criptografia e autenticação). Confiabilidade. Escalabilidade. Gerência da rede. Gerência de diretrizes (políticas de segurança).

2.2 Topologias e Tipos de VPNs Falando um pouco sobre as topologias que podem ser implementadas uma VPN, geralmente temos a VPN para acesso remoto e para conectar escritórios ponto a ponto ou site-to-site. Um dos tipos de VPN é a rede de acesso remoto, também chamada rede discada privada virtual (VPDN), a qual é uma conexão Usuário-LAN, ou seja, de um usuário que está normalmente na Internet à Intranet Corporativa da empresa. Muito utilizada por empresas cujos funcionários precisam se conectar a uma rede privada de vários lugares distantes. Normalmente, uma empresa que precisa instalar uma grande rede VPN de acesso remoto pode criar sua própria estrutura ou terceirizar o processo para um provedor de serviços.

Outro exemplo clássico de acesso remoto são empresas com centenas de vendedores em campo que necessitam do acesso remoto via VPN para registrar seus pedidos de vendas. O acesso remoto via VPNs permite conexões seguras e criptografadas entre redes privadas de A p o s t i l a / E - Bo o k d o C u r s o I I N S 6 4 0 - 5 5 4      

   

 

 



   

    

   



Página 327

 

 

  


empresas e usuários remotos por meio do serviço de provedor terceirizado. Outra aplicação é no caso de funcionários em home-office, ou seja, que trabalham sem sair de casa, ou ainda aqueles que prestam suporte em campo e necessitam acessar arquivos e sistemas da empresa de maneira segura. No acesso remoto, o usuário acessa a rede interna da empresa do seu computador, PDA ou qualquer dispositivo que permita realizar uma VPN através de um software cliente VPN, como o Cisco VPN Client. Esse acesso pode ser realizado utilizando uma linha discada, seja ela através da telefonia convencional ou uma linha RDSI ou ISDN (rede digital de serviços integrados), ou através de uma Internet banda-larga, como o ADSL ou Cable Modem.

Através do uso de equipamentos dedicados e criptografia em grande escala, uma empresa pode conectar múltiplos pontos fixos em uma rede pública como a Internet, chamadas de VPN siteto-site, as quais podem ser ainda classificadas como: 



Baseada em Intranet – se uma empresa tem um ou mais locais remotos que quer ver ligados por uma rede privada, pode criar uma rede do tipo VPN intranet para conectar redes LAN entre si, como se fosse uma “linha privada” ou circuito WAN através da Internet. Baseada em Extranet – quando uma empresa tem uma estreita relação com outra (parceiros, fornecedores ou clientes), pode construir uma rede do tipo VPN extranet que conecta uma rede LAN a outra LAN, permitindo às empresas o trabalho em ambiente compartilhado, porém com restrições de acesso mais rígidas que na baseada em intranet, pois nesse exemplo temos duas empresas diferentes se comunicando diretamente.

Em uma VPN site-to-site, o host remoto pode enviar e receber normalmente o tráfego TCP/IP através de um gateway VPN, o qual pode ser um roteador, firewall, um concentrador VPN da Cisco ou um Cisco ASA da série 5500 (Adaptive Security Appliance). O gateway VPN é responsável por encapsular e criptografar o tráfego de saída de um site específico e enviá-lo através de um túnel VPN através da Internet até um gateway VPN remoto no local de destino. Após a recepção, o gateway VPN remoto remove o cabeçalho, descriptografa o conteúdo e retransmite o pacote para o host de destino dentro da sua rede privada.


   

 

 



   

    

   



Página 328

 

 

  


Veja a seguir a nomenclatura dos equipamentos VPN utilizada por padrão em uma topologia site-to-site. 







Headend VPN device ou Concentrador VPN: Atua como um dispositivo de terminação dos circuitos VPN, geralmente localizado em um local da rede primária (por exemplo, na matriz da empresa ou em um Data Center). VPN access device ou Gateway VPN ou Equipamento VPN de Acesso: Dispositivo de terminação VPN, localizado em um escritório remoto. Tunnel ou Túnel: Fornece uma conexão lógica para passar o fluxo da VPN (por exemplo, um túnel Ipsec ou um túnel GRE). Broadband service ou Serviço de Banda Larga (ex ADSL): Meio de transmissão através da Internet de alta velocidade, como um ADSL ou Cable Modem.

Outra opção atualmente disponibilizada é a VPN SSL, a qual é uma ligação privada virtual (VPN - Virtual Private Network) que pode ser estabelecida usando apenas um web browser (Internet Explorer, Firefox, Safari, Opera, etc), sem a necessidade de criar conexões e configurações complexas nos computadores dos clientes ou recorrer a software adicional de VPN Cliente.


   

 

 



   

    

   



Página 329

 

 

  


Este serviço é necessário para acessar aos recursos internos de uma empresa, que de outra forma só estariam disponíveis dentro dela, ou com recurso à tradicional ligação VPN. Então se eu precisar acessar recursos de rede através do web-browser, caso seja necessário acessar arquivos ou edição de páginas, por exemplo, uma VPN tradicional será necessária? Na realidade não, a VPN SSL pode também fazer o que chamamos de “ Full AnyConnect SSLVPN Client”, que através de um cliente SSL muito mais leve que um cliente VPN tradicional permite ao cliente acessar aos recursos de rede como se estivesse se conectando em uma VPN de acesso remoto tradicional. Tanto o ASA como os roteadores com Cisco IOS suportam as VPNs SSL, porém cada um tem suas limitações e requisitos, por exemplo, o ASA vem com licença para duas conexões simultâneas, se mais forem necessárias será preciso adquirir mais licenças. Vamos aprender em um tópico posterior mais sobre o assunto e como implementar VPNs SSL no ASA Firewall.


   

 

 



   

    

   



Página 330

 

 

  


3 VPN IPSec – Conceitos, Protocolos e Terminologia O IPSec é um framework padrão do IETF, definido pela RFC 4301, que proporciona confidencialidade, integridade e autenticação dos dados. Com o IPSec podemos criar um túnel entre dois pontos, por onde os “dados sensíveis” (dados que necessitam de criptografia) são enviados protegidos. Os “dados sensíveis” são definidos por quem está configurando a VPN, e normalmente são selecionados através de uma access-list. Mais especificamente, o IPsec oferece os seguintes itens de segurança para t ráfego VPN: 







Confidencialidade: A confidencialidade dos dados é fornecida através da criptografia dos dados. Se um terceiro interceptar os dados criptografados, ele não pode interpretálo. Integridade: A integridade de dados garante que os dados não serão modificados em trânsito. Por exemplo, roteadores em cada extremidade de um túnel podem calcular um valor de checksum ou um valor de hash para os dados transmitidos. Se os dois roteadores na recepção recalcularem o valor e o resultado for o mesmo, significa que os dados muito provavelmente não tenham sido modificados em trânsito. Autenticação: autenticação de dados permite que as partes envolvidas na comunicação verifiquem se a outra parte é quem realmente diz ser. Existem vários métodos de autenticação possíveis com o IPSec: o Nomes de usuário e senhas o Senhas de “Um Tempo” (One-time passwords - OTP) o As tecnologias de biometria (como impressões digitais ou análise de exame de retina) o Chaves pré-compartilhada (Preshared keys) o Assinaturas via certificados digitais Esconder os endereços privativos ao cruzar a Internet

3.1 Framework IPSec O framework IPSec, ou seja, sua estrutura, prevê dois tipos básicos de protocolos que podem ser utilizados dentro de um pacote IP: o Authentication Header (AH), que provê a autenticação e integridade dos dados, mas não a confidencialidade, e o Encapsulating Security Payload (ESP), que provê autenticação, confidencialidade dos dados e integridade da mensagem.


   

 

 



   

    

   



Página 331

 

 

  


Na figura mostrada anteriormente, cada funcionalidade do IPSec está em um dos blocos com espaços que podem ser preenchidos com os protocolos ao lado, porém veja que a confidencialidade, que são os algoritmos de criptografia não são suportados pelo AH. Para o IPSec fornecer a confidencialidade você terá que utilizar o protocolo ESP ou ESP trabalhando em conjunto com o AH (veja a linha do “Protocolo IPSec”). O segundo espaço representa o tipo de confidencialidade implementado usando um algoritmo de criptografia como DES, 3DES, AES ou SEAL. A escolha depende do nível de segurança exigido, a ordem de nível de segurança (da esquerda para a direita – menos seguro para o mais seguro) segue ao lado: DES - 3DES - AES - SEAL. O terceiro espaço representa a integridade que podem ser implementados usando hashs MD5 ou SHA. Lembre que o SHA é mais seguro que o MD5. Essa garantia da integridade é realizada utilizando o Hashed Message Authentication Codes (HMAC), normalmente com o MD5 ou SHA1. O quarto representa a forma como a chave secreta compartilhada é estabelecida. Os dois métodos são: pré-compartilhada (preshared key ou PSK) ou com certificados digitais RSA. A IPSec utiliza o protocolo Internet Key Exchange (IKE) para autenticação e troca das chaves. O último grupo representa o algoritmo Diffie-Hellman ou DH utilizado para troca segura das chaves através da Internet. Há quatro algoritmos distintos DH de troca de chaves para se escolher incluindo DH Grupo 1 (DH1), DH Grupo 2 (DH2), DH Grupo 5 (DH5) e DH Grupo 7 (DH7). O tipo de grupo selecionado depende das necessidades específicas de cada projeto.


   

 

 



   

    

   



Página 332

 

 

  


Segue abaixo uma descrição breve de cada grupo e suas aplicações práticas: 



  

Os grupos DH 1, 2 e 5 exponenciação de um módulo principal com um tamanho de chave de 768 bits, 1024 bits e 1536 bits respectivamente. Os clientes Cisco 3000 suportam grupos 1, 2 e 5. As criptografias DES e 3DES suportam grupos DH 1 e 2. A criptografia AES suporta os grupos DH 2 e 5. Os Certicom movianVPN client suportam o grupo 7. O grupo 7 suporta Elliptical Curve Cryptography (ECC), que reduz o tempo para geração das chaves.

Durante a configuração do túnel os pares VPN negociam o grupo DH que irão utilizar. Nos próximos dois tópicos vamos falar um pouco sobre cada protocolo utilizado pela VPN IPSec e suas principais características. Lembre que muitos desses algorítmos de criptografia, hashes e técnicas foram estudados no capítulo anterior, caso haja dúvidas consulte-o. 3.2 Visão Geral dos Protocolos ESP e AH O "Authentication Header” (AH) e "Encapsulating Security Payload" (ESP) são os dois principais protocolos utilizados pelo IPSec. Eles normalmente são utilizados de forma independente, embora seja possível, porém raro, utilizar os dois juntos.

Esses dois protocolos são encapsulados dentro do pacote IP e identificados no campo de protocolo, conforme tabela abaixo. Veja na figura a seguir um exemplo de pacote IP com um quadro do tipo ESP encapsulado nele.


   

 

 



   

    

   



Página 333

 

 

  


Note que no pacote IP normal transportando um TCP, o código do TCP vai no campo “Proto” do pacote IP. Agora quando o ESP foi adicionado, o campo proto fica com o valor referente ao ESP (50) e o valor referente ao protocolo TCP, ou seja, seu identificador fica dentro do quadro do ESP. Código do Protocolo

Descrição do Protocolo

1

ICMP — Internet Control Message Protocol

2

IGMP — Internet Group Management Protocol

4

IP within IP (a kind of encapsulation)

6

TCP — Transmission Control Protocol

17

UDP — User Datagram Protocol

41

IPv6 — next-generation TCP/IP


   

 

 



   

    

   



Página 334

 

 

  


Código do Protocolo

Descrição do Protocolo

47

GRE — Generic Router Encapsulation (used by PPTP)

50

IPsec: ESP — Encapsulating Security Payload

51

IPsec: AH — Authentication Header

3.2.1 ESP (Encapsulation Security Payload)

É um protocolo IP, tipo 50 (não é UDP nem TCP), que prove integridade, autenticação e confidencialidade dos dados. É usado para criptografar o payload dos pacotes IPs. É o principal protocolo utilizado pelo IPSec atualmente, e pode ser configurado no modo Túnel ou Transporte. No Túnel o pacote inteiro é encapsulado e protegido, sendo um novo cabeçalho IP adicionado ao pacote. Já no modo Transporte, são criptografados apena s os “dados”, não sendo alterado o cabeçalho original.


   

 

 



   

    

   



Página 335

 

 

  


3.2.2 AH (Authentication Header)

O AH é semelhante ao ESP, porém não faz criptografia e por isso provavelmente nem será mais suportado pelos equipamentos Cisco em um futuro próximo. É o protocolo IP tipo 51 (não é UDP nem TCP), provê integridade, autenticação e anti-replay. Ele é como uma assinatura digital e garante que o pacote não foi alterado. Assim como o ESP, o AH também pode ser configurado como Túnel ou Transporte. O AH tem restrições de uso quando em conjunto com o NAT (Network Address Translation). Ele calcula os hashes para garantir a integridade utilizando HMAC-MD5 ou HMAC-SHA-1. O processo de autenticação realizado pelo AH ocorre na seguinte ordem: 1. O cabeçalho IP e o payload de dados passam pelo processo de hash usando a chave secreta compartilhada. 2. O hash constrói um novo cabeçalho AH, que é inserido no pacote original. 3. O novo pacote é transmitido para o roteador Ipsec remoto. 4. O roteador remoto faz o mesmo processo passando por um hash o cabeçalho IP e o payload (dados) usando o sua chave compartilhada e comparando os dois hashes. Se os resultados calculados forem iguais o pacote foi autenticado. Quando configurado o IPSec (com ESP ou AH) o tamanho do pacote aumenta, variando de acordo com as opções selecionadas. No máximo são adicionados 58 bytes (quando usando ESP com autenticação) por pacote.

Ambos os protocolos suportam a proteção anti-replay ou “anti-replay protection”, a qual verifica se cada pacote é único e não repetido. Pacotes IPSec são protegidos pela comparação do número de sequência dos pacotes recebidos e uma janela deslizante no host de destino ou gateway de segurança, similar ao que o TCP realiza. Um pacote cujo número de sequência é inferior a janela deslizante é considerado um pacote atrasado ou uma duplicata, nesse caso ele será descartado.


   

 

 



   

    

   



Página 336

 

 

  


3.3 Protocolo IKE (Internet Key Exchange) O IKE é um protocolo híbrido que fornece para o IPSec a autenticação dos Peers ou pares, negociação do IKE, IPSec security associations e estabelecimento de chaves que são usadas pelos protocolos de criptografias. Os parâmetros negociados entre dois dispositivos são conhecidos como uma associação de segurança (Security Association ou SA). Além disso, o IKE aparece nas configurações como ISAKMP. Ao invés de transmitir as chaves diretamente através de uma rede, o compartilhamento de chaves IKE é calculado com base na troca de uma série de pacotes de dados. Isso previne que um terceiro decifre as chaves, mesmo que esse terceiro capture todos os dados trocados que foram utilizados para calcular as chaves. O IKE funciona sobre UDP na porta 500 e está definido na RFC 2409. Conforme mencionado, ele é um protocolo híbrido que combina o Internet Security Association and Key Management Protocol (ISAKMP) e o método de troca de chaves Oakley e Skeme (Secure Key Exchange Mechanism). O ISAKMP define o formato da mensagem, a mecânica do protocolo de troca de chave e o processo de negociação para construir uma SA IPsec. O ISAKMP não define como as chaves são gerenciadas ou compartilhado entre os dois pares IPsec. Já o Oakley e Skeme têm cinco grupos definidos, dos quais os roteadores Cisco suportam o Grupo 1 ou DH1 (chave de 768 bits), Grupo 2 ou DH2(chave de 1024 bits) e Grupo 5 ou DH5 (chave de 1536 bits). O IKE estabelece a comunicação segura entre os pares VPN em duas fases. Na primeira fase ocorre a troca a negociação das políticas do IKE para realização da troca das chaves de maneira segura e autenticação dos pares de equipamento VPN. Na segunda fase o IKE processa o ISAKMP para negociar as políticas do IPSec e estabelecimento do canal de comunicação seguro para troca de informação entre os pares.


   

 

 



   

    

   



Página 337

 

 

  


3.3.1 Modos de Operação do IKE

Existem 3 modos para comunicação e estabelecimento das fases chamados de modo principal (main mode), modo agressivo (agressive mode) e modo rápido (quick mode). A fase 1 pode ser estabelecida nos modos principal ou agressivo e normalmente a fase 2 se dá em modo rápido. Veja breve descrição abaixo: 





Main Mode: Para que a Fase um seja estabelecida com sucesso é necessário que uma série de requisições seja enviada entre os Gateways vpn, o método normal dessa negociação chama-se Main Mode. Esse Método possui uma latência maior, pois depende do envio e recebimento de vários pacotes para a negociação, devido a essa maior quantidade de requisições efetuadas sua segurança é maior. Aggressive Mode: Muitos fabricantes utilizam esse modo de negociação devido a ter uma menor latência, pois envia menos requisições para estabelecer a fase 1, ISAKMP-S. Esse modo, chamado de Aggressive Mode, reduz a quantidade de pacotes enviados e requer mais CPU, pois tarefas relacionadas ao Diffie Hellman precisam ser concluídas antes do primeiro pacote ser reenviado. Devido a esse problema este método de negociação está sujeito a um Denial of Service, enviando ao IPSEC simples pacotes solicitando uma ISAKMP-SA. Quick Mode: Após a fase I (ISAKMP SA) ser concluída a Fase 2 (IPsec SA) pode iniciar, para isso ela utiliza o Quick Mode para negociar parâmetros de criptografia.

A grande vulnerabilidade do Aggressive Mode é que o hash da chave PSK é enviado antes da Encriptação ser habilitada, logo, esse pacote pode ser capturado e uma ferramenta de brute force ou de dicionário pode obter a Chave utilizada. Já no Main mode o hash só é enviado após a encriptação ser habilitada. Com Aggressive Mode o pacote inicial da negociação contém todos os dados necessários para a fase 1 e o IPSEC remoto apenas verifica se pode efetuar ou não a solicitação. Dessa forma também está vulnerável a um ataque man-in-the-middle, caso esse pacote seja interceptado, um atacante pode obter uma conexão VPN válida. O Agressive Mode consome menos recursos de rede, devido fazer menos requisições, porém requer mais CPU por ter que processar a SA inteira antes de terminar a Fase I. O Main Mode consome mais recursos de rede, por enviar mais requisições, por outro lado consome menos CPU, por processar a SA aos poucos, conforme as requisições são recebidas/enviadas. Maioria das implementações de VPN atuais da Cisco utilizam o Main Mode como padrão de troca de chaves.


   

 

 



   

    

   



Página 338

 

 

  


3.3.2 Main Mode

O Main Mode utiliza 6 trocas de mensagens, e por isso é mais lento que o Agressive Mode. 





Mensagens 1 e 2 ou primeira troca: Usadas para garantir a segurança do meio e verificar se os peers estão de acordo. Mensagens 3 e 4 ou segunda troca: Utilizam o DH para gerar uma shared secret que é enviada para o outro peers, que devolve com sua identidade. Esta chave é usada para gerar outras chaves do processo. Mensagens 4 e 5 ou terceira troca: Faz a verificação da identidade do peer remoto.

No main mode a primeira troca (first exchange) entre o equipamento VPN que está iniciando (initiator) a sessão e o que está recebendo a sessão (responder) estabelece a política de segurança básica. Os pares negociam e concordam com os algoritmos e hashes que serão usados para proteger as comunicações do IKE. Ao invés de negociar individualmente cada protocolo, os protocolos são agrupados em conjuntos, chamados de conjuntos de política IKE (IKE Policy). Os conjuntos de política IKE são trocados no início da sessão. Veja a figura ao lado. O processo de troca e escolha da política se dá com o initiator primeiro transmitindo as propostas de esquemas de criptografia e de autenticação que serão utilizadas. O responder ao receber essa proposta procura por uma política ISAKMP que satisfaça a proposta do initiator. O responder escolhe uma proposta que seja mais adequada para a política recebida e envia para o initiator. Se uma política correspondente é encontrada entre os pares, a Fase 1 do IKE continua, mas caso nenhuma correspondência for encontrada o túnel é desativado. As políticas são configuradas localmente e os números que designam cada uma não precisam ser iguais dos dois lados, apenas os conteúdos devem bater. Normalmente em ligações pontoa-ponto existirá apenas uma política e em casos onde existem mais opções de conexão, como em topologias hub-and-spoke, pode ser necessária a configuração de várias políticas no concentrador VPN.


   

 

 



   

    

   



Página 339

 

 

  


Na segunda troca (second exchange) acontece a criação e troca das chaves DH entre os dois equipamentos. Conforme já estudamos, o DH permite que duas partes que não têm conhecimento prévio da outra chave, criem uma chave secreta compartilhada sobre um canal de comunicação inseguro, como a Internet. Os dois pares executam o protocolo de troca de chaves DH para adquirir diversos parâmetros relacionados às chaves de criptografia e hash necessários para o IKE e o IPSec. Vários níveis de trocas de chaves DH estão disponíveis no software Cisco IOS: 



 

DH Grupo 1 - Resulta em uma chave 768 bits. Esse grupo é a escolha usual quando o algoritmo de criptografia é o DES. DH Grupo 2 - Resulta em uma chave 1024 bits. Esse grupo é a escolha usual quando se usa 3DES para criptografia. DH Grupo 5 - Cria uma chave 1536 bits, normalmente usado com AES. DH Grupo 7 (Elliptic Curve Cryptography ou ECC) - geração de chaves IPSec de 163 bits. Este grupo foi criado para ser utilizado com hosts de baixa capacidade de processamento, como os PDAs.

Cada usuário deve ser autenticado antes do caminho de comunicação ser considerado seguro, essa é a função da última troca (terceira troca ou third exchange) da Fase 1 do IKE: autenticar o equipamento remoto. O initiator e o destinatário podem se autenticar utilizando três métodos:   

PSK Assinatura RSA RSA nonce criptografado

Na Fase 1 as negociações das SA’s são bidirecionais, o que significa que os dados podem ser enviados e recebidos utilizando a mesma chave de criptografia e mesmo que haja uma “espionagem” dos dados transmitidos dificilmente o atacante conseguirá decriptografar as informações sem essa chave. 3.3.3 Agressive Mode

Já o Agressive Mode utiliza apenas 3 trocas de mensagens, chamadas de primeira (first exchange), segunda (second exchange) e terceira troca (third exchange), fazendo a identificação do peer antes de criar um canal seguro. É o modo de operação padrão dos equipamentos Cisco. Vamos analisar as fases do modo agressivo. Veja um resumo da troca dos pacotes, conforme figura a seguir.


   

 

 



   

    

   



Página 340

 

 

  








Primeiro pacote - O iniciador envia todos os pacotes necessários para a negociação de SA na primeira mensagem, incluindo sua chave pública via DH. Segundo pacote - O destinatário responde com os parâmetros aceitáveis (informações de autenticação e sua chave pública DH). Terceiro pacote - O iniciador em seguida, envia uma confirmação de que recebeu essa informação.

Finalizada a fase 1 os pares devem estabelecer as políticas do IPSec para estabelecer o canal seguro para transmissão dos dados, pois a fase 1 foi apenas para a realização da troca das chaves e autenticação dos pares. Portanto, o objetivo da Fase 2 do IKE é negociar os parâmetros de segurança IPsec que serão utilizados para proteger o túnel IPsec. O IKE na Fase 2 utilizará o modo rápido (quick mode) e só pode ocorrer após IKE estabelecer o túnel seguro na Fase 1. As SAs são negociadas pelo processo do ISAKMP em nome do IPsec, que necessita de chaves de criptografia para a operação. Nesta fase o SA que usa IPsec são unidirecionais, portanto, uma troca de chave é necessária para cada fluxo de dados. A Fase 2 do IKE executa as seguintes funções: 

  

Negocia parâmetros de segurança IPsec, conhecidos como conjunto de transformação dos túneis Ipsec (IPSec transform sets). Estabelece as SAs para o IPsec. Periodicamente renegocia as SAs do IPsec para garantir a segurança. Opcionalmente realiza uma troca adicional de chaves utilizando o algorítmo DH.

3.3.4 Resumo das fases de estabelecimento do IKE

Veja na figura a seguir uma ilustração resumindo as fases do IKE.

Resumindo, o que é negociado na fase 1 do IKE? H: Hash. A: Authentication – método de autenticação. G: DH group – grupo dieff-helman L: Lifetime – tempo de vida do túnel IKE fase 1 E: Encryption – algoritmo de criptografia a ser utiliza no túnel IKE fase 1     


   

 

 



   

    

   



Página 341

 

 

  


E para a fase 2 do IKE o que será necessário negociar? Basicamente os mesmos parâmetros, porém agora para formar o túnel principal, o que irá realmente proteger os dados. 3.4 Fases de Estabelecimento de uma VPN IPSec Uma VPN IPSec tem 5 fases entre seu estabelecimento e finalização: Identificação do tráfego interessante, IKE fase 1, IKE fase 2, transferência de dados e fim do túnel IPSec (veja figura ao lado). Abaixo segue uma breve explicação de cada fase. 1) Tráfego interessante: É o tráfego que deve ser criptografado, geralmente identificado através de Access-lists padrões ou estendidas. 2) IKE fase 1: Basicamente tem a função de negociar as políticas que serão utilizadas, autenticar os peers e fechar um túnel seguro por onde serão configurados os demais parâmetros. Pode trabalhar em Main Mode ou Agressive Mode. Podemos dizer que é um “primeiro túnel”, para proteger as mensagens de negociação para o túnel principal. Opções do IKE fase 1:     

Algoritmo de criptografia: DES, 3DES, AES Algoritmo Hash: MD5, SHA-1 Método de autenticação: Pré Share, RSA Signature Key Exchange: DH group 1, group 2, group 5 IKE SA lifetime: até 86400 segundos

3) IKE fase 2: É a negociação do “segundo túnel”. São definidos os parâmetros do IPSec e transform sets, são estabelecidos IPSecs SAs, que são renegociados de tempos em tempos, e pode também ocorrer a troca do DH (opcional). O Security Association (SA) é uma conexão entre os dois peers que determina quais serviços do IPSec estão disponíveis naquela conexão (tipo de algoritmo de criptografia e autenticação utilizada, endereço IP, tempo de vida da chave e demais opções). São unidirecionais e para um túnel VPN são criados dois SAs. Lembre que o IPSec pode trabalhar de duas maneiras: Túnel e Transporte. O modo túnel é o padrão, e com ele o pacote inteiro é criptografado e um novo cabeçalho é criado. Já no modo transporte o cabeçalho não é alterado, sendo criptografado apenas os dados. Opções do IKE fase 2:   

Algoritmo de criptografia: DES, 3DES, AES Autenticação: MD5, SHA-1 SA lifetime: até 28.000 segundos

4) Transferência de dados: Após finalizada o IKE fase 2 o tráfego começa a ser enviado pelo túnel, de forma segura (criptografado). 5) Fim do túnel IPSec: O túnel é finalizado quando a SA é deletada (manualmente) ou ocorre o timeout, que pode ser configurado para ocorrer após um determinado espaço de tempo sem transmissão de dados ou após uma quantidade específica de dados transmitidos.


   

 

 



   

    

   



Página 342

 

 

  


Tanto o IKE SA e o IPSec SA têm um tempo de vida útil, ao se aproximar desse tempo os extremos IPSec devem criar novos parâmetros, criando novos IKE E IPSec SAs para a conexão. Geralmente, o tempo de vida útil não é maior que um dia. Trata-se do parâmetro “SA Lifetime” citado nas opções das fases 1 e 2 do IKE. 4 Planejando a Implantação de uma VPN IPSec Antes de configurar uma VPN ou qualquer implementação que formos fazer é importante iniciar planejando, principalmente com uma VPN pela quantidade de dados que teremos que configurar e definir em ambos os lados para que tenhamos sucesso ao fechar essa VPN. O planejamento da VPN deve iniciar com a definição dos protocolos que vamos utilizar na fase 1 e fase 2 do IKE e identificar o tráfego que desejamos criptografar (tráfego interessante). Na topologia abaixo podemos identificar que devemos criptografar os dados que serão trocados entre as redes 10.0.0.0/24, pertencente a R1, e 192.168.10.0/24 pertencente a R2 em ambas as direções, ou seja, fluxo de R1 para R2 e R2 em direção a R1 também (tráfego bidirecional).


   

 

 



   

    

   



Página 343

 

 

  


Para a fase 1 do IKE precisamos definir os seguintes parâmetros:     

H: Hash MD5 (128 bits) ou SHA-1 (160 bits). A: Autenticação via PSKs (chave pré-compartilhada) ou certificado digital. G: Para o grupo DH podemos utilizar os grupos 1, 2 ou 5 em maioria dos roteadores L: O tempo de vida ou Lifetime padrão é de 1 dia. E: A criptografia para o IKE fase 1 pode ser DES, 3DES ou alguns tipos de AES.

Para a fase 2 precisaremos definir o hash e a criptografia (encryption) no mínimo, pois podemos utilizar os padrões para o lifetime. As políticas do IKE fase 2 são chamadas transform sets. Com esses dados temos condições de configurar a VPN nas duas pontas, ou seja, em cada um dos sites que queremos conectar através de Internet utilizando um canal seguro! 5 Configurando uma VPN IPSec via CLI Para configurar uma VPN utilizando IPSec em roteadores Cisco você deve seguir basicamente os 5 passos abaixo. 









Passo 1 - Defina os parâmetros que serão utilizados para o túnel IKE da Fase 1 (isto é, o ISAKMP túnel). Este conjunto de parâmetros é chamado de política de ISAKMP ou “ISAKMP Policy”. Passo 2 - Defina os parâmetros que serão utilizados para o túnel IKE da Fase 2 (isto é, o IPsec túnel). Este conjunto de parâmetros é chamado de “transform set”. Passo 3 - Crie uma ACL para identificar o tráfego "interessante", que deve ser protegido e enviado através do túnel Ipsec de maneira segura. Passo 4 - Crie um mapa de criptografia ou “crypto map” para agrupar logicamente os parâmetros configurados nas etapas anteriores e insira na interface que se conecta ao par Ipsec correto, ou seja, o mapa de criptografia deve ser aplicado na interface correta. Passo 5 - Opcionalmente crie uma ACL adicional para bloquear o tráfego não interessante, impedindo que ele atravesse a VPN. Normalmente as regras de firewall já garantem essa etapa.

A seguir vamos analisar as configurações passo a passo. Apesar do foco do CCNA Security para criação de VPNs ser através do CCP vamos iniciar pela CLI para que você tenha um maior domínio do assunto, pois assim facilita bastante o entendimento da configuração via CCP. Além disso, muitas empresas não permitem o gerenciamento através de ferramentas como CCP, nesse caso você precisará utilizar a CLI para configurar uma VPN e fica “estranho” dizer para a gerência: “Desculpa, mas sei apenas utilizando o CCP!”. Vamos utilizar a topologia do tópico anterior para esse exemplo.


   

 

 



   

    

   



Página 344

 

 

  


5.1 Passo 1 - Configuração Parâmetros da Fase 1 do IKE Entrando no modo de configuração dos parâmetros do ISAKMP, onde o número 1 é apenas o identificador da política (podemos ter mais que uma): R1(config)#crypto isakmp policy 1

Definindo o método de autenticação para chave compartilhada: R1(config-isakmp)#authentication pre-share

Configurando o algoritmo de hash SHA, poderia ser também o MD5 R1(config-isakmp)#hash sha

Definindo a criptografia para fase 1 do IKE com o AES-128 bits: R1(config-isakmp)#encryption aes 128

Configurando a troca de chaves Diffie-Hellman grupo 2: R1(config-isakmp)#group 2

Configurando o tempo de vida do Security Association em segundos: R1(config-isakmp)#lifetime 86400

Agora saia do modo de config do ISAKMP e configure a chave compartilhada para comunicação com o outro peer: R1(config)#exit R1(config)#crypto isakmp key DlteC-Secret address 200.210.50.10 R1(config)#exit

Agora vamos configurar o roteador R2, porém sem as explicações. Note que no comando “crypto isakmp key” foi utilizado uma senha que deve ser a mesma dos dois lados e o IP é o do par remoto. R2#conf term


   

 

 



   

    

   



Página 345

 

 

  


R2(config)#crypto isakmp policy 1 R2(config-isakmp)#authentication pre-share R2(config-isakmp)#hash sha R2(config-isakmp)#encryption aes 128 R2(config-isakmp)#group 2 R2(config-isakmp)#lifetime 86400 R2(config-isakmp)#exit R2(config)#crypto isakmp key Dletc-Secret address 200.200.200.1 R2(config)#exit Router2#

Na tabela a seguir temos um resumo das opções possíveis de configurar dentro da política do ISAKMP na fase 1.

5.2 Passos 2, 3 e 4 - Configuração dos Parâmetros da Fase 2 do IKE, Tráfego Interessante e Crypto-Map Agora vamos configurar o túnel IPSec propriamente dito, a fase anterior diz respeito apenas à troca das chaves e autenticação. O primeiro passo é criar o transform-set, onde são definidos os parâmetros usados pelo túnel IPSec, sendo utilizado nesse exemplo o ESP-AES para criptografia e ESP-SHA-HMAC para hash. O nome dado para a transform-set será MYSET. R1(config)#crypto ipsec transform-set MYSET esp-aes esp-sha-hmac R1(cfg-crypto-trans)#exit

Depois vamos criar a ACL definindo qual será o tráfego protegido pelo túnel IPSec, ou seja, o tráfego interessante: R1(config)#access-list 101 permit ip 10.0.0.0 0.0.0.255 192.168.10.0 0.0.0.255

Agora vamos criar o Crypto Map, que é o agrupamento das regras para construção do túnel, com o nome R1_TO_R2 e ID (identificador) 10: R1(config)#crypto map R1_TO_R2 10 ipsec-isakmp


   

 

 



   

    

   



Página 346

 

 

  


Dentro desse modo de crypto-map é necessário apontar o peer remoto e aplicar a ACL que definiu o tráfego interessante: R1(config-crypto-map)#set peer 200.210.50.10 R1(config-crypto-map)#match address 101

Após essas etapas, ainda em modo de crypto-map, vamos ligar a transform-set ao crypto-map: R1(config-crypto-map)#set transform-set MYSET R1(config-crypto-map)#exit R1(config)#

Agora vamos aplicar na interface WAN de R1, a qual será a ponta 1 do túnel IPSec: R1(config)#interface serial 0/0/0 R1(config-if)#crypto map R1_TO_R2 R1(config-if)#end R1#

Agora vamos à configuração da fase 2 do IKE para o router R2. Router2#conf term R2(config)#crypto ipsec transform-set MYSET esp-aes esp-sha-hmac R2(cfg-crypto-trans)#exit R2(config)#access-list 100 permit ip 192.168.10.0 0.0.0.255 10.0.0.0 0.0.255 R2(config)#crypto map R2_TO_R1 10 ipsec-isakmp R2(config-crypto-map)#set peer 200.200.200.1 R2(config-crypto-map)#match address 100 R2(config-crypto-map)#set transform-set MYSET R2(config-crypto-map)#exit R2(config)#interface serial 0/0/0 R2(config-if)#crypto map R2_TO_R1

A seguir temos um resumo das opções de transform-set possíveis de se configurar e seus nomes no IOS da Cisco. Lembre que esses valores podem variar de acordo com a versão do IOS escolhida.


   

 

 



   

    

   



Página 347

 

 

  


Uma informação interessante é que fase 2 as informações das chaves trocadas pelo DH na fase 1 do IKE são reaproveitadas por padrão. Por isso, aqui temos uma oportunidade de aumentar a segurança utilizando o recurso de Perfect Forward Secrecy (PFS) para rodar novamente o DH e refazer a troca das chaves para a fase 2 , por isso o nome é PFS ou “Troca Perfeita das Chaves”, em português. Isso é feito dentro do Crypto map conforme exemplo abaixo onde vamos utilizar DH do grupo 2 para realizar a troca segura das chaves. R1(config)#crypto map R1_TO_R2 10 ipsec-isakmp R1(config-crypto-map)#set peer 200.210.50.10 R1(config-crypto-map)#match address 101 R1(config-crypto-map)#set transform-set MYSET R1(config-crypto-map)#set pfs group2 R1(config-crypto-map)#exit

Esse é um recurso que a criação padrão através do wizard do CCP que realizaremos mais para frente não permite.


   

 

 



   

    

   



Página 348

 

 

  


5.3 Testanto o Túnel Para testar o túnel você pode dar um ping estendido entre os roteadores e verificar as sessões de IPSec, conforme comandos mostrado a seguir. R1#ping Protocol [ip]: Target IP address: 192.168.10.2 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 10.0.0.1 Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.10.1, timeout is 2 seconds: Packet sent with a source address of 10.0.0.1 .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 164/209/296 ms

Agora com os comandos “show crypto engine connections active” e “show crypto session” podemos verificar os parâmetros das conexões e seus estados. Veja a saída dos comandos abaixo. Router1#show crypto engine connections active Crypto

Engine

Connections

ID

Interface Type Algorithm Encrypt 1 Se1/0 IPsec AES+SHA 0 2 Se1/0 IPsec AES+SHA 4 1001 Se1/0 IKE SHA+AES 0 0

Decrypt IP-Address 4 200.200.200.1 0 200.200.200.1 200.200.200.1

Veja no comando acima que os 4 pacotes do ping aparecem criptografados (encrypt) e decriptografados (decrypt), além disso aparecem os protocolos utilizados nas fases do IKE. R1#show crypto session Crypto session current status Interface: Serial1/0 Session status: UP-ACTIVE Peer: 200.210.50.10 port 500 IKE SA: local 200.200.200.1/500 remote 200.210.50.10/500 Active IPSEC FLOW: permit ip 10.0.0.0/255.255.255.0 192.168.10.0/255.255.255.0 Active SAs: 2, origin: crypto map

Note que no comando acima a VPN está ativa (UP-ACTIVE), no parâmetro Peer você pode ver o par que está conectado via VPN com o R1 e a porta UDP que está sendo utilizada, nesse caso é a padrão de número 500. Além disso, você pode ver no IPSec FLOW que rede está enviando dados, pois você poderia ter várias redes e tipos de tráfego interessante permitidos de maneira mais granular, ou seja, poderia deixar passar HTTP, FTP e E-mail apenas e você teria 3 linhas de ACL.


   

 

 



   

    

   



Página 349

 

 

  


Outro comando que pode ser utilizado é o “debug crypto isakmp”. Com esse comando você consegue ver as negociações das duas fases das chaves e identificar problemas, porém ele é um pouco mais complexo de analisar. Outro teste simples de saber se o túnel está realmente sendo utilizado para envio dos pacotes entre R1 e R2 seria com a realização de um traceroute. 6

Configurando uma VPN IPSec via CCP

A configuração do IPsec baseada em CLI pode se tornar uma tarefa difícil para os administradores de rede que não estão familiarizados com a quantidade de parâmetros e opções do IPsec e o Cisco CCP oferece um assistente de configuração VPN site-to-site (wizard) que pode ajudar você a configurar uma VPN mais facilmente. Para fazer a configuração vá até “Configure > Security > VPN > Site-to-Site VPN”, chegando nessa etapa escolha “Create a VPN Site-to-site” e “Lauch the selected Task”.

O CCP oferece as opções de “Quick Setup wizard” e “Step-by-Step wizard”, os quais dependendo do tipo de VPN a ser criada necessitarão ainda de alguns comandos préconfigurados via CLI, como por exemplo, definições de PKI para fazer autenticação via RSA (certificado digital).


   

 

 



   

    

   



Página 350

 

 

  


Se você clicar no View Deafults do quick setup terá a seguinte saída abaixo, portanto você pode fazer um túnel com as características mostradas sem muita dificuldade utilizando o 3DES em ambas as fases do IKE.

Se você lembra, no exemplo via CLI utilizamos chaves pré-compartilhadas ou PSK para a autenticação. Nesse segundo exemplo, agora via CCP, vamos configurar utilizando certificados digitais ou RSA. No capítulo 9 ensinamos a criar um CA Server, o certificado raiz e também como fazer para gerar certificados nos clientes, tanto em roteadores como no ASA. Portanto, nesse exemplo via CCP vamos utilizar a autenticação via RSA, para ter os certificados basta inserir um CA Server, como fizemos no exemplo do capítulo 9, e gerar os certificados digitais dos roteadores, também como fizemos naquele exemplo. Aí dentro do CCP vamos utilizar RSA como autenticação ao invés de PSK. Você vai ver que é simples durante o passo a passo. Vamos aproveitar o exemplo para mais uma vez rever o planejamento, parâmetros das VPNs e fases do IKE!


   

 

 



   

    

   



Página 351

 

 

  


6.1 Planejando a Implantação via CCP O planejamento da VPN é o mesmo tanto no CCP como via CLI, temos que definir os parâmetros das fases 1 e 2 do IKE. Vamos utilizar a mesma topologia anterior.

Portanto uma empresa com duas unidades quer conectar as redes LAN de R1 e R2 através de uma VPN IPSec. Da topologia já conseguimos tirar vários dados, tais como os peers (pares) que irão fechar o túnel (R1: 200.200.200.1 e R2: 200.210.50.10), a rede que utilizará a VPN em R1 10.0.0.0/24 e em R2 192.168.10.0/24. Vamos supor nesse exemplo que o tráfego interessante (gatilho para acionar a VPN) será todos os protocolos, não vamos fazer filtragem. Normalmente a porta 500 do UDP é utilizada para negociação do IKE fase 1 e se a rede utiliza NAT, o que normalmente acontece na prática, a porta UDP 4500 é utilizada na tradução desses pacotes. Além disso, é importante saber que se utilizarmos o cabeçalho do ESP ele é transportado direto no IP com o número de protocolo 50, já o Authentication Header (AH) utiliza o protocolo IP número 51. Como já falamos anteriormente, se houver NAT o ESP é escondido através de um datagrama UDP na porta 4500. Porque tudo isso é importante? Simples a resposta, para que você possa ajustar suas ACLs ou firewall que eventualmente pode estar ativado na entrada da Internet. É importante lembrar que na prática regras de firewall são os maiores causadores de problemas no estabelecimento de VPNs. Para o IKE fase 1 temos as seguintes opções: Hashing  MD5 com 128-bit ou SHA1 com160-bit (mais seguro) Authentication (autenticação)  Pre-shared Key (PSK) ou RSA-Sigs (digital signatures – mais seguro) Group (grupo DH para troca de chaves)  1, 2 e 5 (mais seguro) Lifetime (tempo de vida)  86400 seconds (1 dia por padrão) ou menos que um dia (mais seguro) Encryption (criptografia)  3DES ou AES-128 192 ou 256 (mais seguro é AES com 256 bits)  

 



Vamos utilizar então a política mais forte ou mais segura: Hashing: SHA Authentication: RSA-Sigs (PKI) DH group: 5 Lifetime: 3600 segundos ou 1 hora Encryption: AES-256     


   

 

 



   

    

   



Página 352

 

 

  


Para a fase 2 do IKE temos que definir as seguintes opções: Endereços dos Peers (pares)  configurados na Crypto map e devem ser alcançáveis por ambos os roteadores para que eles possam negociar as fases do IKE e fechar o túnel VPN. Tráfego interessante a ser criptografado  configurado na Crypto ACL define o tráfego que pode passar através da VPN. Algoritmo de criptografia  configurado na Transform set e referenciado a uma crypto map utilizando DES, 3DES, AES ou todas as opções (os roteadores negociam e escolhem). Não precisa ser o mesmo da fase 1. Método de Hashing (HMAC)  configurado na Transform set e referenciado na crypto map MD5 ou SHA utilizando HMAC, precisa ser a mesma em ambos os pares. Lifetime (data ou período de tempo)  configurado globalmente no comando crypto ipsec securityassociation lifetime ... Precisa ser a mesma em ambos os roteadores e pode ser expressa em segundos ou número de kbytes. Perfect Forward Secrecy (PFS)  configurado na Crypto map e define se utilizamos ou não um novo DH na fase 2 ou utilizamos os mesmos parâmetros criados na fase 1. Você pode escolher na fase 2 os grupos DH 1, 2 ou 5. Interface de saída da VPN  uma Crypto map aplicada na interface de saída onde os pacotes estarão criptografados e passando pela rede pública. 













Vamos utilizar os seguintes parâmetros para o IKE fase 2: IPs dos pares que fecharão a VPN pela Internet R1: 200.200.200.1 e R2: 200.210.50.10 Tráfego a ser protegido (bidirecional): R1 entre origem 10.0.0.0/24 para o destino 192.168.10.0/24 e em R2 de 192.168.10.0/24 para 10.0.0.0/24. Criptografia: AES-192 HMAC: SHA Lifetime: padrão Interface de saída dos roteadores: serial 1/0 em ambos PFS: DH grupo 2 (precisaremos ajustar manualmente ou depois via CCP)  

    


   

 

 



   

    

   



Página 353

 

 

  


6.2 Preparando os roteadores: certificado digital e NTP Como vamos utilizar chaves RSA ou certificados digitais é importante que os relógios dos roteadores estejam sincronizados com o CA Server, pois podemos ter problemas relacionados à expiração dos certificados emitidos, por isso comece ajustando as horas dos roteadores de preferência utilizando NTP, assim como mostramos no exemplo do capítulo 9. Via CCP o NTP é configurado em “Configure > Router > Time > NTP and SNTP”.

O certificado digital (contando que o CA já está corretamente configurado e com o IP 200.0.0.1) é só seguir os mesmos passos mostrados no capítulo 9. Vamos resumir: R1(config)#ip domain name cisco.com R1(config)#crypto key generate rsa The name for the keys will be: R1.cisco.com Choose the size of the key modulus in the range of 360 to 2048 for your General Purpose Keys. Choosing a key modulus greater than 512 may take a few minutes. How many bits in the modulus [512]: 1024 % Generating 1024 bit RSA keys, keys will be non-exportable...[OK] Chapter 20: Implementing IPsec Site-to-Site VPNs 505 R1(config)#crypto pki trustpoint CA R1(ca-trustpoint)#enrollment URL http://200.0.0.1 R1(ca-trustpoint)#exit R1(config)#crypto pki authenticate CA Certificate has the following attributes: Fingerprint MD5: B1AF5247 21F35FE3 0200F345 7C20FBA0 Fingerprint SHA1: F5BB33E3 1CB5D633 0DF720DF 8C72CD48 E744CF5B % Do you accept this certificate? [yes/no]: yes Trustpoint CA certificate accepted. R1(config)#crypto pki enroll CA % % Start certificate enrollment .. % Create a challenge password. You will need to verbally provide this password to the CA Administrator in order to revoke your certificate. For security reasons your password will not be saved in the configuration. Please make a note of it. Password: senhasecreta


   

 

 



   

    

   



Página 354

 

 

  


Re-enter password: senhasecreta % The subject name in the certificate will include: R1.cisco.com % Include the router serial number in the subject name? [yes/no]: no % Include an IP address in the subject name? [no]: no Request certificate from CA? [yes/no]: yes % Certificate request sent to Certificate Authority % The 'show crypto pki certificate verbose CA' command will show the fingerprint. CRYPTO_PKI: Certificate Request Fingerprint MD5: E8E01D26 862C811C 32CB3FCF 858BAF5F CRYPTO_PKI: Certificate Request Fingerprint SHA1: E3133B07 07DEA5FD BC6A1D64 DBC9F71F 3CACA767 %PKI-6-CERTRET: Certificate received from Certificate Authority

O mesmo deve ser feito em R2 para que ambos tenham os certificados digitais emitidos e validados pelo CA Server. Agora que os roteadores têm as chaves RSA para autenticação vamos à configuração da VPN. 6.3 Configuração da VPN via CCP Para configurar a VPN, como já mencionamos anteriormente, vá no CCP em “Configure > Security > VPN > Site-to-Site VPN” , escolha o wizard para Site-to-Site VPN e clique em Launch the Selected Task. Vamos fazer a configuração utilizando o Step-by-Step Wizard e clicar no botão Next, conforme já mostrado nas telas anteriormente. Na segunda tela vamos escolher a interface de saída onde conectamos a VPN (outbound) para as fases 1 e 2, o endereço do roteador remoto e o método de autenticação, que nesse caso vamos usar certificados digitais.

Clique em Next para configurar as políticas da fase 1 do IKE conforme planejado, veja a tela a seguir. Nessa tela se existirem políticas criadas elas serão mostradas e várias políticas podem ser utilizadas. Você não vai conseguir apagar pelo wizard, mas pode apagar as que não vai utilizar editando a VPN pelo CCP ou através da CLI.


   

 

 



   

    

   



Página 355

 

 

  


Terminando a configuração clique em OK e depois em Next para configurar o IKE fase 2, definindo a política para proteção dos dados. Chegando na tela clique em ADD e configure a política como planejado.

Note que a opção do PFS para a fase 2 do IKE não está mostrada no wizard. Agora clique em OK e NEXT. Vamos configurar a ACL e especificar o tráfego a ser criptografado na próxima tela.


   

 

 



   

    

   



Página 356

 

 

  


Em R1 a origem é a Local Network (10.0.0.0/24) e a rede remota (remote network) é a LAN de R2 192.168.10.0/24. Clique em Next para ver um resumo das configurações que serão aplicadas e finalizar o wizard clicando em Finish. Você pode aplicar a configuração no roteador, gravar em um arquivo ou cancelar a operação.


   

 

 



   

    

   



Página 357

 

 

  


A configuração da política da fase 1 do IKE via CLI seria a aplicada abaixo: R1(config)#crypto isakmp policy 1 R1(config-isakmp)#encr aes 256 R1(config-isakmp)#group 5 R1(config-isakmp)#lifetime 3600 R1(config-isakmp)#authentication rsa-sig R1(config-isakmp)#hash sha

Você pode verificar a política com o comando “show crypto isakmp policy”. A seguir vamos ver o equivalente da configuração da fase 2 do IKE e aplicação dessa política de VPN na interface de saída. R1(config)#crypto ipsec transform-set Fase-2-Pol esp-aes esp-sha-hmac R1(cfg-crypto-trans)#exit R1(config)#access-list 100 permit ip 10.0.0.0 0.0.0.255 192.168.10.0 0.0.0.255 R1(config)#crypto map CCP_CMAP_1 1 ipsec-isakmp R1(config-crypto-map)#match address 100 R1(config-crypto-map)#set peer 200.210.50.10 R1(config-crypto-map)#set transform-set Fase-2-Pol R1(config-crypto-map)#set pfs group2 R1(config-crypto-map)#exit R1(config)#interface GigabitEthernet1/0 R1(config-if)#crypto map CCP_CMAP_1 R1(config-if)#exit

Note que o comando do PFS não foi aplicado pelo wizard, você teria que aplicá-lo posteriormente. Outro ponto interessante é que dependendo da versão de CCP utilizada, muitas regras de firewall, VPN e IDS aparecem com o nome CCP ou invés de CCP, por isso não estranhe. 6.4 Troubleshooting Básico em VPNs Para verificação da configuração e troubleshooting podemos utilizar os comandos já estudados para CLI: show crypto isakmp policy show crypto map show crypto isakmp sa show crypto ipsec sa show crypto engine connections active debug crypto isakmp      

Basicamente os problemas mais comuns são de configuração, pois temos parâmetros que devem bater em ambos os lados, por exemplo, se um lado estiver esperando criptografia 3DES e do outro lado AES128 o túnel não fecha, isso tanto para fase 1 como para fase 2, porém você pode ter acertado a configuração da fase 1 e errado na fase 2. Esse é o tipo de problema para ser cobrado na prova de certificação. Outro problema mais comum em campo é relativo a ACLs filtrando as portas UDP utilizadas pela VPN ou NAT transverso não funcionando, pois lembre-se que com NAT a porta UDP a ser utilizada é a 4500. O mais comum é recebermos a resposta do ping como U.U.U quando a VPN está com problemas, ou seja, o U representa que o roteador recebeu uma mensagem de ICMP unreachable porque a rede LAN remota realmente não pode ser alcançada via Internet sem a VPN, pois o IP das LANs são privativos e não roteados na Internet. A p o s t i l a / E - Bo o k d o C u r s o I I N S 6 4 0 - 5 5 4      

   

 

 



   

    

   



Página 358

 

 

  


A partir desse ponto podemos ativar o debug crypto isakmp para verificar o que está acontecendo na prática. Normalmente em exames nesse ponto você pode verificar as configurações em ambos os roteadores que algum parâmetro deve estar errado, por isso repetimos tanto o planejamento e o que deve ser definido em ambos os lados para que a VPN feche. Com o debug ativado você deve repetir o ping para a LAN remota, utilizando como origem o IP da sua LAN (ping estendido) e verificar se mensagens referentes ao IKE fase 1 serão mostrados na saída do debug. Se nada acontecer é porque ou o IKE fase 1 está ativo e não precisa ser negociado ou simplesmente o tráfego interessante não está ativando a VPN. Os principais problemas nesse caso podem ser: Interface down. Crypto map aplicada errada. Problemas de roteamento.   

Com o comando show crypto isakmp sa você pode verificar se existe um túnel fase 1 negociado e ativo. Você também pode com o show ip route verificar se existe problema de roteamento, porém isso já deveria ter sido visto antes de configurar a VPN! Uma tentativa na prática se tudo estiver aparentemente certo (configurações dos dois lados) é ativar e desativar o crypto-map na interface: R1(config)#int g1/0 R1(config-if)#no crypto map MYMAP R1(config-if)#crypto map MYMAP %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is OFF R1(config-if)#crypto map MYMAP

Após o procedimento mostrado acima verifique se o debug ainda está ativo (show debugging) e faça novamente o ping, dessa vez deve mostrar algo. Note a opção source no ping define que a origem dos pacotes deve ser a LAN de R1. Se o problema persistir você deve verificar os parâmetros em ambos os lados, corrigir o que está errado e quando o ping funcionar com o comando show crypto engine connections active você poderá verificar as conexões ativas. 7

Conceitos e Implantação do VPN SSL no Cisco ASA

Esse recurso de acesso VPN via SSL também é conhecido como “Clientless SSL VPN” ou WebVPN e permite acesso remoto a recursos da rede corporativa em a partir de qualquer localidade, sem a necessidade de configurações específicas ou até mesmo a instalação de clientes VPN nos computadores dos usuário remotos. Os usuários podem utilizar, por exemplo, acesso seguro via browser para utilizar recursos de rede. Esse recurso pode ser configurado na linha de dispositivos Adaptive Security Appliance (ASA) 5500 series ou em roteadores com Cisco IOS. Podemos ter três tipos de VPNs SSL: 1. Clientless SSL VPN: um cliente remoto utiliza um navegador de Internet (web browser) via SSL para acessar servidores HTTP ou HTTPS que estão situados em uma LAN Corporativa. Além disso, é possível acesso via navegador a arquivos do Windows utilizando Common Internet File System (CIFS). Um exemplo típico é acesso HTTP ao cliente Outlook Web Access (OWA).


   

 

 



   

    

   



Página 359

 

 

  


2. Thin-Client SSL VPN (Port Forwarding): através de um pequeno applet baseado em Java é disponibilizado para download para que um cliente remoto acesse de maneira segura via TCP à aplicações que utilizam portas estáticas, porém não pode ser via UDP. Exemplos de aplicações que podem utilizar esse tipo de acesso são POP3, SMTP, IMAP, SSH e Telnet. É preciso que o cliente tenha acesso de administrador na máquina local e não funciona com aplicações que utilizam portas de forma dinâmica, por exemplo, alguns tipos de servidores FTP. 3. SSL VPN Client (SVC-Tunnel Mode): nessa opção o usuário remoto faz o download de um pequeno cliente em seu computador, o qual permite acesso completo aos recursos internos da rede corporativa, assim como uma VPN tradicional de acesso remoto. O programa cliente pode ficar instalado permanentemente no computador do usuário ou ser removido de maneira segura quando a sessão for finalizada. O cliente é chamado de Cisco AnyConnect. O Clientless SSL VPN pode também ser configurado em roteadores com Cisco IOS com versão 12.4(6)T ou acima, na versão 15 do Cisco IOS será necessário a licença de Security. Apesar das VPNs tradicionais suportarem políticas de segurança e algoritmos de criptografia mais fortes que a VPN SSL, mesmo assim a flexibilidade desse tipo de solução está fazendo com que ela seja cada vez mais utilizada para acesso remoto seguro às redes corporativas. A VPN SSL é suportada em diversos sistemas operacionais, tais como Windows, Macintosh, Linux, Apple iOS, Android e Windows Mobile. 7.1 Protocolos SSL e TLS O Transport Layer Security (TLS) e o seu antecessor Secure Sockets Layer (SSL) são protocolos criptográficos que tem como objetivo fornecer segurança nas comunicações realizadas através da Internet para serviços como email (SMTP), acesso a páginas da Internet com protocolo seguro (HTTPS) e outros tipos de transferência de dados. Há algumas pequenas diferenças entre o SSL 3.0 e o TLS 1.0, mas o protocolo permanece substancialmente o mesmo. A primeira versão do SSL foi desenvolvida pela Netscape em 1994, sendo que o SSL versão 3.0 foi lançado em 1996. O TLS versão 1.0 foi padronizado da IETF originalmente definido pela RFC 2246. O termo "SSL" se aplica a ambos os protocolos, exceto se disposto em contrário. O protocolo SSL 3.0 também é conhecido como SSL3 e o TLS 1.0 como TLS1 ou ainda SSL3.1. As VPNs SSL da Cisco utilizam na realidade o TLS por trás das suas aplicações. O SSL/TLS pode utilizar o PKI ou infraestrutura de chaves públicas, podendo utilizar uma variedade de tipos de chaves e algoritmos de criptografia, os quais são negociados de forma similar ao que os roteadores utilizaram para formar canais seguros de comunicação.


   

 

 



   

    

   



Página 360

 

 

  


7.2 Estabelecimento de VPNs SSL O SSL é amplamente utilizado em diversas transações via Internet, tais como Internet Banking e outros acessos que exigem segurança e privacidade entre o servidor e o cliente, portanto antes de ir para a configuração das VPN vamos estudar um pouco sobre como o SSL flui em uma transação segura de maneira básica, pois assim entendermos melhor como a VPN irá funcionar. Vamos abaixo resumir a negociação do SSL no acesso HTTPS: 1. O cliente inicia a conexão utilizando TCP na porta de destino 443 e como origem uma porta alta dinâmica acima de 1023 com uma mensagem de SYN. 2. O three-way handshake normal é realizado para estabelecer a sessão TCP entre o servidor e o cliente. 3. Depois que o cliente inicia sua requisição de conexão o servidor responde com seu certificado digital, contendo sua chave pública. Esse processo é realizado através de uma troca de mensagens de Hello. 4. Nesse ponto o cliente terá que verificar a validade e a credibilidade do certificado e tomar a decisão de ir enfrente com a conexão ou não. Pensando em uma VPN seria o cliente decidindo se acredita ou não na credibilidade do servidor de SSL VPN. É aqui que o PKI entra em cena, pois o certificado deve estar assinado por uma autoridade certificador (certificate authority - CA) que o navegador de Internet do cliente deve confiar e validar a autenticidade. O cliente deve verificar a certificate revocation list (CRL – lista de certificados revogados), data de emissão e validade, quem emitiu o certificado e demais parâmetros para aí extrair a chave pública do certificado e continuar o processo. 5. O próximo passo é o cliente gerar a chave secreta que será utilizada para criptografar os dados enviados entre ele e o servidor. Para garantir que a chave seja transmitida de maneira segura o cliente criptografa a chave secreta antes de enviar ao servidor com a própria chave pública do servidor. 6. O servidor decriptografa a mensagem e envia e utiliza como sua chave privada, permitindo que a partir desse momento que ambos os dispositivos conheçam a chave secreta e possam utilizá-la no processo de criptografia. 7. A chave é utilizada para criptografar a sessão SSL, por isso é chamada de chave de sessão (session key). Veja a figura abaixo resumindo a operação a partir do passo 3. Note que após o handshake normal do TCP o cliente e o servidor trocam mensagens de Hello onde informações específicas do SSL são trocadas, há uma troca das chaves (Key Exchange), negociação do método de criptografia (Cipher Suite Negotiation) parecido com o processo feito pelo IKE negociando suas políticas, para aí sim o cliente começar a solicitar a página com o HTTP GET.


   

 

 



   

    

   



Página 361

 

 

  


7.3 Configurando SSL Clientless VPNs no ASA Vamos utilizar o ASA Security Device Manager (ASDM) para através de um Wizard possamos ativar de forma rápida e simples uma VPN SSL. Os passos gerais para configuração da VPN SSL utilizando o ASDM segue abaixo: 1. 2. 3. 4. 5. 6.

Abra o wizard para configuração específica da SSL VPN no ASDM Configure a URL para a VPN SSL e a interface Configure a autenticação do usuário Configure o group policy (política do grupo) Configure o “bookmark lists” Verifique se está tudo conforme planejado e teste a SSL VPN

No ASDM clique em Wizards na barra de menu e escolha “VPN Wizards”, depois selecione a opção Clientless SSL VPN Wizard .


   

 

 



   

    

   



Página 362

 

 

  


Clique em Next e você vai visualizar uma caixa de mensagens para especificar um profile de conexão para ser associado aos usuários que utilizarão a clientless SSL VPNs e a interface que os usuários vão se conectar inicialmente, a qual será uma interface externa (outside) normalmente ou com nível de segurança baixo no ASA.

Nessa mesma tela será preciso escolher o certificado digital, sendo que por padrão o ASA utiliza um certificado do tipo self-signed, ou seja, instalado no próprio dispositivo, porém é possível utilizar PKI e certificados emitidos por um CA Server e não receber aquela mensagem de que o certificado não é reconhecido. Além disso, aqui também teremos o endereço IP que deverá ser utilizado pelos clientes para utilizar o serviço. Uma vez tudo configurado basta clicar em Next. Na próxima página de configuração teremos as opções de autenticação que pode ser via AAA, utilizando um servidor externo, ou através de usuários criados no banco de dados local, inclusive podem até serem inseridos novos usuários e senhas nessa mesma página. Podemos integrar o ASA ao Access Control Server (ACS) ou Identity Services Engine (ISE), utilizando tanto RADIUS como TACACS+. Configure as opções planejadas e clique em Next.

Na próxima página teremos a configuração do group profile que pode ser utilizada para vários usuários, permitindo que eles tenham as mesmas permissões sem a necessidade de


   

 

 



   

    

   



Página 363

 

 

  


configuração um a um. O padrão é todos os usuários estarem vinculados ao “default group”. Faça as configurações e clique em Next.

Na próxima página você terá que definir se quer fornecer aos usuários autenticados na SSL VPN uma lista de links/URLs que apontam para serviços corporativos que estão atrás do ASA. Esses Bookmarks podem ser criados e reutilizados por múltiplos grupos. Aqui você precisa clicar em Manage, depois Edit e aí adicionar a lista para fazer o bookmark para os usuários. Dê OK, OK e depois Next para prosseguir.

Na próxima página o ASA mostrará um resumo da configuração e podemos finalizar clicando em Finish, aí você terá algumas mensagens de confirmação, a opção de ver a configuração que será aplicada na CLI e finalizará a tarefa.


   

 

 



   

    

   



Página 364

 

 

  


Abaixo segue o equivalente da configuração via CLI. asa1(config)#group-policy SSL_Group internal asa1(config)#ssl trust-point ASDM_TrustPoint0 outside asa1(config)#webvpn asa1(config-webvpn)#enable outside asa1(config-webvpn)#group-policy SSL_Group attributes asa1(config-group-policy)#vpn-tunnel-protocol ssl-clientless asa1(config-group-policy)#webvpn asa1(config-group-webvpn)#url-list value MyList asa1(config-group-webvpn)#exit asa1(config-group-policy)#exit asa1(config)#tunnel-group DlteC_IINS type remote-access asa1(config)#tunnel-group DlteC_IINS general-attributes asa1(config-tunnel-general)#default-group-policy SSL_Group asa1(config-tunnel-general)#tunnel-group DlteC _IINS webvpnattributes asa1(config-tunnel-webvpn)#group-alias SSL_VPN enable asa1(config-tunnel-webvpn)#group-url https://200.0.0.3/SSL_VPN enable

Para verificar as conexões vá até “Monitoring > VPN > VPN Statistics > Sessions” para visualizar as sessões em andamento. Nesse método um servidor Web deve estar vinculado ao acesso ou então um servidor com CIFS para acesso aos arquivos do Windows. Em laboratório você pode ativar o HTTPS em um roteador atrás do ASA para simular o servidor Web interno. No próximo tópico vamos fazer a configuração do Full SSL AnyConnect VPN e ter acesso similar a uma VPN tradicional.


   

 

 



   

    

   



Página 365

 

 

  


7.4 Configurando o Full SSL AnyConnect VPN no ASA Agora vamos configurar o AnyConnect que permite acesso completo aos recursos de rede, por isso seu nome é Full SSL VPN. O uso dessa solução ou de uma solução de VPN tradicional em larga escala, por exemplo, para mais de 900 a 1000 usuários deve ser bem pensada e verficar se realmente os usuários necessitam acesso completo à rede, pois se eles precisam acessar servidores e serviços Web a opção do WebVPN é mais simples e mais leve por não precisar do cliente AnyConnect nos computadores. Mesmo assim, se for realmente necessário acesso completo algumas decisões tem que ser tomadas, como por exemplo, onde e como os clientes AnyConnect serão instalados nos computadores remotos. O caminho para chegar ao wizard é o mesmo que utilizamos para o exemplo anterior, porém agora selecione a opção “AnyConnect Wizard” e clique em Next para prosseguir.

Na primeira página o wizard pede para você dar um nome para a “connection profile” onde os usuários AnyConnect irão se conectar e também a interface de saída (outgoing), mesma filosofia utilizada para a SSL VPN.

Clicando em Next na próxima página vamos configurar se utilizaremos SSL e também podemos utilizar IPSec. Abaixo temos a definição do certificado digital com as mesmas características A p o s t i l a / E - Bo o k d o C u r s o I I N S 6 4 0 - 5 5 4      

   

 

 



   

    

   



Página 366

 

 

  


que configuramos anteriormente. Vamos utilizar certificado self-signed e não PKI nesse exemplo.

Clicando em Next vamos definir onde o pacote de software do AnyConnect será disponibilizado para download. O próprio ASA pode ter o software na flash ou você precisará fazer o download em Cisco.com e copiar os arquivos na flash do ASA via TFTP. Se a imagem estiver na flash o ASDM informará com uma mensagem.


   

 

 



   

    

   



Página 367

 

 

  


Clicando em Next teremos as opções de autenticação dos usuários, também via AAA ou através de usuários do banco de dados local do ASA. A palavra chave LOCAL em maiúsculo é para uso da base de dados local via AAA.

Depois de configurar a autenticação clique em Next e passe a configurar a faixa de endereços que será fornecida aos clientes. Lembre que esses endereços serão da sua rede corporativa e precisam ser roteados internamente em sua LAN e WAN corporativa para que esses usuários remotos tenham acesso aos recursos necessários.

Clicando em Next vamos cair na página de configuração do DNS, WINS e nome do domínio que serão passados juntamente com o endereço IP dinâmico para a interface virtual do cliente.


   

 

 



   

    

   



Página 368

 

 

  


Clicando em Next teremos a configuração para evitar o uso Network Address Translation (NAT) para os endereços do pool da VPN, para isso podemos utilizar a opção Exempt VPN Traffic from Network AddressTranslation para retirar a faixa da VPN do NAT e não termos problemas quando os servidores responderem às requisições dos clientes VPN.

Clicando em Next temos uma tela informando que o cliente pode ser baixado via SSL pelos clientes ou já estar instalado na máquina do usuário e depois temos a finalização do wizard e da criação do VPN Full via AnyConnect.


   

 

 



   

    

   



Página 369

 

 

  


Abaixo segue a configuração vi CLI do que fizemos via wizard. object network NETWORK_OBJ_10.0.0.0_25 subnet 10.0.0.0 255.255.255.128 ip local pool POOLS-for-AnyConnect 10.0.0.51-10.0.0.100 mask 255.255.255.0 group-policy GroupPolicy_SSL_AnyConnect internal ! group-policy GroupPolicy_SSL_AnyConnect attributes vpn-tunnel-protocol ssl-client dns-server value 8.8.8.8 wins-server none default-domain value cisco.com exit ! webvpn enable outside anyconnect image disk0:/anyconnect-macosx-i386-2.5.2014-k9.pkg 1 anyconnect image disk0:/anyconnect-win-2.5.2014-k9.pkg 2 anyconnect enable ! tunnel-group-list enable tunnel-group SSL_AnyConnect type remote-access tunnel-group SSL_AnyConnect general-attributes default-group-policy GroupPolicy_SSL_AnyConnect address-pool POOLS-for-AnyConnect ! tunnel-group SSL_AnyConnect webvpn-attributes group-alias SSL_AnyConnect enable nat (inside,outside) 3 source static inside interface destination static NETWORK_OBJ_10.0.0.0_25 NETWORK_OBJ_10.0.0.0_25 no-proxy-arp route-lookup


   

 

 



   

    

   



Página 370

 

 

  


7.5 Conectando-se ao ASA e Instalando o AnyConnected Para o usuário se logar e instalar o AnyConnect client ele precisa utilizar HTTPS e colocar o endereço IP do ASA, assim o ASA vai mostrar uma página com o connection profile que ele deve utilizar (mostrado como um Group ao usuário). O usuário deve digitar seu username, sua senha e escolher o grupo correto para baixar o software e fechar a full VPN SSN.

Depois de autenticado o ASA tentará enviar e instalar o AnyConnect client no computador do usuário. Muitos métodos de instalação são possíveis, tais como ActiveX ou Java, por isso o computador do usuário deve ter os requisitos mínimos de instalação que você pode encontrar em Cisco.com procurando pela última versão do AnyConnect.

Existem pacotes de instalação diferentes para cada sistema operacional e você pode manter várias versões no ASA para manter a possibilidade de diferentes usuários de rede se conectarem à rede via AnyConnect. A p o s t i l a / E - Bo o k d o C u r s o I I N S 6 4 0 - 5 5 4      

   

 

 



   

    

   



Página 371

 

 

  


Uma vez instalado o software cliente o usuário já pode acessar os recursos de rede. 7.6 Split Tunneling Essa opção permite que os clientes conectados tanto via VPN SSL ou IPSec possam acessar servidores da Internet diretamente sem passar pelo túnel e ser redirecionado para a Internet pelo ASA, pois isso causaria o dobro do tráfego para o ASA. Sem esse recurso quando o cliente for acessar uma página da Internet ele teria que enviar o tráfego ao ASA, o ASA teria que redirecionar o tráfego para a Interne e ainda fazer o NAT desse usuário, pois na VPN ele utiliza um IP privado. Essa solução tem suas falhas em termos de segurança, porém é utilizada para evitar sobrecarga nos links de Internet das empresas e também evitar que recursos adicionais de IDS e IPS sejam gastos com as conexões desses usuários remotos, pois esses tráfegos precisariam ser analisados antes de sair em texto claro para a Internet. Para ativar o recurso vá em “Configuration > Remote Access VPN > Network(Client) Access> Group Policies” e edite a política do grupo (group policy) escolhendo a opção “Advanced > Split Tunneling”. Veja figura a seguir.

Em “Monitoring > VPN > VPN Statistics > Sessions” você pode verificar as VPNs estabelecidas e identificar de que tipo cada uma delas é.


   

 

 



   

    

   



Página 372

 

 

  


8 Resumo do Capítulo Bem pessoal, chegamos ao final do capítulo. É muito importante que nesse ponto do curso você tenha domínio dos seguintes itens: Descrever uma VPN, tipos e topologias. Descrever os blocos funcionais do IPSec e suas funções. Explicar a funcionalidade do protocolo IKE e suas fases de estabelecimento. Configurar e verificar uma VPN site-to-site com “pre-shered key authentication” e utilizando certificados digitais utilizando o CCP e CLI. Comandos Show e Debug para realizar troubleshooting em VPNs. Conceito e implementação de VPNs SSL através do ASA e ASDM.    

 


   

 

 



   

    

   



Página 373

 

 

  


Capítulo 11 - Operação e Gerenciamento de Redes Seguras

Depois que uma rede é instalada, o pessoal de operações de rede passa a monitorar e manter os equipamentos e softwares instalados.

Objetivos do Capítulo Ao final desse capítulo você terá estudado e deverá compreender: System Development Life Cycle. Disaster Recovery ou Recuperação de Desastres. Políticas de Segurança. Análise de Riscos. Fatores para Comstruir uma Rede Segura. Cisco Self Defending Network. Protegendo Borderless Networks. Segurança em Unified Communications, redes sem fio e SANs. 

Do ponto de vista de segurança, a área de operações de segurança tenta garantir a segurança do hardware, software e os diversos meios instalados investigando comportamentos anômalos da rede, ou seja, procurando por comportamentos fora do padrão estabelecido do funcionamento da rede..



  

  



   

 

 



   

    

   



Página 374

 

 

  



2

System Development Life Cycle _____ 376

1.1

Iniciação ou Initiation____________ 377

1.2

Aquisição e Desenvolvimento _____ 377

1.3

Implementação_________________ 378

1.4

Operação e Manutenção _________ 378

1.5

Disposal ou Descarte ____________ 379

7.2

Fronteiras Lógicas ______________ 400

7.3

SecureX e Context-Aware Security _ 401

8 Segurança em Redes com VoIP, Wireless e SAN ____________________________ 402

8.1 Voz

8.1.1 8.1.2

Dispositivos de uma Rede VoIP ____ 403 Riscos de Segurança em Soluções VoIP 405 8.1.3 Separando o tráfego de Voz dos demais tráfegos na LAN ________________________ 408 8.1.4 Utilizando equipamentos de segurança (firewall, IDS, IPS, etc) ___________________ 409 8.1.5 Trafegando a voz em túneis VPN (criptografar as conversações) _____________ 410 8.1.6 Reforçando parâmetros de segurança nos dispositivos VoIP ____________________ 410

O Lado Operacional da Segurança __ 379

2.1

Tarefas e rotina operacional ______ 380

2.2 Ferramentas para Avaliação de Segurança __________________________ 381 2.2.1

Exemplos de Comandos do NMAP _ 382

8.2 Questões de Segurança em Redes Sem Fio (Wireless) _______________________ 411

3 Considerações sore Recuperação de Desastres – Disaster Recovery _________ 384 4

8.2.1 8.2.2

Construindo uma Política de Segurança 386

8.3.1

Interfaces de comunicação para SANs 415 8.3.2 Logical Unit Numbers (LUNs) e LUN Masking 416 8.3.3 Zoneamento Fibre Channel _______ 417 8.3.4 World Wide Names _____________ 417 8.3.5 VSANs ________________________ 418 8.3.6 Protocolos de autenticação de Porta 418 8.3.7 Opções de Segurança em SANs ____ 418 8.3.8 Protocolos SAN Seguros, Acesso Seguro e Segurança dos Dados __________________ 419

6 Fatores para o Design de uma Rede Segura ____________________________ 389

Cisco Self-Defending Network _____ 391

6.2

Design da SDN _________________ 392

6.3

Gerenciamento das Redes SDN ____ 393

6.4 Produtos Cisco para Redes SelfDefending __________________________ 395 7 Protegendo Borderless Networks – Redes sem Fronteiras _____________________ 399

Padrões 802.11 e Dispositivos Cisco 412 Segurança em Redes sem Fio _____ 413

8.3 Questões de Segurança em SANs (Storage Area Network) _______________ 414

5 Análise e Gerenciamento de Risco de Segurança _________________________ 388

6.1

Questões de Segurança em Soluções de 402

9 10

Resumo do Capítulo _____________ 420 Conclusão ____________________ 420

7.1 Arquitetura e Componentes da Cisco Borderless Network___________________ 399


   

 

 



   

    

   



Página 375

 

 

  


1 System Development Life Cycle Após a implementação de uma rede segura é necessário compreender o sistema de ciclo de vida do desenvolvimento ou System Development Life Cycle (SDLC) para fins de avaliação de alterações no sistema e ajustar implementações de segurança quando necessário. O SDLC inclui cinco fases:     

Initiation ou (início do projeto), Acquisition & Development (ou aquisição e desenvolvimento), Implementation (ou implantação), Operations & Maintenance (ou operação e manutenção) e Disposition (ou descarte).

É importante incluir considerações de segurança em todas as fases do SDLC. Veja a figura abaixo.

Uma rede de computadores é uma entidade dinâmica, em constante mudança para satisfazer as necessidades dos seus usuários. Componentes de rede novos são adicionados e, eventualmente, são retirados da planta instalada (desinstalados por problemas, avanços tecnológicos ou fim de vida). A vida útil desses componentes pode ser definida pelo SDLC, ou seja, o ciclo de vida dos equipamentos e dispositivos de segurança. Esta metodologia de ciclo de vidas é muito mais implementada para o desenvolvimento de software, porém pode ser utilizada para outras áreas da Tecnologia da Informação, por isso, ao procurar na Internet os exemplos serão muito mais voltados ao desenvolvimento de programas, mas a Cisco escolheu colocar aqui essa etapa para que o aluno entenda o ciclo de vida de um projeto de segurança em uma empresa.


   

 

 



   

    

   



Página 376

 

 

  


Em cada fase citada anteriormente do SDLC existem considerações e procedimentos de segurança a serem levados em conta, vamos analisar cada fase com os olhos da segurança. 1.1 Iniciação ou Initiation Esta fase é composta de dois procedimentos de segurança: 



Categorização ou Classificação de Segurança: classificação de segurança, como o nome sugere, classifica a gravidade de uma violação de segurança em um componente de rede particular. Define três níveis de potencial impacto sobre as organizações ou indivíduos, se há uma violação da segurança: baixo, moderado e alto.Por exemplo, um dispositivo de rede adicionado recentemente à rede poderia ser classificados com um nível de segurança alto, moderado ou baixo, dependendo da sua criticidade. Avaliação preliminar dos riscos: Apesar de uma avaliação de risco mais formal ser parte do SDLC, a avaliação preliminar dos riscos oferece uma visão geral (em alto nível) dos requisitos de um sistema de segurança.

1.2 Aquisição e Desenvolvimento Estas são as tarefas de segurança relacionadas com a fase de aquisição e desenvolvimento da SDLC: 











Avaliação de riscos: Identifica os requisitos de proteção para o sistema através de um processo formal de avaliação de risco. Esta análise baseia-se na avaliação de risco que foi realizada durante a fase de iniciação, mas é mais aprofundada e específica. Requisitos de segurança funcional: Analisa as necessidades operacionais para abordar o ambiente de segurança do sistema, a política de segurança da informação da empresa e a arquitetura de segurança da empresa. Requisitos de garantia da segurança: Com base nos requisitos jurídicos e funcionais de segurança, esta análise fornece evidências de que o recurso de rede em questão será protegido no nível desejado. Considerações de custo e relatório: Determina qual o custo de desenvolvimento que a segurança da informação irá gerar ao longo do ciclo de vida do sistema. Estes custos incluem hardware, software, pessoal e treinamento. No final é gerado um relatório detalhado com esses custos. Planejamento da segurança: esta fase deve gerar um documento completo dos controles de segurança que serão utilizados no sistema. O plan o de segurança também descreve perfeitamente o sistema de informação e inclui anexos ou referências aos principais documentos que sustentam o programa de segurança da informação da organização. Exemplos de documentos que suportam o programa de segurança da informação incluem: um plano de gerenciamento de configuração, plano de contingência, plano de resposta a incidentes, sensibilização para a segurança e um plano de treinamento, regras de comportamento, avaliação de risco, teste de segurança e avaliação de resultados, acordos de interligação do sistema, as autorizações de segurança e acreditações e por último um plano de ações e metas. Desenvolvimento dos controles de segurança: devem assegurar que os controles de segurança que são descritos pelos vários planos de segurança serão realmente concebidos, desenvolvidos e implementados. No final é gerado um relatório completo com base nos controles que já vinham sido definidos anteriormente. Não necessariamente os controles precisam ser criados do zero ou jogar -se fora o que a empresa já possui, pois os controles já implementados podem passar a fazer parte desse documento e até com melhorias.


   

 

 



   

    

   



Página 377

 

 

  




Desenvolvimento de testes de segurança e avaliação: Esses testes devem assegurar que os controles de segurança que são desenvolvidos para um novo sistema de informação estão funcionando corretamente e são eficazes. Alguns tipos de controles de segurança, principalmente os de natureza não técnica, não podem ser testados e avaliados até o sistema de informação estar implantado. Esses controles são normalmente gerenciais e operacionais. Outros componentes do planejamento: Considera todos os componentes necessários do processo de desenvolvimento que incorporem a segurança no ciclo de vida da rede, os quais incluem os contratos, a participação de todos os grupos funcionais necessários dentro de uma organização, a participação de uma entidade certificadora externa, o desenvolvimento e a execução dos planos de contratação e processos.

1.3 Implementação Estas são as tarefas de segurança relacionadas com a fase de implementação do SDLC, onde um CCNA Security começa a se envolver: 







Inspeção e aceitação: Validar e verificar se a funcionalidade que descreve uma especificação está incluída nos entregáveis do projeto. Aqui é validar se o que foi planejado realmente foi colocado no projeto de implantação. Integração dos sistemas: Assegurar que o sistema está integrado ao site operacional onde o sistema de informação está sendo implantado. As configurações de segurança e comandos devem ser ativados de acordo com as instruções do fornecedor e orientações de implementação de segurança disponíveis. Certificação da segurança: Utilizar técnicas de verificação e estabelecer procedimentos de validação. Esta etapa dá confiança aos gestores da organização que as garantias apropriadas e medidas de proteção estão no lugar. A certificação da segurança também descobre e descreve as vulnerabilidades conhecidas do sistema de informação que está sendo implantado. Credenciamento ou accreditation da segurança: Após a operação dos controles de segurança exigidos serem verificados, são fornecidos os privilégios administrativos apropriados ao sistema para processar, armazenar e/ou a transmitir dados específicos. É quando o sistema sai da fase de projeto e passa para a área operacional cuidar do dia a dia relacionado ao sistema.

1.4 Operação e Manutenção Agora o sistema está implantado e será operado pelas equipes responsáveis pelo dia a dia da segurança da empresa. A área de Operações deve garantir que nenhum funcionário se torne uma ameaça à segurança nesse dia a dia da corporação, além disso, deve garantir também que os dados possam ser recuperados a partir de backups e que mudanças no sistema de informação não irão comprometer a segurança do sistema como um todo. Nessa fase temos duas tarefas de segurança relacionadas: 

Gerenciamento da configuração e controle: vamos considerar os impactos potenciais à segurança que podem ser causados por alterações específicas para um sistema de informação ou no seu ambiente de produção. A gestão da configuração e seus diversos procedimentos de controle de configuração são críticos para estabelecer uma base inicial (baseline) de hardware, software, firmware, componentes e suas configurações, para posteriormente controlar e manter um inventári o preciso de todas as alterações ao sistema. Esse processo é denominado Change Management no ITIL.


   

 

 



   

    

   



Página 378

 

 

  


Monitoração contínua: nessa fase o ambiente dever ser continuamente monitorado e também assegurado que os controles de segurança continuam a ser eficazes através de testes e avaliações periódicas. O envio de relatórios de status de segurança do sistema de informação aos funcionários adequados é uma atividade essencial de um programa global de segurança da informação.

1.5 Disposal ou Descarte Estas são as tarefas de segurança relacionados com a fase de disposição do SDLC: 





2

Preservação da informação: Algumas informações são necessárias guardar para atender exigências legais. É importante sempre rever a técnica empregada para a guarda dos documentos para não cair em problemas com tecnologias obsoletas, difíceis de serem repostas. Limpeza das mídias: Assegurar que os dados são excluídos, apagados e gravados novamente, conforme necessário. Eliminação de hardware e software: O descarte de hardware e software, conforme indicado pelo gestor de segurança da informação do sistema, deve ser realizado em casos de problemas e atualização tecnológica. Essa é uma etapa muito importante, pois, por exemplo, um HD pode ser relido diversas formatações atrás e informações importantes podem ser retiradas dos equipamentos eliminados de maneira incorreta. Existem empresas especializadas em inutilizar e descartar equipamentos sensíveis à segurança. Além disso, existem questões ambientais a serem observadas e seguidas ao se descartar equipamentos eletrônicos.

O Lado Operacional da Segurança

As recomendações de segurança voltadas às áreas operacionais visam garantir que nenhum funcionário se tornará uma ameaça à segurança, ou seja, que os dados possam ser recuperados a partir de backups e que mudanças no sistema de informação não venham a comprometer a segurança de um sistema, dispositivo ou informação. A seguir temos uma visão geral destas recomendações. 



Segregação de funções: princípio básico do sistema de controle interno que consiste na separação de funções, nomeadamente de autorização, aprovação, execução, controle e contabilização das operações. Ao pessoal de segurança da informação devem ser atribuídas responsabilidades de tal forma que nenhum único empregado pode comprometer a segurança do sistema. Isto poderia ser feito através de um sistema para dois operadores (na qual as tarefas específicas exigem duas pessoas) ou um sistema de controle de dois homens (em que dois trabalhadores têm de aprovar um o trabalho do outro). Job rotation ou rotation of duties (troca de cargo ou responsabilidades): é o rodízio de funções promovido pela organização, para que o funcionário possa adquirir novos conhecimentos em setores diferentes e acumular experiências, sem sair da companhia em que trabalha. É a rotação em cada trabalho ou área para agregar valor e saberes que serão muito úteis no dia-a-dia da organização. O potencial de um único empregado para causar uma violação de segurança em curso é diminuído por ter vários empregados periodicamente girando entre as funções. Isso resulta em uma rotação de "peer review" ou “pares revisores”, processo em que os empregados verificam um trabalho de outro. No entanto, as organizações menores, com número limitado de funcionários podem ter dificuldade para implementar esta recomendação.


   

 

 



   

    

   



Página 379

 

 

  




Trusted recovery ou recuperação confiável do sistema: recuperação confiável implica em fazer os preparativos para uma falha do sistema (por exemplo, backup de dados sensíveis e garantir os backups). Além disso, ter um plano para recuperar dados em caso de falha. Os procedimentos de recuperação devem assegurar que os dados sejam protegidos durante o processo de backup (por exemplo, executando um sistema operacional em modo de usuário único ou modo de segurança durante a restauração dos dados). Além disso, os dados devem ser restaurados de modo que suas permissões originais estejam em vigor, evitando causar problemas de acesso aos usuários. Controle das mudanças e configurações: Ao se fazer alterações em um sistema de informação, várias pessoas devem rever as mudanças com antecedência para antecipar os problemas que podem ser gerados por ela. Por exemplo, uma mudança em um sistema pode abrir uma brecha de segurança em outro sistema. Os principais objetivos da gestão da configuração e mudança é minimizar possíveis interrupções do sistema, permitindo que em situações de risco o sistema possa voltar rapidamente ao ponto antes da mudança, processo chamado de procedimento de fallback, e usando os recursos da rede de maneira mais eficiente e eficaz.

2.1 Tarefas e rotina operacional Ainda tratando de aspectos operacionais, uma das funções desse time é de testar a segurança periodicamente. Esses testes foram realizados na implementação do sistema e agora devem ser parte da rotina operacional do sistema. Durante a fase de implantação ou implementação, deve-se avaliar a segurança da rede em cada componente do sistema e depois no sistema como um todo. Através de uma avaliação durante essa fase pela equipe de implementação as chances de descobrir todas as falhas no projeto de segurança são maiores, pois normalmente a equipe é mais capacitada, além disso pode-se avaliar o sucesso da estratégia de implementação ou estratégia operacional que foi planejada. Outra missão durante a implantação é determinar se a solução de segurança vai ao encontro das diretrizes da política de segurança corporativa. Depois do sistema entrar em sua fase de operação e manutenção, a equipe operacional deve continuar a realizar avaliações periódicas de segurança para verificar o desempenho da solução. E além de avaliações regulares, a Cisco recomenda que as avaliações sejam realizada depois que um componente seja adicionado (por exemplo, um servidor web) ao sistema. Os resultados das avaliações de segurança podem ser utilizados para diversos fins, tais como: 

  

Criar uma linha de base (baseline) para o nível de proteção do sistema de informação. Isso significa que o administrador pode ter mapeado como é o funcionamento normal do sistema para saber o que é ou não um comportamento diferente, por exemplo, ele sabe que tem um tráfego de e-mail sainte médio de 50Mbytes por dia e houve um aumento repentino para 500Mbytes de informação, isso pode indicar uma infestação por vírus. Identificar estratégias para combater falhas de segurança mapeadas. Complementando outras fases do SDLC, como a realização de avaliações de risco. Realizar uma análise de custo/benefício quando se avalia medidas de segurança adicionais.

Uma variedade de técnicas de avaliação de rede estão disponíveis no mercado, algumas delas podem ser automatizadas, e outras são procedimentos manuais. Podemos considerar as seguintes abordagens para avaliar a segurança de rede:


   

 

 



   

    

   



Página 380

 

 

  






   



Escanear por endereços IP e portas abertas que esses hosts possuem (ping sweep e port scan); Fazer uma varredura nos hosts identificados procurando por vulnerabilidades conhecidas; Uso de utilitários de quebra de senha; Revisão dos sistemas de logs de segurança; Realizar varreduras de vírus; Realizar testes de penetração (de preferência com a contratação de um consultor externo para verificar se é possível invadir sistemas específicos); Procurar por SSIDs de redes wireless para identificar as redes sem fio inseguras.

Note que as técnicas utilizadas para fazer a verificação de segurança são as mesmas ou muito semelhantes das que os invasores irão utilizar para tentar penetrar na rede ou comprometer um determinado sistema, é o uso do “hackerismo ético”, o qual busca soluções para os problemas de segurança e não invadir sistemas para seu próprio proveito, seja ele financeiro ou para satisfação pessoal. 2.2 Ferramentas para Avaliação de Segurança Várias ferramentas e utilitários estão disponíveis para a realização de uma avaliação de segurança. Alguns estão disponíveis como freeware e outros pacotes requerem a compra de uma licença. Abaixo segue uma lista de ferramentas e utilitários mais utilizados:      

Nmap GFI LANguard Tripwire Nessus Metasploit SuperScan da Foundstone, uma divisão da McAfee

Vamos ver uma das ferramentas - uma das mais famosas - o NMAP. Criado por Fyodor, esse programa é o scanner mais conhecido de todos, extremamente poderoso e cheio de recursos. Utilizado por dez entre dez hackers como parte de seus ataques. Vamos ver as opções e facilidades que esse programa nos oferece para descobrir portas de serviços e computadores na rede. Alguns sistemas podem oferecer proteções em nível de rede que fazem com que pacotes ICMP ou conexões a determinadas portas, entre outras restrições, não consigam ser efetuadas. O NMAP possui alguns recursos para tentar burlar esses firewalls e alguns deles estão listados abaixo. Mais informações sobre o NMAP em .


   

 

 



   

    

   



Página 381

 

 

  


Apenas digitando nmap pode-se rapidamente obter os resultados mostrados na figura. Os números das portas, seu estado (se estão abertas ou filtradas por firewall) e, ainda, uma possível descrição do serviço que está rodando naquela porta. Uma das vantagens do NMAP frente a outros scanners (como Languard, para o sistema Windows) é que seus recursos avançados permitem fazer as varreduras do modo mais preciso possível, passando muitas vezes por proteções impostas por firewalls. 2.2.1 Exemplos de Comandos do NMAP

A seguir, veremos alguns dos recursos avançados de scanneamento do NMAP. 







-sT TCP connect() scan: Essa é a forma mais básica de scanneamento. A chamada de sistema connect(), provida pelo sistema operacional, é usada para abrir uma conexão com as portas. Se a porta estiver no estado listening, connect() terá sucesso. Uma grande vantagem dessa opção é que você não precisa de nenhum privilégio especial (root). Qualquer usuário pode usar, mesmo com permissões limitadas. Entretanto, é o scanneamento mais facilmente detectado por sistemas de IDS. -sS TCP Syn scan: Esta tática é muito conhecida como "half-open" scanning, porque não realiza uma conexão TCP completa. Enviando um pacote com o flag Syn setado, como se fosse abrir uma conexão real e esperando pela resposta, uma resposta Syn/ACK indica que a porta está no estado listening. Um flag RST indica que a porta não está escutando (non-listening). Se o flag Syn/ACK for recebido, o flag RST é imediatamente enviado para encerrar a conexão. A vantagem dessa tática de scanneamento é que poucos sites irão registrá-la em arquivos de log. Infelizmente, são necessários privilégios de root para a construção dos pacotes Syn customizados. -sF -sX –sN Modos Stealth FIN, Xmas Tree, ou Null scan: Algumas vezes nem mesmo a tática Syn scanning é furtiva o suficiente. Novos firewalls e filtros de pacotes observam por Syns para portas restritas, e programas como Synlogger e Courtney conseguem detectar esse tipo de scanneamento. Por outro lado, essas técnicas mais avançadas de scanneamento (stealth FIN, Xmas Tree, ou Null scan) podem ser capazes de passar através desses filtros sem muitos problemas. -sW Window scan: Esse modo é muito similar ao ACK scan, exceto que, às vezes, pode ser possível detectar portas abertas mesmo sendo filtradas, isso devido à anomalia do tamanho da janela TCP reportado por vários sistemas operacionais. Sistemas A p o s t i l a / E - Bo o k d o C u r s o I I N S 6 4 0 - 5 5 4

     

   

 

 



   

    

   



Página 382

 

 

  


vulneráveis a isso incluem AIX, Amiga, BeOS, BSDI, Cray, Tru64 UNIX, DG/UX, OpenVMS, Digital UNIX, FreeBSD, HP-UX, OS/2, IRIX, MacOS, NetBSD, OpenBSD, OpenStep, QNX, Rhapsody, SunOS 4.X, Ultrix, VAX e VxWorks. Para mais informações sobre modo de escaneamento e outros recursos que esse scanner oferece, consulte o site do software: . O NMAP também fornece uma GUI (interface gráfica) chamada Zenmap, ideal para aqueles que não gostam de ficar digitando no shell. Veja a figura abaixo.


   

 

 



   

    

   



Página 383

 

 

  


3 Considerações sore Recuperação de Desastres – Disaster Recovery Com o potencial para desastres naturais (como furacões, enchentes e terremotos) e desastres provocados pelo homem (como atentados terroristas) que paira sobre as redes de hoje, os administradores de rede precisam ter planos de contingência. Embora esses planos são às vezes chamados de planos de continuidade de negócios ou planos de recuperação de desastres, o planejamento de recuperação de desastres tende a abordar as medidas tomadas durante e imediatamente após um desastre. Especificamente, a recuperação de desastres (que é apenas um subconjunto do planejamento de continuidade de negócio) diz respeito à possibilidade de fornecer recursos para que os funcionários acessem os dados, hardware e software que precisam para fazer seus trabalhos. Também tenha em mente que, apesar de um plano de recuperação de desastres frequentemente trazer a mente pensamentos apenas sobre hardware redundante e instalações de apoio, um plano abrangente de recuperação de desastres também considera a possível perda de pessoal-chave. Os dois principais objetivos do planejamento de continuidade de negócios (business continuity plan) são: 



Mover operações críticas de negócios para outra instalação, enquanto a instalação original está em reparo; Utilizar formas alternativas de comunicação interna e externa.

O objetivo geral destes planos é permitir que uma organização seja capaz de realizar operações de negócios críticos após um desastre. Três fases de recuperação incluem:   

Fase de resposta de emergência Fase de recuperação Voltar a fase de operação normal

Uma vez que estes planos não conseguem resolver todos os cenários possíveis, a recuperação de desastres e planos de continuidade de negócios normalmente visam os eventos que são mais prováveis de ocorrer. Para ilustrar a gravidade da perda de dados críticos, considere que algumas empresas gastam oficialmente aproximadamente 25% de seu orçamento de TI na continuidade dos negócios e planos de recuperação de desastres. A Cisco também oferece as seguintes estatísticas sobre as empresas que mais perderam com seus registros informatizados em casos de desastre:   

43% nunca reabriu de novo. 51% fecham dentro de dois anos. 6% sobrevivem em longo prazo.

A Continuidade de negócios e planos de recuperação de desastres deve abordar diferentes níveis de rupturas ou disrupções, especificando diferentes respostas com base na gravidade do problema. Para ajudar na quantificação do problema, vamos considerar as categorias apresentadas abaixo: 





Não desastre: as operações normais são interrompidas por um período curto (problemas de dia a dia). Desastre: as operações normais de negócios são interrompidas por um ou mais dias, no entanto, nem todos os recursos críticos da localidade atingida são destruídos. Catástrofe: todos os recursos da localidade atingida são destruídos e as operações comerciais normais devem ser movidas para um local alternativo (site backup).


   

 

 



   

    

   



Página 384

 

 

  


Considerando as classificações acima agora é necessário pensar na solução de uma localidade backup, ou seja, uma instalação reserva ou medidas de redundância para cada um dos casos de desastre. Podemos ter os seguintes tipos de sites backup para o desastre e catástrofe (site aqui é o termo em inglês para localidade e não um website): 





Hot-site: são mantidos por empresas comerciais para os seus clientes, e esses sites incluem tudo desde infraestrutura de telefone até equipamentos de informática. Os servidores, no hot site serão espelhos dos servidores no local principal e a replicação das bases de dados é realizada em tempo real. Basicamente, os funcionários chegam no local e começam a trabalhar. Essa é a solução mais cara e deve ser utilizada apenas em grandes empresas e para os sistemas críticos. Veja a figura ao lado. Warm-site: esse tipo de site backup terá todo o equipamento físico necessário, juntamente com alguns dos servidores configurados e mantidos. O retorno à operação em um warm site levará mais tempo em comparação a um hot site, pois o warm site não é um espelho do site principal como no hot site. Pode haver necessidade de subir backups, por exemplo, que tomam bastante tempo, e a replicação das bases de dados normalmente não é realizada em tempo real. A consequência disso é que os sistemas críticos podem levar dias para serem reestabelecidos. Cold-site: não oferecem um local alternativo onde as operações de negócios podem ser realizadas, ao contrário de um site hot ou warm, um cold site geralmente não contém recursos de informática redundantes (como servidores e roteadores). Portanto, a rede precisa ser reconstruída a partir do zero, o que pode demorar algumas semanas. Embora um cold site ser mais barato inicialmente, em relação aos outros dois, um cold site pode criar consequências mais a longo prazo. De fato, as consequências financeiras poderiam ser muito maiores do que as economias de custo inicial.


   

 

 



   

    

   



Página 385

 

 

  


4 Construindo uma Política de Segurança Uma Política de Segurança da Informação tem por objetivo possibilitar o gerenciamento da segurança em uma organização, estabelecendo regras e padrões para p roteção da informação. A política de segurança possibilita manter a confidencialidade, garantir que a informação não seja alterada ou perdida e permitir que a informação esteja disponível quando for necessário.

Os controles devem ser definidos levando em conta as características de cada empresa, definindo o que é permitido e o que é proibido. A implantação, para ser bem sucedida, deve partir da diretoria da empresa para os demais funcionários (abordagem top down). A política deve ser divulgada para todos os funcionários da organização, de forma a manter a segurança das informações. O principal objetivo da política de segurança é para proteger os ativos de uma organização, os quais incluem mais do que apenas itens tangíveis. Ativos implicar também coisas como a propriedade intelectual, processos e procedimentos, dados confidenciais de clientes e funções específicas de servidor (por exemplo, e-mail e aplicações web). Além de proteger os ativos da organização, uma política de segurança serve para outros fins, tais como as seguintes: 





Manter os empregados cientes das suas obrigações, assim como das práticas de segurança; Identificar as soluções específicas de segurança necessárias para cumprir as metas da política de segurança; Atuar como uma base para monitoramento de segurança contínuo.

Uma política de uso apropriado (Appropriate - ou Acceptable - Use Policy - AUP) pode também ser parte de uma política de segurança. Ela deveria expressar o que os usuários devem e não devem fazer em relação aos diversos componentes do sistema, incluindo o tipo de tráfego permitido nas redes. A AUP deve ser tão explícita quanto possível para evitar ambiguidades ou maus entendimentos. Por exemplo, uma AUP pode listar newsgroups proibidos. Além disso, devido a uma empresa ter diversas áreas e cada uma delas com diversos níveis hierárquicos e diferentes preocupações, normalmente a política de segurança pode ser dividida em diversos documentos, porém todos devem seguir as mesmas diretrizes mesmo que separados.


   

 

 



   

    

   



Página 386

 

 

  


Como mencionado anteriormente, uma política de segurança da organização normalmente é composta de vários documentos, cada um para um público específico. Na figura ao lado você tem uma visão geral de alto nível destes documentos complementares. Em um nível muito elevado, uma Política de Governança (Governing Policy) regula e aborda conceitos de segurança considerados importantes para uma organização. A política de administração ou governança é dirigida principalmente a funcionários administrativos e técnicos. Abaixo estão listados os elementos típicos de uma política de governança:      

Identificar o tema abordado pela política. Discutir a visão da organização sobre a questão. Analisar a importância da política para o ambiente de trabalho. Explicar como os funcionários cumprirão a política. Enumerar as atividades, ações e processos adequados. Explicar as consequências do descumprimento da política.

Já as Políticas Técnicas (Technical Policy) fornecem um tratamento mais detalhado de uma política de segurança da organização. O pessoal de segurança e de TI são os alvos dessas políticas técnicas, pois utilizam essas políticas no exercício das suas tarefas do dia-a-dia. Os componentes típicos de políticas técnicas incluem tarefas específicas de segurança e pessoal de TI em áreas como as seguintes:     

E-mail. Redes sem fio. Acesso remoto. Uso da Telefonia. Uso dos recursos de TI como computadores e notebooks.

Por último, as Políticas de Usuário tratam de questões de segurança e procedimentos relevantes para os usuários finais. Por exemplo, um usuário final pode ser convidado a assinar uma política de uso aceitável (AUP) para acesso à Internet. Essa AUP pode indicar que o acesso à Internet é somente para fins comerciais, caso um usuário final seja encontrado usando a Internet por razões pessoais, ele ou ela pode enfrentar as consequências previstas na política de governança. Os demais documentos visam esclarecer mais aprofundadamente determinadas questões e especificar itens mais técnicos das políticas, podendo conter, por exemplo, as melho res práticas para uso do e-mail, etc. São os documentos de apoio e detalhamento das políticas. A responsabilidade final da política de segurança da empresa repousa sobre os ombros dos quadros superiores (por exemplo, o Chief Executive Officer - CEO). No entanto, a gerência sênior de TI normalmente supervisiona o desenvolvimento de uma política de segurança, ao contrário de estar intimamente envolvido com a criação da política. O pessoal de segurança ou TI Senior geralmente estão diretamente envolvidos com a criação da política de segurança. Esses indivíduos podem criar a política ou delegar a sua criação. Exemplos de segurança sênior ou pessoal de TI incluem:   

Chief Security Officer (CSO) Chief Information Officer ou Diretor de Informações (CIO) Chief Information Security Officer ou Diretor de Segurança da Informação (CISO)

Assim que uma política de segurança é criada, a segurança e a equipe de TI são responsáveis pela sua aplicação dentro da rede da organização. Os usuários finais são responsáveis pelo cumprimento da política de segurança.


   

 

 



   

    

   



Página 387

 

 

  


5 Análise e Gerenciamento de Risco de Segurança A segurança da rede consiste em mitigar riscos, portanto, os projetistas de segurança da rede precisam identificar ameaças que podem afetar o bom funcionamento da rede. Esse processo é conhecido como identificação de ameaças, do inglês threat identification. No entanto, além da identificação básica de ameaças, uma decisão chave na fase de projeto gira em torno de analisar a probabilidade da ameaça ocorrer e a gravidade das consequências se ela ocorrer. Esta análise é chamada de análise de risco (risk analisys). Ao realizar a análise de risco, uma das duas grandes abordagens pode ser utilizada: quantitativa ou qualitativa. Normalmente análises quantitativas são realizadas através de fórmulas matemáticas e são menos aconselháveis que as qualitativas. A realização da análise de risco qualitativa é baseada na experiência da equipe que a executa. Essa análise enfatiza que é fundamental ter a presença de três tipos de profissionais na execução desta metodologia de análise: a) o líder; b) quem registra as informações; c) os especialistas. Por outro lado, entre os especialistas devem estar presentes o conhecedor das instalações, quem detém o conhecimento das operações e o especialista na metodologia de análise. Para se obter uma boa análise de risco qualitativa é necessário possuir formulários específicos, normalmente compostos por escala de cinco pontos, variando a probabilidade e severidade dos riscos de “muito baixo” a “muito alto”. Uma análise quantitativa utiliza modelos matemáticos onde probabilidade e a severidade de um risco ocorrer são utilizadas como entrada. Como exemplo de uma fórmula de análise quantitativa, considere o seguinte: ALE = AV * EF * ARO. Essa fórmula calcula a expectativa de perda anual (ALE - annualized loss expectancy). A ALE produz um valor monetário que pode ser usado para ajudar a justificar os gastos de soluções de segurança. Os fatores que contribuem para o valor ALE estão abaixo: 





Asset value (AV): O valor patrimonial do ativo ou active value é o custo total de um ativo, incluindo um preço de compra, as despesas de manutenção periódica e todos os outros custos associados com a aquisição desse equipamento. Exposure factor (EF): O fator de exposição é uma porcentagem que representa a perda de um ativo que ocorra por uma ameaça antecipada ao tempo que efetivamente deveria ocorrer. Annualized rate of occurrence (ARO): A taxa anualizada de ocorrência representa quantas vezes por ano ocorre uma ameaça específica.

Dos dois destes fatores mostrados ao lado outra métrica pode ser calculada, a expectativa de perda única (SLE – Single loss expectation). O SLE representa a perda de valor monetário esperado a partir de uma única ocorrência de um risco previsto. O SLE pode ser calculado a partir da seguinte fórmula: SLE = AV * EF. O exercício de realizar uma análise de risco traz diversos benefícios: 

 



Identificação de uma relação custo/valor para o custo das medidas de segurança em relação ao valor previsto das medidas de segurança. Justificação dos gastos de capital pedido para as soluções de segurança. Identificação das áreas da rede que se beneficiariam com mais de uma solução de segurança. Fornecimento de estatísticas para o planejamento de segurança no futur o.

Redução do risco envolve a gestão de risco e/ou prevenção de riscos:


   

 

 



   

    

   



Página 388

 

 

  




Gestão de riscos (risk management): a gestão de risco assume que nem todas as ameaças em potencial podem ser eliminadas. É uma tentativa de reduzir os danos previstos a um nível aceitável. Por exemplo, nas listas anteriores de ameaças potenciais, IPS, IDS, HIPS e as soluções de firewall podem ser introduzidas para reduzir a probabilidade e impacto das ameaças identificadas. Prevenção de Riscos (risk avoidance): prevenção de riscos pode eliminar os riscos identificados não expondo um sistema para usuários finais. Isso seria inviável para uma aplicação de e-commerce, por exemplo. No entanto, se os designers pudessem identificar uma forma de implantar um serviço e ao mesmo tempo eliminar os riscos potenciais, essa nova abordagem poderia ser altamente lucrativa.

Há vários tipos de riscos do ponto de vista tecnológico e outros riscos que não são tecnológicos. Um risco tecnológico, por exemplo, é não ter um servidor bem configurado para ter senhas seguras. Em muitos casos, o servidor aceita uma senha que seja simplesmente admin. Se o servidor for configurado de forma a exigir uma senha que contenha números, letras e símbolos, automaticamente a segurança é maior, isso deve fazer parte da política de segurança. O risco é que, se não tenho senhas seguras, qualquer pessoa pode acessar documentos, informações confidenciais ou e-mails. Os riscos não tecnológicos são, por exemplo, a fuga das informações. Isso pode ocorrer no simples fato de jogar um papel no cesto de lixo ou falar no celular no elevador, divulgando informações da empresa na frente de outras pessoas. Esse é um risco que tem a ver com processos e pessoas, e não com tecnologias. As pessoas precisam ter incorporado em sua cultura o tema da segurança, para colocar uma senha segura, não falar no elevador sobre qualquer assunto, não atirar papéis importantes no cesto de lixo e demais medidas de segurança levantadas na política de segurança. Portanto, análise de riscos depende do escopo do projeto, podendo ser também: Tecnológico, Humano, Processos e Físico. 6

Fatores para o Design de uma Rede Segura

A tentação comum no projeto de uma solução de segurança é de tornar a rede de difícil uso para sua finalidade. Portanto, quando um projetista tem que pensar em uma solução de segurança de rede, ele deve reconhecer que as necessidades da empresa, ou seja, as necessidades do negócio são mais importantes que todas as outras necessidades. Veja abaixo os elementos de um projeto de rede segura: 









Necessidades de Negócios: As necessidades das empresas ditam o que uma organização deseja realizar com sua rede. Lembre que esta necessidade é o mais importante de todas as necessidades. Análise de Risco: Como discutido anteriormente, uma análise global do risco pode ser usada para atribuir um nível adequado de recursos (por exemplo, uma quantidade adequada de dinheiro) a um potencial risco de segurança. Política de Segurança: No início deste capítulo você leu sobre os elementos das políticas de segurança. Uma política de segurança geralmente contém vários documentos, tendo como alvo um público específico dentro de uma organização. Estes documentos individuais fornecem orientação para o dia-a-dia da empresa relativos à segurança da rede, para todos os funcionários da organização. Melhores Práticas: em vez das regras obrigatórias impostas por uma política de segurança, um conjunto de melhores práticas (desenvolvidas interna e/ou externamente) pode oferecer métodos comprovados para alcançar um resultado desejado. Operações de Segurança: o dia-a-dia das operações de segurança implicam em responder a um incidente, monitoramento, manutenção e auditoria (para assegurar a conformidade com a política de segurança da organização).


   

 

 



   

    

   



Página 389

 

 

  


Outro fator importante a se considerar é que um sistema de segurança muitas vezes fica comprometido devido a hipóteses e premissas incorretas feitas pelo projetista da rede ou pessoa responsável pela configuração inicial da rede. Por exemplo, um grupo de usuários considerado o usuário habitual de um sistema pode estar incorreto. Além disso, os tipos de ataques que uma rede pode estar sujeita poderiam ter sido classificados incorretamente. Para evitar fazer premissas incorretas sobre o projeto e implementação da rede, considere as seguintes recomendações da Cisco: 



  





Analisar como a falha de um componente do sistema impacta outros componentes do sistema. Determinar quais os elementos em uma rede são fail-open ou fail-closed. Por exemplo, suponha que um componente de segurança de uma rede (como um aparelho IPS) falhe, se um determinado tráfego que não pode ser analisado por ele for encaminhado, ao invés de ser negado, o componente é dito estar operando no modo fail-open. No entanto, se um componente de segurança nega o tráfego que não pode fiscalizar, o componente é dito estar operando em fail-closed (também conhecido como fail-safe mode), que seria o mais seguro dos dois modos. Identificar todos os possíveis ataques a que uma rede pode estar exposta. Avaliar a probabilidade de que um ataque em particular, seja lançado contra a rede. Se um ataque parece improvável por causa dos recursos de processamento requerido, extrapolar para considerar o fato de que os mesmo recursos estarão mais disponíveis no futuro. Considerar a inevitabilidade do erro do usuário em comprometer a segurança do sistema. Enviar suas premissas e hipóteses para revisão por outras partes que conheçam o assunto dentro da organização.

Uma característica relevante quando se trata de controle de acesso é como ele se comporta quando falha. Quando um controle de acesso falha e restringe o acesso ele é chamado de fail closed. Quando um controle de acesso falha e permite o acesso ele é considerado fail open. Outra consideração ao se projetar ou realizar o design de uma rede segura é: “Que privilégios de acesso serão dados aos usuários finais?”. Uma abordagem para a segurança de uma rede é o de atribuir aos usuários os privilégios mínimos que eles necessitam para realizar suas funções, conhecido como “least-privilege concept” ou “conceito do mínimo privilégio”. Basicamente, o princípio do mínimo privilégio significa que qualquer objeto (usuário, administrador, programa, sistema, etc) deveria ter somente os privilégios que o objeto precisa para realizar as suas tarefas - e nada mais. Mínimo privilégio é um princípio importante para limitar a exposição aos ataques e para limitar os danos causados por ataques. Deve-se explorar meios para reduzir os privilégios requeridos para as operações. Na Internet há uma infinidade de exemplos, eis alguns: Não se deve dar a um usuário a senha do root se tudo que ele precisa fazer é resetar o sistema de impressão. Ao invés disso, escreve-se um programa que execute em modo privilegiado (no ambiente Unix, utilizar o setuid) e que realiza tal tarefa podendo ser executado pelo usuário; Não executar um programa com privilégios de root se a única coisa que ele precisa com tais privilégios é escrever em um arquivo protegido. Ao invés disso, permita que o arquivo seja escrito por algum grupo e sete o grupo (setuid no ambiente Unix) do processo para este grupo; Não permita que alguma (s) máquina (s) da rede interna confie (m) no firewall de forma que este não possa fazer “backups” nesta (s) máquina (s). Ao invés disso instale um "drive" de fita magnética na máquina do firewall de modo que ele possa fazer o seus próprios "backups". Esse conceito é muito difícil de se implementar na prática e exceções sempre serão necessárias devido a complexidade das aplicações e necessidades de cada área formam a organização.


   

 

 



   

    

   



Página 390

 

 

  


O último princípio que vamos analisar para o projeto de rede de segurança considera a complexidade de uma solução de segurança. Uma solução de segurança complexa, por sua natureza, pode tornar difícil para os administradores de rede efetivamente solucionar problemas relacionados à segurança. Além disso, se os usuários se deparam com um procedimento de segurança complexo que deve executado para realizar suas tarefas, normalmente eles irão procurar uma forma mais simples de contornar para melhorar a sua produtividade, o que pode trazer outros riscos não previstos. Portanto, a Cisco recomenda a solução mais simples possível, que ainda realize os resultados desejados. Uma solução de segurança relativamente simples pode fazer o seguinte:   

Ajudar os administradores a solucionar problemas de segurança de forma mais eficaz. Incentivar os usuários a seguir as práticas de segurança. Verificar as vulnerabilidades de segurança mais visíveis.

Lembre-se também que o treinamento dos usuários será fundamental para o sucesso das políticas de segurança implementadas e redução dos riscos de segurança. Nesse processo devem ser identificadas as necessidades de treinamentos, os instrutores ou tutores (que podem ser ou não pessoas da TI) e os grupos que necessitam ser treinados. Para garantir a efetividade desse tipo de programa de treinamento todos os funcionários devem ser encorajados a participar e periodicamente reciclagens devem ser ministradas. Com o treinamento de sensibilização adequada, todas as categorias de usuários finais (tais como executivos, gerentes, funcionários e empregados temporários) podem contribuir para a segurança global da rede. Note que o treinamento de sensibilização, uma política de segurança e defesas de rede devidamente instaladas não são suficientes quando usados isoladamente. No entanto, esses elementos de segurança são complementares e quando utilizados em conjunto conseguem cumprir as expectativas com relação à segurança. 6.1 Cisco Self-Defending Network Como já vimos anteriormente, um planejamento cuidadoso é a chave para proteger uma empresa e desenvolver um conjunto formal de políticas de segurança é o passo inicial mais importante. É necessário identificar quem está utilizando a rede, certificar-se de que é alguém autorizado para o fazer e controlar o acesso à informação, além de certificar que o tráfego na rede esteja protegido. Uma falha de segurança pode ter um impacto devastador. Dados confidenciais sobre a empresa ou dos seus clientes podem ser roubados, um vírus pode trazer implicações empresariais críticas, apagar informações importantes e danificar o ambiente de trabalho dos funcionários, aplicações maliciosas podem desacelerar os recursos empresariais e impedir o acesso da sua empresa à Internet, e muitos outros problemas podem ser ocasionados pelos incidentes de segurança. A segurança deve estar integrada em cada uma das partes da rede para localizar próativamente qualquer atividade suspeita, identificar ameaças e adaptar-se rapidamente a novos desafios. A proposta da Cisco Self-Defending Network é a de proteger a empresa identificando, prevenindo e adaptando-se a ameaças provenientes de dentro e de fora dela. Além disso, permite tirar partido da inteligência e equipamentos que já existem na rede para ajudar a manter a empresa em funcionamento de forma eficaz e a reduzir os custos operacionais. Quando uma Cisco Self-Defending Network é construída, deve-se considerar como os produtos de segurança individuais funcionam em conjunto. Como resultado, a Cisco Self-Defending


   

 

 



   

    

   



Página 391

 

 

  


Network integra um conjunto de soluções de segurança para identificar ameaças, impedir as ameaças e adaptar-se às ameaças emergentes. Veja a figura ao lado. Portanto as redes Self-Defending propostas pela Cisco são: 





Integradas: segurança é construída na rede, ao invés de ser adicionada a uma rede já existente. Colaborativas: o pessoal de TI com foco em segurança colabora com o pessoal de TI com foco em operações de rede. Adaptáveis: soluções de segurança que podem se adaptar à evolução das ameaças.

As redes Cisco Self-Defending podem ser mais rentáveis, em comparação com apenas implementar uma série de soluções independentes (também conhecidas como soluções pontuais). Isso porque uma infra-estrutura complementar simplifica a gestão e tarefas administrativas. Da mesma forma, os ciclos de atualização de equipamento podem ser mais bem coordenados (updates e upgrades de software e hardware). 6.2 Design da SDN A construção de um Cisco Self-Defending Network começa com uma plataforma de rede que possui segurança integrada. Em seguida, os recursos de segurança estratégica, como a seguir, são adicionadas em camadas em cima de uma base já segura: 



Controle de Ameaça: estratégias para conter e controlar as ameaças incluem o seguinte: o Controle de ameaças aos Endpoints defendem os equipamentos finais contra ameaças, geralmente provenientes da Internet, como vírus e spyware. o Controle de ameaças à Infraestrutura protege servidores e aplicativos compartilhados contra ameaças internas e externas. o Controle de ameaças de segurança provenientes de e-mail, como anexos malintencionados. Comunicação Confidencial e Autenticada: tecnologias como o IPsec e VPNs SSL podem fornecer canais confidenciais e autenticados de comunicação. Especificamente, a solução Cisco Secure Communications oferece um conjunto de produtos que podem ser classificados em duas categorias amplas: o Acesso remoto seguro protege a transmissão das comunicações de rede em uma organização através da Internet utilizando um túnel seguro.


   

 

 



   

    

   



Página 392

 

 

  


VPNs Site-to-site protegem a transmissão de comunicações de segurança entre uma unidade principal de uma organização e outros sites (por exemplo, escritórios domésticos ou parceiros de negócios) através de uma infraestrutura de WAN com base na Internet. Soluções de Gerenciamento: produtos que proporcionam controle do sistema de políticas de configuração e oferecem uma variedade de benefícios: o Implantação de uma nova política para vários dispositivos ao mesmo tempo o Manter a consistência da configuração o Visão do status de segurança da rede ponta a ponta o Rápida resposta aos ataques o Melhoria da congruência com a política de segurança da organização o



Já estudamos nos capítulos anteriores os equipamentos e como implantar essas recomendações de segurança que as redes self-Defending da Cisco propõe. 6.3 Gerenciamento das Redes SDN Falando mais especificamente sobre o gerenciamento da rede, quando uma organização começa a crescer o gerenciamento de segurança fim-a-fim se torna uma tarefa mais complicada. Felizmente, a Cisco oferece um conjunto de ferramentas de gerenciamento de segurança, os componentes principais são o Cisco Security Manager (CSM) e o Cisco Security Monitoring, Analysis and Response System (MARS). O Cisco Security Manager é um aplicativo que pode ser usado para configurar os recursos de segurança em diversos produtos de segurança da Cisco. De uma perspectiva de escalabilidade, o Cisco Security Manager pode ser útil em pequenas redes (por exemplo, redes com menos de dez dispositivos), e também pode ajudar a gerenciar mais eficientemente redes com milhares de dispositivos. Como alguns exemplos, o Cisco Security Manager oferece a aplicação desses recursos: 

 

Provisionamento de segurança em uma variedade de plataformas Cisco, incluindo roteadores Cisco IOS-based, Cisco ASA 5500, Cisco PIX 500, sensores de IPS Cisco 4200 e para o Advanced Inspection and Prevention Security Services Module (AIP-SSM) , disponíveis para a plataforma de switch Cisco Catalyst 6500. Execução de tarefas de configuração via interface gráfica. Aplicação de uma política centralizada, o que mantém a consistência ao longo da rede e pode ser herdado por dispositivos recém-instalados, ou seja, como um processo de “copiar e colar” as configurações de equipamentos já instalados nos novos.


   

 

 



   

    

   



Página 393

 

 

  


Interoperabilidade com Cisco Secure Access Control Server (ACS) para fornecer conjuntos de permissões customizados para diferentes usuários.

Clique no link a seguir para visitar uma página com mais informações sobre o CSM. http://www.cisco.com/assets/cdc_content_elements/flash/sec_manager/index.html Já o Cisco Security Monitoring, Analysis and Response System (MARS) é um produto que oferece monitoramento de segurança para dispositivos de segurança e aplicações. Além de dispositivos e aplicações Cisco, o Cisco Security MARS pode monitorar vários dispositivos e aplicações de outros fabricantes. O Cisco Security MARS pode realizar as seguintes funções: 





Utilizar a correlação de eventos para coletar eventos de vários dispositivos de rede, reduzindo assim o número de falsos positivos. Identificar as estratégias de mitigação adequadas para os desafios específicos de segurança. Utilizar tecnologia Cisco NetFlow para mais facilmente identificar anomalias na rede.

Clique no link a seguir para visitar uma página com mais informações sobre o CSMARS. http://www.cisco.com/assets/cdc_content_elements/flash/security_mars/demo.htm


   

 

 



   

    

   



Página 394

 

 

  


6.4 Produtos Cisco para Redes Self-Defending Para finalizar o curso vamos fazer uma revisão dos produtos que fazem parte da rede SelfDefending da Cisco que já estudamos até o momento: • Roteadores com Cisco IOS: Muitos roteadores Cisco IOS podem ser configurados com Intrusion Prevention System (IPS), rede privada virtual (VPN) e firewall.

• Cisco ASA 5500 series security appliance: O Cisco série 550 Adaptive Security Appliances (ASA) oferece uma ampla variedade de soluções de segurança como firewall, IPS, VPN, antivírus, antispyware e antiphishing, tudo integrado em um só equipamento.

• Cisco PIX 500 series security appliance: O Cisco PIX 500 Series oferecem recursos de firewall e terminação de VPN. Esse produto já foi descontinuado, mas deixamos aqui porque você ainda pode encontrar em campo, ele foi o predecessor do ASA.


   

 

 



   

    

   



Página 395

 

 

  


• Cisco 4200 series IPS appliances: O Cisco 4200 series são dispositivos de IPS para modo inline utilizados para analisar o tráfego. Se esta análise identifica um tráfego malicioso, o appliance de IPS pode executar operações como bloqueio do tráfego, o envio de um alerta para o sistema de gerenciamento ou instruindo outro dispositivo de rede (como um aparelho de segurança da Cisco PIX) para bloquear a conexão do invasor.

• Cisco Security Agent (CSA): Cisco Security Agent (CSA) é um aplicativo que fornece serviços de IPS em um host. Portanto, a CSA é chamado de Host-Based Intrusion Prevention System (HIPS). Esse produto também foi descontinuado.


   

 

 



   

    

   



Página 396

 

 

  


• Cisco Secure Access Control Server: O aplicativo Cisco Secure Access Control Server (ACS) pode fornecer autenticação, autorização e contabilização (AAA), permitindo assim que diferentes conjuntos de permissões possam ser aplicadas a diferentes usuários.

• Módulos de segurança para Cisco Catalyst 6500 series switch e Cisco 7600 series Router: diversos módulos fornecem recursos de segurança para o chassi dos equipamentos da linha 6500 e 7600. Por exemplo, você pode inserir um módulo de serviços de Firewall (FWSM) em um chassi de prestação de serviços de firewall entre várias VLANs definidas em um switch da série Cisco Catalyst 6500.

• Cisco Router and Security Device Manager (SDM): Cisco SDM fornece uma interface gráfica para configurar uma variedade de características de segurança (por exemplo, IPS, VPN IPsec de site para site e firewall), além de oferecer vários recursos de configurações gerais do roteador. O SDM foi descontinuado e substituído pelo SDM.


   

 

 



   

    

   



Página 397

 

 

  


• Cisco Configuration Professional (CCP): A Cisco Configuration Professional (CCP) é o substituto para o Device Security Manager (CCP). Ela é também uma ferramenta gráfica de gerenciamento de dispositivos de acesso para roteadores Cisco que simplifica a configuração com assistentes fáceis de usar para o roteador, firewall, sistema de prevenção de intrusão (IPS), VPN, Comunicações Unificadas, WAN e LAN.


   

 

 



   

    

   



Página 398

 

 

  


7 Protegendo Borderless Networks – Redes sem Fronteiras A Cisco Borderless Network Architecture é a arquitetura técnica que permite que as empresas conectem qualquer pessoa, em qualquer lugar, a qualquer hora e com qualquer dispositivo - com segurança, confiabilidade e integração total, ou seja, redes onde suas fronteiras estão estendidas através da nuvem. Ela é o alicerce da Cisco Intelligent Network, proporcionando otimização, dimensionamento e segurança para colaboração e virtualização. A arquitetura é incorporada em uma infraestrutura de hardware e software dimensionável e resiliente. Os componentes da arquitetura são reunidos para criar sistemas de rede estendem suas fronteiras.

Portanto, as fronteiras das redes estão cada vez mais se dissolvendo mais, sendo que onde começa e termina a rede fica cada vez mais difícil de dizer. 7.1 Arquitetura e Componentes da Cisco Borderless Network Os serviços Borderless Network são recursos avançados e diferenciados que as Cisco Borderless Networks oferecem em seus portfólios de roteamento, switching, segurança, conexão sem fio e otimização de WAN. 



Mobilidade: O Cisco Motion oferece acesso sem fio de missão crítica com mobilidade contínua e confiável para aumentar a produtividade da força de trabalho. Assista a uma demonstração. A tecnologia Cisco CleanAir pode amenizar interferências de RF e garantir o desempenho. Já a tecnologia ClientLink pode ajudar a aumentar em até 27% a capacidade total do canal e 65% em média na taxa de rendimento para clientes de 802.11a/g. É possível também fornecer vídeo multicast com velocidade superior através de redes sem fio com o VideoStream. Gerenciamento de energia: Reduzir os custos com energia e melhorar a eficiência é necessário atualmente e pode ser realizado com o Cisco EnergyWise.


   

 

 



   

    

   



Página 399

 

 

  










Segurança: O Cisco SecureX é uma arquitetura de segurança contextual que reforça as políticas de segurança por toda a rede distribuída, não somente em um único ponto no fluxo de dados. Seus componentes incluem: o As Cisco Security Intelligence Operations (SIO) para uma segurança mais eficaz com correlação à ameaça global e atualizações em tempo real. o As soluções Cisco AnyConnect e Cisco TrustSec para ajudar a conectar dispositivos portáteis e terminais na rede e a ambientes de rede, de forma segura, com políticas e aplicações contextuais. Desempenho dos aplicativos: O Cisco Application Velocity melhora a velocidade e a disponibilidade de qualquer aplicativo para aumentar a continuidade dos negócios e a produtividade dos funcionários. Ele acelera os aplicativos e otimiza a WAN com Wide Area Application Services (WAAS) nos módulos dos roteadores de serviços integrados Cisco Generation 2 (ISR G2) Services Ready Engine. Otimização de multimídia: A Cisco Enterprise Medianet dimensiona a rede e prioriza aplicativos de vídeo, colaboração e multimídia em qualquer dispositivo para aprimorar a experiência do usuário. Gerenciamento: As soluções de gerenciamento da Cisco ajudam as organizações de TI a implantar, gerenciar e solucionar com mais eficiência os problemas da rede e dos serviços que elas oferecem. Os principais produtos são: o Cisco Prime LAN Management Solution (LMS) o Cisco Prime Network Analysis Module (NAM) o Cisco Prime Collaboration Manager (CM)

7.2 Fronteiras Lógicas Em redes convencionais estamos acostumados a definir as fronteiras de uma rede pelas camadas do modelo OSI, por exemplo, camada-2 entre os switches e LANs e camada-3 entre roteadores e suas WANs. Em redes sem fronteiras ou borderless essa classificação é mais flexível e solta, pois servidores, clientes e serviços de rede não tem suas interfaces restritas. Apesar disso, podemos ainda classificar por região ou função daquele segmento de rede. Uma classificação para esses limites segue abaixo. 



Borderless end zone (extremidades): equipamentos que conectam os dispositivos à rede, portanto aqui devemos nos preocupar com vírus, malware e outros softwares maliciosos. Podemos utilizar o Network Admissions Control (NAC) e Identity Services Engine (ISE) para certificar que os hosts se conectando à rede obedecem o mínimo de requisitos de segurança, por exemplo, verificando vírus com ferramentas de escaneamento, service packs, instalação de patches e assim por diante. Borderless data center: são equipamentos que fornecem serviços em nuvem (cloud) para que usuários de rede e clientes da empresa possam utilizar recursos. Nos borderless data centers podemos implementar firewalls com o Adaptive Security Appliance (ASA) e IPS para proteção das informações.


   

 

 



   

    

   



Página 400

 

 

  




Borderless Internet: a Internet dispensa descrições e podemos incluri dispositivos como IPSs, firewalls e protocolos de inspeção para verificar e combater ameaças das camadas 2 à 7 do modelo OSI. Policy management point (Gerenciamento da política de segurança): em um mundo perfeito teríamos um ponto único de controle capaz de implementar medidas de segurança através de toda a rede. O Cisco Security Manager (CSM) é um exemplo desse tipo de ferramenta, assim como o ACS. Ambos são capazes de controlar o acesso e implementar políticas seguras de acesso aos administradores de redes.

7.3 SecureX e Context-Aware Security A arquitetura SecureX é uma estratégia e não somente um produto ou linha de equipamentos. Os elementos principais dessa estratégia de segurança são: 







Context awareness: esse ponto quer dizer “observe o contexto todo”, por exemplo, você precisa confirmar os parâmetros para dar acesso a recursos de redes aos usuários é preciso saber quem eles são, como eles acessam a rede, o tipo de computador que eles usam, etc. Ferramentas como ISE, NAC e AAA podem ajudar nessa missão. AnyConnect Client: já estudamos esse recurso de VPN e ele é utilizado para garantir a integridade dos dados enviados através da Internet. TrustSec: cria um mecanismo distribuído para implementar uma política de reforço de segurança distribuída. O objetivo é controlar a segurança fim a fim garantindo que os hosts que estão se conectando à rede estão seguindo a política de segurança da empresa. Podemos utilizar o ISE, NAC e AAA para implementar esse recurso. O uso de security group tags (SGT) permite também dar tags ou marcas de segurança aos dispositivos. Além disso, os dados podem ser criptografados para garantir a confidencialidade. Security Intelligence Operations: o SIO é um serviço baseado em nuvem (cloudbased service) gerenciado pela Cisco que visa identificar e fazer correlação de ameaças em tempo real. Por exemplo, uma ameaça nova descoberta na Internet foi descoberta e medidas de defesa podem ser aplicadas aos dispositivos de segurança da empresa mesmo antes que ela chegue ao perímetro de segurança dela.

Podemos ainda utilizar diversos dos equipamentos já estudados para manter a integridade e controlar a perda dos dados.


   

 

 



   

    

   



Página 401

 

 

  


8 Segurança em Redes com VoIP, Wireless e SAN Cada vez mais as redes deixaram de ser “redes de dados” para se tornarem uma rede “multiserviços” ou “convergentes”, ou seja, tudo sobre IP: Voz sobre IP, vídeo sobre IP, etc. Cada vez mais diferentes serviços estão sendo intergrados à rede IP com suas características específicas de tráfego, necessidades de qualidade de serviços e, consequentemente, necessidades especiais de segurança. Nesse capítulo trataremos das principais características e considerações de segurança para redes VoIP (voz sobre IP) ou Telefonia IP, sem fio ou Wireless e SAN ou Storage Area Network.

8.1 Questões de Segurança em Soluções de Voz A tecnologia de Voz sobre o protocolo IP é basicamente converter o sinal de voz analógico em uma codificação digital e transmiti-la pela rede IP, aparentemente o conceito é simples. Na figura a seguir você pode verificar a principal aplicação do VoIP e Telefonia IP nas corporações, as quais aproveitam a rede IP existente para transmitir a voz, o que traz um benefício imediato na redução dos custos de telefonia entre a Matriz e a Filial, pois como a ligação passa pela rede interna não há custo adicional com a operadora de Telecom. Esse foi o principal motivo da popularização da tecnologia tanto nas empresas como para usuários residenciais com o uso do Skype e MSN para fazer ligações gratuitas através da Internet.


   

 

 



   

    

   



Página 402

 

 

  


O tráfego IP para voz tem uma característica especial, pois eles são vários pacotes de tamanho pequeno que precisam ser enviados rapidamente pela rede IP, ou seja, é um tráfego de tempo real, não suportando grandes atrasos ou variações de tempo (jitter) que normalmente uma rede IP sofre. Outro ponto é que além dos pacotes de voz temos também os pacotes de controle que normalmente são trocados entre os terminais IP (telefones ou softfones) e os Communications Managers (centrais telefônicas IP). Portanto, uma parte importante de uma rede com suporte a telefonia IP é a qualidade de serviço ou QoS, para assegurar que haverá largura de banda garantida e a correta prioridade para os pacotes de voz dentro da rede IP. No lado da segurança a voz sobre IP também tem suas vulnerabilidades e questões a serem tratadas, pois o serviço roda em portas TCP e UDP que devem ser liberadas nos firewalls, além de diversos ataques e riscos de segurança que devem ser endereçados. 8.1.1 Dispositivos de uma Rede VoIP

Antes de iniciarmos a discussão sobre as questões mais específicas de segurança, vamos analisar a Telefonia IP no ponto de vista da Cisco. Tipicamente uma rede de telefonia IP é composta pelos elementos da figura ao lado, contendo: 













Telefones IP - fornecem serviços de voz sobre IP e normalmente um acesso à rede para o desktop, compartilhando o mesmo ponto de rede. Pode ser alimentado por uma fonte externa ou diretamente pelo Switch utilizando o PoE (power over ethernet). Gatekeeper - Fornece Call Admission Control (CAC) ou controle de admissão de chamadas, gestão e controle de banda e tradução de endereços (dial plan). Gateway - Fornece a tradução entre o mundo VoIP e as redes não-VoIP, como a PSTN ou rede de telefonia convencional. Gateways também oferecem acesso físico para dispitivos convencionais de voz analógicos ou digitais, tais como telefones, aparelhos de fax e PABX. Unidade de controle multiponto (MCU) - Fornece conectividade em tempo real para que participantes em vários locais possam assistir a uma videoconferência ou uma reunião via audioconferência. Call Agent - Fornece controle de chamadas para telefones IP, CAC, gestão e controle de banda e tradução de endereços. O Cisco Unified Communications Managers e Cisco Unified Communications Manager Business Edition tem a função de Call Agents. Eles atuam como as centrais telefônicas em uma rede IP. Servidores de aplicativos (Application servers) - Prestam serviços como correio de voz e mensagens unificadas, como por exemplo, o Cisco Unity. Estação de Videoconferência - Fornece acesso para o usuário final participar de uma videoconferência. A estação de videoconferência contém um dispositivo de captura de vídeo e um microfone para o áudio. O usuário pode ver o vídeo e ouvir o áudio que se A p o s t i l a / E - Bo o k d o C u r s o I I N S 6 4 0 - 5 5 4

     

   

 

 



   

    

   



Página 403

 

 

  


origina em uma estação de usuário remoto, interagindo em tempo real com voz e vídeo simultâneos.

A comunicação entre esses diversos dispositivos se dá através de diversos protocolos de comunicação que se dividem entre controle de chamada e a voz ou vídeo propriamente dito. Seguem os principais protocolos utilizados no VoIP: 















Session Initiation Protocol (SIP): pode usar TCP ou UDP para fornecer áudio, vídeo, streaming, mensagens instantâneas e presença. Media Gateway Control Protocol (MGCP): usado para controlar as operações tanto no gateway da rede como na PSTN. H.323: Um padrão ITU para um conjunto de protocolos que regem as comunicações de voz e vídeo em uma rede VoIP. Skinny Call Control Protocol (SCCP): também chamado simplesmente skinny (magro), um protocolo proprietário Cisco para a conectividade entre um telefones IP Cisco e o Call Manager. Real-Time Transport Protocol (RTP): responsável por transportar o fluxo de áudio e vídeo na rede. Secure Real-Time Transport Protocol (SRTP): desenvolvido como um método para corrigir e melhorar o protocolo RTP fornecendo criptografia, autenticação, integridade e capacidade de evitar repetição. Real-Time Transport Control Protocol (RTCP): Fornece controle e estatísticas forada-banda dos fluxos RTP. H.248 (Megaco): um protocolo desenvolvido pela IETF em colaboração com a ITU, que é uma forma de Media Gateway Control Protocol.

Na figura a seguir podemos verificar os protocolos utilizados entre os dispositivos em uma topologia simples. Entre o Call Manager e os telefones IP é utilizado o protocolo Skinny, o qual informa quando um usuário quer utilizar o serviço de telefonia e faz a sinalização entre os telefones e o Call Manager.


   

 

 



   

    

   



Página 404

 

 

  


Depois de completada a chamada, ou seja, o usuário local ligou e o usuário remoto atendeu o telefone, o fluxo RTP/RTCP é estabelecido diretamente entre os telefones para a troca dos pacotes de voz. Nas versões mais atuais do Call Manager a comunicação entre os telefones e demais endpoints será realizada via SIP. Já entre o Gateway e o Call Manager (CUCM) é utilizado o protocolo MGCP. Tudo isso rodando via IP, com exceção da conexão entre o Gateway de voz e a rede PSTN que está sendo feita com uma linha analógica do tipo FXS/FXO. 8.1.2 Riscos de Segurança em Soluções VoIP

Como a voz sobre IP está sendo transmitida pela rede IP, muitos dos riscos de segurança são mitigados naturalmente ao aumentar a capacidade de defesa da infraestrutura em questão, porém temos também alguns riscos inerentes à tecnologia VoIP. Toll Fraud – Fraude de Tarifação A Fraude de tarifação acontece quando um usuário ou um atacante é capaz de colocar chamadas interurbanas (frequentemente chamadas internacionais) sem a autorização para fazê-lo. Em sua forma mais simples, alguém dentro de uma empresa pode estar violando a política de fazer chamadas de longa distância. A fraude de tarifação é um grande negócio na América corporativa hoje, por exemplo, especialmente em grandes corporações, que podem não ter um controle apertado sobre sua estrutura de ligações de longa distância. No Brasil também esse tipo de fraude é bastante difundida. Outros métodos de fraude de tarifação envolvem hackers invadir um sistema telefônico. Se você pode ganhar acesso ao sistema, você pode ser capaz de reprogramá-lo para permitir chamadas para determinados números, ou você pode ser capaz de ligar para um número e depois chamar a partir do mesmo número. Você pode se lembrar o caso de Kevin Mitnick, quando ele manipulou uma empresa de telefonia de modo que seu número de telefone foi o único que poderia responder a um concurso realizado por uma estação de rádio. Claro que isso foi antes dos dias do VoIP, mas o conceito é o mesmo, somente a tecnologia mudou.


   

 

 



   

    

   



Página 405

 

 

  


Pishing e Vishing O phishing é uma forma de fraude eletrônica, caracterizada por tentativas de adquirir fotos e músicas e outros dados pessoais , ao se fazer passar como uma pessoa confiável ou uma empresa enviando uma comunicação eletrônica oficial. Isto ocorre de várias maneiras, principalmente por email, mensagem instantânea, SMS, dentre outros. O termo "vishing" ou “phishing por voz” se refere ao ato por meio do qual criminosos usam mensagens pré-gravadas para apresentar um falso anúncio de marketing para roubar números de cartões de crédito, cometer outros tipos de roubo de identidade ou tentar vender produtos fraudulentos. Denial of Service ou Negação de Serviço (DoS) Os ataques à disponibilidade podem causar perda de receita, de produtividade e incremento dos custos (normalmente decorrentes de manutenções não previstas) pela indisponibilidade ou degradação do serviço. Dentro dessa categoria incluem-se ataques como o DoS e DDoS que já estudamos e continuam sendo aplicados dentro de uma solução VoIP pelos atacantes. A maioria dos ataques DoS cai em uma das três categorias: Sobrecarga de Recursos Rede - Envolve a sobrecarga de um recurso de rede que é necessário para o bom funcionamento de um serviço. O ataque DoS visa consumir toda a banda disponível, fazendo com que usuários autorizados sejam incapazes de acessar os serviços necessários. Esgotamento de Recursos no Host - envolve a utilização de recursos críticos do host ou endpoint. Quando o uso desses recursos é maximizada pelo ataque de negação de serviço, o servidor não pode mais responder a solicitações de serviços legítimos. Ataque por Pacotes Mal Formados - envolve o uso de pacotes mal formados e dados inesperados, o que pode causar no sistema operacional um crash (parada completa). Um exemplo deste tipo de ataque é usar combinações ilegais de flags TCP. A maioria das pilhas TCP/IP são desenvolvidas para responder a utilização adequada, não são desenvolvidos para detectar anomalias. Quando a pilha recebe dados ilegais, ela pode não saber como lidar com o pacote, causando uma pane no sistema. O mesmo pode ser gerado enviando mensagens SIP mal formadas, as quais o Call manager não consegue interpretar e reinicia imediatamente devido à essa exceção. Esses tipos de problemas ou Bugs são constantemente analisados e corrigidos. 



Acesso não Autorizado a Equipamentos da Rede VoIP Os invasores podem tentar obter acesso a vários componentes da rede VoIP, como um telefone IP ou Cisco Unified Communications Manager (CUCM), tentando descobrir senhas e nomes de usuário ou invadir as telas de login. Ou pode haver recursos que não são protegidos de forma adequada, permitindo um acesso que não deveria ser permitido. No caso dos telefones IP da Cisco existe um risco de segurança relacionado ao acesso Web aos telefones, o qual vem habilitado por padrão e pode ser utilizado por um atacante para descobrir informações como endereços IP e dados sobre outros servidores da rede.


   

 

 



   

    

   



Página 406

 

 

  


Eavesdropping e SPIT Esses são exemplos de ataque à privacidade e confidencialidade que consistem na escuta (eavesdropping), que tem o impacto de expor informações confidenciais de determinado negócio, operação ou pessoa física, podendo evoluir para um ataque à integridade. Já no ataque de SPIT, mensagens não autorizadas são recebidas, violando a privacidade dos usuários do serviço, seria o SPAM na telefonia IP. Outros Ataques Possíveis A lista de ataques possíveis é muito vasta, porém abaixo são sumarizados alguns destes ataques, apenas para que você tenha uma visão do tipo de abuso que pode ser implementado: 















SIP Bombing: é um ataque tipo DoS no qual uma grande quantidade de mensagens VoIP modificadas são "bombardeadas" contra algum dos componente da rede SIP. Nesse caso o sistema fica ocupado tratando essas mensagens e o serviço fica indisponível ou com a qualidade degradada. SIP-Cancel/Bye DoS: outro ataque tipo DoS, no qual o atacante simula uma mensagem de desconexão do tipo CANCEL ou BYE (dependendo do estado da chamada) evitando que o originador possa iniciar conversações ou derrubando sessões em andamento. Manipulação dos registros: é um ataque tipo Spoofing que pode evoluir para Call Fraud e MITM, onde um user agent se faz passar por outro, podendo receber suas chamadas ou fazer chamadas no seu nome. Falsificação de 3xx Response Codes: é um ataque tipo Spoofing que pode evoluir para Call Hijack ou MITM, onde uma mensagem de redirecionamento do tipo 3xx é forjada de forma que o originador transmita a sua comunicação através de um componente de rede comprometido. Escuta do RTP: RTP utiliza CODEC’s padrão para codificar a voz. Se o invasor consegue capturar o tráfego RTP de um canal de voz (hoje facilitado pelo uso das redes wireless), é muito fácil remontar e ter acesso à conversa sendo conduzida. Manipulações do SSRC no RTP: ataque do tipo Spoofing que pode evoluir para um DoS, Call Hijack ou Call Fraud, a reescrita do SSRC pode ser utilizada para interromper chamadas ou remover um usuário da chamada, tomando o seu lugar, ou para enviar conteúdo falso. Manipulação do CODEC no RTP: ataque do tipo DoS, no qual o atacante pode degradar a qualidade da conversa mudando sistematicamente o CODEC sendo usado, por exemplo, para um CODEC de mais alto consumo de banda. Inserções RTCP: ataque do tipo DoS, através do qual o atacante pode interromper conversações em andamento falsificando mensagens do protocolo de controle do RTP, por exemplo mensagens do tipo BYE.

Veremos a seguir algumas maneiras de reforçar a segurança em redes VoIP. Vamos dividir nossa abordagem em quatro áreas: 1. 2. 3. 4.

Separando o tráfego de Voz dos demais tráfegos na LAN. Utilizando equipamentos de segurança (firewall, IDS, IPS, etc). Trafegando a voz em túneis VPN (criptografar as conversações). Reforçando parâmetros de segurança nos dispositivos VoIP.


   

 

 



   

    

   



Página 407

 

 

  


8.1.3 Separando o tráfego de Voz dos demais tráfegos na LAN

Para separar o tráfego de voz do de dados em switches Cisco você deve utilizar uma VLAN de Voz ou Voice VLAN, conforme figura ao lado. A maioria dos telefones IP tem duas portas, uma para conectar o switch e outra para o micro do usuário. Dentro do telefone IP ocorre a separação do tráfego da VLAN de Voz e Dados e o envio correto somente dos dados para o micro, conforme planejado. As principais vantagens de se utilizar a VLAN de voz são:    

Cria um domínio de broadcast separado para tráfego de voz. Protege contra espionagem (eavesdropping) e sabotagem. Torna o uso de técnicas de sniffing mais difíceis. Torna mais fácil de implementar VACLs (Voice ACLs) que são ACLs específicas para o tráfego de voz.

Porém, mesmo com a criação de uma VLAN de voz não garante que o switch sofra ataques já discutidos anteriormente como estouro da tabela MAC, para ataques de MITM e escuta, e switch spoofing que é a colocação de um switch externo e entroncá-lo com o a rede para obter acesso aos pacotes, isso pode ser mitigado desligando as portas não utilizadas e com o BPDU Guard nas portas de acesso.


   

 

 



   

    

   



Página 408

 

 

  


8.1.4 Utilizando equipamentos de segurança (firewall, IDS, IPS, etc)

Outra maneira de mitigar ataques em soluções de VoIP é utilizando equipamentos de segurança em conjunto com os dispositivos de Voz. Por exemplo, o Cisco ASA (Adaptive Security Appliances) é capaz de inspecionar os diversos protocolos de voz para garantir que os protocolos SIP, SCCP, H.323, MGCP e demais atendem aos padrões de voz. Cisco ASA Adaptive Security Appliances também pode fornecer recursos para ajudar a proteger o tráfego de voz possibilitando as seguintes facilidades: 



 

  

Certifica se as solicitações SIP, SCCP, H.323, MGCP e demais estão em conformidade com as normas estabelecidas. Previne que pacotes inadequados do SIP sejam enviados para o Cisco Unified Communications Manager, evitando ataques através de pacotes mal formados ou códigos maliciosos. Limita a taxa de pedidos SIP (ataques de DoS). Reforça a política de chamadas (whitelist, blacklist de chamador/interlocutor e o possibilita o SIP Uniform Resource Identifier). Abre dinamicamente as portas para as aplicações de voz Cisco. Ativa apenas "os telefones registrados" para fazer chamadas. Permite a inspeção de chamadas criptografadas.

Além disso, o Cisco IOS firewall também oferece muitas destas facilidades de segurança citadas acima. Ainda utilizando a figura como referência, o tráfego de voz pode ser criptografado para utilização em redes não seguras, como a Internet. A criptografia do tráfego de voz evita que pacotes capturados possam ser abertos e remontados para ouvir a conversação em questão.


   

 

 



   

    

   



Página 409

 

 

  


8.1.5 Trafegando a voz em túneis VPN (criptografar as conversações)

Outra aplicação está ilustrada na figura mostrada ao lado, onde uma VPN foi criada entre o CUCM e o Gateway de Voz, possibilitando a comunicação segura não somente dos canais de voz mas também da informação de controle ou sinalização. Em conjunto com a VPN é possível fazer a autenticação segura dos usuários remotos que desejam utilizar os recursos de voz, possibilitando acesso remoto seguro dos usuários que estão fora dos limites físicos da empresa ou em home-office.

8.1.6 Reforçando parâmetros de segurança nos dispositivos VoIP

Por último, também é necessário que as configurações dos endpoints e communication managers estejam em conformidade com as melhores práticas de segurança para que o mal uso ou brechas de segurança comuns não possam ser exploradas pelos atacantes. Além de usar os métodos já discutidos até o momento, existem mais formas de proteger os equipamentos da rede VoIP:    

Desenhar uma arquitetura segura para os servidores Reforçar a segurança nos telefones IP Reforçar a segurança nos servidores CUCM Utilizar sistemas IPS, IDS e Firewall

Quando falamos dos telefones IP algumas recomendações abaixo são aconselháveis:   

Utilizar firmware certificado Utilizar arquivos de configuração certificados Desativar (Porta do PC, Botão de configuração, Speakerphone, Acesso via Web)


   

 

 



   

    

   



Página 410

 

 

  


8.2 Questões de Segurança em Redes Sem Fio (Wireless) O termo WLAN é utilizado quando se tem uma rede local sem fio, que utiliza sinais de radio frequência e segue o padrão IEEE 802.11, as WLAN’s possibilitam uma grande área de cobertura e boas taxas de transmissão.

O padrão estabelecido trabalha através de dois métodos: 



Autenticação: verifica se o host tem autorização de comunicar-se na rede. A autenticação ocorre entre o cliente e o ponto de acesso. Criptografia: determina o modo como a informação circula após ser transmitida, os três tipos de criptografia são WEP, WPA, WP2.

Uma rede WLAN 802.11 tem a seguinte estrutura (veja a figura ao lado):     

BSS - Basic service set – uma área de comunicação. STA - Wireless LAN Stations – clientes da rede. AP - Acess Point – ponto de acesso, através dele os clientes se comunicam. DS - Distribution System – interliga os AP’s, o backbone WLAN. ESS – Extend Service Set - Formada por um conjunto de BSS.


   

 

 



   

    

   



Página 411

 

 

  


8.2.1 Padrões 802.11 e Dispositivos Cisco

Os padrões definidos pelo IEEE 802.11 atualmente são: 









IEEE 802.11a: Utiliza a técnica OFDM (Orthogonal Frequency Division Multiplexing), trabalha na frequência de 5 GHz. IEEE 802.11b: Possibilita uma taxa de transmissão superior ao padrão, pois utiliza o High Rate (HR/DSSS). IEEE 802.11g: fornece a velocidade do padrão 802.11a mas com inteligência de transmissão do padrão 802.11b, utiliza o OFDM e opera na freqüência de 2.4 GHz. IEEE 802.11n: Trabalha com taxas de transferências de 65 Mbps a 600 Mbps. Utiliza o processo de transmissão MIMO-OFDM e opera na faixa de freqüência:de 2,4 GHz ou 5 GHz. IEEE 802.11ac: nova tecnologia wireless que possibilita banda de até 1.300 Mbps na frequência de 5 GHz, ou seja, mais do que o dobro da atual especificação que garante produtos operando a até 600 Mbps.

A Cisco aplica a teoria que estudamos até o momento com uma série de produtos que compõe a Cisco Unified Wireless Communications, segue abaixo uma visão geral de cada elemento de rede (veja a figura ao lado): 







Cisco Aironet (Access Points ou AP): são os access points da Cisco que em sua última versão melhora o desempenho e a disponibilidade utilizando o padrão 802.11n e a tecnologia CleanAir nos pontos de acesso Aironet série 3500. Os APs da Cisco podem ser configurados stand-alone ou através do protocolo Lightweight Access Point (LWAPP) utilizando controladoras wireless. Controlador de rede LAN sem fio Cisco ou Wireless LAN Controler (WLC): são responsáveis por funções de controle sistêmico dos APs, como políticas de segurança, prevenção de intrusão, gerenciamento de RF, QoS e mobilidade. Utilizam o protocolo Lightweight Access Point (LWAPP) para controlar os APs e podem ser gerenciados com o Wireless Control System. Sistema de Controle sem fio da Cisco ou Wireless Control System (WCS): software de gerenciamento dos dispositivos sem fio da Cisco. Mobility Services Engine (MSE): O dispositivo Mobility Services Engine (MSE) oferece informações de localização, IPS sem fio adaptável e muito mais.


   

 

 



   

    

   



Página 412

 

 

  


8.2.2 Segurança em Redes sem Fio

A segurança é um ponto fraco das redes sem fio pois o sinal propaga-se pelo ar em todas as direções e pode ser captado a distâncias de centenas de metros utilizando um laptop com antena amplificada o que torna as redes sem fio inerentemente vulneráveis à interceptação. Por isso é muito comum ao não configurar nenhum recurso de segurança em seu AP doméstico que você sirva de provedor de Internet para um ou mais de seus vizinhos, o que além de reduzir a sua banda pode causar infecções por vírus que os computadores desses visitantes sorrateiros podem transmitir. Isso também pode ser estendido para as empresas, as quais podem sofrer invasões pelas redes sem fio, o que abriu um novo leque de opções de entrada para os hackers. Os hackers Wireless tem um conjunto de ferramentas à sua disposição, dependendo do seu nível de conhecimento. Abaixo segue uma lista de ferramentas que são normalmente utilizadas, chamadas “Network Stumbler”, para encontrar redes sem fio:     

Kismet mostra as redes sem fio que não transmitem os seus SSIDs (sem broadcast). AirSnort sniffa e quebra chaves WEP. Cracks CoWPAtty WPA-PSK (WPA1). ASLEAP reúne dados de autenticação. Wireshark pode fazer scan dos dados em redes sem fio e SSIDs do 802.11.

Para os hackers de nível mais avançado com o uso de um analisador de espectro é possível identificar, classificar e encontrar outras fontes de sinais RF (rádio frequência) de Wi -Fi. Analisadores de espectro modernos podem identificar os tipos específicos de dispositivos que estão causando interferências RF e levar até a sua localização física. Lembre-se sempre que as redes sem fio são extremamente convidativas para os hackers, pois nem é preciso entrar no prédio para conseguir o acesso, por isso seja muito criterioso ao planejar uma rede sem fio segura, podemos até utilizar uma palavra de mais efeito nessa recomendação, seja paranoico quando tratar de segurança em redes sem fio. Veja a seguir algumas recomendações de seguranças que devem ser seguidas quando um projeto de wireless é feito para minimizar os riscos de segurança. • Instale o roteador em um local mais afastado da rua e de janelas. • Muitos roteadores permitem controlar a intensidade do sinal então diminua a intensidade para restringir a propagação para fora do prédio. • Trocar a senha padrão do roteador, em geral o nome de usuário é admin e a senha também é admin. • Trocar o SSID padrão do roteador e desabilitar o broadcast do SSID. • Não permitir gerenciamento através da rede sem fio mas somente através da rede cabeada conectada a uma das portas LAN do roteador. • Usar o WPA/TKIP e WEP não são as opções mais seguras de acesso. • Instale atualizações de firmware quando disponibilizadas pelo fabricante. • Desligue o roteador ou desabilite a rede sem fio no computador quando o dispositivo não estiver em uso. • Tenha sempre em mente a segurança de todo o sistema instalando um firewall, atualizando o antivírus, o sistema operacional e os programas. • Em caso de acesso a redes públicas sem fio utilize uma VPN IPSEC para acesso seguro dos seus dados na Internet. • Redes Wireless utilizando WPA2/AES devem ter a senha (pass phrase) mínima de 21 caracteres. • A implantação de uma solução wireless deve utilizar preferencialmente WPA2/AES em conjunto com uma ferramenta de autenticação. A autenticação deve ser tratada por um servidor de autenticação centralizado.


   

 

 



   

    

   



Página 413

 

 

  


• Utilize uma rede guest (convidado) isolada da sua rede corporativa para acesso sem fio de visitantes e terceiros. 8.3 Questões de Segurança em SANs (Storage Area Network) Em linhas gerais, podemos definir SAN como uma infraestrutura que permite que diversos servidores tenham acesso a discos externos de modo rápido e confiável.

O conceito de discos externos já é, há algum tempo, uma realidade mundial, e vem sendo cada vez mais adotado. Os discos externos não são limitados em espaço como um disco interno, são mais fáceis de manusear quando necessário e trazem facilidades para o compartilhamento por vários servidores. A figura central de uma SAN, de fato, é o servidor de discos ou, como é popularmente conhecido, o storage. As SANs vem para oferecer uma resposta ao crescente volume de dados que devem ser armazenados em um ambiente de rede corporativa, além disso a infra-estrutura das empresas estão evoluindo rapidamente para atender a três requisitos de negócio principais:  



Redução de capital e despesas operacionais. Aumentar a agilidade para apoiar a mudança de prioridades de negócios, requisitos do aplicativo e crescimento de receita. Melhorar a replicação de longa distância, backup e recuperação (restore) para satisfazer as exigências regulamentares e melhores práticas da indústria.

Você vai ler algumas vezes o termo fabric ou fabric switch, onde fabric é semelhante em conceito a um segmento de rede em uma LAN, porém agora estamos em uma Storage Area Network ou SAN.


   

 

 



   

    

   



Página 414

 

 

  


A Cisco oferece uma abordagem de nível empresarial para implantação de SANs escaláveis e altamente disponíveis, além de mais facilmente administrada. Soluções de SAN da Cisco oferecem meio de acesso preferencial, gerenciamento e proteção de recursos de informação através de uma variedade de tecnologias de transporte, incluindo Fibre Channel, Fibre Channel over IP (FCIP), Internet Small Computer Systems Interface (iSCSI), Gigabit Ethernet, ou rede de fibra óptica. A família de equipamentos MDS 9000 são multilayer fabric switches que suportam diversos tipos de interfaces e a maioria das facilidades que citaremos a seguir.

8.3.1 Interfaces de comunicação para SANs

As SANs podem ser implementadas utilizando interfaces, de diferentes tipos. A maioria dos SANs usam o protocolo SCSI para a comunicação entre servidores e dispositivos. Os protocolos suportados para transporte entre uma SAN, os quais encapsulam os comandos SCSI, são os seguintes:       

SCSI: Small Computer System Interface FCP: Fibre Channel Protocol FCIP: Fibre Channel sobre TCP/IP IFCP: Internet Fibre Channel Protocol iSCSI: Internet Small Computer System Interface SAS: Serial Attached SCSI FCOE: Fibre Channel Over Ethernet

O SCSI (Small Computer System Interface) é uma tecnologia que permite ao usuário se conectar a uma larga gama de periféricos, tais como discos rígidos, unidades CD-ROM, impressoras e scanners. Características físicas e elétricas de uma interface de entrada e saída (E/S) projetadas para se conectarem e se comunicarem com dispositivos peri féricos são definidas pelo SCSI. O iSCSI utiliza o mesmo conjunto de comandos SCSI sobre TCP/IP (normalmente Ethernet). Nesse caso, os switches, cabos e hubs seriam de protocolo TCP/IP. O Fibre Channel Protocol (FCP) é um Protocolo de Transporte SCSI e que foi desenvolvido para facilitar a comunicação de blocos de dados entre origem-destino em redes FC. No modelo de redes FC, FCP é um protocolo da camada FC-4. Além disso, para o uso do FCP nenhuma modificação especial é necessária no FC e no SCSI, pois utiliza o mesmo formato de quadro e de serviços definidos pelas especificações do FC e a arquitetura SCSI já existente. O Fibre Channel over IP (FCIP) permite a conexão de dois FC-SANs interligando switches através de TCP/IP. Um túnel ponto a ponto é criado através de uma rede IP, e o tráfego Fibre A p o s t i l a / E - Bo o k d o C u r s o I I N S 6 4 0 - 5 5 4      

   

 

 



   

    

   



Página 415

 

 

  


Channel é encapsulado e desencapsulado nos terminais. Quando um túnel é estabelecido, dois FC-SANs se juntam para formar um só FC-SAN virtual. Todos os switches em cada lado do túnel conseguem ver os outros switches como se fossem locais. O Fibre Channel over Ethernet (FCoE) foi desenvolvido com a intenção de manter o modelo Fibre Channel. No FCoE, o quadro nativo do FC é mapeado no quadro do Ethernet, permitindo que tráfegos FC sejam transmitidos através da rede Ethernet. Todos esses recursos de conectividade estão sendo direcionados para utilização dentro de um ambiente de switching, como a nova plataforma Cisco Nexus. 8.3.2 Logical Unit Numbers (LUNs) e LUN Masking

No contexto do armazenamento de dados, um número de unidade lógica (LUN) é um endereço numérico para uma unidade de disco específicos e para o dispositivo de disco em si. Um LUN vem do mundo SCSI e é utilizado como uma forma de diferenciar os discos individuais dentro de um dispositivo comum de destino SCSI, como disk array. Com a máscara de LUN ou LUN Mask, você pode ativar um LUN para hosts específicos, enquanto ao mesmo tempo negando o acesso para outros hosts. Máscara de LUN é implementada em nível do adaptador de barramento de host (HBA – Host Bus Adapter). Um HBA é um adaptador de I/O (entrada e saída) que fica entre o barramento do computador host e a rede Fibre Channel e gerencia as comunicações entre os dois canais. Máscara de LUN, que é implementado no HBA é tão segura como a HBA. Com HBAs é possível forçar o endereço de origem, e se um HBA está comprometido então o processo de LUN masking pode estar comprometido também. Isto significa que a máscara de LUN não pode ser considerada um recurso de segurança por si só. O principal benefício de usar máscara de LUN (LUN Mask) é que é uma forma de manter servidor com comportamento impróprio isolado no seu compartimento, restringindo a atividade do servidor que poderia danificar os discos que são parte de outros sistemas. Por exemplo, os servidores do Windows que estão ligados a uma SAN ocasionalmente podem corromper volumes de discos não-Windows, como volumes do Linux tentando escrever códigos do Windows nesses volumes. Utilizando o LUN Masking você pode esconder esses volumes do Linux dos servidores Windows e evitar esse tipo problema.


   

 

 



   

    

   



Página 416

 

 

  


8.3.3 Zoneamento Fibre Channel

O zoneamento Fibre channel é a divisão de um fabric ou switch de Fibre Channel em pedaços menores. Uma SAN pode conter vários dispositivos de armazenamento, mas nem todos os dispositivos devem ser capazes de comunicar com outros dispositivos na SAN. Zoneamento é uma maneira de realizar esta tarefa de segurança.

O Zoneamento é muitas vezes confundido com uma máscara de LUN porque ambos têm o mesmo objetivo final. No entanto, o zoneamento é aplicado sobre os switchs fabric, enquanto uma máscara de LUN é executada em dispositivos terminais. O zoneamento também é mais seguro, pois membros da mesma zona são capazes de visualizar apenas os outros membros da zona a que pertencem, segregando os usuários por região. Apesar disso, os dispositivos podem ser membros de mais de uma zona. 8.3.4 World Wide Names

A World Wide Name (WWN) é um endereço de 64 bits que as redes Fibre Channel usam para identificação individual de cada elemento em uma rede Fibre Channel. Figura 2 mostra um WWN que pode pertencer a um switch SAN Cisco MDS 9000.


   

 

 



   

    

   



Página 417

 

 

  


Os WWNs são utilizados dentro do zoneamento para configurar as permissões de segurança. Os Worlds Wide Names não representam uma prática de segurança sólida, principalmente porque o WWN pode ser falsificado. Isto significa que se alguém pode comprometer um HBA, pode ser capaz de falsificar um endereço de HBA conhecido e quebrar essa medida de segurança. 8.3.5 VSANs

Uma rede de área virtual de armazenamento (VSAN) é uma agregação de portas de um grupo de switches Fibre Channel que formam um fabric virtual. Você pode alocar portas dentro de um único switch em VSANs múltiplas. Além disso, várias portas em muitos switches podem ser combinados para formar um único VSAN. Desta forma, VSANs são muito semelhantes às VLANs. Também, como com VLANs, uma marcação ou tagging (VSAN ID) é utilizada para identificação das informações das diversas SANs quando cruzar Inter-Switch Links. O VSAN foi um protocolo originalmente proprietário da Cisco, porém foi adotado como um padrão pela ANSI. 8.3.6 Protocolos de autenticação de Porta

Há dois principais protocolos de autenticação de porta para VSANs:  

DHCHAP (Diffie - Hellman Challenge Handshake Authentication Protocol) Challenge Handshake Authentication Protocol (CHAP)

O DHCAP é uma opção para autenticar os dispositivos que se conectam a um switch Fibre Channel, o qual permite que apenas os dispositivos certificados possam ser adicionados ao switch fabric. O CHAP é usado como o protocolo obrigatório em iSCSI, que foi definido pela Internet Engineering Task Force (IETF). O Challenge Handshake Authentication Protocol utiliza um handshake triplo para se autenticar. 8.3.7 Opções de Segurança em SANs

Em SAN, existem três tecnologias que necessitam de uma análise e reforço de segurança: o fabric SAN, os hosts e os discos. Esses são os três componentes que precisam ser garantidos. Dentro desses limites, existem seis zonas de segurança a serem focadas em SANs:      

Contole de acesso ao gerenciamento da SAN (acesso aos dispositivos) Acesso ao Fabric (acesso seguro aos dispositivos) Acesso ao destino (acesso seguro aos LUNs e volumes de destino) Protocolos SAN (protocolos de segurança utilizados na comunicação intra-SAN) Acesso IP ao Storage (FCIP segura e iSCSI) A integridade dos dados e sigilo (criptografia de dados em movimento e os dados em repouso)


   

 

 



   

    

   



Página 418

 

 

  


Quando falamos em Gestão de Riscos de segurança em uma SAN, no que tange ameaças à segurança no gerenciamento devemos incluir as seguintes três principais áreas de vulnerabilidade: 





Switch fabric comprometido: o Switch fabric pode ser comprometido pela alteração ou modificação das configurações, configs perdidas, mudança de portas ou serviços, etc. Isso pode resultar na perda do serviço, parada no sistema e assim por diante. Confidencialidade e integridade dos dados comprometida: pode ser comprometida por uma brecha no sistema, colocando em risco a confidencialidade e/ou a integridade dos dados. Interrupção no processamento do Switch: pode ser feita usando um negação de serviço (DoS) contra o switch, fazendo com que a CPU esgote os seus recursos e pare de funcionar.

Para garantir o acesso ao fabric e volumes de discos há três principais áreas de preocupação: 1. Os dados em si devem ser garantidos a todo custo. O assunto em questão é a perda de confidencialidade e/ou integridade, onde uma brecha no sistema pode levar ao comprometimento dos dados. 2. A integridade LUN deve ser assegurada. Se a configuração LUN é adulterada, poderia haver uma perda de dados e potencialmente a disponibilidade para os usuários finais. Se os dados forem perdidos, a restauração a partir de um backup (se houver) pode levar muito tempo. Quaisquer alterações na configuração podem comprometer a estabilidade do sistema como um todo. 3. A indisponibilidade do próprio switch. Se usarmos como exemplo um ataque de negação de serviço, isso poderia provocar uma indisponibilidade de acesso até que o ataque seja identificado e eliminado. 8.3.8 Protocolos SAN Seguros, Acesso Seguro e Segurança dos Dados

É recomendado proteger os protocolos de SAN que são usados na comunicação switch a switch diretamente. O Encapsulated Security Protocol (ESP) é um protocolo utilizado para criptografia opcional dentro de redes Fibre Channel. O Fibre Channel Security Protocol (FC-SP) é uma estrutura de segurança que oferece vários protocolos para aumentar a segurança da rede Fibre Channel. Existe também o Fibre Channel Authentication Protocol (FCAP), o qual é um método de autenticação opcional entre dois dispositivos usando certificados ou chaves de criptografia, porém sua desvantagem é que ele precisa de uma infraestrutura de chaves públicas (PKI ou Public Key Infrastructure) já implementada para funcionar. As características dentro de iSCSI são usados para garantir acesso IP seguro ao storage, que usa algumas das mesmas técnicas que estão disponíveis para redes IP. Por exemplo, as ACLs são semelhantes às zonas Fibre channel, VLANs são de natureza semelhante ao VSANs e 802.1x segurança nas portas é semelhante a segurança de portas no protocolo Fibre Channel. Por último, é preciso em muitas ocasiões criptografar os dados armazenados em um dispositivo de SAN e também quando ele é transferido de um lugar para outro. Existem várias maneiras de proteger seus dados em uma solução de SAN da Cisco. Como mencionado anteriormente, você pode usar o CHAP, DHCHAP, FCAP, e FC-SP, dentre outros.


   

 

 



   

    

   



Página 419

 

 

  


9 Resumo do Capítulo Bem pessoal, chegamos ao final do capítulo. É muito importante que nesse ponto do curso você tenha domínio dos seguintes itens: System Development Life Cycle. Disaster Recovery ou Recuperação de Desastres. Políticas de Segurança. Análise de Riscos. Fatores para Comstruir uma Rede Segura. Cisco Self Defending Network. Protegendo Borderless Networks. Segurança em Unified Communications, redes sem fio e SANs.        

10 Conclusão Parabéns, se você chegou até aqui é porque concluiu seus estudos! Tenha certeza de que compreendeu todos os conceitos aqui mostrados. Dê uma repassada na matéria e tome notas dos pontos que não entendeu muito bem. Agradecemos pela sua confiança e para quem vai fazer o exame de certificação desejamos boa sorte! Equipe DlteC do Brasil


   

 

 



   

    

   



Página 420

 

 

  

Apostila-Curso-CCNA-Security-m.pdf

Recommend Documents