Category Archives: Segurança

Autenticação, Autorização e Accounting: Conceitos Fundamentais

O presente artigo é o primeiro de uma série que discute a utilização do conceito de identidade para a criação de regras de controle de acesso. Por ser um texto introdutório, começaremos justamente pelos conceitos mais básicos. Por exemplo:  – o que é identidade ?

Identidade pode ser definida como “um conjunto de características próprias e exclusivas de um sujeito”. (Vale registrar que, no universo de Redes e Segurança, o sujeito mais comum ainda é o username). Mas para que os processos de diferenciação entre os usuários possam ser iniciados, é necessário primeiramente validar a identidade apresentada. E, para entender como isso acontece, é fundamental conhecer a terminologia a seguir:

  • Autenticação: processo de verificação de uma identidade alegada, por meio de comparação das credenciais apresentadas pelo sujeito com outras pré-definidas. A combinação username/password é muito comum mas vários outros métodos estão disponíveis (certificados digitais, biometria, etc).
  • Autorização: processo que ocorre após a autenticação e que tem a função de diferenciar os privilégios atribuídos ao sujeito autenticado. Os atributos de autorização normalmente são definidos em grupos mantidos em um base de dados centralizada. (Cada sujeito herda as características do grupo a que pertence…)
  • Accounting: processo por meio do qual um equipamento de Rede que implementa uma política de acesso (accounting client), coleta informações sobre a atividade do elemento autenticado e as envia ao servidor de autenticação.

Balrog

A arquitetura AAA (Autenticação, Autorização e Accounting) define uma forma estruturada para integração dessas três funcionalidades.  Talvez seja mais fácil visualizar o papel de cada um dos componentes se os associarmos às questões que eles foram projetados para responder:

  • Autenticação: trata de responder a questão “quem é o usuário ?”
  • Autorização: tem a função de definir “o que um usuário (já autenticado) tem permissão de fazer” ?
  • Accounting: está relacionada com a questão “o que o usuário fez?”. Através desse processo o cliente de autenticação (equipamento de rede), coleta os dados de atividade do usuário e os envia ao servidor de accounting (o qual, normalmente, contempla todos os elementos AAA).

Listamos abaixo alguns cenários de uso dos conceitos AAA para controle de acesso a serviços de Rede.

  • Controle de acesso em ambientes LAN: permite habilitar o acesso (Layer 2) à porta física (no caso de switches) ou ao segmento áereo (no caso Wi-fi). Para viabilizar tal validação, foi criado o padrão IEEE 802.1X, disponível em Wireless APs e switches LAN modernos. Um cuidado a se tomar é que a expressão “suportar 802.1X” significa basicamente controlar o status “up/down” da porta após autenticação, o que é muito pouco diante das possibilidades da solução. Para ter os benefícios é vital especificar detalhadamente todas as funções AAA desejadas.
  • Controle de acesso em ambientes VPN de acesso remoto (client-to-site): verifica-se inicialmente o direito de montar o túnel e, a seguir, são validadas as credenciais daquele usuário (extended authentication).
  • Controle de acesso através de firewalls: podem ser citados como exemplo as funcionalidades Authentication Proxy (Cisco IOS) e Cut-through Proxy (Cisco ASA). Nesses casos, o firewall intercepta as requisições e aplica regras dinâmicas conforme permissões informadas pelo servidor AAA.
  • Controle de Acesso avançado através de Firewalls: especificamente para a família ASA, existem as possibilidades de criação de políticas de acesso baseadas em usuários/grupos da estrutura de diretório corporativo bem como o uso do atributo avançado “Security Group Tag”. (Mas esse tema certamente merece outro post).
  • Controle de acesso à Internet num ambiente corporativo, definindo políticas aceitáveis de uso conforme o grupo ao que o usuário pertença (por exemplo: funcionários regulares, sub-contratados e visitantes).

Outra aplicação importante da arquitetura AAA está relacionada ao controle de acesso administrativo aos equipamentos de Rede, tarefa essa para o qual o protocol o TACACS+ é otimizado. Recomando fortemente a leitura do texto “RADIUS e TACACS+: dois protocolos complementares“, para saber mais detalhes sobre o tema.

Bem, esse foi apenas um texto inicial. Em breve teremos outros posts tratando de usos específicos dos conceitos aqui discutidos.

** Notas:

  • Apesar de no mundo de TI o sujeito clássico ser um username, tem se tornado cada vez mais freqüente a utilização do termo identidade para definir elementos tais como: dispositivo (ou tipo de dispositivo) de onde partiu o acesso, localidade em que o usuário se encontra (rede corporativa, VPN, ou rede externa) ou aplicação solicitando acesso a um determinado recurso ou processo.
  • Dentre as opções existentes para obtenção do username, podemos citar o uso de um prompt apresentado por alguma aplicação ou a extração direta da algum atributo de um certificado digital.

** Artigos Relacionados:

Alguns cenários práticos de uso do conceito de Identidade: https://alexandremspmoraes.wordpress.com/tag/identity/

Para entender sobre a evolução do controle de acesso baseado em Identidade nos Firewalls, veja o seguinte artigo:

http://wp.me/p1loe7-l2

 

** Agradecimentos:

Registro aqui os agradecimentos ao meu grande amigo Andrey Lee por gentilmente ter produzido (e cedido) a ilustração usada nesse post (espero que se lembrem do filme 1 de “O Senhor dos Anéis”…)

5 Comments

Filed under Português, Segurança

Funcionalidade de Stateful Firewall em Roteadores Cisco: yes, we can !!

Na primeira vez que ouvem sobre a possibilidade de implementar soluções de stateful firewall em roteadores, muitos administradores de Segurança demonstram imediata desconfiança…

Por um lado acho compreensível, visto que os roteadores são, por excelência, elementos provedores de conectividade, não impondo restrições para encaminhamento de pacotes (basta que conheçam a rota para o destino de interesse). Vale ainda lembrar que a operação padrão de roteamento tem natureza stateless, já que os pacotes são roteados como entidades individualizadas ( e não como parte de uma conexão).

Entendo ainda que em pontos específicos da rede, tais como Data Center e borda Internet, não é uma prática recomendável apostar todas as fichas em um elemento só.

Mas o que pensar sobre implementar a funcionalidade de stateful firewall em roteadores que atendem localidades remotas e que, tipicamente, não apresentam requisitos elevados de desempenho ? Seria possível ter um firewall de verdade em um tal roteador ? (- Sem dúvida… Caso contrário, nã0 me atreveria a escrever este post… 😉 )

Começo a responder tais perguntas, afirmando que a funcionalidade integrada de stateful firewall não é novidade nos roteadores Cisco. O modelo Context Based Access Control (CBAC), também conhecido como Classic IOS Firewall está disponível há mais de dez anos e o seu sucessor, Zone-based Policy Firewall (ZFW), ilustrado na Figura 1,  há pelo menos seis…

Figura 1: Visão Geral do conceito de “Security Zone”

Neste ponto da discussão você pode estar se perguntando:

Se já existia o CBAC, por que criar o Zone-based Firewall ? O CBAC não era suficiente ?

Bem, vamos à análise:

  • A abordagem CBAC já provia um firewall stateful mas as regras de inspeção eram criadas entre pares de interfaces, não havendo um conceito de “domínio de segurança” (Security Zone, utilizando a nomenclatura do ZFW). Tal característica dificultava a visualização lógica das relações de confiança entre os elementos da topologia e também trazia desafios em termos de expansibilidade. Imagine, por exemplo, criar regras entre dez interfaces distintas ou estabelecer uma política que controle o acesso entre as interfaces Giga 1/1.200  e Giga 1/2.25… (É fácil perceber que uma política INISIDE>OUTSIDE é algo bem mais intuitivo…)
  •  A linha de raciocínio de construção de políticas adotada pelo ZFW é muito similar à que se usa para configurar Qualidade de Serviço (class-map para classificar pacotes e policy-map para definir as ações a serem tomadas para o tráfego classificado) e, portanto, para os que já estão acostumados com QoS, assimilar os conceitos do ZFW será mais simples. (A estrutura de configuração é mostrada na Figura 2).
  • O modelo proposto pelo Zone-based Policy Firewall permite que o roteador seja configurado de modo a bloquear por default, fato este que o aproxima em comportamento dos appliances de segurança dedicados. Após este passo inicial de “fechar” o roteador, você pode definir os critérios para que os pacotes sejam encaminhados entre duas dadas interfaces (que agora são membros de Security Zones). E teríamos, assim, uma espécie de encaminhamento condicional: além de dispor da rota para o destino, a criação daquela conexão específica deve estar prevista na política de firewall em vigor.

Figura 2: Estrutura de uma política de acesso do Zone-based Firewall

Alguns fatos adicionais merecem especial menção:

  1. O ZFW é a abordagem que vem recebendo todos os investimentos no que concerne a evolução funcional. Só convém usar o CBAC em roteadores muito antigos cujo IOS não suporte o novo modelo.
  2. O ZFW está disponível nas imagens Security do Cisco IOS, juntamente com as funcionalidades de VPN. Desta forma, se você comprou tal imagem por precisar da conectividade segura materializada pelas soluções de VPN,  a boa notícia é que ganhou um stateful firewall de brinde ! 🙂 ( E reciprocamente…)
  3. Os roteadores ISR (Integrated Services Routers), os quais já provêem uma miríade de opções de conectividade e serviços (switching, WLAN, Multicast, Telefonia IP/VoIP, backup via GSM/CDMA/DSL, etc) podem agora ser configurados como gateways condicionais (tanto em modo roteado como modo transparente), o que os torna ainda mais completos e flexíveis.
  4. Nunca é demais enfatizar que as listas de controle de acesso (ACLs) empregadas numa política ZFW são de natureza stateful e, portanto, vão muito além de meros filtros de pacotes.

Termino este breve post, propondo que você estude mais a respeito do Cisco Zone-based Policy Firewall para que possa contar com tal recurso em seus projetos que envolvem os roteadores Cisco ISR. Para facilitar o acesso a informações sobre o tema, produzi uma série de artigos e, naturalmente, espero que o material seja útil. (É importante observar, no entanto, que a página do blog mostra os posts mais recentes primeiro… Vale a pena começar pelos “older posts“…)

*** Nota:

Também é relevante se informar sobre a facilidade de se montar INTRANETS seguras com a tecnologia GET VPN:

*** Leitura Adicional:

Leave a comment

Filed under Português, Redes, Segurança

Segurança para Comunicações Unificadas: o que esperar do seu Firewall ?

Em um artigo anterior, apresentamos os conceitos básicos de VoIP, Telefonia IP e Colaboração (http://wp.me/p1loe7-c2) e caracterizamos o papel das redes convergentes como plataforma de negócios. Não é necessária uma longa reflexão para concluir que um tal apelo negocial vem acompanhado da necessidade de se prover segurança para o transporte integrado de vídeo, voz e dados.

Seguindo o clássico raciocínio de que é recomendável criar “camadas de segurança”, resumimos a seguir algumas iniciativas relevantes no que concerne à Segurança de Telefonia IP:

  • Separação das VLANs de voz e dados nas portas de acesso dos switches LAN (usando o conceito de “Voice VLAN“)
  • Prover proteção contra as técnicas que podem induzir um redirecionamento de tráfego em ambientes de switches LAN (mesmo sem necessidade de configuração explícita de espelhamento de portas). Exemplos de ataques em um tal categoria são ARP Cache Poisoning (combatido com Dynamic ARP Inspection) e emulação do servidor DHCP (combatido com DHCP Snooping).
  • Controle de acesso entre subredes associadas a voz e dados.
  • Criptografia da voz para evitar a remontagem das conversações eventualmente capturadas
  • Proteção dos servidores que implementam as soluções de colaboração usando firewalls
  • Proteção das entidades de sinalização (Call Managers, gateways, gatekeepers, etc) por meio de firewalls.

A discussão de todas as técnicas que acabamos de elencar exigiria muitos artigos e, portanto, concentraremos nossa atenção na última delas. E uma das motivações para uma tal escolha é precisamente esclarecer o significado da expressão “inspeção avançada dos protocolos de telefonia“, sempre presente nos descritivos técnicos dos firewalls disponíveis no mercado (mas quase nunca detalhados).

A esta altura, alguém que já conheça os princípios básicos de segurança de redes pode estar se perguntando: ” – Se voz e vídeo são apenas novas aplicações que usam o transporte convergente, por que precisariam de um tratamento especial ao atravessar um firewall…? A resposta está relacionada à forma com que os protocolos de sinalização de Telefonia IP (que podem usar transporte TCP ou UDP) negociam as portas UDP destinadas aos canais de mídia (RTP/RTCP):

  • Se os firewalls inseridos entre os elementos de sinalização não entenderem perfeitamente a natureza do protocolo em uso (SCCP, SIP, H.323 ou MGCP), não serão capazes de criar corretamente as conexões RTP/RTCP. E, bem sabemos, deixar um intervalo de portas UDP previamente aberto não é uma boa idéia se você tem intenção de implementar uma política de firewall que tenha alguma dignidade… 🙂
  • Apesar de sempre mencionarmos a criação das conexões, também é vital (tanto sob a ótica de segurança como de liberação de recursos) que elas sejam terminadas dinamicamente. Para materializar tal possibilidade é importante que o firewall suporte timeouts diferenciados para as sessões de controle e mídia.
  • Os protocolos de sinalização de voz tipicamente incluem o endereço IP em seu payload (camada de aplicação). Desta forma, caso as comunicações se estabeleçam em ambientes com NAT ou PAT, é fundamental que o firewall tenha consciência de tais características para que possa efetuar as traduções de endereços IP nas camadas 3 e 7 simultaneamente.
  • Um dos atrativos de Telefonia IP é a capacidade de prover confidencialidade para a voz transportada, usando, por exemplo, sinalização sobre TLS (Transport Layer Security) para então derivar os canais Secure RTP (SRTP) para mídia (vide figura 3). O desafio em uma tal situação é que muitos firewalls não conseguem entender a sinalização cifrada e teriam, portanto, que deixar um grande número de portas UDP (associadas ao SRTP) abertas. Isso, em termos práticos, significa abrir mão da criptografia de voz ou do stateful firewall.

Para auxiliar na compreensão dos principais conceitos da integração de firewalls a projetos de UC , passaremos agora à análise de alguns modelos de topologia: um primeiro, contendo apenas telefones IP, e um mais abrangente, prevendo a existência de gateways de voz e comunicação com a rede pública de telefonia (PSTN). Por último (Figura 3), examinaremos a situação de agregar criptografia a fluxos de voz que atravessam o firewall.

A Figura 1 ilustra um cenário simples em que dois IP Phones SCCP (Skinny), que residem em  redes diferentes, precisam se comunicar em uma topologia protegida por um Cisco ASA. A figura caracteriza a situação inicial (apenas sinalização) e um momento seguinte, com uma ligação estabelecida. (Note que o firewall identifica claramente as portas associadas a áudio). Para fins práticos, vale citar que, além da permissão para registro dos telefones e execução de chamadas (porta de serviço TCP/2000 na direção do telefone ao CUCM ), você precisará criar regras que permitam o uso dos serviços auxiliares:

  • TFTP (dos telefones para o CUCM): neste caso, as atribuições principais do servidor TFP são a transferência de arquivos de firmware e configuração para os telefones.
  • Resolução DNS do nome do CUCM ( e eventuais serviços complementares).
  • DHCP é a escolha tradicional para endereçamento dos IP phones. A opção DHCP 150 informa os telefones sobre o endereço IP do servidor TFTP. Tal funcionalidade pode ser habilitada por interface no próprio Cisco ASA.

Figura 1: Cenário simples usando sinalização SCCP (Skinny)

Há ambientes com complexidade bem superior ao que foi mostrado na Figura 1, exigindo alta capacidade de coordenação por parte do firewall. Isso costuma ocorrer porque, mesmo depois de ter migrado toda a sua rede para telefonia IP, você ainda precisará integrá-la com as redes tradicionais de telefonia, fato este que exige a inclusão dos gateways de voz . Se você estiver usando o conjunto de padrões H.323, por exemplo, a primeira tarefa adicional é decidir se os gateways se comunicarão diretamente com o CUCM ou se haverá o uso de um gatekeeper.

Dentre os protocolos definidos no framework H.323, alguns são de particular relevância para redes VoIP/IPT:

  • H.225: responsável por criação e finalização de chamadas em ambientes H.323. As mensagens H.225 usam a porta TCP/1720.
  • H.245: responsável por flow control, negociação de funcionalidades e alocação dos canais de mídia, dentre outras atividades. A porta TCP usada para o H.245 é derivada da inspeção H.225.
  • H.225 RAS: As mensagens de Registration, Admission and Status (RAS) são usadas nos ambientes em que o roteamento de chamadas de voz é executado de forma centralizada por um gatekeeper H.323. A porta UDP/1719 é reservada para o RAS.

Os dois modelos H.323 brevemente descritos são ilustrados na Figura 2. A principal razão para incluir tal exemplo está relacionada com a tentativa de enfatizar que o firewall deve ser capaz de analisar as várias etapas de sinalização e manter o processo de chamadas o mais transparente possível para os usuários finais.  Note que há várias entidades de sinalização envolvidas (CUCM, gateways, gatekeeper), as quais normalmente estão situadas em diferentes interfaces do firewall. Além disso, o objetivo final (após inspecionar as várias mensagens de controle) é estabelecer a chamada entre os telefones (os quais também podem estar localizados em interfaces diferentes).

Cumpre ainda ressaltar que o Cisco Unified Communications Manager (CUCM) pode operar simultaneamente como controlador de chamadas que usem qualquer dos protocolos mencionados (SCCP, SIP, H.323 e MGCP), o que permite seu uso como elemento de interworking entre tais tecnologias. Mais interessante ainda é o fato de o Cisco ASA poder ser incorporado a um tal cenário sem qualquer perda de funcionalidade.

Figura 2: Inserção do firewall em ambientes com H.323

A Figura 3 traz um cenário que envolve troca de sinalização sobre TLS (TCP 2443 para SCCP/TLS ou TCP/5061 para SIP/TLS) e posterior estabelecimento do canal SRTP através do firewall. Basicamente, o firewall se apresenta como CUCM para os telefones (usando os certificados apropriados) e simula ser um telefone para o CUCM. Após criação de tais relações de confiança, os telefones podem se registrar de forma segura e criar as sessões SRTP pertinentes.

Lembrando que as chaves para criptografia de voz são geradas durante o processo de sinalização, usar mensagens de controle em clear text não é uma abordagem conveniente. (Daí o fato de se recorrer ao transporte sobre TLS).

Figura 3: Criptografia de voz (SRTP) em ambientes com stateful firewalls

Para sintetizar o que foi exposto até aqui, achei interessante criar uma espécie de resumo sobre o que não pode faltar no seu firewall para telefonia, usando como exemplo o protocolo SIP (pois sua tendência de adoção é crescente):

  • A partir da análise da sinalização SIP entre o controlador de chamadas IP (Call Manager)  e os telefones IP,  devem ser criadas dinamicamente as permissões pertinentes para o tráfego de mídia (RTP/RTCP) entre os telefones envolvidos.
  • Deve ser possível configurar timeouts distintos para a conexão de sinalização SIP e para as conexões de mídia dinamicamente negociadas (RTP/RTCP).
  •  A inspeção stateful da sinalização SIP deve estar igualmente disponível para TCP e UDP.
  • O firewall deve ser capaz de analisar os pacotes de manutenção do canal de controle (keepalives) de modo a garantir que a conexão de sinalização não necessite ser restabelecida a cada chamada.
  • Deve ser possível especificar os métodos SIP (SIP Methods) aceitáveis e bloquear requisições de conexão que utilizem métodos indesejáveis.
  • Deve ser possível analisar conexões de sinalização criprografadas (SIP over TLS), de modo que sejam criadas dinamicamente as permissões adequadas para o tráfego de mídia cifrado (Secure RTP) entre os telefones IP envolvidos.

Para ir um pouco além do que foi tratado no presente post, sugiro a leitura do texto Firewalls and UC Security (artigo que escrevi para a Cisco Support Community): https://supportforums.cisco.com/docs/DOC-24159

** Leitura Adicional:

Leave a comment

Filed under Português, Redes, Segurança

Múltiplas camadas de defesa: A complementaridade do Firewall e do IPS

Não há muita discussão no que diz respeito à possibilidade de um Sistema de Prevenção de Intrusão (IPS) complementar o trabalho realizado por um firewall stateful. No entanto, é bem comum que se presenciem discussões de cunho quase filosófico sobre o posicionamento relativo de tais elementos em uma topologia de rede. O propósito do presente artigo é discutir as duas opções clássicas e caracterizar porque uma delas se mostra a mais natural. (Não que você precise concordar comigo… :-))

As duas disposições tradicionais são representadas na Figura 1, na qual os conceitos de “antes” e “depois” estão relacionados com o sentido de criação da conexão de uma máquina cliente para um servidor que se deseja proteger.

  • No primeiro arranjo, apenas o tráfego permitido pelo firewall é passado ao IPS, o qual, por sua vez, tem função de promover uma inspeção mais detalhada. Imagine, por exemplo, que se tente fazer um telnet, a partir de uma máquina externa, a um servidor web localizado na DMZ. O firewall poderia bloquear tal acesso sem necessidade de uso de qualquer funcionalidade mais elaborada do IPS.
  • Já no segundo modelo, todos os pacotes passariam inicialmente pelo IPS antes de chegarem à interface outside do firewall. Em algumas situações cheguei a ouvir que a razão de se ter o IPS na rede outside era permitir que ele “protegesse” o firewall ou que limitasse as novas conexões para tal dispositivo…

Figura 1: Posicionamento Relativo de Firewall e IPS

Refletindo por um instante sobre a atuação dos equipamentos de rede no contexto do modelo de camadas TCP/IP, podemos perceber que a complexidade de operação ( e conseqüente impacto em recursos tais como CPU) aumenta na seguinte ordem: Switch LAN (L2) < Roteador < Firewall < IPS.

Os sistemas IPS concentram seus recursos de análise nas camadas de rede, transporte e aplicação. Além disso mantém informação de estado (stateful pattern matching), realizam detecção de anomalias e, após tais tarefas, ainda precisam encaminhar os pacotes permitidos (na camada de enlace). Tantas atribuições acabam significando que a mais alta performance atingida por um IPS (num dado momento) é aproximadamente 4 ordens de grandeza menor que a do maior switch ou roteador da época e cerca de 1/10 da performance do maior firewall disponível. A última comparação é ainda mais favorável ao firewall se as métricas de conexões por segundo (CPS) e pacotes por segundo (pps) forem levadas em conta, conforme já discutido no artigo “Considerações sobre desempenho de Firewalls” (http://wp.me/p1loe7-15).

Uma outra forma de avaliar o cenário é pensar que se fosse possível construir um IPS com a mesma performance do maior roteador disponível, o custo por Gbps protegido pelo IPS seria certamente muito maior do que o custo por Gbps encaminhado pelo roteador. (Não há mágica aqui… Toda a capacidade de análise de padrões e contexto de um IPS exige módulos de hardware e software complexos, o que naturalmente acarreta custos extras).

Mas de onde vem a (eventual) percepção de que um IPS teria maior desempenho que o Firewall ? (– Seria natural ter o IPS antes do Firewall ?) Enxergo duas possíveis explicações:

  • Em um grande número de empresas a solução de IPS foi comprada (ou implementada) bem depois que o firewall já estava em uso. Essa diferença de fase entre os projetos de Firewall e IPS pode ter contribuído para que o IPS fosse selecionado entre as ofertas mais modernas do mercado ao passo que o firewall era um pouco antigo (no que diz respeito a desempenho).
  • Os parâmetros utilizados para análise provavelmente foram restritos a throughput (Gbps), de modo que foi negligenciado o fato de que um IPS tem natureza stateful. ( Conforme já mencionado, CPS é um atributo chave na avaliação de qualquer elemento stateful).

Uma opção que pode ser interessante para prover visibilidade adicional é representada na Figura 2. O IPS está localizado depois do firewall e um IDS (Intrusion Detection System) foi acrescentado à rede externa (em modo passivo, sem bloqueio de conexões). Desta forma pode-se obter informação sobre tentativas de ataque (inclusive direcionados a alvos entre o roteador e o firewall). O desafio é justamente ter uma equipe (tipicamente um Grupo de Resposta a Incidentes) que possa tirar proveito dos dados coletados.

Figura 2: Combinando Firewall, IPS e IDS

Se você ainda não está convencido sobre qual seria a opção mais natural, imagine a alegoria proposta na Figura 3. Considerando que o controle de passaporte (ou mesmo o check-in) corresponde ao firewall e que o sistema de raio-X represente o IPS, apenas quem teve acesso concedido ao portão de embarque será submetido à inspeção avançada. Lembre-se de sua experiência em aeroportos e considere a inversão dos processos: todos que chegam ao terminal passam inicialmente pelo raio-X, independentemente de terem viagem marcada…

Figura 3: Ilustrando a relação entre Firewall e IPS

O modelo que emprega o Sistema de Prevenção de Intrusão após o firewall é adequado tanto em projetos em que os equipamentos são distintos quanto naqueles em que o IPS consiste em um módulo do firewall. Na segunda opção é ainda comum que o firewall selecione os tipos de tráfego que serão direcionados ao IPS (em vez de se fazer o espelhamento completo), ação esta que também contribui para um melhor uso dos recursos de IPS.

** Artigos Relacionados:

** Recursos Adicionais:

1 Comment

Filed under Português, Segurança

Protocolos Seguros para gerenciar sua Rede LAN

Nas comunidades de TI e Telecom é bem comum que se propague a idéia de que as disciplinas de gerenciamento e segurança de Redes são inconciliáveis (e mutuamente excludentes). Em vez de formar algum juízo de valor, entendo ser conveniente buscar soluções que mostrem que tal pessimismo não pode se perpetuar. Afinal, as redes precisam ser gerenciadas… E, se por um lado Segurança não pode ser um entrave para o gerenciamento, este último não deve inserir vulnerabilidades.

O objetivo do presente artigo é apresentar resumidamente as áreas de gerência que tipicamente estão presentes em uma rede LAN e, quando possível, mostrar versões seguras para os protocolos de Rede envolvidos (dos quais o SNMPv3, Simple Network Management Protocol versão 3, é apenas um exemplo).  Admitiremos em nossa análise o caso mais simples, isto é, o uso de um switch nível 2 na camada de acesso.

Acesso seguro à linha de comando (Command Line Interface = CLI) para fins de configuração e monitorização:

  • Usar cliente Secure Shell versão 2 (SSH) em substituição ao Telnet
  • Configurar o switch para que não aceite acesso terminal que não seja SSH
  • Usar no mínimo criptografia DES mas, se possível, optar por 3DES-168 (ou AES).
  • Controlar os comandos que podem ser executados via SSH e console física por meio do protocolo TACACS+ (autenticação, autorização e accounting de comandos).

Se você confiar as atividades de configuração e monitorização a uma interface gráfica (Graphical User Interface = GUI), convém que sejam observadas as seguintes orientações:

  • Usar HTTPS e não HTTP.
  • Definir os algoritmos criptográficos aceitáveis para a garantia de confidencialidade da sessão HTTPS. Usar no mínimo DES mas, preferencialmente, 3DES-168 (ou AES).
  • Exigir autenticação de usuário administrativo seguida de autorização e accounting dos comandos através do protocolo TACACS+.

Para transferência segura de arquivos (imagens de sistema e arquivos de configuração, por exemplo) é recomendável que se opte por SCP (Secure Copy) ou SFTP (Secure FTP) em lugar de FTP e TFTP.

Após esta breve descrição das opções de configuração e acesso a arquivos, voltemos ao SNMP…

A versão 3 do protocolo SNMP (SNMPv3) foi criada com o propósito de eliminar a visão histórica de que o significado da sigla era Security is Not My Problem. O novo modelo inclui não só autenticação individualizada (por usuário) mas também criptografia dos dados transmitidos. Lembrando que há operações do SNMP que permitem até mesmo alteração da configuração do equipamento, é fácil perceber que não convém que os dados (e muito menos a senha de acesso) sejam transferidos em claro.

Vale, no entanto, um alerta: a RFC 3414 (SNMPv3) prevê três modos possíveis de operação do protocolo, os quais são representados na Figura 1. Desses, apenas o AuthPriv contempla simultaneamente autenticação e criptografia, significando que é o único que atende nosso objetivo de gerenciar com Segurança a rede. Desta forma, se você está pensando em utilizar SNMPv3, deve verificar tanto do lado das soluções de gerência como dos elementos gerenciados, se existe suporte ao modo AuthPriv e, neste caso, quais os algoritmos criptográficos disponíveis. (Imagine um produto que suporta criptografia… Mas com chave de 5 bits… )

Figura 1: Modos de operação e exemplo de pacote SNMPv3 AuthPriv

Uma outra área relevante de gerência de Redes é o controle de sincronismo entre os equipamentos. Para se ter uma idéia da importância de se dispor de uma referência única (e confiável) de relógio, listamos algumas aplicações em que a informação de tempo é utilizada:

  •  Coerência das informações de gerenciamento
  •  Coerência do accounting de utilização dos serviços de rede (normalmente controlados via RADIUS)
  •  Coerência do accounting de acesso administrativo a equipamentos de Rede (função clássica do TACACS+)
  •  Verificação da validade de Certificados Digitais
  •  Definição de políticas de acesso baseadas em horário
  •  Verificação da validade de licenças de software vinculadas a horário
  •  Subsídio para medição confiável de parâmetros de SLA
  •  Subsídio para auditoria (desde que o processo utilizado para sincronização seja seguro…)

O protocolo clássico de sincronismo é o Network Time Protocol (NTP), o qual em sua versão 3 (RFC 1305, datada de 1997) já especificava o uso de autenticação do servidor pelo cliente através de hash MD5. Diante das aplicações que acabamos de listar para a informação de sincronismo, surge naturalmente a pergunta:  – Você, na condição de administrador de Redes ou Segurança, se sentiria confortável se os seus equipamentos de Rede aceitassem qualquer informação de tempo que lhes fosse passada ?

Diante disso, vale advertir que existe uma versão simplificada do NTP, denominada SNTP (Simple NTP), que não inclui autenticação e que, portanto, não é adequada para ambientes em que é preciso comprovar comprometimento com minimização do risco operacional e disponibilizar informações para fins de auditoria. Mais detalhes são providos na Figura 2.

Figura 2: Autenticação entre cliente e servidor NTP

O presente texto é uma tentativa de caracterizar um primeiro passo na busca do objetivo maior de se construir redes LAN mais seguras. Isso porque, apesar de existirem  várias funcionalidades específicas de Segurança de LAN (802.1x, Port Security, Private VLANs, etc), se o gerenciamento não for conduzido de forma segura, todo o resto do esforço poderá ser perdido.

** Sumário de Recomendações:

  • Acesso Remoto Seguro a CLI: SSHv2
  • Acesso Remoto via Interface Gráfica: HTTPS
  • Transferência Segura de arquivos: SCP (Secure Copy) ou SFTP (Secure FTP)
  • Monitorização e Alertas: SNMPv3 no modo AuthPriv
  • Sincronismo Seguro: NTPv3 (no mínimo) com autenticação MD5 por parte do cliente (equipamento)
  • Controle de Acesso Administrativo (autorização e accounting de comandos): TACACS+

** Notas:

  • Já existe o NTP versão 4 mas muitos produtos ainda não o implementam. Enquanto a disponibilidade do novo protocolo não se amplia, o mínimo aceitavél é o suporte à versão 3.
  • As considerações aqui feitas para um switch L2 também se aplicam a elementos que operam em camada 3 (switches L3 e roteadores).
  • Há um interessante guia de hardening de switches Cisco produzido pela NSA (National Security Agency), cuja leitura é altamanente incentivada: (http://www.nsa.gov/ia/_files/switches/switch-guide-version1_01.pdf)

** Artigos Relacionados:

5 Comments

Filed under Português, Redes, Segurança

RADIUS e TACACS+: dois protocolos complementares

Além de mostrar que os protocolos RADIUS e TACACS+ são complementares (e não concorrentes), o presente texto tem a intenção de esclarecer alguns erros conceituais envolvendo tais protocolos.

Diante da confusão clásssica, resolvi montar uma espécie de sessão “fatos e mitos” para facilitar o entendimento:

  • O protocolo TACACS (RFC 1492) já não é mais utilizado em implementações práticas, pois não oferece nenhuma vantagem significativa em relação ao RADIUS. O TACACS+ é uma evolução do TACACS que, dentre outras coisas, utiliza transporte TCP (em vez de UDP, como é o caso do TACACS). Desta forma não faz sentido solicitar “TACACS”, pensando-se em obter os benefícios do TACACS+.
  • Apesar de ter sido criada pela Cisco, a especificação do TACACS+ (que data de 1997 !) está documentada  sob a forma de ‘draft’ no site do IETF, permitindo que vários outros fabricantes desenvolvam o suporte a tal protocolo. E isso de fato aconteceu. Muitos fabricantes de dispositivos de redes (tais como roteadores, switches e firewalls) declaram em seus data sheets o suporte a TACACS+.
  • Alguns fabricantes criaram uma implementação inspirada no TACACS+ que foi batizada como HWTACACS. A despeito do novo nome, os clientes HWTACACS suportam as mesmas características do TACACS+ e são, inclusive, compatíveis com o servidor TACACS+ mais  usado no mercado (Cisco Secure Access Control System – CS ACS).
  • O protocolo RADIUS foi desenvolvido e otimizado para fazer controle de acesso a serviços de Rede. É bem natural para o RADIUS, por exemplo, diferenciar os perfis de acesso à Rede em ambientes dial-up, VPNs de acesso remoto (tais como IPSec e SSL VPN) e redes sem fio (ou cabeadas) que usam 802.1X.
  • Por não separar os processos de Autenticação e Autorização (dentro da arquitetura AAA), o RADIUS é mais adequado para atribuir um perfil de autorização (authorization profile) que permaneça ativo no equipamento de rede durante todo o tempo de conexão do usuário. O RADIUS não é usado para tarefas interativas de autorização durante a sessão.
  • Exemplos de perfis atribuídos com RADIUS são: enquanto usuários do Grupo 1 têm acesso a FTP e Telnet, usuários pertencentes ao Grupo 2 podem usar web (HTTP) e e-mail (SMTP).
  • O TACACS+ separa os processos de Autenticação e Autorização e foi otimizado para controle de comandos de configuração e monitorização ( e até dos argumentos desses comandos). Este tipo de cenário de aplicação do TACACS+ costuma ser chamado Controle de Acesso Administrativo a Equipamentos de Rede (em oposição a controle de acesso a serviços de rede).
  • Cada comando disponível em um equipamento que suporte cliente TACACS+ é autorizado individualmente pelo servidor antes que possa ser executado. Imagine a alternativa (nada flexível e gerenciável) de fazer um download de todas as possíveis combinações de comandos e argumentos sob a forma de um authorization profile... (Especialmente em equipamentos que possuam uma miríade de funcionalidades tais como os roteadores ISR da Cisco).
  • Todas as definições de comandos de administração dos equipamentos são efetuadas de forma centralizada no servidor TACACS+. Isso é particularmente importante em redes com grande número de ativos de rede. (Considere, por outro lado, a opção de definir os comandos em cada equipamento de Rede…)
  • Com TACACS+ é possível permitir, por exemplo, que um grupo de usuários tenha acesso de configuração aos comandos relativos a Telefonia IP em um conjunto de equipamentos e que possa apenas visualizar as informações de rede em um segundo conjunto. A flexibilidade é total ! ( E você não está mais sujeito a soluções do tipo “tudo ou nada”.)
  • Se você deseja dispor de toda a capacidade de controle de acesso administrativo provida pelo TACACS+, é necessário deixar claro, em uma eventual RFP, que devem ser implementadas integralmente as funções de AAA para tal protocolo (especificamente no âmbito de autorização e accounting de comandos). Falar simplesmente que um equipamento “deve suportar TACACS+” não garante que os serviços AAA de interesse sejam fornecidos.

Após essa breve compilação sobre as características dos protocolos, gostaria de enfatizar alguns pontos:

  • A grande maioria dos equipamentos de Rede suportam simultaneamente os clientes RADIUS e TACACS+. Em vez de tentar encará-los como concorrentes, convém entender as aplicações para as quais são otimizados e fazer a seleção correta. É perfeitamente normal (e aconselhável), por exemplo, usar RADIUS num ambiente 802.1X para controlar o acesso de qualquer usuário  a uma porta física do switch e um processo TACACS+, separado, para controlar os comandos que os usuários com privilégio de administrador de rede podem executar no switch (para configurá-lo e operá-lo).
  • O servidor AAA mais difundido do mercado, CS-ACS, suporta a operação simultânea como servidor RADIUS e TACACS+. Isso permite que o CS-ACS seja usado tanto para as funções de controle de acesso a serviços de rede como para as tarefas de controle de acesso administrativo a equipamentos de rede.

Para facilitar a obtenção de informações adicionais sobre o assunto, listo a seguir uma coletânea de links úteis:

  1. TACACS+ and RADIUS Comparison (http://www.cisco.com/en/US/tech/tk59/technologies_tech_note09186a0080094e99.shtml)
  2. TACACS+ Protocol Version 1.78 (http://tools.ietf.org/html/draft-grant-tacacs-02)
  3. Original TACACS RFC (http://tools.ietf.org/html/rfc1492)
  4. Além da discussão teórica sobre a arquitetura AAA (incluindo os cenários mais adequados para o uso de RADIUS e TACACS+), o capítulo 14 do livro Cisco Firewalls (Identity on Cisco Firewalls) traz inúmeros exemplos práticos de uso de AAA em roteadores e Firewalls Cisco http://www.ciscopress.com/bookstore/product.asp?isbn=1587141094

** Artigos Relacionados:

Leave a comment

Filed under Português, Segurança

INTRANETS Seguras e Expansíveis com GET VPN

O termo VPN (Virtual Private Network) é utilizado para representar tecnologias que se propõem a emular as características de uma rede privada mesmo quando os dados são transportados sobre uma infra-estrutura compartilhada.  A motivação comum às várias soluções de VPN é prover uma alternativa ecomonicamente viável aos circuitos dedicados de comunicação WAN, sem comprometer os aspectos de segurança.

Mas o termo segurança é abrangente e pode representar recursos bem distintos quando considerado sob a perspectiva de cada tecnologia analisada. As duas modalidades mais comuns de VPN (IPSec e MPLS-VPN) são otimizadas para resolver problemas complementares e possuem desafios também complementares.

A arquitetura de segurança  IPSec provê respostas para as questões de criptografia de dados, integridade, autenticação e gerenciamento de chaves criptográficas. E tudo isso é feito através de protocolos e algoritmos padronizados, fato este que a tornou uma referência quase onipresente quando o assunto é VPN. No entanto, o modelo IPSec prevê o uso de negociações ponto-a-ponto entre as partes comunicantes e encontra desafios, principalmente de roteamento, quando precisa ser implantada em larga escala.

Já o serviço MPLS-VPN provê a segmentação lógica da Rede de transporte e roteamento otimizado (any-to-any)  mas não traz qualquer definição associada à classe de disciplinas tratadas pelo framework IPSec.

Diante das capacidades expostas, consideremos agora a demanda de montar a Intranet de uma grande empresa que usa Comunicações Unificadas IP entre seus sites (interesse de tráfego any-to-any) mas que, para atender a regulamentações de seu segmento de mercado, precisa lançar mão dos benefícios providos pelo IPSec (especialmente criptografia de dados).

Em primeira análise, duas respostas simplistas poderiam ser apresentadas:

  • Montar sessões IPSec ponto-a-ponto entre cada entidade remota e o site central. Tal abordagem não seria satisfatória, pois poderia comprometer a meta de delay aceitável (150ms) para o tráfego de voz. Além disso, estaríamos abrindo mão da conectividade full-mesh que caracteriza o MPLS.
  • Configurar sessões (túneis) entre cada dois pontos remotos, de modo a evitar a passagem pela localidade central.  Além de ser praticamente ingerenciável sob o ponto-de-vista de configuração, um tal cenário ainda exigiria que cada gateway de VPN remoto (tipicamente um roteador) suportasse um número muito grande de túneis simultâneos, o que implicaria aumento de custo.

Se a mera sobreposição do IPSec ao MPLS não atende as necessidades especificadas, por que não desenvolver uma tecnologia que utilize as definições IPSec sem dispensar a conectividade otimizada provida pelo MPLS ?

Foi exatamente o que a Cisco fez… Tomando por base a RFC 3547 (Group Domain of Interpretation – GDOI) e assumindo a premissa de que para Intranets não é necessário se preocupar com a questão de esconder o endereçamento IP privado, foi criada tecnologia Group Encrypted Transport VPN (GET VPN), cujas características essenciais são elencadas a seguir:

  • Criação de Security Associations para grupos de gateways em vez do tradicional ponto-a-ponto.  Tal escolha se justifica, pois no âmbito de Intranets assume-se que os gateways VPN participantes possuem o mesmo nível de confiança. O controle de admissão de um gateway (Group Member, no contexto GET VPN) a um grupo é efetuado por uma nova entidade denominada Key Server, a qual também é responsável por distribuir, de forma centralizada, as chaves e políticas de criptografia  a serem usadas pelos membros do grupo.
  • Preservação do cabeçalho IP no pacote cifrado, sem mudar o formato do pacote IPSec (ESP) padronizado. Isso significa que um pacote criptografado com GET VPN é um caso particular de IPSec e, portanto, permite o aproveitamento de todos os algoritmos e hardwares criptográficos construídos para a tradicional tecnologia de VPN.

    GET VPN: Preservação do Cabeçalho IP

Alguns benefícios decorrem naturalmente das definições básicas de GET VPN:

  1. A preservação do cabeçalho garante que os pacotes cifrados usem o mesmo roteamento dos pacotes não-cifrados, dispensando assim a criação de uma nova camada de roteamento para o tráfego VPN.
  2. O valor do campo DSCP é automaticamente copiado para o header IP externo e, portanto,  o investimento em QoS (classificação e marcação) continua válido para o tráfego cifrado.
  3. Pode-se contabilizar a utilização da rede, por usuário, independentemente dos pacotes serem cifrados, o que representa um ganho de visibilidade em relação ao IPSec tradicional.
  4. Dado que os Group Members possuem a chave para decifrar o tráfego enviado por qualquer membro do grupo, torna-se natural e direta a distribuição de conteúdo multicast com criptografia (de forma idêntica à que se faria para tráfego não cifrado). Ressalte-se aqui que o GET VPN é a primeira tecnologia a vencer tal desafio.
  5. O gerenciamento de políticas de criptografia é bastante facilitado, pois é feito pelo Key Server de maneira centralizada. Isso é particularmente relevante para os provedeores de serviço que não mais necessitam configurar túneis VPN e definições de interesse de tráfego cifrado em centenas de equipamentos.

    Relações entre os elementos GET VPN (KS e GM)

Um aspecto crítico a se manter em mente é que um roteador habilitado para tal solução não deixa de dispor dos recursos do IPSec clássico. Pode-se empregar GET VPN para a montagem de um grupo Intranet e, ao mesmo tempo, IPSec tradicional para uma conexão Internet segura. Outro ponto relevante é que um mesmo roteador pode participar simultaneamente de vários grupos distintos, permitindo, assim que se obtenha uma solução simples de isolamento de departamentos dentro de uma mesma empresa.

Para obter mais informações sobre o assunto GET VPN, visite o portal:

http://www.cisco.com/go/getvpn

Leave a comment

Filed under Português, Redes, Segurança